# Pareto Chart

**URL:** https://kaizumi.com/dictionary/pareto-chart

**Description:** A Pareto chart sorts bars tallest to shortest and adds a running-total line. In the 400 complaints worked here, four of eight cover 85%.

**Category:** lean-tools

**Tags:** problem-solving, quality, metrics

## Reading the chart | How to read a Pareto chart

A Pareto chart has five main parts. Once you know what each part does, the chart is easy to read. Two of the five are easy to set up incorrectly in software, which is how a chart can look finished and still be unreadable.

We will use one dataset throughout this page: `400` customer complaints logged over a year, sorted into eight categories. The same chart works for defect types, downtime reasons, missed appointments, or rejected claims.

```kz-figure
id: anatomy
caption: The five marks, drawn to scale. The tinted band is the vital few: every bar up to and including the one that crosses the 80% line.
wide: true
```

1. **The bars, sorted from tallest to shortest.** Sorting is what makes a Pareto chart different from a standard bar chart. It puts the largest category first so you can immediately see where most of the volume sits.
2. **The left vertical axis.** This shows the raw count, running from `0` up to your grand total. In our example, that total is `400`—not `152` (the height of the first bar) and not a rounded number like `500`.
3. **The right vertical axis.** This shows percentages, running strictly from `0`% to `100`%. No other range is valid.
4. **The cumulative percentage line.** This line shows a running total. Each point adds the current bar's percentage to the sum of the bars before it. The first point sits at `38`% (the first bar's share), and the final point reaches exactly `100`%.
5. **The `80`% reference line.** This horizontal line runs across the chart at `80`%. Look at where the cumulative line crosses it. The bars to the left of that crossing point are the vital few, the ones worth your time. The bars to the right are the trivial many.

### The two axes have to agree

The left and right axes measure the exact same data using two different units: raw counts on the left and percentages on the right. When set up properly, the chart is easy to verify. The left axis should end at your grand total (`400`), and the right axis should run from `0`% to `100`%. When both scales match, the first point on the cumulative line will sit at the exact same height as the top of the first bar.

You can check any Pareto chart in about ten seconds. Look straight across from the top of the first bar. If the first point of the line sits above or below the top of that bar, the two vertical scales do not match. If the scales do not match, every crossing you read off that chart sits in the wrong place.

```kz-callout
tone: warn
title: Set the percentage axis by hand.
p: Spreadsheets auto-scale it. Excel will run the axis up to `120`% to make the line fit, which drags the `80`% gridline down to where `67`% really sits. Open the secondary axis, set the minimum to `0` and the maximum to `100`, and turn auto off. This is the most common way a Pareto chart gets drawn wrong.
```

The second common mistake is where the cumulative line starts. The first point on the line must equal the first bar's individual share, which is `38`% in our data. If the line starts at `0`% and only reaches `38`% above the second bar, every point on the line has been shifted one category to the right.

When that happens, the line will cross `80`% over the fifth bar instead of the fourth. That makes you assign work to five categories when four are enough. One cell fixes it: set the first cumulative value to the first category's percentage rather than to zero.

### Where the Other bar goes

If your data includes a catch-all category like Other, Miscellaneous, or Unknown, always place it at the far right. Keep it at the end no matter how tall it is. An "Other" bar is a combination of unrelated issues, not a cause you can investigate and solve, so it cannot be a priority. If you sort it by size and place it near the front, you put an unfocused group at the top of your project list.

In our dataset, Other accounts for `8` out of `400` complaints, which is small enough to set aside. A tall Other bar is a different problem, and it has its own fix further down this page.

```kz-qa
q: How do you calculate the cumulative percentage line on a Pareto chart?
a: Divide each category's count by the grand total to get its share. Then add that share to the running total of the shares that came before it. Here `152` ÷ `400` = `38`%, then `38` + `24` = `62`%, then `62` + `13` = `75`%, on to exactly `100`%.
q: What is the difference between a Pareto chart and a bar chart or a histogram?
a: A bar chart shows categories in any order you like. A Pareto chart sorts them tallest to shortest and adds a running-total line, so it answers which few matter instead of how big each one is. A [histogram](/dictionary/histogram) is different again. Its bars are numeric ranges in numeric order, and you must never sort them, because the shape of the spread is the point.
q: Where does the Other bar go on a Pareto chart?
a: Last, always, even when it is taller than the bars to its left. Ranking it by height puts a bucket nobody can act on at the front of the queue.
```

