Pilot Project & MVP

AI implementations rarely fail because of technology; they fail because the scope is too broad: too many processes at once, too many stakeholders involved, too long before seeing results. A pilot flips this — one clearly defined process, a small team, one measurable success criterion. Within weeks, you have a real result you can use to assess both the value and the limitations.

The MVP principle means this: build the simplest working version first, then expand based on real usage. An email automation starts with the most common enquiry type instead of all of them; a document AI with one receipt type instead of ten. What works in the pilot is then systematically rolled out to additional cases.

Three ingredients determine success: First, a process with genuine pain and measurable effort — not a prestige project. Second, a clear success criterion defined upfront (for example, halve processing time or achieve AI accuracy above a specific threshold). Third, the people who live this process daily — their feedback turns a prototype into a tool that people actually use.

At the end of the pilot comes a deliberate decision: expand, adjust or stop. Even a stopped pilot is a win — it prevented an unworkable concept from being rolled out at full scale with substantial investment.

The transition from a successful pilot into regular operation is its own project step — and is often underestimated. Three things change: Volume increases (what worked with 20 cases per week must run reliably at 200), variety grows (new document types, locations or enquiry types bring edge cases the pilot never encountered), and attention drops (during the pilot the project team watched daily — in live operation the system must work reliably without that level of care). A good rollout plan addresses all three: load testing, step-by-step expansion of case types and monitoring that flags problems before users see them.

Expanding in waves has proven effective: each wave covers a new case category or location, with a short observation phase before the next begins. In parallel, operational responsibility must be clarified — who responds to errors, who maintains the rules, who decides on expansions? Without this, the system stays permanently attached to the original project team. With it, the pilot becomes operational infrastructure that survives key people leaving.

A pilot project can also fail, and the causes repeat. The most common mistake is scope creep: trying to cover all cases, all locations or the full rollout in the pilot sacrifices the speed advantage that makes the pilot worthwhile in the first place. A second classic mistake is a missing or vague success criterion — without a clearly defined, measurable threshold set upfront, you end up endlessly debating whether the pilot succeeded, and the expansion decision goes nowhere.

Equally common is bypassing the people who work the process daily. If the pilot is built without the team, the edge cases that determine practical success go undetected, and later adoption suffers. And finally, pilots are sometimes extended indefinitely instead of making a clear decision — the time-limited experiment becomes a permanent workaround with no accountability.

The remedies are known and straightforward: keep scope consciously small, define a measurable success criterion upfront, involve the process owners from the start and make a clear decision at the end — expand, adjust or stop. A deliberately stopped pilot is also a success, because it prevented a costly misallocation with minimal investment.

The most common mistake at the end of a pilot isn't a wrong conclusion — it's a delayed decision. The pilot gets extended because the success criterion was barely missed and someone gives it 'a bit more time' — or because nobody wants to take responsibility for stopping. Yet that's precisely a valuable insight: identifying a concept as unsuitable at small scale before rolling it out broadly.

Decision readiness exists when three conditions are met: the pre-set criterion has been met or clearly missed, the observation period is long enough to smooth out outliers, and stakeholders have given a clear assessment of real-world viability. Then comes the deliberate decision — expand, adjust or stop. What shouldn't happen: moving the goalposts because the numbers are inconvenient. That undermines the value of the entire pilot process.