PMstyle 2024年6月~8月Zoom公開セミナー(★:開催決定)

カテゴリ

Powered by Six Apart

« 「正解の呪縛」から逃れよう! | メイン | 私のプロジェクトはどこに向かって進むのか? »

2009年8月 2日 (日)

プロジェクトトラブルをどうとらえ、どう対処するか

(2009/03/18)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
■■
■■ 【記事広告】
■■   プロジェクトトラブルをどうとらえ、どう対処するか
■■           株式会社プロジェクトマネジメントオフィス
■■
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

プロジェクトマネジャーの活動の中で、意外と重要なのはトラブル対応である。特に
トラブルが顕在化する前に、トラブルの予兆を感じとり、上位組織に対して、支援を
求めていく活動は極めて重要である。

この記事では、そのような局面で、プロジェクトの状況をどのように捉えていけばよ
いかを解説する。

◆トラブルとは何か?

トラブル対応というときに、もっとも難しいのはトラブルとは何か?という話だ。

リスクマネジメントであればどれだけ言っても言い過ぎということはないが、トラブ
ルとなると、あまり、軽々しく口にすると、「オオカミ少年」のような話になってし
まい、肝心の時に支援を受けられないかもしれない。支援する組織側も限りあるリソ
ースで対応しなくてはならないからだ。

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

レベル1:現計画(ベースライン)に回復できそうである
レベル2:現計画への回復は困難だが、プロジェクトに与えられた制約条件はクリア
できそうである
レベル3:プロジェクトの制約条件をクリアするのは困難である

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

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

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

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

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

(a)期間1(序盤)開始時で25%遅延
(b)期間5(終盤)開始時で25%遅延

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

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

(a)期間4開始時での25%遅延。期間1からほぼ8%ずつ遅延が累積。
(b)期間4開始時での25%遅延。期間2までは遅延0。期間3で25%遅延。

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

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

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

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

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

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

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

例えば、上の例で

・期間4開始時での25%遅延。期間1で遅延25%。期間2、3は遅延なし。

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

これに対して、

・期間4開始時での25%遅延。期間2までは遅延0。期間3で25%遅延。

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

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

◆関連セミナー

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

プロジェクトアセスメントとリカバリーマネジメント<14PDU>
【カリキュラム】
1.プロジェクトリカバリーマネジメントの考え方と概要
2.アセスメント
3.問題の見極め
4.問題からのリカバリーソリューション
5.アセスメントのプロセスとツール
6.リカバリープログラムの計画
7.プロジェクトの安定化
8.プロジェクトの回復
〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓

コメント

コメントを投稿