Fishbone Diagrams: Mapping the Causes of a Problem

A fishbone diagram is a simple visual tool for mapping all the possible causes of a problem before you decide which one to chase. You write the problem in a box on the right, draw a horizontal spine leading to it, and branch off the main categories of cause — people, method, machine, material, measurement and environment — adding specific causes as smaller bones. The finished picture resembles a fish skeleton, which is where the name comes from. Its purpose, and the reason I reach for it so often in investigations, is to stop a team fixating on the first cause that springs to mind and instead lay out the whole landscape of possibilities.

This guide explains what a fishbone diagram is, how to build one with a team, and how to turn a crowded diagram into a short list of causes actually worth investigating.

Why map causes before chasing them

The instinct when a problem appears is to grab the most obvious explanation and act. Sometimes that is right; often it is not, and you have spent effort fixing something that was never the cause. A fishbone diagram slows that instinct just long enough to ask a better question: what are all the things that could be causing this?

Laying the possibilities out visually does two useful things. It gets the whole team's knowledge onto one surface, so the quiet operator who knows exactly what changed last week gets heard — and in my experience that operator is very often holding the answer. And it exposes gaps: categories with no causes listed are a prompt to go and look. The diagram is also known as an Ishikawa or cause-and-effect diagram.

The categories of cause

Most fishbone sessions use a standard set of category bones as prompts. In manufacturing the common six are:

• People — skills, training, staffing, communication.
• Method — the process, procedures and the way work is done.
• Machine — equipment, tooling, maintenance and settings.
• Material — raw materials, components and consumables.
• Measurement — gauges, inspection and how data is collected.
• Environment — temperature, humidity, cleanliness, layout.

These are prompts, not a straitjacket. A service or office problem might swap machine and material for categories like systems, policies or suppliers. The point is to have a handful of headings that jog the team's memory so no obvious area is quietly overlooked.

How to run a fishbone session

1. Agree the problem statement

Write the problem in the head of the fish, specifically. "Rework on assembly line 2 rising over the past month" is workable; "quality issues" is too vague to map. Everyone should agree this is the problem before anyone brainstorms causes — I have seen whole sessions wasted because two people were quietly mapping two different problems.

2. Draw the spine and the category bones

Sketch the horizontal spine into the problem box and add a diagonal bone for each category. A whiteboard or a large sheet works best because the whole team needs to see it and add to it.

3. Brainstorm causes onto the bones

For each category, ask "what here could cause this problem?" and add every idea as a smaller bone, without debating it yet. You can push deeper by asking why a cause happens and adding sub-bones — effectively running a mini 5 Whys along each branch. Keep it generative; judgement comes later. The one thing I insist on is that people are honest about their own area rather than pointing exclusively at the next department along.

4. Cluster and challenge

Once ideas dry up, step back. Look for causes that appear under several categories, which often points to something significant. Challenge vague entries and make them specific enough to test.

5. Prioritise the few worth investigating

A full fishbone can hold dozens of causes; you cannot chase them all. Mark the handful the team judges most likely and most impactful, ideally guided by any data you have. Those become the candidates you verify with evidence.

From cluttered board to real action

A fishbone diagram identifies possible causes; it does not prove any of them. That is the step teams most often skip, and it is the one that matters most to me as an auditor. Having narrowed to a few likely causes, you still have to test them — switch the suspected cause off and see whether the problem goes away, or check the data to confirm the link. The diagram tells you where to look; evidence tells you what is true.

Suppose a team mapping a recurring paint defect fills the machine and material bones heavily and finds the environment bone almost empty. That emptiness is a clue: nobody has checked whether humidity or temperature swings are involved. Going to measure it, hypothetically, might reveal the real culprit that the busy bones had distracted everyone from. Turning that observation into a checked cause is what converts a good diagram into a solved problem.

Frequently asked questions

What is the difference between a fishbone diagram and the 5 Whys?

A fishbone diagram maps many possible causes across categories at once, giving you breadth; the 5 Whys drills down a single chain of cause and effect, giving you depth. They work best together — use the fishbone to find the likely branches, then the 5 Whys to dig into the most promising one. Neither proves a cause on its own; both need evidence.

How many people should be in a fishbone session?

A small cross-functional group of roughly four to eight works well — enough to bring different perspectives without becoming unwieldy. Crucially, include people who actually do the work, because they hold the detailed knowledge of what really happens. One person facilitating keeps the session moving and the diagram legible.

Does a fishbone diagram prove the root cause?

No. It surfaces and organises possible causes, but every candidate still has to be verified with evidence before you act on it. Treating a well-populated bone as proof is a common mistake. The diagram's job is to make sure you consider the full picture, not to hand you the answer.

Where to go next

A fishbone diagram is one of the quickest ways to get a team's collective knowledge onto the table and stop premature fixes. If you would like a structured way to score your operation and see where your problems are most likely to cluster, ProgressXL is coming soon. To talk through a stubborn problem you would like mapped properly, get in touch.