Ishikawa Diagram: Guide, Facilitation Tips & Template

The Ishikawa diagram (also called fishbone diagram, cause-and-effect diagram, or herringbone diagram) is a structured root cause analysis tool that organizes potential causes of a problem into categories and displays them visually in a fishbone pattern. It belongs to the seven basic quality tools (Q7) and was first used in 1943 by Kaoru Ishikawa at Kawasaki Steel Works [1].

Unlike unstructured brainstorming, the Ishikawa diagram forces systematic coverage of all cause categories. This makes it particularly valuable when a problem has multiple potential cause areas — Man, Method, Machine, Material, Environment — and the team needs to look beyond the most obvious explanation.

Search for “Ishikawa diagram” online and you’ll find ten variations of the same content: definition, 5M list, a manufacturing example. No result provides a concrete facilitation script for a 90-minute workshop. None explains which M model (4M, 5M, 6M, 7M, 8M) to use when. And none honestly names the situations where the Ishikawa diagram is the wrong tool.

This guide closes those gaps — with a complete workshop format, an M-model decision guide, a service context example, and an overview of the most common mistakes.

From Kawasaki Steel Works to Q7: Where the method comes from

Kaoru Ishikawa (1915-1989) was a professor at the University of Tokyo’s engineering faculty and one of the founders of modern quality management. In 1943, he first used the cause-and-effect diagram at Kawasaki Steel Works to systematically analyze factory problems [1].

In his foundational work Guide to Quality Control (1968), Ishikawa described the diagram as one of seven basic quality tools — alongside histograms, check sheets, Pareto charts, control charts, scatter plots, and run charts [1]. The American Society for Quality (ASQ) still ranks it as one of the most widely used tools in quality management [2].

The name “fishbone diagram” derives from its visual structure: the problem sits at the fish’s head (right), the main categories form the bones, and individual causes branch off as sub-bones — as deep as needed until the root cause is reached.

Which M model should you use?

A common source of confusion: there is no single set of M categories. Ishikawa himself recommended adapting categories to the specific problem [1]. The common M models are variants, not dogma.

Model	Categories	Suited for	Typical industry
4M	Man, Machine, Material, Method	Simple production problems	Manufacturing (basic form)
5M	+ Milieu (Environment)	Problems with environmental factors	Manufacturing, logistics
6M	+ Measurement	Quality problems with data aspects	Quality management, laboratory
7M	+ Management	Organizational problems	Services, project management
8M	+ Money	Problems with budget relevance	Strategic analysis

Recommendation: Start with 6M as your default configuration. Add Management (7M) when organizational causes are relevant — which is almost always the case for service problems. The 4M basic form suffices for simple, well-defined manufacturing problems.

Important: You are not bound to these labels. If your problem involves a digital customer service process, more useful categories might be “Technology,” “Data,” “Process,” “Customer interface,” “Training,” and “Organization.” The M models are starting points, not constraints.

When is the Ishikawa diagram the right choice?

The Ishikawa diagram is not the right tool for every problem. Its strength lies in structured hypothesis generation about possible causes — not in cause confirmation.

Use the Ishikawa diagram when:

• A problem has multiple potential cause areas and you want to systematically work through all of them
• A cross-functional team has different explanations for the same problem — ideally with representatives of different user types who know the problem from their respective perspectives
• You need to go beyond the obvious and push the team to think deeper
• Traceability of the analysis matters for stakeholders or audits — a documented Ishikawa workshop supports compliance with ISO 9001:2015 clause 10.2 (Nonconformity and Corrective Action), which requires systematic cause determination for deviations

Use a different tool when:

Situation	Better alternative	Why
You want to find the deepest cause of a single chain	5 Whys method	5 Whys drills vertically; Ishikawa works horizontally across categories
The system has feedback loops and complex interactions	System dynamics / Causal loop diagram	Ishikawa cannot capture interdependencies between causes [3]
You need quantitative probabilities for cause chains	Fault tree analysis (FTA)	FTA shows logical dependencies and calculable failure probabilities
You want to proactively prevent failures before they occur	FMEA	Ishikawa is retrospective — it analyzes existing problems, not potential ones [4]
Quantitative data already exists	Scatter plot / Regression / DOE	Statistical methods provide evidence; Ishikawa provides hypotheses

Practical tip — Ishikawa + 5 Whys + Pareto as an integrated workflow:

