The finance director is not hostile. That is what people get wrong about this meeting. She has read the pack, she believes the numbers, and she has asked the one question her job permits: "What does this deliver inside the budget year?" The transformation lead's honest answer is a bad one. The data remediation delivers nothing inside the budget year; it unblocks four use cases that start in month fourteen. The training program produces people whose value shows up in how fast wave three moves. The governance capability delivers nothing ever, in the positive sense: it prevents things. Beside those three lines sits a workflow tool with a vendor demo, a nine-month payback, and a competitor's case study. The tool will be funded at 100 percent, the capability lines at somewhere between half and two thirds, and the transformation will quietly become a tool purchase. Nobody decided that. The budget process decided it, and it will decide the same way every year until somebody changes the architecture of the request.

The Mismatch of Clocks

The hardest financial problem in an enterprise AI transformation is not the size of the number. It is that the work and the money run on different clocks.

The work compounds. A data foundation built in year one is why a use case in year three costs 40 percent of what the first one cost. People trained in year one appreciate: they run the second redesign faster than the first, the fourth faster than the second. The method gains value with every replication, because each pass leaves templates, gate criteria, and scar tissue the next pass inherits. You are building a machine that produces outcomes, and machines have build times.

The money does not compound. It arrives in twelve-month slices, allocated by a process whose central discipline is to make each slice justify itself inside its own year. That process is what stops organizations funding zombies forever, but applied to a compounding investment it produces a predictable distortion: it over-funds whatever can show a return inside twelve months and under-funds whatever cannot, regardless of which produces more value over three years.

Now overlay the program's central arithmetic. BCG's 10-20-70 rule holds that roughly 10 percent of the effort in a successful AI transformation goes to algorithms, 20 percent to technology and data, and 70 percent to people and process: redesign, training, change, adoption, governance, and the standing capability that keeps it running. Almost every leader can recite it. Very few have noticed that the 70 percent consists almost entirely of things that cannot show a return inside their own budget year, and the 10 percent almost entirely of things that can. The budget process does not hate the 70 percent; it asks a question the 70 percent cannot answer, and funds the answer it gets.

The two bad resolutions

The first is to fund the transformation as an annual project. Each year it competes line by line, and each year the compounding investments lose. They lose fairly, on the criteria the process uses: a remediation block cannot beat a licence with a payback calculation, because the licence answers the question and the remediation does not. Run that for three cycles and you have funded the 10 percent faithfully and the 70 percent partially, every year, and you get exactly the organization that arithmetic predicts.

The second is to seek one large multi-year commitment. "Approve 3.2 million over three years and let us work." If the answer is no, which it usually is, you have burned capital and are back to annual funding with a reputation for asking too big. If the answer is yes, you have removed the evidence discipline that made the program work: baselines, pre-committed kill criteria, and stage gates exist because money was conditional on evidence, and unconditional money turns gates into ceremonies. An unconditional three-year budget is a zombie's ideal habitat: nothing must prove anything until year three, and by then the item that should have died in month eight has a team, a sponsor, and a story.

The third answer, and this lesson's artifact

The answer is neither, and it is the shape large capital programs outside AI have used for decades: portfolio funding with stage-gated releases. A multi-year envelope, approved with annual conviction, from which money is released in tranches only as gates pass. The envelope gives the compounding investments their runway; the gates keep every tranche earning its release. Finance keeps its optionality, because it has not written a cheque, it has agreed a shape. Most finance leaders who would refuse the first will consider the second, because the second costs them nothing they value.

The artifact you leave with is the Funding Architecture: three funding classes with different rules, a release mechanism tied to evidence rather than activity, and a base-budget conversion path for the parts of the program that must stop being a project. It does not replace the Level 4 wave business case, which still gets built item by item with ranges, full costs, and a capped downside. It is the architecture those cases live inside.

The Three Funding Classes

