AI project proposals are now being approved and handed off to the manager of the organisation’s Plan division. It’s the same way every other technology project is kick-started. A business case is written, requirements are documented, funding is approved against a fixed scope, the Build team delivers, and then the sustainment or Run team takes over to support the system in production.
In Brief
- Plan-Build-Run assumes solutions are knowable before work starts and stay true long enough to survive each handoff. AI breaks both assumptions.
- The length of task frontier AI can complete on its own has doubled roughly every seven months since 2019, shorter than most project cycles.
- AI tends to amplify an organisation's existing delivery design, so handoff delays and lost learning become more costly, not less.
- AI high performers are nearly three times as likely to have redesigned workflows; companies with mature product operating models, built on persistent teams, outperform peers.
Each step in the chain has a manager to coordinate work, a stage gate to garner executive sponsorship, and a budget line. The process is familiar, well governed and defensible at audit time. The challenge, though, is its timing.
Research from Model Evaluation and Threat Research (METR) found that the length of tasks frontier AI systems can complete on their own, measured by how long the same tasks take skilled people, has doubled roughly every seven months since 2019, and that the trend may have accelerated in 2024 (METR, 2025). On that trajectory, a business case approved today is likely to describe capabilities that have been overtaken before the Build team finishes. On the evidence, Plan-Build-Run as designed cannot keep pace.
Plan-Build-Run assumes the solution won't change
Plan-Build-Run rests on two assumptions. The first is that a technology solution can be defined and scoped upfront before work begins: Plan specifies it, Build executes it, and Run then sustains it. The second assumption is that any solution will survive as-is while it passes through each handoff. Where both assumptions hold, this linear approach to management and coordination through separate IT functions is efficient. Unfortunately, AI breaks both assumptions at once.
Snowden and Boone (2007) distinguish complicated problems, where analysis can find the solution in advance, from complex problems, where the answer emerges only through experiment. What AI can do inside a process, policy workflow, or service channel is a complex problem. It is discovered by trying, observing the result and adjusting. IT’s Plan function typically has no mechanism for that feedback loop, because its output is a signed-off specification recording what was known on the day it was written. KPMG (2016) made a similar case a decade ago: where speed and agility are the priority, business cases and committee approvals become a barrier, and the project-oriented Plan-Build-Run approach has to give way to a different IT operating model. AI adds a second moving part. The tools themselves evolve rapidly while the specification waits in the queue for sign-off.
Early pilots keep Plan-Build-Run in place
Plan-Build-Run persists in organisations that are otherwise well run, partly because early AI work fits it comfortably. A pilot can be scoped, funded, delivered and closed like any other project, so the first round of results looks like evidence that the existing process works. The strain appears when the organisation tries to scale.
At scale, the pressure falls on the structures the model created. Approval authority is tied to project scope, reporting lines follow functional silos, and performance is measured against delivery to plan. Each of those structures also shapes management practices. Argyris (1977) observed that organisations default to single-loop responses, correcting a variable inside the existing system, because questioning the system means questioning the assumptions on which authority rests. The usual response to slow AI delivery follows that pattern: a faster intake process, an AI centre of excellence, a single individual appointed as the AI architect, a streamlined approval gate. Each correction is reasonable, and each keeps the handoffs in place.
AI speed exposes every handoff
The immediate consequence of AI within silos is that it makes handoff costs visible. The 2025 DevOps Research and Assessment (DORA) report, drawing on nearly 5,000 technology professionals, found that AI acts as an amplifier, strengthening what already works in high-performing organisations and intensifying the problems of struggling ones (DeBellis et al., 2025). The same report found that without attention to workflows and team alignment, individual productivity gains from AI tend to be lost further down the delivery chain. In a Plan-Build-Run design, handoffs sit further down the chain. A team can generate code, analysis or draft policy in hours, then wait weeks for the next stage gate or management coordination meeting. The wider data points the same way.
McKinsey’s 2025 global survey found that 88% of organisations use AI in at least one business function, yet only about 6% qualify as high performers generating significant enterprise value. Those high performers were nearly three times as likely as others to have fundamentally redesigned their workflows (McKinsey & Company, 2025). BCG’s research found that 60% of companies report minimal revenue and cost gains from AI despite substantial investment (Boston Consulting Group, 2025). The gap between those numbers sits in the design the adoption runs through.
The escalating cost is less obvious. In Plan-Build-Run, each AI initiative is a project, and when the project closes, the team is dispersed. What the team learned about where the tools help, where they mislead and what the data will support leaves with its members. The next initiative starts from scratch, with a specification written against AI capabilities that have already moved on. Each doubling in what the tools can take on widens the gap between what they can do and what the organisation has approved, designed and staffed itself to do. By the time that gap shows up in a portfolio review, it has usually been growing for months.
Persistent teams keep what AI projects learn
The tempting response is to try to run Plan-Build-Run faster. Smaller, lightweight business cases and quicker stage gates shorten cycle time, but they leave the feedback loop broken because the people who learn what the AI can do are still separated from the people who decide what to build next. The more useful question is where the organisation holds AI learning once a pilot or full-scale project is complete.
The alternative is to hold that learning in persistent teams that own an outcome across iterations, are funded against outcomes rather than a fixed scope, and are measured on value released and used by their customers. McKinsey’s research across more than 400 companies found that companies with the most mature product operating models had 60% higher total shareholder returns and 16% higher operating margins than companies in the bottom half (McKinsey & Company, 2023). Three places show which design an organisation is actually running, whatever its org chart says. If each AI change needs its own business case, the funding model is project-based. If teams own delivery but not the result, accountability still stops at the handoff. If the dashboard reports on-time and on-budget, every decision below the executive level will keep optimising for projects and scope, not an outcome.
None of this is a small change. Funding rules, delegations and performance measures are executive decisions, and in the public sector they sit inside appropriation cycles and ministerial accountability that commercial research does not cover. The constraint is real, and it will not yield to more effort inside the current design.
What this means for senior leaders: Plan-Build-Run was built for solutions that could be specified in advance and stayed stable, and AI provides neither. Faster stage gates do not close the gap, because learning still disperses when each project closes. The funding model, what teams own and what gets measured show whether AI learning is being kept or lost.
Plan-Build-Run can govern AI investment, but it cannot keep up with it. The executive who moves funding, ownership and measurement to where the learning happens gives the organisation a way to reap the benefits of every new generation of AI capability as it arrives, instead of writing another business case for it.
References
- Argyris, C. (1977). Double loop learning in organizations. Harvard Business Review, 55(5), 115–125.
- Boston Consulting Group. (2025). The widening AI value gap: Build for the future 2025. https://media-publications.bcg.com/The-Widening-AI-Value-Gap-Sept-2025.pdf
- DeBellis, D., Storer, K., Harvey, N., Beane, M., Edwards, R., Fraser, E., Good, B., Kalliamvakou, E., Kim, G., Maxwell, E., D’Angelo, S., Inman, S., Murillo, A., & Villalba, D. (2025). State of AI-assisted software development 2025. DORA, Google. https://dora.dev/dora-report-2025/
- KPMG. (2016). Next-gen IT operating model. https://assets.kpmg.com/content/dam/kpmg/xx/pdf/2016/10/Next-Generation-IT-Delivery-Models.pdf
- McKinsey & Company. (2023, December 19). The bottom-line benefit of the product operating model. https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/the-bottom-line-benefit-of-the-product-operating-model
- McKinsey & Company. (2025, November 5). The state of AI in 2025: Agents, innovation, and transformation. QuantumBlack, AI by McKinsey. https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai
- METR. (2025, March 19). Measuring AI ability to complete long tasks. Model Evaluation and Threat Research. https://metr.org/blog/2025-03-19-measuring-ai-ability-to-complete-long-tasks/
- Snowden, D. J., & Boone, M. E. (2007). A leader’s framework for decision making. Harvard Business Review, 85(11), 68–76.
