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

先日、リカバリーについて述べたが、もうひとつ、リカバリーに関連してはっきりさせておきたいことがある。

プロジェクトと計画というのを分けて考える必要があることだ。リカバリーという言葉は、

　・プロジェクトのリカバリー
　・計画のリカバリー

という両方の意味で使われるが、この２つは全然意味が違う。前者は目標変更であり、後者は計画変更である。

実は、この区分が必要なのはリカバリーだけではなく、リスクである。リスクにはプロジェクトリスクと計画リスクがある。プロジェクトリスクはプロジェクトのゴールに影響を与えるリスクであり、計画リスクは計画の実行に影響を与えるリスクである。

例えば、技術リスクを考えてみよう。製品の構成技術が実現できないかもしれないというリスクはプロジェクトリスクである。これに対して、設計を効率化する技術に問題が生じるかもしれないというリスクは計画リスクである。

ＰＭＢＯＫでいえばプロジェクトリスクが存在している場合には、そのリスクは回避しないとプロジェクトを開始することはできない。プロジェクトリスクの多くは、プロジェクトに責任はなく、プロジェクトスポンサーが解決すべきリスクが多い。ちなみに、よく、「リスクをとる」という言い方をするが、これはプロジェクトリスクをとることを意味する場合が多い。リスクはどこまで行ってもリスクであり、リスクが起らないことにかけるわけだ。このような場合、リスクモニタリングをいくらしても仕方ない。この手のリスクが運悪く発生した場合には、プロジェクトリカバリーが必要になる。

これに対して、計画リスクは、可能性が大きい、あるいは、計画に対する影響が大きければ、計画の見直しという形で着手前に対応するが、それ以外の場合には、軽減措置をとった上で受容することが多い。しっかりとモニタリングすれば、マネジメントで解決できる範囲にあるからだ。これがリスクマネジメントであり、発生した場合には計画のリカバリーを行うことになる。

実際のプロジェクトを見ていると、プロジェクトリスクはかなり慎重に検討しているが、計画リスクはあまり考えていないケースが多い。計画そのものがそんなにクリティカルではないのでこれで済んでいるが、はやり、ここを何とかし、脂肪のない計画を作りたいものである。

それはそうとして、このプロジェクトと計画の区別がきちんとできることが、大局観の第一歩であることをよく認識しておきたいものだ。