プロジェクトマネジメントでの段階的詳細化の方法について

段階的詳細化についていくつか書いてきましたが、どのように詳細化すればよいのかの基準が明確ではありません。

これはPMBOKもしかり、他のプロマネ本もしかりです。これもプロジェクトの個性によって違いがあるので、抽象的にしか記述できないことは理解できます。

そんな場合は、先輩プロジェクトマネージャや、組織のプロセス資産である「過去プロジェクトの成功事例」などを見ればわかるのですが、他の観点からも見てみたいという方のために、管理人の観点で書いてみます。

段階的詳細化について

段階的詳細化について、PMBOKガイドの定義を引用します

得られる情報が増え、より正確な見積りが可能になるにつれ、プロジェクトマネジメント計画書がより詳細化していく反復プロセス。

これ以上は短くできないような定義です。先のことはわからない。わかったときに検討しようというようなことでしょうか。

しかし、額面通りに受け止めると、痛い目に遭う可能性があります。

詳細化の手順

ざっくりですが、次の手順を想定しています。

  • 最初は判明している範囲を詳細化
  • プロジェクトが進むにつれて詳細化を繰り返す

最初は判明している範囲を詳細化

最初の段階では、その時点で知りえる最大限の情報を用いて、プロジェクト計画書を作成します。その時点の最大限の情報を集める努力はしてください。

プロジェクトが進むにつれて詳細化を繰り返す

それを元に作成したプロジェクト計画書ですが、プロジェクトが進行していくにつれて、新たな情報が追加されていきます。

その時点で判明している最大限の情報で、プロジェクト計画書を修正します。

これは、当初作成した計画書よりも詳細化されているはずです。これをプロジェクトが終結するまで、反復していきます。

当然その修正内容は、当初想定していたものから逸脱する可能性があります。そうなると、変更要求として適切に管理し修正していきます。

特にベースラインの変更を伴う詳細化の場合は、スポンサーに承認を得るなど、適切な処置が必要です。

最初の計画が肝心

そのため、最初の計画が甘いと、この段階的詳細化により、要件が膨らむなどの症状が現れることがあります。

そうならないためにも、最初の計画(見積もり時点が該当)で、できうる限り最大の想像力をつかって、未来を予想することが大切です。

悲観的にとまでは言いませんが、リスク登録簿を充実させるくらいに考えておいてください。

これがプロジェクトマネージャに要求される「先を見通す目」ということです。

すべてを知ることはできませんが、少しでも想定外の事態を減らせれば、プロジェクトを成功に近づけられます。

詳細化の対象

詳細化の対象は、プロジェクトマネジメント計画書になします。しかし、プロジェクトマネジメント計画書は、さまざまな計画書と補助計画書で構成されています。その中のどれに該当するのでしょうか?

管理人は、WBSとアクティビティ、すなわちスケジュールだと考えています。

当初の計画では、荒いWBSとスケジュールを作成しておきます。そしてプロジェクトが進み、詳細な情報が出てきた段階で詳細化を行う、ということです。

しかし、先程も書いたのですが、ここで当初計画(見積り)と乖離していると面倒なことが起こります。

それは、スコープの拡大・コストオーバー・納期遅延の三重苦に苦しめられる可能性があるということです。

詳細化といっても変更要求をともなうような詳細化は危険です。これは詳細化とは呼びません。

要件の抜け・モレの可能性がある不具合案件です。都合がよい詳細化という使い方はやめましょう。

見積りに失敗している可能性が高いのです。

詳細化の手順とは?

詳細化の手順とは何でしょうか?

それは、当初から作業する結果とボリュームがわかっているが、細かい段取りや、時期、要員手配というリソースが決っていないため割り当てられなかったものをブレークダウン(詳細化)する、といったものです。

具体的には次のような内容でしょうか?

最初はざっくり

当初計画では、次のような成果物があるとします。WBS-1を作成するために、WBS-1-1とWBS-1-2のワーク・パッケージがあると想定します。

詳細化の方法概要

まだ、現時点ではWBS-1-1の詳細がわかりませんが、WBS-1-1で作成する成果物はわかっています。

詳細が判明

WBS-1-1の詳細がわかってきたので、アクティビティに分解し、担当者と期間を割り当てた状態です。

詳細化の方法詳細

このとき、WBS1-1の内容や、アウトプットが変わっていてはだめです。変わるようであれば変更要求をあげる必要があります。

例えば、WBS1-1は「○○設計書の作成」するワーク・パッケージだとします。

その○○設計書の要件が、当初計画で10個とした場合、アクティビティは、その10個を作成するための、手順・期間・担当を詳細化すればよいはずです。

ところが「詳細化したところ、11個の要件になってしまった」というのが、変更要求が必要である、という意味です。

大抵、詳細化をしていくと要件が増えていくものです。ですが「先のことはわからないから」というのは、言い訳になりにくいですよ。

まとめ

段階的詳細化の考え方は、PMBOKで説明されるまでもなく、自然にプロジェクトマネジメントの中で使っているものと思います。

管理人もPMBOKを学習する前から、似たようなことをしていました。

しかし、都合よく段階的詳細化の考えを解釈すると、いつまでも正確な見積もりを出せない状態に陥ります。

あくまでも、当初の計画から膨らまないような詳細化をしていく必要があると、管理人は考えます。

みなさんも実務の上でどこまでが限界か? を感じてください。

 

PM

Posted by wpmaster