A fishbone diagram, also called an Ishikawa diagram or cause-and-effect diagram, maps every plausible cause of a problem onto branches that feed into a central spine pointing at the problem itself. The shape looks roughly like a fish skeleton, which is where the name comes from. It was developed by Kaoru Ishikawa for quality control in manufacturing and works well any time a team suspects a problem has multiple, unrelated contributing causes rather than one linear chain.
What changed in 2026
- Digital fishbone templates replaced most whiteboard sessions. Remote and hybrid teams now build the diagram in shared visual tools during a video call rather than requiring everyone in one room with a physical whiteboard.
- AI-assisted brainstorming pre-populates branches for review. Teams increasingly generate a first-draft set of possible causes per category from historical incident data, then use the live session to correct and prioritize rather than start from a blank diagram.
- Fishbone diagrams got paired with a scoring step more consistently. Instead of ending the session once the diagram is full, more teams now vote or score the branches immediately afterward to decide which one gets investigated first.
The standard categories
The classic version uses six categories, sometimes called the 6 Ms, though teams commonly adapt them to fit their domain:
| Category |
Typical questions |
| People |
Was training, staffing, or communication a factor |
| Process |
Was the procedure unclear, skipped, or wrong |
| Equipment |
Did a tool, machine, or system malfunction or lack capability |
| Materials |
Were inputs defective, wrong, or inconsistent |
| Environment |
Did external conditions, physical, market, or timing, play a role |
| Management |
Were priorities, resources, or oversight a factor |
Software and service teams often swap in categories like Code, Infrastructure, Third-party, and Process instead of the original manufacturing-oriented six. The specific categories matter less than having several distinct ones, so the brainstorm does not collapse into a single line of thinking.
Building one, step by step
- Write the problem at the head of the fish, stated specifically and neutrally, not as an accusation.
- Draw the spine and label the main category branches, adapted to the domain.
- Brainstorm causes under each category, without judging or filtering yet, since the point of this stage is coverage, not accuracy.
- Ask why behind each cause listed, one or two levels deep, the way a short five whys chain would, to move past surface-level entries.
- Review the full diagram and mark which branches look most likely, based on available evidence rather than which one is loudest in the room.
- Pick the top branch or two to investigate first, with a plan for how to confirm or rule each one out.
Fishbone diagram vs five whys
The two techniques solve different shaped problems. Five whys follows one line of reasoning deeper; a fishbone diagram spreads wide across several possible lines before choosing which one to go deeper on. A practical pattern many teams use: build the fishbone diagram first to make sure no obvious category of cause gets missed, then run a five whys chain on the one or two branches that look most promising, rather than picking either technique exclusively.
Common mistakes
The most frequent mistake is stopping at the brainstorm and never following up — a fishbone diagram full of plausible causes that nobody actually confirms or rules out is a documented list of guesses, not a finished analysis. The second is skewing the categories toward whichever one the loudest person in the room already suspects, which quietly turns a supposedly open brainstorm into a foregone conclusion. Keeping categories balanced, and asking directly whether each one has been genuinely considered, helps counter both.
FAQ
Is a fishbone diagram the same as root cause analysis?
No. A fishbone diagram is one technique used during a root cause analysis, specifically the brainstorming and categorization stage, not the whole process from problem definition through verified fix.
Do all six categories need entries?
No. Some categories will legitimately have few or no plausible causes for a given problem. Forcing entries into every category just to fill the diagram adds noise.
Can a fishbone diagram be used for a positive goal, not just a problem?
Yes, some teams adapt it to map contributing factors toward a desired outcome rather than a failure, though the classic use case remains diagnosing problems.
How long should a fishbone diagram session take?
Usually 30 to 60 minutes for the brainstorming stage. Longer sessions tend to produce diminishing returns and are better split into a session plus follow-up investigation.
Where to go next