We are called into these regularly: a project months past its date, a client who no longer trusts the estimates, a team that says it is nearly done and has said so for some time. Emotions are high and the instinct is to make a large decision quickly.

That instinct is worth resisting for about two weeks, because the large decision — continue, replace, restart — depends entirely on facts that are usually not established yet.

First, find out what actually exists

The most reliable signal is not the status report. It is the software.

Ask to deploy the current state to a fresh environment and use it. Not a demonstration by the team — your own hands, on a clean deployment, from the repository. This single exercise is remarkably informative.

If it can be deployed and the working parts genuinely work, you have an asset, and the problem is scope, sequencing or communication. If it cannot be deployed at all, or only runs on one developer's machine with manual steps, that is a different situation and a much more serious one.

Second, find out why it is late

The answer given is usually "the requirements kept changing" or "it turned out to be more complex". Both may be true and neither is actionable. The causes we actually find, in rough order of frequency:

  • The scope was never fixed. Nobody wrote down what "done" means, so every review adds work and the end recedes at the rate of progress.
  • An integration turned out to be much harder than assumed. Often the real cause hiding behind the stated ones, and often still unresolved.
  • There is no automated testing. Each new feature breaks two old ones, and the team spends its time on regressions rather than progress. This produces the characteristic pattern of being "ninety per cent done" for months.
  • Data migration was left until the end. The real data is messier than the sample, and this is discovered with no time left.
  • One person is the bottleneck. Everything routes through an individual who is now the constraint on everything.

These have different remedies, which is why the diagnosis matters more than the decision.

Third, measure the technical debt honestly

Get an independent read of the codebase: structure, test coverage, dependency currency, how deployment works, whether secrets are handled properly, whether anyone could pick it up.

The purpose is not to grade the previous team. It is to answer one question — is this a foundation or a liability? A codebase that is unfashionable but coherent and tested is worth continuing. One with no tests, no deployment process and no one who understands it is a sunk cost regardless of what was spent.

That word is worth dwelling on. Money already spent should have no influence on the decision. The only question is which path is cheapest from today.

Then choose, on evidence

Continue with the existing team when the code is sound and the problem is process. Fix the process: freeze the scope to a written list, deploy something to a real environment weekly, add tests around whatever keeps breaking, and remove the bottleneck. Most stalled projects are here, and most are recoverable.

Change supplier, keep the code when the codebase is workable but the relationship or the capability is not. Budget four to eight weeks for a new team to become genuinely productive in an unfamiliar codebase, and insist on a proper handover — repository, infrastructure access, documentation and a working local setup — before the old arrangement ends.

Restart when there is no deployment, no tests, no documentation and no one who understands it. This is less common than frustration makes it feel, and the honest version of the decision includes the fact that the second attempt will encounter the same requirements that defeated the first. Restart with the discovery you did not do the first time.

What to change on day one, whichever path

  • A written scope for the next release only. Not the whole product. One release, small enough to complete, with an explicit list of what is excluded.
  • Weekly working software. Deployed to an environment you can reach, every week, no exceptions. This replaces reported progress with observed progress and it is the single most effective change available.
  • A definition of done that includes tested and deployed, agreed by both sides.
  • One person who decides. Stalled projects usually have several people who can add scope and nobody who can refuse it.

The uncomfortable part

In a good number of these, the supplier is not the main problem. Requirements that changed every fortnight, decisions that took three weeks each, an internal team that could not free the person who knew the existing system — these are client-side causes, and changing supplier without changing them produces a second late project.

The two-week diagnosis is uncomfortable for the same reason it is useful: it does not only assess the code.