1999 by CRC Press LLC

chapter eighteen
Cause-and-effect diagrams
John Skip Benamati and Timothy C. Krehbiel
Miami University
Contents
18.1 Purpose
18.2 Strengths, weaknesses, and limitations
18.3 Inputs and related ideas
18.4 Concepts
18.4.1 Constructing the diagram
18.4.2 Root cause analysis
18.5 Key terms
18.6 Software
18.7 References
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
Acorrectly constructed cause-and-effect diagram will lead to a better under-
standing of the system of interest. The underlying causal relationships
among the subsystems and processes comprising the system should become
1999 by CRC Press LLC
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 devel-
opment 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 iden-
tified. 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 improv-
ing many systems.
18.4 Concepts
A cause-and-effect diagram is a graphical representation of the causal rela-
tionships 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 evaluat-
ing 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
1999 by CRC Press LLC
leading to that outcome are brainstormed. It is important in the brainstorm-
ing period to consider all possibilities so that no important factors are over-
looked. 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 dia-
gram, 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 fail-
ure medium branch (a horizontal arrow near the lower right of Figure 18.1)
Figure 18.1 The main portion of the cause-and-effect diagram for the client server
application failure.
1999 by CRC Press LLC
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 dis-
played in the tiny branches. For illustrative purposes, only one of the medi-
um 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.
18.4.2 Root cause analysis
A correctly constructed cause-and-effect diagram is very useful for con-
ducting 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: mid-
dleware, server, network, or client. Assuming that the problem is deter-
mined 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, appli-
cation software failure, and system software failure.
Suppose that the problem was determined to be with the client hard-
ware. 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 prob-
lem, 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
Figure 18.2 The detailed portion of the cause-and-effect diagram associated with
client hardware failure.
1999 by CRC Press LLC
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 Acharacteristic or event of a system that the cause-
and-effect diagram is meant to study; typically, a problem or unde-
sirable 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 dia-
grams. 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 dia-
grams using Minitab for Windows is easy, but not very flexible. In SAS, use
the Ishikawa procedure.
1999 by CRC Press LLC
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.