パフォーマンス設計のミスによるコスト超過

・PMを目指している。

・PM初心者でも失敗しないプロジェクト管理をやりたい。

・破綻プロジェクトからマネジメントを学びたい。

・プロジェクトの実例からリスク情報を集めたい。

そこで本コラムでは、iPM naviに参加している大手コンサルファームの社員・出身者が、実際にPMアドバイザーで参画した破綻プロジェクトを立て直した実例を紹介します

お疲れ様です、ゆーろー@常駐しないPMOです。

わたしがプロコンサルとして参加しているiPM naviの”えのき”さんが、実際にPMアドバイザーで参画したプロジェクトとなります。

それではご覧ください♪

もっと、えのきさんのコラムを読む時は画像をタッチ！ （iPM naviサイトで無料で読めます）

from えのき's column

プロジェクト計画では「品質基準」を検討しなくてはなりません。

しかし、ハードウェア選定を軽視するPMがいます。

そうすると、顧客要件の業務運用を快適に稼働させるシステムの性能（パフォーマンス）が出せず、プロジェクトが破綻するケースがあります。

何故、このようなトラブルが起こるのでしょうか？

それは、「品質を担保するためのスコープ」が間違っているからです。

management lesson

このmanagement lessonは、多くのプロジェクトマネージャが身に覚えがあると思います。

プロジェクトが破綻する根本的な原因は計画のミスです。

このコラムで紹介する破綻プロジェクトは計画段階で、PMが必要なスキルを持っていなかったことで起こった実例です。

こんにちは、プロコンサルのえのきです。

今回は、『パフォーマンス設計のミスによるコスト超過』というテーマです。

あなたのマネジメント業務で活用できるように、解決までのアプロローチを以下の順番でお伝えします。

・プロジェクトの状況

・問題の設定

・原因追求

・解決策

・教訓（リスク管理表へ整理）

👍 今回のコラム

むずかしさ　：
★★☆☆☆（PM初級者向け）

気付き学び　：
★★★★★(性能設計のミスによるリスク)

お役立ち　　：
★★★★★(品質基準の作成)

---

プロジェクトの状況

1.プロジェクトのスコープと体制

・顧客は大手介護サービス会社。

・顧客の情報システム部で新規構開発を実施。

・情報システム部の窓口は木村。

・プロジェクトオーナーは情報システム部の山田。

・システム化スコープは商品管理、資産管理、顧客管理。

・中堅SierのA社が開発ベンダーとして参画。

・A社は全開発工程の成果物の納品、システムリリースの責任を請け負う。

・A社の開発体制は業務チーム、基盤チーム、テストチーム、管理チームで構成。

・A社のPMは佐藤（初心者PM）

2.プロジェクト目標

品質目標：100%の不具合修正

スケジュール目標：予定通りのリリース

コスト目標：予算内でのシステム完成

3.プロジェクトの進捗状況

現在、プロジェクトは総合テスト工程であり、所要期間の50%が経過していた。

性能テストを実施していたが、計画通りのパフォーマンスが出せなかった。

そこで、原因不明であるがハードウェアのグレードアップを顧客の情報システム部 木村に依頼した。

しかし、木村から

「原因不明にも関わらず、予算を追加することはできない。」

と一蹴された。

佐藤は状況を把握しているが、具体的な問題や解決策が分からない状態である。

**守秘義務により企業名・団体名・個人名等は架空名称となります。

---

問題の設定

*私がアドバイザーとして、プロジェクトに参画して解決させた経緯のスタートです。

問題を考える場合は、どのマネジメント領域で発生したかを分類することで、後続のアプローチがスムーズに行え、得られた結果の根拠も説得力を持つ。

そこで、今回の問題は、プロジェクトで起きた事象を、様々なプロジェクト情報から考えをもとに考たところ『コストマネジメント領域』で発生した問題として取り扱った。

また、今回のプロジェクトの問題をこのように設定した。

”性能設計通りのパフォーマンスが出せずコスト超過”

この問題を放置することで、コスト目標である予算を逸脱する恐れがあった。

様々なプロジェクト情報
プロジェクト計画書、レービュー結果報告書、要求変更書、レビュー対象物、作業実績情報、作業範囲記述書、要件定義書、成果物一覧、課題問題整理表、役割分担表、要員の選定根拠、勤務表、成果物、関係者からのヒアリング結果

