そこで本コラムでは、iPM naviに参加している大手コンサルファームの社員・出身者が、実際にPMアドバイザーで参画した破綻プロジェクトを立て直した実例を紹介します。

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

わたしがプロコンサルとして参加しているiPM naviの”MIRIO”さんが、実際にPMアドバイザーで参画したプロジェクトとなります。

それではご覧ください♪

from MIRIO's column

このmanagement lessonは、多くのプロジェクトマネージャが身に覚えがあると思います。

プロジェクトが破綻する根本的な原因は計画のミスです。

このコラムで紹介する破綻プロジェクトは計画段階で、PMが必要なスキルを持っていなかったことで起こった実例です。

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

今回は、『スケジュール破綻！リリースできない...』というテーマです。

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

・プロジェクトの状況

・問題の設定

・原因追求

・解決策

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

プロジェクトの状況

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

・顧客は大手ファイナンス会社。

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

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

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

・システム化スコープは商品管理、資産管理、顧客管理。

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

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

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

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

2.プロジェクト目標

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

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

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

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

現在、プロジェクトは要件定義工程であり、最終日であった。

想定よりも要件のボリュームが多いためスケジュールの延期を顧客の情報システム部 木村に依頼した。

しかし、木村から

「事情は分かった。」

「しかし、当初の計画通り進めてほしい。」

と一蹴された。

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

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

問題の設定

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

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

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

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

”クライアント要求を予定通りにリリースできない”

この問題を放置することで、品質目標である要望達成率100%を逸脱する恐れがあった。

原因の追求

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

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

1.原因の仮説と検証

2.今回の問題の原因

計画した作業スケジュールが間違っていた と判明した。

また、PMはスケジュールの見積もり方法を知らず、直感を頼りに見積もりを行ったことが分かった。

解決策

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

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

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

解決策C
クライアントの要望に応えるため、増員してスケジュールを延ばす。

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

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

⚫︎ スコープについて ビジネスインパクトの強い機能を優先して段階的にリリースすることに問題はなし。

⚫︎ スケジュールについて スケジュールの延期はできない。

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

また、この解決策を施行することで、スケジュールが30%超過することになった。

*但し、ビジネスインパクトの強い要件は計画していたリリース日にサービスインした。

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

今回の原因は、計画した作業スケジュールが間違っていたということであった。

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

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

・作業工数、スケジュールの見積もりは有識者を含めて行う。

・要件定義が終了した時に、作業工数、スケジュールの調整を行えるようにルール化する。

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

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

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

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

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

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

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

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

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

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

1.構成を順番通りに、

2.正しい手順で、

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

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

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

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

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

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

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

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

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

アンケートのお願い