The slide is titled "AI Program: FY Budget" and it has two lines on it. The first reads "Platform, integration, and build: $470,000," and behind it sits a signed vendor contract, a schedule with 41 dated tasks, and a named engineering owner who answers for it every second Tuesday for a year. The second reads "Change management," and behind it sits a downloaded template, a fifteen-minute slot on the next all-hands, and the word "HR." No number. Asked what the change line costs, the program director says "it is mostly internal time," which the room hears as free, and which is the sentence that kills the program eighteen months later. BCG's 10-20-70 rule says roughly 10 percent of AI value comes from algorithms, 20 percent from technology and data, and 70 percent from people and process. That page proposed the inverse and nobody flinched. This lesson turns the 70 percent into a workstream with what the technology side already has: scope, a budget, a named owner, dated milestones, dependencies, and metrics.

The Arithmetic Tell

Every AI program says it takes change management seriously. Nobody has ever argued against it in a steering committee, which is exactly why the claim carries no information. The useful question is: what does your change workstream cost, who owns it, and what are its milestone dates? Three questions, thirty seconds, and the answers sort programs into two piles.

For the technology workstream you can name a number, a vendor, a plan, and a person. For the change workstream you can usually name at most a person: part time, no budget line, holding a slide deck. Technology work arrives pre-packaged with an invoice. Change work arrives as an absence, and no procurement process demands a line item for "the humans transitioning into the new way of working." So its default cost is zero, and zero is what most programs budget.

Now put BCG's ratio next to that. The 10-20-70 rule is not a statement about the importance of people, it is an allocation claim: about seventy cents of every dollar needed to convert AI capability into business value goes into people and process. McKinsey agrees from another direction: high performers, the roughly 6 percent of organizations reporting material impact, are about three times more likely to have fundamentally redesigned workflows, and workflow redesign ranks among the strongest drivers of impact. Redesign is not a software category. It is people working differently and processes documented differently, and that budget line has no number on it.

MIT's autopsy of the 95 percent of enterprise GenAI pilots that deliver no measurable profit-and-loss return supplies the mechanism. One named cause is adoption without transformation: the tool gets used, the usage chart rises, the work around it is unchanged. That is what happens when you install capability and fund nothing that moves the surrounding work. S&P Global's 42 percent of companies scrapping most of their AI initiatives in 2025, up from 17 percent, records the same failure.

Why this workstream is the one that gets deleted

The change plan is the only workstream whose absence is invisible until adoption has already failed. Skip the integration work and the tool does not connect; everyone sees it in week two. Skip the data cleanup and the model produces garbage in the first demo. Skip the change work and nothing visible happens: the launch proceeds, the dashboards look fine, and then over ten to fourteen weeks people route around it and adoption settles at a third of plan. By then the money is spent and the political capital is gone.

Invisible costs get cut first, by a finance analyst sweeping for soft line items who finds "change and enablement: $290,000" and sees a number with no invoice attached. So the job is not to argue for change management in the abstract. It is to make it structurally difficult to delete: give it the paperwork the technology workstream has, so removing it means signing your name next to the deletion of five named components, each with an owner and a milestone another workstream depends on. Paper is the defense.

The technology line has a number. Until the change line has one too, you have not taken change management seriously. You have mentioned it.

The Artifact: The Change Plan (Five Funded Components)

The artifact is the Change Plan: five components, each with an owner, a budget number, milestones tied to the roadmap's waves, and one adoption metric. Five is not arbitrary. Fewer and you have a slogan; more and it needs its own change plan. The discipline is that every component carries a number, even when the honest number is "0.3 of a person's time, formally released by their manager." A named fraction of a person is a budget. A hope is not.

Component 1: Communication (the narrative, not the announcement)

Most programs mistake communication for the launch announcement. The announcement is about four percent of the work. The rest is the narrative that keeps three audiences oriented for eighteen months, and they need different content, not one deck at three sizes.

• Executives need the portfolio view: what is in flight, what the gates decided, the technology-to-change ratio, and what is not working.
• Managers need specifics: what changes for their team, in which week, what it costs in throughput, what they must enforce. They are a delivery channel, not an audience.
• The people whose work changes need what nobody wants to write down: what their day looks like afterward, and what this means for their job.

