subject: Is Something Fishy Here? Root Cause Analysis Using Fish Bone Diagrams [print this page] For the root cause analysis of a specific problem, a fishbone diagram tool is used. To monitor the potential root causes while brainstorming, this diagram gives a structural way to record. This diagram also helps the team to approach a particular problem in an organized way and to go deep to explore the lesser visible reasons.
The fishbone model, a kind of cause and effect chart, was originated by a quality control professional from Japan named Dr. Kaoru Ishikawa. Hence the other nickname for this diagram, the "Ishikawa Diagram." It is commonly referred to as a "fishbone" model because in appearance it is similar to the skeletal structure of a fish.
The "backbone" of the fishbone diagram is a horizontal line that divides the paper in two. The analysis starts with a problem to be investigated. On the right side of the page the problem is written in the form of a question. Sometimes a drawing of a fish head or an arrow will point to the question under consideration.
The following group of bones symbolize main categories of facts that might be a part of the main cause. These category titles are inscribed on the paper at the top and the bottom. Arrows placed on an angle are arranged in a backwards and forwards pattern, that make a herringbone pattern.
There are many methods that have been used in the past to obtain categories for different types of problems. For example, the manufacturing industry has used the 6 M's. Whereas service and administrative problems use the 8 P's to help determine a starting point. In addition, the Service industry may also use the 4 S's to categorize problems.
After the skeleton starts to take shape, these lines in turn can have their own lines pointing into them, breaking down factors that contribute to it. This can go on infinitely, but will be difficult to draw beyond a few levels for obvious reasons.
With the skeleton of the diagram in place a team brainstorms about each category, looking for reasons that produce the end result. Generally, it is good to phrase a problem as a question and ask team members to answer the question in the context of each category. In general, the question is "Why is this happening?" Then, for each category, the question shifts to "How are factors in this category causing this?"
The brainstorming continues until team members can no longer think of useful items to add to the diagram. At this point, the results are analyzed to identify the most likely root causes of the problem. Finding the same issue within multiple categories is a good indication that it is an important root cause in the system. Likewise, areas of the diagram that are densely populated with detail are likely to point to areas of significance.