The Pareto chart is one of the [seven quality tools](/guides/six-sigma-tools). It shows you where to use the other six.

## The table | How to build a Pareto chart

You do not need special software to build a Pareto chart. The chart comes directly from a four-column table that you can build from a tally sheet with a calculator, or in a spreadsheet.

```kz-formula
expr: Share % = (n ÷ N) × 100
expr: Cumulative % = Σ shares to this row
var: n | **This category's count.** Billing error is `152`.
var: N | **The grand total** of every category, `400`. Never a subtotal, and never the tallest bar.
var: Σ | **Running sum.** This row's share plus every share that came before it. The last row is `100`%.
```

The workflow takes four steps: count the occurrences, sort the categories from largest to smallest, calculate each category's percentage of the total, and add up the running total row by row.

| Category | Count | Share | Cumulative |
|---|---|---|---|
| Billing error | `152` | `38`% | `38`% |
| Late delivery | `96` | `24`% | `62`% |
| Wrong item | `52` | `13`% | `75`% |
| Damaged in transit | `40` | `10`% | `85`% |
| Missing part | `24` | `6`% | `91`% |
| Rude service | `16` | `4`% | `95`% |
| Website error | `12` | `3`% | `98`% |
| Other | `8` | `2`% | `100`% |
| **Total** | `400` | `100`% | — |

Column two provides the bar heights for the left axis. Column four provides the points for the line on the right axis. That is the whole mapping.

```kz-tiles
lead: Vital few
tile: Categories | 8
tile: Vital few | 4
tile: Covered | 85 | %
```

To find your primary categories, check where the cumulative column passes `80`%. The first three categories add up to `75`%, which falls short of the target. Adding the fourth category brings the total to `85`%. That means four out of the eight categories account for `85`% of all complaints.

This makes our dataset a 50/85 split: `50`% of the categories generate `85`% of the complaints. The `80`/`20` figure comes from Vilfredo Pareto and his note on who owned the land in Italy. Joseph Juran built the chart later and named it after him.

Neither man wrote a law about your data, and real data will rarely match an exact 80/20 ratio. In some processes, a single category causes more than half of all issues. In others, you need six out of eight categories to cover `80`% of the total. Add up your own column, then quote your own ratio instead of the slogan.

The core principle still holds: categories in a process almost never carry equal weight. If all eight categories were identical in size, each would represent `12.5`% and the cumulative line would be a straight diagonal. In practice, the line curves sharply upward on the left and flattens out toward the right. The categories under that steep initial curve are the ones to work on first.

## Choosing a unit | Pareto chart by count or cost

Before sorting your data, decide what unit of measurement you want to analyze. You can look at counts, financial costs, lost hours, or days of delay. The unit you select determines which category appears first, and different units often point to different priorities.

Here is the same dataset of `400` complaints across the same eight categories, with no record re-counted. This time, each category is multiplied by the average cost to resolve it, including refunds, replacement shipments, and administrative time.

| Category | Count | Cost each | Cost | Share | Cumulative |
|---|---|---|---|---|---|
| Damaged in transit | `40` | `$145` | `$5,800` | `29.0`% | `29.0`% |
| Wrong item | `52` | `$100` | `$5,200` | `26.0`% | `55.0`% |
| Late delivery | `96` | `$50` | `$4,800` | `24.0`% | `79.0`% |
| Billing error | `152` | `$15` | `$2,280` | `11.4`% | `90.4`% |
| Missing part | `24` | `$50` | `$1,200` | `6.0`% | `96.4`% |
| Rude service | `16` | `$25` | `$400` | `2.0`% | `98.4`% |
| Website error | `12` | `$10` | `$120` | `0.6`% | `99.0`% |
| Other | `8` | `$25` | `$200` | `1.0`% | `100.0`% |
| **Total** | `400` | — | `$20,000` | `100`% | — |

