Two spreadsheets tell this whole story. The first is a pilot budget the way a steering committee approved it: $150,000 for licenses, $45,000 for integration, $15,000 for a kickoff with lunch, and a line called "change management" that somebody typed, looked at, and deleted because the total was getting uncomfortable. The second spreadsheet is the same pilot budgeted the way the work actually demanded, and it has seven more lines: training by role, SOP rewrites, verification capacity, champion time, floor support for the first twelve weeks. The second spreadsheet was never written, so it was never approved, so the first one went to war alone and lost. Boston Consulting Group compressed this pattern into three numbers that this program treats as arithmetic rather than opinion: in a successful AI transformation, roughly 10 percent of the effort is the algorithms, 20 percent is technology and data, and 70 percent is people and process. Organizations fund the 10, underfund the 20, starve the 70, and then hold a meeting to ask why the 10 is not performing.

The Arithmetic Behind the Failure Record

Chapter 1 gave you the failure record: MIT's finding that 95 percent of enterprise GenAI pilots produce no measurable P&L return, S&P Global's 42 percent of companies scrapping most of their AI initiatives in 2025, Gartner's abandonment forecasts stacking up behind them. It also gave you MIT's autopsy of the causes: no workflow integration, no learning loop, adoption without transformation. Look at that cause list again with fresh eyes. Workflow integration is process work. Learning loops are process and people work. Transformation is, by definition, people and process work. Every cause MIT documented lives in the 70 percent. Not one of them lives in the algorithm. The failure record from Chapter 1 is not a mystery that the 10-20-70 rule helps explain; it is the 10-20-70 rule, photographed at the crime scene. The starved 70 is what "no measurable return" looks like from the inside.

This lesson opens Chapter 3, the readiness lens: people, process, data, governance. The lens says readiness is a property of the organization, not the model, and 10-20-70 is that lens translated into the one language every steering committee already speaks, which is budget. If you can read a pilot's budget, you can predict its autopsy, usually before the kickoff lunch is catered. The four lessons after this one walk the faces of the lens in turn: data readiness and why 63 percent of organizations do not have it, then process, people, and governance readiness, each with its own diagnostic.

One precision note before we go further, because this program does not do slogans. The BCG rule describes the distribution of effort in transformations that succeed. It is not a law of physics and the boundaries between layers are judgment calls; a data pipeline rebuild has process work inside it, and training has technology dependencies. Use the rule the way you use any planning ratio: as a sanity check with teeth. When a proposed budget says the ratio is 80-15-5, the burden of proof is on the budget, not on BCG.

What Each Layer Actually Contains

The rule only becomes a tool when you can sort real line items into the three layers without hesitating. So let us unpack each layer in operator terms.

The 10: algorithms

This is the model and its immediate configuration: selecting the tool or model, writing and testing the prompts, setting parameters, choosing between vendor A and vendor B, tuning outputs for your document formats. It is the layer with all the demos, all the vendor attention, and nearly all the press coverage. It is also, and this is the point everyone resists, largely a solved problem from the buyer's side. You do not build the model; you select and configure it. Competent prompt and configuration work on a departmental pilot is measured in days and weeks, not quarters. The 10 is called the 10 because that is roughly what it deserves.

The 20: technology and data

This is the plumbing: data pipelines that feed the tool clean, current inputs; integration so the tool reads from and writes to the systems where work actually lives (remember from Chapter 1 what happens when a human becomes the manual data bridge); security and access controls; the platform and environment the whole thing runs on. The 20 is real engineering with real cost, and it is chronically underfunded too, which is why the next lesson is devoted entirely to data readiness. But at least the 20 is visible: it produces invoices, tickets, and architecture diagrams, so procurement and IT know it exists.

The 70: people and process

This is everything that makes a working tool into a working operation, and it is worth listing slowly because every item on this list is a budget line that most pilot budgets do not contain. Workflow redesign: redrawing the process map so the AI step has defined inputs, a defined destination, and a named verifier, instead of floating beside the swimlanes. Training: not a one-hour webinar, but role-specific instruction in how each job changes, with practice time. Incentives: adjusting the KPIs and scorecards so that using the new workflow is rewarded rather than quietly punished by unchanged productivity targets. Verification routines: the standing capacity to check AI output, because the job shifted from producing the draft to verifying the draft, and verification takes minutes that must come from somewhere. Role changes: rewriting job descriptions, RACI charts (who is Responsible, Accountable, Consulted, Informed), and approval paths that the new workflow invalidates. Communication: a cadence of honest updates, not one launch email. And floor-level support: champions, office hours, and someone to sit with the confused underwriter in week three, because week three is where adoption curves go to die.

