Cause and Effect Diagram: Fishbone / Ishikawa Root Cause Analysis

The cause and effect diagram — also called a fishbone diagram or Ishikawa diagram — gets used in root cause analysis more than almost any other quality tool. I’ve seen it used well and I’ve seen it used badly, and the difference is almost always the same thing: whether the session was actually facilitated or whether someone just drew the fish and let the room talk. I’ve been handed a completed fishbone diagram as evidence that a root cause analysis had been done, when actually the team spent 90 minutes in a room and the most senior person’s hypothesis ended up on the diagram five different times under five different category labels. That’s not analysis.

 What Is a Cause and Effect Diagram?

A cause and effect diagram, also known as a fishbone diagram or Ishikawa diagram, is a quality management tool used to identify the root cause of a problem. It analyses various possible causes of a problem through structured brainstorming. The diagram gets its name from its shape — a spine running horizontally with branches angling off it like the bones of a fish, each branch representing a category of potential causes.

Kaoru Ishikawa, a Japanese quality control expert, developed the fishbone diagram in the 1960s as part of the Toyota quality management system. It became one of the seven basic quality tools and is now standard in root cause analysis processes across manufacturing, healthcare, software development, and project management.

Unstructured problem discussions tend to go wherever the most confident person in the room steers them. The fishbone structure at least requires the team to address all six categories before concluding anything — which slows that down, which is usually the point.

The Seven Basic Quality Tools

Ishikawa’s intention was to give shop floor workers tools they could use without statistical training. The seven are:

• Fishbone diagram (cause and effect diagram)
• Pareto chart
• Control chart
• Histogram
• Scatter diagram
• Flowchart
• Check sheet

These tools are often listed together in quality management training, but they serve different purposes. The fishbone diagram is a qualitative brainstorming tool — it structures a conversation about possible causes but doesn’t tell you which causes are actually significant. The Pareto chart and control chart are quantitative — they work with data to show where the most impact is or whether a process is in control. The fishbone generates hypotheses. The Pareto chart and control chart test which hypotheses hold up. Using one without the other leaves you either with unverified hunches or with data that doesn’t explain why the pattern exists.

Categorisation of Causes: 6M and Variants

The standard fishbone diagram uses six cause categories, known as the 6M:

• Machine — equipment, technology, tools
• Method — processes, procedures, workflows
• Material — raw materials, components, supplies
• Manpower (Man) — people, training, skills
• Measurement — data, inspection, calibration
• Mother Nature (Milieu) — environment, temperature, humidity

The 6M framework was developed for manufacturing environments. For service industries or project management contexts, adaptations are common. The 8M adds Management and Maintenance. The 4S model (Surroundings, Suppliers, Systems, Skills) suits service contexts. Some organisations use PEMPEM (Plant, Equipment, Methods, People, Environment, Materials). I’ve seen teams use the 6M on a software deployment problem and spend the first 20 minutes arguing about whether “Mother Nature” applied to cloud outages. Pick a framework that fits the problem. If none of the standard ones do, make one up.

Framework	Categories	Best for
6M	Machine, Method, Material, Manpower, Measurement, Mother Nature	Manufacturing
8M	6M + Management + Maintenance	Complex manufacturing / operations
4S	Surroundings, Suppliers, Systems, Skills	Service industries
4P	Policies, Procedures, People, Plant	Healthcare / administration

How to Create a Cause and Effect Diagram

Step 1: Define the problem statement

Write the problem statement at the head of the fish (right side). Be specific — “delivery delays” is too vague; “25% of orders delivered more than 3 days late in Q1” is specific enough to investigate. A vague problem statement produces a vague diagram.

Step 2: Draw the spine and main bones

Draw a horizontal arrow pointing to the problem statement. Add diagonal branches for each cause category — typically the 6M or whichever framework suits the context.

Step 3: Brainstorm causes for each category

For each category, ask “what could cause this?” and add sub-branches. Keep asking “why?” for each cause to build sub-causes. The diagram grows until the team has exhausted plausible causes in each category.

Step 4: Complete the Cause and Effect Diagram across all categories

Continue until all six (or however many) categories have been explored. A complete diagram typically has between 15 and 30 cause entries across all branches.

Step 5: Mark the candidate root causes for verification

Review the completed diagram. Circle or highlight the causes the team has the most evidence for, or those that appear across multiple categories. These become the hypotheses to verify with data.

After the brainstorming session, most teams have a diagram with fifteen to twenty items on it and no clear idea what to do next. The usual move is to vote on which causes seem most likely — which mostly reproduces the same group consensus you were trying to avoid. A more useful approach: for each candidate cause, ask what evidence would confirm or refute it. If you can’t think of any evidence that would change your view, it’s not really a testable hypothesis yet. If you can, go find that evidence before drawing any conclusions.

Facilitation: Where Fishbone Sessions Go Wrong

The fishbone diagram depends on a good facilitated session. Without active facilitation, a few failure modes are almost guaranteed.

