How to handle a software project that has failed

At some point most companies that build software have a project go wrong. It runs far over budget, it misses every deadline, or it is released and nobody uses it. When it happens to you, it feels like a uniquely bad situation, something to be embarrassed about. It is not. Failing software projects are common, and they have been for as long as people have built software. The thing that actually matters is not whether a project fails, because plenty do. It is what you do once you know it is failing. Handled well, a failed project becomes a cheaper next attempt. Handled badly, it becomes months of extra spending on a plan that was already broken. Here is how we think about handling it well.

First, understand why, without blame

The most common mistake when a project is failing is to react before you understand. The pressure is enormous: money has been spent, people are watching, and the instinct is to do something, usually to put in more effort. Resist that. The first step is understanding. Until you know, in plain terms, why the project is failing, any big decision you make is a guess.

So run a post-mortem, and run it honestly. Get the people who actually did the work in a meeting and make it safe for them to tell the truth. The way you make it safe is to focus on decisions and causes, never on individuals. The moment a post-mortem turns into finding who to blame, people start protecting themselves, and the honest information you need disappears. Ask what went wrong, when the project first started to fall behind, and what you would have needed to know earlier to avoid it. You are not looking for a comfortable story. You are looking for the real cause, even when it is uncomfortable and even when it leads back to a decision you made yourself.

It helps to know that most software projects fail on direction and scope, not on engineering skill. Unclear goals, scope that grew too large, a plan built on wrong assumptions, or building something users did not actually want. These are the usual causes, and none of them are fixed by the team simply trying harder. Industry research has shown for a long time that a large share of software projects miss their goals in some way, which is documented in work like the Standish Group's CHAOS research. Your failing project is not a sign you assembled uniquely bad people. It is a normal outcome that you now have a chance to handle better than most.

Then decide: fix, restart, or stop

Once you honestly understand the cause, you face three real options, and naming them clearly is a large part of the work. You can fix the project, restart it, or stop it entirely. Most teams only seriously consider the first, which is exactly why so many failing projects keep failing.

Fix it when the core idea is sound and the problems are specific and solvable. If the goal is right, users want the thing, and the trouble is a handful of concrete issues, then targeted repair is the answer. You address the specific causes the post-mortem found and continue. Restart it when the goal is still worth pursuing but the basic design is wrong. Sometimes the idea is good and the execution went in a direction that cannot be repaired, whether that is an architecture that will not keep working or a plan built on assumptions that turned out false. In that case, patching it forever costs more than starting the build again with what you now know, and a restart is the honest choice. Stop it when the goal itself no longer makes sense, or when what you have learned shows the idea does not work, or when the cost to reach the goal is simply more than the goal is worth.

That last option, stopping, is the one people avoid most, and it is worth saying plainly: stopping is not failure. It is refusing to spend more money on something that will not return its cost. Money and time already spent are gone whether you continue or not, so the only real question is whether the next dollar is worth spending. If the honest answer is no, stopping is the most valuable decision you can make, and a clear stop frees your best people to work on something that matters instead. The biggest mistake in this whole situation is putting more effort into a broken plan, adding people and hours to a project whose problem was never a shortage of effort. That just pays for more of the same failure. We wrote about why "we just need more people" is so often the wrong diagnosis in staff augmentation vs a managed team, and a failing project is the exact place that mistake does the most damage.

Save what is worth keeping

Whatever you decide, do not leave with nothing. Even a project that was never released almost always produced things worth keeping, and the failure is only total if you throw them away.

Look for three kinds of value. First, the working pieces: parts of the code, designs, or research that are sound and can be reused even if the whole did not work. Second, the assets that last beyond the specific attempt, like the understanding of the problem you built up and the user research you gathered along the way. Third, and most valuable, the lessons about what does not work. You now know which assumptions were wrong, which approach failed, and how real users actually behaved when they used it. That knowledge is expensive, because you paid for it with the failed project, and it would be a waste to pay for it again by forgetting it.

This is the mindset that turns a failure into something useful: a failed project removes unknowns. The reason a first attempt is so risky is that it is full of things nobody knows yet, and the failure, painful as it is, answered a lot of them. The next attempt starts with those answers. It skips the mistakes you already made, avoids the assumptions you already disproved, and moves faster because you now know more about the problem you are building for. That is how a failed project makes the next one cheaper. The cost of the failure gives you a clearer plan the second time, but only if you actually use the lessons instead of hiding them out of embarrassment.

The mindset that makes the next attempt cheaper

In the end, the whole thing depends on how you treat failure. If you treat a failing project as a shameful event to hide, you will avoid the honest post-mortem, avoid the clear decision, and avoid admitting what you learned, which is the surest way to repeat it. If you treat it as normal, which it is, and as information, which it is, you get the opposite: an honest look at the cause, a clear choice about what to do, and a set of lessons that make your next attempt genuinely better.

Separate the idea from the execution, and you will usually find the failure was in how the product was built rather than in what it was meant to do. The goal might still be worth pursuing. If it is, a fix or a restart informed by everything you just learned has a much better chance than the first attempt ever did, because it starts with a record of where the first attempt went wrong. And if the goal itself no longer makes sense, stopping cleanly and moving your people to better work is not a loss either. It is the discipline that keeps one failed project from becoming two. When we join a project that is in trouble, the first thing we do is run that honest post-mortem, help make the fix-restart-stop decision clearly, and make sure the next attempt is cheaper than the last. That work is the core of a full product build and of the technical due diligence we do when someone needs an outside opinion on whether a struggling project can be saved.

A failure mode that is specific to fast tooling

There is a newer way for a project to be in trouble, and the usual warning signs do not show it.

The classic troubled project is visibly behind. Everyone can see it, even if nobody wants to say it. The newer version looks fine: changes are being merged, the demos are good, the velocity chart is fine. What is wrong is that a large amount of code has entered the system that nobody has read carefully, and the gap between what the software does and what the team understands has been widening for weeks.

It appears late and all at once, usually as a bug nobody can explain in code nobody can account for. If your project is producing a lot and understanding little, treat that as the same emergency as a missed deadline, because it is one.

Sources

• Standish Group, CHAOS research on software project success rates: https://www.standishgroup.com/