スコープの合意なしにプロジェクトを進めてしまった！〜炎プロ#3

今、あなたがこんな気持ちだったら、これを読んでください。

⚫︎PMOやPMで参画しているプロジェクトを炎上させたくない

⚫︎炎上プロジェクトの実例からリスク管理表を作りたい

⚫︎今すぐトラブルを解決する"きっかけ"が欲しい

あなたもプロジェクトで、こんな空気を感じたことがあったんじゃないでしょうか？

①顧客の仕様に関する不明点がQA管理されていない。
②プロジェクト計画の合意無しに作業を開始している。
③スコープ合意というマイルストーンが無い。
④顧客と開発チームでスコープを合意した書類が無い。
⑤スコープを決めていくタスクが不十分な状態でWBSに盛り込まれている。


これは、どこのプロジェクトでもあり得ることですよね。
しかし、これらを気にも留めずに後でどうにかなるだろうとプロジェクトを進めてしまうPMも多いものです。

こんにちは！
フリーランスPMO商工会議所の林です。

『PMOなら知っておきたい炎上プロジェクトの火消し方法』の第3回目となります。
今回は、PMが冒頭のような空気を感じながらも、スコープの合意なしにプロジェクトを進めたことで結合テスト工程で顧客と齟齬が起こり、炎上したプロジェクトの実例を紹介します。
あなたが5分で理解できて、即日現場で使えるように心掛けて解説していきます。

☑︎取り上げる炎上プロジェクトの概要

要件定義工程で顧客の体制にITプロジェクトの経験者が居ないことによる炎上プロジェクト

☑︎もしこんなプロジェクトにあなたがいたら要注意

①顧客の仕様に関する不明点がQA管理されていない。
②プロジェクト計画の合意無しに作業を開始している。
③スコープ合意というマイルストーンが無い。
④顧客と開発チームでスコープを合意した書類が無い。
⑤スコープを決めていくタスクが不十分な状態でWBSに盛り込まれている。

さて、今回のテーマを告知通り、『問題解決マップ』で炎上プロジェクトを整理して『リスク管理表』に落とし込んでいきたいと思います。

問題解決マップとリスク管理表

👍この記事の信頼性
私自身が直接携わった炎上プロジェクト、クライアントの依頼で検証した炎上プロジェクト、これら総数2,000以上のプロジェクトから、リスク頻度が高いであろう事象を選んで紹介しています。

---

■PROLOGUE

プロジェクト計画において、スコープを明確にするには、『顧客との合意』が必要です。
・合意したつもり。
・合意していないけど後で合意する。
このように安易に考えでマネジメントした結果、プロジェクトが炎上しデスマーチになるケースも多いものです。

PMOは、プロジェクトの歪みやリスクを回避するための指南役・支援役です。
リスク事象として頭の中にインプットしておき、プロジェクト工程の中で何かしらの工夫が必要となります。


【工夫の一例】
☑︎ プロジェクト計画で『スコープの合意条件』を決めておく。
☑︎ 合意されていないスコープは、合意するためのタスクをスケジュールに
　 盛り込んでマイルストーンとして管理していく。

意外にも、このようなことを知らないPMや実施しない開発チームが多いってご存知でしょうか？
今回の炎上プロジェクトが、まさにこの実例となります。
それでは炎上プロジェクトの火消し方法を解説するので、じっくり読んでください。

※この記事は1週間限定で公開しています。

---

■炎上プロジェクトの火消し方法

今回の炎上プロジェクトの実例から得られた教訓をリスク管理表へ落とし込んでいきます。
この記事では以下を解説していきます。
(1)どのようなプロジェクトの事だったのか
(2)根本的な問題は何だったのか
(3)たどり着いた根本的な原因は何だったのか
(4)どのような解決策を講じたのか
(5)リスク管理表へはどのように取り込んだのか

★時間時間が足りない▶︎あなたには”倍速読み”
忙しくて全文を読む時間が足りない！
そんな、あなたへ今回のテーマで解説する内容をイメージでインプットできるようにを『倍速読み』を用意しました。
※倍速読みは概略解説です。以降の本編を読むことで炎上プロジェクトの具体的な火消し方法が分かります。

倍速読み

(1)プロジェクトの事象

■どのマネジメントエリアで起こった事象なのか
スコープマネジメントエリア
■炎上の内容
結合テスト工程を実施中に顧客から、一部のシステム機能に関して要件未確定であることから、テストを進行しても要望通りのシステムが完成しないとの指摘を受けました。
また、PMは合意したつもりでたようですが、顧客は残課題であると認識していたことで双方の齟齬が起こったのです。
そのため、結合テストを中断せざる得ない状況になりました。　
また、今回の実例は、炎上プロジェクトの特徴として『スコープを決めていくタスクが不十分な状態でWBSに盛り込まれている空気感』を放置したことで炎上しました。

プロジェクトの事象

(2)根本的な問題

顧客、PM、開発メンバのヒアリングから今回の根本的な問題は『顧客側とのスコープの合意なしにプロジェクトを進行させた』と定義しました。

根本的な問題

(3)根本的な原因

スコープを決めていくタスクが不十分な状態でWBSに盛り込まれている空気感から、このような問題に発展した場合は、以下のようなことに焦点を当てて根本的な原因を探ることが重要です。
・仕様に関してのQA管理の正確性
・設計段階での仕様変更の管理の正確性
・スコープ確定条件の有無
これらの観点から原因の仮説を立てました。
■原因の仮説

①仕様に関するQAが管理されていない

②仕様変更に伴う設計変更が管理されていない
③スコープの確定日程と確定条件の取り決めがない

---