Dominant voices crowd out useful input. In any group, one or two people tend to do most of the talking. In a root cause analysis, the senior or most confident person in the room often drives the conversation toward their existing hypothesis. The fishbone ends up reflecting what they already believed rather than the collective analysis. A facilitator needs to explicitly solicit input from quieter participants — asking people to write causes on sticky notes before the group discussion is one approach that reduces this effect.

Categories become a constraint rather than a guide. Teams sometimes spend 10 minutes debating which category a cause belongs to rather than capturing it and moving on. The category labels are prompts. If a cause doesn’t fit cleanly, put it somewhere reasonable and move on. I’ve watched teams spend a quarter of their session arguing about whether ‘unclear specifications’ was a Method problem or a Manpower problem. It doesn’t matter. Write it down somewhere.

The session stops at symptoms rather than causes. “Equipment malfunction” is a symptom. “Equipment malfunctioned because it wasn’t serviced on schedule” is closer to a cause. “Maintenance wasn’t scheduled because the maintenance log wasn’t reviewed during shift handover” is getting somewhere. Facilitators need to keep asking “why” for each item until the team reaches something actionable — something that, if changed, would prevent the problem from recurring.

The diagram gets filed rather than acted on. A completed fishbone diagram sitting in a folder three months later is surprisingly common. The analysis is only useful if it leads to verified root causes and corrective actions. If the session doesn’t end with a clear next step — “we’re going to check the maintenance records for the last six months” or “we’re going to sample 50 units and measure X” — it hasn’t done the job.

What to Do After the Cause and Effect Diagram

After the session, you have a list of candidate causes. None of them are confirmed yet — they’re what the team thinks might be causing the problem. Treating them as confirmed causes before verifying them is where a lot of root cause analyses go wrong.

For each top candidate cause, identify what evidence would confirm or refute it. If the team suspects “inconsistent supplier material quality” is driving defects, what does the data show? Do defect rates correlate with specific supplier batches? Do they vary by material lot number? If the hypothesis is right, the evidence should show a pattern. If it’s wrong, the pattern won’t be there.

The Pareto chart is useful at this stage — it shows which categories of defects or causes account for the largest proportion of the problem. If 80% of defects come from three cause categories, those are the candidates worth verifying first. Combining the fishbone diagram with a Pareto analysis gives you both a structured hypothesis set and a prioritisation of where to focus verification effort.

Once a root cause is verified, the corrective action needs to address the cause at the level where it was found — not the symptom. If the root cause is “maintenance schedule wasn’t reviewed during shift handover,” adding a mandatory maintenance log review to the shift handover checklist addresses the cause. Replacing the equipment addresses the symptom and leaves the underlying cause in place to create the same problem with the new equipment.

Fishbone Diagram vs 5 Whys

The fishbone diagram and the 5 Whys technique are both root cause analysis tools, and they’re often used together — but they do different things. Understanding the difference helps you choose the right one, or combine them effectively.

The fishbone diagram works across the whole problem space — you’re looking at multiple categories of potential cause at the same time. It’s good when you don’t know yet which category the root cause lives in, or when you suspect multiple causes are interacting. The weakness: it stays at the surface. “Equipment” is a category, not a root cause.

The 5 Whys goes deep on a single cause, asking “why” repeatedly until you reach something actionable. It’s good when you already have a candidate cause and want to trace it back to its origin. The weakness: it follows one chain and misses parallel causes that might be equally important. Use the fishbone to find the candidates worth drilling into, then use 5 Whys to drill.

The limitation of 5 Whys alone is that it tends to follow a single causal chain and miss parallel causes — problems with multiple contributing causes don’t get fully captured. The limitation of fishbone alone is that it stays at the hypothesis level without drilling into any single cause. Used together, they compensate for each other’s weaknesses.

Advantages and Limitations of the Cause and Effect Diagram

Advantages

• Structured brainstorming. The category framework prevents the analysis from converging prematurely on one cause and ensures different types of cause are considered.
• Visual and collaborative. The diagram makes the analysis visible to the whole group simultaneously, which helps build shared understanding and surfaces disagreements about causes.
• No statistical knowledge required. The fishbone is qualitative — it works with the team’s knowledge and observation rather than requiring data or statistical tools.
• Applicable across industries. The 6M framework is manufacturing-specific, but the underlying structure works in any context with appropriate category adaptation.

Limitations

• Doesn’t quantify causes. The fishbone shows what might be causing a problem, not how much each cause is contributing. Prioritisation requires data analysis — Pareto charts, control charts, or statistical tests.
• Depends on the quality of the session. A poorly facilitated session produces a diagram full of whatever the dominant voices in the room already believed. The diagram looks complete and analytical. It isn’t.
• Can generate too many hypotheses. A thorough session can produce a large diagram with 20+ candidate causes. Without a method for prioritising which to verify, the analysis becomes hard to act on.
• Doesn’t verify causes. The fishbone is a hypothesis generation tool. It doesn’t tell you whether any of the causes on the diagram actually explain the problem. Verification requires a separate step using data.