When to stop a digital transformation project

Projects rarely get stopped. The reason is simpler than office politics. In most cases, nobody wrote down what done would look like.

A project with no definition of done cannot fail. It continues and wastes nerves and resources.

This piece is for leaders who approve digital investments and have at least one initiative they suspect should have ended already. We will cover why stopping is harder than starting, why scope and done are different things, and the stop conditions you can write at kickoff when nobody is yet invested in continuing.

Key Takeaways

• Companies build elaborate machinery for approving projects and almost none for stopping them.
• Scope describes what gets built. Done describes what changes in the business. Most projects define only the first.
• PMI’s 2026 research found 31% of complex projects fail to achieve the full scope of their intended benefits, which means a project can be delivered and still fail.
• A definition of done works best as a single north star metric, agreed upon by every department that will be affected.
• Stop conditions must be observable by someone who was not in the room when they were written.
• Stopping is not the only exit. Kill, park, and reshape are three different decisions.

Why stopping digital transformation is harder than starting

Stopping is a decision made by people with a budget spent. Reputation is also on the line for a team and leaders that have worked hard.

McKinsey’s work on decision biases describes this mechanism. When assessing a project, managers give more weight to the costs already incurred than to the costs still to come. Their recommended fix is structural, since organisations need a mechanism that takes some of the emotion out of resource-allocation decisions.

The mechanism is a standard written before anyone is attached to the outcome.

Without that standard, every stop conversation becomes an argument about opinions. One person thinks it is struggling, another thinks it needs more time, and the most senior or most confident voice decides.

The project then continues by default, because continuing requires nobody to be wrong.

Scope is not the same as done

Scope is what gets built. This could be a portal with these screens or defined user roles. Scope is written carefully because it goes in the contract.

Done is what changes in the business. The handover that took three days now takes three hours. The team that spent half its week reconciling spreadsheets stops doing that. 

Scope completion is easy to verify. Done is the part that most companies don’t write down. 

The newest data makes this concrete. PMI’s 2026 Pulse of the Profession found that 31% of complex projects fail to achieve the full scope of their intended benefits, compared to 12% for projects that are not complex.

Read that definition of failure closely. A project can hit every milestone and still land in that 31%.

The same research found that 61% of complex projects experienced value and alignment gaps, where the project delivered outputs while losing sight of outcomes. 

The north star metric, and who has to agree on it

North Star is essential, but the hard part is getting agreement on it because the pain looks different in each department.

• Finance wants the cost per transaction down. 
• Operations wants the backlog cleared.
• Customer service wants fewer escalations. 
• IT wants the legacy system retired. 

All four can be true at once. All four can be used, months later, as evidence that the project is or is not working.

When those definitions are never reconciled, the project cannot be declared as done by anyone. In fact, it absorbs requests until the budget runs out. That is the mechanism behind a great many digital projects that simply never end.

PMI’s research shared above supports this directly. It attributes scope change less to unclear requirements and more to organisational factors. 

The fix for that is one agreed number that several departments have signed up to before the work starts.

This is the same discipline we described in minimum viable data, applied to success rather than to fields. If two teams measure the metric differently, you do not have a north star. 

Stop conditions you can write at kickoff

Once done is defined, stop conditions become possible. There is finally a standard to measure against.

Write them at kickoff.

That is the only moment when stopping is politically cheap, nobody is attached to the outcome, and everyone can be honest about what would make this a bad idea. It belongs in the same conversation as the analysis phase, where the uncomfortable questions are cheapest to answer.

Six conditions cover most situations.

1. The north star metric has not moved by the agreed checkpoint. A specific number, at a specific date. Set two checkpoints rather than one, so you can see direction instead of a single reading.

2. The pain has changed or gone away. The problem got solved another way, deprioritised, or made irrelevant by a market or regulatory shift. This happens more often than people expect, and almost nobody is assigned to notice it.

3. The founding assumption proved false. Every project rests on a premise. Write it as one sentence at kickoff, and write what evidence would disprove it. “This assumes order history is complete back to 2022” is testable. “This assumes good data” is not.

4. The named owner is gone. The business owner left, changed role, or has stopped attending. A project without an engaged owner has already stopped, as we argued in the piece on ownership. It simply has not been told yet.

5. Accumulated changes have passed an agreed threshold. Set a percentage of original scope at kickoff. Past that line, the work goes back for re-approval as a new project rather than continuing on momentum. This is the governance answer to the drift described in the hidden cost of small changes.

6. The cost to finish exceeds the remaining value. Forward-looking only. Money already spent stays out of this calculation, which is precisely the bias that makes the calculation hard.

The test that makes these useful: every stop condition must be observable by someone who was not in the room when it was written.

“If things are not going well” fails that test. “If average handling time has not fallen below nine minutes by 31 March” passes it.

Three ways to stop

Stopping is rarely binary, and treating it that way is why organisations avoid the conversation. Give leaders three doors.

• Kill. The need is gone, or the approach was wrong. Close it properly and write down what was learned, so the organisation keeps something.
• Park. The need is real but a precondition is missing, usually data quality or a named owner. Park it with a written re-entry condition. A project parked without one becomes a zombie that reappears every budget cycle.
• Reshape. The need is real and the solution was oversized. Come back with a smaller version aimed at the same metric.

Most projects that should be stopped actually need parking or reshaping. Offering only kill or continue is what pushes organisations into continue.

Stopping well is a capability

A word of caution, because this argument can be misread. Stopping too early is also a failure mode, and the middle of a build is supposed to feel difficult. Difficulty is not a stop condition. Discomfort is not a stop condition. A falsified assumption is, and so is a flat metric at an agreed checkpoint. That distinction only holds if the conditions were written before the difficulty arrived.

We have argued before that companies should stop buying projects and start building capability. Knowing when to stop is part of that capability, and it is among the least developed parts in most organisations.

A portfolio that never stops anything is not disciplined. It is slow to admit things, and the cost shows up as capable people maintaining systems that stopped mattering a year ago.

So at the next kickoff, before the budget is approved, ask two questions. What is the one number that tells us this worked. And what would we need to see to agree that it is not working.

If nobody can answer the second question, you have not approved a project. You have approved an obligation.