---

原因の追求

原因を特定するためには関係者へのヒアリングが重要である。

しかし、闇雲に関係者から聞き取りを行っても時間の無駄であることから原因の仮説を3つ立てた。

1.原因の仮説と検証

仮説1
アプリケーションを設計したメンバーのスキルが不足だった。

【仮説の検証】
メンバーはアプリケーション設計を実施する上で、十分なスキルがあったか？

【検証結果】
メンバー選定フェーズにおいて、十分なスキルを有していると判断されていた。

仮説2
ミドルウェアを設計したメンバーのスキルが不足だった。

【仮説の検証】
メンバーはミドルウェア設計を実施する上で、十分なスキルがあったか？

【検証結果】
メンバー選定フェーズにおいて、十分なスキルを有していると判断されていた。

仮説3
ハードウェア選定が間違っていた。

【仮説の検証】
性能設計に準拠したハードウェアを選定し、顧客が承認しなかったか？

【検証結果】
ハードウェア選定は行わず、既存のハードウェアスペックと同等にし、顧客の承認も受けていなかった。

2.今回の問題の原因

ハードウェア選定が間違っていた。

と判明した。

また、PMは昨今のハードウェアの性能を過大評価しており、性能設計に準拠せずグレードの低いハードウェア（既存と同等）を選定を行なったことが分かった。

---

解決策

わたしは3つの解決策を準備した。

解決策A
プロジェクト計画を変更して、選定したハードウェアに合わせて再度開発を行う。

解決策B
適正なハードウェアにグレードアップする。

解決策C
適正なハードウェアにグレードアップして、スケジュールを延期する。

現在のプロジェクトの状況とこの解決策の案をPO山田へ提言した。

PO山田は、このような意向があった。

⚫ 品質について 適正なハードウェアにグレードアップすることに問題はない。

⚫︎ スケジュールについて スケジュールの延期はできない。

このことから、解決策Bを採用した。

また、この解決策を施行することで、顧客はハードウェアのグレードアップによる費用が30%超過することになった。

---

教訓（リスク管理表へ整理）

今回の原因は、ハードウェア選定が間違っていたということであった。

このような事態を、事前に回避することはできる。

それは、プロジェクト計画の段階でこれらを実施することで防止できるのである。

・段階的な性能検証を実施した上で、システムに最適なハードウェアを選定することを性能計画の方針とする。

・性能設計でスペシャリストが、性能対象となる範囲を洗い出して、目標値（品質合格のライン）を顧客と合意する。

今回のトラブルプロジェクトをリスク管理表に整理したので、あなたのマネジメント業務で活用して頂ければ幸いである。

---

なぜ、プロジェクトが破綻したのか？

今回、プロジェクトが破綻したのは、PM経験が少ないことによるプロジェクト計画の策定を失敗したからです❗️

PM経験が浅い方は、プロジェクト計画で何を考えれば良いかが曖昧になっているケースがあります。

プロジェクト計画で、重要なのはプロジェクトを成功させるための要素を認識していなくはなりません。

プロジェクト計画を構成するは3つの要素

WHY：
なぜプロジェクトを行うのか。

WHAT：
どのような作業を行なって、どんな成果物を作るのか。

HOW：
どんな成功に導くための手段や方法を用意するのか。

破綻するプロジェクトは、3つの要素に対して、これらのことが出来ていないからです。

・どれか一つが漏れてしまった。

・間違った手順で作ってしまった。

・正しいメソッドやノウハウを使えなかった。

そのため、PMはプロジェクト計画を立てる時に、以下を意識してください。

1.構成を順番通りに、

2.正しい手順で、

3.メソッドやノウハウを使って、

4.「プロジェクト計画書」に、まとめる。

もし、あなたがこれらを意識していけど、

「勉強したいけど、何から手をつけていいか分からない」

「今の勉強方法が実践で使えるか自信が持てない」

「体系的にプロジェクトマネジメントを学び体験したい」

このように感じているなら、iPM TRAININGにチャレンジしてください。

あなたのプロジェクト計画書を作るスキルUPをサポートするサービスです❗️

iPM TRAININGのご案内 | iPM PREMIUM

最後まで、読んでいただき有難う御座いました。