The cadence is a monthly program note, a briefing at each wave launch, and the honest mid-course update most programs skip because the news is mixed. Skipping it feels prudent and is catastrophic: the credibility of your good news depends on having previously reported bad news. The program that published "wave 1 adoption is 61 percent against a 75 percent target, here is the fix" buys what no budget buys later: when it reports a win, people believe it.

Then the most consequential communication decision in any AI program: the job question. Everyone whose work is touched is asking "does this eliminate my role, reduce my hours, or change what I am judged on?" You will answer it either early and deliberately or by letting the rumor mill answer, which it starts doing days after the first vendor demo is seen through a conference-room window, always in the most threatening available form, because fear is the highest-engagement content ever invented. The plan needs a dated commitment to answer before wave 1 goes live.

Sizing: a named fraction of a communications professional's time, secured in writing from their manager, plus strategist hours: typically 0.2 to 0.4 of a full-time equivalent (FTE, one person working full time for the period) across the program year. The smallest money in the plan and the most often left informal, which means it evaporates the first week that person's day job gets busy.

Component 2: Training (atlas-shaped and role-based)

Training is the largest number in the change plan and the most likely to be wasted, which is why it gets its own lesson next. Here it needs sizing from evidence rather than a per-seat quote.

The arithmetic is mundane: skills gap by role, times affected headcount, times curriculum hours per role, plus the productivity dip. The gaps come from your People Readiness Atlas, specifically its work-sample results rather than its self-reports. If the self-report said 55 percent of staff were confident with AI tools and the work sample put real capability nearer 30 percent, sizing against the self-report underfunds training by nearly half and guarantees a wave 1 support crisis. Spread matters as much as the average: a best function at 52 percent against a weakest at 11 percent is two training needs on one budget line.

Then the part almost every plan omits: the ramp productivity dip is a real cost and belongs in the number. Throughput falls before it rises, and pretending otherwise means the dip is absorbed as unexplained missed targets that managers will blame on the AI program, correctly. Budget it, name it, and tell managers it is expected and temporary. A cost you predicted is a cost; a cost that surprises people is incompetence.

Sizing example, illustrative: 340 affected people across three waves, tiered into three curricula (a two-hour baseline for everyone touched, an eight-hour practitioner tier, a twenty-hour deep tier for verifiers and process owners), giving roughly 5,600 person-hours of training plus about 1,100 hours of productivity dip. That is the number that makes CFOs blink, and it is smaller than the fully loaded cost of one failed pilot, which is the thing it exists to prevent.

Component 3: Floor-Level Support (the one nobody budgets)

For the first four weeks after a wave launch, someone competent is available to the people doing the new work. Not a ticket queue, not a mailbox with a 48-hour service level. Available: a person who can be interrupted, knows the workflow, and can unstick a problem in four minutes.

Level 3 taught the floor check as an individual discipline: watch the work happening rather than reading the report about it. At program scale it becomes a staffed rota, and the champion network supplies most of that staffing. But a champion has a full-time job and has been asked to also do this. Protected time is a budget line, not goodwill. If champion hours are not an explicit release from other work, agreed by their manager in writing, you have asked busy people to be heroes, and heroism has a half-life of nine days.

Adoption curves do not break at launch; launch has energy and attention. They break in week two, when the novelty is gone, deadline pressure is back, and a user hits friction: the evidence panel does not load for a record type, or the verification step takes eleven minutes on Fridays because of a batch job. That user has thirty seconds of patience and a queue of real work. If someone competent is standing there, the friction gets fixed. If nobody is there, the user invents a workaround, because that is what professionals do when a tool fails them and the job still has to ship.

And the workaround invented in week two becomes permanent. It gets taught to the next person and written into the team's informal SOP (standard operating procedure, the documented way work is supposed to be done). Six months later an audit finds 40 percent of the volume never touches the new workflow, and unwinding it costs more than the build, because you are changing a hardened habit rather than a tool. Four weeks of staffed presence is cheap insurance.

Sizing: champions per wave, times protected hours per week, times four weeks, at loaded internal rates, plus a named escalation path into the technical team.

Component 4: Incentives and Recognition

The atlas hands you the assessment's most actionable finding, and most programs read past it. When 22 of 43 interviewees independently say some version of "the early adopters got extra work, not recognition," that is your own organization's evidence that its incentive design punishes exactly the behavior your program requires. You are asking for volunteers in an environment that has already taught people what volunteering costs, and no amount of communication overcomes a lived incentive.

