Chapter 19

B. Root Cause Analysis

Use cause and effect diagrams, relational

matrices, and other problem-solving tools
to identify the true cause of a problem.
(Analyze)

Body of Knowledge V.B

Solving problems and preventing their recurrence are capabilities that reinforce
the importance of effective quality methods. Quality practices are used to inves-
tigate and improve quality deficiencies, plan for successful projects and business
commitments, and review resource constraints to identify inefficiencies. As the
problem-solving and troubleshooting experiences are incorporated into the over-
all quality program and organizational knowledge base, tollgates and validations
can be applied to processes in order to capture and report quality problems. This
helps to provide the input data needed for effective problem solving.
Problem solving can be summarized with a number of techniques, starting
with the eight discipline (8D) approach. This is generic and will be reinforced with
additional examples throughout the chapter:
1. Use a team approach. Pull together those who know the process, are
technically skilled and able to solve the problem, and have authority
within the organization to deploy the changes. Assign a champion to
drive the team to complete the steps.
2. Describe the problem. Use quality techniques and methods to describe
the problem and its impacts in objective and traceable terms. This will
support the prioritization and urgency of the resolutions and actions.
3. Start and check interim actions. This refers to the contingency and
troubleshooting steps needed to control the effects and potential
escalation of the problem under review.
4. Define and check root causes. After exploring potential root causes,
conduct tests or experiments to isolate the most direct causes. Conduct
additional reviews to confirm the correct root cause or investigate
potential interactions leading to potential problem recurrence.

338
 Chapter 19: B. Root Cause Analysis 339

5. Check corrective action. Confirm whether the corrective actions deployed

adequately address the problem without creating unintended side
effects or disruptions.
6. Start permanent corrective action. Upon confirming the suitability of
the corrective action, create or update affected control plans, process
references, procedures, and acceptance criteria. Support this with
training and knowledge transfer.
7. Stop future problems. Make the necessary modifications to those
portions of the management systems covering similar areas and
domains in order to prevent the same issues from recurring (that
is, extend additional controls for procurement of raw materials to
purchasing of finished goods and contracting of third-party services).
8. Congratulate the team. Give credit and recognition to those who
contributed to the solution and successful deployment. This will
reinforce maintenance and stimulate future involvement in
improvement activities.
The corrective action can be summarized in a framework of seven phases of cor-
rective action and related back to the PDSA cycle. This framework, along with
the 8D method summarized above, provides an incremental approach that can be
mapped to project plans and tasks. By following this structure, reasonable esti-
mates of time, resources, materials, and efforts can be derived.1

Phase 1: Identify the Opportunity (Problem

Identification)
Opportunities for improvement must be identified and prioritized, following
which the team and scope should be established. Problems that have the great-
est potential for improvement and the greatest need for solution can be identified
from different sources:
• Pareto analysis of recurring complaints (for example, field failures,
complaints, returns, scrap, rework, sorting, and the 100 percent test)
• Proposals from suggestion schemes
• Field study of users’ needs, competitive outcomes, and market
feedback
• Audit findings and observations of system auditors, government
regulators, and laboratories
• Surveys of customers, employees, and stakeholders
• Brainstorming and creative contributions
Three attributes should be present for a problem to be selected and prioritized:
1. Significant divergence from an established standard
2. Inconsistent impressions or assumptions and objective evidence
340 Part V: Improve Phase

3. Unspecified or unidentified root cause

Identifying problems for improvement is not difficult, as there often are many
more than can be analyzed. The quality council or work group must prioritize
them using the following selection criteria:
1. Is the problem important and substantial? Why?
2. Will resolving the problem contribute to the attainment of goals?
3. Can the problem be defined clearly using objective measures?
After identifying the problems, a corrective action team and team leader should
be selected to own the process improvement, establish goals and milestones, and
drive the efforts to completion.

Phase 2: Analyze the Current Process

In this phase process boundaries are defined specifying outputs and customers,
inputs and suppliers, and process flow. The levels of customer satisfaction and
measurements needed are determined to enable data collection and root cause
identification. This is best accomplished by developing a process flow diagram
and defining the relevant process measures while considering:
• Performance measures with respect to customer requirements
• Data needed to manage the process
• Feedback from customers and suppliers
• Quality/cost/timelines of inputs and outputs
The advantages of data collection include:
1. Confirmation of problems
2. Supportive facts
3. Measurement criteria for setting baselines
4. Ability to measure the effectiveness of an implemented solution
Data can be collected by a number of different methods, such as check sheets,
computers with application software, data collection devices like handheld gages,
or an online system.
Common items of data and information can be obtained from customers, sup-
pliers, designs, process outcomes, and analytics (that is, statistics, quality).
The cause-and-effect diagram is particularly effective in this phase. Determin-
ing all of the causes requires experience, brainstorming, and a thorough knowl-
edge of the process. Techniques used to verify root causes include:
1. Examine the most likely cause of problems
2. Validate data supporting the most likely cause
3. Distinguish what elements of the process change between controlled and
failed states
 Chapter 19: B. Root Cause Analysis 341

