コンセプチュアル・マネジメント

ＰＭＢＯＫの概念の中にプロジェクトの「前提条件」というのがある。たとえば、

・プロジェクト計画書に定義されてる通りにプロジェクト組織が構成される
・顧客はプロジェクトの遂行に協力する
・組織や顧客に関する課題解決はタイムリーに行われる

といったものだ。実はこれらは、誰もが疑おうとしないが、多くのプロジェクトで成立していない前提条件である。最近ではだいぶ知恵がついてきたので、これらをリスクとして扱うことが多い。前提条件の崩壊というのはそれこそ、プロジェクトを崩壊するリスクになりかねない。

多くの場合、前提条件というのはプロジェクトマネジャーは無関係なところで構成される話だ。従って、成り立つかどうかも、ある意味でプロジェクトマネジャーはコントロールできないことが多い。せいぜい、リスク要因としてあげて、監視しておくことが精一杯であるが、監視したところでコントロールできないのだから、どうにかなるものでもない。

では、かくも重要なプロジェクトの前提条件に対してもっとも影響を与える人は誰か。上の例を見てもらうとわかると思うが、上位管理者、顧客、および、ステークホルダである。

さて、逆の視点でみてみよう。プロジェクトをうまく進めるためには、「常識的に考えて必要な前提条件」というのがある。例えば、「プロジェクト要員は必要に応じて確保できる」という前提条件がある。これもなかなか、成立が難しい前提条件の一つだが、このような前提条件が崩れてしまうと、ＰＭＢＯＫというプロジェクトマネジメントの手法そのものの有効性が崩れてしまう。

そんなことはない。リスクとして考えておくべきだという意見もあるだろう。確かに、「十分なスキルを持った要員が必要に応じて確保できる」ということを前提条件にするのであればそれは前提条件が成立しないことをリスクとして考えておくべきだ。しかし、上の例は、前提条件の不成立を受け入れるということはプロジェクトマネジメントをしないということに他ならない。

言い換えると、目標を設定し、目標を達成するためのマネジメントが機能するためには一定の条件がある。実は、一番の前提条件は、「目標が達成可能である」ということなのだ。ここすら前提条件になっていないプロジェクトがときどきある。この議論を見積もりの議論だと思うと間違いだ。背景にある程度の見積もりがあることは間違いないが、見積もりというのは所詮「過去の実績に基づく推定」に過ぎない。従って、目標が達成できるかどうかと、見積もり上のつじつまがあうかどうかはそんなに一致しているものではない。「一致しないのでプロジェクトだ」という言い方もできる。むしろ、重要なのは、できそうだという点について主要ステークホルダの合意があることだ。これが「目標が達成可能」という状態の他ならない。

そのような意味で目標を捉えたときに、「目標が達成可能である」は不可欠の前提条件である。

これ以外の前提条件は、むしろ、不成立があったときにカバーすべき条件だといえなくもないが、ただ、プロジェクトマネジメントではやはり、前提にしているものがある。例えば、
　「計画書は実行されるようにメンバーも含むすべてのステークホルダが努力する」
　「計画通りに実行されればプロジェクトは企業に利益をもたらす」
といった前提条件がある。これが成り立たなければ、ＰＭＢＯＫ流のプロジェクトマネジメントなど成り立たない。こういうのがマネジメントが機能するための一定の条件であり、マネジメントが機能しないというのはリスク以前の問題だ。

そのように考えると、このような前提条件のかなりの当事者は「プロジェクトスポンサー」や「組織の上位管理者」である。交渉責任や指導責任までを入れると、ほぼ、すべてについて責任を持つべきなのはこの２者になるだろう。例えば、ＳＩの受注プロジェクトで当初から顧客に全く協力の意志がないとすればこれはプロジェクトマネジャーの責任とはいえない。受注をしてきた組織の上位管理者の責任である。

このようにマネジメント上、不可欠だと思われる前提条件をクリアするのがプロジェクト環境創りである。ここをしっかりとやっていくようなプロジェクト支援体制を作ることが急務である。