お疲れ様です、ゆーろー@常駐しないPMOです。

わたしがプロコンサルとして参加しているiPM naviのコラムをご紹介します。

今回のコラムは大手コンサルファームで活躍している”えのき”さんが、実際にPMアドバイザーで参画した炎上プロジェクトの実例となります。

こんにちは、プロコンサルのOSAMUです。

私が参加しているiPMでは、PM初心者のスキルアップやDX時代に適応したいPMのリスキリングのサポートとして、iPM TRAININGを運営しています。

その中のオプションサービスとして、『トラブルプロジェクトの実例から学ぶ失敗しないマネジメント』をお伝えしています。

このコラムでは、読者のあなたへ、実際に私がPMアドバイザーとして参画し解決した、トラブルプロジェクトの実例を紹介します。

今回は、『テスト計画のミスでスケジュール遅延』というテーマです。

あなたのマネジメント業務で活用できるように、解決までのアプロローチを以下の順番でお伝えします。

・プロジェクトの状況

・問題の設定

・原因追求

・解決策

・教訓（リスク管理表へ整理）

もっとOSAMUさんのコラムを読みたい方はiPM naviへメンバー登録（無料）してください。登録は（こちら）

プロジェクトの状況

1.プロジェクトのスコープと体制

・顧客は大手エンターテーメント会社。

・顧客の情報システム部で新規構開発を実施。

・情報システム部の窓口は木村。

・プロジェクトオーナーは情報システム部の山田。

・システム化スコープはタレント管理、給与管理、営業管理。

・中堅SierのA社が開発ベンダーとして参画。

・A社は全開発工程の成果物の納品、システムリリースの責任を請け負う。

・A社の開発体制は業務チーム、基盤チーム、テストチーム、管理チームで構成。

・A社のPMは佐藤（初心者PM）

2.プロジェクト目標

品質目標：100%の不具合修正

スケジュール目標：予定通りのリリース

コスト目標：予算内でのシステム完成

3.プロジェクトの進捗状況

現在、プロジェクトは結テスト工程であり、所要期間の50%が経過した。

結合テスト計画のテスト数・作業工数・割当人数・所要期間を有識者のレビューで合格をもらったにも関わらず、大幅に進捗が遅延した。

そのため、顧客の情報システム部 木村にリリース延期を依頼した。

しかし、木村から

「計画が正しいにも関わらず遅延の原因が分からない。」

「そんな状況で、リリースの延期は認められない。」

「当初の計画通り進めて欲しい。」

と一蹴された。

佐藤は状況を把握しているが、具体的な問題や解決策が分からない状態である。

**守秘義務により企業名・団体名・個人名等は架空名称となります。

問題の設定

*私がアドバイザーとして、プロジェクトに参画して解決させた経緯のスタートです。

問題を考える場合は、どのマネジメント領域で発生したかを分類することで、後続のアプローチがスムーズに行え、得られた結果の根拠も説得力を持つ。

そこで、今回の問題は、プロジェクトで起きた事象を、様々なプロジェクト情報から考えをもとに考たところ『スケジュールマネージメント領域』で発生した問題として取り扱った。

また、今回のプロジェクトの問題をこのように設定した。

”テスト項目ごとの実行計画のミスによるスケジュール遅延”

また、この問題を放置することで、スケジュール目標であるリリース日を逸脱する恐れがあった。

原因の追求

原因を特定するためには関係者へのヒアリングが重要である。

しかし、闇雲に関係者から聞き取りを行っても時間の無駄であることから原因の仮説を3つ立てた。

1.原因の仮説と検証

2.今回の問題の原因

テスト難易度の設定が間違っていた

と判明した。

また、テストの難易度がテスト実施日数に影響することを知らず、テスト項目を同じ分量で担当者へ割り振っていたことが分かった。

解決策

わたしは3つの解決策を準備した。

解決策A
テスト難易度を設定せず新規メンバーを投入してテストを続行する。

解決策B
テスト難易度を設定して、一人当たりの分量を見直す。

解決策C
テスト難易度を設定して、一人当たりの分量を見直す。その上でスケジィールを延期する。

現在のプロジェクトの状況とこの解決策の案をPO山田へ提言した。

PO山田は、このような意向があった。

⚫︎ 品質について
テスト難易度を設定して、一人当たりの分量を見直すことに問題なし。

⚫︎ リリース日について
リリース日の延期はできない。

このことから、解決策Bを採用した。

また、この解決策を施行することで、開発ベンダーA社はテストの難易度を設定する工数が必要となり、計画工数を30%超過することになった。

教訓（リスク管理表へ整理）

今回の原因は、テストの難易度の設定が間違っていた（または、行なっていない）ということであった。

このような事態を、事前に回避することはできる。

それは、プロジェクト計画の段階でこれらを実施することで防止できるのである。

・結合テスト計画として、テストの難易度が設定されていることを方針として盛り込む。

・結合テストでテストの難易度から、実施日数を検討して最適なスケジュールをする。

今回のトラブルプロジェクトをリスク管理表に整理したので、あなたのマネジメント業務で活用して頂ければ幸いである。

なぜ、プロジェクトが破綻したのか？

今回、プロジェクトが破綻したのは、PM経験が少ないことによるプロジェクト計画の策定を失敗したからです。

PM経験が浅い方は、プロジェクト計画で何を考えれば良いかが曖昧になっているケースがあります。

プロジェクト計画で、重要なのはプロジェクトを成功させるための要素を認識していなくはなりません。

破綻するプロジェクトは、3つの要素に対して、これらのことが出来ていないからです。

・どれか一つが漏れてしまった。

・間違った手順で作ってしまった。

・正しいメソッドやノウハウを使えなかった。

そのため、PMはプロジェクト計画を立てる時に、以下を意識してください。

1.構成を順番通りに、

2.正しい手順で、

3.メソッドやノウハウを使って、

4.「プロジェクト計画書」に、まとめる。

もし、あなたがこれらを意識していけど、

「勉強したいけど、何から手をつけていいか分からない」

「今の勉強方法が実践で使えるか自信が持てない」

「体系的にプロジェクトマネジメントを学び体験したい」

このように感じているなら、iPM TRAININGにチャレンジしてください。

あなたのプロジェクト計画書を作るスキルUPをサポートするサービスです

最後まで、読んでいただき有難う御座いました。