From pilot to production: the crossing most never make
Organisations run pilots readily, which is a real advantage, and a large share of those pilots never become anything. The reason is usually structural rather than a failure of execution: the pilot was designed to prove that the technology can work, in conditions chosen to make that likely, and the technology working was never the uncertain part. Clean exported data, a narrow slice, a cooperative team, no integration and no security review. Every one of those choices is correct for answering the question being asked. Every one of them also removes exactly the difficulty that decides whether a system reaches production. So the pilot succeeds, the report is positive, and the project stops, because the work between that result and a system people use was never started and now has to be justified from scratch.
The four things that block the crossing
Data access that was never really obtained. The pilot ran on an export somebody produced by hand. Production needs a credential, which needs an approval, which has a queue nobody measured. This is the most common blocker and the one most easily removed in advance by requesting real access in week one rather than accepting a file.
A security review that was never started. Deferred because the pilot was only a pilot. It then lands on a finished system with a deadline attached, and it is the review team's first sight of something they will now be asked to approve under pressure.
No owner for the outcome. The pilot was sponsored by an innovation function whose job is to run pilots. Nobody whose numbers change is accountable for it, so nobody is pushing when the effort required rises.
Nobody built for the real distribution. The pilot data was tidy. Production contains the scans, the malformed records and the exceptions, and the system has to be partly rebuilt to handle them, which reads to a sponsor as the project having failed.
What to do instead
Make the first project narrow and real rather than broad and safe. One genuine workflow, in production, with the actual access granted and the actual review completed, serving perhaps five people.
It is less impressive in a steering meeting and it tests the things that matter. If access takes eleven weeks, you learn that on a small project rather than on a large one. If the security review has questions nobody can answer, you find out while the system is small enough to change.
The output is also more useful. A real system serving five people produces genuine usage data, real objections and a defensible measurement. A pilot produces a slide.
If you already have a portfolio of stalled pilots
This is a common position and it is worth treating as a portfolio decision rather than as a series of individual revivals.
Sort them by one question: is there a named person whose numbers change if this works. The ones with an answer are candidates to restart, with the access and review work done first this time. The ones without an answer should be stopped explicitly rather than left open, because an unclosed pilot consumes attention and makes the next proposal harder to authorise.
Stopping things openly also has an effect on credibility that is easy to underestimate. An organisation that closes projects deliberately is trusted when it says the next one is different.
The one pilot worth running
There is a version that earns its place, and it is not a demonstration. It is a test of the thing you are genuinely unsure about, run in a week, designed so that a negative result is as useful as a positive one.
Usually that means retrieval quality on your real documents, including the awkward ones, or whether a credential can actually be issued in a reasonable time. Both are cheap to test, both are the sort of thing that sinks projects, and neither requires building anything a user would see.
The distinction is simple enough to apply as a rule: a pilot that can only succeed is a demonstration, and a demonstration answers a question nobody had.
Why this is worse in some markets than others
Where organisational buying runs well ahead of individual familiarity with the technology, the pilot pattern is most entrenched, because pilots are how a cautious organisation engages with something it has not internalised. The Stanford AI Index puts United States population adoption at 28.3 %, ranking 24th, while its organisations are among the most active buyers anywhere, and the gap shows up as exactly this behaviour. Our United States page covers the consequences.
The remedy does not vary by market. A project with real access, a real review and an owner who cares about the outcome crosses; one without does not, and no amount of pilot quality substitutes.
If a pilot has stalled
Tell us which of the four blockers it hit. Most stalled projects hit one specific thing, and naming it is usually enough to decide whether restarting is worth it.
A first conversation is thirty minutes and is not a sales call. If the answer is that you do not need us, that is a useful outcome and we will say so.
