The 10-20-70 rule

What is the 10-20-70 rule?

The 10-20-70 rule is a rough split of where the work in an AI project goes: about 10 percent into the model, 20 percent into the technology and the data around it, and 70 percent into people and processes. It is a rule of thumb for planning, and the ordering is the point, not the decimals.

It inverts how AI project plans are usually written. A plan lists licences, integration work and build days, because those are the things a supplier quotes for. The 70 percent has no invoice attached to it. It is the time of people who already have a full job: the service desk that has to work differently, the team leader who decides what still gets checked, and whoever rewrites the work instruction everybody has followed for six years.

Use it as a test. If your project plan has no line for the 70 percent, you are holding a technology plan, not a project plan.

Where the rule comes from

Worth pinning down, because the rule travels almost everywhere without a source. It comes from BCG. In an article of 25 February 2022 on fixing AI and machine learning for business, David Galley, Nicolas de Bellefonds and Sylvain Duranton wrote that companies should weigh the business value of AI through a 10-20-70 formula: 10 percent of the effort in building an adequate machine learning model, 20 percent in high quality data and technology implementation, and 70 percent in developing new business processes or transforming the way business functions operate. BCG has kept using it, in its leader's guide of 12 December 2024 and in the AI Radar of 15 January 2025.

What does not exist behind the numbers is a study. Second-hand write-ups routinely present the split as a research result. One from April 2026 says BCG studied AI implementation across organisations and found it, then names no article, no year and no method. BCG introduced it as a way of weighing effort, and that is how to pass it on.

People also flip the numbers to 70-20-10, which is the name of a different model entirely: the Center for Creative Leadership's finding that leaders learn roughly 70 percent from hard assignments, 20 percent from other people and 10 percent from courses. If the person across the table means training, they mean that one.

What is in each bucket

The 10 percent is the model. Which model you pick, the prompt or the fine-tuning, and the evaluation set that says whether the output is good enough. For ordinary company work in 2026, reading a document or drafting a reply, this is the cheapest part, because the models on the shelf already do it.

The 20 percent is the technology and the data. Connections to the ERP, the mailbox and the file share, access rights so the model sees the price agreements and not the payroll, and logging so you can reconstruct what it did. A supplier can quote this, because it has edges.

The 70 percent is people and process. Rewriting the work instruction so the output is the start of the work and not an extra screen. Training people and letting them be slow at it for a fortnight. Agreeing who checks what. Changing the numbers a team is measured on, because a target written for the old way gets defended. And dealing with the people who liked the old way, a few of whom have reasons you have not heard yet.

Where the 70 percent goes wrong

Nothing measures the 70 percent, but the research into failed projects keeps pointing at it. RAND interviewed 65 data scientists and engineers for a report published on 13 August 2024, and the leading root cause they found was that stakeholders misunderstand or miscommunicate the problem to be solved, so models end up optimised for the wrong metric or do not fit the workflow they land in. The same report cites estimates that more than 80 percent of AI projects fail, about twice the rate of IT projects without AI. Three shapes turn up again and again.

A working tool nobody opens. Four months in, two of six people use it. The rest went back to their own template because the signature block came out wrong in week one and nobody owned fixing it.

The old step that keeps running beside the new one. The model drafts the reply and a colleague still reads every reply before it goes out, because that control was never formally dropped. The work happens twice and handling time falls by a minute instead of five.

The manager whose number gets worse. A team measured on tickets closed per person looks worse in the first month of any change, and the team leader gets to explain that upstairs. Nobody sabotages anything. The pilot simply keeps being scheduled around the busy weeks. If the new way makes somebody's reported number drop, change the number or expect the change to lose.

The same project, budgeted twice

A manufacturer with 70 staff wants an assistant that drafts replies to customer questions. Six people handle about 1,400 mails a month at 9 minutes each, so 210 hours. Both plans below spend 40,000 euro. The difference is what the money is for.

A technology plan

Licences and model usage for a year, 9,000 euro. Mailbox and ERP integration, 22,000 euro. Prompt work and quality testing, 9,000 euro. Every line buys something that gets delivered and switched on, and the integration line grew to fill the budget because it was the only place in the plan where money could go.

A change plan

Model, prompts and an evaluation set of 200 real questions, 4,000 euro. Integration, access rights and logging, 8,000 euro. Then 28,000 euro of people and process: rewriting the service desk instruction, two half days of training plus a fortnight of shadowing for six people, a written rule for which categories go out without a second reading, a reset team target for the first quarter, and a monthly half day to flag bad drafts and adjust the prompt. Most of that 28,000 is internal hours rather than an invoice, which is why it drops out of plans.

What the missing 70 percent cost

This company ran the first plan. The tool worked from week two, nobody rewrote the instruction, the second reading stayed in place, and handling time went from 9 minutes to 8. That is 23 hours a month for 40,000 euro, and at the budget meeting it read as a failure of the technology. The repair took about 15 days over two months and none of it was technical: rewrite the instruction, drop the second reading for the four question types where the draft had been right in 95 of 100 sampled cases, reset the weekly target. Handling time landed at 4 minutes, so 93 hours a month against 210. Those 117 hours were available the whole time, behind the work nobody had budgeted.

The rule in a company of fifteen

In a large organisation the 70 percent is a programme, with a change team, a training curriculum and a steering committee. In a company of fifteen it is a conversation with four people in the room, and that is an advantage rather than a consolation prize. The process owner is sitting there, and so is the person whose target has to change. Within a week you know whether people work the new way, because you can see them. What does not shrink is the substance: the instruction still has to be rewritten, the checking rule still has to be on paper, and somebody still owns the process after go-live. Being small makes that days instead of months, and the trap is assuming it therefore costs no time.

What to watch out for with the 10-20-70 rule

It is a rule of thumb, not a measurement. Do not put it in a business case as a finding. If somebody asks where the 70 comes from, the true answer is that an advisory firm wrote it down in 2022 and it stuck because it matches what people see.

It is not a euro allocation. Spending 70 percent of an external budget on change work mostly buys presentations. The 70 percent is internal time, so respect it by naming the days and the people, not by moving money to a supplier.

It is not a schedule. The 10 and the 20 mostly happen before go-live, and the 70 keeps running after it, which is why a project that ends the day the tool is switched on has skipped most of the work.

It does not say the technology is easy. A 10 percent share of the effort is not a 10 percent chance of trouble. It says the model is rarely the reason a finished project produces nothing, which is a different claim.