When do you stop?

Not because the data is missing. But because the question was never formally asked.

The agreement nobody wants to make

Stop criteria are the conditions under which a project should be ended, paused, or fundamentally redirected - before the next investment decision is made. They are not risk flags. Not KPIs. But explicitly pre-agreed thresholds: If this happens, we stop.

The reason organisations resist writing them down is simple: agreeing on stop criteria feels like planning your own failure. Institutional optimism - God bless it - prefers to wait until the problem is impossible to ignore. Which is exactly how teams end up six months behind schedule, still debating whether the project is really in trouble.

Stop criteria must be defined before further investment is approved - not after. Once the money is spent, a different cognitive mechanism takes over.

Three Examples Worth Studying

1. Technology readiness threshold not reached by Gate 2
   A hardware development team agrees: if the core component cannot demonstrate TRL 5 by the second gate, the project does not advance. This is not a soft target. It is a gate condition. The team knows it, the steering committee knows it, and the budget owner has signed off on it. When TRL 4 is the result, the conversation is uncomfortable but short.

   
   

2. Market signal fails to materialise
   A new service concept is tested with a defined pilot group. The stop criterion: if fewer than a pre-agreed proportion of participants indicate intent to pay within the pilot window, the concept is retired. Not refined, not relaunched - retired, unless a new hypothesis warrants a new mandate.

   
   

3. Strategic fit lost due to external shift
   A project is launched under one strategic assumption. The stop criterion: if a defined external condition changes - regulatory, competitive, or market-structural - the project
   is automatically surfaced for gate review, regardless of its scheduled timeline. The project does not drift forward on inertia.

In all three cases, the stop criterion was agreed at the start of the phase, not negotiated at the end of it. That is the entire point.

The Sunk Cost Problem at the Gate

Here is what actually happens without stop criteria.

A project arrives at the gate. It has consumed significant resources. The team has worked hard. The sponsor is personally invested. The deck is optimistic. And the gatekeepers, looking at everything that has already been spent, find it very difficult to
say: this is not working.

This is the sunk cost fallacy operating at institutional scale. It is not a character flaw — it is a systematic bias that affects even experienced decision-makers. The money already spent is not a reason to continue. It is a reason to be more rigorous about whether continuing is justified.

Stop criteria do not eliminate this pressure. But they shift the conversation. Instead of "Can we justify stopping?", the question becomes "Have we hit the conditions we already agreed would trigger a stop?" That is a structurally different conversation - and a much more honest one.

When the Trigger Fires: Don’t Wait for the Gate

Stop criteria are only as effective as the escalation mechanism behind them. A common and costly misreading is this: the project team recognises that a stop criterion has been met - or is about to be met - and continues running until the next scheduled gate review. By then, weeks or months of additional investment have been committed, and the room to manoeuvre has shrunk considerably.

The rule is straightforward: as soon as a predefined stop trigger is identified, the project team is obligated to convene a Red-Flag Gate - an unscheduled, immediate gate review triggered by the event itself, not by the calendar. This is not optional. It is the
mechanism that gives stop criteria their teeth.

More importantly: escalation should happen before the stop criterion is fully met, not after. If the trajectory is clear - if the data already shows that the threshold will not be reached - the project team should escalate immediately. Early escalation preserves options. Late escalation confirms a fait accompli.

The Red-Flag Gate is not a failure. It is the system working as designed. A project that escalates early and is redirected or stopped with room to spare is a project that was managed well. A project that drifts past its own stop criteria because nobody called the gate is a project that was managed by inertia.

What to Do Now

Take one currently active project. Write one stop criterion for it - not a KPI, not a risk, but a genuine threshold: if X is not achieved by Y, the project does not proceed without a new mandate.

Share it with your steering committee before the next gate. See what the conversation reveals.

five is group works with innovation leaders and R&D organisations on structured gate decision-making. If this topic is relevant to your current portfolio, we should talk.

Picture is AI-generated.