How to stop a project well

To stop a project well, decide the stopping conditions before you start, make the decision at a scheduled review rather than in a crisis, tell the team first and in person, write down what was learned, and move people to new work within days. Done this way, stopping becomes a normal part of managing innovation rather than an admission of failure. The steps below work whether you are ending a two-month experiment or a two-year programme.

Why stopping is so hard

Three forces keep projects alive long after they should end.

Sunk cost. The more money and effort already spent, the harder it feels to walk away, even though past spending should not affect a decision about future spending.

Identity. Project owners, and often their sponsors, become personally linked to the project. Stopping it feels like a judgement on them.

No mechanism. In most organisations, projects are approved at a meeting but there is no equivalent meeting to end them. Without a moment of decision, projects fade slowly: fewer people, smaller budgets, no announcement. These are the zombie projects that crowd every portfolio.

The fix for all three is the same: make stopping a designed, expected step, agreed before anyone is attached to the outcome.

Step 1: Write stop criteria at the start

When a project is approved, write down two or three conditions under which it will stop. Annie Duke, in her 2022 book Quit, calls these kill criteria and suggests pairing a state with a date: "if by this date we have not reached this result, we stop".

Good stop criteria:

• Link to the project's riskiest assumption. Use assumption mapping to find it.
• Use a threshold that is set before results arrive, as in any hypothesis test.
• Include a date. "When it stops being useful" is not a criterion.

Example: "If fewer than one in five pilot users complete a second transaction within six weeks, we stop."

Running a premortem at the start helps: when a team imagines the project has failed and lists the reasons, the most likely reasons become natural stop criteria.

Step 2: Make the decision at a scheduled review

Stop decisions made in a crisis feel like punishment. Stop decisions made at a regular portfolio review, against criteria agreed months earlier, feel like process. Bring each project to its review with the stop criteria printed next to the results. The question is not "do we still like this?" but "has it met the conditions we agreed?"

If the criteria were met, the decision is usually easy. If they were missed but the team has learned something that changes the picture, the right move is a new, explicit bet with new criteria, not a quiet extension. See Innovation portfolio management: fund, scale, pause or stop for how the review works.

Step 3: Separate the project from the people

Before the decision is announced, the sponsor should say clearly, to the team and to others: the project is stopping because the evidence did not support it, and the team did the job of finding that out. A team that ran a clean test and reached a clear "no" has done valuable work. It saved the organisation from funding something that would not have worked.

Never let a stopped project appear in a performance review as a failure of its team, unless the team behaved badly (for example, hid results). If people are punished for stopped projects, nobody will report bad news again.

Step 4: Tell people in the right order

Use a short stakeholder communication plan. The usual order:

1. The project team, in person, by the sponsor. Never by email, never by surprise in a large meeting.
2. Partners, pilot users and suppliers who gave their time. Thank them and tell them what happens next.
3. The wider organisation, briefly, framed as a decision made on evidence.

Prepare answers to the three questions people always ask: why now, what happens to me, and what happens to what we built.

Step 5: Keep the learning

Within two weeks, hold a retrospective and write a one-page closing note:

• What we set out to test.
• What we found, with evidence.
• What we would tell the next team working in this area.
• What assets exist (research, code, contacts, prototypes) and where they are kept.

A feedback capture grid is a quick way to structure the retrospective. File the note where future teams will search for it. The most expensive outcome of a stopped project is a new team repeating it three years later.

Step 6: Close it properly

• Close the budget line and release unused funds back to the portfolio.
• Switch off pilot services, with notice to users.
• Return or reassign equipment, licences and data access.
• Remove the project from dashboards and status reports.
• Move every team member to named new work within days, not weeks. People left idle after a stop are the clearest signal to everyone else that stopping is dangerous.

Illustrative example

Illustrative. A city transport authority in Spain had piloted an on-demand minibus service in two outer districts for nine months. When the pilot was approved, the team had agreed two stop criteria: average occupancy above a set level by month six, and cost per trip below that of the bus route it would replace.

At the month-nine review, occupancy had reached the target in one district but not the other, and cost per trip was well above the bus route in both. The portfolio board stopped the service. The director told the team in person the same afternoon and named the work each would move to. Riders received four weeks' notice and a letter explaining the alternatives.

The closing note recorded something the pilot had not set out to find: most trips in the stronger district were by older residents travelling to one health centre. That insight was handed to the team redesigning that district's regular bus routes, which added a stop at the centre.

Do's and don'ts

Do

• Agree stop criteria before the project starts, with dates.
• Make stop decisions at scheduled reviews.
• Thank the team publicly for producing a clear answer.
• Write the closing note within two weeks.
• Reassign people quickly.

Don't

• Don't let projects fade by starving them of resources. Make the decision visible.
• Don't extend a project that missed its criteria without setting new ones.
• Don't announce a stop by email.
• Don't treat a stopped project as a black mark on the people who ran it.
• Don't throw away what was built. Record where it is.

Questions people ask

When should you kill a project? When it misses the stop criteria you agreed at the start, or when the strategy it served has changed. If you never set criteria, the next best signal is a project that can no longer name the assumption it is testing.

How do you tell a team their project is being cancelled? In person, from the sponsor, before anyone else hears. Explain the evidence, make clear the team is not being blamed, and tell each person what they will work on next.

What is the difference between pausing and stopping a project? A pause keeps the project on file with a written condition for restarting, such as a regulation coming into force. A pause without a restart condition is a stop that nobody wanted to announce.

Where to go next

Stopping is part of a wider strategy cycle; see the pillar How to build an innovation strategy in a few workshops. The guides used here are free: premortem, assumption mapping, retrospective and stakeholder communication plan.