What the categories are for
The branches exist to stop a cause-hunt from collapsing into one comfortable explanation. Left unstructured, a room full of people will generate eight variations on the same idea and call it a thorough analysis. Categories force you to ask the question again from a different angle — was there anything about the equipment? about how we measure this? about the environment it happened in? — and that is where the causes nobody had considered tend to surface.
The default six come from manufacturing and are usually written as the 6 Ms: People (originally Manpower), Method, Machine, Material, Measurement and Environment (originally Mother Nature). They are a starting prompt, not a rule. Service teams often prefer People, Process, Policy, Place, Product and Promotion; a software team might use Code, Data, Infrastructure, Process, People and Third parties. Rename them here to whatever makes your team think harder.
How to run one that actually finds something
Start by writing the problem as an observed fact with as much specificity as you can stand: not 'quality issues' but 'three of the last twelve orders shipped with the wrong label'. A vague head produces a vague diagram, because every branch becomes plausible.
Then fill the branches without filtering. The point of the first pass is coverage, not accuracy — a cause you dismiss in ten seconds cost you ten seconds, whereas a cause nobody wrote down costs you the whole exercise. Ask for causes from the people who do the work, not only the people who own the process; the two groups reliably produce different diagrams.
Once the diagram is full, switch modes and get sceptical. Which of these can you actually check against evidence? Which would explain the specific pattern you observed, including the times the problem did not happen? Circle the two or three worth investigating and go and look. A fishbone that ends in a decision about what to measure next has done its job; one that ends in a photograph of a whiteboard has not.
Common mistakes
The most frequent one is writing symptoms as causes. 'Orders are late' on a branch of a diagram whose head is 'customers are unhappy' tells you nothing you did not already know. Push each branch until it names something that could be changed.
The second is treating the diagram as the analysis. A fishbone generates hypotheses; it does not test them, and the branch with the most sub-causes is not automatically the culprit — it is often just the category the loudest person in the room knows best. The third is stopping at one level. Real causal chains have depth, and a branch that reads 'training' is worth pushing on until it reads something like 'new starters shadow for one shift, and label changes are covered on day three'.
Finally, be careful about blame. As soon as a People branch turns into a list of names, the diagram stops collecting honest input. Ishikawa's own framing was about systems that let errors through, and keeping the branches at that level is what keeps the room talking.
Fishbone or Five Whys?
They answer different questions and work well in sequence. A fishbone is wide: it asks what could be causing this, across every category, and is at its best when the cause is genuinely unknown and several teams have a theory. The Five Whys is deep: it takes one thread and follows it down to something structural, and is at its best when you already know roughly where the trouble is.
The common pattern is to build the fishbone first, pick the branch the evidence favours, and then run a Five Whys down that branch. Both tools are here and both save to the same canvas, so the analysis stays together.