You can buy the 10 with a purchase order. The 70 has no vendor, so it must be budgeted, staffed, and led, or it simply does not happen.

Why the 70 Is Invisible in Procurement

Here is the structural reason the 70 gets starved, and it has nothing to do with anyone being stupid. Organizations acquire things through procurement machinery that is built to buy objects from sellers: a license, an integration contract, a consulting engagement. The 10 fits that machinery perfectly. A vendor exists, a quote arrives, a purchase order is cut, and the finance system now contains proof that AI transformation is happening. The 20 fits partially: integration and infrastructure produce statements of work. But the 70 has no seller. Nobody sends you a quote for "your claims supervisors will spend four hours a week coaching the team through the new workflow for a quarter." There is no PO for "we will rewrite eleven SOPs" (standard operating procedures, the documents that define how work is actually done). The 70 is made almost entirely of your own people's redirected time, and redirected time never arrives as an invoice. It arrives as a fight about priorities, which is exactly the fight the pilot sponsor is least eager to schedule.

So the budget forms around what can be bought, and the effort estimate quietly inverts. The visible 30 percent absorbs 90-plus percent of the funding; the decisive 70 percent gets a kickoff and good intentions. Notice the trap's elegance: nobody decided to skip change management. The purchasing machinery simply had no slot for it, and the machinery's output got mistaken for a plan.

The 10 percent trap: upgrading the model to fix the organization

The trap has a second act, and you have probably watched it. The starved-70 pilot stalls: usage decays, outputs go unverified, the process map is unchanged. The steering committee asks what is wrong, and the answer that comes back is the answer the machinery can act on: the model. Upgrade to the newer version. Switch vendors. Add a premium tier. Each of these is another purchase order, which means each of these is buying more 10 to fix a 70 problem. The new model demos better, the same unredesigned workflow rejects it the same way, and eighteen months later the organization has cycled through three tools and concluded that AI does not work in our industry. It is the restaurant from Chapter 1 buying a third fast oven while the tickets are still shouted across the kitchen. When you hear "the model just isn't quite there yet" about a pilot whose budget was 90 percent licenses and integration, you are not hearing a technology assessment. You are hearing the 70 percent describing its own absence in the only vocabulary the room permits.

Where the High Performers Live

If the 70 is where pilots die, it should also be where the winners are visibly camped, and the evidence says exactly that. McKinsey's State of AI research draws the sharpest line: 88 percent of organizations now use AI somewhere, but only about 39 percent report any EBIT impact at all, and the small group of high performers (roughly 6 percent) is about three times more likely than the rest to have fundamentally redesigned workflows around AI. Fundamental workflow redesign is not a 10 activity or a 20 activity. It is the purest possible 70 activity: process maps redrawn, roles changed, handoffs rebuilt. McKinsey's research also finds impact concentrating where senior leadership personally owns the transformation rather than delegating it to an innovation team, which is another 70 signal, because sponsorship, priority-setting, and incentive changes are leadership work that no vendor can perform on your behalf.

Read those findings next to MIT's 95 percent and the picture closes: the organizations getting nothing bought the 10 and waited; the organizations getting EBIT impact did the 70 and treated the 10 as an ingredient. Same models. Same vendors, often. The difference is the distribution of effort, which is to say, the difference is the second spreadsheet, the one almost nobody writes. So let us write one.

Re-Budgeting Alderline: The 70 Percent, Priced

Here is the worked example, a composite built from the standard failure pattern, with a fictional company and realistic numbers you can adapt. Alderline Insurance, a 1,200-person regional carrier, ran a pilot to draft claims correspondence: the letters and status updates that claims handlers write dozens of times a day. The approved budget was $210,000: $150,000 in annual licenses, $45,000 for integration with the claims platform, $15,000 for kickoff and launch communications. That is 93 percent of the money on the 10 and the 20, and one line, the kickoff, gesturing at the 70. Ten months later the pilot is stalled in the familiar posture: usage down to a handful of enthusiasts, handlers pasting policy details in by hand, two incidents where a draft misstated a coverage term and nearly went out unverified, and a steering committee debating a model upgrade. You have seen this autopsy before; Chapter 1 taught you to run it. This lesson asks a different question: what would the honest budget have been?

Rebuild it line by line, pricing the work the pilot actually demanded. Keep the licenses and integration; they were never the problem.

Walk through the new lines, because each is an estimate you can reproduce. Training: 140 handlers at 4 hours each plus supervisors at 8, plus design of the materials, at loaded internal rates, lands near $38,000. Workflow and SOP work: a process analyst and a claims lead for roughly six weeks, redrawing the map so every AI draft has a named verifier and a defined route, plus 11 SOP rewrites at 10 to 14 hours each, is about $52,000. Verification: the honest one. If handlers send 900 drafts a week and verification averages 3 minutes each, that is 45 hours a week of new work, and funding it for the first six months, tapering as trust and error data accumulate, prices near $31,000. Champions and communication: two handlers at 20 percent time for a quarter, plus supervisor briefings and a weekly honest-update note, about $18,000.

Now check the shape. The vendor license is a price, not an effort, so set it aside and look at the work the organization itself performs: $9,000 of algorithm-layer effort, $45,000 of technology and integration effort, $139,000 of people and process effort. That is a 5-23-72 split. BCG's arithmetic did not need to be imposed on this budget; it emerged from simply pricing the tasks the pilot required to survive. The approved budget's split of that same internal work was, effectively, zero-something-nothing, with a kickoff.

And here is the punchline, which is the entire lesson in one sentence: the honest budget was never rejected. It was never approved because nobody wrote it, so the dishonest budget failed in its place, at full price, plus ten months, plus the two near-miss coverage letters, plus the credibility of the next proposal. $343,000 spent as the work demanded had a path to the 5 percent. $210,000 spent as the machinery allowed was a $210,000 purchase of membership in the 95.

The Artifact: The 70% Line-Item List

This lesson's artifact is the checklist that writes the second spreadsheet. It is the set of line items most commonly missing from AI pilot budgets, each with its unit of estimation, so that "change management" stops being one vague line that gets deleted and becomes twelve to fifteen lines that can each be priced, challenged, and defended. Take it into any budget review: for every line, either a number goes in or someone signs their name to the claim that this initiative uniquely does not need it.

Three usage notes. First, the units matter more than the totals: a budget that says "$38,000 training" invites haggling, but one that says "154 people x 4 to 8 hours x loaded rate" invites only arithmetic, and arithmetic is much harder to delete. Second, items 7 through 9 are the ones that surprise finance every time, because verification feels like it should be free; Chapter 1's learning gap explains why it is not, and until a real feedback loop exists, verification is a standing cost, not a launch cost. Third, if a proposed pilot budget contains fewer than half of these lines, you are not looking at a transformation budget. You are looking at a shopping list, and the failure record from Chapter 1 is a census of shopping lists.

What to Do Monday Morning

The rule becomes leverage the first time you apply it to a live budget, and you almost certainly have access to one.

1. Get one AI initiative's budget in front of you: a proposal in flight, a running pilot, or last year's stalled one. A single page of line items is enough.
2. Sort every line into 10, 20, or 70 and compute the split. Set vendor license fees aside and compute it again on internal effort only; that second ratio is the honest one.
3. Run the 70% Line-Item List against it. Mark each of the fifteen items present, absent, or hand-waved. Count the absences; that number is your headline.
4. Price the three biggest absences using the units in the list. Training, verification capacity, and SOP rewrites are usually the largest and the easiest to defend, since each is just headcount times hours times rate.
5. Bring the second spreadsheet to the next review and ask the question this lesson armed you with: "This budget funds the 10 and the 20; who is funding the 70, and if the answer is nobody, are we choosing to fail at a discount?" Say it more politely than that, but say it.
6. Watch for the 10 percent trap in the wild. The next time a stalled pilot's remedy is a model upgrade, ask what the upgrade changes about training, verification, or the process map. If the answer is nothing, the purchase is anesthetic, not treatment.

Key Takeaways

• Treat BCG's 10-20-70 as the program's arithmetic: in transformations that succeed, roughly 10 percent of effort goes to algorithms, 20 to technology and data, and 70 to people and process.
• Recognize the failure record as the rule's photograph: MIT's documented causes (no workflow integration, no learning loop, adoption without transformation) all live in the starved 70, none in the algorithm.
• Sort line items by layer without flinching: model selection and prompts are the 10; pipelines, integration, security, and platform are the 20; redesign, training, incentives, verification, role changes, communication, and floor support are the 70.
• Expect procurement to starve the 70 structurally: purchase orders can buy the 10 and much of the 20, but the 70 has no vendor and arrives only as your own people's budgeted, defended time.
• Name the 10 percent trap when you see it: upgrading the model to rescue a starved-70 pilot is buying more 10 to fix a 70 problem, and it produces serial tool churn, not transformation.
• Follow the high performers into the 70: McKinsey's top group is about three times more likely to fundamentally redesign workflows, with senior leadership owning the change rather than delegating it.
• Price the 70 in units, not vibes: hours per role for training, minutes per output for verification, hours per SOP for rewrites; arithmetic survives budget reviews that vague lines do not.
• Run the 70% Line-Item List against every AI budget you can reach; a budget with fewer than half its fifteen lines is a shopping list, and shopping lists are what the 95 percent bought.