Pilot fatigue.

A POC without a decision framework is not a proof of concept. It is a delay mechanism.

Organisations across ANZ and APAC have invested significantly in AI proofs of concept over the last two years. The technology has largely worked. Use cases have been validated. Vendors have been pleased. And then, more often than not, the organisation spent the next six to twelve months unable to move, with the pilot itself sitting intact and the decision nowhere in sight.

Two patterns account for most of what goes wrong, and they repeat across sectors with remarkable consistency.

In the first, the business leads the initiative. A use case is identified, a budget is approved, a vendor is selected, and technology agrees to support. Support, however, is not ownership. When the POC concludes, the IT team carries a delivery queue, resourcing constraints, and competing BAU priorities that were never formally reconciled against this commitment. The pilot is innovative work landing inside an operations team, measured on stability and continuity, where it ranks below the seventeen other things already in flight. The business waits. IT is not obstructing. IT is already full.

In the second, technology drives. The architecture is sound, the integration is clean, and the team is proud of what has been built. The business attends the demo, acknowledges the outputs, and returns to the metrics they were already measured against. The tool exists. Adoption does not follow, because no one in the business was ever given a reason grounded in their own priorities to use it.

Both patterns share the same root. The POC was treated as the deliverable, and the decision it was supposed to produce was deferred.

A POC is not just a technical exercise. It is an investment in a future business outcome. The budget committed, the leadership attention redirected, and the internal resources reallocated all carry a cost, with the expectation that something will change on the other side. When that change does not materialise, the investment compounds into lag. McKinsey's 2024 State of AI report found that while 72 per cent of organisations surveyed had adopted AI in at least one business function, fewer than a third had moved beyond pilots to meaningful production deployment at scale, and the most cited reason was the absence of organisational structures needed to make and hold a production commitment. Bain's 2024 Technology Report estimated that stalled AI pilots account for 15-20 per cent of annual technology budgets in large enterprises. For a $50 million technology budget, that is between $7.5 million and $10 million, generating no business return. That figure shows up in write-offs, in project deferrals, and in the accumulated cost of internal friction: the cross-functional time, the re-scoping cycles, the stakeholder fatigue that builds every month a decision is deferred.

One structural response that has worked, and that is increasingly documented in technology leadership literature, is the creation of a dedicated innovation capability that sits separately from BAU IT rather than competing with it. Gartner's Bimodal IT framework introduced a useful distinction between teams managing stable operations and teams built for speed and experimentation, and the underlying principle remains sound even as the specific framework has evolved: when innovative work is assigned to teams whose primary measure is operational continuity, the conditions for pilot stall are predictable. The separation of innovation governance from operational governance is the design principle worth preserving, regardless of how an organisation structures or labels it. IDC's research on digital transformation leadership similarly found that organisations that establish dedicated transformation squads, separate budget lines, and distinct success metrics for innovation work are significantly more likely to progress from pilot to production. These are sometimes called ninja teams, skunkworks units, or centres of excellence. The label matters less than the principle: innovation work requires innovation governance, and that governance cannot be borrowed from an operations team already at capacity.

The conversation that should happen before the POC starts is more consequential than the POC itself. Four questions determine whether any pilot can produce an outcome worth having.

What specific problem is being solved, defined narrowly enough that the organisation will know when it is solved? A document processing backlog with a measurable SLA reduction. A fraud detection gap with a defined false positive threshold. A problem, not a capability.

Who has the authority to commit to production if the POC succeeds? This is a named individual question, and critically, that individual's performance objectives must connect directly to the outcome the POC is intended to deliver. MIT Sloan Management Review research on technology adoption found that the strongest predictor of post-pilot production commitment is whether the decision owner's KPIs are directly tied to the outcome being measured. When the person making the go/no-go call has no personal stake in its success, the call drifts toward caution, delay, or ambiguity. Incentive alignment is structural, not soft.

What are the governance requirements for production? Data residency, model risk, regulatory obligations, and security classification. The requirements a production deployment must satisfy, understood before the POC begins, not discovered after it concludes.

What is the go/no-go criteria, and who owns the call? A defined evaluation threshold, documented in advance, with a named owner for the decision. A call, not a sentiment.

Without those four questions answered before the pilot starts, the POC cannot succeed in the only sense that matters: producing a clear, accountable, committed decision to proceed or stop.

Decision clarity is consistently identified in AI adoption research as one of the rarest organisational capabilities, rarer than data readiness and harder to build than talent. The organisations that scale AI successfully are not the ones with the most technically impressive pilots. They are the ones who treat the decision with the same rigour as the technology.

The AI Decision Acceleration Framework is a fixed-scope engagement lasting two to four weeks that builds the executive clarity your organisation needs before committing to a POC. The framework produces the artefacts your leadership team needs: problem definition, authority mapping, governance requirements, and a documented go/no-go threshold. Before the pilot, not after. Late April bookings are available now at jradvisory.co.

Has your organisation experienced pilot fatigue, a POC that succeeded technically but stalled commercially? Share what happened in the comments.

And if someone in your network is about to commit budget to an AI pilot without this conversation, this is worth sending their way.

Sources:

McKinsey and Company. The State of AI in 2024. McKinsey Global Institute. https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai

Bain and Company. Technology Report 2024. https://www.bain.com/insights/topics/technology/

Gartner. Bimodal IT. https://www.gartner.com/en/information-technology/insights/bimodal

IDC. IDC FutureScape: Worldwide Digital Transformation Leadership 2024 Predictions. https://www.idc.com/getdoc.jsp?containerId=US51255223

MIT Sloan Management Review. Making Digital Transformation Work. https://sloanreview.mit.edu/projects/winning-with-digital-transformation/