The fishbone (cause-and-effect) diagram

Last reviewed 2026-08-20

Cause-and-effect diagram, Ishikawa diagram and fishbone diagram are three names for the same drawing. The effect sits at the head, a spine runs back from it, major categories branch off the spine, and candidate causes hang off those, with sub-causes hanging off them in turn. It is named for Kaoru Ishikawa, who is generally credited with putting it to work in Japanese industry in the 1940s, and it is one of the seven basic quality tools.

It is also the only one of the seven that produces no numbers, which is both its purpose and the source of every way it goes wrong.

What it is actually for

A fishbone makes a group state its hypotheses out loud, in one place, before anyone starts testing. That is a genuinely valuable thing to do. The maintenance fitter's theory, the shift leader's theory and the process engineer's theory usually differ, they are usually all partly right, and without a structure to collect them the investigation quietly becomes whichever theory the most senior person in the room holds.

The categories are scaffolding for that conversation, nothing more. They exist so that a group looking at a weld defect does not spend forty minutes on the welder and none at all on the wire, the fit-up or the gauge.

The 6Ms

The manufacturing default. Six branches, and the mnemonic survives because it is hard to leave a whole class of cause out of it.

Branch Covers Typical entries
Machine The equipment Wear, backlash, clamping force, tool life, calibration overdue
Method How the work is done Written procedure, actual procedure, setup sequence, changeover
Material What goes in Supplier, lot, storage time, moisture, an approved substitution
People (traditionally Man) Who does it, and how they were set up to Training, shift handover, ambiguous instruction, workload
Measurement How you know Gauge resolution, repeatability, datum ambiguity, who inspects
Mother Nature The environment Temperature, humidity, vibration, cleanliness, lighting

"Man" is the traditional label; People or Personnel is the better one, and not only for the obvious reason. A branch labelled "Man" invites entries naming individuals, which is precisely how that branch fails. The useful entries there are about the work system — what the instruction said, what the handover did not cover, how the shift was staffed — because those are the things anyone can change afterwards.

The Measurement branch is disproportionately productive and disproportionately skipped. A defect rate that rose without any process change is very often a gauge that drifted, an inspector who was retrained, or a characteristic whose measurement variation swamps the part variation. Check it early; it is cheap to rule out.

Service and transactional work

The 6Ms fit a machine shop and fit a claims department badly. Service versions in circulation include a 4P set — Policies, Procedures, People, Plant and technology — and an 8P set borrowed from the services marketing mix. The lists do not agree with one another and there is no need for them to. Take any starting set, and delete a branch that yields nothing rather than filling it out of symmetry. Six empty bones on a wall are not thoroughness.

How to run one

Start with an effect that is specific and measurable

This step decides whether the whole exercise is worth anything. A vague effect gives a diagram of everything that has ever gone wrong on that line.

  • Useless: "Quality problems on line 2."
  • Weak: "Poor weld quality."
  • Usable: "Porosity in the root pass of the 6 mm fillet on line 2 — 4.1% of joints in July, against 0.8% in the first quarter."

The specific version does two things the vague one cannot. It excludes causes that could not produce a change in July, which removes half the diagram before it is drawn. And it makes every remaining branch testable, because you now know what a cause has to explain.

The strongest sharpener is a contrast: what is it, and what is it not? If it happens on line 2 and not line 1, everything common to both lines comes off the diagram immediately.

Then branches, then "why does that happen?"

Draw the spine, label the branches, and populate them by repeatedly asking why of each entry. The first thing anyone says on a branch is usually a restatement of the effect; the entries worth having are two or three levels down, where they become concrete enough to go and check.

"Operator error" is not a cause. "The work instruction gives the torque as a range and the two shifts have settled at opposite ends of it" is a cause, and it is also a thing you can verify before lunch.

Two mechanics that matter more than they sound:

  • Generate silently first, then go round the table. Otherwise the diagram records the room's hierarchy rather than its knowledge.
  • Never argue about which branch a cause belongs on. If humidity is Material or Mother Nature, put it in either. The categories are a prompt, not a taxonomy, and that argument has consumed more meeting time than any other feature of the tool.

Finish with a list of checks, not a conclusion

The diagram is done when every candidate has been converted into a question with an answer somewhere in the data:

