How to Run a Pilot Project That Actually Scales (Proof System)

The Pilot Graveyard Is a Management Failure, Not a Technical One

Walk through any organization's pilot history and the exhibits share a profile: technically successful, enthusiastically demoed, quietly buried. Nobody decided against them, that is the point. The expansion owner role was never filled, the gate meeting never had a scheduled date, and the evidence expired while the organization "evaluated." A pilot without a pre-agreed decision mechanism is not an experiment; it is a performance with an open run.

Learning how to run a pilot project that scales therefore starts before any build work happens. Four decisions get made on paper first: what number defines success, who represents the rule, when the decision happens, and what stops the attempt. Every dead pilot skipped at least one of these; most skipped all four. The four-week system below exists to make skipping impossible, not because pilots are fragile, but because organizations are busy.

The Share That Never Crosses the Line

The graveyard has published statistics, and they are consistent across sources. Gartner's AI research found roughly 54% of AI projects make it from prototype to production, meaning nearly half never do. Gartner's 2024 forecast expected at least 30% of generative AI projects to be abandoned after proof of concept by the end of 2025, citing poor data quality, inadequate risk controls, escalating costs, or unclear business value. And BCG's research finds 74% of companies struggling to scale value from AI at all. The base rates differ by population; the shape does not.

Read the bars as a description of what kills pilots, because each study names a management variable, not a technical one. Data quality is a governance decision. Risk controls are paperwork. Unclear business value is a battle statement that was never written. The pilots that survive are not the ones with better technology; they are the ones whose leaders made the four decisions up front and refused to reopen them mid-flight.

Step One: Write the Proof Contract Before Anything Is Built

Five clauses, one page, signatures. Clause one, the Metric: one number, from one system that already exists, with a named owner of the report, "order-status contacts per day, measured in the ticket system." A pilot with three metrics has none. Clause two, the Baseline: the current value measured the same way, in the same system, before anything changes, the before-photo that makes Week 4 falsifiable.

Clause three, the Sample: who is in the pilot and why they represent the rule, written down, never "whoever volunteered." Clause four, the Decision Date: a calendar invitation that already exists, with the decider's name on it, not "when we have enough data." Clause five, the Kill Criteria: the pre-agreed conditions under which the pilot stops, and the framing that makes stopping safe: information is a valid win. The signature matters more than the document: "everyone agreed" evaporates by Week 3; a signature survives the first difficult Monday. The contract is also the seed of the funding case, the same clauses become the risk block in the five-block business case.

Step Two: The Four-Week Arc

The arc is deliberately short because time is the enemy of pilot honesty: every additional week invites feature creep, sponsor impatience, and metric drift. Four weeks, one to baseline, one to build, one to measure, one to decide, keeps each failure mode in its own week where it can be seen and handled.

Weeks 1 and 2: Baseline and Build

Week 1, Baseline: measure the current state with the contracted method, no changes, no launches, just the before-photo. This week routinely saves the pilot: discovering that your baseline query has never been written costs nothing in Week 1 and voids the contract in Week 4. Week 2, Build: configure, integrate, train the sample team, and enforce the parking rule: any "while we're here" feature request goes to a dated parking lot, because every added feature muddies the metric and extends the build.

Weeks 3 and 4: Measure and Decide

Week 3, Measure: the sample runs live; collect the number daily and the friction notes verbatim, measurement without anecdote is blind, anecdote without measurement is noise. Week 4, Decide: the gate meeting against the contract, with exactly three possible verdicts. Scale it: the metric moved past the bar, book the expansion gate before leaving the room. Kill it: kill criteria tripped, stop cleanly, bank the artifacts, and say publicly that information was the win. Iterate it: moved but short, with a named friction cause, one more cycle, one only, date fixed. Anything outside these three verdicts is a deferral wearing a meeting's clothes.

Why the Baseline Week Decides Everything

The baseline is where pilot honesty is either established or quietly lost, and 2026 adds a twist: the current state already contains AI. With 75% of knowledge workers using AI at work, 78% of organizations using it in at least one function, and 71% using generative AI regularly, your sample team is almost certainly improvising workarounds before your pilot arrives. Measure those habits, they are the honest baseline, and they are also your adoption tailwind, because the pilot is upgrading behavior that already exists rather than inventing behavior that does not.

A baseline measured this way changes the Week 4 conversation in kind, not just in degree. "Contacts fell from 80 to 52 per day" is an outcome; "contacts fell from 80 to 52 per day, of which 11 were already being absorbed by informal AI use the team self-organized" is an outcome with a mechanism, and mechanisms are what expansion decisions are actually made on. The transformation statistics that survive honest reading all share that property: before-number, after-number, same measure, same system.

