Fishbone Diagram: What It Is and How to Use It
Map possible causes. Then look for the evidence.
One problem. Several possibilities.
A hypothetical cafe, at lunchtime.
On this page
A fishbone diagram is a visual tool for organizing the possible causes of a specific problem. It places the problem at the “head” and groups potential causes along branches that resemble a fish skeleton.
It helps a team look beyond the obvious explanation. It does not prove causes; it organizes possibilities for investigation.
The idea to remember
The finished diagram maps hypotheses, not confirmed facts.
What is a fishbone diagram?
A fishbone diagram maps the relationship between an effect and its possible causes. It is also called a cause-and-effect diagram or an Ishikawa diagram, after Kaoru Ishikawa, whom the American Society for Quality identifies as its creator.
The effect may be late deliveries, damaged products, or repeated complaints. Possible causes are grouped and divided into subcauses.
Why does it matter?
Problems rarely have only one explanation. A fishbone diagram helps a team:
- Explore causes from several parts of a process.
- Organize brainstorming so ideas are easier to review.
- Make assumptions visible instead of leaving them unspoken.
- Involve people with different knowledge of the work.
- Decide which possible causes require evidence or further investigation.
This reduces the risk of acting on the first explanation suggested.
The components of a fishbone diagram
A basic diagram contains four parts.
- The effect or problem: A clear statement at the head that describes what is happening without assuming why.
- The spine: A horizontal line connecting the cause categories to the effect.
- Main cause categories: Large branches that organize possible causes. Common labels include People, Methods, Equipment, Materials, Measurement, and Environment. They are prompts, not compulsory rules; choose categories that fit the process.
- Causes and subcauses: Smaller branches showing possible explanations and why broader causes might exist.
How does it work?
- Assemble the right people. Include those who understand and perform different parts of the process.
- Define the effect precisely. “Lunch orders take longer than 12 minutes” is more useful than “Orders are sometimes bad.”
- Choose useful categories. Use standard labels or create ones that match the process.
- Brainstorm possible causes. Ask what could cause the effect and add each answer to a relevant branch.
- Explore subcauses. Ask why broad causes might occur until the explanations can be checked.
- Review and investigate. Remove duplicates, clarify unclear wording, and select the most plausible or important causes for verification. Observe the process, collect data, review records, or run a small test before choosing corrective action.
A simple example
Hypothetical example: A small café finds that many weekday lunch orders take longer than 12 minutes.
The team writes that problem at the head of the diagram and proposes six possible causes. Each category below pairs the team's hypothesis with a suggested evidence-gathering action.
New staff have not practiced the lunch workflow.
Observe lunch orders handled by newer and experienced staff. Note where each handoff slows down, rather than assuming staff experience is the cause.
Food and drink orders follow separate queues with no clear handoff.
Time 20 orders from payment to collection. Record food and drink completion separately and observe how the two queues hand orders over.
One card reader creates a bottleneck.
Record how long customers wait to pay and how often the reader is in use. Check whether payment delays explain the total order delay.
Takeaway packaging is stored far from the preparation area.
Observe trips to collect packaging during a lunch period. Record their frequency and duration, and whether preparation stops while staff collect it.
The café records total order time but not where delays occur.
Record timestamps for payment, preparation, and collection. Missing measurement may hide the delay; it does not itself prove what makes orders late.
The ordering and collection queues cross during busy periods.
Observe the queue layout during the lunch rush. Note when paths cross, whether work is interrupted, and which order stages are affected.
No branch is proven. The team might time 20 orders, observe handoffs, and record when queues form to learn which ideas deserve action.
When should you use it?
Use a fishbone diagram when:
- A problem may have several contributing causes.
- A team keeps returning to the same untested explanation.
- People from different functions need to share what they know.
- You need to organize possible causes before collecting evidence.
- A recurring problem requires more than a quick fix.
It is less useful when the cause is verified or an urgent issue requires immediate containment.
How to interpret the result
Look for branches that are specific enough to investigate. Repeated ideas across categories may indicate an important connection, while empty categories may reveal gaps in the team’s knowledge.
Do not count the number of ideas in a category and declare the largest branch the cause. A branch with one verified cause can matter more than a branch with ten weak guesses. The next step is validation, not voting on which explanation sounds best.
Common confusion
A fishbone diagram and the 5 Whys both support cause analysis, but they work differently.
| Tool | What it organizes | What it helps you do |
|---|---|---|
| Fishbone diagram | Many possible causes across categories | Broaden the investigation |
| 5 Whys | One causal path in greater depth | Examine a selected explanation |
| Process map | Work in sequence | Understand the order of activities |
A team can use the fishbone diagram to broaden its view, then use deeper questions to examine a selected branch. A process map shows work in sequence; a fishbone diagram organizes possible explanations for an effect.
Common mistakes
- Writing a vague problem statement. An unclear effect produces unfocused causes.
- Including solutions as causes. “Buy another machine” is an action, not an explanation.
- Treating categories as fixed. Useful labels should reflect the actual process.
- Inviting only managers. People who perform the work often know causes others cannot see.
- Stopping at broad labels. “People” or “training” needs more detail before it can be tested.
- Assuming the diagram proves causation. Brainstormed causes must be verified.
Limitations
The quality of the diagram depends on the knowledge and openness of the participants. It may miss causes the group does not know about, reflect bias, or become cluttered in complex situations. Most importantly, it organizes hypotheses but does not establish which causes are real or how strongly they affect the result.
Quick checklist
Before using the diagram to guide action, check that:
A completed checklist is not proof of causation.
Put it to work
Create a first fishbone diagram in 25 minutes
- Spend 3 minutes writing one specific, observable problem at the right side of a blank page.
- Spend 3 minutes drawing the spine and four to six category branches that fit the problem.
- Spend 8 minutes listing possible causes under each category.
- Spend 5 minutes asking why the broadest causes might occur and adding subcauses.
- Spend 3 minutes marking the two or three causes that are both plausible and testable.
- Spend 3 minutes writing one evidence-gathering action for each marked cause.
Finish by checking that you selected causes to investigate, not causes to declare as proven.
Key takeaways
- A fishbone diagram organizes possible causes of one clearly defined effect.
- Its categories are prompts and should be adapted to the process being studied.
- Causes and subcauses are hypotheses until observation or data verifies them.
- The diagram broadens cause analysis, while the 5 Whys explores one causal path more deeply.
- The tool works best with people who understand how the process operates in practice.
Final takeaway
A fishbone diagram makes a complicated problem easier to examine by arranging possible causes into clear categories and subcauses. It helps a team see the problem as a system rather than jump to one convenient answer.
Its value comes from the investigation that follows. Use the diagram to ask better questions, then use observation and data to determine which causes actually matter.