The Fishbone Diagram
A structured way to map the causes of a recurring problem — only as honest as the conversation in the room.
Most teams hit the same problem twice. Then four times. By the seventh time it returns in a slightly different form, someone suggests doing a proper root cause analysis. A meeting is scheduled. A whiteboard is found. Someone draws the spine of a fish.
Two hours later there is a diagram. It looks thorough. Causes have been grouped, written down, discussed. The team leaves feeling like progress was made.
Six months later the same problem is back.
The fishbone diagram is the alternative to guessing. The question is why, used carefully and run by capable people, it so often produces the same outcome as guessing.
What it is
The fishbone diagram — also called the Ishikawa diagram or cause-and-effect diagram — is a visual tool for mapping the possible causes of a problem. The problem goes at the “head” of the fish, and branches off the spine (the “bones”) group possible causes by category. The standard categories are people, process, equipment, materials, environment, and method, though teams adapt them to fit the work.
It was developed by Japanese quality engineer Kaoru Ishikawa in the 1960s and became a cornerstone of the quality movement that W. Edwards Deming championed in Japan and later in the United States and Australia. It sits alongside the PDSA cycle, the Pareto chart, and the run chart as one of the foundational tools of continuous improvement.
The tool itself is sound. The four decades of practice behind it are sound. What determines whether it works is something else entirely.
Why teams reach for it
When the same problem keeps coming back — a quality issue, a delivery failure, a complaint pattern — the fishbone diagram feels like the right response. It is structured. It is visual. It gets the team in a room together. It signals that this time, you are going to find the real cause.
That instinct is correct. Structured root cause analysis is exactly what chronic problems need. The fishbone is a good answer to the question “how do we move past guessing?”
It is not always a good answer to the question “how do we surface what people actually know?” — and that is the question most chronic problems are actually asking.
Where it goes wrong
Here is what typically happens in the room.
The team leader, or a senior manager, runs the session. They write on the whiteboard. They decide which causes go on the diagram and which do not. The people with the most authority do most of the talking. The people closest to the problem — the ones dealing with customers, handling the process, absorbing the complaints — say what seems safe, or say nothing at all.
They have been conditioned not to raise things they do not believe will be fixed.
So the fishbone gets filled in. It looks thorough. But what it actually maps is the leader’s understanding of the problem. Not the organisation’s.
This is not a failure of the tool. It is a failure of the conditions around it. When people have learned through experience that speaking up leads nowhere — that their observations get dismissed, minimised, or politely ignored — they stop offering them. The knowledge stays locked inside the people who hold it. The diagram reflects what was safe to say, not what is true.
Argyris called this dynamic defensive routines: the learned behaviour of protecting yourself and others from the discomfort of honest information. Defensive routines are rational. They make complete sense given the environment that created them. But they mean every root cause session you run is only as good as the psychological safety in the room.
What the tool actually requires
The fishbone diagram is a conversation tool as much as it is an analytical tool. It only works when the people who know the most feel safe enough to say it.
That means the session cannot be led by the most senior person in the room doing the writing. It means the people facing external customers — the ones who hear complaints in real time, who see where the process actually breaks — need to be not just present but genuinely heard.
It means the leader’s job in that room is not to decide what goes on the diagram. It is to ask better questions and get out of the way.
This is the distinction between Model I and Model II communication. In Model I, the leader controls the agenda, filters the information, and determines what counts as a valid cause. In Model II, the leader creates the conditions for valid information to surface — even when that information is uncomfortable, even when it points to a management decision as the cause.
The fishbone done well is an act of Model II leadership. It requires the leader to genuinely not know the answer before the session starts.
A small example
A small business has been losing customers to a quiet defect that keeps slipping through the final check. The operations manager runs two fishbone sessions over six weeks. Both produce thorough-looking diagrams. Both identify plausible causes — supplier variation, training gaps, equipment wear. The team agrees on actions. Nothing changes.
The third session is different. The operations manager is not in the room. The customer service lead facilitates. Within twenty minutes, two of the people who handle customer calls say something they have never said in a meeting before: the defect is not random. It correlates with one specific shift, run by one specific supervisor, who has been openly skipping a quality check to hit a throughput target the operations manager set six months earlier.
The cause was not on the previous two diagrams because the person who set the target was the one running the session. The information existed. The conditions for it to surface did not.
The fishbone diagram is good at organising what is said in the room. It cannot reach what is not.
Where this fits
The fishbone diagram is one of the standard tools of continuous improvement. It pairs naturally with the PDSA cycle — the fishbone identifies a candidate cause, the PDSA cycle tests whether changing it actually improves the result.
It is also one of the clearest examples of why tools alone do not produce change. The gap between a well-drawn diagram and an actual improvement is almost always a gap in honest conversation, not a gap in analysis. That is the gap between single-loop and double-loop learning: single-loop fixes the error; double-loop asks why the error keeps happening, and whether the assumptions that created it need to change.
Used well, the fishbone is a gateway to double-loop learning. Used poorly, it is a single-loop ritual — thorough-looking, regularly repeated, and ultimately safe.
What is a fishbone diagram used for?
A fishbone diagram is used to map the possible causes of a recurring problem. The problem goes at the “head” of the fish, and branches off it (the “bones”) group possible causes by category — typically people, process, equipment, materials, environment, and method. The point of the tool is not to list causes for the sake of it, but to push past surface symptoms toward causes that can actually be acted on.
Why do fishbone diagrams often fail to solve the problem?
The most common reason fishbone diagrams fail is not the tool itself — it’s the conversation around it. When the most senior person in the room runs the session, the diagram tends to reflect their understanding of the problem rather than the organisation’s. The people closest to the work often stay quiet, especially if they have learned that speaking up leads nowhere. The result is a thorough-looking diagram that misses the actual cause.
Who should run a fishbone diagram session?
Ideally, the session should be facilitated by someone other than the most senior person in the room. The leader’s presence as a writer or decision-maker tends to shape what gets said and what doesn’t. A neutral facilitator — and the explicit inclusion of people who deal with customers and frontline processes — usually produces a far more honest diagnosis than a manager-led session.
What is the difference between a fishbone diagram and the 5 Whys?
Both are root cause analysis tools, but they work differently. The fishbone diagram maps causes laterally — across multiple categories at once — to give a broad view of contributing factors. The 5 Whys works vertically, asking “why” repeatedly to drill down from a symptom to a root cause. The two tools work well together: the fishbone identifies candidate causes, and the 5 Whys deepens the most promising ones.
How does a fishbone diagram relate to the PDSA cycle?
The fishbone diagram is typically used in the “Plan” stage of the PDSA cycle, where you are identifying the problem and forming a theory about its causes before testing a change. A fishbone helps generate the hypothesis. The PDSA cycle then tests it. Without a sound diagnosis, the PDSA cycle improves the wrong thing — which is why the quality of the conversation around the fishbone matters as much as the diagram itself.
Sources
The fishbone diagram was developed by Kaoru Ishikawa in the 1960s and codified in his 1985 book What is Total Quality Control? The Japanese Way. The dynamics of defensive routines and Model I / Model II communication were developed by Chris Argyris across his work, most accessibly in Overcoming Organizational Defenses (1990) and Reasons and Rationalizations (2004). The continuous improvement tradition that frames the tool is the one W. Edwards Deming taught from Out of the Crisis (1982) onwards.