Taking over a failed software project: method and steps

Taking over a failed software project starts with a business decision, never with a code review. You first restore the result the project was meant to deliver, audit what exists with a cold eye, decide between reviving it and rebuilding, then relaunch through small, verifiable releases. The code is almost never the real problem.

I'm Boris Bembinoff, founder of JUNR, a custom software studio for SMBs of 11 to 50 employees in a structuring phase. Taking over a stalled project, salvaging its value or deciding cleanly to stop it, is one of the cases that land on my desk most often. Here is the method I apply, step by step, and how to settle the one question that truly matters: take over the existing code or start from scratch.

What is a failed software project?

A failed software project is a project that has stopped producing value while it keeps consuming time and money. Concretely: chronically late releases, a scope that swells without ever shipping, code no one dares touch anymore, an unreachable vendor, or a director who no longer knows what they are buying. The budget climbs, the tool doesn't ship.

A stalled project is not a project in temporary trouble. A project in trouble has a course and misses a deadline. A failed project, by contrast, has lost its course: no one in the room can state, in a single sentence, the business decision the tool is meant to make possible. That difference governs everything that follows.

Why does a software project really fail?

A software project rarely fails because of the code, and almost always because of a business decision that was never made. The technical side is repairable: you re-read it, you rewrite it, you test it. What does not fix itself is a project launched without a clear answer to the question: what must this tool change, for whom, and measured how?

The Standish Group has tracked software projects since the 1990s in its CHAOS Report. Its finding, repeated edition after edition: only a minority of projects meet budget, deadline and scope at once. Most slip on at least one of the three. Your stalled project is no shameful anomaly. It is the quiet norm of an industry that would rather not talk about it.

You'll tell me that's agile: you move in iterations, you adjust as you go, of course things shift. Except agile moves a decision that exists. Iterating means adjusting a course you have set. Drifting means moving with no course to adjust. You correct a course. You cannot correct the absence of one. And the fog suits everyone for a while: it shields the vendor who is « making progress » and reassures the director who « sees screens ». Then the invoice lands.

The 5-step method to take over a stalled project

Taking over a stalled project follows five steps, and the first four are settled without writing a single line of code. The method runs from the business decision toward the technical work, never the other way. You restore the course, you look at the existing code honestly, you decide, you scope small, then you relaunch.

Step 1: restore the business decision the project was meant to serve

Restoring the business decision is the first step, before any technical audit. Before reopening a single file, I ask the director three questions:

• How will we know it's solved? If the answer is a feature, we're not there yet. If it's an operational result (« I stop losing two days a month », « my sales reps stop re-keying data »), we have the real objective.
• What is it costing you today, concretely? A problem with no cost isn't a problem, it's an annoyance. This question also sets the reasonable budget for the takeover.
• You're asking me to take over a tool. What are you really trying to get? This is where the stated need and the real need part ways.

Until those three answers are written down in black and white, fixing the code is like renovating a house without knowing who will live in it. At almost every first meeting, that sentence is what's missing, not the technical skills.

Step 2: audit the existing code without falling in love or burning it

Auditing the existing code means measuring what the code already written is really worth, without clinging to it on principle or scrapping it out of spite. You look at three things: what runs in production and serves a purpose, what is recoverable with some work, and what will cost more to save than to rebuild. The trap sits on both sides: the director who wants to « make the most » of everything already built, and the vendor who wants to rewrite it all because that's more comfortable for them. One concrete first move, before even reading a line: secure access to the code repositories and credentials, which vanish quickly when a vendor walks away.

Step 3: decide between reviving the existing code and starting from scratch

Deciding between reviving and rebuilding comes down to a single criterion: the cost of the takeover compared to the cost of a rebuild, for equal value delivered. If recovering the existing code lastingly costs less than starting over, you take it over. Otherwise you rebuild, and that's not an admission of failure, it's a deliberate decision. The detail of that trade-off sits in the table below.

Step 4: scope a deliverable that ships in a few weeks