The structural core of the Funding Architecture is a refusal to treat all AI spend as one budget line. Three kinds of money behave differently and fail differently, and mixing them is how organizations starve their own capability while believing they fund it generously.

RUN: the standing capabilities, which belong in base budget

RUN is the operating model's permanent machinery: the five standing capabilities from this chapter's first lesson (discovery and intake, delivery, governance and risk, foundation, value and learning) plus the tooling and platform run rate they depend on: stewardship, the analyst who produces the quarterly value scorecard, the governance secretariat. These are not projects: no end date, no go-live, no payback calculation, because they are the conditions under which everything else produces value. RUN belongs in base budget, and converting run costs from project funding to base is the single most important financial milestone in a transformation, more important than the first positive quarter or the biggest single case.

The reason is mechanical. Project-funded run costs are re-justified annually against new initiatives, which always look more exciting because they carry upside while maintenance carries only absence-of-downside. A stewardship role at 120,000 a year competes, every January, against a proposal promising 400,000 of new value, and it loses, in a well-run organization full of people acting rationally on what the process shows them. Eighteen months later that organization writes an incident report about data quality in an AI-touched workflow and files it as a technology failure. That is how organizations dismantle the capability they just spent two years building: by leaving it somewhere that must win an unwinnable fight every twelve months.

Base budget is not a funding source. It is a permanence mechanism. A role in base is no longer an initiative anyone defends; it is part of what the function costs, reviewed like everything else but never re-litigated from zero. That is the Level 5 permanence argument in a chief financial officer's language: "I am not asking for more money. I am asking to move 340,000 of proven run rate out of project funding into base, because it is not a project, and pretending otherwise guarantees we lose it in a tight quarter." Justify RUN with evidence of standing output (the scorecard, logged gate decisions, stewardship coverage, incidents prevented) rather than payback, and ask after twelve months of that output rather than on day one.

BUILD: the portfolio, funded in tranches against gates

BUILD is what most people mean by "the AI budget": the portfolio's use cases and the foundation projects that unblock them, including redesign, pilots, integration, remediation blocks, and the training that accompanies each wave. It is funded against the Level 4 stage gates, with one property that separates this architecture from ordinary project funding: the envelope is multi-year while the releases are gated. The board approves a three-year envelope and renews conviction annually, and money leaves it only as gates pass. Approving the envelope is not approving the spend; it is agreeing the program's shape, its ceiling, and the criteria for release.

That distinction is the entire trade. A program with a three-year envelope can make three-year commitments: hire into roles, start a data program whose value lands in year three, sign a training partner for multiple cohorts. A program funded annually cannot honestly do any of that, and everyone it tries to hire can tell. Meanwhile finance holds every option it cares about: nothing disbursed, ceiling fixed, criteria written down, and the right to withhold a tranche in any quarter. Name that trade out loud, because the person across the table is scoring exactly that.

EXPLORE: small, capped, and deliberately free of business cases

EXPLORE is a small capped fund for work whose returns are genuinely unclear: testing whether a capability class does what vendors claim on your actual documents, a two-week probe into an unassessed process, an experiment that will probably produce a dead end and a paragraph of learning. Its rules are a size limit, a time limit, and a written finding. No baseline, no adoption ramp, no payback calculation, because demanding those is what killed exploration.

Without a named explore fund, exploratory work either does not happen or it happens in disguise. If it does not happen, the organization can only fund what it already understands well enough to build a case for, which is a slow form of blindness. If it happens in disguise, someone writes a business case for an experiment, invents a benefit number and an adoption assumption, and passes a gate with fiction. That corrupts case discipline everywhere else, because once one case is known to be decorative, every case becomes negotiable. Gartner's forecast that over 40 percent of agentic AI projects will be canceled by the end of 2027, with escalating costs and unclear business value among the drivers, describes in part a population of experiments funded as though they were programs.

Size EXPLORE at a stated 10 to 15 percent of the BUILD envelope, defend its right to fail in advance (a quarter in which every explore item succeeded would mean you were not exploring), and report it separately so its failures never touch the portfolio's numbers. Chapter 5.2 turns this into a full experiment discipline.

