『トラブル時でも作業ループさせない』PMなら押さえておけば失敗なし!
ピンチの時に後続工程を同時進行することはリスクが高い施策です。
✅緊急時に作業の難易度の精査、作業の組み替えが苦手な方
✅PJリスクを集めているPMやPMO
✅プロマネ初心者を抱える管理者
にお伝えしたいプロジェクトリスクの情報です。
この場合、更なるスケジュールの遅延や品質劣化を起こすことがあります。
まずは、一旦冷静になって作業の難易度を精査して、作業の組み替えを考えてから実行に移しましょう。
意外にも、このことを知らないPMが多いって、ご存知でしょうか?
■今回のテーマ
プロジェクト計画における『工数の算出』の検討の中で、『作業の割当人数を間違った』ことにより、『プロジェクトが停滞した』という問題が起こりました。
この問題を取り上げて、原因の追求、解決策、リスク対策を解説していきます。
※プロジェクト検証の結果をお伝えするにあたり、架空の企業である「株式会社XYZ」での出来事として紹介します。
prologue
【プロジェクト状況】
現在のプロジェクトは、製造・単体テスト工程である。 当該工程が所要期間の50%を消化した時点で、スケジュール遅延していた。
そのため、リカバリー策として詳細設計と製造を同時に行っていた結果、中途半端な設計品質であり、製造してテストを行っても品質基準を上回ることが出来きない。
製造と設計を無駄に繰り返すループ状態に陥った。
このままでは、リリース日に間に合わない。
そこで、プロマネ初心者の佐藤は『スコープの縮小』を依頼した。
しかし、クライアント窓口の木村の回答は『我々は、要件を追加していない。また、工数もスケジュールも貴社の提案で進めているプロジェクトである。当初の計画通り進めて欲しい。』と要望された。
プロマネの佐藤は、状況の把握をしていますが、具体的な問題が分からず打つ手もなかった。
そこで、PMOの私へサポートを求めてきた。
(以降のSTEP1-STEP4はPMOが実施した)
STEP1:問題の設定
そして、『製造作業のループによるスケジュール遅延』、このように問題を設定した。
STEP2:原因の究明
この問題は、スケジュール目標であるリリース日している。
そこでPMOの私は、原因の仮説を立て検証を行った。
【原因の仮説】
(1)プロジェクト計画の承認以降に仕様追加がある
(2)プロジェクト全体のスケジュールと工数が間違っている
(3)スケジュールと工数から見た割り当て人数が間違っている
そして、仮説に対して調査を行い検証した。
【仮説の検証】
(仮説1)プロジェクト計画の承認以降に仕様追加がある
▷追加された仕様が議事録、メールなどに記録されていなかったか?
➡︎YES
(仮説2)プロジェクト全体のスケジュールと工数が間違っている
▷有識者の算出した工数と所要期間も計画と同じであったか?
➡︎YES
(仮説3)スケジュールと工数から見た割り当て人数が間違っている
▷有識者の算出した割り当て人数も計画と同じであったか?
➡︎NO
問題の根本的な原因は、『仮説3』と判明した。
また、プロマネ初心者の佐藤は、正確に必要とされる作業工数を求めていたが、割り当て人数を30%程度少なくして算出していたことが分かった。
STEP3:解決策
この問題を放置することは、デスマーチプロジェクトの危険があるため、PMOの私は解決策を3つ考え、プロジェクトオーナーの山田と協議した。
【解決策の候補】解決策A:
プロジェクトを一旦中断して、体制を再構築する。
解決策B:
詳細設計、製造工程は、増員してクリティカルパスに関係のある機能に注力する。そして、クリティカルパスに関係ない機能は、作業開始タイミングを遅らせる。
解決策C:
リリースを延期、もしくはスコープを縮小する。
調査の結果から、正確に必要とされる作業工数を求めていたが、割り当て人数を30%程度少なくして算出していたことが分かっている。
その状況をプロジェクトオーナーの山田へ説明し、山田の意向を踏まえ解決策を決定した。
【採用した解決策と採用の根拠】
山田の意向は、クリティカルパスに関係ない機能は、作業開始タイミングを遅らせることに問題はないが、予算の追加は避けて欲しいとの要望があり、『解決策B』を採用した。
【解決策の実行に伴うダメージ】
また、今回の解決策を実施したことで、ITベンダーにクリティカルパスに関係のある機能に対して作業するメンバーの投入による工数が30%超過した。
今回の問題における原因は、スケジュールと工数から見た割り当て人数が間違ってたということである。
今後、このような事態を避けるために、以下を教訓とした。
【教訓】
(1)詳細設計の終盤で後続の工程に対して作業工数、作業期間、割り当て人数の計画を有識者を含めて行う。
(2)詳細設計の終盤で製造作業の難易度を精査して、作業の組み替えを行う。
STEP4:リスク管理表の作成
最後に、今回プロジェクトで起こった問題を課題問題整理表に記述し、今後のプロジェクトの教訓として役立てるためにリスク管理表に記述した。
このリスク管理表は、ITベンダーのプロジェクト情報として保管され、他チームへの情報共有として利用することになった。
最後まで、読んで頂き有難うございました。
今後の貴方のプロジェクト活動の参考になれば幸いです。
このトラブルプロジェクトは私が対応しました!