The Ishikawa Fishbone problem solving tool (also known as the Cause and Effect diagram) was developed by Kaoru Ishikawa during the 1960’s in Japan. The tool is used in lean production, specifically for getting to the bottom of problems, in a process known as root cause analysis.
The diagram is shaped as a fish skeleton, with the problem (or effect) at the head, and the potential causes being brainstormed along the “fishbones”.
One of the key features of Ishikawa is cross-functional team collaboration.
It enables you to categorise and visualise the different potential causes of a problem to identify its root causes.
Start with a problem statement/effect, at the head. The bones represent categories of potential causes that branch out. Major categories often include Man (People), Methods, Machines, Materials, Measurements, and Environment. Also known as the 5Ms method of lean production.
By identifying underlying issues, teams can develop targeted strategies to address them, rather than simply treating symptoms, leading to more effective problem-solving and process improvement.
Process
Step 1: Identity the problem – clearly state the problem or effect you’re analysing, and write this at the head of the fish. The problem needs to be as specific as possible.
Step 2: draw the backbone – draw a straight line from the left side of the page (the tail) towards the problem statement on the right, this is the backbone of the fish.
Step 3: Determine categories of causes – Decide on the major categories of causes that may contribute to the problem. These are known as the 4Ms, including Man, Machine, Materials, and Measurement, with Environment also added on. These categories form the ribs of the fish. This step is crucial as it structures the brainstorming process and helps in identifying potential causes of the problem. Here are steps for deciding on categories:
- Understand the problem context – before choosing categories, have a clear understanding of the problem you’re analysing.
- Customise categories for your needs – this depends on your specific problem or industry. Service industries may require more policies and procedures, whilst software development may require software and hardware.
- Engage the team – involve people from different roles related to the problem – team brainstorming may uncover aspects not considered and ensure relevant categories are included.
- Review historical data – look at past incidents or problems similar to the one you’re analysing. Historical data can provide insights into which categories were relevant in those cases.
- Be open to revision of categories if necessary.
Step 4: Draw the cause branches – Draw lines outward from the backbone to create branches for each category, resembling fish bones.
Step 5: brainstorm sub-causes: brainstorm potential causes contributing to the problem by getting teams to participate for comprehensive analysis. Add these as smaller branches stemming from each category branch. Encourage team participation for a comprehensive analysis.
Step 6: Analyse and prioritise causes – Once all potential causes have been laid out, discuss and analyse them to identify the most likely root causes. Tools like the 5 Why analysis can be helpful in digging deeper into each cause.
Step 7: Take action – After identifying the root causes, next step is to develop action plans to address these issues to prevent them from occurring again.
Limitations of Fishbone Diagram
- Complexity with large data sets – when dealing with a complex problem with many potential causes, the diagram can become cluttered and overwhelming
- Lacks quantitative analysis – a qualitative tool which does not inherently incorporate quantitative analysis. Use pareto analysis to prioritise causes by impact or likelihood.
- Doesn’t suggest solutions – focuses on identifying causes, not suggesting solutions or addressing the root causes.
- Potential over-simplification – risk of oversimplifying the causes of complex problems, especially if brain storming is rushed, or not detailed enough.
- Limitations in team knowledge – effectiveness is limited by knowledge and experience of team members involved. If key areas of expertise are missing from the team, important causes may be overlooked.
Here’s a clean, blog-friendly example you can drop straight in. I’ll keep it practical and non-academic.
Example: Using an Ishikawa (Fishbone) Diagram to Diagnose Late Project Delivery
Problem (Effect):
A software development project is consistently delivered 2–3 weeks late.
We place this problem at the “head” of the fish and explore possible root causes along the main bones. A common Ishikawa structure uses the 6Ms: Manpower, Methods, Machines, Materials, Measurement, and Environment.
1. Manpower (People)
- Developers are split across too many projects
- High reliance on junior staff without adequate supervision
- Key technical lead frequently unavailable for decisions
2. Methods (Processes)
- Requirements are not clearly defined at project start
- Scope changes are accepted without formal change control
3. Machines (Tools & Technology)
- Outdated project management software
- Slow build and deployment pipelines
- Poor integration between development and testing tools
4. Materials (Inputs)
- Incomplete or late input from business stakeholders
- Poor-quality technical documentation
- Delays in receiving third-party APIs or dependencies
5. Measurement (Metrics & Tracking)
- Progress tracked by hours worked rather than deliverables
- No early-warning KPIs for schedule slippage
- Inaccurate initial time estimates
6. Environment (External Factors)
- Remote teams across multiple time zones
- Frequent production emergencies diverting attention
- Tight deadlines driven by commercial pressure
Insight from the Diagram
By mapping all potential causes visually, the team realises that late delivery is not primarily a technical issue, but a combination of:
- Poor upfront requirements,
- Weak change control,
- Resource over-allocation.
This allows management to focus on process fixes rather than blaming individuals or adding more developers.
Why the Ishikawa Diagram Works
The Ishikawa diagram forces structured thinking, prevents premature conclusions, and encourages teams to look beyond the obvious symptoms to the underlying causes.