Fishbone Diagrams
The Cause-Effect diagram is also known as the Root Cause, Fishbone, or Ishikawa diagram. It is a visual representation of the various factors that contribute to a particular consequence and is very useful for analyzing problems. The advantage of this diagram is that it facilitates the categorization of the causes as well as the methodical identification of each one of them.
Unfortunately, several lead developers and even most architects I know have never used this tool to help themselves and their teams determine the root cause of a problem. In some cases, they don’t even know these kinds of diagrams.
Purposes
A cause and effect diagram examines why something happened or might happen by organizing potential causes into smaller categories. It can also be useful for showing relationships between contributing factors. One of the Seven Basic Tools of Quality, it is often referred to as a fishbone diagram or Ishikawa diagram.
- Explore and identify all possible causes related to a specific problem.
- Discover the root causes that cause a certain effect.
- Show the dependencies between the causes as well as the main factors that influence its appearance.
- Focus the team on identifying the causes and not the symptoms of a specific problem.
- Create a graphic representation of the collective knowledge of the problem at a given moment.
How To Create A Diagram
Preparation
Prepare a white surface such as a blackboard, the wall, or a sheet of paper on which to draw the diagram. It is more convenient to draw the diagram on this type of surface and not on a computer since this encourages creativity and participation among the members of the work team.
Write the problem statement (Effect) in the right box of the diagram. It is important to include a detailed explanation with the information that is necessary for the description of the problem to be accurate. Make sure that all team members agree with the problem statement.
Analysis
It begins by identifying the high-level causes which are called major causes. These causes are what is written as the names of the “main spines” in the diagram. Major causes commonly refer to a category, such as infrastructure, procedure, design, etc.
Give each team member a Post-It packet. For each category, ask them the question… Why does this happen? And then ask them to write the reason on a Post-It and paste it in the corresponding category.
When you are done with all major causes or categories, review the reasons they have written making sure to:
- Delete the reasons that are duplicated.
- Integrate the reasons that are similar.
- Redefine the reasons that are not clear.
The resulting reasons are known as sub-causes. At this point, you have already formed the fishbone diagram.
You can leave the analysis at this level or you can go to the second level of detail. If this is the case, for each sub-cause ask once more why this happens. Request that they write the reasons again in a Post-It and paste them in the corresponding sub-cause.
When finished, review the reasons they have written in the sub-causes, making sure again:
- Delete the reasons that are duplicated.
- Integrate the reasons that are similar.
- Redefine the reasons that are not clear.
Team review the final diagram in order to validate that the set of causes is reasonable, clear, and complete. It is probable that at this stage they find some other cause that has not been previously considered, they can add it. Likewise, they can improve the wording of the causes that are not clear.
Once the analysis is finished, write the results in an Excel file and share it with the team.
Recommendations
Save the Cause-Effect analysis files in a single folder and name each file with a title that relates to the problem being analyzed. The files must be accessible and easy to locate since they are very useful for identifying risks or when planning projects.
You can also invert the diagram to perform a solution-effect analysis. In this case, the solution would go to the left box and the effects would go to the right side.
Real-Life Examples
The following are four real-life scenarios that I found posted on many sites and they are perfect examples of diagrams used correctly:
- Operations outage
- Service outage
- Quality failure
- Security incident
Operations Outage
A production line goes down for a full working day due to failed AC equipment in the company data center. A root cause analysis determines that the equipment had multiple design issues. Such problems weren’t detected or mitigated by maintenance processes. When the equipment needed to be replaced, several issues complicated the process making the outage longer.
Service Outage
A software service experienced an outage after a bug that was missed in testing was launched to production. The procedures required to fix the problem did not go smoothly as backout procedures failed and developers had trouble accessing environments due to issues with security keys.
Quality Failure
A customer finds a problem with a shipment of multiple boxes containing products that passed quality control. A quality control investigation reveals that an error in one of the machines involved in manufacturing the product caused the defect. Testing and quality control processes failed to detect the problem.
Security Incident
A worker loses a laptop filled with company data at a bar. The incident investigation discovers a lack of policy and procedure to prevent such problems. Root cause analysis also reveals technical shortcomings such as weak encryption, a poor password policy, and a lack of an audit trail for data.
Summary
Ishikawa diagrams (also called fishbone, herringbone, cause-effect diagrams, or Fishikawa) are causal diagrams created by Kaoru Ishikawa that show the potential causes of a specific event.
