Rescuing a project that has fallen behind

The instinct that makes it worse

The usual response to a late project is to compress. Add pressure, add hours, shorten the review cycles, ask for daily updates, and promise the original date with more conviction. It feels decisive. It usually produces a team that is more tired and no further ahead, because nobody has yet established what is actually true about the work.

A recovery is a diagnosis before it is a plan. The first two weeks are about finding out where the project really stands, then making one honest decision about the date, the scope, or both.

Week one: build a factual picture

Start with evidence, not status reports. Status reports describe how people feel about progress; evidence describes what exists.

Collect the artefacts. What has actually been produced, and what state is it in? A specification that was circulated but never approved is not a finished deliverable. A system that works in a test environment is not live. Sort every promised deliverable into three piles: exists and is accepted, exists but is not accepted, does not exist. That sorting alone will often explain the delay.

Reconstruct the decision trail. Look for decisions that were needed and never made. In stalled projects, it is common to find work that stopped weeks ago waiting for an approval nobody realised was pending, because the request was made in a corridor or buried in a long email thread. List every open decision with its owner and the date it was requested. This list is often the most immediately useful document in the whole recovery.

Ask each person one question. Not "how is it going" but "what are you waiting for?" The answers cluster quickly: waiting for a decision, waiting for someone else's output, waiting for access, waiting for clarity on what good looks like. Waiting is usually the dominant cost, and it is invisible in a task tracker.

Check the handovers. Where does work pass between people, teams, or organisations? Every handover has a hidden cost: interpretation, rework, delay. If three groups each believe the other is responsible for an integration, that gap will be at the centre of the delay.

Test the plan against reality. Compare the plan's assumptions to what is now known. Were the estimates based on a smaller scope? Did the team assume a supplier lead time that has since doubled? Assumptions that quietly expired are a common cause of slippage, and nobody is at fault for them, which makes them easy to discuss.

Find the one thing that governs the date

Almost every late project has a constraint that determines when it can finish: one team, one decision, one dependency, one scarce skill, one external approval. Compressing everything at once spreads effort thinly and changes nothing.

Map the work as a chain of dependent steps and look for the point where everything queues. If one reviewer must approve every design and that reviewer has two hours a week available, the project's speed is set by those two hours, no matter how hard everyone else works. Adding pressure to the other steps does nothing. Freeing that constraint, by splitting the approval, delegating it, or batching decisions, can move the date more than a month of overtime.

Be careful with the word bottleneck; it should be something you can point at, not a general complaint about being busy.

Choose one of three honest moves

Once you know where the work stands, there are three ways out, and every recovery is some combination of them. Name the combination explicitly.

Move the date. Decide a new date based on the work that remains, not the work that was hoped for. Give a range, and say what the range depends on. A revised date that holds is worth far more than an original date that was never achievable. The conversation is uncomfortable once; the alternative is uncomfortable every week.

Reduce the scope. Identify the smallest version that delivers the outcome to real users. Split the project into a first release that solves the central problem and later increments for everything else. This is the option most often available and least often taken, because it requires someone to say out loud that some promised features will wait.

Add capacity. Useful, but slower and more expensive than people expect, because new people need context before they contribute. Capacity helps most where the work is divisible and well documented, and helps least where the constraint is a single expert or a single decision-maker.

Write down which moves you are making, and what you are explicitly not doing. A recovery plan that says "we will compress everything and hope" is not a plan.

Communicate early, specifically, and once

Bad news gets worse with delay. Stakeholders can usually absorb a new date; they struggle with a surprise.

Say what changed, what you now know, what the revised plan is, and what you need from them. Give the same message to everyone at the same time, in writing, so there is one version of events. Avoid blame in the memo; the objective is a shared picture, not a trial. If individual performance is genuinely part of the problem, that is a separate conversation with that person, not a line in a project update.

Then set an expectation of frequency: a short written update at the same time each week, with the same four sections, so people can see movement rather than re-reading prose.

Stabilise before you optimise

In the first weeks of a recovery, resist the urge to redesign everything. Pick a small number of changes, apply them consistently, and let them work: a single prioritised list of work in progress, a decision log reviewed twice a week, one short stand-up focused on blockers, and a rule that nothing new starts until something finishes.

Limiting work in progress is unglamorous and consistently effective. When a team is allowed to have fifteen things open, everything moves slowly and nothing completes. When the number of open items is capped, finished work appears faster and the picture becomes trustworthy again.

What to avoid

• Heroic overtime as the strategy. It buys a short burst at the cost of the following month, and it teaches the organisation that late projects are solved by exhaustion.
• Silent scope trades. Quietly dropping a promised item to protect a date is a decision; make it visible, with a name against it.
• Rewriting the plan from scratch. The old plan is not the enemy, the missing information is. Keep the structure and correct the facts.
• Adding reporting instead of removing blockers. More status meetings do not make work go faster. Removing the thing everyone is waiting for does.

How you know the recovery is holding

Three signs, roughly a month in: the number of open decisions is falling rather than growing; the weekly forecast stops moving; and people can say what they are working on and what they are waiting for without checking. None of these are dramatic. Together they are the difference between a project that is being managed and one that is being endured.