Skip to main content
Category: Methods
Type: Problem-Solving Technique
Origin: Kaoru Ishikawa, 1960s, Japan
Also known as: Ishikawa Diagram, Cause-and-Effect Diagram, Herringbone Diagram
Quick Answer — The Fishbone Diagram (also called Ishikawa Diagram or Cause-and-Effect Diagram) is a visual brainstorming tool that organizes potential causes of a problem into categories, creating a diagram shaped like a fish skeleton. Developed by Japanese quality control expert Kaoru Ishikawa in the 1960s as part of the Toyota Production System, it helps teams systematically identify root causes rather than jumping to solutions.

​
What is a Fishbone Diagram?

A Fishbone Diagram is a structured brainstorming tool that helps teams identify all possible causes of a problem or effect. The diagram gets its name from its shape — a horizontal “spine” with diagonal “bones” branching off, resembling a fish skeleton. The head of the fish contains the problem or effect being analyzed, while each branch represents a major category of potential causes. The power of the Fishbone Diagram lies in its structure. Without such a framework, brainstorming sessions often devolve into chaos or get dominated by the loudest voices. The diagram forces systematic thinking by providing predefined categories — typically the “6Ms”: Man (people), Machine (equipment), Method (process), Material (resources), Measurement (data), and Mother Nature (environment). This categorization ensures causes are examined from multiple angles and prevents important areas from being overlooked.
“The quality of a product is created by the process that makes it. To improve quality, you must improve the process.” — Kaoru Ishikawa
The diagram works best as a team exercise. When diverse perspectives are combined in a single visual, patterns emerge that no individual would see alone. Each bone can have sub-bones, allowing teams to drill down from general categories to specific contributing factors. The goal is not just to list causes but to build a comprehensive understanding of how and why problems occur.

​
Fishbone Diagram in 3 Depths

  • Beginner: Draw a horizontal line with the problem statement at the right end. Add diagonal lines for major cause categories (6Ms). Brainstorm causes under each category without judgment — quantity over quality at this stage.
  • Practitioner: Use the diagram after gathering preliminary data. Apply the “five whys” technique on each identified cause to drill down to deeper levels. Prioritize causes based on frequency or impact, then validate with evidence.
  • Advanced: Combine Fishbone with fault tree analysis for complex systems. Use the diagram to map not just causes but causal relationships and feedback loops. Apply statistical analysis to identify which branches contain the most significant contributors.

​
Origin

The Fishbone Diagram was developed by Kaoru Ishikawa (1915-1989), a Japanese quality control expert and one of the founding figures of modern quality management. Ishikawa was a disciple of W. Edwards Deming and worked extensively with the Toyota Motor Corporation in the 1950s and 1960s. His work helped transform Japanese manufacturing from producing cheap, low-quality goods to becoming a global standard for excellence. Ishikawa introduced the diagram as part of his “quality circle” concept — small groups of workers who voluntarily meet to identify and solve quality problems. The diagram provided these groups with a structured way to analyze problems without assigning blame. It quickly became one of the seven basic tools of quality control, alongside Pareto charts, flow charts, histograms, and other visual problem-solving methods. The technique gained international recognition after Ishikawa’s 1985 book “What is Total Quality Control? The Japanese Way” was translated into English. Today, the Fishbone Diagram is used across industries — from manufacturing and healthcare to software development and education — wherever teams need to systematically analyze complex problems.

​
Key Points

1

Start with the Effect, Not the Causes

Always begin by clearly defining the problem or effect at the “head” of the fish. A vague problem statement produces a vague diagram. Be specific: “Manufacturing defect rate of 5%” is better than “quality problems.”
2

Choose Relevant Categories

While the 6Ms (Man, Machine, Method, Material, Measurement, Mother Nature) are the standard starting point, adjust categories to fit your context. Service organizations might use People, Process, Technology, and Customer. Software teams might use Code, Infrastructure, Data, and User Experience.
3

Brainstorm, Then Organize

First, generate as many potential causes as possible without evaluation — this is divergent thinking. Only after the brainstorm phase should causes be organized into categories and sub-categories. Premature criticism kills creativity.
4

Validate Before Acting

The diagram identifies hypotheses, not facts. Each potential cause must be verified with data or experimentation before implementing fixes. A cause appearing on the diagram doesn’t mean it actually contributes to the problem.

​
Applications

Manufacturing Quality Control

Identify why products fail to meet specifications. Common categories include equipment calibration, raw material quality, operator training, and environmental conditions.

Healthcare Patient Safety

Analyze adverse events by examining factors like communication protocols, medication processes, equipment reliability, and staffing levels.

Software Development

Map causes of bugs or system failures to categories like code quality, testing coverage, deployment processes, infrastructure, and requirements clarity.

Project Retrospectives

Understand why projects missed deadlines or budgets by examining planning, resources, communication, scope changes, and external dependencies.

​
Case Study

In the early 2000s, a major automotive manufacturer faced escalating warranty claims related to sudden engine failure in one of their popular models. Initial analysis pointed to obvious suspects — bad fuel, poor maintenance by owners — but warranty costs continued rising. The quality team conducted a Fishbone Diagram session with engineers, assembly line workers, and suppliers. Under the “Machine” category, they discovered that a specific CNC machining center had worn bearings that caused minute variations in cylinder wall thickness. Under “Method,” they found that the quality control sampling rate had been reduced during a cost-cutting initiative. Under “Material,” a new supplier’s metal alloy had slightly different thermal expansion properties. The root cause turned out to be a combination: the machining variation + reduced sampling + the new material created a resonance condition under high-temperature operation that didn’t appear in testing. The fix required addressing all three factors simultaneously. Without the structured framework of the Fishbone Diagram, the team might have addressed only one factor and seen the problem recur.

​
Boundaries and Failure Modes

Without prioritization, fishbone diagrams can grow unwieldy. Teams spend hours listing causes but never get to solving them. Always include a validation and prioritization phase.
The 6Ms framework is designed for manufacturing but can constrain thinking in other domains. A software team using rigid categories might miss causes related to organizational culture or market dynamics.
Without a skilled facilitator, the diagram can become dominated by senior voices or devolve into blame assignment. Ishikawa designed the tool to be non-blame-oriented, but groups often need help staying that way.

​
Common Misconceptions

The five whys is a drilling-down technique; the Fishbone is a brainstorming and organizing technique. Best practice: use the Fishbone to generate hypotheses, then use five whys to find root causes within each branch.
The diagram is a thinking tool, not a solution. Many teams create beautiful diagrams but never validate causes or implement fixes. The real work begins after the diagram is complete.
While developed for quality control, the tool applies to any complex problem. Any effect with multiple potential causes — from declining sales to employee turnover — can benefit from Fishbone analysis.
The Fishbone Diagram connects to broader problem-solving frameworks and specific techniques.

Root Cause Analysis

Root Cause Analysis is the broader discipline that the Fishbone Diagram serves. RCA provides the philosophy; the diagram provides one method.

Five Whys

Five Whys is a technique often used in conjunction with Fishbone to drill down from listed causes to their fundamental roots.

PDCA Cycle

PDCA Cycle — Plan, Do, Check, Act — provides the iterative improvement framework within which Fishbone analysis typically operates.

​
One-Line Takeaway

The Fishbone Diagram doesn’t find answers — it structures the right questions. Use it to generate hypotheses, then validate with evidence before acting.