Candidate cause If it were true you would see Where to look
Material lot change Rejects clustering by lot Traceability, stratified Pareto
Gauge drift Rejects rising with no process change Calibration record, Gage R&R
Ambient humidity Reject rate tracking the weather Scatter of rejects against humidity
Setup difference Rejects concentrated after changeovers Reject times against changeover log

That table is the actual output of a fishbone. The drawing is the working.

What a fishbone cannot do

Be firm about this, because the tool invites the opposite belief.

It generates hypotheses. It does not test them. It contains no evidence, no ranking and no data. Every branch carries the same visual weight whether it explains ninety per cent of the problem or none of it, and a bone with eleven sub-causes looks more important than one with two even when the one with two is the answer. Fullness is not significance.

It also has no notion of magnitude, no way to represent two causes that only matter together, and no way to tell you that the effect you wrote at the head is ordinary common cause variation — in which case there is no assignable cause on the wall to find, and the diagram is a hunt for something that does not exist.

The two failures that make most of them worthless

Treating a completed diagram as a completed investigation. A full wall of sticky notes feels like a day's work because it was a day's work, and the temptation is to move straight to actions. What then decides the action is not evidence but advocacy: the cause fixed is the one argued for most forcefully by the person with the most standing. The tell is an action list dated the same day as the diagram, with no data collection in between.

Drawing it before anyone has counted anything. A fishbone is cheap and requires no data, which is exactly why it gets used as a substitute for data. Pair it with a check sheet upstream, so you know what is actually happening, and a Pareto chart downstream, so the hypotheses get tested against counts rather than opinions.

Fishbone or 5 Whys?

They fail in opposite directions, which is why they work well together.

5 Whys — from the Toyota tradition — goes deep on one chain, asking why of each answer until the cause is something a policy or a design can change. Its weakness is that it commits to a single path at the very first step and then follows it with no more evidence than the fishbone had.

A fishbone goes broad across many candidate chains and never goes particularly deep on any of them.

Use the fishbone to lay out the candidates and pick the one worth pursuing, then 5 Whys to walk that chain down to something actionable. Both need the same discipline at every link: what would I expect to observe if this were true, and have I actually observed it?

What a Pareto chart does that a fishbone cannot

A Pareto tells you which effect is worth drawing a fishbone about at all. It is the tool that turns a list of complaints into a ranking, and a fishbone drawn for anything other than the top one or two bars is a well-run investigation into something that does not matter. See how to build one, including the choice of weight — count or cost — that decides which bar comes first.

Afterwards it works in the other direction too. The branches tell you what to stratify by next: if lot, cavity and shift are all on the diagram, they all belong on the check sheet from Monday, and a stratified Pareto a month later will settle several branches at once. Then chart the characteristic over time with limits frozen to the pre-fix baseline to find out whether anything you changed actually held.

Run these on your own numbers

Free, no signup, and nothing you paste is stored — the same tested engine that draws the charts in the product, so the answers cannot disagree.

  • Pareto chart generator — Categories and counts in, ranked bars and the cumulative line out — with the vital few named, an "Other" bucket that always sorts last, and an honest warning when the distribution is flat and there is no dominant cause to attack.
  • Gage R&R calculator (ANOVA) — Paste a crossed study — part, operator, reading — and get the full ANOVA: repeatability and reproducibility separated, the part-by-operator interaction tested rather than assumed away, %GRR, %Tolerance and ndc against AIAG's bands.
  • Control chart generator — Paste a column of numbers, or rows of subgroups, and get a real control chart: limits from the data, Nelson rules 1–4 evaluated, out-of-control points marked.

Read next

  • Common cause and special cause variation — Every process varies. The question is whether the variation is the process being itself or something happening to it — and answering it wrong is how well-meant intervention makes a process worse.
  • How to make a Pareto chart in Excel — Excel has had a built-in Pareto chart since 2016, and it is fine until you need it to behave. Here is the built-in route, the manual build, and the two mistakes that send an improvement team at the wrong defect.
  • The seven basic quality tools — Ishikawa argued that most quality problems can be solved with seven tools and no statistics beyond arithmetic. Here is what each one answers, when each is the wrong tool, and why the order you use them in matters more than the drawings do.