Fishbone Diagram

A logistics manager has noticed that deliveries run late almost every Friday, and only on Fridays. The team's instinct is to jump straight to solutions (add a driver, extend the loading window) before anyone has agreed, in one sentence, what the actual problem is. A fishbone diagram forces that sentence to exist before any cause gets written down.

A fishbone diagram, also called an Ishikawa diagram after its creator Kaoru Ishikawa, or a cause-and-effect diagram, maps possible causes of a specific problem against six standard categories: Man (people), Method, Machine, Material, Measurement, and Environment. The problem sits at the head of the fish, with each category forming a bone running off the spine. It is a structure for generating and sorting causes, not for solving the problem itself. Ishikawa developed the diagram in the 1960s as part of Japanese quality-control practice, and its lasting appeal is that six fixed categories force a group to look in places it would otherwise skip: a team asked to just "list causes" will usually stop after the two or three that come to mind fastest.

• Use it when a specific, recurring problem needs its possible causes mapped before anyone jumps to a fix.
• Use it in a group setting, since the six categories help a team surface causes that any one person would miss alone.
• Use it before a root-cause investigation that will lead into further data collection, such as a Pareto analysis of the causes found.
• Do not use it for vague or badly defined problems: "things are slow" is not specific enough to generate useful causes.
• Do not treat the finished diagram as the answer; it is a list of candidate causes that still need testing against evidence.

One-page model visual

The one-page visual

Use this visual as a quick reference. The card in the deck adds the questions and the steps to run the model in your next meeting.

See all 50 models as cards →

The mistake happens before the diagram is even drawn: teams skip straight to listing causes under a vague problem statement, such as "delivery problems", instead of writing a precise one, such as "twenty-three percent of Friday deliveries arrive more than two hours late". A vague problem statement produces a vague, unfocused diagram, because every category can generate a plausible-sounding cause for almost anything.

The second mistake is filling in categories unevenly. Most groups generate plenty under Method and Machine, because those causes are visible and easy to name, and go quiet under Measurement or Environment, which require more thought. A fishbone diagram with one empty bone is usually a sign the group stopped too soon, not that the category has nothing to offer.

A related habit is letting the loudest voice in the room fill most of the bones. Someone with strong opinions about Machine causes will happily name six of them, while a quieter colleague with a genuine insight about Measurement (how the two-hour threshold is even recorded) never gets asked. Going category by category, and asking each person in the room to contribute to each one, is what keeps the diagram from becoming one person's theory with five decorative headings around it.

Illustrative example: a fictional company, not a customer case.

Problem statement: "Friday deliveries in the North zone run more than two hours late, four weeks running." Under Method, the team notes that Friday route planning happens the night before, alongside end-of-week admin, rather than with the same care as other days. Under Machine, one delivery van has needed unscheduled maintenance twice in the past month, always removed from the Friday rotation without replacement.

Under Man, worth raising even if it is uncomfortable: the same two drivers cover the North zone every Friday, and both happen to also close out the week's paperwork before their final run, a task that does not exist on other days. That is a third candidate cause, sitting in a different category from the first two, and none of the three yet has enough evidence behind it to be called the answer.

Three bones already point to three different, testable causes rather than one vague explanation of "Fridays are busy", which is exactly the point of working category by category instead of guessing. The card takes you through the remaining steps to a decision.

• Front: what a fishbone diagram is for and why the problem statement has to come before the bones.
• Back: the numbered steps to apply the model, plus a short worked example of its own. The company in this guide is a separate illustration, not the example printed on the card.
• Digital: a Miro board with the fishbone template ready for a team workshop, with a video tutorial.

• Pareto Analysis is the natural next step, ranking the causes a fishbone diagram surfaces by actual impact.
• DMAIC Model gives the fishbone diagram a home within a wider structured improvement process.
• Total Quality Management provides the broader quality framework this tool originally comes from.

BizDecks is the cheat sheet for business decisions: 50 models, one card each. See the toolkits.