How the Money Actually Moves

The classes describe where money sits. The release mechanism describes how it moves, and it is where discipline is kept or quietly lost.

Tranches on gate days, criteria as evidence

Tranches are tied to gate days, not to calendar convenience: each is decided in the same room, on the same day, on the same evidence as the gate. When funding decisions happen instead in a finance meeting weeks later, that meeting lacks the evidence and decides on narrative, and the gate review loses its teeth, because passing it no longer moves money.

State release criteria in advance, in writing, as evidence thresholds rather than milestones completed. "The pilot ran" is a milestone; "the pilot met its pre-committed accuracy and cycle-time criteria" is evidence. "Training delivered to 200 people" is a milestone; "60 percent of trained users work the redesigned process unassisted at week six" is evidence.

Milestones can be met by activity alone, and activity is always available. A team told the next tranche depends on "pilot complete" will complete a pilot. A team told it depends on "92 percent extraction accuracy and p90 handling time below four days" will either hit those numbers or come to the gate with an honest miss. Funding tied to milestones funds activity. Funding tied to evidence funds value. Put that sentence in the architecture document itself, because somebody will eventually try to soften a criterion back into a milestone.

Fund the transformation for three years. Release the money one gate at a time, against evidence you wrote down before you knew the answer.

The reallocation rule, which is really an incentive design

Here is the rule that does more for kill discipline than any amount of cultural exhortation: money released from a killed or paused item returns to the envelope, not to the general fund.

Consider the default. An item fails its gate, the program kills it, and the 180,000 goes back to the corporate pot. The program is smaller, and the next planning round reads the underspend as evidence the original ask was inflated. Under those incentives killing is self-harm, so items are not killed; they are paused, rescoped, or moved to a later wave, and the portfolio fills with things nobody believes in and nobody can afford to end. MIT's finding that roughly 95 percent of enterprise generative AI pilots produce no measurable profit-and-loss return, and only about 5 percent of custom-built tools reach production, is partly about technology and substantially about organizations that could not afford, politically, to stop.

Now apply the rule. The item is killed and the 180,000 returns to the envelope, where it goes to the next-best item on the ranked backlog. The kill costs the program nothing except an item it did not want, which makes killing financially painless and therefore honest: you have not exhorted anyone to be brave, you have removed the reason for cowardice. Two guardrails keep it honest the other way: reallocation stays inside the ceiling, so the program cannot grow by killing things, and it follows the ranked backlog rather than the program lead's preference.

Underspend honesty

When released money turns out not to be needed, give it back rather than spending it in December to protect next year's allocation. That feels insane, because underspend is traditionally punished with a reduced baseline. But a transformation program's primary asset is credibility with the people who release its money. A program that returns unspent money once builds the credibility to ask for more twice. The first return buys a finance function that believes your numbers, and belief is what gets tranche four released when the wider budget is under pressure.

The shape you state before you spend

The honest multi-year profile has a shape. Year one is foundation-heavy: remediation, capability build, the first redesigns and training cohorts, with modest realized value because most of the spend buys the conditions for years two and three. Year two is where the curve bends: the first waves are in production and holding, and the second moves faster because method and people now exist. Year three is where compounding shows: use cases cost a fraction of the first ones, and the standing capability produces candidates faster than delivery capacity can absorb them.

Now the critical move. Say the shape in advance, in writing, as part of the funding request. Promise year one as capability and evidence rather than profit-and-loss impact: "In year one you get a data foundation at stated completeness, four trained redesign leads, two workflows in production holding their gains, a gate discipline with logged decisions, and realized value of 300,000 to 500,000 against roughly 1.1 million of spend. We will not be net positive in year one. We expect to cross in the third quarter of year two."