Ishikawa alone delivers hypotheses, but not confirmed causes or an action plan. Only the combination with two more tools produces a complete analysis cycle (similar to how the Morphological Box uses systematic combination, this workflow uses systematic deepening):

1. Ishikawa for breadth (90 minutes, joint workshop): Collect all possible causes across M categories. Prioritize with dot voting down to the top 3. Result: 3 cause hypotheses.
2. 5 Whys for depth (45 minutes, separate session per hypothesis): Drill each of the 3 prioritized causes with the 5 Whys method down to the root cause. Deliberately schedule this session not immediately after the Ishikawa workshop — the team needs time to review initial data and approach the deep-dive with fresh eyes.
3. Pareto for prioritization (30 minutes): Evaluate the identified root causes by frequency and impact. Create a concrete action plan with owners and deadlines. The Pareto analysis prevents the most common failure mode: trying to address all causes at once and thoroughly fixing none of them.

Step by step: Ishikawa workshop in 90 minutes

Most Ishikawa guides describe abstract steps. Here is a concrete workshop format with time estimates, materials, and facilitation tips.

Preparation (before the workshop):

• Participants: 4-8 people from different departments who know the problem from different perspectives [6]. VOREST AG recommends 2-4 hours for a complete workshop [6] — our 90-minute format is a streamlined variant that condenses prioritization and follow-up to the essentials.
• Materials: Whiteboard or flipchart, sticky notes in different colors (one color per M category), markers, dot stickers for prioritization
• Space: Standing tables or open area preferred — standing workshops tend to stay shorter and more active than seated ones
• Preparation: Pre-formulate the problem statement and send it to all participants in advance

Phase 1: Define the problem (10 minutes)

Formulate the problem as a specific, measurable statement — not a vague complaint.

Poor	Better	Industry example
”Quality is bad"	"The error rate in the onboarding phase increased by 40% in Q3”	Telecom provider
”Customers are complaining"	"23% of new customers cancel within the first 90 days”	SaaS / Insurance
”The process doesn’t work"	"Lead time from inquiry to proposal is 14 days instead of the target 5 days”	B2B Mittelstand
”Employees make mistakes"	"18% of claims submissions are missing required fields, causing follow-up requests and 4-day delays”	Insurance
”Service is too slow"	"Median first-resolution time in customer support is 72h instead of the 24h SLA target”	IT services

Facilitation tip: Let the group sharpen the problem statement together. It’s better to invest 5 extra minutes in the definition than 30 minutes in a diagram with a vague question. The Juran Institute warns: “Without a good, clear problem statement, the fishbone diagram will not be effective” [5].

Write the final problem statement at the “fish head” (right side of the whiteboard) and draw the backbone (horizontal line to the left).

Phase 2: Set M categories (5 minutes)

Choose your M model (see table above) and draw the main bones. For most service problems, we recommend 6M or 7M.

Facilitation tip: Don’t just write the categories on the bones — post a guiding question for each. This directs brainstorming more effectively than a bare category label.

7M guiding questions (post on the whiteboard or read aloud):

Category	Guiding question
Man	”What human factors — knowledge, experience, communication, availability — could contribute to this problem?”
Machine	”What technical systems, tools, or software could be involved?”
Material	”What input data, materials, or information could be faulty or incomplete?”
Method	”What processes, work instructions, or workflows could be causing the problem?”
Milieu	”What environmental factors — market, customer behavior, regulation — could play a role?”
Measurement	”Could faulty measurements, KPIs, or data collection methods be distorting or hiding the problem?”
Management	”What decisions, resources, or structures at the leadership level could be contributing?”

Say aloud: “We’re starting with the Man category now. You have 5 minutes. Write each cause on a separate sticky note — keywords are enough. There are no wrong answers.”

Phase 3: Collect causes (35 minutes)

This is the core phase. Work through each category systematically — not all at once.

Process:

1. Start with one category (e.g., “Man”)
2. Each participant writes causes on sticky notes (one cause per note, keywords suffice)
3. Stick notes to the corresponding bone
4. For each cause, ask: “And why is that?” — the answer becomes a sub-bone
5. Repeat “Why?” 2-3 times to move from symptoms to root causes
6. After 5 minutes, switch to the next category

Facilitation tip: In this phase, the rule is separate collection from evaluation. Don’t allow comments like “We can never change that” or “That’s unrealistic.” Every cause mentioned gets recorded. Evaluation comes in Phase 4.

Facilitation tip: If a category remains “empty,” that’s a signal: either the category is irrelevant to this problem (which is fine), or the team has a blind spot. Ask specifically: “If I were to ask department [X] — what would they say?”

