A failing software project rarely announces itself. There is no single bad day, no email that says the plan has collapsed. Instead there is a slow accumulation of missed dates that quietly turn into no dates at all, of demos that show slides instead of software, of meetings where the honest question — is this actually going to work? — never quite gets asked out loud. By the time a leader admits the project is in trouble, the trouble has usually been legible for months. The good news is that most of these projects can be recovered. The recovery just does not start where people expect it to.
The signs, read honestly
The clearest sign is not that the project is late. Every project is late at some point. The sign is that it is late and no one can give you a new date they believe. The estimates have stopped moving because they have stopped meaning anything; "a few more weeks" has been the answer for a quarter. When a schedule loses its ability to be wrong, it has also lost its ability to be right.
The second sign is that there is nothing to show. Not a rough version, not a staging environment, not a single screen a real user could click through — just architecture diagrams, a backend that is "nearly done," and a promise that it will all come together at the end. Software that comes together only at the end usually does not come together at all. Working software, however ugly, is the only currency that counts, and its absence is the loudest signal on the list.
The last signs are human. Finger-pointing between teams, or between you and the vendor. A quiet fear in status meetings, where people report percentages instead of outcomes because the outcome is frightening. When a team stops telling you bad news early, it is not because there is no bad news. It is because the last person who raised it did not enjoy the conversation.
Budget behaves the same way as the schedule. A healthy project spends roughly in step with what it produces; a failing one keeps spending while what it produces flattens. If the burn rate has held steady but the demos have not improved in two months, you are no longer buying progress — you are buying activity. That gap between spend and visible output is one of the earliest honest signals, and it is legible on a finance report long before anyone on the team is willing to say the word failing out loud.
Stop before you spend more
The most expensive instinct in a troubled project is to push harder in the same direction. More people, more overtime, one more sprint — surely the thing is nearly finished, so it would be mad to stop now. This is the sunk-cost trap, and it is worth naming plainly: the money and months already spent are gone whether you continue or not. They are not an argument for continuing. The only question that matters is whether the next euro spent this way produces more value than the same euro spent some other way. Very often it does not.
Stopping does not mean cancelling. It means pausing the reflex to add more input to a process you no longer trust, long enough to understand what is actually happening. A project that has been sprinting toward a wall does not need to sprint faster. It needs someone to look up.
A worked example makes the trap concrete. Suppose you are eight months into a nine-month plan and most of the budget is gone, and the team asks for two more months to finish. The instinct is to reason that you are so close, and two months is small next to what you have already spent. But the eight months are gone whichever way you decide; they belong to the past and to no future choice. The only live comparison is whether two more months on this plan beats two months spent another way — a smaller re-scoped version, a fresh team, or stopping outright. Framed like that, the honest answer is often that the plan has already shown you what it produces, and buying more of it buys more of the same.
What a rescue actually looks like
A real rescue has a shape, and it is almost always the same shape. First, an independent review — someone who was not part of building the thing, and who has no stake in defending the decisions that got you here, looks at the code, the architecture, the deployment, and the way the team works. This is not a witch hunt. It is a diagnosis, and it needs to be honest precisely because everyone close to the project has a reason not to be.
Second, stabilise. Before anything is improved, the bleeding has to stop: the outage that recurs every week, the deploy that takes a day and fails half the time, the data that quietly goes wrong. You cannot rebuild on a floor that is still on fire. Stabilisation is unglamorous and it produces no new features, which is exactly why struggling teams skip it and why it usually has to be imposed from outside.
Third, re-scope to the essential. Almost every failing project is failing partly because it is trying to do too much. The rescue is a chance to ask a question that should have been asked at the start: what is the smallest version of this that delivers real value, and what got added because it was easy to say yes to? Cutting scope in a rescue is not a defeat. It is the single most powerful lever you have, and it is free.
Fix, restart, or change partners
The review answers the question everyone is dreading: do we fix what exists, throw it away and restart, or keep the work but change who is doing it? The honest answer is usually "fix," even when the codebase is unloved. A working system that solves a real problem badly is worth more than an elegant system that does not exist yet, and a full restart re-runs every risk that produced the mess in the first place — while the business waits, again.
A restart is justified only when the foundation genuinely cannot carry the destination: a data model that makes the core use case impossible, a platform choice that cannot scale to the actual load, a security posture that cannot be patched into safety. Even then, restart the part that is broken, not the whole thing. Changing partners is a separate decision from changing code. Sometimes the code is fine and the relationship is not — the cadence is gone, trust is gone, and no amount of good architecture survives a team that has stopped talking. A new partner can often keep most of the existing work and simply restore the discipline around it.
Get to a demoable slice, fast
The fastest way to change the mood of a failing project is to put something real in front of a real person. Not a finished product — a slice. One workflow that runs end to end, in an environment someone can actually open, doing one thing that matters. This does more than prove the technology. It re-anchors every conversation in something concrete, replaces "how far along are we?" with "here, click this," and gives the people funding the work a reason to keep funding it.
Getting to that slice usually means suspending the grand plan for a fortnight and being ruthless about what the slice includes. It is worth the disruption. A team that has shipped nothing for months has forgotten how to finish; a demoable slice teaches it again, and finishing is a habit before it is a skill.
Consider what that slice looks like in practice. A logistics company whose rescue we might imagine does not need the whole dispatch platform to prove life; it needs one driver, one route, and one delivery that can be created, assigned, and marked complete on a real phone against a real server. That is unglamorous next to the original vision, and it is exactly the point — it is small enough to actually finish in two weeks, and real enough that the people in the room stop debating architecture and start reacting to something they can touch. Everything after it is easier because the team has remembered what shipped looks like.
Rebuild trust and cadence
Trust in a troubled project is not rebuilt with reassurance. It is rebuilt with rhythm. A short, predictable cycle — every week or two — that ends in something you can see, is worth more than any roadmap presentation. The promise is small and it is kept, then it is kept again, and slowly the room stops bracing for bad news. Cadence is what turns a rescue from an event into a process, and it is the thing you keep long after the crisis has passed.
Part of rebuilding trust is being able to hear bad news without punishing it. The team that tells you a slice slipped, early and plainly, is the team that is going to deliver. Protect that behaviour. A rescue that restores the schedule but leaves people afraid to speak has fixed the symptom and kept the disease.
Start with an assessment
Every rescue we have described begins in the same place: an honest, independent look before another cent is committed to the current direction. That is why the sensible first step is not a proposal to rebuild and not a promise to fix — it is a short, fixed-fee assessment. A focused review of the code, the architecture, and the way the work is actually happening, ending in a written verdict: fix, restart, or change course, and a costed first phase to get moving. It is deliberately small, because the last thing a struggling project needs is another large commitment made in the dark. You get a clear-eyed diagnosis and a decision you can defend to a board — and only then do you spend the next euro.