How to recover a delayed project: fast-tracking, crashing and the other options

Every project manager eventually gets the message: a supplier is late, a key task took longer than estimated, the finish date no longer holds. The instinctive reaction is to ask everyone to go faster. It rarely works, and it hides the real question: which delay matters, by how much, and what is the cheapest way to win back those days?

This guide describes a repeatable method. First you measure the delay and locate it on the critical path; then you compare the four levers a project manager actually has, and you communicate a plan instead of an apology.

First, measure the delay properly#

“We are late” is not a diagnosis. Before choosing a remedy, answer three questions with data from the schedule, not from impressions:

1. How much? The slippage in working days between the current forecast finish and the approved plan. Without a saved baseline you cannot answer this precisely, which is one of the reasons to keep one (see the guide on baselines and variance).
2. Where? Which task caused the delay, and whether it has already finished, is in progress or has not started yet. A delay that has already happened can only be absorbed downstream.
3. Is it still growing? A task that slipped once because of a missing approval is different from a task whose remaining work keeps increasing week after week.

Update progress first. Recovery plans built on stale percentages recover days that were never lost, or ignore days that are already gone.

Is the delay on the critical path?#

The finish date is driven by the critical path, the chain of dependent tasks with no float. A delay on a critical task moves the finish date day for day. A delay on a non-critical task moves nothing, until it consumes the task’s total float; from that point the task becomes critical and any further day pushes the finish. The critical path guide explains how float is calculated.

This gives a simple triage:

Two consequences are often missed. First, you can only recover time on tasks that are still ahead of you: compressing a task that is already finished is impossible. Second, after any change the critical path can move. A path that had five days of float may become the new critical path once you have compressed the old one.

The recovery options#

Terms such as fast tracking and crashing belong to the standard vocabulary of project scheduling, as collected in PMI’s lexicon of project management terms^[1]. In practice the levers are four.

Fast-tracking: overlap the work

Fast-tracking means starting a task before its predecessor has finished, even though the plan had them in sequence. In scheduling terms, a finish-to-start link is replaced by a start-to-start link with a lag, or the lag of the existing link becomes negative (a lead). Testing starts on the first completed modules instead of waiting for the whole build; the fit-out begins on the floors that are already finished.

It costs no extra effort, but it is not free: the overlapping work relies on information that may still change. The typical price is rework. Fast-track only where the predecessor’s output is stable enough, and keep the overlap short. The guide to task dependencies and lag shows how to model the overlap correctly.

Crashing: add resources to critical tasks

Crashing shortens critical tasks by adding people, overtime or equipment. The rule is economic: compare the options by extra effort per day saved and start with the cheapest, then move to the next one only if you still need days.

Not every task can be crashed. Fred Brooks, in The Mythical Man-Month (1975), formulated what became known as Brooks’s law: adding people to a late software project makes it later. Newcomers need time to learn the context, and every extra person adds coordination. Crashing works on work that divides cleanly (parallel training sessions, independent test scripts, separate building areas) and poorly on work that one person or a small, close team must think through.

Reducing scope

Delivering less on time is often more valuable than delivering everything late. Move a feature, a report or a secondary deliverable to a later phase, with the explicit agreement of whoever owns the requirements. This is a business decision, not a scheduling trick: document it.

Moving the deadline

Sometimes the honest answer is a new date. If the remaining options cost more than the delay, or add unacceptable risk, propose a new finish date, have it approved and save a new baseline. What you should not do is slide the date silently.

A worked example#

A team is rolling out a new internal system. The remaining critical chain is: Development, then Testing (10 days, one tester), then Training (5 days, one trainer), then the Go-live milestone. Documentation (6 days) also starts after development and must be finished by go-live; it runs in parallel with testing and training and therefore has 9 days of float.

An integration problem has extended development by 6 working days. Development is critical, so go-live moves by 6 days, past the date promised to management. The 9 days of float on documentation are irrelevant: it is not where the delay is.

The options on the remaining critical tasks:

Ranked by cost per day saved, training comes first (0.5 person-days per day), then testing (about 1.3 person-days per day). Together they recover 5 days for 5 extra person-days. The sixth day comes from a one-day overlap between development and testing, accepted because the last development day is reserved for documentation of the code, not for new features.

Check the result: after development, the critical chain now takes 7 + 3 − 1 = 9 working days instead of 15, so the 6 days are recovered. Documentation still needs 6 days and ends well within the 9: it remains non-critical, with 3 days of float instead of 9. Had the compression gone further, documentation could have become the new critical path.

The scope cut stays on the table as a fallback if testing reveals more defects than expected.

Choosing and communicating the recovery plan#

A recovery plan is a proposal to the people who approved the original plan. Present it like one:

• the delay in working days and its cause, in one sentence;
• the options considered, with days recovered, extra effort and risks;
• the recommended combination and the resulting finish date;
• what you need from the stakeholders: approval, budget for extra effort, a decision on scope;
• the date of the next checkpoint.

Before sending it, check the plan against this list:

• progress has been updated up to today;
• the recovery acts only on tasks that have not finished yet;
• the critical path has been recalculated after the changes, and no other path has become critical without you noticing;
• the extra people are actually available on those dates and are not already overallocated elsewhere;
• every overlap has an owner who watches for rework.

Common mistakes#

• Recovering on the wrong path. Compressing tasks with float costs effort and does not move the finish date.
• Crashing everything. Adding people to every task inflates cost and coordination; compress only what is needed, cheapest first.
• Fast-tracking without a safety net. An overlap on unstable inputs turns a delay into rework, which is a bigger delay.
• Ignoring Brooks’s law. On work that cannot be divided, new people slow the team down for weeks.
• Re-baselining to make the delay disappear. A new baseline is the result of an approved decision, not a way to reset the variance to zero.
• Communicating late. Stakeholders accept a delay with a plan much more easily than a surprise on the finish date.

How to do it in Planitude#

Planitude’s tracking features cover the diagnosis. The baseline is saved automatically at the first progress update, and each bar shows its slippage in working days. Overdue tasks, tasks behind plan and tasks moved since your last visit are flagged, and links turn red where a delay exceeds the slack and spreads along the chain; hovering shows how far each task moves. With the critical path and total float displayed, you see at once whether the delay touches the finish date.

To test a recovery, change the plan and let the engine recalculate: replace an FS link with an SS link and a lag, shorten a task after adding a second person, check the Workload view for overallocation. Version history and undo let you go back if an option does not work. The Monte Carlo analysis tells you how likely the new finish date is (P50, P80, P95), and the AI estimate of the delay risk marks the open tasks that deserve attention.

You can also ask the AI assistant to propose the changes: every change is shown in preview and checked before it is applied. When the recovery is approved, save a new baseline.

Frequently asked questions#