Turning Around a Project in Trouble: The Mistakes That Keep It Stuck
Almost every troubled project sends the same early signals: dates slip a little at a time, status reports stay green a week too long, and the team is busy without finishing much. By the time someone is asked to turn it around, the problem is rarely a single bad decision. It is a pile of small ones, and the recovery often fails for reasons that have nothing to do with the original cause. The pandemic recovery period made this worse, with split remote teams, stretched supply lines, and people reluctant to deliver hard news over a video call. Here are the mistakes that keep a recovery stuck, and what to do instead.
The diagnosis mistakes
Acting before you understand. The instinct under pressure is to do something visible — replace a vendor, add people, set a new deadline. A recovery that skips an honest diagnosis usually just relocates the problem. Spend the first short stretch listening: to the team, to the data, to the customer, before you commit to a plan.
Trusting the status, not the evidence. If the reports said green right up to the crisis, the reporting is part of the problem. Go look at the actual work — the code merged, the deliverables accepted, the tests passing — not the percent-complete someone typed in.
Confusing symptoms with causes. Missed dates and angry stakeholders are symptoms. The cause is usually upstream: unclear scope, a decision nobody will make, a dependency that was never real. Treating the symptom buys a week and loses a month.
The action mistakes
Adding people to a late project. Brooks's old observation still holds: throwing bodies at a late, complex project usually makes it later, because the team spends its scarce time onboarding instead of delivering. Stabilize the work before you scale the team.
Protecting the original scope. A project in trouble cannot usually deliver everything that was promised on the original date. Pretending otherwise is the most common reason recoveries fail twice. Re-baseline honestly: cut or defer what is not essential, and say so out loud.
Recovering in private. Quietly fixing things and hoping no one notices destroys the trust you need most. Sponsors forgive a problem named early far more readily than one discovered late.
Declaring victory at the first green week. One good sprint is not a recovery. Hold the new discipline long enough that the improvement is structural, not a temporary burst of heroics that burns the team out.
What a real turnaround looks like
The teams that recover well tend to do a handful of unglamorous things consistently. They establish one honest source of truth for status and kill the optimistic reporting. They cut the work in front of them to a short, achievable next milestone and finish it completely before opening the next. They make the hard scope and date conversation with the sponsor early, in plain language, with options rather than excuses. And they protect the team's focus ruthlessly, because a recovering project dies from a hundred interruptions as easily as from one big failure.
Name the real condition out loud — to the team and the sponsor — so everyone is solving the same problem.
Replace optimistic status with a short list of done, in-progress, and blocked, reviewed often.
Re-baseline scope and dates against reality, with cuts and trade-offs stated explicitly.
Deliver one small, complete milestone to rebuild credibility before promising the rest.
A turnaround is less about heroics than about subtraction: removing the false reporting, the unmanaged scope, and the interruptions, until the team can see and finish the next real thing. Once they do that once, momentum usually does the rest.
When a project has lost the room's confidence and needs a clear-eyed reset, XNM's program & project delivery advisory can help you diagnose what is really wrong and get delivery moving again.