When things get difficult — three typical situations:

• The team goes silent: Say: “I’m not hearing anything for category [X] yet. Imagine a new employee starts tomorrow and observes our process for the first time — what would they stumble over?” The perspective shift almost always breaks the blockage.
• One person dominates: Say: “Thanks for that input, [Name]. I’d like to deliberately hear other perspectives now. Who sees it differently or can add something?” Alternatively: set 2 minutes of silent individual writing on sticky notes, then collect.
• Discussion instead of collection: Say: “We’re collecting right now — evaluation comes in Phase 4. Please write both viewpoints as separate sticky notes.” Interrupt discussions consistently — they consume the entire timebox.

Time signal: Announce 1 minute before each category switch: “60 seconds left for Man, then we’re switching to Machine.” Use a visible timer (phone timer on the table).

Phase 4: Prioritize (20 minutes)

The diagram is now full — possibly with 30-50 sticky notes. Without prioritization, it remains a colorful poster without an action plan.

Method 1: Dot voting (quick, 10 minutes)

• Each participant gets 3 dot stickers
• Place dots on the causes deemed most likely
• The 3-5 causes with the most dots are pursued further

Method 2: ABC classification (more thorough, 20 minutes)

• A = strong influence (probable root cause)
• B = medium influence (possible contributor)
• C = weak influence (unlikely)
• Only A-causes are pursued further [6]

Method 3: X/N/C classification (data-driven, 20 minutes)

• X = cause confirmed by data
• N = cause refuted by data
• C = still to be verified (data missing)
• All C-causes become verification assignments [7]

Facilitation tip: Method 1 (dot voting) suits quick workshops. Method 3 (X/N/C) suits teams that already have data. Method 2 (ABC) falls between the two. Choose the method before the workshop, not during it.

Phase 5: Define next steps (20 minutes)

For each prioritized cause:

1. Define verification: What data needs to be collected to confirm or refute the hypothesis?
2. Assign owners: Who will investigate this cause by when?
3. Outline measures: If the cause is confirmed, what is the first countermeasure?

Important: The Ishikawa diagram produces hypotheses, not confirmed causes. The results “reflect the team’s assumptions, not confirmed facts” [8]. Without verification, the workshop is wasted time [5].

Document the results: photo of the diagram, list of prioritized causes with owners and deadlines, planned verification steps.

Example: Root cause analysis in customer service

Problem: “23% of new customers cancel within the first 90 days after signing the contract.”

A cross-functional team from customer service, product management, IT, and sales creates a 7M Ishikawa diagram:

Category	Possible causes	Deeper cause (Why?)
Man	Service staff don’t know all product features	Onboarding training covers only 60% of features
Method	No structured onboarding process for new customers	Process wasn’t updated when the product expanded
Machine (Technology)	Self-service portal has 8-second load time	Backend migration to new system delayed
Material (Data)	Customer feedback isn’t systematically evaluated	No feedback loop between support and product team
Milieu (Customer interface)	Expectations from sales don’t match reality	Sales promises features still in development
Management	No dedicated onboarding team, unclear responsibilities	Onboarding was never defined as a standalone process
Measurement	Churn rate measured only after 90 days — too late	No early warning system for churn signals in the first 30 days

Result after prioritization (dot voting): The three main hypotheses are: (1) missing structured onboarding process, (2) expectation gap between sales and reality, (3) missing early warning system.

Next step: Collect data for each hypothesis — e.g., exit interviews with canceled customers, comparison of sales promises with product reality, analysis of first 30-day usage data. If you want to translate the identified causes into concrete improvement measures, you can continue with personas and prototypes.

Note: This example is illustratively constructed to demonstrate the method in a service context.

5 common mistakes with the Ishikawa diagram

1. Vague problem definition

Symptom: The diagram becomes enormous, the discussion unfocused. After 60 minutes, nobody feels closer to the problem.

Fix: Invest 10-15 minutes in a precise, measurable problem statement before drawing the diagram. If you can’t formulate the problem in one sentence with a number, it’s not sharp enough.

2. Staying on the surface

Symptom: The sticky notes describe symptoms instead of causes. “Customers are unhappy” is not a sticky note that belongs on an Ishikawa diagram.

Fix: For each stated cause, ask “Why?” at least twice. The sub-bones (sub-causes) are often more valuable than the main bones.

3. 100 sticky notes, zero prioritization

