転職リベンジ – PMP編(第7版) – その７プロジェクトの遅延対策について解説！

今回は「プロジェクトの進捗状況が遅延した場合に、PMとして取る施策」について、対策技法の代表例である「クラッシング」と「ファスト・トラッキング」について解説する

遅延対策のセオリー
「クラッシング」とは
「ファスト・トラッキング」とは
例題
まとめ

遅延対策のセオリー

通常、プロジェクトが遅延するリスクを考えて計画の策定時点で対策しておく事がPMの役割だが、PMも神様ではないので、未来に発生するリスク・遅延要素すべてに対して対策が取れるわけではない。プロジェクトに対して遅延が発生した場合、発生した遅延の要因分析・発生している状況に応じて最善と考えられる対策を取る。

通常、PMとしてスケジュール遅延が発生した場合に取りうるセオリー的には、以下の感じ。
(※記載順不同)

問題点の特定・原因分析：
- 今以上の遅延拡大を阻止すべく取れる対策を即座に実行する為、遅延の原因を正しく特定することが必須。
スケジュールの再評価し目標日を再試算：
- 遅延が発生した現状も含め、改めてプロジェクト日程を再評価し、現状で考えられるリアルな目標日を試算する。
リカバリー対策案の検討：
- プロジェクトの方向性・状況によって取れる対策は変わるが、遅延のリカバリーとして考えられる手段を予め考え、その効果と”トレード・オフ”となる要素を明らかにしておく。
  1. 　　　リソースの追加：コスト増が許容される事が前提
  2. 　　　期間延長：遅延を受け入れ、完了時期の延期する
  3. 　　　コミュニケーション手法・内容の見直し
  4. 　　　周囲プロジェクト・類似プロジェクトの知見・資産の活用
  5. 　　　スコープのドロップアウト
ステークホルダーとの調整：
- 経験値的に遅延することがほぼ確信したら、真っ先に関係各位に情報を展開した方が被害が最小で済む場合が大半。
- 報告する相手によっては、取り急ぎの報告だったとしても「1.」「2.」の精度・内容は求められるが、ここに時間をかけ過ぎて情報発信が遅れてるよりは、「遅延規模」だけでも正確に試算し付帯情報は「検討中」にして発信した方が賢明。
- 報告が遅れるほど調整が難しくなるので、まずは情報共有と対策を検討中の旨の情報は発信しておいて損なし。

「クラッシング」とは

横文字がで分かり難くなっているのだが、「資源を追加投資して、スケジュールの短縮を狙う」ってこと

ただし、単純に資源を増やした所で、スケジュールの遅延原因・要素が特定できていなければ、ハッキリ言ってリスクが増加するだけで、期待する効果は殆ど得られない。

まずは、原因分析を行ってから…

　1）どんな資源を
　2）どのタイミングで
　3）どこに投入するのか？

を正しく考えられている事が最も重要。
考えもなしにリソースだけ投入して期待するだけの効果が得られず、逆にプロジェクト内が混乱してしまうって話は、よく聞く代表的な失敗例だったりする。

上記を踏まえ、クラッシクの流れを下記に列挙する

クリティカルパスの特定
- 遅延の原因箇所「クリティカル・パス」を特定する。
- 「クリティカル・パス」の要因を分析し特定する。
タスクの短縮方法の検討
- クリティカル・パス解消後のスケジュールを評価。(期待する短縮が得られているか？)
- 足りていない様であれば、別のクリティカル・パスを探し出す
リソースの追加先の検討
- 要因分析が完了していれば、追加で投入するモノが「人」なのか「機材」なのか「資源」なのか判断がついているはず。
- 「人」であれば、何ができる人を何人投資しなければならないのか？
- 「資源」「機材」であれば、どんなスペックをどのぐらい？
追加コストと効果・リスクの評価
- 単純に追加して、クリティカル・パスが解消されたからと言ってそこで終わりではなく、追加投資後のリスクを考えて置く必要がある。
施策後のモニタリング(管理)
- 想定しているリスクが顕在化しないように、また日程のリカバリーが想定通りに進んでいることを監視する為の監視スキームを考えておく。

「ファスト・トラッキング」とは

これも横文字でわかり難くなっているだけで…

順番通りに進める予定だった作業を「同時並行」で進めることで、スケジュールを短縮させてしまう

って話。当然、無理くりに後工程の作業を進めるわけなので、当初の計画で避けていたリスクが顕在化する可能性が飛躍的に向上する。

単純に考えただけでも「手戻りのリスク」の発生確率は高くなるし、日程自体が複雑化するので、ハッキリ言ってPMとしは遠慮願いたい施策になる。

以下に、ファスト・トラッキングの特徴や手法などを列挙

並列処理
- 一部のタスクを同時並行に実行することで、プロジェクトの総機関の短縮を狙う。
リソースの最適利用
- 日程変更に伴って、タスクの割当や調達機材の日程前倒しなど、具体的に調整した作業以外の部分で関連する作業の調整も必要になってくる。
- 日程上のアクティビティも細分化しなければ、同時並行的に進められない部分が発生する為に、日程調整が繊細且つ複雑化する。
リスク管理
- これまでシーケンシャルに実行することで回避できていたリスクが発生する為、改めて新たな日程でのリスクの洗い出しと評価が必要になる。
- 発生確率が高まったリスクについては、事前に予防策などが必要になる。
コミニュケーションと調整
- 日程が複雑化することで、プロジェエクト内でのコミュニケーション計画を見直し、より綿密にプロジェクト内メンバーが情報共有できる”仕掛け”を作る必要がある。
- また、日程が繊細になることで、日程との微妙なズレが発生することによる同時並行で進めていた作業に対する「手戻り」が即座に発生するリスクがあるので、コミニュケーション・コストを”ケチらずに” 常に情報共有が行われている様な状態にしておく必要がある。

例題

プロジェクトが遅延している状況において、ステークホルダーより開発期間の延長は認められたものの、費用の増額は認められない状況において、遅延対策として適切な対応を下記から選択せよ。

1）クラッシングを行う
2）別のスポンサーから出資を依頼し費用を増額する
3）ファストトラッキングにて日程を見直す
4）プロジェクトの進捗管理方法を見直す

納期の延長は認められているものの費用の増額は認められていない状況化で、現在の日程からの短縮を検討するシチュエーション問題となる。

この際、費用の増額が認められない状況化なので、「1) クラッシング」は除外することができる。

また、選択肢「2) 別のスポンサーからの出資を募る」では、現在のスポンサー・ステークホルダーをスキップすることとなり、プロダクトの提供価値に対する既存のスポンサーへの価値還元の観点からも、プロジェクト・マネジャーとしては越権することとなり、不適切と考えられる。

「4) プロジェクトの進捗管理方法」を見直すの選択肢においては、そもそも「進捗管理方法」に課題があるのであれば、進捗状況が遅延する前段階で、プロジェクト・マネジャーが気が付き事前に対処するべき内容となる。

消去法から考えても「3）ファスト・トラッキンッグ」による”日程見直し” が妥当な選択となる。