```kz-pass
title: Pass 1 — ranked by how often it happens
step: Top bar = Billing error, **152** of 400
step: Its share = 152 ÷ 400 = **38.0%**
step: Four bars to clear 80% → **85.0%**
out: Fix billing first. **Damaged in transit** sits fourth, at `10`% of complaints.
```

```kz-pass
title: Pass 2 — ranked by what it costs
step: Top bar = Damaged in transit, **$5,800**
step: Its share = 5,800 ÷ 20,000 = **29.0%**
step: Four bars to clear 80% → **90.4%**
out: Fix packaging first. **Billing error** falls to fourth, at `11.4`% of cost.
```

```kz-figure
id: rank-flip
caption: The two rankings, side by side. Billing error drops from first to fourth. Damaged in transit climbs from fourth to first.
wide: true
```

Billing errors account for `38`% of all complaints but only `11.4`% of the total expense. Damaged in transit makes up only `10`% of complaints, but it represents `29.0`% of the total cost. Shipping damage affects less than one-third as many customers as billing errors, but each case costs nearly ten times as much because you must replace the product, pay for new shipping, and often issue a refund.

Notice what stays the same between both passes. Four categories are still needed to clear `80`% in both tables (`85.0`% by count, and `90.4`% by cost). The top three categories by cost reach `79.0`%, just under the reference line. The number of priority categories is the same, but the specific categories on that list are completely different. If you only look at the count chart, your team might spend the quarter fixing billing errors while leaving `$5,800` in physical damage untouched.

Also notice where Other sits. Its `$200` cost is higher than Website error at `$120`, and it still goes last. That rule holds in both passes.

```kz-callout
tone: note
title: Choose the unit before you sort.
p: Frequency answers "what happens most". Cost, minutes, bed-days or severity answer "what to fix first". Those are different questions, and they often have different answers. Pick the unit that matches the decision you are about to make. Write it on the axis so the next reader knows what they are looking at.
```

Cost is not the only alternative metric. When reviewing equipment downtime, sort by total minutes lost rather than by the number of stops, and short, frequent interruptions stop dominating the chart. When analyzing quality defects, rank them by where you caught them: the same defect costs ten times more at the customer than at the machine, as covered in our guide on [defect classification](/guides/defect-classification).

In healthcare, sorting clinic delays by total patient-minutes highlights different problems than counting individual delayed visits. If your organization measures [first-pass yield](/dictionary/first-pass-yield), you are already weighing outcomes by their operational effect rather than by simple counts.

## Mistakes | Four Pareto charts that mislead you

A Pareto chart can be built accurately in software and still give a misleading impression. Here are four common issues to watch for, and how to resolve each one.

### 1. The flat Pareto chart

If all eight bars sit around `12`% to `13`%, the cumulative line will form an almost straight diagonal line. When this happens, there is no clear group of top contributors. Choosing the tallest bar anyway is rarely helpful, because small differences between bars in a flat chart are usually just normal variation.

Instead, break the same data down by a different variable. You can split records by shift, work site, supplier, machine, operator, day of the week, or time of day. This is called stratification. A flat chart usually means you grouped the data too broadly, and the real difference is hidden one level down.

### 2. The oversized Other bar

If your Other category would rank in the top three bars by volume, your categories are too broad. You cannot assign a team to solve "Other", and you cannot write a countermeasure against it either.

To fix this, look through the raw records grouped under Other, create specific categories for those items, and rebuild the table. In our example, Other accounts for only `8` out of `400` complaints, which keeps the chart practical and clear.

### 3. Mixed severities in one category

Counting minor issues and severe events as equal units creates a distorted chart. A simple typo on an invoice is not equivalent to a `$40,000` billing dispute, and a near miss is not equivalent to a lost-time injury. When you combine different severity levels into one category, your chart measures how often people logged an incident rather than the actual harm.

This is the same count-versus-cost problem as above, one step earlier: it happens at the tally sheet instead of at the axis. Either divide the category into more specific subcategories, or weight the items by cost, time, or severity score.