Symptom: The team brainstormed enthusiastically, the diagram is full — and then nothing happens. Nobody knows which causes to investigate first.

Fix: Plan prioritization as a fixed part of the workshop (Phase 4). Without prioritization, the diagram is decoration, not a tool.

4. Confusing hypotheses with facts

Symptom: The team “confirms” causes in the workshop through nodding and agreement, without collecting a single data point.

Fix: Each prioritized cause needs a verification plan: what data, who collects it, by when. As long as no data exists, all causes are hypotheses [5][8].

5. Using the wrong method for the problem

Symptom: The problem is highly complex with many interactions (e.g., supply chain problems with dozens of variables). The Ishikawa diagram simplifies reality so much that important connections are lost.

Fix: For complex systems with feedback loops, causal loop diagrams or system dynamics models are better suited. For quantitative cause chains, fault tree analysis (FTA) is the right tool [3].

When the Ishikawa diagram does NOT work

No tool fits every problem. You should know these limitations before calling your next Ishikawa meeting:

1. Complex systems with interactions: The Ishikawa diagram represents causes as independent branches. In reality, causes interact — a staffing decision affects the process, which affects the technology, which affects the staff. The diagram cannot capture these feedback loops [3].

2. Reactive analysis after an event: The Ishikawa diagram analyzes causes before a problem — what led to it? It does not capture what happened after control was lost. For reactive analyses, you need additional tools [10].

3. When quantitative data already exists: If you already have data pointing to a cause, a brainstorming workshop is a waste of time. Use statistical tools (scatter plots, regression) instead to confirm the cause [2].

4. Insufficient team expertise: The quality of the Ishikawa diagram depends directly on the participants’ expertise. A team without domain knowledge produces superficial causes [9].

A systematic review of 21 studies shows: root cause analysis tools (including Ishikawa) are useful for identifying causes, but not for implementing effective prevention measures [4]. The bottleneck is not in brainstorming — it’s in follow-through.

When follow-through is disciplined, the method delivers: Kumah et al. (2024) documented how a hospital reduced needlestick injuries from 11 cases (2018) to 2 cases (2021) — through a fishbone-based improvement programme with consistent implementation of identified countermeasures [11]. The counterexample shows: the problem is not the Ishikawa diagram itself, but organizational discipline afterward.

Creating an Ishikawa diagram: Digital tools

Tool	Advantages	Disadvantages	Suited for
Whiteboard + sticky notes	Tactile, promotes participation, no learning curve	Not remote-capable, hard to document	On-site workshops
Miro / Mural	Remote-capable, easy to share and document	Less tactile, requires licenses	Remote and hybrid teams
Excel / Google Sheets	Good for prioritization phase, data directly integrable	No visual fishbone format	Data-driven follow-up
PowerPoint / Google Slides	Good presentation graphics	Cumbersome for brainstorming	Results presentation
Lucidchart / draw.io	Professional diagrams, templates available	Too complex for quick workshops	Documentation and reports

Recommendation: Use whiteboard + sticky notes for the workshop itself (speed and participation matter more than digital perfection). Transfer the result to Miro or Lucidchart afterward for documentation.

Download template

We provide a free Ishikawa diagram template that you can use directly in your next workshop. The template includes:

• A blank 7M structure to fill in
• The customer service example as a completed reference
• A prioritization matrix for Phase 4
• A checklist for workshop preparation

Frequently asked questions

What is the 7M method?

The 7M method extends the classic Ishikawa diagram with the “Management” category. The seven Ms are: Man, Machine, Material, Method, Milieu (Environment), Measurement, and Management. Adding Management is particularly useful for organizational problems and in service contexts, where leadership decisions are often a central cause.

How do I create an Ishikawa diagram?

In five steps: (1) Formulate the problem as a measurable statement and write it at the “fish head.” (2) Set M categories as main bones (recommended: 6M or 7M). (3) Collect possible causes per category on sticky notes and deepen with “Why?” chains. (4) Prioritize causes (dot voting, ABC, or X/N/C classification). (5) Create verification plans for prioritized causes. Allow 90 minutes for a complete workshop.

What is the difference between 5M and 6M?

The 5M model includes Man, Machine, Material, Method, and Milieu (Environment). The 6M model adds the Measurement category. The difference: 6M considers that faulty measurements or insufficient data collection can themselves be causes of problems. Use 6M when data quality or measurement processes play a role.

What is the goal of the Ishikawa diagram?