Scoping a deliverable perimeter means choosing the smallest version of the tool that produces a real result, and fixing it. Not half the original project: the first brick that, on its own, changes something day to day. A stalled project has almost always swollen without ever shipping. You flip the logic: you ship small, fast, and you verify. Scope discipline is what separates a takeover from a relapse.

Step 5: relaunch through small, verifiable releases

Relaunching through small releases means resuming development by shipping pieces you can test yourself, at short intervals. Each release answers one simple question: does it work, yes or no, for a real use. This is where the « we » takes over: the JUNR team builds and delivers in increments, and at each step you keep the proof that the budget is producing something. The exact opposite of the six-month tunnel that delivers half of what was promised.

Take over the existing code or start from scratch?

Taking over the existing code is the right call when the code in place is maintainable and an outside team can understand it. Starting from scratch becomes unavoidable when saving it means paying twice. The criterion is never emotional (« we've already invested so much »), it's an accounting one: cost of takeover against cost of rebuild, for the same value delivered.

Criterion	Take over the existing code	Start from scratch
Code condition	Readable, documented, picked up by another team in days	Unreadable, undocumented, understood only by its author
Product decision	A course existed, it needs realigning	No course was ever written
Technical foundation	Modern stack, still supported	Obsolete tech or a maintenance dead end
Useful scope left	Part already runs in production and serves	Nothing stable in production, all to be validated
Compared cost	Recovery lastingly cheaper than rebuilding	Saving costs as much or more than rebuilding cleanly
Time to value	Short: you build on what exists	The base slows you more than it helps
Risk of failing again	Low if the cause was steering	High if you restart without changing method

One trap almost always skews this calculation, and it has a name: the sunk cost fallacy. You paid for six months of development, so you want to save the six months. I get it. But the money spent doesn't come back because you dig in. The only question that counts: from today, which path costs the least to reach the result you need? The past doesn't get a vote. And when we take a project over, our job isn't to sell you the most impressive rebuild. It's to find the shortest path to the result, the most profitable one, not the biggest project.

Common mistakes when taking over a stalled project

The most common mistake in a project takeover is starting with the code instead of the business decision. The takeovers I see fail a second time almost all share the same reflexes.

• Restarting development before having rewritten, in one sentence, what the tool must change.
• Wanting to save all the existing code so as « not to have paid for nothing ». The money already spent won't come back, and it must not drive what comes next.
• Taking on the entire original scope, the very one that sank the project.
• Switching vendors without changing the frame. The same fog handed to a new team produces exactly the same result, only more expensive.
• Mistaking activity for progress: screens that move don't prove a decision was made.

Frequently asked questions

How long does it take to take over a stalled project?

Taking over a stalled project produces a usable scoping in a few days to a few weeks, well before the first line of resumed code. The diagnosis, business decision plus audit of the existing code, goes fast. What takes time is the eventual rebuild, and its duration depends directly on the take-over or rebuild trade-off. Be wary of anyone who quotes a takeover without having looked at the existing code.

Should you scrap all of the previous vendor's code?

No, scrapping all of the previous vendor's code on principle is a mistake as costly as keeping all of it. The right decision is made brick by brick: what runs and serves a purpose stays, what costs more to save than to rebuild goes. You judge the code on its maintainability, not on who wrote it.

Can you take over a project without the original developers?

Yes, you can take over a project without its original developers, on one condition: that the code is readable and documented by another team. That is actually the decisive test of a healthy project. Code that only its author understands isn't an asset, it's a dependency. At JUNR, we deliver code an outside team can pick up at any time.

In summary

Taking over a failed software project means first restoring a business decision, then letting that decision govern the technical work. The five steps: restore the course, audit the existing code with a cold eye, decide between taking over and rebuilding, scope something that ships fast, relaunch through small verifiable releases. Code gets repaired. Fog does not: it gets decided.

A stalled project you no longer dare reopen? Let's talk about your specific case, 30 minutes, no commitment: I'll tell you straight whether to take it over or start fresh, and why.