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