writing by えのき *このコラムはiPM naviで配信しています プロジェクト計画では、リスク管理計画を考えていきます。 しかし、正しくリスク管理を行わないPMがいます。 そうすると不具合が多かった時のリスクヘッジがされないでプロジェクトが破綻するケースがあります。 なぜ、このようなトラブルが起こるのでしょうか？ それはプロジェクト計画の段階で、計画と進捗のギャップに対するリスクの対処方法に不備があるからです。 今！あなたのプロジェクトが結合テストフェーズであれば、破綻する運命かを占う方法があります。 まずは、これらをチェックしてください。 ■これらをチェック 1.計画した結合テストの所要機関に含めたバッファー期間が間違っていた。 2.顧客とのコミュニケーションパスが存在しなかった。 3.リスク管理がされていなかった。
監修：Yuichiro Hayashiのキャリア 2000年に大手コンサルファームBにジョイン。
同社の創業時からパートナーとして、セールス・コンサルティングとあらゆる組織で活躍しビジネスの拡大に貢献。
2005年にコンサルファームを設立。
総数2,000以上のプロジェクトに携わり、経験したプロジェクトの検証と分析から『現場で使えるノウハウやリスク情報』を法人顧客やフリーランスPMOに提供。
2020年に大手クラウドソーシング 取締役としてジョイン。
大手コンサルファームBでのセールススキルを活かして同社スタートアップサービスの拡大に貢献
こんにちは、プロコンサルのえのきです。 私が参加しているiPMでは、PM初心者のスキルアップやDX時代に適応したいPMのリスキリングのサポートとして、iPM TRAININGを運営しています。 その中のオプションサービスとして、『トラブルプロジェクトの実例から学ぶ失敗しないマネジメント』をお伝えしています。 このコラムでは、読者のあなたへ、実際に私がPMアドバイザーとして参画し解決した、トラブルプロジェクトの実例を紹介します。 今回は、『そりゃ...リスクが解らなきゃ、止まっちゃいますよ!!』というテーマです。 あなたのマネジメント業務で活用できるように、解決までのアプローチを以下の順番でお伝えします。 ・プロジェクトの状況 ・問題の設定 ・原因追求 ・解決策 ・教訓（リスク管理表へ整理）
目次
・プロジェクトの状況 ・問題の設定 ・原因の追求 ・解決策 ・教訓（リスク管理表へ整理）
プロジェクトの状況
1.プロジェクトのスコープと体制
・顧客は大手半導体メーカー。
・顧客の情報システム部で新規構開発を実施。
・情報システム部の窓口は木村。
・プロジェクトオーナーは情報システム部の山田。
・システム化スコープは資材管理、配送管理、顧客管理。
・中堅SierのA社が開発ベンダーとして参画。
・A社は全開発工程の成果物の納品、システムリリースの責任を請け負う。
・A社の開発体制は業務チーム、基盤チーム、テストチーム、管理チームで構成。
・A社のPMは佐藤（初心者PM）
2.プロジェクト目標
品質目標：100%の不具合修正
スケジュール目標：予定通りのリリース
コスト目標：予算内でのシステム完成
3.プロジェクトの進捗状況
現在、プロジェクトは結合テスト工程であり、所要期間の10%が経過していた。
不具合が多発しリリース日に間に合わないことが判明した。
そこで、リスクを想定しプロジェクトの中断を顧客の情報システム部 木村に依頼した。
しかし、木村から
「今までリスクを共有されたことがない」
「本件がリスクなら最初に影響度を教えてほしい」 と一蹴された。 佐藤は状況を把握しているが、具体的な問題や解決策が分からない状態である。 **守秘義務により企業名・団体名・個人名等は架空名称となります。
問題の設定
*私がアドバイザーとして、プロジェクトに参画して解決させた経緯のスタートです。 問題を考える場合は、どのマネジメント領域で発生したかを分類することで、後続のアプローチがスムーズに行え、得られた結果の根拠も説得力を持つ。 そこで、今回の問題は、プロジェクトで起きた事象を、様々なプロジェクト情報から考えをもとに考たところ 『コミュニケーションマネジメント領域』 で発生した問題として取り扱った。 また、今回のプロジェクトの問題をこのように設定した。 ”リスク影響度がわからずプロジェクトが停滞する" そして、この問題を放置することで、スケジュール目標であるリリース日を逸脱する恐れがあった。
様々なプロジェクト情報とは
プロジェクト計画書、レービュー結果報告書、要求変更書、レビュー対象物、作業実績情報、作業範囲記述書、要件定義書、成果物一覧、課題問題整理表、役割分担表、要員の選定根拠、勤務表、成果物、関係者からのヒアリング結果
原因の追求
原因を特定するためには関係者へのヒアリングが重要である。 しかし、闇雲に関係者から聞き取りを行っても時間の無駄であることから原因の仮説を3つ立てた。 1.原因の仮説と検証 仮説1 計画した結合テストの所要機関に含めたバッファー期間が間違っていた。
仮説の検証
有識者の算出した結合テストのの所要機関に含めたバッファー期間も計画と同じだったか？ 【 検証結果 】 有識者が算出したバッファー期間は計画と同じだった。
仮説2 顧客とのコミュニケーションパスが存在しなかった。
仮説の検証
プロジェクト計画書にコミュニケーションルールの記載はあったか？ 【 検証結果 】 明確にコミュニケーションルールが記載されており顧客と合意していた。
仮説3 リスク管理がされていなかった。
仮説の検証
リスク管理表、議事録、メール等にリスク情報の記録や回避策が残されていたか？ 【 検証結果 】 全て口頭のやり取りで明文されていなかった。
2.今回の問題の原因
リスク管理がされていなかった。
と判明した。
また、PMは全くリスク管理を行わずメンバーからのアラートによってリスクであると把握していたが、影響度を理解していなかったことが分かった。
解決策
原因から、過去の類似トラブルプロジェクトの事例やクライアントのビジネスニーズを考慮し、わたしは3つの解決策を準備した。
解決策A
プロジェクトを中断して結合テスト以降のリスクを全てリスク管理表に整理する。
解決策B
結合テストの不具合がトリガーになるリスクを洗い出して影響度の高いリスクを回避する。
解決策C
結合テストの不具合がトリガーになるリスクを洗い出して影響度を決めてから結合テストを再開する。
現在のプロジェクトの状況とこの解決策の案をPO山田へ提言した。
PO山田は、このような意向があった。
⚫ 品質について
結合テストの不具合がトリガーになるリスクを洗い出して影響度の高いリスクを回避することに問題ない。
⚫︎ スケジュールについて
スケジュールの延期はできない。
このことから、解決策Bを採用した。
また、この解決策を施行することで、SIerにリスクの影響度の調査による工数が30%超過することになった。
教訓（リスク管理表へ整理）
今回の原因は、リスク管理がされていなかったということであった。 このような事態を、事前に回避することはできる。 それは、プロジェクト計画の段階でこれらを実施することで防止できるのである。 ・可能な限り全工程で起こり得るリスクをリスク管理表に記載する。 ・進捗確認のタイミングで計画と実績からリスクを測定しリスク管理表に記載するルールを設ける。 今回のトラブルプロジェクトをリスク管理表に整理したので、あなたのマネジメント業務で活用して頂ければ幸いである。
QAセッション
失敗プロジェクトの原因に関する質問に答えるQ&Aセッションを設けています。 皆さんの疑問や質問に対応することができます。 失敗プロジェクトに対する理解を深め、同じような失敗を回避するためのアドバイスをします。 iPM naviのサイトにアクセスしてコミュニティーに登録してください。 大手コンサルファームの社員や出身者が無料でアドバイスします。 ファームの人材とコミュニケーションが取れるイイ機会です。 是非、ご利用ください。 またコミュニティでは今回の失敗プロジェクトをプロジェクトの教訓としてリスク管理表にまとめました。 こちらも併せてチェックしてください!!
*メンバー登録（無料）する前にiPM naviでどんなことができるのか？を確認する。
最後まで読んでくれて有難う御座いました。
プロジェクトマネージャーを目指すなら必見！計画書の作り方を解説
プロジェクトマネージャーになるために欠かせないスキルの一つが、プロジェクト計画書の作成です。 しかし、初めて計画書を作成する人にとっては、何から手を付けていいか分からず苦戦することもあります。 そこで、プロジェクト計画書の作成手順を分かりやすく解説します。
Comments