トラブルへのリソースの逐次投入は火種を延焼させてしまう

プロジェクトのトラブルは、予兆をつかむことができます。それはプロジェクトマネージャやリーダの役割を担うメンバが計画と実績の差異を見つけようとしている間なら。

予兆を掴むということは、計画どおりに進捗していないことばかりを追うことではありません。そればかり追っていれば良いのなら、WBSと睨めっこしているだけで十分なのですから。

でも、現実はそうは行かないのです。

とはいえ、どんなベテランのプロジェクトマネージャやリーダであっても、隅々まで目を光らして計画と実績の差異をチェックし続けることは限りがあります。なんらかの自分だけのルールを設け、よりリスキーなテーマについて自らのリソースを投入することになります。

トラブルはもともと小さな進捗遅れや仕様の理解違い、はたまた、スケジュール上の伝達誤りなどが起因で発火します。

そうすると、さすがに視界に煙が上がるのが目視できるようになりますから、ここで対処を開始することになるわけです。当然の対応です。

ただ、ここで目算を誤ると取り返しのつかないトラブルに昇格する場合もあるということを知っておかなければなりません。

目算を誤ると火種のトラブルに対する対策としてのリソースを過小に見積もり、投下することになります。過小に見積もった分、当然鎮火しませんからずっと引っ張るんですね。ただ、一見鎮火しているように見えていますから、別の、プライオリティの高いWBSにリソースを相変わらず投下し続けるのです。

時々、ボッとトラブルの火が上がると鎮火したトラブルにリソースを投下し続けることになるのです。ここで、変だな、と気付けるかどうかが最終ライン、といったところでしょうか。

火種のうちのトラブルがもし、延焼し始めたらどれだけプロジェクトに影響するか。

これを火種のときに見極めなくてはいけないのです。そしてその火種のトラブルが鎮火できなかったときのプロジェクトに与えるエクスボージャを読み、プロジェクトの進捗の障害となるものに当たるのであれば、一時的にリソースを十分に投下し鎮火しなければ、継続的にリソースを逐次投入することになり、その投下したリソースの効果は得られないまま延焼してしまうのです。

この、効果が得られないままジワジワと燻っている状態かどうかを検証しないといけないのです。ここはただ、トラブルの状況を聞いていてはいけないということであり、リソースを突っ込んでいる以上、成果が出ているかという観点でものを見る習慣をつけなければならないということを意味しています。

なので、計画と実績の差異の時点でプロジェクトの進捗上の障害となるものかどうかを見極めることがトラブルの予兆を掴むということにつながるのです。

 

失敗の本質―日本軍の組織論的研究 (中公文庫)

失敗の本質―日本軍の組織論的研究 (中公文庫)