8D D4: fishbone vs 5 Whys, and how to combine them

Fishbone diagrams and 5 Whys are the two tools most often named in D4, and reviewers see both used badly. Neither one proves a root cause on its own. The fishbone helps a team list possible causes without jumping to the first idea. 5 Whys helps follow one verified fact down to a cause you can control. This page is about choosing and combining the tools. For what D4 must contain overall, see how to write a D4 root cause; for weak wording to avoid, see weak D4 root cause examples.

When a fishbone helps

Use a fishbone (Ishikawa diagram) when the cause is genuinely unknown and several areas could be involved. The usual categories (man, machine, method, material, measurement, environment) are a prompt, not a form to fill.

• New or intermittent failures where nobody yet knows where to look.
• Problems that cross departments, such as a design tolerance meeting a process limit.
• When the team keeps returning to one favourite theory and needs to widen the search.
• For the escape side too: draw a second, smaller fishbone for why detection missed it.

When 5 Whys helps

Use 5 Whys when you already have a confirmed starting fact and need to go deeper than the first answer. It works best on a single chain with clear physical or process links.

• You know which station, tool or batch produced the defect and need the reason behind it.
• Each answer can be checked against data, a record or a test.
• The chain should stop at a cause you can act on and verify, not at a person or at “not followed”. See why operator error isn’t a root cause.

Five is a habit, not a rule. Stop when the next answer is outside your control or no longer adds an action; keep going if the last answer is still a symptom.

How to combine them

• 1. Widen: build the fishbone from facts in D2 (what, where, when, how many). List possible causes.
• 2. Screen: mark each possible cause as ruled out, possible or confirmed, with the evidence for each mark. Most branches should be closed by data, not by discussion.
• 3. Deepen: run 5 Whys only on the causes that survived screening.
• 4. Verify: test the final cause before D4 is written as closed.
• 5. Repeat for escape: run the same steps for why the defect was not detected.

Verify the cause with data

A reviewer looks for proof that the chosen cause really explains the problem. Useful forms of verification:

• Comparison: good vs bad parts, shifts, lots or machines, and whether the difference lines up with the suspected cause.
• Turn it on and off: recreate the defect by setting the suspected condition, and remove it by correcting the condition, where safe and practical.
• Records: process data, maintenance logs, change records or material certificates that match the time window of the failure.
• Measurement check: confirm the gauge or test can actually see the defect before relying on its results.
• Is / Is-Not fit: the cause should explain why the problem appears where it does and not elsewhere; see the D2 Is / Is-Not table.

Illustrative examples from several sectors

These examples are fictional and only show the structure.

• Automotive machining, oversize bore: fishbone lists tool wear, fixture, coolant, gauge and material. Gauge study and material certificates rule out two branches. Tool-life data matches the oversize parts, and 5 Whys leads to a tool-change interval that was set without wear data.
• Electronics (PCBA), solder bridging: fishbone across stencil, paste, placement, reflow profile and board design. Comparing lots shows bridging only on one stencil revision. 5 Whys goes to an aperture change released without a trial build.
• Food packaging, weak seals: the team starts 5 Whys on “operator set wrong temperature” and stops at the person. A fishbone widens the search; data shows seals failed only after a jaw replacement, and the cause is a missing setup check after maintenance.
• Medical device moulding, flash: fishbone screens resin moisture, tool damage and parameters. Turning the suspected parameter back reproduces the flash; restoring it removes it.

Common misuse

• A fishbone pasted into D4 as the root cause, with every branch still open.
• 5 Whys started from an assumption instead of a verified fact.
• Each “why” is an opinion, with no record or test behind it.
• The chain ends at blame, training or “procedure not followed”.
• Only the occurrence is analysed; the escape is never asked.
• Several unverified causes listed so that one of them is probably right.
• The diagram is so large that the reviewer can’t see which cause the team chose and why.

Next, turn the verified cause into a D5 permanent corrective action. The free printable 8D / D4 checklist (PDF) covers D1–D8 and goes deeper on D4.

FAQ

Which tool should go in the 8D report?

Show the result, not just the tool. A short screened list of causes with the evidence for each, plus the verified chain to the root cause, usually reads better than a full diagram.

Do I need both tools every time?

No. If the starting fact is already confirmed and the chain is simple, 5 Whys alone may be enough. Use a fishbone when the cause is unclear or several areas could be involved.

What does 8D Gate check?

It gives a pre-send readiness check on the 8D text: an Accept / Conditional / Reject advisory with missing evidence and questions. It isn’t a customer decision. The review tool is v0.1: it reviews English 8D reports, and the interface and report are in English. Templates are also available in German, Czech and Polish.

Free pre-send readiness check

Before the 8D goes out, run the text through the free supplier 8D readiness check.

Get the free 8D / D4 checklist

Keep the one-page version ready for the next complaint. It covers D1–D8 and goes deeper on containment, D4 root cause, and verification.