The fix is cheap and structural:

• Recognition tied to verified improvement, not enthusiasm. Celebrate the team that cut rework by a measured amount, not the person who posted the most prompts. Enthusiasm-based recognition produces performative adoption, which is worse than none because it corrupts the metrics.
• The extra work counted in workload planning. If a champion gives six hours a week, six hours of something else must visibly come off their plate. That negotiation happens with function heads.
• Adoption health on the manager scorecard. What is on the scorecard is what the manager protects when the week gets tight. If adoption is not on it, adoption loses every collision with throughput, and the manager is being rational.

Two other atlas themes tell you what to design around. Where 17 of 43 say "mistakes here travel upward fast," the safest move is the old method, whose errors are familiar and forgivable. Where 15 of 43 express veterans' craft pride, that expertise becomes either your strongest verification asset or your most effective resistance, depending on whether the program treats their judgment as the thing being replaced or the thing being scaled.

Sizing: mostly free and entirely political. Recognition design costs a few hours; workload accounting costs no cash and two hard conversations with function heads measured on output. Put a zero in the budget column with a named owner and a date beside it, because a zero-cost component with no owner will not happen.

Component 5: Manager Enablement (the one that determines the rest)

Frontline and middle managers are the transmission layer, and a program that trains users but not managers has built a machine and left out the operators. Three functions make them decisive:

1. They answer the questions your communication cannot anticipate. Every carefully written FAQ meets reality as someone asking their manager, at 8:40 on a Tuesday, "does this mean they are cutting two of us?" What that manager says next is your real communication strategy.
2. They decide whether the verification gate's time budget is respected or squeezed. You costed a human review step at eleven minutes. Under quota pressure the manager decides whether eleven minutes is real. If they signal the gate is optional when the queue is long, your control becomes a rubber stamp and stays one until an incident makes it visible.
3. They set the local weather on mistakes. A team's willingness to try the new method and report what broke is set by how their manager reacted the last three times someone brought them a problem. You cannot fix that culture globally, but you can equip 18 managers to handle the first month's errors well.

Sizing: three manager sessions per wave (pre-launch, mid-wave, post-wave debrief), plus the manager's guide. The guide is not a summary of the user training. It holds the FAQ with the answers managers are authorized to give, the job-change language written by the program rather than improvised on a Tuesday, the escalation path with names and response times, and the throughput dip to expect with permission to miss the target by it.

Sequence note, and it is load-bearing: manager enablement goes before user training. A trained user reporting to an unprepared manager reverts within a month; an untrained user reporting to a well-prepared manager gets pulled along. If you can only fund one in a wave, fund the managers.

Four Structural Properties That Make the Plan Fundable

Components alone read as a wish list. Four structural properties turn them into something a program office can schedule, finance can fund, and a steering committee can govern.

Wave-coupled milestones

Every change activity is dated against a specific wave rather than floating in a quarter. Not "training in Q2" but "tier 2 curriculum complete for function A by week 11, three weeks before wave 1 go-live in week 14." The rule that makes this bite: training completes before go-live, not during it, and change readiness sits in the roadmap's dependency arrows like a data-quality task or an integration build. So a wave whose training is late slips the wave.

Programs resist that sentence, and their resistance is the diagnosis. If change readiness cannot slip a go-live, it is not a dependency, it is a preference, and preferences get compressed to zero under schedule pressure. The coupling makes change work schedulable, and schedulable work is fundable: a testable gate condition your stage-gate discipline from Chapter 4.2 already enforces.

The technology-to-change ratio, reported honestly

Compute your actual split and publish it on the quarterly page: two lines, technology and integration, change and enablement, each as a percentage of the total. Then, the part that takes nerve, report it even when it embarrasses you, with the argument for moving it and a target for next year.

A strategist reporting "we are at 62 percent technology and 38 percent change, and here is our plan to close it" is more persuasive than one claiming compliance with BCG's ratio. Everyone in the room can do the arithmetic on your budget page and will check. A published gap creates a standing agenda item; a claimed success closes the conversation. You are not trying to win an argument about a ratio, you are trying to keep a line item alive through four budget cycles. One caveat: BCG's 70 percent covers the whole transformation, including process-redesign work often booked inside project budgets rather than a change line, so state what you measured and what it excludes.

