Stop rule

A stop rule is an explicit condition that says when an initiative, project, process or decision path must be paused, revised or stopped. It exists to prevent inertia from carrying work forward after evidence has shown that the current path no longer makes sense.

In brief

Organisations are usually better at starting than stopping. In SMEs, this is especially visible: projects remain open, experiments become habits, temporary exceptions become permanent, and initiatives continue because stopping would require a decision nobody owns.

A stop rule makes stopping legitimate before fatigue, conflict or sunk cost makes it unavoidable.

It is not pessimism. It is governance. The rule protects resources, attention and optionality.

Operational definition

A stop rule has four components.

A condition: the measurable or observable signal that triggers review.

A threshold: how much deviation, delay, cost, risk or non-adoption is enough to activate the rule.

An owner: the role authorised to stop, pause or redesign the initiative.

A consequence: what happens when the rule is triggered.

Without all four, a stop rule is only a warning. With all four, it becomes part of the decision architecture.

Why it matters for SMEs

SMEs have limited managerial bandwidth. Every open initiative consumes attention, even when nobody admits it. When projects continue without a stop rule, the company accumulates organisational debt.

The founder often becomes the only person allowed to stop things. This creates delay and emotional pressure. People keep low-value work alive because stopping it feels like failure or disobedience.

A stop rule changes the meaning of stopping. It becomes execution of a prior agreement, not a personal judgement.

For investors and buyers, stop rules show managerial maturity. A company that knows what not to continue is less likely to burn capital through uncontrolled initiatives.

Observable signals

Look for projects that are always “almost done”.

Look for pilots that never become either a standard or a closed experiment.

Look for meetings where the same initiative is discussed without progress.

Look for tools bought but not adopted, while the company avoids declaring the outcome.

Look for exceptions that became normal practice without review.

Look for work continuing because “we already invested too much”.

Common mistakes

The first mistake is defining stop rules after the problem appears. At that point, the discussion is already emotional. Stop rules should be defined at the beginning.

The second mistake is using vague conditions: “if it does not work”. A useful rule says what “not working” means.

The third mistake is giving everyone the responsibility to stop and nobody the authority. The owner must be explicit.

The fourth mistake is treating a stop as failure. A stopped initiative may be the best decision the system makes if the evidence says the path is wrong.

Operational example

A company launches a CRM adoption project. In previous software projects, tools remained half-used for months because nobody wanted to declare failure.

This time, the company defines stop rules at launch. If after 60 days fewer than 80% of new opportunities are entered within 48 hours, the project pauses. If two sales roles bypass the tool for two consecutive weeks, the workflow is reviewed before more features are configured. The sales director owns the stop decision, not the software provider.

At day 60, adoption is 62%. The rule triggers a pause. The review shows that the opportunity stages do not match the real sales process. The company redesigns the stages before adding automation.

The project is delayed by three weeks, but avoids six months of false adoption.

Diagnostic questions

Which current initiatives have no explicit stop condition?

Which projects continue mainly because they already started?

Who is authorised to pause or close an initiative?

What evidence would make the company revise the path?

Which exceptions have become permanent without a decision?

What would be freed if low-value open work were closed?

Practical implications

Write stop rules at the start of initiatives, pilots, change programs and system implementations.

Use observable conditions: adoption rate, lead time, data quality, cost threshold, missed dependency, lack of owner, repeated bypass.

Attach each rule to a review moment. A stop rule without a review date is rarely used.

Make the consequence explicit: stop, pause, redesign, escalate, reduce scope or run another test.

MARTRO reading

In MARTRO’s reading, stop rules protect optionality. They prevent the organisation from continuing paths that close future choices without producing evidence of value.

They also connect governance with cognitive margin. Every open initiative consumes attention. Stopping low-value work is often the first way to create room for change that matters.

When to go deeper

Go deeper when projects stay open without progress, when pilots never close, when software adoption remains ambiguous, or when the company has too many initiatives and no mechanism for stopping.

Natural next steps are decision rights, decision latency, door-closing decision and 30-60-90 change programs.

Frequently asked questions

Is a stop rule the same as a deadline? No. A deadline says when something should be done. A stop rule says which evidence requires stopping, pausing or redesigning.

When should a stop rule be written? At the beginning, before sunk cost and politics make stopping difficult.

Does a stop rule make people less committed? No. It makes commitment more intelligent by clarifying what evidence will change the path.

Who should own the stop decision? The role with authority over the initiative and enough proximity to the evidence. It should not be left implicit.

Can a stop rule lead to continuation? Yes. The rule triggers review. The review may confirm continuation, but with evidence rather than inertia.