Root cause analysis: choosing between 5 Whys, fishbone and 8D

Three methods dominate root cause analysis, and most organisations pick one and use it for everything. They are not competing brands of the same thing; they suit different problem shapes. 5 Whys is for a single causal chain you can follow. Fishbone is for when several causes may interact and you need to broaden before narrowing. 8D is for when a customer is involved, product needs containing, and the fix must be verified. This guide walks one problem through all three, then covers the parts every method depends on and most write-ups skip.

Start with a problem statement made of data

Every method fails identically if the statement is vague, because each simply elaborates whatever you put at the top. A usable one contains what, where, when, how many, how detected and how you know — and no adjectives.

• Not usable: “Quality problems on the shaft line have got worse recently and the customer is unhappy.”
• Usable: “Between the 14th and the 22nd, 47 of 1,200 shafts on part 4471 measured an outside diameter above the upper limit of 20.05 mm. All 47 came from machine 3, all on the night shift, and all were found by the customer at goods-in rather than by our end-of-line check.”

The second version has already done analytical work. It gives you a boundary — machine 3, night shift, one week — so every candidate cause must explain why the problem appeared there and nowhere else. It also surfaces a second problem: the escape. The customer found what the end-of-line check did not, and those are two failures with two causes.

The process facts: shafts are turned on three CNC machines, the finish pass is compensated by a tool offset adjusted from a measurement taken once per shift, inserts are changed on a piece count, and bar stock arrives in heat-treated lots from one supplier.

5 Whys: one chain, one cause

5 Whys is right when the problem is bounded, the chain is likely to be linear, and people who know the process can answer each step. It is fast — half an hour — and honest about its scope. Each answer must be a fact, not an opinion:

1. Why did the shafts measure oversize? The finish turning pass left more material on the diameter than the program allows.
2. Why did it leave more material? The tool offset was not adjusted as the insert wore during the shift.
3. Why was the offset not adjusted? It is set from one measurement, taken at the start of the shift.
4. Why is once per shift enough? It is not, on this material — the insert reaches its wear limit about two thirds of the way through a night shift, so the last third runs uncompensated.
5. Why does the insert reach its wear limit early? The change interval is set by piece count, and that count was established on bar stock of lower hardness than the lots delivered this month.

That fifth answer is a cause you can act on: the insert interval and the offset frequency are both set from an assumption about incoming hardness, and nothing connects a change in hardness to a review of either.

Depth is worth tracking rather than assuming. The published measure: Depth = number of consecutive answered whys, counted from Why 1 until the first blank (0–5). Most abandoned analyses stop at two or three, and a chain that stops at three has almost always stopped at a symptom. Five is a convention, not a law — stop when you reach a cause you can change, and go past five if the chain is still inside your process.

The limitation is worth saying out loud: 5 Whys follows one path. If the oversize shafts were caused by insert wear and a gauge reading low and a coolant concentration that drifts at night, the chain above finds the first and assumes the others do not exist. That is the moment to reach for a fishbone.

Fishbone: broaden before you narrow

A fishbone is right when you do not know which family the cause belongs to, when several causes may interact, or when the room has competing theories and you need all of them visible before anyone defends one. Its job is to generate candidates, not select one. The branches are commonly machine, method, material, measurement, people and environment; here the room produced these among others:

• Machine — insert wear interval set by piece count rather than measured wear; machine 3's turret repeatability worse than the other two.
• Method — offset measured once per shift; no trigger to re-check after a material change.
• Material — bar hardness varies between lots; this month's are harder than the count was set on.
• Measurement — end-of-line gauge calibrated outside its interval; the check is a sample, not every piece.
• People — night shift check frequency lower than day shift; no standard for when to re-measure.
• Environment — coolant concentration drifts overnight when the mixer is not topped up.

A drawn fishbone with twenty candidates and no way to rank them is where most of these end. The published scoring turns it into a register: Priority score = likelihood (1–5) × evidence weight (none = 1, weak = 2, moderate = 3, strong = 4 — so the score runs 1–20).

Scoring: the insert wear interval is likelihood 5 with strong evidence (4) = 20, the wear measurements being in hand. Bar hardness variation is 4 with strong evidence (4) = 16, since the lot certificates confirm the change. Night shift check frequency is 4 with moderate evidence (3) = 12. Coolant concentration is 3 with weak evidence (2) = 6. The uncalibrated gauge is 2 with moderate evidence (3) = 6 — low as a cause of oversize parts, but a strong candidate for the separate escape problem, which a 5 Whys chain would never have surfaced.

Two disciplines separate a useful fishbone from a wall decoration. Evidence weight is evidence you have, not confidence you feel; a cause everyone is sure about with nothing to show for it weights 1 and sorts itself down the list. And the output is a shortlist, not a root cause — the top candidates each need testing, and 5 Whys is a good way to drive down the survivor.

8D: when a customer is involved