4. Subject the cause to scrutiny and challenges

5. Use experimental design, Taguchi’s quality engineering, and other
advanced techniques to determine the critical factors and their levels
6. Confirm with supporting data during verification steps
Once the root cause is determined, the next phase can begin.

Phase 3: Develop the Optimal Solution(s)

(Correction)
Upon obtaining the information, the project team begins its search for possible
solutions. Creativity and brainstorming on possible solutions requires creation,
combination, or modification of existing practices. Combining two or more pro-
cesses is a synthesis activity that relies heavily on benchmarking.
Once possible solutions have been determined, evaluation or testing of the
solutions comes next. Acceptance criteria include such things as cost, feasibility,
effect, resistance to change, consequences, and training. Solutions must prevent
reoccurrence and solve the problem.

Phase 4: Implement Changes

Changes are implemented using an implementation plan that describes the “who,
what, when, where, why, and how” of implementation. The implementation plan
includes the responsibilities, schedules, milestones, and monitoring activities
related to measurement approaches. Measurement tools such as run charts, con-
trol charts, Pareto diagrams, histograms, check sheets, and questionnaires are
used to monitor and evaluate the process change.

Phase 5: Study the Results

By collecting data and reviewing results, meaningful change and continuous
improvement can be achieved. By evaluating the results, the team can verify and
validate that the problem has been solved, or determine whether any unforeseen
problems have developed as a result of the changes. If the team is not satisfied,
then some of the previous phases will need to be repeated.

Phase 6: Standardize the Solution

(Recurrence Control)
Positrol (positive control) assures that important variables are kept under control.
It specifies the what, who, how, where, and when of the process and is an updat-
ing of the monitoring activity. Standardizing the solution prevents backsliding. In
addition, the quality peripherals—the system, environment, and supervision—
must be certified. Finally, operators need clear instructions for the particular pro-
cess, and cross-training within the process to ensure next-customer knowledge
and job rotation. Total product knowledge is also desirable.
342 Part V: Improve Phase

Phase 7: Plan for the Future (Effectiveness

Assessment)
Regularly scheduled reviews of progress must be conducted to identify areas for
future improvement and to track performance with respect to internal and exter-
nal customers. They also must track changing customer requirements. By incor-
porating process measurement and team problem solving in all work activities,
quality, delivery, and cost levels can be improved, and complexity, variation, and
out-of-control processes will be reduced. These lessons learned in problem solving
must be transferred to appropriate activities within the organization to improve
the knowledge base of the enterprise.

Corrective Action System

A corrective action system is needed to drive to the root cause of issues and for-
mally implement corrections to those issues.

Root Cause Analysis Methodology

Root cause analysis (RCA) is a methodology used to analyze a problem and put a
solution in place so that the problem does not happen again. The goal of RCA is
to determine and address the root cause of the problem. The methodology is the
corner­stone of continual improvement.
Problem solving and RCA are at the heart of the corrective and preventive action
(CAPA) process. The difference between corrective action and preventive action
is the timing of the problem. If the problem has already happened, the request
is called a corrective action, and RCA focuses on the root cause that allowed the
problem to happen in the first place. If the problem has not yet happened but is
likely to happen, the request is called a preventive action, and RCA focuses on the
root cause that could potentially allow the problem to happen. RCA is also con-
ducted in failure analysis, incident analysis, or near misses to investigate the root
cause of failures or incidents or determine the underlying weakness in a system
that could lead to a problem.2
The general methodology for performing RCA is:
1. Define and document the problem requiring RCA.
2. Understand the problem.
3. Collect and analyze data.
4. Determine the root cause(s).
5. Establish a corrective action plan.
6. Implement the corrective action plan.
7. Evaluate the effects of implementation to demonstrate that the root cause
of the problem was eliminated.
Some of the RCA methodologies in use include 8 discipline (8D) methodology, 5
whys, Six Sigma—DMAIC (define, measure, analyze, improve, control), and drill
deep and wide (DDW) (Ford Motor Company).
 Chapter 19: B. Root Cause Analysis 343

Some techniques used to uncover the root cause include:

• Value-added and non-value-added analysis
• Comparison of the as-is processes and the should-be processes
• Failure mode and effects analysis (FMEA)
• Change analysis (evaluating changes made that could potentially
affect the outcome)
• Barrier analysis (errors in prevention—why did the inspection fail to
capture the defect?)
• Prediction analysis (why did the organization fail to predict the
problem?)

Identify Root Cause

