And How to Save It
Let us begin with a difficult truth. That new pilot you are about to kick off, the one being championed internally as the next major leap in transformation, is more likely to stall than succeed. This will not be because of bad code, immature algorithms or even external market forces. It will happen because, organisationally, we have not learned the lessons of the last thirty years.
I have seen this story repeat across sectors and industries. Smart people create well-intentioned ideas, backed by credible insight. They gain internal traction, produce promising results and then disappear. The pilot is not cancelled. It is not even declared a failure. It simply stops progressing. There is no budget request for scale-up, no handover into operations and no official decision either way. Instead it slides quietly into organisational limbo. The team disperses. Stakeholders turn their attention elsewhere. What was once described as high impact becomes a historical footnote, recycled into someone's CV as an experiment that showed potential.
This is pilot purgatory. It is a state in which innovation is neither alive nor officially dead, sustained only by inertia and the reluctance to confront what went wrong.
The Data Has Been Trying to Warn Us
According to the Standish Group, which has tracked IT project outcomes since 1994, the overall success rate for technology initiatives remains low. In 1994, only 16 per cent of projects were delivered on time, on budget and with acceptable scope. Three decades and multiple waves of transformation later, that number has risen only marginally, to 31 per cent. Despite agile frameworks, digital tooling and executive buy-in, most innovation initiatives still stall or fail.
31% of change projects are successful, after 30 years of doing them...
Worse still, 19 per cent of projects fail completely, and over 50 per cent are classified as challenged. These are not edge cases. This is the industry norm. The lesson is simple. Pilots do not fail because of technical limitations. They fail because we do not design them to succeed beyond their own narrow scope.
What Pilots Are Supposed to Do
When executed well, pilots serve a clear and essential function. They allow organisations to manage risk, validate assumptions and assess feasibility before committing large-scale resources. A good pilot should explore technical viability, process fit, user adoption and commercial value. It should be constructed as the first step of a repeatable and supportable system, not as a proof-of-concept for internal theatre.
Pilots and trials should assess outcome need, reduce risk, be disposable
Too often, however, this purpose becomes distorted. Pilots are used to impress stakeholders, to build momentum or to demonstrate capability. They are built quickly, often in isolation, using curated data and shortcuts that will never survive in production. Once pressure mounts to show results, a dangerous phrase enters the conversation: "Let us just put the pilot live."
At this point, all the things that were deliberately skipped are suddenly required. Monitoring, logging, error handling, security, performance optimisation and user support are now urgent problems. The data pipeline is not production-ready, and the integration points have not been tested. Business ownership is unclear, and there is no budget provision for scale. The result is predictable. The system stalls, trust declines and the project joins the long list of initiatives that almost made it.
How to Spot a Doomed Pilot Before It Begins
There are usually signs. These patterns repeat so consistently that they are worth identifying up front. If your pilot shows more than a few of the following characteristics, it is almost certainly heading for purgatory.
No unit economics. If nobody can tell you the cost per transaction, breakeven point or expected efficiency gain, you are not building a business case. You are building a toy.
A focus on demonstration over foundation. If the pilot is designed to look impressive, but cannot handle real data, it is unlikely to succeed beyond the first presentation.
Lack of ownership. If there is no individual in the business who is accountable for making this live, operating it and supporting its users, then there is no future state. Departments do not scale software. People do.
Clean, curated data. If your pilot depends on perfect datasets, it will fail the moment it meets production reality. Messy, incomplete, contradictory data is the norm. Systems must be designed accordingly.
Uncontrolled scope. If the pilot started with one objective and now includes five, the probability of success has dropped significantly. Simplicity is not just helpful. It is essential.
Technology driving the conversation. If the discussion begins with what the platform can do, rather than what the business needs, the pilot will become a showcase, not a solution.
Change management as an afterthought. If most of the effort is spent on building the system, and little is invested in supporting people through the transition, adoption will fail. Culture eats code.
Even in Flight, the Signs Are Clear
Sometimes it is not obvious until later. There are a few reliable indicators that a pilot is already drifting.
Endless extensions. If timelines keep slipping with no hard decision points, the project has lost momentum. Pilots should have fixed gates, not rolling deadlines.
Shifting success criteria. If the metrics for success change every few weeks, nobody really knows what good looks like. Without clarity, you are chasing approval rather than impact.
Stakeholder disengagement. If your original champions are no longer responding, the project has lost internal credibility. Attention is a proxy for belief.
No integration plan. If integration is treated as a future task, it will become a future problem. If it is not designed in from the start, it is almost always too expensive to retrofit.
User avoidance. If end users are not adopting the system, or are finding workarounds, the pilot is solving the wrong problem. Resistance is a form of feedback.
If stakeholders lose interest, stop showing up, stop the pilot.
A Framework for Making It to Production
It is not all bad news. There are organisations that succeed, and the ones that do tend to follow a very different approach. They treat the pilot as the beginning of the production system, and they follow a deliberate sequence of decisions, design and delivery.
This is the framework I recommend, based on work with organisations that have succeeded in moving pilots to real-world deployment.
Phase One: Define the Sandbox
Before anything is built, define your constraints. This is not about opportunity. It is about boundaries. Begin with the systems that cannot be touched, the processes that must remain intact, and the organisational realities that will not change. Then define your security obligations, your integration capabilities, your data availability and your regulatory context.
Clarity of constraint is what drives realism in design. A pilot built without boundaries will inevitably collapse the moment it meets one.
Phase Two: Find the Owner
Ownership must be personal. Someone must be named. That person must have the authority to fund production, the power to allocate team time and the willingness to be held accountable if it fails.
There are three tests to apply here. Can they approve the budget without requiring five layers of committee? Can they mandate adoption across teams? And what happens to them if it does not work? If the answer to any of those is uncertain, you need a new owner.
Phase Three: Define Success in Four Scenarios
Before the first line of code is written, define your decision points. These should include:
- A clear failure threshold. If the pilot cannot process live data by a certain point, it stops.
- A minimum viable outcome. For example, a 20 per cent improvement in speed with 80 per cent reliability.
- A target success state. What the business would consider a strong result, such as a 40 per cent reduction in effort, a measurable financial return or high user satisfaction.
- A runaway success scenario. If the pilot performs significantly better than expected, is the infrastructure ready to scale? Are resources available?
These scenarios must be written down, circulated and revisited, signed off. They become the reference point when decisions are required under pressure.
Phase Four: Build the Coalition
There are three critical groups who must be engaged early.
- The operators, who will run the system.
- The integrators, whose systems it touches.
- The affected, whose workflows will change.
Each of these groups can block you if excluded. They can also become your champions if involved meaningfully.
This is not stakeholder management, it needs to be personal and relentless.
Phase Five: Design for Day 100, Build for Day 1
Do not design the system for the demo. Design it for production. Then scale it back to fit the pilot. From the beginning, include logging, monitoring, error handling, basic documentation, and access control. Use production data. Expect failure and build paths through it.
This is more work. It is also significantly faster than rebuilding everything later.
Phase Six: Run the Pilot with Hard Gates
Your pilot should have at least three structured checkpoints.
- At day thirty, confirm technical viability. Does it work with real data? Do the numbers still make sense?
- At day sixty, test integration. Can it connect to the required systems? Do the users understand it?
- At day ninety, make the go or no-go decision. Are the criteria met? Is the business case intact? Is the scale-up plan viable?
Do not extend these gates. Make the call.
Phase Seven: Plan the Transition Before It Ends
The most common reason that good pilots fail to scale is that nobody plans for what happens next. As you approach the end of the pilot, document the transition.
- Who takes ownership of the system?
- What will the first thirty days look like in production?
- Where is the funding coming from?
- What will be scaled first, and what risks will that introduce?
- What is the rollback plan if something breaks?
If these questions are not answered before the pilot concludes, the likelihood of success drops sharply. You need to consider probably the worst case question and scenario from a risk perspective.
The pilots are so successful, can't we just turn it on everywhere?
A runaway success pilot brings the greatest risk of all, in addition to failure you should have a plan for success, and rapid scaling. Including the costs, risks and resource requirements, resource includes training, operational staff, releasing the innovation / pilot team from becoming the 'forever support team'.
Change is Human, Not Technical
The final insight may upset your engineering team. The success of your pilot does not depend on technical excellence. It depends on change management.
Most pilots are 70% people, not software engineering. Most pilots do not plan for that.
The most successful programmes allocate 70 per cent of their resources to people and process, 20 per cent to systems and data and only 10 per cent to the algorithms themselves. This is not a fluke. It is because the majority of failure modes are organisational, not computational.
People do not resist technology. They resist systems that make their work harder, threaten their roles or change things without explanation. Your pilot is only valuable if it is adopted, and adoption is a human problem.
The Bottom Line
We have had thirty years of innovation pilots. And we have spent much of that time getting it wrong. The tools have changed. The failure patterns have not.
We still confuse impressive demonstrations with usable foundations. We still avoid the hard questions about ownership, scale and risk. We still push pilots into production without re-architecting for reality.
Your next pilot does not have to fail. But if you want it to succeed, you will need to do something that most organisations still avoid. You must treat the pilot not as a test, or a demonstration, or a hope. You must treat it as the deliberate first step of your production system.
It is less exciting. It is more difficult. It is also far more likely to work.
The decision is yours, need some help... you know how to find us.
p.s, if you are part of a leadership team we are running two of our well received AI for C-Suites day events in the next quarter, if you are interested in attending and the details and getting your AI pilot off the ground and headed to production... drop me a message