writing by えのき *このコラムはiPM naviで配信しています 計画コストを超過するプロジェクトは、『赤字プロジェクト』です。 考えられる原因はこのようなことです。 ①追加仕様 ②スキル不足 ③見積もりミス ④リスク工数の見積もりミス 要件定義工程で、コストオーバーを経験されたPMが多いこと... それはなぜか？ RFPでは予想できなかった業務・システム機能仕様が明確になるからです。 意外に、このことを知らないPMが多いってご存知でしょうか？
監修：Osamu Hirayamaのキャリア 2001年に大手コンサルファームBにジョイン。ITコンサルタントとして複数のシステム開発プロジェクトのPM・PMOに従事。 2016年よりSIerの取締役として、BtoC向けスマートフォンアプリ開発サービスのビジネススケールに貢献。 2019年にITコンサルファームを設立。大手金融会社の新規事業のIT担当として、脳機能を定期的に測定することにより、認知機能の変化を把握するシステムの開発を担当し自社ビジネスを拡大。
こんにちは、プロコンサルのえのきです。 私が参加しているiPMでは、PM初心者のスキルアップやDX時代に適応したいPMのリスキリングのサポートとして、iPM TRAININGを運営しています。 その中のオプションサービスとして、『トラブルプロジェクトの実例から学ぶ失敗しないマネジメント』をお伝えしています。 このコラムでは、読者のあなたへ、実際に私がPMアドバイザーとして参画し解決した、トラブルプロジェクトの実例を紹介します。 今回は、『コスト増加の原因に要件の明確化があるって知ってましたか？』というテーマです。 あなたのマネジメント業務で活用できるように、解決までのアプロローチを以下の順番でお伝えします。 ・プロジェクトの状況 ・問題の設定 ・原因追求 ・解決策 ・教訓（リスク管理表へ整理）
目次
・プロジェクトの状況 ・問題の設定 ・原因の追求 ・解決策 ・教訓（リスク管理表へ整理）
プロジェクトの状況
1.プロジェクトのスコープと体制 ・顧客は大手半導体メーカー。 ・顧客の情報システム部で新規構開発を実施。 ・情報システム部の窓口は木村。 ・プロジェクトオーナーは情報システム部の山田。 ・システム化スコープは製造管理、物流管理、倉庫管理。 ・中堅SierのA社が開発ベンダーとして参画。 ・A社は全開発工程の成果物の納品、システムリリースの責任を請け負う。 ・A社の開発体制は業務チーム・基盤チーム・テストチーム・管理チームで構成。 ・A社のPMは佐藤（初心者PM） 2.プロジェクト目標 品質目標：100%の不具合修正 スケジュール目標：予定通りのリリース コスト目標：予算内でのシステム完成 3.プロジェクトの進捗状況 現在、プロジェクトは要件定義工程である。 要件定義工程の最終日に要件が明確になった結果、RFPでは予想できなかった多くの機能が必要となった。 そのことから、A社のPM佐藤がコストの追加を要求したが、顧客の情報システム部 木村から「我々は要件を追加していない。当初の計画通り進めてほしい」と一蹴された。 しかし、佐藤は状況を把握しているが、具体的な問題や解決策が分からない状態である。 **守秘義務により企業名・団体名・個人名等は架空名称となります。
問題の設定
*私がアドバイザーとして、プロジェクトに参画して解決させた経緯のスタートです。 問題を考える場合は、どのマネジメント領域で発生したかを分類することで、後続のアプローチがスムーズに行え、得られた結果の根拠も説得力を持つ。 そこで、今回の問題は、プロジェクトで起きた事象を、様々なプロジェクト情報から考えをもとに考たところ『コストマネージメント領域』で発生した問題として取り扱った。 また、今回のプロジェクトの問題をこのように設定した。 ”要件が明確になったことによりコスト増加” また、この問題を放置することで、コスト目標を大きく逸脱する恐れがあった。
様々なプロジェクト情報とは
プロジェクト計画書、レービュー結果報告書、要求変更書、レビュー対象物、作業実績情報、作業範囲記述書、要件定義書、成果物一覧、課題問題整理表、役割分担表、要員の選定根拠、勤務表、成果物、関係者からのヒアリング結果
原因の追求
原因を特定するためには関係者へのヒアリングが重要である。 しかし、闇雲に関係者から聞き取りを行っても時間の無駄であることから原因の仮説を3つ立てた。 1.原因の仮説と検証 仮説1 要件追加に伴うコストの見直しルールがない
仮説の検証
プロジェクト計画書にコスト見直しルールの記載があったか？ 【 検証結果 】 コスト見直しのルールが明記されており顧客とも合意済み
仮説2 RFPに記載されていない要件が追加された
仮説の検証
追加された仕様が議事録やメールなどに残されているか？ 【 検証結果 】 プロジェクトで指定された共有サーバの指定フォルダーに残されていた
仮説3 コストインパクの大きい要件を把握していなかった
仮説の検証
課題管理表にコストインパクトの大きい要件が記録されていたか？ 【 検証結果 】 記録されていなかった
2.今回の問題の原因 コストインパクの大きい要件を把握していなかった と判明した。 また、不測の際のリスクバッファー構成も間違っていた。
解決策
わたしは3つの解決策を準備しました。 解決策A コストを肥大化させた機能を含めて再度見積もりを行う。 解決策B コストを肥大化させた機能は、基本機能のみをスコープ対象とする。 解決策C コストを肥大化させた機能は、基本機能のみをスコープ対象として、新たに追加費用を請求する。 現在のプロジェクトの状況とこの解決策の案をPO山田へ提言した。 PO山田は、このような意向があった。 ⚫︎ スコープについて コストを肥大化させた機能の中でプロジェクトの目的を達成させるために必要となる基本機能をスコープ対象とする。 ⚫︎ リリース日について リリース日の延期はできない。 このことから、解決策Bを採用した。 また、この解決策を施行することで、開発ベンダーA社は人員の増加が必要となり、計画工数を30%超過することになった。
教訓（リスク管理表へ整理）
今回の原因は、コストインパクトの大きい要件を把握していないということであった。 このような事態を、事前に回避することはできる。 それは、プロジェクト計画の段階でこれらを実施することで防止できるのである。 ・RFPに記載されていない必要な機能を予測する。 ・予測した機能を顧客に提言し、スケジュールとコストを協議する。 ・要件定義工程でコストインパクトのある要件が発生した段階で顧客と協議する。 今回のトラブルプロジェクトをリスク管理表に整理したので、あなたのマネジメント業務で活用して頂ければ幸いである。
最後まで、読んでいただき有難う御座いました。
プロコンサル えのきさんのコラムを、もっと読むにはiPM naviメンバーサイトへログインして下さい。 アカウントをお持ちでない方は、画像をタッチして無料メンバーに登録して下さい