What is often called a problem is really only the “failure mode” or a symptom
reflecting the output from a failed process. The root cause of a problem, therefore,
lies in the input(s) and process itself. The necessary steps include identifying the
root cause, creating an action plan to address the root cause, implementing the
plan, and effectively closing out the corrective action or preventive action request.
Once the root cause has been identified, putting in the proper controls ensures
that the problem will not reoccur.

Cause-and-Effect Diagram (Fishbone Diagram)

Causes are the conditions that create the failure mode or problem. A cause-
and-effect (CE) diagram is a tool used to identify the many potential causes for an
effect, or the problem. Professor Kaoru Ishikawa is the father of the CE diagram.
The CE diagram has since become a basic quality tool used in conjunction with
other analytical tools to solve problems.
CE diagrams are also called Ishikawa diagrams or fishbone diagrams because the
resultant causes are shown on branches that, when completed, resemble the skele-
ton of a fish. Factors thought to cause a problem or result in an event are grouped
into categories, with the head of the fish depicting the problem or event. The goal
of a CE diagram is to identify all the probable causes and then select the most
likely ones for further investigation.3
Constructing a CE diagram:
1. Create a team of individuals who are familiar with the process,
problem, and other functions (for example, engineering and
maintenance if equipment related).
2. Define the problem (effect). Place the effect in the extreme right-hand
corner and draw an arrow with the head pointing to the effect.
3. Brainstorm and list all the possible causes that may contribute to
the problem.
4. Group the causes into categories and give each category a name.
344 Part V: Improve Phase

5. Begin constructing the diagram by drawing lines, or the bones of the

fish. Title the bones with the names of the categories.
6. Allocate the causes collected from the brainstorming activities into
the related categories. The completed diagram is known as the CE
(fishbone) diagram.
7. Circle any potential root causes on the CE diagram. The team can then
gather data to verify the most likely root cause(s).
While the standard structure of the diagram represents a fishbone, the number
and types of categories in which to group the potential causes are unlimited:
• Man
• Machine
• Material
• Method
• Maintenance
• Management
• Measurement
• Mother Nature
• Miscellaneous
Service industries typically use some variation of the eight P’s, or:
• Product (service)
• Place
• People
• Process
• Promotion
• Productivity
• Price
• Physical evidence
Or even the four S’s:
• Suppliers
• Systems
• Surroundings
• Skills
The fishbone diagram is often used in conjunction with the 5 whys. As potential
causes are identified, the 5 whys tool is used to drive to a deeper understanding
 Chapter 19: B. Root Cause Analysis 345

of the cause, and eventually reach the root cause. Additional enhancements to this
diagram can be applied to support more extensive analysis, including:
• Indicating whether the causes are controllable (within control,
minimal influence).
• Specifying those causes that are control factors or “noise” factors (that
is, secondary or tertiary influences).
• Differentiating the causes and defining candidates for subsequent
analysis (that is, design of experiments factors).

5 Whys
The 5 whys method asks the question, “Why does this problem exist?” or “Why
did this event occur?” five times, driving to a more detailed level with each
“why” to arrive at the root cause of the problem. Frequently, the root cause lies
with a system or process. The process is called 5 whys because one can usually
arrive at the root cause by asking “why” multiple times, usually at least five times
(and often more). The sequential progression and diagnosis of subsequent “whys”
becomes increasingly more intensive, diving more deeply into the root causes
contributing to the problem. Generally, by the fifth “why” question, the true gap
requiring resolution is revealed.

Is/Is Not Comparative Analysis

This method is a simple comparison that is intended to improve the precision
of the problem diagnosis, and refine the analysis to pinpoint the ranges or batches
where the defect source emerged (see Figure 19.1). Is/is not analysis can provide

Problem statement:
Is Is not Differences and changes
What What is the specific object What similar objects could
that has the defect? What have the defect but do not?
is the specific defect? What other defects could
be observed but are not?
Where Geographically? Physically Where, when, and what
on the part? size could the defect have
appeared but didn’t?
When When was the defect first
observed? When since
then? When in the product
life cycle?
Size How many objects have the
defect? How many defects
per object? Size of defect?
Trend?

Figure 19.1 Comparative analysis.

346 Part V: Improve Phase

insight into details and help to determine whether the defect is related to any
­special causes (that is, operator error, damages in shipping, deficient raw material).

Cause-and-Effect (X–Y) Relational Matrix

The cause-and-effect or X–Y relational matrix is used to quantify and prioritize the
impacts of causes (X) on effects (Y) through numerical ranking. This relational
matrix shows the impacts scores, which can be based on objective measures or
subjective ordinal values (see Figure 19.2). Additional weighting can be applied
to show those process inputs that have greater importance and should be more
closely analyzed. One potential use is to formally prioritize those causes that were
identified using the Ishikawa (fishbone) diagram.4

Root Cause Tree

