本ブログは移転しました。こちらをご覧ください。
◆プロジェクトマネジメントのトライアングル
プロジェクトマネジメントのトライアングルというのがある。プロジェクトの制約を表現するもので、基本的には
・スコープ(プロダクト品質)
・タイム
・コスト
であり、この3つの要素のバランスをうまくとり、プロジェクト品質を向上させるためのマネジメントを行う。あるいは、ITなどの受注型のプロジェクトでは、スコープを目標と考え、目標達成のためのマネジメントを行うという考え方をするケースもある。この場合は、プロダクト品質がプロジェクトの品質になる。
◆ゴールの多層性とトライアングル
ここで、前回、述べたことを思い出して戴きたい。プロジェクトの目的は、成果物を生み出すことではなく、ゴールを達成することであると述べた。ここで、「ゴール」について少し考えておきたい。
PMBOKにはゴールという言葉は出てこないが、達成すべきものだ。この範囲は広い。目的も含まれるし、プロダクトスコープもプロジェクトスコープも含まれる。実際にゴールとはプロジェクトをどういう範囲で考えるかに関わってくる問題である。
つまり、ゴールは
開発チームの視点:達成すべきスコープ
組織としての視点:達成すべき目的
となる。最低限、この2つの視座がある。このような多層性がある。
そのように考えると、プロジェクトマネジメントのトライアングルは
・ゴール
・タイム
・コスト
と考える方が現実的である。つまり、開発チームにおいても、組織においてもコストとタイムという制約は変わらない。しかし、そこで達成しなくてはならないことには違いがある。
このようにマネジャーにとって、プロジェクトマネジメントとは、タイムとコストの制約の中で、プロジェクトチームの生み出した成果物を使って、(戦略・組織上の)目的を達成するための活動である。
逆にいえば、マネジャーがプロジェクトの目的をきちんと設定していない場合、あるいは、正しくその目的をプロジェクトに伝えていない場合には、スコープ計画は不適切になり、プロジェクトの生み出した成果物には手戻りが生じる。事実、スコープ変更の多くの理由は目的とスコープの不整合で起こっている。
◆ゴールのマネジメントツール GBS
では、ゴールのマネジメントをうまく行うにはどうすればよいか?これはマネジメントの問題なので、いろいろなフレームワークや考え方があると思うが、その一つにブレークダウンストラクチャーを作るという考え方がある。GWS(ゴールブレークダウンストラクチャー)である。
ゴールブレークダウンストラクチャーは
(1)ミッション(戦略ゴール)
(2)ビジネス目標(組織上のゴール)
(3)プロジェクトリクエスト(プロジェクトのゴール=完了基準)
(4)スペック(プロダクト開発のゴール=WBSのトップ)
というゴールのブレークダウンを行う。すると、(4)のスペックがWBSのトップになるので、戦略ゴール(ミッション)から、スムーズにWBS(スコープ定義)まで展開していけるというメリットがある。
また、ゴールの多層性でいえば、一般的には(2)が組織のゴール、プロジェクトで達成すべき問題になるが、このゴールをプロジェクトリクエストに展開して行くことによって、マネジャーとしてのプロジェクトマネジメントとしてすべきことが明確になる。この点でもメリットのある手法だと言えよう。
GBSによって、プロジェクト側はプロジェクトリクエストを満足するためのプロジェクトマネジメント計画を策定する。ここから先は、いわゆるプロジェクトマネジメントの世界である。問題はマネジャー側である。トライアングルから分かるように、コストとスケジュールの制約はプロジェクトと同じものであり、管理をしておけばよい。しかし、ビジネス目標の達成については、自らがマネジメントしていく必要がある。ビジネス目標の中には、マーケットシェアのように、プロジェクトの成果物が上がってきたあとのマネジメントが必要なものがある一方で、ROIや技術開発のようにプロジェクト実施中にマネジメントが必要なものもある。プロジェクトマネジャーにプロジェクトスペックを渡す前に、GBSだけではなく、スケジュールについても検討しておく必要がある。
PM養成マガジンエグゼクティブ2号より
定期購読(無料)はこちらから。
最近のコメント