A transformation judged on year-one profit-and-loss impact will be cancelled in year one, because year one's honest numbers look exactly like failure to anyone who was not told what to expect. Said afterwards, that explanation is an excuse; the same sentence twelve months earlier is a forecast that came true. It is also why McKinsey's finding that 88 percent of organizations use AI while only around 39 percent report any EBIT (earnings before interest and taxes) impact, mostly under 5 percent, is less damning than it looks: much of that gap is year-one programs measured against year-three expectations.

The 70 Percent Defense

Everything above is architecture. This is what decides whether the 70 percent survives a tight quarter. Change and capability spend loses budget fights for three reasons unrelated to its value. It is diffuse: the benefit spreads across many outcomes instead of attaching to one. It is latent: cutting it breaks nothing this month, and the consequence arrives two quarters later attached to a different cause. And it reads as optional: a line called "change management" sounds, to a reasonable person under pressure, like something managers could do by communicating better. Three structural moves change that. Not arguments: structure. A leader without them loses the 70 percent eventually however well they argue, because they are arguing every year against a process that only has to win once.

Move one: bundle change costs into the case, never beside it

Change, training, adoption support, and redesign costs belong inside each use case's business case, not as a separate line in a program budget. The fix is mechanical: a line item that can be cut independently will eventually be cut independently. A cost inside an approved item cannot be trimmed without reopening the item's approval and its business case.

Concretely: the invoice-exception use case does not cost 180,000 for technology plus a share of a 240,000 change budget. It costs 310,000, of which 180,000 is technology and integration and 130,000 is redesign, training, champion time, and two quarters of adoption support. There is no version of it that costs 180,000, because a version without the change work does not produce the benefit in the case. It is also true: McKinsey's strongest impact finding is that fundamental workflow redesign is among the largest drivers of value, and high performers are roughly three times more likely to redesign workflows than to layer tools onto them. A tool budget without a redesign budget is a different investment: the one with the 95 percent failure rate.

Move two: express foundation and training in beneficiary arithmetic

Foundation and capability investments have no business case of their own, which is why they lose. Give them one by borrowing from their beneficiaries. Do not write "data remediation, supplier master, 210,000." Write: "supplier master remediation, 210,000, unblocks six portfolio items with a combined modeled benefit range of 1.4 to 2.1 million, three of which cannot start until completeness reaches 95 percent on eight fields." That is the Level 4 backlog discipline re-used as a funding argument, converting an unanswerable question ("what is the return on clean data?") into an answerable one: what does this unblock, worth how much, and when?

The same works for training: not "training program, 95,000" but "training program, 95,000, produces four qualified redesign leads, which is the difference between two concurrent redesigns and four, which is the difference between the year-two plan and half of it." Capability spend expressed as capacity, capacity expressed as the portfolio it enables.

Move three: put standing capability where it stops being re-litigated

The third move is the RUN conversion, and it closes the loop. Bundling protects change costs at the item level; beneficiary arithmetic protects foundation investments at the portfolio level. Neither protects permanent capability, which has no item to hide inside and no beneficiary list that ever ends. Only base budget does that. Notice what the three moves share: each removes a decision rather than winning it. Bundling removes the option to cut change separately. Beneficiary arithmetic removes the question the foundation cannot answer. Base-budget conversion removes the annual re-justification. The 70 percent is not defended by advocacy. It is defended by there being nothing convenient to cut.

Worked Example: Three Years of Money, and One That Went the Other Way

Norvik Group is the mid-market industrial distributor from this level's earlier lessons: roughly 2,400 people, a scrap year behind it, four quarters of governed program since. Every figure below is illustrative and rounded.

The architecture as approved

A three-year envelope of 3.2 million, approved with annual conviction, split three ways:

• RUN: 0.9 million across three years, covering 2.9 full-time equivalents (FTE, meaning the workload of one full-time person) plus tooling: 1.2 FTE data stewardship, 0.8 FTE value and measurement, 0.5 FTE governance secretariat and regulatory register upkeep, 0.4 FTE champion coordination, and roughly 70,000 a year of platform run rate. Project-funded in year one, with an approved conversion into base budget from the start of year two.
• BUILD: 2.0 million, released in six tranches tied to gate days, against evidence criteria written in advance for each tranche.
• EXPLORE: 0.3 million, capped at 15 percent of the build envelope, governed by a two-person sign-off with a 25,000 ceiling and six-week limit per probe, and reported outside the portfolio's value numbers.

Year one, as it actually released

Five tranche decisions were scheduled against the year's gate days: four released, one withheld.

• Tranche 1 (February, 210,000): released against baseline completion for two processes and a signed redesign scope. Evidence, not activity: the baselines existed with stated measurement methods, and finance had validated the cost-per-transaction basis.
• Tranche 2 (May, 340,000): released against the invoice-exception pilot hitting its pre-committed thresholds for extraction accuracy and p90 handling time under five days. It came in at four days, the number that later appears in the board pack.
• Tranche 3 (July, 180,000): withheld. The customer-correspondence item reached its gate with a completed pilot and no evidence: sampling showed no improvement over baseline on the two criteria set in January, and the adoption ramp had not started. Under a milestone regime it would have passed, because the pilot had certainly run. The item was killed, and the 180,000 returned to the envelope and went to the next-best blocked item on the ranked backlog: the supplier master remediation's second block, which unblocks three wave-three items.
• Tranches 4 and 5 (September, 190,000; November, 130,000): released for the reallocated foundation block, training cohort two, wave-two redesign scoping, and the adoption support tail on the invoice work.

EXPLORE spent 60,000 across four probes: two dead ends written up in a paragraph each, one inconclusive, and one that produced enough signal to enter the portfolio as a scored candidate for wave three: a 25 percent hit rate, reported as such.

At year end, 110,000 of released money was unspent because two integration windows slipped into January, and the program returned it rather than finding a December use for it. That is why tranche 6 was released without argument in a quarter when three other programs were cut.

The year-one report to the board

Total year-one spend was roughly 1.1 million: 700,000 BUILD, 340,000 RUN, 60,000 EXPLORE. Realized value: 412,000, of which 260,000 is clear and 152,000 probable with assumptions listed. Avoided spend from items killed at gate, computed by finance rather than the program: 340,000.

The presentation is the point. Those numbers were not offered as a shortfall requiring explanation; they were presented against the pre-stated shape, which had promised 300,000 to 500,000 of realized value against roughly 1.1 million of spend, with net positive expected in the third quarter of year two. Value landed inside the range, spend landed on plan, and alongside went the capability inventory year one was buying: the data foundation at stated completeness on the fields three use cases need, four qualified redesign leads, two workflows holding their gains for two quarters, a year of logged gate decisions including one kill, and the RUN conversion ready to execute.

Year two's conviction was renewed without drama, not because the numbers were impressive (412,000 against 1.1 million is a losing year in isolation) but because that was the year everyone had agreed to expect, and the program reported it honestly, returned money it did not need, and killed the item that deserved killing. The RUN conversion went through in the same cycle, so the 2.9 FTE no longer appear in any January fight.

The other way: the annual-project transformation

A regional retailer of comparable size funded its AI work as an annual initiative instead. Not badly funded: roughly 4.1 million across three years, more than Norvik. Every January the program re-justified everything, line by line.

The same pattern repeated three times. Tool and licence lines survived intact, because they were visible, vendor-backed, and demonstrable: a renewal has a price, a product, and a consequence if you stop paying. The training, stewardship, and change lines were trimmed 30 to 50 percent to fit, every year. Nobody proposed cutting the transformation. They proposed deferring a training cohort, holding a stewardship vacancy for two quarters, and asking function managers to absorb the change communication. Cumulatively across three years: technology lines funded at roughly 97 percent of ask, capability and change lines at roughly 58 percent.