This is a diagram that visually shows the connection between the failure effects
and the potential root causes and core problems. This hybrid approach combines
the fishbone and 5 whys methods, providing the ability to analyze interactions
among causes (see Figure 19.3). This analysis reflects an advanced category of

Rating of importance 10 6 9 8
to customer
1 2 3 4 5 6
Yield (accuracy)

implementation
Commonality
Efficiency

Change

Process inputs Total Percent

1 Customer input 8 6 8 8 252 11.36%
2 Equipment specs 8 5 10 8 264 11.90%
3 Bill of materials 7 5 10 5 230 10.37%
4 Number of revisions 8 6 10 8 270 12.17%
5 Label documentation 8 2 8 9 236 10.64%
6 Continuous/concentrated 5 3 2 2 102 4.60%
distribution drawings
7 Pre-critical control point 5 5 2 2 114 5.14%
meeting
8 Ownership 8 10 8 8 276 12.44%
9 Approval cycles 8 8 5 8 237 10.69%
10 AMK delays 8 8 5 8 237 10.69%
2,218

Figure 19.2 Cause-and-effect relational matrix.


Customer suffered a corrosion problem, Opportunity: Controllability Color code:
(SRA—Sulfur-related anion) and discovered a surge of sulfate with H: High C: Within control
our product. They suspect it’s the Being
M: Medium I: Have influence
primary contributor and want to know studied
L: Low N: No influence
the root cause and control.
Should
investigate

A. Understand the B. Internal C. SRA D. SRA introduced E. SRA Introduced

meaning and reliability measurement originated from during manufacturing after manufacturing.
of customer data. of SRA. original material. process.

C1. Lot SRA transforms E1.

to lot during Cross Product
What’s the The readings B1. Where do
variation. manufacturing. contamination absorbs
repeatability and are the we measure
H, N M, I when lines SRA
reproducibility calculated SRA, R&R? H, C shift products. over time.
(R&R) of customer sulfate
L, I H, I
data? L, N concentration
of product/ B2. Resin
B7.
resin? test. M, I During Bag
Sample
(surface B3. Test molding. contamination.
size. M, I

Chapter 19: B. Root Cause Analysis 347

What’s the only?) or the prime L, I L, C
correlation sulfate product? SRA
between concentration H, C During transforms
our data of test B6. Air cleaning. Exposing Contamination over time.
and their coupon/ quality. L, C to air. M, N through leaking M, N
data? L, N water? L, N M, C bag. L, I
B4. Test
cleaned
product? Resin absorb
Correlation doesn’t mean H, C Outside SRA from
causation. Is sulfate really cleanroom. air. M, C Product
the primary contributor? Cleaning releases
(Otherwise it might not help the B5. Test/ removes/ SRA
problem.) Need to work with monitor cleaning Inside Parts absorb SRA from absorbs over time.
customer and its data. M, I solution? H, C cleanroom. air inside cleanroom. M, C SRA. M, C L, I

Figure 19.3 Root cause tree example.

348 Part V: Improve Phase

analysis tools including fault tree analysis, event tree analysis, and current/future
reality trees. The root cause tree can be modified to show:
• “Or” relationships where only one of several causes can lead to
the effect
• “And” relationships where multiple causes are needed to occur
together for the effect to materialize
• Simultaneous effects, those that appear at the same time once the
causes have activated
• Codes indicating status, weighting, or activity
The root cause tree starts with the statement of failure effects at the top, progressing
to different approaches reflected in each “branch” to determine potential contrib-
uting causes. The color coding effectively draws attention to those areas or causes
where more action is needed. A corrective action team can map their priorities and
tasks against the boxes on the root cause tree to conduct a thorough and traceable
investigation. The boxes that are identified as having a high opportunity (H) or are
within control (C) are those that the team can directly address in order to have the
greatest impact to continual improvement and problem resolution.5

Failure Mode and Effects Analysis

Failure mode and effects analysis (FMEA) is described by AIAG as a systematic group
of activities intended to:
• Recognize and evaluate the potential failure of a product/process and
the effects of that failure
• Identify actions that could eliminate or reduce the chance of the
potential failure occurring
• Document the entire process
FMEA is included among the quality tools to diagnose and analyze the potential
root causes associated with the defined failure conditions of the product or pro-
cess under review. The details of FMEA examples are addressed in Chapter 3,
­Section 2 of this handbook.
The purpose of an FMEA is to:
• Understand the opportunity for failure and the impact of risks in a
product or process design
• Prioritize the risks
• Take actions to eliminate or reduce the impact of risks
Risk priority scores are tabulated based on severity, occurrence, and detection
­ratings, and mitigations must be determined and implemented for higher-risk
items. It is a good practice to revisit the FMEA and update it once the mitigation is
completed to reevaluate the risk and verify that all high-risk items are completed.
From these mitigations the root causes of failure can be addressed and resolved.