When to stop a project you already committed to

Stopping is the delivery decision least often made on purpose. Committed projects rarely get cancelled. They starve: people are borrowed, the check-ins thin out, the target date passes without comment, and a year later the work is still nominally open. That outcome costs more than a clean stop in every way that matters, and it happens because stopping feels like admitting the commitment was a mistake.

The only question that counts

Sunk cost in engineering has a house style. "We are seventy per cent done." "We have already put four months into this." "The team would be demoralised." Each sentence is about the past, and the past is the one part of the project a decision cannot change.

The question that replaces all of them: knowing what we know today, would we commit the remaining capacity to get the remaining outcome? Treat the unfinished part as a fresh demand arriving this morning, sized by the team as it now understands the work, competing for the same capacity as everything else waiting. If it would clear the bar, continue, and say why. If it would not, the months already spent do not alter the answer. They only make it harder to say.

"Seventy per cent done" deserves particular suspicion. It is nearly always a statement about effort spent against the original estimate, not about work remaining. Ask for the remaining figure instead, in FTE-months, from the delivering team.

Three signals that justify stopping

The outcome no longer matters. The customer the work was for has left. The regulation was delayed or withdrawn. The strategy the demand served changed in the spring. This is the cleanest reason and the one most often missed, because nobody goes back to the requester to ask whether they still want it. The test is cheap: ask the person who was promised the outcome whether they would ask for it again today.

The remaining cost has roughly doubled. Not the total; the remaining. If the commitment was six FTE-months, three are spent, and the team's honest figure for what is left is now six, the organisation is being asked for a different commitment from the one it agreed to. I use "doubled" as an illustrative tripwire, not a law. Pick your own multiple in advance. What matters is that crossing it forces the question above instead of another re-estimate.

A dependency will not land. The other team's platform work was cut. The vendor's API is not coming this year. Legal will not sign. A dependency that was asked for but never confirmed has become one that is confirmed absent, and the work cannot produce its outcome without it. Continuing means building inventory for a day that has no date.

Equally important are the things that are not signals. The work is harder than expected. It is late. The team is tired of it. People are wanted elsewhere. Each of these may be a reason to move a date, cut named scope or change who is on it, and those are different decisions. Lateness alone tells you about the estimate, not about the value of finishing.

Set the kill criteria when you commit

The middle of delivery is the worst vantage point for this judgement. The owner has argued for the work, the team has lived in it for months, and every status conversation rewards optimism. So decide what would stop it before any of that is true.

At commitment time, write one to three conditions under which the work stops or returns for a decision. They should be observable and specific to this piece of work:

• "If the pilot customer has not signed by the end of October, stop."
• "If the team's remaining estimate at the mid-point exceeds the original total, bring it back for a decision."
• "If the identity team's migration is not confirmed by week four, stop and park."

This is the same move as the fourth field of a commitment exception, the condition that would change the decision, applied to every commitment and not only the early ones. Writing it takes two minutes on the day everyone is still clear-headed.

The criteria then need a moment at which they are read. That is what a check-in is for. A status that is a judgement with a reason and not just a colour has somewhere to say "the second condition has been met". A row of green circles does not.

Who stops it, and how

The owner proposes the stop. That is part of what owning a commitment means, and an owner who can only ever report progress is a narrator. The decision is taken with whoever was promised the outcome, since it is their promise being withdrawn, and they hear it from the owner directly, with the reason, before they infer it from silence.

The delivering team's part is to supply the remaining figure and the state of the work. It should not be the team's job to stop a project by attrition, which is what happens when nobody above them will make the call.

Be exact about pause versus stop. A pause is a stop with a review date and a stated condition for resuming. "On hold" without either is a stop nobody recorded, the delivery-stage version of the slow maybe. If you cannot name the date on which you will look again, you have stopped. Say so.

Closing a stopped commitment honestly

A stopped commitment gets a close like any other. The essay on why "delivered" is not an outcome argues for three closes instead of one. This is the third, and it needs four things written down.

The outcome: not delivered. In those words. Not "deprioritised", not "descoped to zero", not left open, and not renamed into a smaller project that can be marked done.

The reason. Which signal, and when it became true. "Stopped in week nine: the identity migration this depended on was cut from the platform plan" is a record. "Priorities changed" is not.

What exists. Partial work has a state: what shipped, if anything; what is sitting in a branch; what would be reusable and what would have to be redone. Someone will propose this work again, and this paragraph is what they will need.

The lesson. About the commitment, not the stop. The useful lesson is rarely "we should have stopped sooner". It is usually about what was known at commitment time: the dependency was never confirmed, the outcome rested on one customer, the estimate was given before anyone had looked at the migration. That is the sentence the next commitment can use, and it is the reason a retrospective should produce one written lesson and not a mood.

Then release the capacity out loud. The FTE-months that were committed return to their teams' lines on a named date, and what they go to next is a decision, not a drift.

A stopped project with a reason on the record is evidence that the organisation can change its mind. Count those separately from misses. Several quarters with no stops at all usually does not mean every commitment was sound. It means the unsound ones are still open.

Where DeliverySheet sits

DeliverySheet will not tell you to stop. It has no scoring formula, no ranked list and no alerts, so the judgement and the conversation stay with the owner. What it does is give a stop somewhere honest to land. When a demand is committed before it is ready, the recorded exception includes the condition that would change the decision. For any commitment, the delivery outcome is recorded as delivered, delivered with exclusions or not delivered, and Learn requires a written lesson before the demand counts as complete.