Framework library · Decision making and problem solving
Pareto analysis
Pareto analysis counts or costs each cause of a problem, ranks the causes from largest to smallest and plots their cumulative share. In most data a few causes account for most of the effect, so the chart shows where effort pays. The 80/20 split is a tendency, not a law. The analysis is worth doing because the real shares are often different from what the team assumed.
Use it when
- You have counts or costs by cause, such as faults, complaints, outages or service credits, and need to decide where to act first.
- Effort is spread across many small fixes and you suspect a few causes drive most of the cost.
- You need to show a board or a team why one cause gets the budget and others do not.
Avoid it when
- You do not yet know the causes. Draw a fishbone diagram first, then count.
- The causes interact, so fixing one changes the others. Pareto treats causes as independent.
- The categories are vague or mostly "other". Fix the coding before ranking, or the chart ranks the coding scheme.
How to run it
Choose the effect to measure
A count, hours or money, whichever the business feels. Outage hours rank causes differently from outage counts.
Code every event to one cause
Six to ten categories, each specific enough to act on. Keep "other" below a tenth of the total.
Rank and plot
Largest first, with the cumulative share. The chart marks the 80% line and highlights the causes that fall within it.
Find the few causes that matter most
The causes that take the cumulative share to roughly 80%. Check that each can be fixed; a large cause nobody can change is context, not a target.
Fix, then run it again
After acting on the top cause, repeat the analysis on new data. The ranking should change; if it does not, the fix did not work.
Work through it
Answer the questions below, or load the worked example to see a finished one. The drawing updates as you type. Export the result as a PowerPoint deck, a Word document, an Excel workbook, a PDF or plain text.
What you type stays in this browser, so you can close the page and come back to it. It is not sent to Blue Prysm or anyone else, and the exports are made here, on your device. Privacy policy.
Mistakes to avoid
- Ranking by count when cost or duration is what matters. A rare cause with long outages can matter more than a frequent short one.
- Expecting exactly 80/20 and forcing the cut there. Use the actual curve.
- Using a month of data. Small samples rank causes by chance; use a period long enough to be stable.
- Ignoring the long tail entirely. Small causes that are cheap to fix can be worth doing alongside the big ones.
Where it comes from
In the first edition of his Quality Control Handbook (1951), Joseph M. Juran named the principle of the vital few and the trivial many after the economist Vilfredo Pareto, who had observed that a small share of people held most of the wealth. Juran later wrote that Pareto had never claimed the principle applied generally ("The Non-Pareto Principle; Mea Culpa", 1975), and came to prefer "the vital few and the useful many". Source.
Use it with
Further reading
Work through it with us
The frameworks here are free to use as they stand. If you would rather work through the question behind this one with us, these are the ways an engagement starts.