Say “root cause analysis” in any cocktail party and you’ll hear back “Ishikawa diagram.” Ok, that might work only with cocktail parties that cater to engineers, but an Ishikawa diagram is the de-facto tool of many to diagnose a problem. So let’s look how it differs from our de-facto diagnosis tool: the why issue tree / issue map.
Ishikawa diagrams and issue trees are alike
Ishikawa diagrams have many names: they are also called cause-and-effect diagrams, fishbone diagrams, or even Fishikawa diagrams. Having the problem at the right of the diagram—on the fish head—they spell out all the possible causes on the left, sorting them out by types. Each type branches out into smaller types, thereby somewhat mimicking the bone structure of a fish.
Kaoru Ishikawa developed fishbone diagrams as one of the seven “tools of quality”: -1- the histogram, -2- the scatter diagram, -3- the Pareto chart, -4- the Ishikawa diagram, -5- the statistical process chart, -6- the flowchart, and -7- the checksheet (source (for a book); another source for a free online resource).
When talking about Ishikawa diagrams, people usually propose pre-defined sets of causes, such as the 4 Ms + E: methods, machine (equipment), manpower (people), materials, and environment (source). This might be useful in specific environments, but a strong Ishikawa diagram has the same characteristics as a strong issue tree; it…
- Answers a why question.
- Progresses from the key question to the analysis as it moves to the
- Is mutually exclusive and collectively exhaustive (MECE).
- Uses an insightful breakdown.
As with issue trees, applying the first two rules to an Ishikawa diagram is pretty straight forward. It’s applying third and the fourth that has all the fun. So, if you decide to use an Ishikawa diagram, don’t blindly follow the 4 Ms + E approach; instead ensure that you build your diagram on an appropriate set of dimensions, as set that’s both MECE and insightful. You can either develop the set specifically for that problem or use one of the standard frameworks.
Ishikawa diagrams and issue trees are different
Ishikawa diagrams and issue trees are different in three ways:
They flow in opposite directions. Ishikawa diagrams go to the original question as you read them from left to right. Not a big deal but in Western countries we’re used to flowing when moving from right to left, so you might feel more comfortable with the layout of an issue tree.
They don’t require the same space. Here’s another point that might sound trivial but can matter: issue trees tend to be extremely space hungry: ten pages is pretty common to capture an entire tree. By nudging causes closer to one another, an Ishikawa diagram makes it easier to see the entire problem in a compact way. This is useful when sharing it with teammates or clients.
They don’t go in the same level of detail. The main difference between Ishikawa diagrams and issue trees is that the diagram only lists the potential causes whereas the tree lists the potential causes, summarizes them in logical groups, spells out the hypothesis associated with each group, explains the analysis necessary for testing each hypothesis, and lists the data sources where you can find the information that fuels the analyses.
The primary advantage of spelling out all this information is that the issue tree become a roadmap for your project, helping you in assigning efforts and resources where they matter most, allowing you to step back and see the big picture at any moment, and facilitating the integration of efforts (for instance by allowing you to go to each data source only once by identifying beforehand all the information bits that you need from it).
Pick whichever tool but pick one
So which should you use, an Ishikawa diagram or an issue tree? I prefer trees, especially for solving complex problems, because it gives me that ability to see the big picture easily, making it easier to commute between seeing the individual tree and the forest. But, in the end, it doesn’t really matter, what is important is that you structure your diagnosis effort; if you can do it without any diagram or tree, congratulations! Otherwise, try both tools and pick the one works for you.