Claim a free live session
← The feed
The stall

How to kill a stalled AI pilot without losing the budget

The real fear isn't admitting the pilot failed. It's that killing the pilot reads as killing the mandate. Here's how to separate the two.

Ashruf HassaballaCo-founder · A³6 min read
A moment of concentration during a session on the A³ campus

Nobody keeps a dead pilot alive because they believe in it. They keep it alive because cancelling it means walking into a room and saying the thing the board funded did not work — and the fear, usually correct, is that the mandate goes with it.

Three tests: dead or merely slow

  • Can anyone name the workflow it changes and the number it moves? If not after this long, it was never scoped — that is dead, not slow.
  • Has anyone outside the project team asked for it? Sustained silence from the intended users is the clearest signal available.
  • Is the blocker technical or organisational? Technical blockers get solved by engineering time. Organisational ones do not get solved by more of the same, and this is the distinction that decides it.

How to write the memo

Concede the specific: this configuration, on this workflow, did not reach production, and here is the honest reason. Do not concede the general — nothing about the mandate is invalidated by one badly scoped attempt.

Reframe what was learned as an asset, and be precise about it: you now know the data reality, the governance surface, the operator objections, and which vendor claims do not survive contact. That knowledge cost real money and it transfers to the next attempt. It is the only thing you have to trade.

You are not asking to be forgiven for a failure. You are asking to spend the second attempt better than the first.

Keeping the budget in the department

Ask for reallocation, not for new money — the line already exists and defending it is easier than requesting it. Name the specific change in approach that the reallocation buys, and attach a decision date so the ask has a shape.

What the second attempt should do differently

Name the workflow before choosing the vendor. Measure a baseline in week one. Put the operators in the room from the start. And watch the capability run on a problem shaped like yours before committing anything — which is the step the first attempt almost certainly skipped.

Reading helps. Seeing the capability tested is better.

When you're ready to move from ideas to evidence, bring us the problem and we'll build the right session around it. The first one is free.