8D is right when the problem has escaped to a customer, when product needs containing while you investigate, and when the fix must be evidenced outside your team. It is not a better 5 Whys; it is a disciplined container with a root cause step inside it, and it is disproportionate for an internal issue. Applied to the shaft problem:

1. D1 — Team. Name the people, including someone from the process and someone able to release resource. A team of one is a report, not an 8D.
2. D2 — Problem description. The data statement above.
3. D3 — Interim containment. Quarantine the three affected lots, sort the customer's stock at our cost, 100% checks on machine 3. Record the evidence that containment is working.
4. D4 — Root cause. The insert interval and offset frequency were set from a hardness assumption, with nothing linking a change in incoming hardness to a review. Verified, not asserted.
5. D5 — Permanent corrective actions. Offset measured every 25 pieces; insert interval derived from measured wear; incoming hardness change added as a review trigger.
6. D6 — Implement and verify effectiveness. Live from a stated date, evidence collected afterwards rather than predicted.
7. D7 — Prevent recurrence. Update the control plan and process failure mode analysis; apply the trigger to the other machines and parts on that material.
8. D8 — Close and recognise the team.

What makes 8D worth its cost is that closure has a definition rather than a feeling. The published rule: Report closed = all 8 disciplines complete, with D4 and D6 marked “Complete & verified” and carrying written evidence. D4 is the root cause and D6 the effectiveness check — the two steps easiest to assert and hardest to prove.

Containment, correction and corrective action are three different things

These three get collapsed into one word in most write-ups, and that is how a problem gets closed and then comes back.

Containment stops the effect reaching anyone else while you still do not know why it happened. Sorting the customer's stock, quarantining three lots, adding a 100% check: none improve anything, all are wasteful by design, and all are correct. Containment is temporary and needs a removal condition written down when it goes in — containment that becomes permanent is expensive.

Correction fixes the specific nonconforming product: rework the 47 shafts, scrap them, or replace them. It has no effect on the next batch.

Corrective action changes the process so the cause cannot produce the effect again. Measuring the offset every 25 pieces is corrective action; sorting the stock is not. The test: if you did this and walked away for six months, would it recur? Write the three separately, each with an owner and a date — a single “action taken” field is where the distinction dies.

Stopping at a cause you can actually change

Every method can be driven too far or not far enough. Not far enough produces “operator error”. Too far produces “inadequate management commitment to quality”. Neither can be acted on.

“Operator error” is almost never a root cause, because it does not explain itself. If someone did the wrong thing, the useful question is what made that possible or reasonable at the time: no standard, two standards, a standard that cannot be followed at the required rate, training that never happened, a fixture that fits both ways round, a check that takes longer than the cycle allows. Those are causes with fixes. Naming a person is a cause with only a punishment, and it stops anyone reporting the next one.

A cause is at the right depth when it passes all of these:

• You can describe a specific change to a process, setting, standard, tool or design that addresses it.
• The change is inside the authority of someone you can name.
• Had the cause not been present, the problem could not have occurred as it did — and you can say why.
• It explains the boundary in your problem statement. A cause affecting all three machines equally does not explain 47 parts from machine 3.
• It does not name a person as the terminal answer.

Verifying that the fix worked

This is the step skipped most often, and skipping it converts problem-solving into paperwork. There are two verifications, and they happen at different times, which is part of why they get lost.

The first verifies the cause, before you commit to a fix. The strongest form is to turn the cause on and off: restore the old insert interval on a controlled run and see whether oversize reappears; apply the new one and see whether it stops. Where a cause cannot safely be reintroduced, show instead that it was present in every occurrence and absent in the comparison cases — machine 3 ran the hard lots and the others did not. Never sufficient: that the explanation sounds right. Plausibility is the commonest reason a wrong root cause survives review.

The second verifies effectiveness after the fix is live, and needs a measure, a period and a threshold agreed before the clock starts. Here: zero shafts above 20.05 mm across at least 4,000 pieces over 30 days, on the calibrated gauge. Agreeing the threshold in advance matters, because one set afterwards is set to whatever the data turned out to be. Verification must also be able to come back negative — properly implemented actions that did not work are common.

Which brings us to the uncomfortable part. A completed form with an unverified root cause is not problem-solving; it is a record that a meeting happened. It will pass an audit, satisfy a customer's request for a report by Friday, and close on the system — and the problem will return, usually within a quarter, to someone who has never seen the original report. The methods in this guide do not solve problems. The verification at the end does.

Choosing, in one paragraph

Use 5 Whys when the problem is bounded and the chain looks linear; its weakness is that it follows one thread. Use a fishbone when several causes might interact or the room disagrees, then score the candidates and drive the survivors down with 5 Whys. Use 8D when a customer is involved and the fix must be evidenced. Whichever you pick, two things decide whether it works: a problem statement made of data, and a verification step that could have come back negative.