Why pilots die

In most established companies there is a graveyard, and it is kept in slide decks. In it lie the pilots that worked. The technology did what was promised, the demo impressed the right people, the summary recommended proceeding. And then, at a speed too slow to notice, nothing happened. Nobody killed the project. Nobody decided against it. It simply never became part of how the company runs, and after enough months the deck stopped being opened.

When this happens with AI, the usual conclusion is that the technology was not ready, and the usual response is to wait a year and pilot again. But the technology mostly did work. The pilot proved that. What failed was everything around it, and that failure has a repeating structure worth taking apart, because none of it is about AI, and all of it will happen again next time.

The pilot answers the wrong question

A pilot is designed to succeed. That sounds like a virtue, and it is the root defect. To give the technology a fair chance, the pilot runs on cleaned data, on the standard cases, with an enthusiast at the controls and the vendor's best engineer one phone call away. All reasonable. And it means the pilot answers the question: can this work under favourable conditions? The answer to that question is almost always yes, and it was known before the pilot started.

The question that decides everything is a different one: will this survive our worst Tuesday? The real data, with its duplicates and empty fields. The order that arrives half in another language. The person operating it who did not choose it and has a queue behind them. Month three, when the novelty is gone and the vendor's engineer has stopped answering quickly. A pilot constructed to succeed cannot answer this question, by construction.

The cliff after the demo

There is also an economic illusion built in. Getting to an impressive demo is roughly a tenth of the work. The other nine tenths is wiring the thing into your actual company: the permissions, the integration with the business system that was customised beyond recognition years ago, the exception handling, the logging, the question of who gets woken up when it fails. None of that demos well, and all of it decides whether the thing lives.

Pilot budgets fund the first tenth and end precisely where the work begins. This is why so many companies have experienced the strange grief of a successful pilot. The funded excitement is over. The unfunded reality has arrived. Waiting for next year's budget, the momentum quietly dies.

Nobody owns month three

A pilot is owned by a champion: an innovation lead, an enthusiastic manager, sometimes the vendor. Production has to be owned by the people who run the process every day, and they were often not in the room when the pilot was designed. So when the system misbehaves in month three, and something always misbehaves in month three, the question becomes: whose job is it to care? If the answer takes more than a second, the outcome is already decided. The operator with a deadline routes around the new system and back to the old way, quietly, one case at a time. The old way never left. It was waiting. Adoption does not fail loudly. It evaporates.

The parallel trap

The most common form of caution is to run the old way and the new way side by side, to be safe. It feels prudent and it is quietly fatal, because it makes the new way optional, and optional things lose to habit almost every time. Under pressure, people flee to the familiar path. Usage falls, so the results look weak, which justifies more caution, which keeps the old way alive. The loop closes itself.

Somewhere there has to be a moment when the new way becomes the way. That moment is a management decision with a date on it, not a technical milestone that arrives on its own. In every dead pilot, nobody ever scheduled it.

What the survivors have in common

The systems that make it into production share a handful of habits, and none of them are technical.

They start inside the process, not next to it. Pick one live slice of the business, one product line, one region, one customer segment, and run there from day one, dirty data included. It will be slower and harder than a lab pilot, and that difficulty is information, not failure. They have an owner from operations before they have a demo, and the builder leaves while the owner stays. If no one in operations will own it, that is a verdict on the project, and it should be believed. They define in advance what result would justify switching off the old way, write it down, and put a date on the decision. And they live inside the tools people already have open all day, because every new tab is a place where adoption goes to die.

Above all, they are judged at month three, not day one. A demo is judged on its best day. A production system earns its life on its worst.

Boring is what production means

The companies that get this right are rarely the most innovative ones. Often they are conspicuously unfashionable. They treat a new system the way they treat a new production line: procedural, owned, measured, and unglamorous. Pilots die of excitement. Production systems live on routine.

And routine is the one competence an established business has in abundance. The same temperament that makes such companies slow to start is exactly what makes a change permanent once it is made. Twenty years of running things reliably is not a handicap in this era. It is the qualification. The pilot was never the hard part, and it was never the point.