← Insights

Root cause

5 Whys vs Fishbone: when to use which

June 2026 · 7 min read

Both tools sit in the root cause toolbox used by quality engineers, lean practitioners and Six Sigma teams worldwide. Both ask the same question: not "what failed?" but "why did it fail?" And in the wrong situation, both can confidently lead you to the wrong answer.

The 5 Whys drills down a single chain of logic. The Fishbone maps an entire landscape of potential causes. Knowing when to reach for each - and when to run both in sequence - is the difference between a root cause analysis that closes the problem and one that just closes the report.

Two tools, one job. Left: a 5 Whys chain drills from symptom to root cause. Right: a Fishbone maps all six cause categories at once.

Two tools with very different shapes

The 5 Whys and the Fishbone diagram were both developed within Japanese manufacturing during the twentieth century. Both became staples of quality management, Six Sigma and CAPA. Both appear in D4 of a standard 8D report. That is where the similarity ends.

The 5 Whys follows a linear chain: one cause leads to one cause leads to one cause, five levels deep. The Fishbone - also called the Ishikawa diagram, after Kaoru Ishikawa who formalized it at Kawasaki - maps a landscape of potential causes across six structured categories, branching outward from a central spine. One is a drill. The other is a net.

The 5 Whys

The method is deliberately simple. Write down the problem. Ask why it happened. Write the most honest answer you can. Ask why that is the case. Repeat until you reach something you can change - a process, a system, a decision - not just an event.

A 5 Whys chain on a real-world quality escape. Each step challenges the answer above it - not the original symptom.

Notice what happens at each step: the question is not "why did the component fail?" It is "why was the tool worn beyond threshold?" Then "why was wear not monitored?" The chain stays anchored to the previous answer, which is what separates a genuine 5 Whys from a list of guesses.

Notice also where the chain ends - not at "the operator didn't check" (that is a symptom, not a cause) but at the system failure that made the error possible: a process document that was never updated. That is the correct stopping point. Every corrective action from there will be structural.

Three things the 5 Whys does well:

• Speed. One person, one conversation, one page. Fast enough to complete between a shift debrief and a customer response.
• Clarity. A linear chain is easy to present to leadership, customers and auditors. The logic is transparent.
• Depth. If you stay honest, you almost always land on a process or governance failure - which is exactly where a permanent fix lives.

Two failure modes to watch for:

• Stopping at human error. "The operator made a mistake" is never a root cause - it is always a symptom of a system that allowed the mistake to occur. Keep asking why until you reach the system.
• A chain that branches. If Why 2 has two equally valid answers, the chain splits - which usually means the problem is multi-factorial. That is the Fishbone's territory.

The Fishbone (Ishikawa)

The Fishbone is a team tool and a hypothesis generator. Draw a horizontal spine with an arrow pointing to the problem on the right. Six branches come off the spine - one for each of the 6M categories: Man (skills, training, behaviour), Machine (equipment, tooling, calibration), Material (inputs, components, specifications), Method (procedures, processes, work instructions), Measurement (inspection, gauging, data quality), and Mother Nature (environment, temperature, humidity).

The team brainstorms every possible contributing cause under each category, adding sub-causes as branches off the main bones. Nothing is evaluated during the brainstorm - you capture everything first. The result is a comprehensive map of hypotheses, covering the full width of your process.

The same problem mapped across all six cause categories. Every bone is a hypothesis - none are verified until data confirms them.

The critical word in that last sentence is hypotheses. A Fishbone meeting that produces a populated diagram and then closes the corrective action is not a root cause analysis. It is a brainstorm. The bones represent possibilities, not facts. The next step after building the diagram is always the same: gather data to identify which bone, and which branch of that bone, is actually supported by evidence.

Three things the Fishbone does well:

• Completeness. The 6M structure forces you to consider categories you might skip if you started digging straight away. Teams regularly find the root cause on a bone they would not have looked at otherwise.
• Team engagement. Because everyone contributes, the team understands the analysis - they do not just receive an answer from one person. That buy-in matters when the corrective action lands back on the floor.
• Breadth before depth. Running the Fishbone before collecting data tells you where to look, which makes the data collection targeted and efficient.

Two failure modes to watch for:

• No data follow-up. A Fishbone diagram is not a conclusion. Without verifying which hypotheses are supported by evidence, you are just managing opinions.
• The blame exercise. "Man" branch items pointing at specific individuals need careful handling. The question is always "what in the system allowed this?" - never "who is at fault?"

When to reach for each

The rule of thumb

If you can draw the cause-and-effect chain in one sitting without branching, reach for the 5 Whys. If you need a room and a whiteboard, reach for the Fishbone.

The branching test is the key diagnostic. The moment a "why?" question has two equally valid answers - tool wear AND incorrect setup, for example - the linear 5 Whys chain is no longer the right shape for the problem. That is not a failure of the method; it is the method telling you something important about the problem's structure.

The power move: use them in sequence

The most effective root cause analysis uses both tools - and uses them in order.

Step 1 - Fishbone first. Open the investigation wide. Run the 6M brainstorm as a team. Build a complete hypothesis map before anyone anchors on a cause. Resist the urge to skip this step because you think you already know the answer - that is exactly the situation where teams find their assumption was one bone away from the real cause.

Step 2 - Collect data to find the leading bone. Gather inspection records, process data, materials traceability, operator observations. Identify which category and which branch is most strongly supported by evidence. This is the step most teams skip, and it is why corrective actions fail - they fix the loudest hypothesis, not the proven one.

Step 3 - 5 Whys down the winning branch. Once the data points to a specific bone, run a tight 5 Whys chain to reach the system-level root cause. This is the combination that gives you the completeness of the Fishbone and the precision of the 5 Whys in a single investigation.

This sequential approach is standard practice in a thorough D4 root cause analysis, in DMAIC Analyse, and in any customer-facing 8D where the root cause is disputed. Skipping straight to 5 Whys risks running a fast, clean chain down the wrong branch entirely.