プロジェクト初期にがんばって作ったWBS。なのに、1ヶ月後には誰も見ない『死んだExcel』になっていませんか？私もかつては何度もその失敗を経験しました。理由はいくつかあると思いますので、それぞれ紐解いていきます。
ケース１：WBS運用ルールを可視化できていない
往々にしてありえるのが、口頭で説明済だから・一般的なルールだから、という暗黙知で済ませることでルールを可視化(資料化)できていない場合に運用が形骸化することがあります。（明文化されていない→空中戦になりがち）
資料化することで説明会においても対象者に刷り込みしやすくなります。PMO目線の意見ではありますがPMOであればこそ、このあたりの仕組化は手を抜きたくないところです。
ケース２：タスク(アクティビティ)の完了定義が曖昧
WBSの更新ルールを定義していても、メンバーが更新してくれないことがありえます。理由として考えられるのは、更新の仕方が分からないから、というのがありえます。（≒WBSが使いにくい）
よくあるのが、資料作成というタスクで執筆が完了すれば進捗を100%(完了)にしてよいのか、或いは暗黙で内部レビューが終わった段階で完了にできるのか、定義されておらず更新が放置されてしまう、ことがありました。
対策としてはケース1と併せて更新ルールも定義してしまうのがよいと考えます。
ケース３：WBSの粒度が細かすぎる
WBSが細かすぎてメンテしていられない・・・これはWBS作成の永遠の課題の一つだと思っています。
通常、WBSは階層を３～４ほどに区切って作成することが多いですが、最小単位のタスクまで定義する必要が出てくるシーンがどれくらいありえるか？がポイントだと思っています。
（≒プロジェクトの現工程でタスク(レベル4)まで定義するのが適切な運用なのか、判断した上で運用しているか？）
判断に必要な要素としては、現在の工程とプロジェクトメンバーの数に左右されると考えます。
例えば、実装工程で複数のプログラマーが参画しており、機能・画面・部品といった切り方で実装を分担する場合はタスクまで定義したほうがよいですが、工程が要件定義や基本設計であれば、対象ドキュメントの作成状況が追跡できるレベルでタスクが定義されていれば事足りることが多いです。
WBSは工程によって作成粒度を変えて運用する、これは段階的詳細化の原則であり、ベストプラクティスです。
どのタイミングで、どこまで細かくすべきかの判断がPMの腕の見せ所です。私は24年の現場経験の中で、このバランスを常に意識して運用しています。
ケース４：メンテ癖がない人・すぐ忘れる人・反発する人がいる
プロジェクトメンバーは家族ではないため、言うことを聞かない人や独自ルールで生きている方が一定数いらっしゃいます。WBSのメンテをいくらお願いしてもやってくれないこともあると思います。
こういった方たちへの対処方法はどうなるのか？私の考えでは、正攻法は諦めて自分の足で情報を拾いメンテナンスする、が正しいです。
いくら怒ってもやらない人はやらないですし、改善が見込めない活動に労力を割くべきではないと割り切ってしまうのがよいと思います。（諦観）
最後に（宣伝）
「自分の現場のWBSが機能していない」「スケジュールの立て直し方が分からない」という方は、ぜひ一度ご相談ください。今回のブログでは書ききれませんでしたが、WBSを作成する方の立場によっても、運用課題は異なっていると思います。この辺りも丁寧に紐解きます。
WBSの運用状況・構成案作成・現実的な引き直しを一緒にサポートします。
