トラブルプロジェクトの教訓から学ぶ『スケジュールを見積もる』という重要性！

見積もったスケジュールの検証はどうするかを知らないと非論理的なプロジェクト計画となります。

f:id:yuro-1969:20200210094218p:plain

✅スケジュール見積もりに自信のない方
✅PJリスクを集めているPMやPMO
✅プロマネ初心者を抱える管理者

にお伝えしたいプロマネ情報です。

プロジェクト計画において、『スケジュールを見積もる』には、『作業ボリューム（作業工数）〕と『作業を完了させるための所要日数（スケジュール）』の親和性が非常に難しいものです。
例えば、プロマネ初心者の方であれば、知識よりも『経験』が足りないことから、どの程度のスケジュールを引いて良いのか迷うものです。
こんな時は、経験豊富な有識者のレビューを受けるのが得策です。
意外にも、このことを知らないPMが多いって、ご存知でしょうか？

■今回のテーマ

プロジェクト計画における『スケジュールの作成』の検討の中で、『スケジュール見積もりが間違っている』ことにより、『クライアント要求を予定通りリリースできない』という問題が起こりました。

この問題を取り上げて、原因の追求、解決策、リスク対策を解説していきます。

※プロジェクト検証の結果をお伝えするにあたり、架空の企業である「株式会社XYZ」での出来事として紹介します。

prologue

株式会社XYZは、市場シェアの拡大と業務コストの削減のために、新規プロジェクトを立ち上げることになりました。

プロジェクトの目的として、売上の10%増加と業務コストの20%削減を掲げています。目的を達成させるためには、個々の目標の設定が必要です。品質目標は、レスポンスタイム、受け入れ合格に数値目標を設定しました。

コスト目標は、開発費用を1800万円以内として、スケジュール目標は、リリース日を10月1日、主要なマイルストーンをユーザーテストによる品質判断としています。

また、プロジェクトの開始は、4月1日。開発期間を6ヶ月としました。

【プロジェクトの登場人物】

▷山田

株式会社XYZの事業部長であり、プロジェクトオーナー。

▷木村

株式会社XYZの社内調整役。クライアント窓口であり、ITベンダーとコミュニケーションを取る。

▷佐藤

このプロジェクトの開発を担当する株式会社ABCのプロジェクトマネージャーであり、今回初めてプロジェクトマネージメントを行うプロマネ初心者。

▷PMアドバイザー

The manager's Barに所属。プロマネ初心者の佐藤のマネジメントアドバイザー。

【プロジェクト状況】

現在のプロジェクトは、要件定義工程である。
要件定義の最終日に、プロマネの佐藤は、要件のボリュームが大きいことから『スケジュールの延期』を依頼した。
しかし、クライアント窓口の木村の回答は『事情は分かるが、我々も困る。当初の計画通り進めて欲しい』と要望された。
プロマネの佐藤は、状況の把握をしていますが、具体的な問題が分かっていない。
そのため、PMOの私へサポートを求めてきた。
（以降のSTEP1-STEP4はPMOが実施した）

STEP1：問題の設定
このトラブルプロジェクトは私が対応しました！

STEP1：問題の設定

今回の問題は、プロジェクトで起きた事象を、様々なプロジェクト情報を元に考えたところ、『スケジュールマネジメントエリア』で起こっている問題として取り扱うことにした。
そして、『クライアント要求を予定通りリリースできない』、このように問題を設定した。

f:id:yuro-1969:20200207161438p:plain

STEP2：原因の究明

この問題は、スケジュールであるリリース日を逸脱している。
そこでPMOの私は、原因の仮説を立て検証を行った。

【原因の仮説】
(1)要件定義工程において、トラブルにより作業遅延した

(2)要件定義工程において、当初よりも要件が増えている
(3)計画した作業スケジュールが間違っている

結果は、以下の通りとなった。

【仮説の検証】
(仮説1)要件定義工程において、トラブルにより作業遅延した
▷課題問題整理表に作業遅延に起因するトラブル事項の記載はなかったか？
➡︎YES

(仮説2)要件定義工程において、当初よりも要件が増えている
▷議事録、メール等に要件追加の事実が記載されていないかったか？
➡︎YES

(仮説3)計画した作業スケジュールが間違っている
▷有識者のスケジュールも計画と同じであったか？
➡︎NO

問題の根本的な原因は、『仮説3』と判明した。
また、プロマネ初心者の佐藤は、正確に必要とされる作業工数を求めていたが、スケジュールの見積もり方法を知らず、勘を頼りに見積もりを行ったことが分かった。

f:id:yuro-1969:20200207161817p:plain
STEP3：解決策

この問題を放置することは、デスマーチプロジェクトの危険があるため、PMOの私は解決策を３つ考え、プロジェクトオーナーの山田と協議した。

【解決策の候補】
解決策A：
クライアントの理解が得られなければプロジェクトを中止する。

解決策B：
ビジネスインパクトの強い機能を優先してリリースする（段階的なリリース）。

解決策C：
クライアントの要望に応えるため、要員を増やし開発期間を延ばす。

調査の結果から、スケジュールの見積もり方法を知らず、勘を頼りに見積もりを行ったことが分かっている。
その状況をプロジェクトオーナーの山田へ説明し、山田の意向を踏まえ解決策を決定した。

【採用した解決策と採用の根拠】
山田の意向は、段階的なリリースに問題はないとの見解であった。
しかし、ビジネスインパクトの強い範囲はを必ずリリース日に間に合わせて欲しいとの要望があり、『解決策B』を採用した。

【解決策の実行に伴うダメージ】
また、今回の解決策を実施したことで、クライアントとITベンダーに段階的なリリースによる3スケジュールが30遅延した。
今回の問題における原因は、計画した作業スケジュールが間違っていたということである。
今後、このような事態を避けるために、以下を教訓とした。

【教訓】
(1)プロジェクト計画で作業工数、スケジュールの見積もりは有識者を含めて行う。
(2)プロジェクト計画で要件定義終了段階で作業工数、スケジュールの調整を行えるようにルール化する。