How to Rescue a Stalled Software Project
Key takeaway
Stop feature work first, then run a two-week technical and scope assessment before deciding anything. Most stalled projects fail on unclear ownership and unbounded scope rather than on code quality — and a rewrite is the right call far less often than it feels.
The pattern is recognisable from a distance: the deadline has moved three times, nobody can demonstrate working software end to end, and every status update contains the phrase "almost done". Panic rewrites and adding people both make it worse. A structured assessment does not.
Step 1 — Freeze new scope
Nothing can be assessed while the target is moving. Announce a freeze on new requirements for the assessment period. This is also a useful political test: if the freeze can't hold for two weeks, unbounded scope is your root cause and no technical fix will help.
Step 2 — Assess the three things that matter
- Code — can it build and deploy from a clean checkout? Is there any automated test coverage? How much of the promised functionality actually runs?
- Scope — what was contracted, what was added informally, and what does the business genuinely need to go live?
- People — who decides, who has context, and who is leaving. Knowledge concentrated in one departing person is a schedule risk bigger than any code issue.
Step 3 — Repair or restart?
Restart only when the code can't be built or deployed reliably, when it sits on an unsupported runtime that blocks security patching, or when nobody remaining understands the core logic. Otherwise repair: it's usually faster, and the existing system encodes hundreds of business rules that nobody has written down anywhere else.
The middle path is often the right one — keep the domain logic, replace the layer that's actually rotten, and route new work through the replacement while the old part shrinks.
Step 4 — Get to a shippable slice in six weeks
- Define the smallest release that delivers real business value, and defer everything else explicitly.
- Establish a working deployment pipeline before anything else — you cannot stabilise what you can't ship.
- Add tests to the critical paths only; broad coverage is a later luxury.
- Demonstrate working software weekly to the actual stakeholders, with no slides.
Step 5 — Fix the process that produced this
A rescue that doesn't change how decisions are made buys you a year at most. Name one accountable owner on each side, keep a visible scope ledger where every addition trades against something, and require a working demo — not a percentage — as the definition of progress.