リスクを考えたの？だからプロジェクトが止まったんだよ！
・PMを目指している。
・PM初心者でも失敗しないプロジェクト管理をやりたい。
・破綻プロジェクトからマネジメントを学びたい。
・プロジェクトの実例からリスク情報を集めたい。
そこで本コラムでは、iPM naviに参加している大手コンサルファームの社員・出身者が、実際にPMアドバイザーで参画した破綻プロジェクトを立て直した実例を紹介します。
お疲れ様です、ゆーろー@常駐しないPMOです。
わたしがプロコンサルとして参加しているiPM naviのMIRIOさんが、実際にPMアドバイザーで参画したプロジェクトとなります。
それではご覧ください♪
プロジェクト計画は予め作業工数を算出して万全に備えます。
完璧にしたつもりでも、プロジェクトは予期せぬ出来事の連続です。
予期しない事象は回避しなければなりませんが、計画段階での予防はできないものです。
そのためには何をすれば良いのか？ 作業工数に『リスク回避工数』を盛り込んでおきましょう。
リスク回避工数は、過去のプロジェクトで起こった問題事象とそれに関わった工数のデータを持っていれば推計できます。
意外にも、これをやっていないPMが多いってご存知でしょうか？
from MIRIO's column
この教訓は、多くのプロジェクトマネージャが身に覚えがあると思います。
プロジェクトが破綻する根本的な原因は計画のミスです。
このコラムで紹介する破綻プロジェクトは計画段階で、PMが必要なスキルを持っていなかったことで起こった実例です。
こんにちは、プロコンサルのMASAです。
今回は、『リスクを考えたの？だからプロジェクトが止まったんだよ！』というテーマです。
あなたのマネジメント業務で活用できるように、解決までのアプロローチを以下の順番でお伝えします。
・プロジェクトの状況
・問題の設定
・原因追求
・解決策
・教訓（リスク管理表へ整理）
👍 今回のコラム
むずかしさ ：
★★☆☆☆（PM初級者向け）
気付き学び ：
★★★★★(リスク回避工数の見積もりミスによるリスク)
お役立ち ：
★★★★★(工数の算出)
リスク発生率：
★★★★★（非常に高い）
プロジェクトの状況
1.プロジェクトのスコープと体制
・顧客は大手人材紹介会社。
・顧客の情報システム部で新規構開発を実施。
・情報システム部の窓口は木村。
・プロジェクトオーナーは情報システム部の山田。
・システム化スコープは商品管理、資産管理、顧客管理。
・中堅SierのA社が開発ベンダーとして参画。
・A社は全開発工程の成果物の納品、システムリリースの責任を請け負う。
・A社の開発体制は業務チーム、基盤チーム、テストチーム、管理チームで構成。
・A社のPMは佐藤（初心者PM）
2.プロジェクト目標
品質目標：100%の不具合修正
スケジュール目標：予定通りのリリース
コスト目標：予算内でのシステム完成
3.プロジェクトの進捗状況
現在、プロジェクトは製造・単体テスト工程であり、所要期間の50%が経過していた。
未確定の仕様が多く作業が滞った。
そこで、未確定部分をスコープ対象外にして欲しい旨を顧客の情報システム部 木村に依頼した。
しかし、木村から
「未確定部分をスコープから排除したらビジネスに悪影響が出る。」
「当初の予定通りにプロジェクトを進めてほしい。」
**守秘義務により企業名・団体名・個人名等は架空名称となります。
問題の設定
*私がアドバイザーとして、プロジェクトに参画して解決させた経緯のスタートです。
問題を考える場合は、どのマネジメント領域で発生したかを分類することで、後続のアプローチがスムーズに行え、得られた結果の根拠も説得力を持つ。
そこで、今回の問題は、プロジェクトで起きた事象を、様々なプロジェクト情報から考えをもとに考たところ『コストマネジメント領域』で発生した問題として取り扱った。
また、今回のプロジェクトの問題をこのように設定した。
”リスク回避の予測ができず作業が停滞する”
そして、この問題を放置することで、品質目標である要望達成率100%を逸脱とスケジュール目標であるリリース日を逸脱する恐れがあった。
様々なプロジェクト情報
プロジェクト計画書、レービュー結果報告書、要求変更書、レビュー対象物、作業実績情報、作業範囲記述書、要件定義書、成果物一覧、課題問題整理表、役割分担表、要員の選定根拠、勤務表、成果物、関係者からのヒアリング結果
原因の追求
原因を特定するためには関係者へのヒアリングが重要である。
しかし、闇雲に関係者から聞き取りを行っても時間の無駄であることから原因の仮説を3つ立てた。
1.原因の仮説と検証
仮説1
未確定に仕様を忘れてた。
【仮説の検証】
未確定の仕様に関して課題管理表に記載されていたか？
【検証結果】
抜け漏れなく記載されていた。
仮説2
計画した開発工数が間違っていた。
【仮説の検証】
有識者が算出した開発工数も計画と同じだったか？
【検証結果】
有識者が算出した工数と同等だった。
仮説3
リスク回避工数の見積もりが間違っていた。
【仮説の検証】
有識者が算出したリスク回避工数も計画と同じだったか？
【検証結果】
有識者が算出したリスク回避工数よりも大幅に少なかった。
2.今回の問題の原因
リスク回避工数の見積もりが間違っていた。
と判明した。
また、PMは開発工数を算出したもののリスク回避工数を付加せず作業工数として扱っていたことが分かった。
解決策
原因から、過去の類似トラブルプロジェクトの事例やクライアントのビジネスニーズを考慮し、わたしは3つの解決策を準備した。
解決策A
未確定の仕様をスコープ対象がとしてプロジェクトを進める。
解決策B
クリティカルパスに影響する未確定仕様を早急に決定し、プログラム製造を再開する。
解決策C
全ての要件を再確認してから、作業を再開しスケジュールを延期する。
そしてスケジュールを延期する
現在のプロジェクトの状況とこの解決策の案をPO山田へ提言した。
PO山田は、このような意向があった。
⚫ スコープについて
作業の組み替えを行い未確定仕様を決定する作業は問題ない。
⚫︎ スケジュールについて
スケジュールの延期はできない。
このことから、解決策Bを採用した。
また、この解決策を施行することで、顧客とSIerに未確定の仕様を決める作業による工数が30%超過することになった。
教訓（リスク管理表へ整理）
今回の原因は、リスク回避工数の見積もりを間違っていたということであった。
このような事態を、事前に回避することはできる。
それは、プロジェクト計画の段階でこれらを実施することで防止できるのである。
・作業工数の中にリスク回避工数を含める。
・リスク回避工数を正確に算出して有識者のレビューを受ける。
今回のトラブルプロジェクトをリスク管理表に整理したので、あなたのマネジメント業務で活用して頂ければ幸いである。
なぜ、プロジェクトが破綻したのか？
今回、主人公のPMはプロジェクトを成功させるためにマネジメントの学習をしてプロジェクトに臨みました。
しかしプロジェクトは破綻…
プロジェクトが終了してからPM へ
「どのような学習をしたのか？」
そんなインタビューをしました。
【学習方法】
・専門書籍を読破
・基本的なプロジェクト管理のセミナー参加
・インターネットでの情報収集
これらは間違った学習方法ではありません。
しかし、プロジェクトを失敗しました。
それは何故か？
学習方法を知らずにスキルUPに取り組みました。
使った学習教材が概念レベルの説明だけであり、実践的なPMになる材料がなかったからです。
【あなたはこんな悩みってありませんか？】
☑︎ 勉強したいけど、何から手を付けていいか分からない
☑︎ 今の勉強法が実践で使えるか自信が持てない
☑︎やる気と集中力が続かず、ついサボってしまう
☑︎ 頑張って勉強しているが、なかなか結果が出ない
そのお悩みは、私も参加しているiPM naviが解決してくれます。
大手コンサルファーム直伝！
PMになるためのあなたにピッタリな勉強方法がわかります。
しかも無料です!!
☑︎ 業務の中で学べる
今、あなたの業務には、プロジェクトを学ぶ材料がたくさんあります。
それを上手に使って、実践的なPMになる勉強方法があります。
☑︎休憩時間の8分だけ使えばOK
ランチしながら、スマホで情報を見てメモるだけ！
こんな簡単で時短で実践的なPMに近づける勉強方法があります。
詳しくはこちらをご覧ください↓
最後まで、読んでいただき有難う御座いました。
いいなと思ったら応援しよう！
