Map a broad set of possible causes without confusing a well-organised brainstorm with proof.
In one minute
An Ishikawa—or fishbone—diagram places a defined effect at the “head” and groups possible causes on branches. Teams often use categories such as People, Process, Technology, Data, Environment and Management, but categories should fit the work.
The diagram helps a group explore and organise hypotheses. It does not show which cause is true or how much each cause contributes. The next step is to choose high-value hypotheses and test them.
Best for: a problem with several possible cause families and cross-functional knowledge.
Avoid when: the effect is vague, the team has no process knowledge or quantitative data already identifies the cause.
The problem it addresses
Problem-solving groups can anchor on the first explanation, follow the loudest participant or generate a flat list with no causal structure. The Ishikawa diagram creates shared coverage and encourages deeper branches.
The intended outcome is a structured hypothesis map and an evidence plan.
When to use it
- during Root Cause Analysis after the problem is defined;
- when causes may come from several parts of a process;
- in a cross-functional workshop;
- to organise findings from interviews and observations;
- before deciding what data to collect;
- to deepen a high-priority category from a Pareto chart.
When not to use it
Do not use the diagram:
- as evidence that a listed cause is real;
- before agreeing on one precise effect;
- to rank causes by the number of ideas on a branch;
- when the issue is a simple, verified one-step failure;
- as a decorative requirement after a decision is already made;
- to replace statistical or technical analysis where it is needed.
Inputs required
- one measurable effect statement;
- scope, time and location;
- people familiar with different parts of the work;
- process map, records or observations where available;
- a suitable category set;
- a method for prioritising and testing hypotheses.
Step-by-step process
1. Define the effect
Write the effect at the head with extent and boundary. Example: “Incorrect appointment-time complaints rose from 18 to 31 per 1,000 reschedules in May.”
2. Choose meaningful categories
Manufacturing often uses versions of the 6Ms. Service or digital teams may use:
- people;
- process;
- technology;
- data/information;
- policy/management;
- environment/partners.
Categories are prompts, not causes.
3. Generate possible causes
Start silently to reduce anchoring, then add concise causes to the relevant branches. A cause can appear in more than one category if the mechanisms differ.
4. Deepen the branches
Ask why or what condition created each candidate. Add sub-causes until the hypothesis can be tested.
5. Check coverage and duplicates
Look for empty branches, repeated labels, interactions and factors outside scope.
6. Prioritise hypotheses
Use impact, plausibility, evidence gap and test cost. Do not vote on “the root cause.”
7. Build an evidence plan
For each priority hypothesis, define the observation, comparison, query or experiment that could support or reject it.
8. Update the diagram
Mark branches as supported, rejected or unresolved. Move verified relationships into the wider RCA record.
Visual model
Text alternative: six cause families point toward one defined effect. Candidate causes are then prioritised and converted into evidence tests.
Interactive example
Scenario
Effect: “Complaints about incorrect reminder times increased by 35% after the May release.”
Candidate causes:
- agents entered the wrong time;
- reschedule integration test missing;
- reminder job reads stale data;
- customers misunderstand time zones;
- release approval lacked downstream review;
- messaging provider delayed delivery.
Your move
Place each cause in a useful category and identify which ones can already be challenged by evidence.
Worked answer
| Candidate | Category | Evidence test |
|---|---|---|
| Agent entry error | People / Process | Compare manual entry patterns before and after release |
| Missing reschedule test | Process | Inspect test suite and release changes |
| Stale read model | Technology / Data | Trace affected records and reproduce |
| Time-zone misunderstanding | Data / Customer context | Segment complaints by timezone and message content |
| Missing downstream review | Management / Process | Review approval checklist and change record |
| Provider delay | Partner / Technology | Compare delivery timestamps; delay alone may not explain wrong content |
If delivery success and timing remained stable, the provider hypothesis becomes weaker. It should be marked as challenged, not silently deleted.
Facilitation notes
- Use a neutral facilitator for sensitive problems.
- Invite frontline and technical knowledge, not only managers.
- Ask for mechanisms, not labels such as “communication.”
- Keep idea generation separate from evaluation.
- Give every high-priority hypothesis an owner and evidence test.
Expected output
- one defined effect;
- cause categories suited to the process;
- a multi-level hypothesis map;
- interactions and evidence gaps;
- prioritised hypotheses;
- tests, owners and statuses.
Common mistakes
- Using a vague effect such as “poor quality.”
- Treating standard categories as mandatory.
- Writing symptoms on cause branches.
- Assuming more ideas on a branch mean greater importance.
- Voting for a root cause.
- Stopping after brainstorming.
- Ignoring interactions between branches.
Quality checklist
- The effect is measurable and scoped.
- Categories fit the actual work.
- Participants represent relevant process knowledge.
- Branches include deeper mechanisms, not only labels.
- Facts and hypotheses are distinguishable.
- Priority causes have evidence tests.
- The diagram is updated as evidence changes.
Template
| Cause family | Candidate cause | Deeper mechanism | Existing evidence | Evidence needed | Test owner | Status |
|---|---|---|---|---|---|---|
| People | ||||||
| Process | ||||||
| Technology | ||||||
| Data | ||||||
| Management | ||||||
| Environment |
Knowledge check
What does a completed Ishikawa diagram prove?
A. The longest branch is the root cause.
B. Every listed cause contributed to the effect.
C. The team has a structured set of hypotheses to test.
D. The most frequently mentioned cause should be fixed first.
Answer: C. The diagram organises possible causes; evidence is still required.
Related tools
- Supports: Root Cause Analysis
- Often combined with: 5 Whys, Pareto Analysis
- Followed by: evidence collection and PDCA
- Not to be confused with: a verified causal model
References
- Ishikawa, K. Guide to Quality Control. Asian Productivity Organization, 1976. ISBN 978-92-833-1036-5. Google Books record (opens in a new tab). Primary author source.
- American Society for Quality. “What is a Fishbone Diagram?” ASQ guide (opens in a new tab). Authoritative professional procedure.
- American Society for Quality. “Cause Analysis Tools.” ASQ overview (opens in a new tab). Authoritative context on combining fishbone and other causal tools.
Sources reviewed 27 July 2026.