『クライアントにITプロジェクト経験者がいない』PMなら成功するための体制を準備！
クライアント体制に不備がったら、PMは成功のために思考をフル回転させてください。
✅常にクライアント側の体制に泣かされている方✅PJリスクを集めているPMやPMO✅プロマネ初心者を抱える管理者にお伝えしたいプロジェクトリスクの情報です。
プロジェクトは予期せむトラブルに見舞われるものです。
その中でも、クライアントの都合で作業が停滞することもあり、クライアント体制に関するトラブルも多いのものです。
『クライアント側にITプロジェクト経験者がいない』ことで、プロジェクトが前に進まないと嘆くプロジェクトマネージャーもいます。
しかし、『無い物ねだり』をしていてもプロジェクトは進みません。
その時は、『クライアント側へITベンダーのメンバーをアサインする』を行いましょう。
意外にも、これができていないPMが多いって、ご存知でしょうか？
その中でも、クライアントの都合で作業が停滞することもあり、クライアント体制に関するトラブルも多いのものです。
『クライアント側にITプロジェクト経験者がいない』ことで、プロジェクトが前に進まないと嘆くプロジェクトマネージャーもいます。
しかし、『無い物ねだり』をしていてもプロジェクトは進みません。
その時は、『クライアント側へITベンダーのメンバーをアサインする』を行いましょう。
意外にも、これができていないPMが多いって、ご存知でしょうか？
■今回のテーマ
プロジェクト計画における『体制の構築』の検討の中で、『クライアント側のITプロジェクト経験がいないが、クライアントがどうにかするだろうと放置した』ことにより、『クライアント側の体制にITプロジェクトの経験者がいない』という問題が起こりました
この問題を取り上げて、原因の追求、解決策、リスク対策を解説していきます。
※プロジェクト検証の結果をお伝えするにあたり、架空の企業である「株式会社XYZ」での出来事として紹介します。
prologue
株式会社XYZは、市場シェアの拡大と業務コストの削減のために、新規プロジェクトを立ち上げることになりました。
プロジェクトの目的として、売上の10%増加と業務コストの20%削減を掲げています。
目的を達成させるためには、個々の目標の設定が必要です。
品質目標は、レスポンスタイム、受け入れ合格に数値目標を設定しました。
コスト目標は、開発費用を1800万円以内として、スケジュール目標は、リリース日を10月1日、主要なマイルストーンをユーザーテストによる品質判断としています。
また、プロジェクトの開始は、4月1日。開発期間を6ヶ月としました。
【プロジェクトの登場人物】
プロジェクトの目的として、売上の10%増加と業務コストの20%削減を掲げています。
目的を達成させるためには、個々の目標の設定が必要です。
品質目標は、レスポンスタイム、受け入れ合格に数値目標を設定しました。
コスト目標は、開発費用を1800万円以内として、スケジュール目標は、リリース日を10月1日、主要なマイルストーンをユーザーテストによる品質判断としています。
また、プロジェクトの開始は、4月1日。開発期間を6ヶ月としました。
【プロジェクトの登場人物】
▷山田
株式会社XYZの事業部長であり、プロジェクトオーナー。
▷木村
株式会社XYZの社内調整役。クライアント窓口であり、ITベンダーとコミュニケーションを取る。
▷佐藤
このプロジェクトの開発を担当する株式会社ABCのプロジェクトマネージャーであり、今回初めてプロジェクトマネージメントを行うプロマネ初心者。
▷PMアドバイザー
The manager's Barに所属。プロマネ初心者の佐藤のマネジメントアドバイザー
【プロジェクト状況】
現在のプロジェクトは、要件定義工程である。当該工程の所要期間を50%消化した時点で、クライアント内部で要件が確定できていないことから、クライアント窓口の木村から『要件定義工程の延長して欲しい』と要望された。
プロマネの佐藤は、状況の把握をしていますが、具体的な問題が分かっていない。
そのため、PMOの私へサポートを求めてきた。
（以降のSTEP1-STEP4はPMOが実施した）
株式会社XYZの事業部長であり、プロジェクトオーナー。
▷木村
株式会社XYZの社内調整役。クライアント窓口であり、ITベンダーとコミュニケーションを取る。
▷佐藤
このプロジェクトの開発を担当する株式会社ABCのプロジェクトマネージャーであり、今回初めてプロジェクトマネージメントを行うプロマネ初心者。
▷PMアドバイザー
The manager's Barに所属。プロマネ初心者の佐藤のマネジメントアドバイザー
【プロジェクト状況】
現在のプロジェクトは、要件定義工程である。当該工程の所要期間を50%消化した時点で、クライアント内部で要件が確定できていないことから、クライアント窓口の木村から『要件定義工程の延長して欲しい』と要望された。
プロマネの佐藤は、状況の把握をしていますが、具体的な問題が分かっていない。
そのため、PMOの私へサポートを求めてきた。
（以降のSTEP1-STEP4はPMOが実施した）
目次
STEP1：問題の設定
今回の問題は、プロジェクトで起きた事象を、様々なプロジェクト情報を元に考えたところ、『組織マネジメントエリア』で起こっている問題として取り扱うことにした。
そして、『クライアント側の体制にITプロジェクトの経験者がいない』、このように問題を設定した。
STEP2：原因の究明
この問題は、品質目標である要望達成率100%を逸脱、スケジュール目標であるリリース日を逸脱している。
そこでPMOの私は、原因の仮説を立て検証を行った。
STEP3：解決策
この問題を放置することは、デスマーチプロジェクトの危険があるため、PMOの私は解決策を３つ考え、プロジェクトオーナーの山田と協議した。
【解決策の候補】
解決策A：
ITベンダーの実現可能な範囲に計画を立てる。
解決策B：
要件定義の取り纏めをITベンダーが支援し、リリース日を変えないようにスケジューリングする。
解決策C：
プロジェクトを中断して、体制を含め計画を見直しをする。
調査の結果から、スケジュールの遅延をリカバリー出来るのであれば、コスト増加もやむを得ないと判断していたことが分かっている。
その状況をプロジェクトオーナーの山田へ説明し、山田の意向を踏まえ解決策を決定した。
【採用した解決策と採用の根拠】
【解決策の実行に伴うダメージ】
山田の意向は、 要件定義の取り纏めをITベンダーが支援し、リリース日を変えないようにスケジューリングすることに問題はないとの見解であった。
しかし、プロジェクトの中断は避けて欲しいとの要望があり、『解決策B』を採用した
【解決策の実行に伴うダメージ】
また、今回の解決策を実施したことで、クライアントにクライアント側の体制へITベンダーのメンバーをアサインすることによるコストが10%超過した。
今回の問題における原因は、ITプロジェクト経験者のアサインが困難だったということである。
今後、このような事態を避けるために、以下を教訓とした。
【教訓】
(1)クライアントが開発工程で実行する作業と作業を行うために必要となるスキルや経験の説明をする
STEP4：リスク管理表の作成
最後に、今回プロジェクトで起こった問題を課題問題整理表に記述し、今後のプロジェクトの教訓として役立てるためにリスク管理表に記述した。
今後の貴方のプロジェクト活動の参考になれば幸いです。
