PMstyleプロデュース

そこで、トラブルだと言ってもよい状況、つまり、定義は何かという話になる。トラ
ブルの定義などないと思うが、計画と実績の差異のレベルは３つに区別できる。

レベル１：現計画（ベースライン）に回復できそうである
レベル２：現計画への回復は困難だが、プロジェクトに与えられた制約条件はクリア
できそうである
レベル３：プロジェクトの制約条件をクリアするのは困難である

通常、トラブルというのはレベル３のことを指している。一つだけ注意して欲しいの
は、回復もクリアも「できそう」であって、「できる」ではないこと。同様に、「困
難」であって、「不可能」ではないこと。つまり、よい意味でも悪い意味でもリスク
がつきまとう話であることだ。

さらに４つの目のレベルとして、制約条件をクリアすることだけではなく、プロジェ
クトを継続することも難しい状況があるが、これはこの記事では除外して考える。

◆判断基準の明確化は難しい

次に誰もが考えることは、基準を標準化することだが、そんなに単純ではない。例え
ば、スケジュールでみたときに、ある時点では25％の遅れがあったとしよう。どうい
う事情であるにせよ、これが「問題」であることは間違いない。ここでまず考えなく
てはならないのは数字の持つ意味。

この25％はどういう25％なのかという問題だ。想定されるケースは以下の通り。仮に
プロジェクト期間を均一な期間１～５の５つに分けて考えてみよう。すると

（a）期間１（序盤）開始時で25%遅延
（b）期間５（終盤）開始時で25%遅延

では全く数字の意味が違う。

次は、スナップショットではなく、微分値。

（a）期間４開始時での25%遅延。期間１からほぼ8%ずつ遅延が累積。
（b）期間４開始時での25%遅延。期間２までは遅延０。期間３で25%遅延。

では、やはり数字の意味が異なることは明らかだ。このように、スナップショットで
数字を切り取っても、その数字からプロジェクトがどういう状況にあるかを判断する
のは難しい。上の微分（時系列グラフ）も含めて、いろいろな視点から数字を見る必
要がある。

◆ベースライン以外の状況をどうみるか

さらに、判断を複雑にするのは、ベースライン以外の状況である。上の例は、スケジ
ュールだが、コスト、リソース、品質のなどでも同じような議論ができ、これらは上
のような複雑さはあるにしろ、ある程度定量的に分析できる。

ところが、実際のトラブルのときに多くの人が真っ先に気にするのは、数字そのもの
よりも、プロジェクトマネジャーの状況だとか、プロジェクトメンバーの疲労だとか、
上位組織の関心、あるいは、ベンダーや顧客の協力といったことである。

いくら、数字的に回復の可能性があっても、メンバーに覇気がなければ危ないと考え
るのが自然であるし、上位組織が逃げていたらもうダメだと考えるのが自然だ。プロ
ジェクトマネジャーはこの辺りのところをよく観察して、トラブルかどうかという判
断をする必要があるのだ。

◆対応が必要だからトラブルではない

さらに、もう一点、注意すべきことがある。トラブルとみなすべきかどうかは、対応
が必要かどうかとは別の話であるということだ。

例えば、上の例で

・期間４開始時での25%遅延。期間１で遅延25%。期間２、３は遅延なし。

という例を挙げたが、これは回復のための対応は必要だが、トラブルであると考えに
くい。回復のための対応は、納期の前倒しを求められた時と同じ平時の計画変更であ
る。粛々とすべきものである。

これに対して、

・期間４開始時での25%遅延。期間２までは遅延０。期間３で25%遅延。

の場合には、回復も必要だし、明らかにトラブルである。したがって、平時の計画変
更ではなく、緊急体制を取る必要がある。つまり、場合によってはプロジェクトマネ
ジャーまで含めた体制の変更と支援の強化、などをリカバリーとして行う必要がある。

もちろん、上にも述べたように、ベースライン以外の周辺状況がどうかによって最終
的には判断されるべきであるが。

◆関連セミナー

上のような議論をするアセスメントとリカバリーのセミナーがあります。

◆プロジェクトアセスメントとリカバリーマネジメント＜１４ＰＤＵ＞
【カリキュラム】
１．プロジェクトリカバリーマネジメントの考え方と概要
２．アセスメント
３．問題の見極め
４．問題からのリカバリーソリューション
５．アセスメントのプロセスとツール
６．リカバリープログラムの計画
７．プロジェクトの安定化
８．プロジェクトの回復
〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