How to Kill an AI Project Without Damaging the Programme

Projects that should stop rarely do, because stopping requires someone to say so and nobody wants to declare failure. This playbook covers stopping cleanly and keeping what was learned, drawing on FISTA Solutions' AI enablement work.

When is this worth doing?

When the stopping criteria set at the start have been met, or when the signals are present and no criteria were set.

It is better done early. A project stopped at the point the evidence became clear costs a fraction of one that continues with reduced ambition for another two quarters.

What does the sequence look like?

Step	Purpose
1. Check against the criteria	Set at the start, if they exist
2. Test the signals honestly	Ceiling, data, benefit, ownership
3. Decide with the sponsor	Not by attrition
4. Capture what is reusable	Before the team disperses
5. Communicate as a decision	With what was learned
6. Reuse it visibly	So the learning is real

Step 1 — Check against the stopping criteria

If the business case stated what result would prove it wrong, compare against that.

This is why stopping criteria are worth writing at the start: they convert an emotional decision into a check. A project that hit its stated failure condition can be stopped without anyone arguing about judgement.

Where no criteria exist, say so and set them now for the remaining period rather than continuing indefinitely on impression. See how to write an ai business case.

Step 2 — Test the signals honestly

A quality ceiling below what the use case needs, despite genuine effort. Data that does not support the task and cannot be obtained. No measurable benefit after a fair trial. The problem having changed. Nobody willing to own the result in production.

Any of those is sufficient. The last one is the most telling and the least discussed: a system nobody will take responsibility for in production should not reach production.

Be honest about whether the effort was genuine. Stopping because the first approach did not work is premature; stopping after a serious attempt is not.

Step 3 — Decide with the sponsor, not by attrition

Projects usually stop by fading: the team is reassigned, the meetings stop, and nobody declares anything.

That is the worst outcome. It leaves the question open, wastes the opportunity to capture learning, and produces a portfolio full of things that are neither running nor stopped.

Make it a decision with a date, taken by the sponsor, recorded. Uncomfortable for an afternoon and considerably better for everyone afterwards.

Step 4 — Capture what is reusable

The evaluation set, the data preparation work, the documented decisions, and the honest account of why it did not work.

These are frequently worth more than the code. An evaluation set built for a failed project describes what the task actually required, and the next attempt starts from it rather than from nothing.

Do this before the team disperses. Knowledge walks out the door within weeks, and reconstructing it later is not possible.

Step 5 — Communicate it as a decision

Say what was tried, what was learned, why it is stopping, and what is being kept.

Framing it as a failure damages the people involved and makes the next AI proposal harder to fund, which is a cost that outlasts the project by years.

Organisations that stop things cleanly and say why develop a reputation for honest reporting, which makes future funding easier. Those that let projects fade develop a reputation for not knowing what is happening.

Step 6 — Reuse what you kept, visibly

Use the evaluation set, the cleaned data, and the documented decisions on the next attempt, and say that you are.

That makes the learning real rather than rhetorical. A team that hears the previous project's work being reused understands that stopping produced something.

It also validates the decision to capture it, which makes the next stop easier to do properly.

What about partially successful projects?

Narrow rather than stop. A system that works on a subset of cases and not the whole scope is frequently worth shipping for the subset.

That is a different decision from stopping and it is often the right one. The trap is continuing at full scope while quietly serving only the subset, which produces a system whose actual coverage nobody has stated.

Say explicitly what it does and does not cover, and ship that.

How do you protect the people involved?

By attributing the decision to evidence rather than to performance, and by moving them to work that matters.

People who worked on something that stopped are frequently the most experienced in the organisation about what does not work, which is valuable. Treating them as associated with failure loses that and teaches everyone else to avoid honest reporting.

How the organisation treats them is watched closely and determines whether anyone raises a concern early next time.

Who needs to be involved?

The sponsor who owns the decision, the team lead, and someone to capture the learning who is not emotionally invested.

The last role matters. The people closest to a project are the least able to write an honest account of why it did not work, which is not a criticism of them.

How long does it take?

A decision within days once the evidence is clear, plus one to two weeks to capture what is reusable properly.

What are the common failure modes?

Continuing on sunk cost. Stopping by attrition. Dispersing the team before capturing learning. Framing it as failure. And never reusing what was kept.

How do you know it worked?

A recorded decision with a date, reusable artefacts captured, the learning applied to the next attempt, and the people involved working on something that matters.

What does it cost?

Mostly people's time rather than tooling. The expensive version is the one that stalls halfway and leaves the organisation with neither the old state nor the new one, which is why a narrow first pass beats a comprehensive plan nobody finishes.

Budget the work as an operated change rather than a project with an end date, because most of these need a maintenance tail. See AI total cost of ownership.

What should you do first?

Write down what result would make you stop, if nobody has. That single sentence makes the decision possible later.

How FISTA Solutions helps

FISTA Solutions runs this work alongside client teams rather than around them: stopping criteria set at the start so decisions rest on evidence, evaluation sets and data work captured before teams disperse, evidence produced as the work proceeds, and handover that leaves your people able to continue without us. Delivery runs through AI agents, AI enablement, and forward deployed engineers. The record is 150+ projects for 50+ companies across 12+ countries, with 47% average efficiency gains where measured.

To run this with support, message FISTA on WhatsApp, or read how to recover a failing AI project.