Adoption metrics, not usage metrics

Level 1 taught the usage trap on a single pilot. It returns at program scale, because these metrics are what justify the budget at renewal. If your change workstream reports license logins, its success measure is indistinguishable from the vendor's marketing dashboard. The metrics that earn renewal are behavior and outcome:

Every one costs more to collect than a login count, which is why login counts dominate the industry. The manager pulse leads the other three by roughly a month, making it the cheapest early-warning instrument you own.

Capacity collision, stated rather than hoped away

The atlas's initiative-collision calendar exists for this moment. Your change plan competes for the same scarce resource as every other transformation in the building: the attention of the same managers and senior operators. An ERP (enterprise resource planning) go-live in Q3 takes the identical hours from the identical people, and it wins, because an ERP cutover has a hard date and a bigger budget. The honest plan says so and sequences around it. Moving one function's training by six weeks costs six weeks; running it into the collision costs the training, the credibility, and the wave, and produces a meeting where someone concludes the workforce is "change fatigued," which is what we call it when we scheduled three transformations into one calendar and then blamed the team.

Worked Example: The Change Plan for Waves 0 to 2

All numbers below are hypothetical, sized for a mid-sized enterprise with 340 affected people across three waves. Use the shape and the arithmetic, not the figures.

The published ratio is therefore 62 percent technology and integration, 38 percent change and enablement. The quarterly page says exactly that, adds "BCG's benchmark implies closer to 30-70," and commits to two moves next cycle: booking wave 3's process-redesign facilitation in the change line rather than the build budget, and funding a second comms fraction.

Wave-coupled milestones

Note what week 24 encodes. Function C's training sat on the ERP cutover window the collision calendar had flagged, so the plan moves it, states why in one line, and accepts a six-week delay to wave 2's function C scope. That visible trade buys more steering-committee confidence than optimistic scheduling ever does.

The first result: week one of wave 1

Wave 1 goes live in week 14. On day three, a champion on floor-support rota watches an operator in function B open the evidence panel on a particular record type and wait. The panel takes about forty seconds for records with more than twelve linked documents, roughly one in six, and the operator has quietly started skipping it for those and approving on the summary alone. Forty seconds of latency has silently converted a designed verification gate into a rubber stamp for exactly the records most likely to be complicated.

The champion logs it that afternoon. The technical team ships a fix in nine days. Total damage: one operator, three days, no permanent workarounds.

Compare the counterfactual: nobody is on the floor, the skip becomes normal practice within two weeks, she teaches it to the colleagues who join in wave 2, and eleven months later a quality review finds approval errors clustered in complex records that no one can explain. Floor support converts luck into a function. The same catch made by accident is a story; made by a staffed rota, it is a control.

The Failure Story: The Unfunded 70 Percent

A distribution company, roughly 1,200 employees, does nearly everything right. The portfolio is well chosen: three back-office processes with volume, structure, measurable error rates, and clean cost baselines, picked on value and readiness rather than enthusiasm. The data work is real, funded, and finished before the build starts, and the integration is deep rather than bolted on. By the standards of the 95 percent, this program is in rare company.

The change budget is one all-hands, a recorded webinar, and a SharePoint FAQ page.

Nobody decided this. It is the residue of a hundred small reasonable choices: HR is stretched thin, the comms person has a product launch, the champions were "identified" but never released from anything, and training was scoped as "vendor-provided onboarding," which turns out to be a 45-minute recorded session on the interface and nothing about the changed workflow. The change line, had anyone computed it, is about 6 percent of spend.

Wave 1 launches and the tool works exactly as specified: it reads from the systems where the work lives, writes back correctly, and the outputs are good. That detail matters for what comes next.

Week two: the friction arrives on schedule. Three teams hit three small problems: a field mapping needing manual correction on about one record in nine, a slow refresh, and a report that no longer matches the downstream team's format. Each is a two-hour fix if someone competent hears about it. Nobody is on the floor, and tickets go into a three-day queue, which is nine lifetimes when the work has to ship today. So the teams invent workarounds, and the workarounds work.

Week five: the managers make their rational choice. Throughput is down, they were never told a dip was expected, adoption is not on their scorecards, and the old path still works. So they quietly permit it. Not defiance: protection, a good manager shielding their team from a program that gave them a login and no instructions.

