外部PGMOがプロジェクトの炎上を事前に察知します


PGMOゲートチェックのイメージ

ゲートチェックとは?

ゲートチェックはプロジェクトの各工程完了/開始タイミングで成果物や計画を第三者目線でレビューしプロジェクト改善点をレポートします。

 

ゲートチェックはプロジェクト各工程の完了/開始タイミングで実施します。

  1. 当該工程成果物をご提供いただく
  2. PGMOが成果物をレビューし、レビュー表を返信
  3. PJリーダー層/経営層/CxO層向けに当該工程完了と次工程開始の判定材料をレポート

の手順で1工程のゲートチェックを実施します。

 

プロジェクト開始前、プロジェクト進行中のいずれであってもゲートチェックサービスは提供可能です。

※進行中プロジェクトの場合、工程区切りでなくご契約時にプロジェクト全工程の成果物をご提供ください


Guradian Gate ご依頼の流れ

まずはお問合せください。無料相談会でヒアリングし、各種ご提案いたします。

Guardian Gate ご依頼のフロー

 

  • プロジェクトの現況/課題などヒアリング
  • Guardian Gate サービスのご説明
  • おおよそのゲートチェックタイミングのご提案

などディスカッションし、ゲートチェック計画書とお見積書を提示します。

サービス内容に納得いただけましたら、ご発注ください。

契約/NDA締結後、プロジェクトリーダー層向けのご説明を経て、初回ゲートチェックを実施します

Guardian Gate サービスレベルと費用


■ライトガード梅コース:35万円(税別)×ゲートチェック回数

成果物のレビュー結果と評価レポートを返信し、プロジェクト側の対応を見届けないサービス

確認応答するTCPプロトコルに対するNTPプロトコルのようなサービスですので、レビュー結果に対するプロジェクト側の対応はプロジェクトリーダー層やステークホルダーが未届け点検する必要があります。例えば

「XXXの表記は一意に汲み取りにくいのですが、どういう意味ですか?」

といったレビュー質問に対する質疑ができないため、

「XXXの表記をPJ内で認識齟齬がないか確認の上、IT/業務/ベンダーの3主体で合意し、一意に汲める記載に改めてください」

といったレビュー指摘でカバーすることになります。


■スタンダードガード竹コース:50万円(税別)×ゲートチェック回数

成果物のレビュー結果と評価レポートを返信し、レビュー対応結果を1回だけ再チェックするサービス

レビュー結果に対するプロジェクト側の対応はプロジェクトリーダー層やステークホルダーが未届け点検する工数がない場合、PGMOが指摘対応後の成果物を再度レビューいたします。概ね竹コースで重度のリスクはヘッジできます。

  • プロジェクト側はレビュー表の質問/指摘に対して担当者が回答を追記する
  • 指摘事項を元に成果物を改訂する

の作業が完了したタイミングで改訂版成果物/レビュー表を返信ください。PGMOが再レビュー結果を返信しますが、全てのレビューがCLOSEできてない場合は梅コースと同様、プロジェクトリーダー層やステークホルダーが見届け点検する必要がありますが、概ね竹コースで重度のリスクはヘッジできています。


■フルガード松コース:65万円(税別)×ゲートチェック回数

成果物のレビュー結果と評価レポートを返信し、レビュー指摘対応が完全に実施されCLOSEするまで見届けるサービス

PGMOがレビュー指摘がCLOSEするまで見守ります。レビュー往復回数は無制限です。


@ゲートチェックに要する期間

1ゲートチェックは最短2営業日で返信します

成果物数やページ数の多寡に依らず、下記メソッドによってレビュー深度をコントロールし、工程成果物提出から最短2営業日でレビュー完了し、十分な効果を発揮できます。

  • 仕様書やテスト結果等はサンプルチェックとなります。
  • 抜け漏れや不整合を検知したら「XXXが漏れています、再度、全量の抜け漏れチェックを実施してください」旨の指摘とし、全量の抜け漏れや不整合チェックはプロジェクト側に委ねます。

Guardian Gate 効果

平均1工程のゲートチェックで20~30の指摘/質問をしています

 

PGMOは1回のゲートチェックで平均20~30のプロジェクトエラーを指摘

プロジェクトの出来不出来や対象工程にも依存しますが、PGMOレビューで、およそ20~30のレビュー指摘/質問(優先度中/高)をしています。

これはブランドコンサルファームのコンサルPMOや大手SIerの参画可否に依存しません。

平均予算7億円規模のリッチな管理下にあるプロジェクトであっても、1工程あたり20以上のプロジェクトエラーをレビュアーや管理者が検知できていません。潜在的不備を抱えたまま当該工程完了が承認され、プロジェクトが進行しています。これが実態なのです。


プロジェクトリスクを極小化しましょう!

変更や修正が後続工程になるほど、コストや影響スコープが過大になります。

プロジェクト単体で検知できないエラーをGurdian Gateで早期発見し、スピーディーに修正しませんか?