Before spending anything more on a project that stalled last year, establish four things: what actually exists and works, what it would cost to finish compared with starting again, who owns the code and the accounts, and whether the problem was the team or the scope. January is when these questions get asked and it is usually the third or fourth time they have been raised.
This guide is for an owner or manager who has a half-finished system, a supplier relationship that has gone quiet, and a decision to make before committing another year's budget.
Key takeaways
- Find out what works before deciding anything: a demonstration of the current system, run by you, not shown to you.
- Scope is the cause more often than the team is, and replacing the team without fixing the scope repeats the year.
- Ownership of code, data and accounts determines your options, so check it before you open the conversation.
- Finishing is usually cheaper than restarting, but only when the existing work can actually be assessed.
Step 1: see what exists, yourself
Ask to use the current system rather than to be shown it. A demonstration follows a path that works. Using it yourself finds the edges.
Three specific things to establish: which user journeys run end to end, which are partially built, and which exist only as screens with nothing behind them. A project that is described as ninety percent complete very often has one complete journey and several that stop at the point where they would have to save something.
Step 2: separate the scope problem from the team problem
These have different fixes and they are frequently confused.
Signs the scope was the problem. Requirements changed repeatedly, decisions took weeks, several people could approve and none could decide, the definition of finished was never written down, and the thing being built kept growing.
Signs the team was the problem. Deadlines moved without explanation, questions were answered vaguely, nobody could show working software for long stretches, and the same issues were reported as fixed more than once.
If it was scope, changing supplier will produce the same result with new people and a new invoice. If it was the team, fixing scope alone will not help. Most stalled projects have some of both, and the honest split matters.
Step 3: check what you own
Before any conversation about continuing, confirm where the code lives and whether you can reach it, whose name is on the hosting, domain and app store accounts, whether you have a current copy of the data, and what the contract says about ownership.
This is not about preparing to leave. It is that every option, finish, pause, hand over, restart, depends on these answers, and finding out mid-negotiation is worse than knowing in advance.
Step 4: get finishing costed against restarting
Ask for two estimates from a party able to give both honestly: what it takes to complete the existing system to a defined scope, and what it takes to build the same defined scope from scratch. Both against the same definition of finished, written down first.
Finishing usually wins, because the unglamorous work of integrations, data models and edge cases is already partly done. Restarting wins when the foundation genuinely cannot support what is needed, and that case should be arguable in specifics rather than asserted.
Be careful with an assessment from whoever would do the rebuild. Ask what specifically cannot be kept and why.
Step 5: restart smaller
Whatever you decide, do not resume at the original scope. Define the smallest version that is genuinely usable by real users, set a date for that and nothing beyond it, and name one person who can make decisions without a meeting.
A stalled project almost never restarts successfully at full size, because the conditions that stalled it are still there.
Related guides
- There is a longer treatment of the same subject in taking over an existing software project.
- Where this gets expensive is covered in the signs a legacy application needs modernization.
- If the pattern is that new products never get started, why the new product never starts covers the cause.
If you want an independent assessment of what exists before committing this year's budget, Discuss Your Plan.
Ali Boran Gazel