Cause and Effect Methodology Tips

By Steve Wilheir


A cause and effect diagram is a tool used to facilitate root cause analysis for a defined problem. The diagram provides a structured way to record potential root causes during brainstorming, encouraging teams to think about a problem systematically and to dig deeper to discover less obvious causes.

Cause and Effect diagram have been illustrated in many ways. One of the most novel is called the "Cause and Effect" or "Ishikawa" diagram, named after Dr. Kaoru Ishikawa, its originator. Dr. Ishikawa was an expert in Quality Control Theory. Why it is called "fishbone" becomes obvious when the diagram is completed, in that it looks like a fish skeleton.

The starting point of the study is a dilemma that is to be researched. The dilemma is articulated as an inquiry on the right half of the paper. A sketch of a fish head or an arrow directs you to the relevant inquiry. Left of the articulated dilemma, a horizontal line separates the page into a pair of sections, forming the "spinal column" of the cause and effect diagram.

The following collection of bones stand for the primary types of variables that might play a part in the underlying or root cause. The labels of these subsets are displayed across the upper and lower portions of the page. Arrows lead in the direction of the spinal column and in the direction of the head, creating a herringbone look.

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.

There are many factors which are responsible for the root cause for each category of issues and the analysis begins once the basic skeleton is ready. There are arrows with the factors written above them, points towards each category line. These category lines also have their own lines pointing into them and further breaks down the factors that contribute to them. As this continues infinitely, due to visible reasons, it is hard to go beyond few levels.

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.






About the Author: