The 1-10-100 Rule: Origin, Meaning, and What It Actually Proves
Updated September 2026. Sources: Labovitz & Chang, Making Quality Work (Harper Business, 1992); IBM Systems Sciences Institute defect-cost material; Boehm, Software Engineering Economics (1981).
The rule in one paragraph
The 1-10-100 rule states that it costs about $1 to prevent a defect at the source, about $10 to correct it once it has entered your process, and about $100 once it reaches the customer as a failure. It was codified by George Labovitz and Yu Sang Chang in Making Quality Work (1992) as a total-quality-management expression of the prevention-appraisal-failure cost structure. The three numbers are an order-of-magnitude heuristic, not measured constants; the real ratios vary by defect class and process maturity. What is durable is the direction: a defect gets roughly ten times more expensive each time it survives to a later stage. In software, that is the case for shift-left testing, design review, and clear requirements.
Where the rule comes from
The specific 1-10-100 framing was put into print by George Labovitz and Yu Sang Chang, with Victor Rosansky, in Making Quality Work: A Leadership Guide for the Results-Driven Manager (Harper Business, 1992). Labovitz and Chang ran Organizational Dynamics Inc., a total-quality-management consultancy, and the rule was their compact way of teaching the economics behind the prevention-appraisal-failure model that Joseph Juran and Armand Feigenbaum had established decades earlier. The idea it expresses is older than the name: the cost of a quality problem rises steeply the longer it goes uncaught.
The rule has since been adopted well beyond its origin, most heavily in data-quality writing (where the three stages become the cost per bad record: prevent, cleanse, or suffer the downstream failure). The engineering version is the same shape applied to defects rather than records. Because the rule travelled so widely, it is frequently attributed to whichever source the writer knows best, which is how it came to be conflated with two separate pieces of software research.
Three threads that all point the same way
The 1-10-100 rule is regularly cited alongside two software-specific datasets. They are not the same thing, and getting the attribution right is part of using the rule honestly.
| Thread | Source | What it actually says |
|---|---|---|
| The 1-10-100 rule | Labovitz & Chang, 1992 | Prevent $1 / correct $10 / fail $100, as a TQM teaching heuristic |
| IBM SSI defect multipliers | IBM Systems Sciences Institute | Roughly 1x design, 6.5x implementation, 15x test, up to 100x maintenance; from internal material, not a peer-reviewed study |
| Boehm cost-of-change curve | Boehm, 1976 / 1981 | Field data from TRW and others; ratios from about 1:5 to 1:200 by phase and project type |
The honest reading: the 1-10-100 rule is the memorable heuristic, the IBM SSI figures are a widely repeated but weakly documented table, and Boehm's curve is the piece with the most rigorous underlying data. They converge on the same direction, which is why the rule is durable, but only Boehm's work carries measured field data behind it. The full account of that data is on the Boehm cost-of-change curve page.
How the rule maps to software rework
The 1-10-100 rule is the same prevention-appraisal-failure structure the PAF cost-of-quality model uses, compressed into three numbers. Mapping the stages onto engineering work makes the argument concrete:
- $1, prevention. Clear requirements, design review, architecture decision records, threat modelling for sensitive features, test-driven development, and accessibility considered at design time. This is the cheapest dollar in the model. The unclear-requirements page covers the single highest-ROI prevention investment for most teams.
- $10, internal failure. Rework caught in development, code review, or QA before release: a bug found in testing, a design flaw caught in review, a failing pipeline. Real cost, but contained, because nothing has shipped.
- $100, external failure. The defect reaches production: an incident, a hotfix, support load, a security disclosure, or reliability-driven churn. This is where the cost of the failure itself, not just the fix, lands on the business.
The practical takeaway is the same one the whole cost-of-quality literature reaches: the highest-leverage spend is at the $1 stage, because every dollar there removes a defect that would otherwise cost ten or a hundred times more downstream. To turn the heuristic into your own team's number, the COPQ calculator decomposes rework into the four PAF buckets, and the rework cost formula gives three methods for measuring it directly.
How the rule is misused
The rule is genuinely useful and genuinely abused. Three misuses to avoid:
- Treating 1, 10, and 100 as precise. They are an order-of-magnitude heuristic. Boehm's field data ranged from roughly 1:5 to 1:200; modern CI/CD teams often see much flatter slopes because a defect caught minutes after a commit barely costs more than one caught at design. Quote the direction, not the digits.
- Using it to justify infinite up-front design. The rule argues for cheap early prevention, not for a heavyweight waterfall. Boehm and Basili's 2001 revision explicitly walked back the waterfall reading: the cost gradient flattens under strong CI/CD, which favours fast feedback over exhaustive up-front specification.
- Citing the numbers with no source, or the wrong one. Most repetitions of the rule attach it to whichever name the writer knows. The careful citation names Labovitz and Chang for the heuristic, and Boehm for the field data, and flags the IBM SSI figures as widely repeated but weakly documented.
None of this makes the rule wrong. It makes it a heuristic, which is what it was always meant to be. The direction (defects get dramatically more expensive the later they are caught) is one of the most consistently reproduced findings in the cost-of-quality literature, and it holds in physical construction too, where rework runs 4 to 12% of project value and front-end planning earns the same prevention payback.
Sources
- Labovitz, G. and Chang, Y.S., with Rosansky, V. Making Quality Work: A Leadership Guide for the Results-Driven Manager. Harper Business, 1992. (Origin of the 1-10-100 framing.)
- IBM Systems Sciences Institute. Relative Cost of Fixing Defects. Widely cited defect-cost multipliers (roughly 1x / 6.5x / 15x / 100x); reportedly from internal IBM material rather than a peer-reviewed study.
- Boehm, B. Software Engineering. IEEE Transactions on Computers, C-25(12), 1976.
- Boehm, B. Software Engineering Economics. Prentice-Hall, 1981.
- Boehm, B. and Basili, V. Software Defect Reduction Top 10 List. IEEE Computer, January 2001.
- Juran, J.M. Quality Control Handbook (1951) and Crosby, P. Quality Is Free (1979), for the underlying prevention-appraisal-failure cost structure.
Frequently asked questions
What is the 1-10-100 rule?▼
A quality-management heuristic: about $1 to prevent a defect at the source, $10 to correct it once it is inside your process, and $100 once it reaches the customer as a failure. The numbers are an order-of-magnitude rule of thumb; the point is that defect cost escalates by roughly ten times each time it slips to a later stage.
Who created the 1-10-100 rule?▼
It was codified by George Labovitz and Yu Sang Chang (with Victor Rosansky) in Making Quality Work (1992), as a TQM expression of the prevention-appraisal-failure cost structure. It is often conflated with the IBM SSI defect multipliers and Boehm's cost-of-change curve, which are separate pieces of software research pointing the same way.
Is it the same as the IBM SSI defect multipliers?▼
No. The IBM Systems Sciences Institute figures (about 1x design, 6.5x implementation, 15x testing, up to 100x maintenance) are a separate defect-cost table, reportedly from internal IBM material rather than a peer-reviewed study. They land near the 1-10-100 rule and are cited alongside it, but they are a different artefact.
How does it map to software rework?▼
$1 is prevention (design review, clear requirements, TDD); $10 is internal failure (rework caught in development or QA before release); $100 is external failure (production incidents, hotfixes, support load, churn). It is the same prevention-appraisal-failure structure as the PAF cost-of-quality model, compressed into three numbers.
Are the 1, 10, 100 numbers literally accurate?▼
No. They are an order-of-magnitude heuristic. Real ratios vary widely: Boehm's 1981 data ranged from about 1:5 to 1:200, and modern CI/CD teams often see much flatter slopes. In safety-critical or regulated settings the escalation can run far beyond 100. Use the rule as a directional argument, not a dollar prediction.
Why does the cost escalate by roughly ten times per stage?▼
Because a defect caught later drags more accumulated work with it. A requirements error caught in requirements is a sentence to rewrite; caught in production it means re-opening design, re-coding, re-testing, coordinating a release, and often absorbing the cost of the failure itself. Each surviving stage adds another layer of work to undo and redo.
Related pages