Week eight: adoption reaches 34 percent and stalls. Not falls. Stalls, which is worse, because a falling number triggers alarm and a flat number triggers patience. The remaining 66 percent is not resistance. It is a functioning parallel process, staffed by people doing their jobs well, now taught to newcomers as the way things are done here. Unwinding it is a change program of its own, which no one will fund, because the first did not work.

Month five: the diagnosis meeting concludes, in minutes repeated for years afterward, that the tool "did not fit our workflows." This is precisely backwards. The tool fit the workflow and was integrated into it. What was never funded was the humans' transition into it: nobody explained what changed, nobody was there in week two when friction was still cheap, nobody prepared managers to hold the line through the dip, and nobody made adoption count for anyone whose performance was measured.

The line item is deleted next cycle, and the company now holds an internal belief, defended with a real example, that AI does not work in distribution operations. That belief will cost more over five years than the program did. Carry this out of the story: BCG's 70 percent is not a philosophy, it is an accounting instruction. If you spend X on technology, the people-and-process work is not a rounding error on X, it is a multiple of it.

What to Do Monday Morning

1. Draw the five components on one page with a name and a number against each. Where you do not know the number, write your best estimate and mark it as one: a wrong number starts a conversation, a blank starts nothing. Where the honest cost is zero cash, write "$0, owner: [name], date: [date]."
2. Couple every change milestone to a roadmap wave. Replace every quarter with a week number tied to a named wave, training completing before go-live. Then the harder step: get change readiness into the wave's gate criteria, so a wave whose training is late slips. The argument you get tells you how real your change plan is.
3. Compute and publish your technology-to-change ratio. Two numbers, one slide, on the quarterly page. Publish the honest figure, name the gap against BCG's 10-20-70, and commit to one move that closes part of it next cycle, especially if the number embarrasses you.
4. Protect the floor-support hours in writing before the wave launches. Not "champions will help." An email to each champion's manager naming the person, the hours per week, the four-week window, and what comes off their plate, with a confirming reply. After go-live you negotiate during a crisis and lose.
5. Put manager enablement in the plan ahead of user training, and schedule the first session for the managers whose teams are in wave 1. Bring the guide in draft: FAQ with authorized answers, job-change language, escalation path with names, and the expected throughput dip.
6. Answer the job question, in writing, with a date. If you cannot answer it fully yet, publish what you know, what you do not, and when you will know. Silence is not neutral; it is an answer written by the rumor mill in the most frightening available words.

Key Takeaways

• Test any program's change commitment with three questions: what does the change workstream cost, who owns it, what are its milestone dates. Technology work arrives with an invoice; change work arrives as an absence, so its default budget is zero unless you force a number onto the page.
• Build the Change Plan as five funded components (communication, training, floor-level support, incentives and recognition, manager enablement), each with an owner, a number, wave-coupled milestones, and one adoption metric.
• Size training from work-sample evidence rather than self-reports and count the ramp productivity dip as a real cost: an illustrative 340 people across three waves runs about 5,600 person-hours plus 1,100 hours of dip, less than one failed pilot.
• Fund floor-level support for the first four weeks after each wave launch, because adoption breaks in week two and the workaround invented then becomes permanent, taught to newcomers and hardened into practice.
• Fix the incentive your own atlas caught: when 22 of 43 people report that early adopters got extra work and no recognition, the program is asking for behavior its reward system punishes, and the repair (recognition tied to verified improvement, workload accounting, adoption on scorecards) is cheap in cash, expensive in politics.
• Enable managers before users: they answer what communication cannot anticipate, decide whether the verification gate's time budget is real, and set the local weather on mistakes.
• Couple change milestones to roadmap waves so a wave whose training is late slips, and publish the technology-to-change ratio honestly (an illustrative 62 to 38 against BCG's 10-20-70) instead of claiming compliance.
• Measure adoption with behavior and outcome metrics (in-scope work through the new path, gate adherence, workaround incidence, manager pulse) rather than license logins, and remember the failure mode's wording: a program that concludes the tool "did not fit our workflows" usually built a tool that fit perfectly and never funded the humans' transition into it.

Training is the largest number in this plan and the most commonly wasted. The next lesson is about making it change behavior rather than fill seats.