Lean teams use it to brainstorm causes widely before narrowing down. It keeps a group from fixating on the first idea and shows where to collect data.
Where it comes from
The diagram was developed by Japanese quality expert Kaoru Ishikawa, which is why it is also called an Ishikawa diagram. It is often listed among the basic tools of quality control.
At a glance
A fishbone for uneven paint thickness
Swipe sideways to see the whole diagram.
How to apply Fishbone Diagram
- 1
Write the problem at the head
State the effect clearly and specifically. Draw a horizontal spine leading to it.
- 2
Choose cause categories
Common sets are the 6Ms: people, machine, method, material, measurement and environment. Office teams often use process, policy, people and systems.
- 3
Brainstorm causes
Have the team add possible causes under each category. Ask why to add sub-causes as smaller bones.
- 4
Select likely causes
Mark the causes the team thinks matter most. Base the choice on evidence where you have it.
- 5
Verify with data
Test the selected causes at the gemba or with data. Drill into confirmed ones with 5 Whys.
Worked example
A coating line sees uneven paint thickness. The team lists causes under method, machine, material and environment, including spray nozzle wear and humidity swings. Data shows thickness tracks nozzle age, so nozzle replacement moves into the PM plan.
Common mistakes
- Treating every cause on the diagram as proven instead of verifying the likely ones.
- Building the diagram without the people who do the work.
- Writing vague causes such as "training" that cannot be tested or acted on.
When Fishbone Diagram is not the right tool
A fishbone diagram lists possible causes. It does not prove any of them. Use data or tests to confirm the likely causes before acting.
For a simple problem with one clear chain of cause, five whys is quicker.
Choosing the categories
Manufacturing teams often use six categories: people, machine, method, material, measurement and environment. Older versions call people "man" and environment "mother nature".
Service and office teams often use process, policy, people and systems instead. Pick categories that help the team think, then add or drop as needed.
Narrowing the causes
Once the diagram is full, the team votes on the most likely causes. Data, such as a Pareto chart of defect types, then checks the vote.
Kaoru Ishikawa described the diagram, and it is often called an Ishikawa diagram after him.