■プロジェクトが遅延してしまったら■
以上の道具を駆使すれば，たとえプロジェクトが途中で遅延しても，高い確率でリカバリできる。リリース延期を考えたり，メンバーに過剰労働を強いる前に，いくつか試みるべき方法がある。以下，具体的に見ていこう。
課題表で遅延を把握
まず遅延の原因を把握する手順から見ていこう。遅延の原因は，作業の遅れ，仕様の変更，製品の不具合など様々だ。通常，これらは課題表（図7[拡大表示]）やミーティングで発覚する。
前述のリスク管理表がトップダウン的に作成するのに対し，課題表は担当者からボトムアップであがってくる問題を記入する。課題表には，スケジュールを遅らせない範囲で対処すべき期日を記入しておく。これが守られる限り，課題はきちんとコントロールされており問題としては表面化しない。
こうした情報は，全員で共有するのが望ましい。小規模なチームならExcelシートを共有フォルダに入れておくだけでもいい。
明治乳業は，生産・物流システムの再構築に当たり，グループウエアのNotes上に情報共有システムを用意した。「必要な情報にたどり着きやすくするために，タイトルは長くてもいいから具体的に書くように求めた」（明治乳業 情報システム部 生産G 課長 田中弘幸氏）。
課題表に挙げた問題のうち，担当者レベルでは期日を守れない，または担当者レベルで対応できないものに対しては，マネージャーの出番となる。
●リカバリの方法(1)
コンティンジェンシー予備を使う
コンティンジェンシーとは日本語で「不測の事態」。コンティンジェンシー予備＊9とは，不測の事態に備えてあらかじめ多めに積み立てておく時間やコストのことである（図8[拡大表示]）。遅延がコンティンジェンシー予備の範囲内である限り，基本的にプロジェクト自体の変更は必要ない。
キヤノン販売はOracle E-Business Suiteで基幹システムを構築した際，コンティンジェンシー予備を使って予定通りのリリースにこぎ着けた。リリースは元々2003年4月の予定だったが，開発プロジェクト自体は2月で終了させることとし，1カ月間の猶予を見ていた。ところが結局，テストや教育が3月までずれ込み，予備をフルに使い予定通りのリリースを守った＊10。
コンティンジェンシー予備を効果的に積み立てておけるかどうかは，リスク・マネジメントの巧拙にかかる。課題管理表を細かくチェックすると同時に，過去の事例などを参考に，リスクを定性的，定量的に分析することをPMBOKでは推奨している。
重大なリスクが発覚したら，早めにコンティンジェンシー予備を積み立てたい。後半になるほど，リソースを融通できる余裕が少なくなる。
●リカバリの方法(2)
フリー・フロートを活用する
(1)は，事前にリスクを予測できていた場合にのみ可能な対処である。では，予測できなかった突発的な遅延に対しては，どういう対処法があるか。
まずやるべきことは，クリティカル・パスの確認と，クリティカル・パスに無関係なタスクの「最早開始日」「最遅開始日」を調べることである。クリティカル・パスとは，そのタスクが遅れるとプロジェクト全体が遅れてしまうタスクをつないだ線のこと。通常，一つのプロジェクトに1本ある。タスクの「最早開始日」「最遅開始日」とは，クリティカル・パスに影響を及ぼさない範囲で「最も早くタスクを開始できる日」「最も遅くタスクを開始できる日」を指す。クリティカル・パス上にないタスクは，この範囲内で開始日を任意に設定できる。
例えば，先行タスクが8月1日に終了し，後続タスクが8月8日に始まる3日間のタスクの場合，最早開始日は8月1日，最遅開始日は8月5日となる＊11。タスク開始日は，この間の任意の日に設定できる。もし8月1日に開始するように当初スケジューリングされていれば，開始日を4日間だけ遅らせる猶予があるわけだ。この猶予期間のことを，フリー・フロート（余裕日）と呼ぶ。このように一定限度内で遅延しても問題ないフリー・フロートを持つタスクはたくさんある。
遅延しているタスクがクリティカル・パス上に無く，遅延がフリー・フロートの範囲内に収まるようであれば，遅延を気にする必要はあまりない。もし，遅延タスクがクリティカル・パス上にあるなら，フリー・フロートを持つ別のタスクにアサインされている技術者を遅延タスクにアサインし直して，リカバリできる（図9[拡大表示]）。ただしこの方法は，クリティカル・パスに影響を及ぼさない範囲で行わなければならない。大がかりな対策が打ちにくいという制約がある。
●リカバリの方法(3)
ファスト・トラッキングを試みる
(1)(2)は他のタスクへの影響が少なく，比較的楽な作業なので，できればこれで済ませたい。しかしそれが無理と分かったら，タスクの所要時間を短縮できないか考える。所要時間を短縮すると言っても，工程を単純に減らせば，品質が下がる可能性が高い。
成果物の品質にダメージを与えずに所要時間を短縮する方法に，ファスト・トラッキングがある（図10[拡大表示]）。これは，通常は順番に実行するタスクのスケジュールを重ね合わせ，トータルの所要時間を圧縮する方法である。
出光興産は，新生産系システムの導入に当たり，ある拠点での開発が大幅に遅れ，リリース延期の危機に見舞われた。「センターで開発した共通モジュールに，拠点ごとの個別モジュールを組み合わせて，拠点ごとに順次導入していく計画だった。ところが最初の拠点である北海道の個別モジュール開発に手間取ったことで，その後の各拠点の開発が（ところてん式に）遅れることが決定的になった」（山村氏）。
そこで各拠点の技術者をセンターに集め，個別モジュールと，共通モジュールのインタフェースを集中して並行開発することにした。これにより，リリース延期を免れた。
似たような事態に直面したプロバインズ 高柳氏は，テストと教育を重ね合わせた。テストと教育とで同じマシンを使わなくてはならないことがネックとなったが，教育は日中に，テストは夜間に行い乗り切った。
この方法のデメリットは，タスク同士の関係を明確にしておかないと後で不整合が起こりやすいこと。その結果，手戻りが発生し，かえって事態を悪化させる要因にもなりかねない。
●リカバリの方法(4)
クラッシングの可能性を探る
タスクの所要時間を短縮する方法としてもう一つ，クラッシングがある。クラッシングとは，期間短縮のために追加投資を行うこと（図11[拡大表示]）。「技術者を新規に投入」というのが典型だ。
日本ユニシスは，開発したプログラムを顧客に渡し検証を依頼したが，予定していたスケジュールで検証結果が戻ってこないことがあった。「顧客の検証担当者はプロジェクト専任ではなく忙しかったらしく，作業が後回しにされていたようだ」（片岡氏）。このままではリリース日に間に合わない。そこで，日本ユニシス側で要員を新たに補充し，検証作業を一部アウトソースしてもらって乗り切った。
もちろん，コストとスケジュールのトレードオフは十分に分析しておくことが重要である。最小のコストで最大の効果が期待できる方法でなければ意味がないからだ。外注を活用するか，社内の技術者を回してもらうか，作業場所は確保できるか，開発ツールやマシンなどの作業環境もそろえる必要があるか，そもそも要員の投入が効果的かなど，検討すべき点は多い。検討が不十分だと，単なるコスト・アップに終わってしまうこともある。
