Cause-and-effect diagrams

Cause-and-effect diagrams

18.1 Purpose

A cause-and-effect diagram is a graphical representation of the cause and effect relationships present in an information system or a system in general. The diagram can be used to conduct a root cause analysis, to help design or redesign systems, and to help create or redefine operation standards. The diagrams are sometimes referred to fishbone diagrams, because of their appearance, or Ishikawa diagrams in reference to the quality expert Kaoru Ishikawa who championed their use.

18.2 Strengths, weaknesses, and limitations

A correctly constructed cause-and-effect diagram will lead to a better understanding of the system of interest. The underlying causal relationships among the subsystems and processes comprising the system should become clear to the people constructing the diagrams and the people interpreting them. The diagram can then be used as an effective tool for identifying the root cause of an undesirable system effect. The diagram is also helpful in facilitating a wide range of discussions concerning the system and efforts to improve the system. Moreover, a detailed cause-and-effect diagram can be used as a technical source for a wide range of purposes including the development and revision of technical, operating, and inspection standards.

The effectiveness of the cause-and effect diagram is directly related to the quality of the work that goes into developing the diagram. Everyone involved with the system must participate in the construction process by offering their input concerning all the factors involved in the problem. These factors must be placed into categories that are relevant and properly defined. The relationships among the categories must also be correctly identified. If possible, causal relationships should be verified with regression analysis or other statistical techniques.

Three common mistakes in constructing cause-and-effect diagrams are not clearly defining the categories, improper verification of the causal relationships, and not having enough detail in the diagram. Teamwork and dedication to detail should overcome these problems.

18.3 Inputs and related ideas

Cause-and-effect diagrams are useful tools for identifying the likely causes of a problem during the problem definition stage (Part II) of the system development life cycle. Brainstorming (Chapter 14, Section 14.4.4.3) is a valuable tool when developing a list of possible activities to be used in a cause-and-effect diagram. Once the cause-and-effect diagram is drawn, it is often helpful to use it in conjunction with a Pareto diagram (Chapter 11) to help prioritize and allocate resources. In general, the seven tools for quality improvement (Pareto diagram, cause-and-effect diagram, control chart, process flow diagram, check sheet, scatter diagram, and histogram) serve as a complimentary tool set which has been proven to be effective in improving many systems.

18.4 Concepts

A cause-and-effect diagram is a graphical representation of the causal relationships inherent in a system. Constructing a cause-and-effect diagram requires a team composed of people knowledgeable about the system of interest. In the following example, a cause-and-effect diagram for evaluating client server application failures is presented.

18.4.1 Constructing the diagram

The first step in constructing a cause-and-effect diagram is to develop a clear definition of the effect or outcome of interest. Then all possible causes leading to that outcome are brainstormed. It is important in the brainstorming period to consider all possibilities so that no important factors are overlooked. Unimportant causes can be dropped later.

In our example a client server application failure is the system event of interest and is placed in the box on the right side (the effect side) of the diagram, as shown in Figure 18.1. Next, the main arrow pointing into the effect box (the trunk) is drawn.The trunk is in the left side of the diagram (the causal side).

Four to six branches are then selected to represent the main causes of the main effect. The branches represent cause-and-effect relationships with the main effect of interest. Leading into the big branches, are medium branches which are used to represent the next layer of causal relationships. Note that the cause-and-effect relationships should move in the direction of the arrows in the figure. For example, a software bug leads to a middleware problem, which leads to the client server application failure. Or, a broken physical connection can lead to a network problem, which results in the client server application failure.

A cause-and-effect diagram can contain as many different levels of branches as necessary. Typically two to five levels are used. If four or five levels are used, it is often helpful to produce the diagram in pieces. Note that in Figure 18.1 the big and medium branches are displayed, while in Figure 18.2 the small and tiny branches attached to the Client hardware failure medium branch (a horizontal arrow near the lower right of Figure 18.1) are displayed. Three small branches are used to identify the main causes for this type of failure, and sub-categories within the small branches are displayed in the tiny branches. For illustrative purposes, only one of the medium branches in Figure 18.1 is expanded, but in practice any or all of the medium branches could be broken down and illustrated in detail.

Figure 18.1  The main portion of the cause-and-effect diagram for the client server application failure.

Figure 18.2  The detailed portion of the cause-and-effect diagram associated with client hardware failure.

18.4.2 Root cause analysis

A correctly constructed cause-and-effect diagram is very useful for conducting a root cause analysis. For example, suppose that a client server application failure has occurred. The cause-and-effect diagram shown in Figure 18.1 suggests that the cause is one of the following four factors: middleware, server, network, or client. Assuming that the problem is determined to be with the client, we now investigate the possible sources within the client, listed in Figure 18.1 as human error, client hardware failure, application software failure, and system software failure.

Suppose that the problem was determined to be with the client hardware. Next, we turn our attention to Figure 18.2 and try to determine if the client hardware failure was owing to a processor problem, a memory problem, or a hard drive problem. Assuming that it was a hard drive problem, the cause-and-effect diagram gives three possibilities for such an event: disk head crash, hard drive full, and driver failure. Answering this question leads to the root cause of the client server application failure. Suppose that the hard drive was found to be full. The full hard drive is said to be the root cause of the client server application failure. Reaching the root cause required a series of four questions each probing a causal relationship one step further.

A root cause analysis is only possible when the causal relationships in a cause-and-effect diagram are valid. An analyst should verify the structure of the branches and the direction of the arrows beginning with all tiny branches before using the diagram. For instance, tracing the logic presented above, the analysts should have previously verified that a full hard drive can lead to a hard drive problem, which can lead to a client hardware failure, which can lead to a client problem, which can lead to the client server application failure. If possible, these paths should be verified with data and statistical models.

18.5 Key terms

Branches —

The factors causing the effect of interest; branches are sub-divided into big, medium, small, and tiny branches. When the term fishbone diagram is used, branches are referred to as bones.

Effect of interest —

A characteristic or event of a system that the cause-and-effect diagram is meant to study; typically, a problem or undesirable event.

Root cause analysis —

Identification of the initial factor resulting in an effect of interest; the root cause is usually found in a tiny branch. This initial factor starts a chain reaction of cause and effect situations, moving from a tiny branch to a small branch to a medium branch to a big branch, and ultimately resulting in the effect of interest.

Sources of variability —

Many different things can affect the outcomes from systems, including the effects of workers, machines, materials, methods, measurements, and the environment. These six sources of variation are sometimes used as the big branches on a cause-and-effect diagram.

Trunk —

The trunk is the central part of the diagram to which the big branches are attached. When using the term fishbone diagram, the trunk is referred to as the spine.

18.6 Software

Most graphing packages have the ability to produce cause-and-effect diagrams. For example, the chapter figures were produced with Microsoft PowerPoint.

Many statistical or quality improvement software packages can be used to produce cause-and-effect diagrams. Construction of cause-and-effect diagrams using Minitab for Windows is easy, but not very flexible. In SAS, use the Ishikawa procedure.

18.7 References

1.  Gitlow, H., Oppenheim, A., and Oppenheim, R., Quality Management: Tools and Methods for Improvement, 2nd ed., Irwin, Burr Ridge, IL, 1995, chap. 9.

2.  Ozeki, K. and Asaka, T., Handbook of Quality Tools: The Japanese Approach, Productivity Press, Cambridge, MA, 1990, chap. 12.