PMが”場当たり”的に基本設計工程でWBSを変更するため顧客や開発メンバからの信頼を失った

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

わたしがプロコンサルとして参加しているiPM naviのコラムをご紹介します。

👍 このコラムは

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

ボリューム　：
★★★☆☆(5分-8分で読める)

気付き学び　：
★★★★★(顧客の合意の重要性)

お役立ち　　：
★★★★★(スコープ管理)

仕事の実用性：
★★★★☆（今すぐ使える）

---

writing by MIRIO
*このコラムはiPM naviで配信しています。

システム開発で顧客のニーズを実現するのは、大変難しいものです。

緻密な計画を立てても、予想外のトラブルが起こったり、開発途中で顧客の仕様変更を受け入れタスクの組み替えをしたりと、プロジェクトマネージャは気を抜く暇がないポジションですよね。

しかし、プロジェクトの推進を”場当たり”的に行なっていくPMがいたら、一体どうなるのでしょうか？

このようなPMに、メンバーが信頼を寄せることはありませんよ。

言わずともプロジェクトは大炎上ですよね❗️

あなたの周りにこのようなことで困っているプロジェクトチームはありませんか？

あなたが、このような炎上プロジェクトの主役にならないように『PMは顧客・開発メンバから信頼されていない』をリスクと捉えPJ計画の段階でリスク管理表に書き込んでおいてくださいね。

---

こんにちは、MIRIOです。

最初に見てもらったのが、プロジェクトマネージャであれば、押さえておきたいリスク事象の一つなんですね。

このようなリスクが起こりやすいプロジェクトには特徴があるんです。

特徴1：
PMがプロジェクトのスコープを曖昧に理解して進めている。

特徴2：
開発メンバがWBSに従わず独自の判断で進めている。

特徴3：
顧客と合意したスコープに対して、不要な要件を排除しないで進めている。

特徴4：
開発メンバ・顧客とのコミュニケーションルールに不備がある。

特徴5：
PMが顧客と合意したスコープに対して正しくWBSに落とし込めていない。

あなたが、参加しているプロジェクトが特徴1〜特徴5に当てはまっていたら、炎上プロジェクトの予感がしますので、細心の注意を払ってマネジメントしてくださいね。

このコラムでは、炎上プロジェクトの実例をあなたに紹介することで、プロジェクトのリスクをINPUTしてもらいマネジメントに役立ててもらえればと思ってます。

また、炎上プロジェクトの火消しまでのアプローチをたどれるように、このような順番で解説していきます。

approach1：根本的な問題

approach2：根本的な原因

approach3：解決策

今回は、『PMが”場当たり”的に基本設計工程でWBSを変更するため顧客や開発メンバからの信頼を失った』というテーマで、話しをスタートしますね！

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

炎上プロジェクトの概要

PMが”場当たり”的に、基本設計工程でWBSを変更するため顧客や開発メンバからの信頼を失ったことによる炎上プロジェクト

1.プロジェクトのスコープと体制
・顧客は大手製造メーカーである。

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

・システム化スコープは商品管理 、受注管理、課金管理が対象である。

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

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

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

2.プロジェクトの状況
・現在、プロジェクトは基本設計工程を行なっている。

・A社の開発メンバは、PMの作成したWBSで作業を進めていた。

・WBSは『計画に無かったタスクが突然現れる』、『タスク順序が間違っている』、『スコープ変更に伴って不要となった要件を盛り込んだタスク…etc』と精度が低い。

・これは、今に始まったことではなく要件定義工程でも頻繁に起こり、顧客からA社へクレームも多かった。

・開発メンバは、PMを信頼できなことから各自の経験でタスクを考え作業を進めていた。

・このことから、マネジメント不能になり進捗の遅れや品質の悪さが目立ち始めた。

・プロジェクトを正常化するには、PMとメンバの協力関係の再構築が必要でありリリース日を延期せざる得ない状況になった。

*今回の実例は『特徴5：PMが顧客と合意したスコープに対して正しくWBSに落とし込めていないケース』である。

炎上プロジェクトの火消しまでのアプローチ

approach1：根本的な問題の定義

顧客、PM、開発メンバのヒアリングから今回の根本的な問題を『PMは顧客・開発メンバから信頼されていない』と定義しました。

approach2：根本的な原因の追求

このようなケースでは、『開発メンバのスコープの理解』、『コミュニケーションルールの周知と認識』、『WBSの品質精度』に焦点を当てて根本的な原因を探ることが重要です。

そのため、以下のように原因の仮説を立てました。

(1)原因の仮説
①開発メンバは必要・不要の要件を理解していない。

②作業を進めていく上での懸念等をエスカレーションする仕組みがない。

③WBSが顧客要件をシステム化設計できるようにタスク割されていない。

(2)仮説の検証
仮説の検証として、関係者へレビューをしました。

(3)根本的な原因
レビューを通じて根本的な原因を探った結果、『WBSが顧客要件をシステム化設計できるようにタスク割されていない』ということが判明しました。

approach3：解決策

(1)解決策の案
根本的な原因から3つの解決策（案）を準備しました。

【解決策A】
プロジェクトマネジャーを交代する。

【解決策B】
プロジェクトマネジャーの弱点を補えるようにフォローアップ出来るメンバーをアサインする。

【解決策C】
チームの中のPM経験者をプロジェクトマネジャーに昇格させる。

(2)実行した解決策
プロジェクトに問題が起こった場合は、問題の大きさは関係ありません。

プロジェクトの管理要素である『品質』、『コスト』、『スケジュール』、『スコープ』のいずれかを調整することになります。

*プロジェクトの成功のためのトレードオフを仕掛ける。結末は以下の通りとなりました。

【解決策】
解決策B：プロジェクトマネジャーの弱点を補えるようにフォローアップ出来るメンバーをアサインする。

【解決策を選んだ理由】
・開発会社からPMのスキルアップのため交代は避けたいとの意向があった。

・PM育成のために開発会社で支援メンバを参画さ得るのであれば現在のPMが継続することに異論はない。

教訓の整理

このような炎上プロジェクトは、リスク対策として、あなたのプロジェクトマネジメントに活かしてくださいね。

プロジェクトが失敗する大きな要因の一つとして『WBSの精度』が挙げられます。 WBSの精度が低いと、その場の状況に合わせてWBSを変更する、または作り直すといった無駄な作業が発生します。

これは、今までの成果を台無しにするどころか、作業の手戻りというコストの増加や顧客・開発メンバのモチベーションを下げる結果となりプロジェクトチームの崩壊を招く可能性が高いものです。

このように安易に考えでマネジメントした結果、プロジェクトが炎上しデスマーチになるケースも多いものです。

PMは、リスク事象として頭の中にインプットしておき、プロジェクト工程の中で何かしらの工夫が必要となります。

そのため今回の教訓からリスク対策を以下のように整理しました。

【リスク対策1】
PMOやPMを任命したスポンサーが、予めPMの力量の把握をして不足スキルを補う体制を整備する。

【リスク対策2】
有識者が、計画工程、各開発工程の開始前に品質・コスト・スコープの目標を達成できるWBSであるかをレビューする。

【リスク対策3】
チームの弱点を正確に把握した上で、リスク範囲（品質・コスト・スケジュール・スコープ）を洗い出しておく。

あなたのプロジェクトマネジメントにお役に立てば幸いです。

---

★★★　45秒で分かるiPM navi　★★

無料メンバーの登録（こちら）

iPM naviの活用方法（こちら）

★★★　ぜひ、お立ち寄りください　★★

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