### 4. Too few records to trust

Creating a Pareto chart from a small sample, such as `30` records from a single week, mostly highlights short-term noise. On the next `30` records, the third bar could easily swap places with the first bar purely by chance.

Before committing resources based on a chart, ask whether the gap between the top categories is larger than ordinary week-to-week fluctuation. If the ranking changes constantly from one week to the next, you have a stability question rather than a ranking question.

```kz-compare
leftTitle: What a Pareto chart answers
left: Which few categories carry most of the total
left: Whether a category shrank after you changed something
left: Where the next hour of improvement work should go
rightTitle: What it cannot answer
right: Why the top bar is tall — that needs [5 Whys](/dictionary/5-whys) or a [fishbone](/dictionary/fishbone-diagram)
right: Whether the process is stable — that needs a [run chart](/dictionary/run-chart) or a [control chart](/dictionary/control-chart)
right: Whether a rare event is catastrophic — severity is not frequency
```

The right-hand column lists what the chart cannot do. A Pareto chart ranks your categories by size, but it does not explain why those problems occur. It tells you that damaged goods cost `$5,800` per year, but it cannot tell you why the packaging fails during transit.

Once you know which category to address, switch to [root cause analysis](/dictionary/root-cause-analysis). Use five whys when the causes run in a single chain, or a [fishbone diagram in manufacturing](/guides/fishbone-diagram-in-manufacturing) or a service setting when the causes branch.

## Before and after | Redrawing a Pareto chart after a fix

A Pareto chart is most useful when you build it twice: first to choose where to focus, and second to confirm that your solution worked.

Suppose your team takes the cost ranking at its word and fixes packaging, which was the largest cost category and only the fourth-most-frequent one. As a result, damage complaints drop from `40` cases down to `8`, while all other categories remain unchanged. Here is the updated table sorted by complaint count.

| Category | Count | Share | Cumulative |
|---|---|---|---|
| Billing error | `152` | `41.3`% | `41.3`% |
| Late delivery | `96` | `26.1`% | `67.4`% |
| Wrong item | `52` | `14.1`% | `81.5`% |
| Missing part | `24` | `6.5`% | `88.0`% |
| Rude service | `16` | `4.3`% | `92.4`% |
| Website error | `12` | `3.3`% | `95.7`% |
| Damaged in transit | `8` | `2.2`% | `97.8`% |
| Other | `8` | `2.2`% | `100.0`% |
| **Total** | `368` | `100`% | — |

Total complaints decrease from `400` to `368`. Total resolution costs drop from `$20,000` down to `$15,360`. That represents an annual savings of `$4,640`, or a `23.2`% reduction in resolution expenses, achieved by addressing a category that ranked fourth on the initial count chart.

Two patterns stand out in the updated table. First, the cumulative curve rises more steeply. Three categories now account for `81.5`% of complaints, whereas those same three previously covered `75`%. When you resolve one major issue, the remaining categories take up larger shares of the new total. So your vital few gets shorter as you work: three categories now, instead of four.

Second, Damaged in transit and Other both have `8` cases, and Other still goes last. The rule matters here. Both bars are the same height, so without it a problem you have already fixed could outrank a bucket nobody has sorted.

The cost ranking shifts as well. Wrong item is now the top cost category at `$5,200`, which represents `33.9`% of the remaining `$15,360` in annual expenses. That becomes the next priority for your team, and you know it only because you drew the chart a second time.

This is why a Pareto chart belongs in a structured improvement cycle. In [PDCA](/dictionary/pdca) (Plan-Do-Check-Act), you use the chart during Plan to pick your target, and again during Check to see whether the bar moved. The [DMAIC](/dictionary/dmaic) process uses the tool the same way in Measure and later in Control.

In an [A3 problem-solving](/guides/a3-problem-solving) report, place the original chart on the left to document the initial condition, and the updated chart on the right to show the result. The first chart explains why you chose the project, and the second provides clear evidence that the change worked.

Source: https://kaizumi.com/dictionary/pareto-chart
Licence: free to quote and cite with attribution to Kaizumi.
