Go/no-go criteria: when stopping an AI project is a value

Of the dozens of AI project post-mortems we have witnessed, the most recurrent sentence always comes from someone on the team, never from the minutes: "we knew for months". Projects that fail badly, the ones burning eighteen months and the credibility of every subsequent initiative, rarely die of a surprise; they die from the absence of a mechanism turning what the team knows into a decision the organisation takes. That mechanism has an unpoetic name, go/no-go criteria, and its absence is among the most curable failure causes in the whole repertoire.

There is a structural reason why AI projects need it more than others: they are experiments by nature, with uncertain outcomes no planning removes, and an experiment without written stopping conditions is not an experiment, it is an open-ended commitment under another name. The value proposition of serious advisory, we often tell clients, includes the no: an advisor who can only say go is a salesperson with a different business card.

The anatomy of a criterion that works

A go/no-go criterion worthy of the name has four components, and each missing one turns it into a wish. The metric, which must be a business metric or directly linked to one (complaint handling time, user adoption rate, cost per file), never a model metric alone, because brilliant accuracy on a process nobody uses passes every technical threshold and fails anyway. The threshold, with the number written before the start, when nobody yet has interests to defend: above it you proceed, below it the consequence applies. The date, because a threshold without a deadline is a moving finish line, and "one more month and we are there" is the official language of zombie projects. And the decision-maker, one person with a name and signing power, because decisions assigned to a committee have the property of never being taken by anyone.

The fifth component, implicit but decisive, is the moment of writing: criteria are fixed at kickoff, inside the initiative's Canvas, together with sponsor and process owner. Writing them mid-project is already negotiating.

Stop, correct, proceed: three outcomes, not two

The name hides a simplification, because the useful outcomes are three. The go confirms and unlocks the next phase with its budget. The no-go closes, and a closure done well has its ritual: the learnings get documented, reusable data and code get archived, the outcome gets communicated with the same visibility as the launch, because a well-closed experiment is paid-for information that must yield. In between sits the pivot, the course correction with new criteria and a new date, which is legitimate once and becomes obstinacy the second time: the practical rule we suggest is a single pivot per initiative, resolved by the decision-maker, never self-granted by the team.

Criteria, moreover, do not live only at the pilot's end: mature organisations place them at every phase transition, from idea to pilot, from pilot to MVP, from MVP to production, with progressively more demanding thresholds. It is the same principle as critical gates applied to the single project, and it produces the same effect: it moves resources from what promises to what demonstrates.

Making the stop socially possible

The hard part of no-gos is not technical, it is anthropological. Sunk cost weighs ("we have already spent too much to stop now", which is exactly the reasoning that multiplies the spending), the sponsor has exposed their face, the team fears that closing the project means a judgement on the people. An organisation that wants working criteria must defuse this mechanism, and the tools are known: explicitly separating the evaluation of the experiment from the evaluation of the people, publicly celebrating well-executed closures as much as launches, measuring project leaders also on the speed with which they free resources from what does not yield.

In the portfolio, the health signal is counter-intuitive: a physiological share of no-gos says the thresholds were real, while a portfolio where everything always clears every gate tells of criteria written to be cleared. The right question at year end is not how many projects moved forward, it is whether the ones stopped were stopped at the right time.

Decision criteria are among the deliverables of our AI Strategy work, written initiative by initiative inside backlog and roadmap, with thresholds, dates and decision-makers: calendly.com/fabiolalli/zerofive, or hello@zerofive.ai. The test to run today, meanwhile, takes five minutes and one ongoing project: does the condition under which you would stop it exist, written anywhere? And if it materialised tomorrow, who would sign?