OPINION
A successful pilot is not a decision
The most common outcome of an enterprise pilot is not failure. It is a pilot that works, is agreed to have worked, and is followed by nothing.
The pilot works. Everyone agrees it works. Then nothing happens.
This is the most common outcome I have seen, and for a long time I read it as a failure of the software. It is not. It is a category error about what a pilot is for.
A pilot answers a question nobody was stuck on
The implicit promise of a pilot is that uncertainty is technical. Show that the system can read the documents, route the tickets, match the records, and the path forward becomes obvious.
But by the time an organisation is willing to run a pilot, almost nobody senior doubts that the technology can work. They have seen the demo. They have seen a competitor's press release. The question holding up the decision is different, and usually unspoken:
| The pilot asks | The decision needs |
|---|---|
| Can the system do the task? | Who owns the process once it changes? |
| Is the output accurate enough? | Who is accountable when it is wrong? |
| Can it connect to our systems? | Who maintains that connection in a year? |
| Do users like it? | Whose job description changes, and who tells them? |
A pilot that answers only the left-hand column produces a result everyone accepts and nobody can act on. The meeting ends with genuine enthusiasm and no next step, because the next step was never a technical one.
The three things a pilot structurally cannot test
Some of this is not anyone's fault. A pilot is scoped small and run short, which is exactly what makes it affordable, and also what makes it blind in three specific places.
Who maintains the data. Pilots run on a curated extract. Somebody cleaned it, usually the person most invested in the pilot going well. In production that cleaning is a standing job, and it belongs to someone who was not in the room.
The exception path. A pilot is measured on the cases it handles. The cost of a system is decided by the cases it does not, because those need a human route, and designing that route is where the real process change lives.
Whose job changes. This is the one that decides adoption and the one nobody writes into the pilot scope. If the tool makes a task faster, someone's role was partly that task. Until that is named out loud, the safest thing for that person to do is nothing, and nothing is very easy to do.
The conversation that has to happen first
What I do now is unglamorous and takes about an hour.
Before the pilot is scoped, I ask three questions and write the answers down where both sides can see them:
- What result would mean yes? Stated as something checkable, not "if it goes well". If nobody can answer, the pilot is exploratory, which is fine, but it should be called that so nobody expects a decision at the end.
- Who signs that decision? A name, not a department. Departments do not sign.
- Who owns the process afterwards? Also a name, and ideally one who has been told.
Then I insist the pilot includes one real integration and runs on real data with the people who would actually use it. A sandbox with sample records is faster to build and tests almost nothing worth knowing. The friction of the real system is the finding.
None of this is clever. It just moves the hard conversation to the front, where it costs a meeting, instead of the end, where it costs the project.
Where this is wrong
Two honest qualifications.
Sometimes a pilot's real function is political rather than evaluative. It gives a sponsor something concrete to point at in a budget cycle that has not arrived yet. That is a legitimate use, and reading it as a decision process is my mistake, not theirs. The tell is that nobody can name the decision-maker, and the useful response is to scope it cheaply rather than to force a commitment that is not available.
And some pilots should stay small forever. A tool that quietly serves one team well is not a failed rollout. Not everything needs to become a platform, and the instinct to treat every working pilot as the start of an enterprise programme has wasted more time than it has saved.
The failure mode worth naming is narrower than "pilots do not convert": it is running a pilot as though it were a decision process when nobody has agreed what decision it feeds, and then being surprised by the silence.