The Ishikawa diagram has two goals: (1) To systematically and completely identify all possible causes of a problem — beyond the obvious. (2) To visually structure these causes so that a team can jointly prioritize and target the most likely root causes for investigation. It is a hypothesis generator, not an analytical tool.

When should you NOT use the Ishikawa diagram?

In four situations: (1) With highly complex systems with feedback loops — use system dynamics models instead. (2) When quantitative data already exists — use statistical methods. (3) For proactive failure prevention — use FMEA. (4) When the team has no domain expertise about the problem.

What is the difference between Ishikawa and the 5 Whys method?

The Ishikawa diagram works horizontally across categories: it collects possible causes from different areas (Man, Method, Machine, etc.). The 5 Whys method works vertically in depth: it drills a single cause chain step by step downward. Both methods complement each other ideally: use Ishikawa for breadth, 5 Whys for depth.

Related methods

• Morphological box: When you want to systematically develop solution combinations rather than analyze causes
• 5 Whys method: When you want to trace a single cause chain in depth
• PDCA cycle: When you want to start a structured improvement cycle after root cause analysis
• Kano model: When you want to prioritize customer needs rather than analyze problems
• Gemba walk: When you want to observe the actual process on-site before root cause analysis

---

Research methodology

This article synthesizes findings from Kaoru Ishikawa’s original publication, a systematic review on the effectiveness of root cause analysis tools, and the analysis of 8 German-language specialist contributions on the Ishikawa diagram. Sources were selected based on methodological rigor, practical relevance, and currency. All service context examples are illustratively constructed, not documented case studies.

Limitations: Academic literature on the effectiveness of the Ishikawa diagram primarily comes from healthcare and manufacturing. Empirical studies on its application in service innovation are limited.

Disclosure

SI Labs offers consulting services in the area of service innovation and uses the Ishikawa diagram as a tool in the analysis phase of the Integrated Service Engineering Process (iSEP). This practical experience informs the facilitation tips in this article; readers should be aware of potential perspective bias.

References

[1] Ishikawa, Kaoru. Guide to Quality Control. Tokyo: Asian Productivity Organization, 1968. [Book | Historical | Citations: >10,000 | Quality: 95/100]

[2] American Society for Quality. “Seven Basic Quality Tools.” https://asq.org/quality-resources/seven-basic-quality-tools [Industry Authority | Quality: 90/100]

[3] Qualityze. “Fishbone vs. Cause & Effect: Choosing the Right RCA Tool.” https://www.qualityze.com/blogs/cause-effect-vs-fishbone-diagram [Industry | Quality: 70/100]

[4] Martin-Delgado, J. et al. “How Much of Root Cause Analysis Translates into Improved Patient Safety: A Systematic Review.” Medical Principles and Practice (2020). DOI: 10.1159/000508677 [Systematic Review | N=21 studies | Citations: 100+ | Quality: 85/100]

[5] Juran Institute. “The Ultimate Guide to Cause and Effect Diagrams.” https://www.juran.com/blog/the-ultimate-guide-to-cause-and-effect-diagrams/ [Industry Authority | Quality: 85/100]

[6] VOREST AG. “Ishikawa-Diagramm — Ursache-Wirkungs-Diagramm.” https://www.vorest-ag.com/Qualitaetssicherung-Methoden/Wissen/Ishikawa-Diagramm [Practitioner | Quality: 75/100]

[7] Six Sigma Blackbelt. “Ishikawa-Diagramm.” https://www.sixsigmablackbelt.de/ishikawa-diagramm/ [Practitioner | Quality: 80/100]

[8] Qualitaetsmanagement.me. “Ishikawa-Diagramm.” https://qualitaetsmanagement.me/kvp-einfuehren/ishikawa-diagramm/ [Practitioner | Quality: 70/100]

[9] Lean Six Sigma Definition. “Fishbone Diagram.” https://www.leansixsigmadefinition.com/glossary/fishbone-diagram/ [Industry | Quality: 70/100]

[10] Aviation Safety Blog. “Pros and Cons of Fishbone Diagrams in Aviation SMS.” https://aviationsafetyblog.asms-pro.com/blog/pros-and-cons-of-fishbone-diagrams-in-aviation-sms-programs [Industry | Quality: 65/100]

[11] Kumah, E. et al. “Needlestick injuries among healthcare workers in a Ghanaian tertiary hospital: a fishbone-based quality improvement approach.” BMC Nursing, 2024. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC11345949/ [Case Study | N=1 hospital, 4-year longitudinal | Quality: 75/100]