スコープの合意なしにプロジェクトを進行して破綻...
・PMを目指している。
・PM初心者でも失敗しないプロジェクト管理をやりたい。
・破綻プロジェクトからマネジメントを学びたい。
・プロジェクトの実例からリスク情報を集めたい。
そこで本コラムでは、iPM naviに参加している大手コンサルファームの社員・出身者が、実際にPMアドバイザーで参画した破綻プロジェクトを立て直した実例を紹介します
お疲れ様です、ゆーろー@常駐しないPMOです。
わたしがプロコンサルとして参加しているiPM naviの”OSAMU”さんが、実際にPMアドバイザーで参画したプロジェクトとなります。
それではご覧ください♪
from OSAMU's column
プロジェクト計画ではスコープを明確にしていきます。
しかしスコープの確定条件と確定日の応用行わないPMがいます。
そうすると、要件通りのシステムが完成できずプロジェクトが破綻するケースがあります。
何故、このようなトラブルが起こるのでしょうか？
それは、「スコープの確定条件の取り決め」に不備があるからです。
このmanagement lessonは、多くのプロジェクトマネージャが身に覚えがあると思います。
プロジェクトが破綻する根本的な原因は計画のミスです。
このコラムで紹介する破綻プロジェクトは計画段階で、PMが必要なスキルを持っていなかったことで起こった実例です。
こんにちは、プロコンサルのOSAMUです。
今回は、『スコープの合意なしにプロジェクトを進行して破綻...』というテーマです。
あなたのマネジメント業務で活用できるように、解決までのアプロローチを以下の順番でお伝えします。
・プロジェクトの状況
・問題の設定
・原因追求
・解決策
・教訓（リスク管理表へ整理）
👍 今回のコラム
むずかしさ ：
★★☆☆☆（PM初級者向け）
気付き学び ：
★★★★★(スコープの確定日程・条件のミスによるリスク)
お役立ち ：
★★★★★(スコープ管理)
プロジェクトの状況
1.プロジェクトのスコープと体制
・顧客は大手鉄鋼会社。
・顧客の情報システム部で新規構開発を実施。
・情報システム部の窓口は木村。
・プロジェクトオーナーは情報システム部の山田。
・システム化スコープは商品管理、資産管理、顧客管理。
・中堅SierのA社が開発ベンダーとして参画。
・A社は全開発工程の成果物の納品、システムリリースの責任を請け負う。
・A社の開発体制は業務チーム、基盤チーム、テストチーム、管理チームで構成。
・A社のPMは佐藤（初心者PM）
2.プロジェクト目標
品質目標：100%の不具合修正
スケジュール目標：予定通りのリリース
コスト目標：予算内でのシステム完成
3.プロジェクトの進捗状況
現在、プロジェクトは結合テスト工程であり、3日間（10%消化）が経過した。
木村から
「一部の要件が確定していないという課題が未解決である。」
「この状態で、要望通りにシステムは完成できるのか！」
と厳しい指摘があった。
佐藤は状況を把握しているが、具体的な問題や解決策が分からない状態である。
**守秘義務により企業名・団体名・個人名等は架空名称となります。
問題の設定
*私がアドバイザーとして、プロジェクトに参画して解決させた経緯のスタートです。
問題を考える場合は、どのマネジメント領域で発生したかを分類することで、後続のアプローチがスムーズに行え、得られた結果の根拠も説得力を持つ。
そこで、今回の問題は、プロジェクトで起きた事象を、様々なプロジェクト情報から考えをもとに考たところ『スコープマネジメント領域』で発生した問題として取り扱った。
また、今回のプロジェクトの問題をこのように設定した。
”スコープの合意なしにプロジェクトを進行させている”
この問題を放置することで、スケジュール目標であるリリース日を逸脱する恐れがあった。
様々なプロジェクト情報
プロジェクト計画書、レービュー結果報告書、要求変更書、レビュー対象物、作業実績情報、作業範囲記述書、要件定義書、成果物一覧、課題問題整理表、役割分担表、要員の選定根拠、勤務表、成果物、関係者からのヒアリング結果
原因の追求
原因を特定するためには関係者へのヒアリングが重要である。
しかし、闇雲に関係者から聞き取りを行っても時間の無駄であることから原因の仮説を3つ立てた。
1.原因の仮説と検証
仮説1
仕様に関する不明ていがQA管理されていなかった。
【仮説の検証】
OA管理表で解答未記入はあったか？
【検証結果】
全て解答済みで解決していた。
仮説2
設計書の未修正があった。
【仮説の検証】
設計書の変更履歴が正確に更新されていなかった？
【検証結果】
全ての正しく更新されていた。
仮説3
スコープの確定日程と確定条件の取り決めがなかった。
【仮説の検証】
プロジェクト計画書に「スコープ確定の条件等」が整理され記載されていなかった？
【検証結果】
プロジェクトスコープの記載はあったが、確定条件等は見当たらなかった。
2.今回の問題の原因
スコープの確定日程と確定条件の取り決めがなかった と判明した。
また、PMはスケジュールの見積もり方法を知らず、直感を頼りに見積もりを行ったことが分かった。
解決策
わたしは3つの解決策を準備した。
解決策A
要件が確定している範囲のみをスコープ対象とする。
解決策B
要件定義のゴールを設定し、クリティカル部分のみ要件を再定義する。
解決策C
要件定義のゴールを設定し、全ての要件を再定義する。
現在のプロジェクトの状況とこの解決策の案をPO山田へ提言した。
PO山田は、このような意向があった。
⚫︎ スコープについて
クリティカル部分のみ要件を再定義することに問題はない。
⚫︎ スケジュールについて
スケジュールの延期はできない。
このことから、解決策Bを採用した。
また、この解決策を施行することで、SIerは要件定義に対する工数が30%超過することになった。
教訓（リスク管理表へ整理）
今回の原因は、スコープの確定日程と確定条件の取り決めがされていないということであった。
このような事態を、事前に回避することはできる。
それは、プロジェクト計画の段階でこれらを実施することで防止できるのである。
・スコープ確定のスケジュールと条件を決める。
・スコープ確定となる条件成立をマイルストーンとする。
今回のトラブルプロジェクトをリスク管理表に整理したので、あなたのマネジメント業務で活用して頂ければ幸いである。
なぜ、プロジェクトが破綻したのか？
今回、プロジェクトが破綻したのは、PM経験が少ないことによるプロジェクト計画の策定を失敗したからです❗️
PM経験が浅い方は、プロジェクト計画で何を考えれば良いかが曖昧になっているケースがあります。
プロジェクト計画で、重要なのはプロジェクトを成功させるための要素を認識していなくはなりません。
プロジェクト計画を構成するは3つの要素
WHY：
なぜプロジェクトを行うのか。
WHAT：
どのような作業を行なって、どんな成果物を作るのか。
HOW：
どんな成功に導くための手段や方法を用意するのか。
破綻するプロジェクトは、3つの要素に対して、これらのことが出来ていないからです。
・どれか一つが漏れてしまった。
・間違った手順で作ってしまった。
・正しいメソッドやノウハウを使えなかった。
そのため、PMはプロジェクト計画を立てる時に、以下を意識してください。
1.構成を順番通りに、
2.正しい手順で、
3.メソッドやノウハウを使って、
4.「プロジェクト計画書」に、まとめる。
もし、あなたがこれらを意識していけど、
「勉強したいけど、何から手をつけていいか分からない」
「今の勉強方法が実践で使えるか自信が持てない」
「体系的にプロジェクトマネジメントを学び体験したい」
このように感じているなら、iPM TRAININGにチャレンジしてください。
あなたのプロジェクト計画書を作るスキルUPをサポートするサービスです❗️
最後まで、読んでいただき有難う御座いました。
お忙しい中、読んで頂き有難うございます。サポートは、今後のPM育成を充実させる活動と他のクリエイターへ還元していきたい考えています🙇♂️