Methods & Guides
How to Use a Cause and Effect (Fishbone) Diagram
A practical guide to building a fishbone diagram, using the 6M framework, and validating causes with data.
A practical guide to building a fishbone diagram, using the 6M framework, and validating causes with data.
You know something is wrong. A process keeps failing. A defect keeps appearing. A complaint keeps coming back. You fix what looks broken, and three weeks later it is broken again.
The problem is not the fix. The problem is that you never found the actual cause.
A Cause and Effect Diagram, also called a Fishbone Diagram or Ishikawa Diagram, is a structured visual tool that forces a team to map every plausible cause of a problem before deciding what to fix. It does not give you the answer. It stops you from jumping to one before you have earned it.
Dr Kaoru Ishikawa developed the tool in the 1960s while working on quality control processes in Japanese shipbuilding. The name comes from the shape: a horizontal spine pointing at the problem, with diagonal bones branching off into cause categories. It looks like a fish skeleton. The visual is deliberate. It forces breadth before depth, categories before conclusions.
The Fishbone Diagram is a hypothesis-generation tool. That is its job. It helps a team surface every credible explanation for a problem in a structured way, so that nothing obvious gets overlooked and no single person's assumption dominates the room.
It is not a root cause analysis on its own. A completed fishbone diagram is a list of suspects, not a verdict. The real work, validating which causes are actually driving the problem with data, comes after the diagram is built.
The three names you will encounter:
Fishbone Diagram - named for its visual shape
Ishikawa Diagram - named after its creator, Dr Kaoru Ishikawa
Cause and Effect Diagram - named for its function
All three refer to the same tool. In a Lean Six Sigma context, it sits in the Analyse phase of DMAIC, typically after data collection has confirmed the problem exists and before you design solutions.
Use a Fishbone Diagram when:
A problem has multiple possible causes and you are not sure which matter most
A team is jumping to solutions without understanding the underlying cause
A previous fix failed and the problem has returned
You need to document the analysis for an audit, a project review, or a regulatory body
You are in the Analyse phase of a DMAIC project and need to structure a brainstorm
Do not use it as a standalone tool for simple, single-cause problems. If you already know the cause and have data to prove it, skip the diagram and move to solutions.
Before you build one, understand what each part represents.
| Part | What it represents |
|---|---|
| Head (right side) | The problem or effect you are investigating |
| Spine | The horizontal arrow connecting the head to the tail |
| Main bones | The major cause categories (typically 4 to 6) |
| Sub-bones | Specific causes within each category |
| Sub-sub-bones | Deeper contributing factors, added when a cause needs further drilling |
The diagram reads right to left. The problem sits on the right. Causes branch in from the left. The further left you go, the more specific the cause becomes.
The most widely used category framework in manufacturing and operations is the 6Ms. Each M represents a major area of potential cause:
Man (People): anyone involved in the process, including training, skill, fatigue, and human error
Method (Process): how the work is done, including procedures, instructions, and standards
Machine (Equipment): tools, machinery, software, and any technology involved
Material: raw materials, components, consumables, and inputs to the process
Measurement: how performance is tracked, including calibration, data accuracy, and reporting
Mother Nature (Environment): physical conditions such as temperature, humidity, layout, and noise
The 6Ms are a starting point, not a rule. In service and healthcare environments, teams often adapt the framework. Common alternatives include the 4Ps (Policies, Procedures, People, Plant) or the 8Ps used in service industries, which add Price, Promotion, Product, and Place.
You need a whiteboard, a large sheet of paper, or a digital template. You need a team. And you need a clearly defined problem before you walk into the room.
Draw a box on the right-hand side of your surface. Write the problem inside it. Draw a horizontal arrow pointing into the box from the left. This is your spine.
The problem statement is the most important line on the diagram. A vague statement produces a vague analysis. A specific one focuses the team.
Weak: "Quality issues on the production line" Strong: "22% defect rate on Line 3 during night shifts in Q2, up from 8% in Q1"
The stronger version is measurable, time-bound, and specific enough that every team member knows exactly what they are trying to explain. The American Society for Quality (ASQ) recommends that the problem statement be agreed upon by all participants before the session begins.
Draw four to six diagonal lines branching off the spine, roughly three above and three below. Label each one with a cause category. For most manufacturing and operational problems, start with the 6Ms and adapt as needed.
A fishbone session with one person is a list of your own assumptions. The tool works because different people see the same process differently.
A productive team typically includes:
Someone who works directly in the process every day
Someone who receives the output of the process (internal customer)
A subject matter expert
At least one person with no direct involvement, who can ask naive questions
Five to eight people is the practical range. Fewer and you miss perspectives. More and the session becomes hard to manage. Plan for 60 to 90 minutes.
Work through each bone systematically. For each category, ask the team: "What in this area could cause the problem?"
Write every suggestion on the diagram without debate. The brainstorm phase is generative. Evaluation comes later. Use sticky notes if you want flexibility to move causes between categories.
Practical tip: If the team is stuck on a category, ask "Has anything in this area changed recently?" Change is often where causes hide.
For each cause identified, ask: "Why does this happen?" Add the answer as a smaller branch off the main cause. This is where the 5 Whys technique integrates naturally. Keep asking why until you reach a cause that is specific enough to investigate with data.
A cause like "operator error" is not specific enough. "Operator skips step 4 because the instruction sheet is stored in a different room" is.
When the brainstorm is complete, step back and look at the full diagram. Work with the team to identify the causes most likely to be driving the problem. Use multi-voting: give each participant three to five votes and ask them to allocate votes to the causes they believe are most significant.
Circle or highlight the top candidates. These become your hypotheses for data validation.
The diagram does not prove anything. It generates hypotheses. For each prioritised cause, design a data collection plan to confirm or rule it out. This might mean stratifying existing data, running a measurement study, or observing the process directly.
A fishbone session that ends without a validation plan has produced a list of opinions, not a root cause analysis. The ASQ's guide to root cause analysis is clear on this point: structured analysis tools must be paired with evidence before conclusions are drawn.
To make this concrete, here is how a cross-functional team might apply the fishbone diagram to a real operational problem.
Problem statement: "On-time delivery rate dropped from 94% to 79% in the six weeks following the introduction of a new warehouse management system."
The team draws the spine, places the problem in the head, and sets up six bones using the 6M framework. The brainstorm produces the following:
| Category | Causes identified |
|---|---|
| Man | Staff unfamiliar with new system; night shift team had less training time |
| Method | Pick-and-pack sequence changed with new system; no updated SOPs issued |
| Machine | New system has 15-second lag on barcode scans; two scanner terminals offline |
| Material | Bin locations reorganised but labels not updated across all zones |
| Measurement | Dispatch confirmation now requires two-step sign-off; adds 4 minutes per order |
| Environment | Temporary storage zone created during system rollout reduces floor space by 30% |
After multi-voting, the team circles three priority causes:
No updated SOPs issued after the method change
Night shift team received less training time
Two-step dispatch sign-off adding 4 minutes per order
These become the hypotheses. The team then collects data: they compare on-time rates between day and night shifts (confirming the training gap), time the dispatch process before and after the sign-off change (confirming the 4-minute delay), and audit SOP compliance on the floor.
Two of the three hypotheses are confirmed by data. One is not. The team moves to solution design with evidence, not assumptions.
The fishbone diagram is simple to draw. It is surprisingly easy to misuse. These are the failure patterns that appear most often.
"Poor quality" and "customer complaints" are not problem statements. They are categories. A vague head produces a vague diagram. Every cause the team generates will be equally vague, and the session will end with a list of things that are broadly true about your business rather than specific hypotheses about this problem.
Write the problem statement before the session. Include a metric, a time period, and a baseline.
If everyone in the room works in the same function, the diagram will reflect that function's perspective. A manufacturing team running a fishbone on a delivery problem without anyone from logistics or customer service will miss entire categories of cause.
Cross-functional teams produce better diagrams. This is not a preference. It is structural.
"Operator error" appears on fishbone diagrams everywhere. It is almost never a root cause. It is a category. The real cause is why the operator made the error: unclear instructions, inadequate training, a poorly designed process, time pressure.
If your diagram is full of one-word causes, you have not drilled deep enough. Ask "why does this happen?" at least twice for every cause before you consider it specific enough to investigate.
A fishbone session that produces a diagram and nothing else has generated a list of opinions. Opinions need to be tested. Before the team leaves the room, assign ownership and a deadline for validating each priority cause. Without this step, the diagram goes on a shelf and the problem continues.
The fishbone diagram structures the thinking. It does not replace it. Some teams complete a diagram and treat the most-voted cause as the confirmed root cause without collecting a single data point. That is not root cause analysis. That is a structured guess.
The diagram is the starting point. Data is the answer.
The fishbone diagram is one of several root cause analysis tools. Knowing when to use it, and when to use something else, saves time.
| Tool | Best used when | Limitation |
|---|---|---|
| Fishbone Diagram | Multiple possible causes; team brainstorm needed | Does not prove causes; needs data validation |
| 5 Whys | Single cause chain; quick investigation | Can oversimplify complex problems with multiple causes |
| Pareto Chart | You have data on defect types or complaint categories | Requires existing data; does not explain why |
| FMEA | Proactive risk analysis before a process launches | Resource-intensive; not suited to reactive problem-solving |
| Fault Tree Analysis | Complex systems where failures have multiple pathways | Requires technical expertise; time-consuming |
In practice, the fishbone diagram and 5 Whys are often used together. The fishbone maps the breadth of possible causes across categories. The 5 Whys drills down the depth of each cause. Used in sequence, they complement each other well.
The Lean Enterprise Institute notes that in A3 problem-solving, teams frequently use a fishbone to populate the cause analysis section before selecting the most likely cause for 5 Whys investigation. This combination is a reliable structure for most operational problems.
The 6M framework was designed for manufacturing. The underlying structure works across every sector, but the categories need to fit the environment.
The 6Ms apply directly. The tool is most powerful here when investigating quality defects, equipment downtime, or yield losses. The physical nature of manufacturing processes means causes are often observable and measurable.
NHS improvement teams frequently use a modified framework. "Machine" becomes "Equipment and Technology." "Mother Nature" becomes "Environment," covering ward layout, staffing ratios, and shift handover conditions. "Man" becomes "Staff," covering training, fatigue, and communication. The NHS England improvement methodology incorporates structured cause analysis tools including fishbone diagrams in serious incident investigations.
In service environments without physical machinery, the 6Ms are replaced by process-oriented categories. A common adaptation uses: People, Process, Policy, Technology, Data, and Environment. This maps better to the causes of errors, delays, and compliance failures in office-based processes.
You do not need software to run a fishbone session. A whiteboard and marker pens are sufficient, and often better, because the physical act of drawing and moving sticky notes keeps teams engaged.
That said, a pre-built template removes the setup time and ensures the structure is consistent across projects.
SimplicityHub provides two free templates you can download and use immediately:
Fishbone Diagram Template - a full working template with the 6M framework pre-built, suitable for most operational problems
Fishbone Starter Template - a blank version for teams who want to define their own categories
Both are available as part of the free template library, which includes over 80 Lean Six Sigma tools with no sign-up required.
If you want to go further with root cause analysis, the free Root Cause Analysis course covers the fishbone diagram alongside 5 Whys, Pareto analysis, Fault Tree Analysis, and FMEA, with a free certificate on completion.
For teams exploring AI-assisted analysis, the AI Root Cause Analysis page covers how automated fishbone generation and pattern recognition are changing how teams approach the Analyse phase.
The fishbone diagram has been in use for over 60 years because it solves a specific and persistent problem: teams jump to solutions before they understand causes.
Used correctly, it does three things well:
It forces breadth. By working through categories before conclusions, teams surface causes they would have missed if they went straight to the most obvious explanation.
It structures a team conversation. The diagram gives everyone a shared surface to contribute to. It reduces the risk that one voice dominates the analysis.
It produces testable hypotheses. The output is not a solution. It is a prioritised list of causes to validate with data. That distinction matters.
The tool has limits. It does not prove anything. It requires a specific problem statement to be useful. And it depends entirely on the team assembled to use it.
Build the diagram. Vote on the priorities. Then go and collect the data. That is the sequence. The diagram is the start of the analysis, not the end of it.
A fishbone diagram is used to organise possible causes of a problem into clear categories before you decide what to fix. It helps teams avoid guesswork, surface overlooked causes, and turn a broad problem into testable hypotheses.
The 6M framework groups causes into Man, Method, Machine, Material, Measurement, and Mother Nature. It gives teams a simple starting structure for brainstorming, especially in manufacturing and operational improvement work.
No. A fishbone diagram supports root cause analysis, but it does not prove the root cause on its own. It is a structured way to generate and prioritise likely causes, which you then validate with data.
Use a fishbone diagram when a problem may have multiple causes and the team needs a structured brainstorm. It works well in the Analyse phase of DMAIC, especially when the obvious explanation has not been confirmed.
The biggest mistakes are using a vague problem statement, stopping at surface-level causes like operator error, and finishing the session without a validation plan. Those mistakes turn the exercise into opinions rather than evidence.
Ready-to-use fishbone template with a worked example, plus 80+ other free Lean Six Sigma templates.