Step Three: Design the Sample and the Scale Path Together

The sample decision is where pilot honesty usually dies. The enthusiastic team is the worst sample for the same reason it is the easiest yes: they generate friendly data, forgive friction, and prove the exception. The representative-middle team, typical workload, typical skepticism, truthful manager, proves the rule, and only proof of the rule climbs. Score your candidates on representativeness, not eagerness, and write two sentences for the teams you exclude, so exclusion reads as methodology instead of rejection.

While you are at it, design the scale path the pilot feeds: the ladder rungs (Bake, Prove, Expand, Embed) with the gates between them. The expansion owner gets named now, the process owner from the battle statement, never the pilot lead, because building the exception and running the rule are different jobs. The handoff is a formal meeting with artifacts: build documentation, proof results, the expansion playbook, and the support model. Pilots that design their scale path before starting are the ones that never see a museum.

Step Four: Make the Decision Meeting Decide

The Week 4 meeting has one agenda item: the contract. The evidence is the number from the system that already measures it; the verdicts are the three agreed in advance; the decider is the name on the invitation. What kills the meeting is scope drift, re-litigating the metric, re-defining the sample, "let's give it another quarter." The contract exists precisely to make those sentences out of order. If the number is short but the cause is named and fixable, the verdict is Iterate with a date, not an open-ended extension that quietly becomes the museum.

Prepare the room the way you would prepare for any gate: know who is likely to resist and why. The stakeholder heat map takes fifteen minutes and separates the skeptics who need evidence from the skeptics who need inclusion, the two get different treatments, and confusing them costs the verdict. The adoption machinery that follows a Scale verdict is its own discipline, and the change management data is clear that the week after the gate matters more than the week before it.

If the Verdict Is Kill: Kill Well

A clean kill is the most underrated artifact in the pilot discipline. Bank everything: the process map, the ratio table, the scored vendor audition, the baseline data, the friction notes, these are the assets the next attempt inherits, and they mean the killed pilot was tuition, not waste. Thank the sample team by name and publicly, because they did real work under real constraints, and how you treat them decides whether the next sample team tells you the truth.

Organizations that kill pilots cleanly get two compounding gifts. Their people stop hiding bad news, because bad news has a known, safe exit route, which means the next pilot reports honestly in Week 3 instead of surprises in Week 4. And their next pilot proposal gets taken seriously, because the portfolio has a spine: this committee has watched a kill happen and seen the discipline hold. The graveyard stays empty not because nothing dies, but because everything that dies is harvested.

The Five Mistakes That Reopen the Graveyard

Even teams that know the system drift back into the old habits under deadline pressure. These are the five failures that reopen the graveyard, in the order they typically appear.

Each mistake is cheap to prevent and expensive to unwind, and all five are caught by the same instrument: the Proof Contract, read aloud at the start of every week. When a pilot starts drifting, the drift is almost always visible in the contract first, a clause everyone avoids quoting is a clause already broken.

• Three metrics instead of one: every added metric dilutes the gate until nothing clears it
• The friendly sample: friendliness proves the exception, and the exception does not scale
• The unbooked gate: a decision date without a calendar invitation is a hope, not a date
• Scope creep by courtesy: every "while we're here" feature muddies the metric it serves
• The orphan expansion: no named process owner means the proof expires waiting for a runner

The System Behind the System: A 90-Day Scale Plan

The pilot sits inside a larger discipline, and the 90-day view makes the sequence explicit. Days 1-30: write the Proof Contract, run the baseline week, and build with the parking lot enforced. Days 31-60: measure daily, hold the gate on the scheduled date, and take one of the three verdicts, no fourth option. Days 61-90: if scaled, run the first expansion wave with the process owner leading and the support model staffed; if killed, harvest the artifacts and re-brief the next battle; if iterating, run the single extra cycle and hold the second gate.

The surrounding machinery, the battle that chose the pilot, the five-block case that funded it, the adoption radar waiting for it, and the prompt vault that drafts the contracts and gates in minutes, is the Digital Transformation Playbook system. The Proof Contract is Day 9, the Pilot-to-Scale Ladder is Day 8, and the gates are designed with the decider's name already on the invitation. Day 1 of the Digital Transformation Playbook course is free with any account, and it starts with the audit that tells you which of your past pilots died of undeciding.

Frequently asked questions