既存資産の利用を間違えると一気にコスト超過の恐怖...
お疲れ様です、ゆーろー@常駐しないPMOです。
わたしがプロコンサルとして参加しているiPM naviのコラムをご紹介します。
今回のコラムは大手コンサルファームで活躍している”平山 理”さんが、実際にPMアドバイザーで参画した炎上プロジェクトの実例となります。
近頃のプロジェクトは、開発期間の短縮、予算の低減が強いられています。
PMとしては頭の痛い話です。 このとき、一つのアイデアとしては『既存資産の流用』です。
これは、プロジェクトのスケジュールやコストを最適にさせる効果があります。
しかし、流用可否を調査せずに感覚に頼って流用した時ほど、トラブルになるケースが非常に多いのです！
意外に、このことを知らないPMが多いってご存知でしょうか？
こんにちは、プロコンサルの平山 理です。
私が参加しているiPMでは、PM初心者のスキルアップやDX時代に適応したいPMのリスキリングのサポートとして、iPM TRAININGを運営しています。
その中のオプションサービスとして、『トラブルプロジェクトの実例から学ぶ失敗しないマネジメント』をお伝えしています。
このコラムでは、読者のあなたへ、実際に私がPMアドバイザーとして参画し解決した、トラブルプロジェクトの実例を紹介します。
今回は、『既存資産の利用を間違えると一気にコスト超過の恐怖...』というテーマです。
あなたのマネジメント業務で活用できるように、解決までのアプロローチを以下の順番でお伝えします。
・プロジェクトの状況
・問題の設定
・原因追求
・解決策
・教訓（リスク管理表へ整理）
👍 このコラムは
むずかしさ ：
★★☆☆☆（PM初級者向け）
ボリューム ：
★★★☆☆(5分-8分で読める)
気付き学び ：
★★★★★(既存資産の流用の留意事項)
お役立ち ：
★★★★★(コスト管理)
仕事の実用性：
★★☆☆☆（有識者のサポートが必要かな）
プロジェクトの状況
1.プロジェクトのスコープと体制
・顧客は大手ネットオークション会社。
・顧客の情報システム部で新規構開発を実施。
・情報システム部の窓口は木村。
・プロジェクトオーナーは情報システム部の山田。
・システム化スコープは経理管理、総務管理、人事管理。
・中堅SierのA社が開発ベンダーとして参画。
・A社は全開発工程の成果物の納品、システムリリースの責任を請け負う。
・A社の開発体制は業務チーム、基盤チーム、テストチーム、管理チームで構成。
・A社のPMは佐藤（初心者PM）
2.プロジェクト目標
品質目標：100%の不具合修正
スケジュール目標：予定通りのリリース
コスト目標：予算内でのシステム完成
3.プロジェクトの進捗状況
現在、プロジェクトは基本設計工程である。
基本設計工程の最終日に、A社は他顧客で同じようなプロジェクトを実施して、得られた成果を流用できると考え見積もりをしていた。
しかし、一部の業務処理に流用できないことが判明した。
リリース日を遅延させないようにするには、流用できなかった機能の設計を行う必要があった。
そのために、PM佐藤は顧客の木村に工数不足を補う追加の予算を依頼したが、
『予算は、既に合意していて追加できない。』
『当初の計画通り進めてほしい』
と一蹴された。
しかし、佐藤は状況を把握しているが、具体的な問題や解決策が分からない状態である。
**守秘義務により企業名・団体名・個人名等は架空名称となります。
問題の設定
*私がアドバイザーとして、プロジェクトに参画して解決させた経緯のスタートです。
問題を考える場合は、どのマネジメント領域で発生したかを分類することで、後続のアプローチがスムーズに行え、得られた結果の根拠も説得力を持つ。
そこで、今回の問題は、プロジェクトで起きた事象を、様々なプロジェクト情報から考えをもとに考たところ『コストマネージメント領域』で発生した問題として取り扱った。
また、今回のプロジェクトの問題をこのように設定した。
”既存資産の流用ができずコストーバー”
また、この問題を放置することで、コスト目標を大きく逸脱する恐れがあった。
様々なプロジェクト情報とは
プロジェクト計画書、レービュー結果報告書、要求変更書、レビュー対象物、作業実績情報、作業範囲記述書、要件定義書、成果物一覧、課題問題整理表、役割分担表、要員の選定根拠、勤務表、成果物、関係者からのヒアリング結果
原因の追求
原因を特定するためには関係者へのヒアリングが重要である。 しかし、闇雲に関係者から聞き取りを行っても時間の無駄であることから原因の仮説を3つ立てた。
1.原因の仮説と検証
仮説1
流用のための調査工数が不足していた。
【 仮説の検証 】
有識者の算出した調査工数も計画と同じだったか？
【 検証結果 】
有識者の算出した調査工数と同じであった。
仮説2
流用の調査を行うメンバーのスキルは不十分である。
【 仮説の検証 】
調査メンバーは類似案件の開発経験があったか？
【 検証結果 】
調査メンバは類似案件の経験者であり、且つベテランSEであった。
仮説3
流用を前提にしていたことから調査が不十分である。
【 仮説の検証 】
調査結果報告書が残されているか？
【 検証結果 】
調査メンバは類似案件の経験者であり、且つベテランSEであった。
2.今回の問題の原因
流用を前提にしていたことから調査が不十分であった。
と判明した。
また、流用する資産を把握せず、類似案件ということだけで流用可能と思い込み、メンバーへ曖昧な調査範囲を伝えていた。
解決策
わたしは3つの解決策を準備しました。
解決策A
一部の業務処理に合わせられるように、流用資産を無理やりカスタマイズする。
解決策B
流用できない一部の業務処理を断定して、改めて設計する。
解決策C
流用できない一部の業務処理を断定いて、改めて設計する。 また、基本設計の期間延長とリリース日の見直しを行う。
現在のプロジェクトの状況とこの解決策の案をPO山田へ提言した。
PO山田は、このような意向があった。
⚫︎ スケジュールについて 基本設計の期間を延長することに問題なし。
⚫︎ リリース日について リリース日の延期はできない。
このことから、解決策Bを採用した。
また、この解決策を施行することで、開発ベンダーA社は設計作業が追加になったことにより、計画工数を30%超過することになった。
教訓（リスク管理表へ整理）
今回の原因は、流用を前提にしていたことから調査が不十分ということであった。
このような事態を、事前に回避することはできる。
それは、プロジェクト計画の段階でこれらを実施することで防止できるのである。
・資産流用が適応できない場合は、顧客とコスト、スケジュールについて協議できることを合意しておく。
・流用部分の適用可能性について、事前に評価する工程を設け評価結果に応じた進め方を検討しておく。
今回のトラブルプロジェクトをリスク管理表に整理したので、あなたのマネジメント業務で活用して頂ければ幸いである。
♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪
＼ お知らせです ／
失敗しないプロジェクトの方法を学びませんか？
♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪♪
・プロジェクトで困ったことが起きた！
・どうやってマネジメントすればいいんだ！
・専門家に聞くにしても高いお金が必要！
・ネットで調べるのも時間が掛かる！
一般的なPM教材は概念ばかり…実践的な教材はないのか！
こんなことを感じてる方は、無料で利用できるプロジェクトマネジャのポータルサイトiPM naviをご利用ください。
iPM naviは、大手コンサルファームの社員・卒業生がプロコンサルとして、サポートする無料で利用できるプロジェクトマネージャのポータルサイトです。
ファームならではのノウハウやメソッドのコミックエッセイから専門家監修の基礎知識まで、幅広いコンテンツを配信しています。
また、業界初！お悩みワードを選ぶと解決ヒントになるコラムが検索できサービスも無料で使えます！
詳しくはiPM naviのサイトで確認してください。
サイトはこちら↓
最後まで読んでいただき有難う御座いました。
いいなと思ったら応援しよう！
