Sustaining momentum after the pilot

Noor had seen it happen at her last employer. A pilot ended with good results, a presentation and applause. Then the pilot team went back to their day jobs, the champion at the pilot site left, the budget for scaling was postponed to next year, and twelve months later the model was still running at one site, slowly drifting, with nobody watching it. "Pilot purgatory," she called it. The tenth session was about avoiding it.

Why pilots stall

Pilot purgatory is the state in which AI initiatives succeed as pilots but never move into production or scale. It is common, and its causes are rarely technical. The exam guide's task on scaling AI asks you to move initiatives from experimental to production-grade, including governance and operational requirements, and to evaluate multiple factors during scaling to protect business continuity and performance. Most stalled pilots fail on one of those requirements.

Production-grade

A pilot and a production system are different things even when they use the same model. A pilot can tolerate manual steps, a single person who understands it and a spreadsheet for monitoring. A production system that eleven clinics depend on cannot. Moving to production means meeting a list of operational and governance requirements, which Andre turned into a checklist for every gate.

Lorraine noticed that the checklist cost money. Monitoring, support, documentation and fallbacks all take time to build. That was the point. A business case that counted the model and the integration but not these items would understate the cost of production, and the gap would appear as a stalled scale-up. The strategy course's life-cycle costs had included most of them; the checklist made sure they were actually delivered.

Scaling in waves

The exam guide asks you to use scaling methods that start with short-term wins and progress toward enterprise-wide deployment, and to protect business continuity and performance while scaling. Scaling everything at once is risky: a problem that appears at the fifth site appears at all twelve at the same time, and support is overwhelmed. Scaling in waves spreads the risk and the workload, and lets each wave learn from the last.

The no-show reminders were planned to scale in two waves after the pilot gate: four more clinics in May 2027, then the remaining four clinics and the emergency hospital's booking desk in July. A quiet month between the waves, June, was kept free for fixing whatever wave 1 revealed. Each wave would have a champion trained in advance, a two-week period of extra support, and a go or no-go check before the next.

The estimate also served as a check. If wave 1 produced far more than 48 questions, something was wrong with the training, the guide or the tool, and the steering group would want to know before wave 2.

Protecting business continuity

Scaling changes processes that the business depends on every day. The exam guide asks you to evaluate multiple factors during scaling to protect business continuity and performance. For Cascade Ridge those factors included timing, capacity, dependencies and fallbacks.

• Timing: avoid starting a wave in the busiest weeks, such as the weeks before a long weekend or during a staffing shortage at the clinic.
• Capacity: check that the systems, the support team and the clinic staff can absorb the change, including the extra reminders and follow-up calls.
• Dependencies: check that the booking system, messaging service and data feeds the model relies on are stable, and that no other major change is planned at the same site in the same weeks.
• Fallbacks: make sure each clinic can turn the extra reminders off and return to the standard process within minutes.
• Performance at scale: watch costs, response times and model performance as volume grows, since a model can behave differently on clinics with different clients.

The last factor was not hypothetical. The Cheyenne clinic served a different mix of clients from the pilot clinics, with more holiday-home owners who booked months ahead. Noor planned to check the model's recall on that clinic's history before its wave, and to recalibrate if it fell short, rather than discover the problem after launch.

Keeping people engaged

Momentum is partly a matter of attention. Andre planned several ways to keep the transformation visible after the first pilots: a short quarterly update to all staff on what each initiative had achieved and learned, including what had been stopped; recognition for clinics and individuals whose feedback improved a tool; rotating some champions every year, so that the role spread skills rather than burning out a few people; and a steady pipeline of new ideas through the intake form, so that there was always a next initiative to look forward to.

He also planned for the people who kept the system working after launch. Initiative owners would have their AI responsibilities written into their job descriptions and goals. Monitoring and support would be scheduled work, not favors. The data analyst's arrival in the second quarter of 2027 would be used to move routine monitoring off Noor, freeing her for the next experiments.

Building the next wins on the first

The best protection against stalling is to make each success make the next one easier. The no-show reminders would leave behind more than a model: a tested integration with the booking system, a pattern for monitoring prediction models, a fairness check routine, trained champions, a support model and a story staff could tell. The lab-report extraction pilot, starting in spring, was planned to reuse as much of that as possible. Noor estimated that reuse might cut the time from approval to pilot for later initiatives by about a third, though she cautioned that this was an expectation to test, not a promise.

This is what the exam guide means by progressing from short-term wins toward enterprise-wide deployment, and why lesson 3 placed reusable patterns among the center of excellence's main jobs. A transformation is visible when the fifth initiative is noticeably easier than the first.

Knowing when to stop

Sustaining momentum does not mean keeping every initiative alive. The strategy course described the decisions available at each gate: scale, continue, pause, terminate or pivot. Stopping a weak initiative frees people, money and attention for stronger ones, and it shows staff that the gates are real. Andre wanted the first stopped initiative, whenever it came, to be announced with the same clarity as the first success, with what had been learned and what would be done with the freed budget.

From experimental to production-grade governance

Governance also changes at launch. During a pilot, decisions are made by the initiative team and the steering group at the gate, and the system is watched closely by the people who built it. In production, the system becomes part of normal operations, and governance must become routine: scheduled reviews, monitoring with alerts that reach an owner, a change procedure for updates, and a place in the register of AI systems with a review date. The exam guide's phrase about moving initiatives from experimental to production-grade, including governance and operational requirements, refers to this shift from close attention to reliable routine.

Change control deserves a word of its own. A prediction model, a prompt, a guardrail rule or a set of approved documents can all change after launch, and each change can alter behavior. Cascade Ridge's procedure was simple: every change was tested against the initiative's evaluation set before release, recorded in the register with the reason, approved by the business owner for tier 2 and by the steering group for tier 3, and reversible. Model updates from a provider counted as changes too, which was why the vendor contracts in lesson 8 asked for notice.

A gate in practice

The no-show pilot gate, planned for late April 2027, showed how these ideas fit together. The steering group would see twelve weeks of evidence: the outcome compared with the comparison clinics, the adoption funnel, guardrail and fairness measures, costs against budget, the champions' reports and the production readiness checklist. It would then make one of the decisions from the strategy course. If the evidence met the agreed criteria and the checklist was complete, the decision would be to scale in waves, with the wave 1 tranche released. If the outcome was promising but the checklist incomplete, the decision would be to continue the pilot for a set period while the gaps were closed. If the outcome fell below the break-even point, the pilot would stop.

Scaling scenarios on the exam

Exam scenarios about scaling often describe a pilot that succeeded but has not spread, or an organization that wants to roll a tool out everywhere at once. The best answers name a production owner, meet operational and governance requirements before scaling, use waves with support and fallbacks, and tie funding to gates. Answers that scale before monitoring and support are in place, that extend pilots indefinitely, or that keep failing initiatives running because money has already been spent are usually wrong.