16 September 20268 minute read
Stalled software projects share a pattern. The original intent was clear enough to start. Then scope grew, people changed, a supplier went quiet, the remaining budget no longer matched the remaining work, or nobody could say whether the thing being built was still the thing the business needed. By the time a new team is asked to “just finish it”, the most expensive decision is already on the table: continue, recover, or start again.
Do not make that decision from a demo and a folder of tickets. Make it from a short, honest assessment. The aim is not to assign blame. It is to see what you actually have.
Separate intent from the artefact
Ask what the project was supposed to achieve for the business, who the users were, and what “finished enough” meant. Then look at what exists: running software, partial software, designs, documents, credentials, environments, and the knowledge that only lives in inboxes. The gap between those two pictures is the real project, not the original proposal.
If the commercial intent has moved — a different customer, a different process, a different regulatory demand — finishing the old plan can be a precise way to waste the remaining money.
What to inspect before you touch the code
- Access: source control, hosting, domains, third-party accounts, data stores and admin credentials. If you cannot operate it, you do not own it yet.
- Running reality: what is in production or staging, and whether that matches what people think is live.
- Documentation versus folklore: what is written down, and what only one person can explain.
- Quality signals: tests, deployment path, error handling, and whether a change can be released without heroics.
- Data: where it lives, how sensitive it is, and whether it can be restored.
- Contracts and dependencies: licences, supplier obligations, and anything that expires.
- People: who still understands the history, and who the users actually are now.
Resist the immediate rewrite
A rewrite feels clean. It is also how stalled projects become second stalled projects. If the current system already supports part of the operation, the cheaper path is often to freeze scope, make it operable, and deliver the next slice of value on a known foundation. Rewrite only when the assessment shows that change is unsafe, the architecture cannot carry the remaining need, or the existing artefact does not actually do the job.
Choose the smallest valuable next step
Recovery is a sequence, not a slogan. Stabilise access and deployment. Name the remaining risks. Identify the smallest increment that would make the software more useful to a real user. Put a decision point after that increment: continue, change direction, or stop. Sponsors deserve a commercial picture — remaining cost against remaining value — not a promise that “a bit more work” will finally land it.
Handled this way, a stalled project can still become a working product, a narrower product, or a deliberate stop. All three are better than an expensive continuation that nobody can explain.
