By Hank Marquis
Anyone with IT Infrastructure Library® (ITIL®) certification has heard of Ishikawa or “fishbone” diagrams, usually in the context of Problem Management.  Aside from knowing it is a root-cause analysis tool, most have no idea how to use it.

Root Cause Analysis

Ishikawa, "Fishbone", or cause-and-effect diagram all refers to the same thing.  A graphical representation of inputs (causes and reasons) and an output (the problem or event.)  A practitioner guides a group in organizing causes according to importance.  This results in a graphic showing the relationship between causes, reasons and the problem under study.  This graphic helps identify root causes, inefficiencies, and others issues.

Use this technique whenever you must:

Completed Ishikawa diagrams somewhat resemble a fishbone, and thus the nickname of “Fishbone Diagram”.  Keeping with the fish analogy, the “head” should contain a problem description.  From the head originates the “spine” of the diagram.  From the spine “ribs” indicate the major area that can cause the problem as described.

In ITIL, the “3 P’s” normally represent the starting point for the “ribs.”  The 3 Ps are: People, Process and Products (tools.)  Note that you can use any ribs you desire, in the diagram above I have added “environment”, feel free to modify your ribs to suite the issue at hand.  The goal is to identify just a couple of main rib categories that include the most probable contributing factors. 

The creation of an Ishikawa diagram follows a fairly simple process:

1. Assemble a group of people familiar with the problem at hand.
2. Draw a flat horizontal line as the “backbone” and a box to the right of the backbone as the “head” on a presentation board or flipchart. 
3. Work with the group to arrive at a problem description that is clear and concise. Write the problem description in the problem box or fish head of the diagram.  In the example the problem is "bouncing incidents", referring to why some incidents "bounce" between support groups.
4. Have the team discuss and agree to the major cause groups or initial “ribs”.  If the group cannot agree on the major causes, just use the 3 P’s -- People, Process, Product.  Write a label for each "rib" allowing space for reasons as shown in the example.  
5. Use traditional brainstorming techniques to fill in possible reasons for the "ribs" as follows:
   • Ask each person one by one to give a possible cause (perhaps in the form of a question) for each "rib."  One possible reason per person, and if they cannot think of one they can pass.  Make sure that each cause is clear, concise and measurable.
   • Draw the cause on a line connected to the appropriate "rib" and label it with the cause.  If the proposed cause is a factor in an existing cause (rib) then draw another backbone off the rib, add another rib, and label it.
   • Go back and repeat until everyone says “pass” and there are no more possible causes for existing ribs and there are no new ribs to add.
6. With the fishbone complete, now review and discuss the Ishikawa diagram to look for common or repeated causes.  Try to determine the root cause of the problem.

The fastest and easiest way to interpret Ishikawa diagram results is to select and rank the top 5 causes.  Let the group decide how to rank the causes.  The 5 Whys are also useful in determining the most likely root-cause when the diagram is completed as well.  [See "Five Whys to Solve Problems" DITY Vol.2 #19 for more on this technique.]  Circle the selected causes. Have appropriate group members investigate these causes using other troubleshooting techniques.  Repeat as required.

Mastering Cause-and-Effect

Experienced practitioners limit the number of “ribs” (causes) to focus the group. Some suggest allowing no more than 3 to 5 ribs.  Other key Ishikawa usage techniques include:

• Using sticky notepad sheets for the ribs or inputs to make rearranging the fish bones easy
• Framing the problem as a question, such as "why are incidents bouncing back and forth between support groups?" Each cause should answer that question.
• Ensuring that “ribs” are causes of the problem, not symptoms of the problem
• Using brainstorming to determine exactly what the ribs should be -- the “5 Whys” technique can help here
• Checking that the causes on the diagram are not themselves other problems
• Combing empty (or nearly empty) ribs with or onto other related ribs as appropriate
• Splitting up dense ribs into additional ribs as appropriate
• Making copies of the results and circulate them to others to gain more insight and involvement of staff

The Ishikawa diagram is a powerful tool for harnessing the combined knowledge and experience of a group of people.  It lets the group focus on why problems occur without the distraction of symptoms.  

Try fishing for a solution the next time a tough problem comes up.  And don’t limit yourself the Problem Management -- use this technique anywhere you need to determine the root cause of something.

Where to go from here:

Related articles:

• 3 Steps to Success with CFIA explains Component Failure Impact Assessment
• Fault Tree Analysis made Easy shows how to create Fault Tree diagrams
• Service Outage Analysis in 7 Steps lists the steps to create a Service (or system) outage analysis
• 7 Steps to the TOP documents the purpose and function of the Technical Observation Post (TOP)
• 5 Whys to Solve Problems introduces the "5 Whys" quality management techniques for root cause assessment
• How to Roll the Deming Wheel explains how to use the Plan-Do-Check-Act (PDCA) cycle to resolve a process problem

Entire Contents © 2006 itSM Solutions LLC.  All Rights Reserved.