The fishbone is a known structure model to brainstorm root cause of effects. This post is going to explain how to add symptoms into the mix to validate that we found and resolve the root cause and not a symptom.
Every root cause will have several symptoms that are much easier to detect but are not the root cause of a problem. In a complex system, where many parts of the system working autonomously and in parallel, the odds to find a symptom is much higher than to land on the root cause.
Because it is easier to find the symptom, many people tend to think that they found the root cause. They resolve the sign, to find out after a while that another symptom appears as a new effect to the system.
Let’s take communication as a common problem that we are trying to brainstorm. The first cause that people will find is missing prioritization. But, is prioritization is the root cause of communication issues? I hope that you agree with me that it is not. One way or another, people temp to see the first symptom as the root cause and try to resolve it. If someone addresses prioritization, he will find out very fast that communication is still a problem.
The twist that we introduce to the fishbone is simple but enforce people to think about all symptoms. Instead of the main line (fish bones) representing categories, they are describing the symptoms that we found out while brainstorming. The backbone represents the root cause.
Our fishbone diagram will look like this:
Categories will expend each symptom. At the end of the fish (as the fishtail), we place the categories of the root cause. Casual factors should branch from the categories (the same as in a regular fishbone). We found out more than once that more than one fishbone diagram is needed due to multiple root cause. We tend to end up with numerous backbone lines going from the head, but you can alternatively use multiple fishbone diagrams.
Here’s an example with some data:
We found this approach working for us extremely well. The need to think on symptoms enforce us to find them up and distinguish them from the root cause.
When we present those diagrams to customers, they found the distinction between the root cause and the symptom helpful as well. More than once, we found ourselves arguing with a customer if the root cause is not a symptom, a very healthy debate.
Adding symptoms is a simple modification to a known method. If you try to use it, you’ll see the difficulty and the benefit that comes with new approaches.