Stopping is a decision, and it is usually made too late
Every organization has a project that everyone privately believes will not deliver, and which is still funded. It rarely survives because someone is defending it. It survives because stopping requires a named person to make an unpopular decision on a Tuesday, and continuing requires nobody to do anything at all. The default costs money quietly, so it wins.
The cost of a late stop is not only the extra spend. It is the team held on work that is going nowhere, the internal experts whose hours are consumed, and the opportunity left unfunded because the budget is committed. A project stopped in month four with a written record of what was learned is a respectable outcome. The same project stopped in month eleven, after two rescues and a relaunch, is a different kind of event.
This is written by a firm that gets paid to build things, which makes it worth stating plainly: the advice below sometimes ends an engagement we are being paid for. We think a vendor who cannot say stop is worth less than one who can, and buyers should hold everyone they hire to that.
You are probably here because
- The status has said ninety percent for six weeks
- The sponsor who wanted this has moved on, and nobody has re-asked the question
- You are being asked to approve more budget and cannot articulate why you hesitate
- Everyone in the room agrees it is struggling and nobody has said the word
The test below takes about an hour and produces a decision that can be written down and defended.
The only test that survives scrutiny
Compare the remaining cost with the remaining value. Nothing else. The money already spent is gone under every possible decision, so it has no bearing on which one is best, and any argument that begins “we have already invested” is a statement about feelings rather than economics.
Has the reason to build it changed? The most common cause of a project that should stop is not technical difficulty. It is that the world moved. The regulation was delayed, the acquisition happened, the process it was going to automate got outsourced, the sponsor left and the successor has different priorities. The build may be going perfectly well and be aimed at a target that no longer exists.
Is the remaining cost worth the remaining value? Estimate honestly what is left to spend — including your own people, not just the invoice — and what the thing is worth once it works. If the answer is no, stop. If the answer is yes only under the best case, that is also a no, because software rarely comes in under the best case.
Where is the failure — problem, approach, or execution? These have three different remedies and they get confused constantly. If the problem is not solvable as posed, stop. If the approach is wrong, change the approach, which is usually a descope rather than an ending. If the execution is poor, change the team, which is a different conversation and should not be dressed up as a strategic reassessment.
Four exits, and most people only consider two
Stop and continue are the loud options. Two quieter ones are usually better and get skipped because they require a more precise diagnosis.
Descope. Ship the part that works and abandon the part that does not. The most frequent misdiagnosis we see is a project killed whole when sixty percent of its value sat in a component that was nearly done. Ask what could be delivered in four weeks if the rest were dropped today. The answer is often surprisingly good.
Pause with conditions. Legitimate only when the blocker is external, dated and specific — a system migration finishing in the spring, a data source arriving after a merger closes. Write the condition and the review date down. A pause without a written condition is a slow cancellation that continues to consume attention.
Change the team. Appropriate when the problem is tractable, the approach is sound, and the delivery is not. It is a real option and it should be named honestly rather than laundered as a change of direction, because the second version teaches your organization nothing.
Stop. The right answer when the reason to build has gone, or when remaining cost exceeds remaining value under reasonable assumptions. Done properly it is fast, written down, and includes a harvest.
Six signals that justify stopping
None of these is decisive alone. Two together is a conversation; three is usually an answer.
The sponsor changed and nobody re-asked the question. Projects inherit their justification from a person. When that person leaves, the justification should be re-established explicitly, and frequently it cannot be.
The success measure was never defined, or keeps moving. If nobody can state the number or the observable behaviour that would mean this worked, the project cannot succeed, because success has no definition. A measure that is redefined after each disappointing result is the same problem in motion.
Every status is ninety percent. A schedule where the remaining work never shrinks means the estimate is being made from the wrong model of the work. Ask for the list of remaining items with hours against each; if it cannot be produced in a day, the ninety was not measured.
Scope grows with every answered question. Healthy discovery converges: you learn things and the remaining unknowns reduce. When each answer opens two new requirements, the problem is not understood well enough to be under contract yet.
Nobody can name who uses it on Monday. Ask which named person will use this in their job in the first week after launch, and what they will stop doing. Vagueness here predicts non-adoption more reliably than any technical signal.
The demo is always next week. Three consecutive slips of a demonstration, with reasons each time, is a different thing from one slip. Working software is the only status report that cannot be written optimistically.
How predictive each signal is, in our experience
Our judgment, not a study. Note the last row: cost overrun is the signal that gets acted on and the weakest predictor on the list.
Four things that look like failure and are not
Stopping a healthy project is a real error and it happens, usually after a bad month or a hostile review.
An estimate revision. A team that revises upward on new evidence is doing the job. The warning sign is a team that never revises, not one that does.
An unpleasant discovery about your own systems. Finding that a critical table has been silently wrong for two years is bad news about the business and good news about the project, which just paid for itself in diagnosis. Do not shoot the messenger and then rehire someone else to find the same thing.
An early quality number that disappoints. First results on hard problems are usually poor. What matters is the trajectory across two or three cycles and whether the team can explain the errors. No movement after several honest attempts is different, and that is a real signal.
Friction between the teams. Uncomfortable, and usually a sign that real constraints are surfacing. Silence is worse. Judge whether disagreements are about substance and get resolved, not whether they occur.
The stop meeting
Make it a decision meeting with an owner, not a review. One page prepared in advance, containing five things: what was intended, what exists today, what remains to be spent including internal time, what it is worth if completed, and the recommendation with a named decision-maker. Ninety minutes.
Two mechanics keep it honest. Have someone argue the opposite case deliberately — if the recommendation is stop, one person is assigned to make the strongest case for continuing, and vice versa. And decide in the room. A stop decision deferred for further analysis is nearly always a continue decision that nobody had to sign.
| When you stop | What it typically costs | What you keep |
|---|---|---|
| During discovery | Discovery fee, a few weeks of internal time | A written assessment; the data findings; the decision |
| End of a first increment | The increment, plus notice period | Working component, data pipeline, evaluation set |
| Mid-build | Work in progress, some of it unusable alone | Whatever was completed to a shippable state, if any |
| Just before launch | Nearly the full cost, plus the rollout not done | An asset nobody operates, which decays quickly |
The table argues for milestone structure more than for early pessimism. A project cut into increments that each end in something usable can be stopped at four points with most of its value banked. One structured as a single delivery at the end can only be stopped by writing off everything, which is why such projects rarely are.
A stop decision in five working days
From doubt to a written decision
Five days is deliberate. A stop question left open for a month is answered by the calendar, because the team keeps billing while the analysis runs. If the decision genuinely needs more evidence, name the evidence and its date, and reduce the burn rate meanwhile rather than leaving it at full.
Harvest before the team disperses
The window is short. Two weeks after a stop, the engineers are on other work and the knowledge is gone. Spend three to five days of the wind-down on the following and you will recover a meaningful fraction of the spend.
The data work. Cleaning, joining and reconciling your sources is usually the largest hidden cost of any project and it is the most reusable thing produced. Keep the pipelines, the mappings and the notes on which source wins a conflict.
The evaluation set. If someone assembled a labelled set of examples with correct answers, that asset outlives the project and is expensive to rebuild. It is the first thing the next attempt will need.
The written record of why it stopped. Two pages: what was tried, what was learned, what would have to be true for this to work later. Without it your organization funds a near-identical project within eighteen months, because nothing prevents it.
The access and environment documentation. Somebody spent weeks discovering how to get at your systems. Write it down.
Contract mechanics, briefly
Read the termination clause before the meeting, not after. Time-and-materials arrangements usually stop cleanly with a short notice period. Fixed-price arrangements need care: a termination-for-convenience provision typically obliges payment for work completed and sometimes for committed capacity, and there may be a minimum. Neither is a reason to continue a project that should end; it is a number that belongs in the remaining-cost calculation.
Three practical items. Get the code, models, prompts and documentation into your own repository before the last day. Get data deletion from the vendor’s environments confirmed in writing. And reserve a small block of transition hours — ten to twenty — for the following month, because questions always arrive after the team has gone.
What the vendor should be doing
The vendor sees the signals first. They know whether the remaining work list is honest and whether the approach is converging. They are also being paid to continue, which is a conflict worth naming rather than pretending away.
The behaviour to look for is a vendor who brings you the bad news before you ask for it, with options attached rather than only a problem: what could be delivered if the scope halved, what would have to be true to continue, what they would do in your position. A vendor who resists a stop conversation, or who responds by proposing a larger phase two, has told you what they are optimizing for. Judge them on the month they lose revenue, not the month they win it.
The mistakes we are called in to fix
- Killing a whole project when the working sixty percent could have shipped in a month
- A pause with no written condition and no review date, which is a cancellation nobody signed
- Re-staffing sold as a change of direction, so the organization learns nothing from it
- Stopping with no harvest, losing the data work and the evaluation set with the team
- One delivery at the end, leaving no point at which stopping banks any value
- The same project refunded eighteen months later, because nobody wrote down why it stopped
- A decision deferred for more analysis, which funded two more quarters by default
Before you decide
- Remaining cost estimated including your own people’s time
- Remaining value stated as a number or an observable outcome
- The failure located: problem, approach, or execution
- Descope considered explicitly — what ships in four weeks if the rest is dropped
- A named person will make the call, in the meeting, on the day
- Somebody assigned to argue the opposite case
- Harvest planned: data work, evaluation set, written record, access notes
- Termination terms read, and transition hours reserved
Bottom line
Compare remaining cost with remaining value, and ignore what has been spent. Locate the failure precisely, because a problem that is unsolvable, an approach that is wrong and a team that is underperforming look identical from a status report and need three different answers. Consider descoping before stopping; it is the most commonly missed option and often the best one. Then decide in the room, harvest the reusable work in the same week, and write down what was learned so your organization does not buy the same lesson twice. A stop taken early and cleanly is not a failed project. It is a funded question that got answered.
Frequently asked questions
Difficulty shows up as slower progress on a converging problem: the remaining unknowns shrink, the estimate is revised once with reasons, the team can explain what is hard. A project that should stop looks different — the unknowns grow, the success measure moves, and nobody can name who will use the result. Judge the direction of the unknowns, not the mood.
Yes, and read the answer with their incentive in mind. The useful question is not “should we continue” but “what would you deliver if the budget halved tomorrow, and what would you drop first?” That produces a ranked view of value that is hard to give evasively, and it tells you whether a descope exists.
It usually does, which is why the default is to continue and why the cost of that default is invisible. The counter is structural rather than personal: build gates into the plan at the start with pre-agreed criteria, so that stopping at a gate is the plan working rather than an individual’s judgment being overturned.
Cheaply, only if you harvested. With the data pipelines, the evaluation set, the environment documentation and a written record of what was tried, a restart can pick up at perhaps half the original cost. Without them it is a fresh start with a worse reputation, and the second attempt is usually harder to fund than the first.
Typically two to four weeks under a time-and-materials arrangement, and whatever the termination clause specifies otherwise. Give the honest notice rather than the minimum; a team told early will spend the remaining time on handover and harvest, and a team told on a Friday will spend it on their next assignment.