『仕様追加を甘く見るな』PMの力量が問われる瞬間！

製造工程での仕様追加は製造済みの機能に大きく影響するため、しっかりと調査しなければなりません。

✅仕様追加の承諾判断に迷う方
✅PJリスクを集めているPMやPMO
✅プロマネ初心者を抱える管理者

にお伝えしたいプロマネ情報です。

プロジェクトが進むにつれクライアントが考えていた仕様が陳腐化することもあります。
特に長期プロジェクトでは、その傾向が顕著ではないでしょうか。
しかし、仕様追加の要望を軽く受け入れてしまうと思わぬトラブルが発生することもあります。
トラブルを起こさないようにするには、計画に沿って事前調査を行なってください。
また調査するための必要スキルを知ることが大事です。
意外にも、このことを知らないPMが多いって、ご存知でしょうか？

■今回のテーマ
プロジェクト計画における『スコープマネジメント計画』の検討の中で、『仕様追加時の事前調査をするために必要なスキル設定を行わなかった』ことにより、『プロジェクトが停滞した』という問題が起こりました。
この問題を取り上げていきます。
※プロジェクト検証の結果をお伝えするにあたり、架空の企業である「株式会社XYZ」での出来事として紹介します。

 prologue

株式会社XYZは、市場シェアの拡大と業務コストの削減のために、新規プロジェクトを立ち上げることになりました。

プロジェクトの目的として、売上の10%増加と業務コストの20%削減を掲げています。 目的を達成させるためには、個々の目標の設定が必要です。 品質目標は、レスポンスタイム、受け入れ合格に数値目標を設定しました。

コスト目標は、開発費用を1800万円以内として、スケジュール目標は、リリース日を10月1日、主要なマイルストーンをユーザーテストによる品質判断としています。

また、プロジェクトの開始は、4月1日。開発期間を6ヶ月としました。

 

【プロジェクトの登場人物】

▷山田

株式会社XYZの事業部長であり、プロジェクトオーナー。

▷木村

株式会社XYZの社内調整役。クライアント窓口であり、ITベンダーとコミュニケーションを取る。

▷佐藤

このプロジェクトの開発を担当する株式会社ABCのプロジェクトマネージャーであり、今回初めてプロジェクトマネージメントを行うプロマネ初心者。

▷PMアドバイザー

The manager's Barに所属。プロマネ初心者の佐藤のマネジメントアドバイザー。

 

【プロジェクト状況】
現在のプロジェクトは、製造・単体テスト工程である。
当該工程が所要期間の50%を消化した時点で、追加した仕様が、多くの機能に影響することがわかった。
影響する機能を修正することからリリース日を守ることができそうもない。
そこで、プロマネ初心者の佐藤は『追加した仕様の対応を運用フェーズで実施すること』を依頼した。
しかし、クライアント窓口の木村の解答は『貴社の影響調査の結果、プロジェクト計画の変更をしなくても対応できると出会った。当初の計画通り進めて欲しい』と要望された。
プロマネの佐藤は、状況の把握をしているが、具体的な問題が分からず打つ手もなかった。
そこで、PMOの私へサポートを求めてきた。
（以降のSTEP1-STEP4はPMOが実施した）

  目次

STEP1：問題の設定

今回の問題は、プロジェクトで起きた事象を、様々なプロジェクト情報を元に考えたところ、『スコープマネジメントエリア』で起こっている問題として取り扱うことにした。
そして、『仕様追加を承諾したが調査ミスによりスケジュール遅延』、このように問題を設定した。

STEP2：原因の究明

この問題は、スケジュール目標であるリリース日を逸脱している。
そこでPMOの私は、原因の仮説を立て検証を行った。
【原因の仮説】
(1)調査範囲が間違っている
(2)調査工数と調査期間が間違っている
(3)調査したメンバーのスキルが不足している

そして、仮説に対して調査を行い検証した。
【仮説の検証】
(仮説1)調査範囲が間違っている
▷有識者の検証した調査範囲と同じであったか？
➡︎YES

(仮説2)調査工数と調査期間が間違っている
▷有識者の算出した工数と所要期間も計画と同じであったか？
➡︎YES

(仮説3)調査したメンバーのスキルが不足している
▷調査を担当したメンバーは、追加された仕様の影響範囲を理解していたか？
➡︎NO

問題の根本的な原因は、『仮説3』と判明した。
また、プロマネ初心者の佐藤は、追加した仕様に関わらないメンバーに調査を依頼していたことが分かった。

STEP3：解決策

この問題を放置することは、デスマーチプロジェクトの危険があるため、PMOの私は解決策を３つ考え、プロジェクトオーナーの山田と協議した。
【解決策の候補】
解決策A：
追加仕様に関係するメンバーに調査させ、全ての追加仕様を盛り込みスケジュールを変更する。

解決策B：
追加仕様に関係するメンバーに調査させ、ビジネスインパクトの大きい追加仕様だけを対応する。

解決策C：
追加仕様に関係するメンバーに調査させ、ビジネスインパクトの大きい追加仕様だけを対応し、スケジュールを延期する。

調査の結果から、追加した仕様に関わらないメンバーに調査を依頼していたことが分かっている。
その状況をプロジェクトオーナーの山田へ説明し、山田の意向を踏まえ解決策を決定した。

【採用した解決策と採用の根拠】
山田の意向は、追加した仕様に関わらないメンバーに調査を依頼していたことに問題はないが、リリースの延期はできないとの要望があり、『解決策B』を採用した。

【解決策の実行に伴うダメージ】
また、今回の解決策を実施したことで、ITベンダーに追加した仕様の再調査による工数が30%超過した。
今回の問題における原因は、調査したメンバーのスキルが不足していたということである。
今後、このような事態を避けるために、以下を教訓とした。

【教訓】
(1)製造/単体テスト工程で仕様追加に関わる工数と時間を算出し、プロジェクトの進行に影響がないことを確認する。
(2)製造/単体テスト工程で仕様追加が及ぼす影響範囲を有識者と関係メンバーで調査する。

STEP4：リスク管理表の作成

最後に、今回プロジェクトで起こった問題を課題問題整理表に記述し、今後のプロジェクトの教訓として役立てるためにリスク管理表に記述した。
このリスク管理表は、ITベンダーのプロジェクト情報として保管され、他チームへの情報共有として利用することになった。

最後まで、読んで頂き有難うございました。
今後の貴方のプロジェクト活動の参考になれば幸いです。

このトラブルプロジェクトは私が対応しました！ 

www.abmtraining.net