Skip to content
All tools
Problem SolvingBeginner

Ishikawa Diagram

Organise a team’s possible causes around a clearly defined effect, then turn branches into evidence tests.

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

CandidateCategoryEvidence test
Agent entry errorPeople / ProcessCompare manual entry patterns before and after release
Missing reschedule testProcessInspect test suite and release changes
Stale read modelTechnology / DataTrace affected records and reproduce
Time-zone misunderstandingData / Customer contextSegment complaints by timezone and message content
Missing downstream reviewManagement / ProcessReview approval checklist and change record
Provider delayPartner / TechnologyCompare 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

  1. Using a vague effect such as “poor quality.”
  2. Treating standard categories as mandatory.
  3. Writing symptoms on cause branches.
  4. Assuming more ideas on a branch mean greater importance.
  5. Voting for a root cause.
  6. Stopping after brainstorming.
  7. 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 familyCandidate causeDeeper mechanismExisting evidenceEvidence neededTest ownerStatus
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

References

  1. 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.
  2. American Society for Quality. “What is a Fishbone Diagram?” ASQ guide (opens in a new tab). Authoritative professional procedure.
  3. 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.