The four steps to constructing a cause and effect diagram

Learn how to visually describe potential root causes of a business challenge

Add bookmark

The cause and effect diagram is an easy yet powerful tool commonly used in a cross functional setting to visually describe the potential root causes for a specific problem in question. The tool lends itself to enabling a team to readily organize the causes behind the problem into useful categories, providing a structured brainstorming session.

One of the seven basic quality tools, the cause and effect diagram is also know as the fishbone diagram (as the key causes look like the bones of a fish when displayed visually, hence the name) and the Ishikawa diagram (named after Kaoru Ishikawa, who first proposed the tool). Variations of this method include the cause enumeration diagram, the cause and effect diagram with the addition of cards (CEDAC) and a desired-result fishbone diagram.

How to construct a cause and effect diagram step-by-step

Define the problem (effect) to be solved.

This first step is probably one of the most important tasks in building a cause and effect diagram. While defining your problem or event, your problem statement may also contain information about the location and time of the event. On the cause and effect diagram the problem is visually represented by drawing a horizontal line with a box enclosing the description of the problem on the tip of the arrow. 


Identify the key causes of the problem or event

In this step, the primary causes of the problem are drilled down by using brainstorming techniques. Often these causes are put in categories such as people, equipment, materials and external factors. Some of the commonly used primary causes, but not limited to, include the four M's of manufacturing (machine, method, material and manpower); the four S's of the service sector (surroundings, suppliers, systems and skills); the five M's (measurement, maintenance, money, management and Mother Nature); and the eight P's of marketing (product, price, place, promotion, people, process, physical environment and productivity).

Other appropriate primary causes include service, quality, technology, consumables, work processes, environment, service level, etc. The image below shows how to visually depict these key causes on the cause and effect diagram. 



Identify the reasons behind the key causes

The goal in this step is to brainstorm as many causes for each of the key causes. Tools such as the five Whys (the subject of a future column) can help your team to drill down to these sub-causes. To facilitate participation from all of your team members, ask each member of the group to provide one reason behind a key cause.

These suggestions should be written down and connected to their appropriate key cause arrow (see the image below). Remember that these reasons are free-flowing, form logical patterns and are inter-connected to a key cause. 


Identify the most likely causes

At the end of step three, your team should have a good overview of the possible causes for the problem or event; if there are areas in the chart where possible causes are few, see if your team can dig deeper to find more potential causes.

The team then should focus more specifically on the potential cause(s) that have a high probability of taking place. It is not unusual for teams to use techniques such as multi-voting to shortlist the areas that will have lasting impact on solving the problem at hand. In certain instances, the team might collect additional data to better understand and quantify the potential causes. Simple hypothesis testing, such as asking "Where?", "When?", and "How?" lead to a better understanding of the relationship beween the potential cause and the problem the team is tasked to solve.

How to get the most out of the cause and effect diagram

One of the key pitfalls to watch for when completing a cause and effect diagram is to avoid getting into the habit of providing never-ending possible causes to the problem. A good facilitation tip in this situation is to decide when to stop the cause and effect discussion by focusing the team on their "span-of-control" and "sphere-of-influence".

Span of control refers to work areas where the team has complete control of its environment. The sphere of influence refers to the work areas where the team is able to exert some influence but not full control. For teams to come up with meaningful solutions, they should operate in both these work areas.

Other helpful tips to ensure the effectiveness of the cause and effect diagram is to have an experienced facilitator. This person can help the team unearth the real reasons behind the problem/event using techniques such as the five Whys, causal trees or root cause analysis techniques. It is also not a bad idea to look for data to back up opinions expressed to confirm the true nature of the causes.

A healthcare cause and effect diagram example

As I mentioned in an earlier column, hand hygiene compliance in a healthcare setting is less than optimal in most hospitals, with over 90,000 deaths attributed to hospital acquired infections every year in the United States.

In the Mayo Clinic, one of its teams used the cause and effect diagram to identify the various potential causes of improper hand hygiene in the health care setting. In the abridged diagram shown below, the various main factors such as process/measures, physical access/design, system issues, culture and not having the right tools were identified.

The team then conducted a quick assessment to determine how often the potential causes occurred. Based on this data, the team then implemented a multi-pronged pilot to increase awareness, accessibility and accountability, and to initiate other specific interventions. This resulted in sustained improvements in hand hygiene compliance in the pilot units. Now, that is not a fish tale! 


To learn more about methodologies to implement to achieve operational excellence and successful business outcomes, check out PEX Network's PEX Guide: What is operational excellence?

This article was originally published on 24 May 2010.


RECOMMENDED