AKA: Ishikawa Diagram, Herringbone Diagram, Cause and Effect Diagram, Fishikawa Diagram
A Fishbone Diagram is a type of diagram used to show the causes of a particular problem or opportunity and to break down those causes into categories that are elaborated into successive levels of detail. They were created by Kaoru Ishikawa and are considered one of the
Seven Basic Tools of Quality.
At its most basic, the fishbone diagram consists of a single effect or issue at the far right of the diagram (the
head) with a horizontal arrow pointing to it. From this horizontal line main branches extend vertically both upward and downward (the
ribs), with each main branch representing a single causal category.
Each category branch then has primary causes of the effect that fit in that category as sub-branches, with sub-causes branching off the appropriate primary causes in a repeating pattern until there is agreement that the root cause of each primary cause is identified (collectively the
The result is a diagram that uses a structure similar to that shown below.
This structure helps the creators think in a systemic way by letting evaluate each primary cause in isolation (at least initially).
standard categories for various problem domains which provide a framework for the problem analysis; however it is perfectly acceptable to create your own cause categories if it seems more appropriate the problem you are investigating. Or feel free to start from one of the
standards and add or remove categories as appropriate. These mostly serve as references and mnemonics to help you ensure you are considering all possible aspects of the problem in your analysis.
standard categories for Manufacturing (also called the
8 M’s) are:
standard categories for Marketing (also called the
7 P’s) are:
standard categories for Sales (also called the
5 S’s) are:
standard categories for Service work (also called the
4 P’s) are:
Fishbone Diagrams are a primary technique used for root cause analysis. In addition the structure can also be used for:
There are also variations of the standard Fishbone Diagram technique that add quantitative information such as weightings or factors that enable a more nuanced analysis of root causes based on priority or weighted impact.
Their simple visual structure makes them easily understandable to a wide audience and they are a good way to summarize information or to act as the starting point for further analysis.
The most important thing to remember though is that Fishbone Diagrams usually act as a foundation for further action. That action might be problem solving, risk mitigation, process improvement, or a variety of other actions that act to reduce the impact of the root causes identified (or important factors for non-root cause analysis). This means that the quality of resulting diagram and how well it captures the underlying factors involved can have a major impact on future efforts. If you just take a shallow pass at analysis, your future efforts are likely to be directed to the wrong areas or areas where the impact is less than it could be.
Creation of a Fishbone Diagram is usually done as a team exercise but like most techniques you can do it on your own. However, if done on your own you lose the value of multiple perspectives and group knowledge that may result in a significantly stronger end product.
The first step of creating a Fishbone Diagram is to define the problem statement that the diagram will address. The statement should be clear and agreed upon by all parties taking part in the creation of the diagram.
This statement is placed at the middle right in the
head of the Fishbone Diagram.
If the issue you are investigating is very broad or poorly defined, it may be better to create several diagrams that address more granular aspects of the problem space that can be clearly defined.
For an example, I will leverage and expand upon an actual fishbone diagram from a research paper into causes of incomplete or hidden requirements. So the effect we are looking at is “Incomplete/ Hidden Requirements” and our diagram at this point looks like this:
The next step is to define the primary causal categories you are going to use (the
ribs) for the diagram and to add them. Include category labels at the end of each
rib. You can use one of the sets of
standard categories discussed above, or create your own categories.
For the example I will stick with the 5 categories that were used in the research paper. They were Tools, Organization, People, Input, and Method. When the categories are added to the diagram it looks like this:
The next step is to identify primary causes of the problem and add them to the appropriate
rib in the diagram. This identification could be based on actual data or could be the result of brainstorming the by participants in the diagram creation process. Alternatively, you could generate a whole list of primary causes and add them to the appropriate ribs once the initial list is complete.
Some causes may be applicable to more than one category. If so, you should add a separate instance
bone of that cause to each category
rib it is applicable to.
Keep in mind that there are three general conditions that must be met to demonstrate a causal relationship. These are:
If X is present then Y is present, or
If X is not present then Y is not present, or
If X increases then Y increases
However, most Fishbone Diagrams that are created for root cause analysis are initially more exploratory in nature and so proving the 3rd condition may not always be something that is possible or necessary (especially with the data collection and experimentation that may be necessary to actually ‘prove’ the causal linkage in a formal manner). Especially because most ‘problems’ in the organizational realm are likely to have multiple causes, rather than just one.
So while meeting condition 3 above usually means ruling out all other alternative causes, when creating a Fishbone Diagram you may just want to identify other possible causes and add them to diagram. You can supplement the diagram by adding probability weights or factors to various causes in order to identify the most likely or those with the largest impact.
For the example I will stick with the primary causes that were used in the research paper. When the primary causes are added to our diagram it looks like this:
Once you have your initial list of primary causes added to the diagram, revisit each of them and ask
why. Why is that primary factor a cause of the problem? The answers become secondary causes that are added to the diagram as branching
bones off the primary cause
bone you are analyzing.
You should continue to ask
why and add more sub-branches, or even sub-branches off of sub-branches, until you feel you have arrived at a root cause (or causes) for that primary issue. This may involve going down several ‘levels’ and essentially an undertaking of the
5 Why’s technique.
For example, if a primary factor of a problem was
Users weren’t trained in the system then your further levels of analysis might show that:
support stafftraining courses provided by the vendor
support stafftraining courses provided by the vendor because there were no funds in the training budget to send them with
The diagram in the research paper I have been re-creating up to this point only went as far as the primary causes, so from this point forward I will just make up enough (semi)plausible changes to demonstrate what I am talking about. In fact, the diagram is going to beat you over the head with a single point to make things easier later on in the example. When the secondary causes are added to our diagram it looks like this:
At this point it’s a good practice to refine the diagram by pausing and asking the following questions:
For purposes of the example, I am going to say that we decided one category name could be clearer (changing
Process) and that a few of the causes in the diagram should be moved to different categories. All of the changed elements are identified with a purple in the diagram below:
Once the diagram has been refined it is a good idea to supplement the diagram with visual cues or weighting values to identify the level of impact or likely impact that each of the categories and causes have. The goal with this step is to increase the usefulness of the diagram by highlighting the most important findings, identifying finding types, or by supplementing the information in the diagram to allow for greater utility of the diagram.
This might be as simple as bolding the description of the single primary cause under each category that is perceived to have the largest impact on that category. Or the single primary cause for each category that should be addressed first (which may not always be the one with the largest impact). You would then repeat that process for each primary cause to identify the single secondary cause with largest impact or highest priority. And again for the tertiary causes of each secondary cause. And etc.
Another option is to use color codes on the causal text to identify priorities or impact levels (high, medium, low). Or for identifying the organizational unit or external entities that ‘own’ responsibility for the various causes that were identified.
Or you might supplement the textual labels of the diagram with weighting values to add a qualitative dimension to the diagram. For example, based on the information captured and assuming a 100% total ‘cause’ for the effect being analyzed, what percentage of the overall impact came from each category? So if you were analyzing a Service issue with the 4 P’s standard category set, the categories might break down like this:
Then you would repeat that step but evaluating the impact of only the primary causes on the category. Then repeat it again for each primary cause. And again for any secondary causes. And etc.
For the example the only change I am going to make it to weight each of the categories with a percentage value indicating the level of impact the accumulated causes are thought to have on the effect that is being analyzed. In theory, this would help us identify priority areas for future changes.
With that simple change, the diagram now looks like the one below:
The next step is to look for the important root causes across the entire diagram that will be the focus of whatever the next steps will be. These could be the causes that appear under multiple categories; that had the highest weighted impact scores, or that the evaluation team feels are the most important ones to address.
Your situation may be simple enough that there is only 1 or 2 actual ‘root’ causes, but in most situations there may be more ‘root’ causes than you can easily address within the time, scope, or budget you are operating under. In that case you need to identify which are the most important ‘root’ causes for getting the goals you desire.
As you can see from the diagram below I have identified a single recurring underlying root cause for a great many of the primary causes I identified.
The end result should be a diagram that identifies the root cause(s) of the effect that is being investigated. If there are multiple causes, hopefully the diagram has helped to identify the most important ones and provided some insight as to whether significant improvement of the main effect can be achieved by a few focused efforts or if there might need to be a lot of changes and work done is many areas in order to achieve the desired level of improvement.
Going back to the example, the end interpretation of the diagram would be something like this:
Hidden and Incomplete Requirements are a regular occurrence because the organization does not understand the importance of RE which means that there is no attention paid to improving people (through better hiring, training, or developmental opportunities); RE processes (through a center of excellence, standardized RE process, RE tools, and process specific training); and organizational awareness (which should drive increased engagement from stakeholders and the assignment of higher quality resources to RE efforts). Therefore, we should focus on increasing awareness of the importance of RE as a driving force in order to enable many further changes that would result.
One thing that should be clear from the sample is that a fishbone diagram can easily get VERY complex. It should be obvious to you that I skipped a lot of opportunities to dive further into the primary causes and identify more sub-causes. And that the sub-causes I used in the example were simplistic.
If you were to create a diagram on this same topic for your organization (and I encourage you to give that a try, it’s something you can probably do as a great exercise with your peers) that you may end up with 4 or 5 sub-cause levels before you get agreement on ‘root’ causes.
However, if you don’t go to that level of detail the value of your analysis is likely to be severely compromised.
An additional non-diagram option for capturing the same information as in a fishbone diagram is to use a simple hierarchical list as shown below. This is also a great way to create the ‘first draft’ of your diagram while you busy brainstorming so that you aren’t worried about having to move causes around for clarity and readability.
Effect: Incomplete / Hidden RequirementsCause:
1. Tools 1.1. Missing requirements template 1.1.1. No RE tools available 18.104.22.168. Funding is focused on individual projects rather than project process 1.1.2. No PMO or COE to provide standardized templates 22.214.171.124. Poor understanding of the importance of RE 126.96.36.199. No focus on improving RE skills 188.8.131.52.1. Poor understanding of the importance of RE 2. Process 2.1. Missing completeness check of requirements 2.1.1. Lack of standardized RE process 184.108.40.206. Poor understanding of the importance of RE 2.2. Requirements frequently change 2.3. Missing solution approach 2.4. Adopted Agile methodology 2.4.1. Project team members had little knowledge of Agile 220.127.116.11. Lack of Agile training 18.104.22.168. Lack of Agile mentoring / process support 2.5. Poor requirements elicitation techniques 2.5.1. No focus on improving RE skills 22.214.171.124. Poor understanding of the importance of RE 3. Organization 3.1. Development team too small 3.2. Lack of time 3.3. Different interests within project team 3.4. Poor understanding of the importance of RE 4. People 4.1. Missing domain knowledge 4.2. Lack of experience 4.3. Missing qualifications of RE members 4.3.1. Poor understanding of the importance of RE 4.3.2. RE specialists and team members are unaware of RE qualifications 126.96.36.199. No focus on improving RE skills 188.8.131.52.1. Poor understanding of the importance of RE 5. Input 5.1. Poorly defined requirements 5.2. Missing engagement from the customer side 5.2.1. Poor understanding of the importance of RE 5.3. Unclear business needs 5.4. Requirements frequently change 5.5. Requirements are not clear when development begins 5.6. Customer has unrealistic goals / concepts 5.7. Missing knowledge / skills / qualifications of customer
What Should the Results Be?or by using Mind Mapping software. Once you have taken the first pass or two you can adjust the major categories or refine the wording of causes, which should let you quickly create an initial Fishbone Diagram that just needs to be refined and which is unlikely to need major revision.