Method 03 · Widen
Ishikawa: the fishbone diagram
A fishbone diagram collects every cause that could have produced a problem, sorted by category, so that you do not settle for the first explanation that comes to mind.
Kaoru Ishikawa first used the diagram in 1943, to explain to engineers at Kawasaki Steel Works how a tangle of factory factors hung together. It only became widely known in the 1960s, when he set it alongside the seven basic tools of quality control. The shape is familiar: a horizontal spine pointing at the problem, with diagonal bones for the main categories and the individual causes hanging off them.
More important than the shape is what the method is for. Ishikawa widens: the quality literature calls this generating hypotheses. It does not produce an answer but a stock of possible causes, arranged so you can see which angle you skipped. Anyone who reads the diagram as a conclusion is using it wrongly.
When to use it, and when not
| A good fit when | A poor fit when |
|---|---|
| You have no direction yet and want to avoid choosing too early. | You already know the cause and are looking for agreement. Then it is theatre. |
| Several disciplines are involved and you want their knowledge on the table. | You are doing it alone. A one-person fishbone is a list with a drawing around it. |
| The problem is complex enough that a single chain will not capture it. | The chain of cause and effect is short and clear. Go straight to asking why. |
| You want to share the result; the picture reads more easily than a list. | You have no time to verify afterwards. Untested causes are more dangerous than no causes. |
What you need
- Three to eight people from different corners. The value is in the bone where you personally can think of nothing and your colleague can think of three things.
- A sharply stated problem. It goes in the head of the fish and steers everything that follows.
- Forty to sixty minutes. Twenty to collect, ten to sort, ten to vote, and the rest to agree what you will go and check.
How to run it
-
Put the problem in the head
An observable deviation, not a suspicion. Everything you collect afterwards has to bear on it.
-
Choose your categories
The classic 6M (people, machine, method, material, measurement, environment) comes from manufacturing. For IT and services, people, process, technology, data, environment and supplier works better. Pick what fits; the categories are memory aids, not law.
-
Collect broadly and without judging
Anything that could have caused the problem goes on. Arguing about likelihood slows the collecting down, and it will come soon enough by itself.
-
Ask once more for each cause
“And what causes that?” produces the sub-causes. A bone with only headline causes stays at the surface.
-
Vote (a common follow-up step)
A full fishbone has thirty to forty causes on it. You cannot investigate them all. Everyone gets roughly one vote per three causes and hands them out; that forces a choice.
Strictly speaking, voting is not part of Ishikawa itself. It comes from the practice of quality circles, kaizen and lean workshops, where it became standard enough to feel native. We have built it into the worksheet; skip it happily if you are working with two people.
-
Test the top, do not believe it
The causes with the most votes are the group’s best-supported suspicions. That is a different thing from the truth. Go and measure, or run an Is/Is-not on them, or keep asking with 5 Whys.
A worked example
Deviation: since Tuesday’s release, the customer dashboard takes more than ten seconds to load, against two seconds before.
| Category | Causes collected |
|---|---|
| People | The release went out without anyone who knows the dashboard looking at it |
| Process | There is no performance test in the pipeline; the staging environment holds a tenth of the data |
| Technology | A new charting library; every tile now makes its own API call instead of one shared call |
| Data | The events table has grown from two to forty million rows this year |
| Environment | The caching layer has been switched off since last week’s maintenance |
| Supplier | The external exchange-rate API has been slower since their own change |
Eighteen causes in total, so six votes each. The top after voting: one API call per tile, the caching layer being off, and the grown table.
Notice what happens to the first line. “Nobody looked at it” belongs on the fishbone, but not as blame: it is a statement about how the work is organised. Phrased that way it is usable, and in 5 Whys it will produce a countermeasure rather than a conversation.
Common mistakes
- Reading the diagram as a conclusion. The fullest bone is the one there was most to say about, not the one the cause sits in.
- Adopting the categories blindly. 6M on an IT problem gives you an empty “material” bone and an overflowing “people” bone, and that steers the analysis the wrong way.
- Using the people bone as a blame bone. Write down what made the work hard, not who got it wrong.
- Collecting everything and then choosing nothing. Without a voting round, everyone leaves with a different idea of what happens next.
- Filling it in on your own. Then you collect exactly the causes you already knew, in a form that suggests it is more than that.
Combining it with the other methods
- 5 Whys comes after this. The voted top goes deep; on the worksheet you can send a cause straight across.
- Is / Is-not is the test. Does this cause also explain why the problem stayed away where you expected it? If not, you can drop it without further investigation.
- Pareto comes before it when you have many separate incidents. Run the fishbone on the category that does the most damage.
Frequently asked questions
How many causes are enough?
Twenty to forty for a problem of any size. Under ten and you were probably judging while you were supposed to be collecting.
Do I have to fill every bone?
No. An empty bone is information: it says nobody could think of anything in that corner. If that keeps happening on a category that genuinely matters, you are probably missing someone in the room.
What if one category swallows everything?
Then that category is probably drawn too widely, or the problem is already one of them. Split it, or choose a different set.
Can I do this alone?
You can, and it beats nothing, but know what you end up with: your own knowledge, neatly sorted. Have someone else add to it afterwards.
What do I do with the causes that got no votes?
Leave them. They cost nothing, and when the first hypothesis falls over you do not start again but take the next one off the list.