By year three the organization had six AI tools in production, a data foundation started twice and finished never, a training program that reached about a third of the affected staff, and adoption stuck in the fifties as a percentage of eligible users, with heavy attrition in exactly the functions that got the trimmed change support. Realized value was real but small, mostly confined to two functions where a determined manager had done the redesign work herself, unfunded.

The chief financial officer's year-three conclusion was that AI had underdelivered relative to a 4.1 million investment, and it was reasonable given what he could see. What he could not see, though it sat in three years of budget spreadsheets, was the cause: the organization funded the 10 percent faithfully and the 70 percent partially, every single year, and got the result that arithmetic predicts. Nobody made that decision; twelve locally rational trims made it. S&P Global found 42 percent of companies scrapped most of their AI initiatives in 2025, up from 17 percent the year before, and a share of those were adequate ideas whose 70 percent was removed in slices too thin to notice.

With the money architected, the remaining question is what the organization on the other side becomes: how work, roles, and decisions are arranged once AI is native to the process rather than added to it. That is the next lesson.

What to Do Monday Morning

The architecture becomes real only once your existing money is sorted into it, and that sorting is usually uncomfortable enough to be worth doing first.

1. Split your current AI spend into RUN, BUILD, and EXPLORE. Every line, no residual category, then note which class funds your standing capabilities. If governance, stewardship, or value measurement sits inside a project line, you have found the thing most likely to disappear in your next tight quarter.
2. Propose the base-budget conversion for one RUN item in the next planning cycle. Pick the one with the most visible standing output, usually value measurement or stewardship, and frame it as a category change rather than a new ask: same money, out of project funding, because it is not a project.
3. Rewrite your next tranche's release criteria as evidence rather than milestones. For each line, ask whether activity alone could satisfy it. "Pilot complete" becomes a threshold with a number and a measurement method, agreed before the period starts rather than at the gate.
4. Bundle change costs into your next use-case business case. One item, one number, with redesign, training, and adoption support inside it. If someone asks for the technology-only figure, answer that it is a different investment with a different benefit.
5. Write the beneficiary arithmetic for your largest foundation item. What it unblocks, worth what range, and which items cannot start without it. One paragraph, kept current as the backlog changes.
6. State the three-year shape in writing before you request year one. Year one as capability and evidence with a value range, year two as the bend, year three as the compounding, and the quarter you expect to cross into net positive. Put it in the approval document, not the appendix: it is the cheapest insurance you have, and it expires the moment the money is spent.

Key Takeaways

• Diagnose the core problem as a mismatch of clocks: value compounds across three to five years while budgets arrive in twelve-month slices that must each justify themselves, which over-funds the visible 10 percent and starves the compounding 70 percent.
• Reject both bad resolutions: annual project funding starves investments that cannot pay back inside their own budget year, and an unconditional multi-year commitment either gets refused or removes the evidence discipline.
• Build the Funding Architecture instead: a multi-year envelope with annual conviction and gated tranche releases, giving the program planning runway and finance the optionality that makes multi-year approval possible.
• Separate RUN, BUILD, and EXPLORE because they behave differently, and treat the conversion of RUN costs into base budget as the single most important financial milestone, since project-funded capability loses its annual fight against exciting new initiatives every time.
• Tie releases to evidence thresholds rather than completed milestones: "the pilot ran" is activity, "the pilot met its pre-committed accuracy and cycle-time criteria" is value, and funding follows whichever you wrote down.
• Adopt the reallocation rule so money from a killed item returns to the envelope rather than the general fund, which makes kills financially painless and therefore honest, and return genuine underspend, because a program that hands money back once earns the credibility to ask twice.
• Defend the 70 percent structurally: bundle change costs inside each use case, express foundation and training in beneficiary arithmetic that names what they unblock and what it is worth, and move standing capability into base budget.
• State the multi-year shape before you spend, promising year one as capability and evidence rather than profit-and-loss impact, because a transformation judged on year-one P&L is cancelled in year one.