『WBSが簡単に作れる』PMなら押さえておけば失敗なしの眼から鱗の秘訣！

PMなら正しくWBSを作成できなければ、メンバーからの信頼が得られません。

✅WBSを簡単に作れるようになりたい方
✅PJリスクを集めているPMやPMO
✅プロマネ初心者を抱える管理者

にお伝えしたいプロジェクトリスクの情報です。

プロジェクトの推進において、プロジェクトマネージャーがメンバーから、信頼を損なうものが『WBS』に関わるトラブルです。
このトラブルで一番多いのが、コロコロWBSが変更されることです。
これは、今までの作業が台無しになることもあり、メンバーのモチベーションが低下する原因でもあります。
プロジェクトマネージャーは、正しくWBSを作ることができなければなりません。
または、他人（例えば、部下）が作成したWBSのワークパッケージの内容や関連の正否を判断できる知識がなければなりません。
意外にも、これができていないPMが多いって、ご存知でしょうか？

■今回のテーマ

プロジェクト計画における『工数の算出』の検討の中で、『正確にWBSが作成されていない』ことにより、『プロマネの信頼がない』という問題が起こりました。
この問題を取り上げて、原因の追求、解決策、リスク対策を解説していきます。
※プロジェクト検証の結果をお伝えするにあたり、架空の企業である「株式会社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：原因の究明

この問題は、品質目標である要望達成率100%を逸脱、スケジュールであるリリース日を逸脱している。
そこでPMOの私は、原因の仮説を立て検証を行った。

【原因の仮説】
(1)不要な要件が排除されていない
(2)コミュニケーションルールが文書されていない
(3)残課題の解決が主要な設計に与える影響を把握していない

結果は、以下の通りとなった。

【仮説の検証】
(仮説1)不要な要件が排除されていない
▷メンバーは不要な要件を理解していたか？
➡︎YES

(仮説2)コミュニケーションルールが文書されていない
▷ルールをメンバーと共有していたか？
➡︎YES

(仮説3)正確にWBSが作成されていない
▷プロジェクトマネージャーは正確にWBSに必要な作業を盛り込んでいたか？
➡︎NO

問題の根本的な原因は、『仮説3』と判明した。
また、プロマネ初心者の佐藤は、思い出したようにWBSへ作業を追加しているため、メンバーはプロジェクトマネージャーを信用していないことが分かった。

STEP3：解決策

この問題を放置することは、デスマーチプロジェクトの危険があるため、PMOの私は解決策を３つ考え、プロジェクトオーナーの山田と協議した。

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

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

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

調査の結果から、思い出したようにWBSへ作業を追加していたことが分かっている。
その状況をプロジェクトオーナーの山田へ説明し、山田の意向を踏まえ解決策を決定した。

【採用した解決策と採用の根拠】

山田の意向は、プロジェクトマネージャーの弱点を補えるようにフォローアップ出来るメンバーをアサインすることに問題はないとの見解であった。
また、ITベンダーの上層部の意向は、佐藤のプロマネスキルをアップさせたいことから、『解決策B』を採用した。

【解決策の実行に伴うダメージ】

また、今回の解決策を実施したことで、ITベンダーにフォローアップメンバーのアサインすることによる工数が30%超過した。
今回の問題における原因は、正確にWBSが作成されていなかったことである。
今後、このような事態を避けるために、以下を教訓とした。

【教訓】
(1)プロジェクト計画でITベンダーは、プロマネの弱点を正確に把握する。
(2)プロジェクト計画でITベンダーは、チームの弱点を正確に把握した上で体制を組む。

STEP4：リスク管理表の作成

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

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

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

 

www.abmtraining.net