Pareto chart

Each bar is one cause, and its height is how often that cause happened, or how much it cost. The bars are sorted with the biggest on the left. A line above them climbs from left to right, showing the running total as a share of the whole, so by the last bar it reaches 100%.

The point of the sort is to make a pattern visible that a table hides: in most processes a small number of causes produce most of the trouble. The chart does not explain why. It tells you where to look first.

Use it when you have counted the reasons something went wrong and need to decide which to work on. Delays, complaints, rework, failed calls, returned forms: anything where each event can be put under one cause and counted.

It is the usual chart of the Analyse phase, and it is just as useful earlier, when a team is still arguing about what the problem is. A Pareto chart of real counts ends most of those arguments in a few minutes.

Do not use it to show change over time. A Pareto chart is a snapshot of one period; for whether things are getting better or worse, use a run chart or a control chart.

Do not use it when one event can have several causes at once and you count it under each. The bars then add up to more than the total, and the running line means nothing. Log the first or main cause only, and say which rule you used.

And be wary when the counts are small. With twenty events, the order of the bars can change from one month to the next by chance alone. Gather enough events for the biggest bars to be clearly bigger before you act on the order.

Read the line before the bars. Find where it crosses about 70 to 80%, and count the bars to its left. If two or three bars get you there, the problem is concentrated and the chart has done its job: those are the causes to work on.

If the line rises evenly and you need most of the bars to reach 80%, the problem is spread thin. That is a finding too. It usually means the categories are too fine, or the real cause sits upstream of all of them, and a fishbone diagram is the next step rather than a project on the first bar.

The 80/20 rule is a tendency, not a law. Do not expect exactly 20% of the causes to make 80% of the problem, and never bend the categories to make the chart look like it.

A medical ward wanted patients who were going home to leave by noon, so beds were free for the afternoon admissions. Over eight weeks, 200 discharges finished after noon. For each one the nurse in charge logged the first thing the patient was waiting for. The figures below are illustrative, built to show the method, not taken from a real ward.

Three causes, medicines to take home, transport and the discharge letter, account for 71% of the late discharges. Two of the three are work the hospital does itself, which is good news: they are in its own hands. The care package bar is smaller but slower to change, because it depends on another organisation.

What the chart does not say is just as important. It counts how often each cause happened, not how long each delay lasted. If transport delays were much longer than the others, a second Pareto chart of hours lost, rather than of events, could put transport first. Count what matters to the person waiting.

Two short calculations turn a list of counts into a Pareto chart. Stated in words first, then written out, then worked with the ward above.

List each cause once with its count. Sort the list from largest to smallest, and move any "other" row to the bottom whatever its size, because it is not one cause. In a third column, add each count to the total of the rows above it, and in a fourth, divide that running total by the grand total.

Draw the counts as columns and the running share as a line on a second axis that runs from 0 to 100%. Recent spreadsheet programs have a Pareto chart built in, which does the sorting for you, but check that it has not hidden your "other" row or sorted it into the middle.

Label the period and the counting rule on the chart itself. A Pareto chart without its dates and its definition of a cause invites the wrong argument.

In DMAIC it belongs to Analyse, where it narrows a broad problem to the few causes worth a project. It often appears in Define as well, to scope the work, and again in Control, drawn with new counts to show that the bars you worked on have shrunk.