スケジュールが遅れたら、まずは『正しい遅延日数を求めろ』PMなら絶対使って欲しいツール!
スケジュールがどのくらい遅れるのか正しく計算することで、リカバリー計画も作れます。
✅スケジュール遅延が起こると焦ってしまう方
✅PJリスクを集めているPMやPMO
✅プロマネ初心者を抱える管理者
にお伝えしたいプロジェクトリスクの情報です。
プロジェクト実行とは、形のないものを徐々に未来に向かった形あるものに作り上げていく作業です。
そのため、予期せぬ出来事がプロジェクトを停滞させることもあります。
特に、スケジュール進捗の遅れは、ベテランPMでも焦ってしまうものであり、リカバリー策を早急に考え実行しなければプロジェクトの失敗が待っています。
その時、リカバリー策を考える前に、必ず実施して欲しいのが『このままの状態が続けば、リリースは何日遅れるのだろうか?』という最悪のシナリオを想定してください。
そのシナリオ(最終的な遅延日数)を『EVM(Earned Value Management)』を使って求めることが大事です。
意外にも、このことを知らないPMが多いって、ご存知でしょうか?
■今回のテーマ
プロジェクト計画における『スケジュールマネジメント計画の作成』の検討の中で、『進捗データの収集から分析して将来を予測するツールを用意しなかった』ことにより、『リリースの超過日数が不明であり再計画できない』という問題が起こりました。
この問題を取り上げて、原因の追求、解決策、リスク対策を解説していきます。
※プロジェクト検証の結果をお伝えするにあたり、架空の企業である「株式会社XYZ」での出来事として紹介します。
prologue
【プロジェクト状況】
現在のプロジェクトは、総合テスト工程である。
当該工程の所要期間を50%消化した時点で、多くの不具合が発生したことから、プロマネ初心者の佐藤は、念のために『リリースを1週間延長して欲しい』と依頼した。
しかし、クライアント窓口の木村の回答は『正確な延長日数が分からなければ、社内で調整できない。当初の計画通り進めて欲しい』と要望された。
プロマネの佐藤は、状況の把握をしていますが、具体的な問題が分かっていない。
そのため、PMOの私へサポートを求めてきた。
(以降のSTEP1-STEP4はPMOが実施した)
STEP1:問題の設定
今回の問題は、プロジェクトで起きた事象を、様々なプロジェクト情報を元に考えたところ、『スケジュールマネジメントエリア』で起こっている問題として取り扱うことにした。
そして、『リリースの超過日数が不明であり再計画できない』、このように問題を設定した。
STEP2:原因の究明
この問題は、スケジュール目標であるリリース日を逸脱している。
そこでPMOの私は、原因の仮説を立て検証を行った。
【原因の仮説】
(1)計画した不具合件数が間違っている
(2)計画した総合テストの所要期間に含めたバッファー期間が間違っている
(3)現状から予測した遅延日数が間違っている
結果は、以下の通りとなった。
【仮説の検証】
(仮説1)計画した不具合件数が間違っている
▷有識者が算出した不具合件数も計画と同じであったか?
➡︎YES
(仮説2)計画した総合テストの所要期間に含めたバッファー期間が間違っている
▷有識者の算出した総合テストの所要期間に含めたバッファー期間も計画と同じであったか?
➡︎YES
(仮説3)現状から予測した遅延日数が間違っている▷有識者の計算した遅延日数と同じであったか?
➡︎NO
問題の根本的な原因は、『仮説3』と判明した。また、プロマネ初心者の佐藤は、現状から予測した遅延日数を算出する方法を知らなかった。そして、不具合の傾向を見ると軽微な修正であり、2日あれば対応が出来ることが分かった。
STEP3:解決策
この問題を放置することは、デスマーチプロジェクトの危険があるため、PMOの私は解決策を3つ考え、プロジェクトオーナーの山田と協議した。
【解決策の候補】解決策A:
2日分の作業を行うために、メンバーを増員してリリー日を延期する。
解決策B:
2日分の作業を残業によって対応しリカバリーする。
解決策C:
リリー日を2日間延期する。
調査の結果から、現状から予測した遅延日数が間違っていたが、不具合の傾向を見ると軽微な修正であり、2日あれば対応が出来ることが分かっている。
その状況をプロジェクトオーナーの山田へ説明し、山田の意向を踏まえ解決策を決定した。
【採用した解決策と採用の根拠】
山田の意向は、残業によるリカバリーに問題はないとの見解であった。
しかし、リリース日の延期は避けて欲しいとの要望があり、『解決策B』を採用した。
【解決策の実行に伴うダメージ】
また、今回の解決策を実施したことで、ITベンダーに残業でのリカバリー対応による工数が30%超過した。
今回の問題における原因は、現状から予測した遅延日数が間違っていたということである。
今後、このような事態を避けるために、以下を教訓とした。
【教訓】
(1)プロジェクト計画で遅延日数を算出する方法(ツール)を準備する。
(2)進捗確認のタイミングでスケジュール遅延が見られた時は、正確な遅れ日数を算出する。
STEP4:リスク管理表の作成
最後に、今回プロジェクトで起こった問題を課題問題整理表に記述し、今後のプロジェクトの教訓として役立てるためにリスク管理表に記述した。
このリスク管理表は、ITベンダーのプロジェクト情報として保管され、他チームへの情報共有として利用することになった。
最後まで、読んで頂き有難うございました。
今後の貴方のプロジェクト活動の参考になれば幸いです。
このトラブルプロジェクトは私が対応しました!
こちらのコラムシリーズもご覧ください♩
PM HACKERを読んでみる(こちら)