Key Elements for Effective

Root Cause Analysis &

Problem Solving

Presented by:

DIEGO CELY
Quality Improvement Advisor

What we will discuss. . .

What are problems

How problems are communicated: CREI statement
Types of problems and problem solving methods
Process View of problems
Isolating problems to their process of origin; establishing
context for Root Cause Analysis
Levels of Root Cause investigation
Data collection/analysis tools to apply at each level of
Root Cause investigation
Confirming root causes before applying solutions
Three possible solutions to each root cause
Getting the most out of Root Cause Analysis
investigations

Visual Definition of Problem

Gap between current
condition, (what is),
and the desired
performance level,
(what must be, should
be or could be)
This gap can exist in a
process, product or
system
A problem can only be
considered to be valid if
what should be is
specified

Where do gaps arise?

Customer complaint
Nonconforming output
of a process
Out of control process
Management systems
not being followed
Safety incidents
Environmental
releases
Goals not being
achieved
Can be actual,
potential or generated

Communication of Problems

CREI Problem Statement

A tool for communicating the gap:
Concern: what is wrong; statement of
nonconformity
Requirement: what should be;
documented requirement or reference to
Evidence: data demonstrating that
something is wrong; objective evidence
observed that supports statement of
nonconformity
(Impact): how significant is the problem
from a performance and/or cost standpoint

Concern
What is wrong?
What is different than
what should be?
May be recognized as a
symptom, (effect), or as a
failure condition, (failure
mode)
Define in terms of
requirement, (language of
organization)

Requirement
What should be
Must be defined and valid
Can be found in
procedures, policies,
drawings, specifications,
etc.
#1 reason problems are
not effectively solved is
that Requirement is not
clearly known or defined
Reference where
Requirement can be
found
State as defined in
Requirement document

Evidence
Demonstrates
requirement is not being
fulfilled
Data initially gathered
associated with problem
Objective evidence
collected while auditing
process or system
Must be verifiable
Can be tangible, a
statement of admission
or observed

Impact

How big is the problem?

How much does it cost?
Is the customer affected?
Is it affecting fulfillment of
organizational goals?
Refer to effect and severity
ranking on FMEA for
performance impact
Also consider cost impact
In the case of auditing findings:
typically, auditors do not cite
Impact as this could be viewed
as subjective
Impact should be determined
by auditee upon their review of
the audit finding

Utilizing CREI Format

Incorporate these fields on problem solving and
nonconformance report formats to prompt
complete recording of information re: problems
May require some investigation to identify
necessary information for completing CREI
statement, especially location and actual
statement of Requirement
Critical success factor to effective problem
solving is consistent and complete
communication of problem condition

Problem Categories
and Problem Solving Approaches

Types of Problems
Simple, cause
known; Just do it
issues
Complex, cause
unknown; need to
dig deeper issues
Sometimes the
financial impact of a
problem dictates
how it will be
classified

Just Do It Issues
Typically isolated, sporadic incidents
Are easily fixed; apparent cause tends to be
known
Often recognized during process planning
and reflected in PFMEA
Addressed through troubleshooting,
(diagnosis and remedy) and reaction plans
on control plans, (control of nonconformity)
Can be fixed by process owner; addressed
at process level
Occurrence should be monitored ongoing
for cost and impact

Troubleshooting

Dig Deeper Issues

Sometimes referred to as Chronic

Long-term and/or complex issues
Cause is not readily apparent, unknown
Require in-depth investigation to identify root cause
Addressed through root cause analysis,
disciplined problem solving and improvement
process
Source of problem typically unknown
Cross-functional participation needed to solve
Effective resolution requires both process and system
solution consideration
Require management intervention via resource
commitment
When available data re: problem is limited, may be
handled as Just do it based on impact and/or risk

Steps in Disciplined Problem Solving

1. Establish Team
2. Operational Problem Definition
3. Containment & Interim Actions, (if
needed)
4. Root Cause Analysis, (process &
system)
5. Plan & Implement Solutions
6. Results of Solutions
7. Verification, (including independent)
8. Closure & Congratulate the Team

Problem Type Considerations

Just Do It
Reflects product or
process controls
established when
planning the process
Management decision to
live with such conditions
based on acceptable level
of risk
Should be routinely
evaluated for cost and
impact
Can only be eliminated by
applying disciplined
problem solving to
understand true root
cause in order to improve
process

Dig Deeper
Unanticipated
conditions which occur
May also be anticipated
issues for which actual
level of risk is now
determined to be
unacceptable
Require concentrated
investigation to
understand source of
problem and process
factors leading to
problem condition to
allow appropriate
solutions

A Note about Fire-fighting!

Fire-fighting is essentially unprescribed actions taken on a
process without
understanding the relation of
causal factors and process
output
Fire-fighting is dangerous as
these actions tend not to be
specifically focused to a
particular cause
The resulting impact of firefighting is typically not known
ahead of time
Therefore, chaos is
introduced into the process
A very high-risk approach to
problem solving!

Problem Type Considerations

Problem
Type

Process of
Origin

Method

Considerations

Just do it

Known

Troubleshooting;
rework

Seen before; can

live with impact
when problem
recurs

Dig Deeper

Unknown

Root cause
analysis

Data-driven
investigation to
determine actual
factors causing
problem condition

Unknown

Fire-fighting

Taking action
possibly on wrong
process; not using
data to confirm
root cause

Prioritize Problems

Most organizations should

only be actively working on 35 disciplined problem
solving efforts, (Dig Deeper
issues), at a time to balance
the use of resources and get
the most effective solutions;
(no one person should be
working on more than 2 Dig
Deeper teams at any given
time)
Impact portion of CREI
statement facilitates
prioritization of problems for
allocation of problem solving
resources
Management is responsible
for establishing the priority

Process View of Problems

The Secret to Solving

Problems

The source of every problem is a process: typically the

gap is found in the output of the process
The cause of every problem is one or more process
factors not behaving as they should
Understanding the relationship between process factors
and process outputs is important to effective problem
solving
Data about the process and the problem is required to gain
enough understanding to effectively solve any problem
The result of any problem solving effort is increased
knowledge about processes and their outputs

Components of Process
Environment
(space, layout, etc.)

Input
(Materials)

Evaluation
(plan, gages, etc.)

Process steps
(Methods)

Equipment
(selection,
Maintenance, etc.)

Actual Output
(Desired outcome:
targets, goals, specs)

People
(training, skills)

Management Policies & Practices

What are the Process Factors?

Processes are mainly
influenced by:
Man
Material
Machine
Methods
Mother Nature,
(environment)

Other factors which

influence processes
include:
Measurement
Management System,
(policies including
SOPs, targets,
operational decisions)
Money
Other?

Process View
Products/Services = output of producing Processes

Producing Processes to accomplish Plans

Planning Processes apply System

to fulfill customer requirements

System Processes = Policies, Objectives & Practices

(how an organization does business)

Main Functions of Problem Solving

Define Gap between what
is and what should be
Identify process of origin
from which gap is originating
Study the process of origin
to determine which process
factor(s) are causing the gap
Analyze the relationship
between process causal
factors and system factors to
identify root cause

Getting to the Process of Origin

Where was the problem found?
Where is the first process the problem
condition could occur?
Go to these and any processes in
between to collect data recognizing where
the problem is actually first observed; this
is the process of origin!
Use a process flow diagram to make this
investigation visual.

Is/Is Not Analysis

Also known as Stratification Analysis
Provides further detail about the problem so a
complete operational definition of the problem
can be formulated.
Used at this stage as well as in applying
interim/containment actions and
implementing/verifying permanent actions.
Splitting the dictionary or 20 questions to
the answer demonstrates this idea of
problem convergence

Use Data to determine

What is the problem? define the problem condition such
that anyone could recognize it; basis for data collection
about the problem
Where is the problem occurring? which processes,
customers; also, where on the output is the problem
condition observed?
Who knows about the problem? who initially identified the
problem? Who else has seen this problem? Who is
involved in the process steps reflected in the process flow?
When did the problem begin? timeline associated with
when the problem was seen; can be applied even for
ongoing problems
How big is the problem? how much output is affected?
Narrows the problem focus to isolate the problem to its
process of origin
Data is collected to demonstrate answers to these questions

Applying Is/Is Not Analysis

Clarify aspect what question needs to be answered to
obtain a better understanding of the problem
Identify what data to collect that would assist in answering
the question
Determine where that data can be obtained
Decide how to go about collecting the data; what
tools/methods to apply
Go collect the data
Review and analyze the data to draw a conclusion re:
questions being posed
This is an important step in Root Cause Analysis as the
results of this investigation provide a context for the root
cause investigation
By conducting Is/Is Not Analysis, it is also possible to
determine if further investigation can take place at this time

Components of Problems
Operational Definition
Basis for root cause investigation
More detailed version of CREI statement based on
what was learned from Is/Is Not
Indicate process from which problem
originated/generated
Indicate direction of problem related to requirement
Define extent of problem
Possibly isolates problem to a certain timeframe
Include refined information re: impact
Problem statement must be clear, concise and
understandable by anyone

A Root Cause is. . .

A process factor which directly defines

the reason for the problem when it is
present and is having an influence on
the process and its output.

4 Levels of Root Cause

Defect/Detection Cause = Product level

Direct Process Cause = at Process of Origin

Actual Root Cause = previous process factors
contributing to Process Root Cause, (planning)
System Root Cause = management system
policy/practice contributing to Actual Root Cause

Dig! How Deep?

Management decides
on depth of root
cause investigation
through the
establishment of
SMART goals for
each problem solving
effort.

Problem Solving Goals

Define problems
boundaries/depth of
solutions
Identify right people to
solve problem
Establish measures of
end results
Develop plan of how to
accomplish the goal
Tie problem solving
goals to organizational
objectives/targets
Provided to team by
Management

Effective Problem Solving is

based on
SMART Goals:
Specific
Measurable
Agreed upon by team as
attainable
Relevant to organization
and results-oriented
Timing defined

Root Cause Analysis

Systematic investigation
of a process to identify
the root cause of the
gap, and take corrective
action to eliminate the
gap and keep it from
occurring again in the
future
A structured investigation
that aims to identify the
true cause of a problem,
and the actions
necessary to eliminate it.

Process Cause vs. System Cause

Process Cause
What factor of the
process of origin is
triggering the undesirable
output
What other processes
and their factors are
causing the trigger?
Relates product output,
(symptom), to process
parameters, (causes)

System Cause
Addresses how the
management system
allowed the process to
become out of control
Relates process factor
causes to weaknesses
in management systems
policies/practices

Process
Root Cause Analysis
Disciplined Problem
Solving

Identify process
from which
problem originated

4/8/2007
Review data from
operational
definition,
containment and
interim action

Identify potential
causes
contributing to the
problem

Develop plan to
test if potential
cause actually
leads to problem

Conduct test and

collect data

Analyze data from

test

Select other
potential causes

No

Does potential
cause directly
lead to problem
condition?
Yes

Identify possible
actions to monitor
process for
problem condition

No

Can cause be
controlled or
eliminated?
Yes
Identify possible
actions for either
controlling or
eliminating cause

System
Root Cause Analysis
Disciplined Problem
Solving

Identify
management
policies related to
process from
which problem
originated

4/8/2007

Review existing
policies for existing
controls

Identify possible
management
policy controls to
address cause

No

Do current policies
define controls to
prevent the cause of
the problem?

Yes
Investigate if these
controls are in
place

Identify how these

controls and/or
policies can be
changed

No

Controls
working?

Yes
Analyze why
controls are not
working at the
process where
problem originated

Identify other
processes affected
by these policies

Root Cause Analysis Levels

Level

Root Cause

Consideration

Tools

Other
(Wide)

Product

Defect/Detection
cause

Condition of
controls to
detect problem

Control
Barrier
Analysis

What other
products have
similar
controls?

Process

Direct process
cause, (trigger at
process of origin

Factors at
process of
origin triggering
problem, (5Ms)

Fishbone,
(cause &
effect)

What
processes
have similar
trigger cause?

Plan

Actual root cause,

(led to trigger
cause)

Linkage to
planning
processes that
trigger cause

5 Why with
Hypothesis
testing

What other
processes
affected?

System

weakness in
mgt. policies or
practices

Linkage of mgt.
system to
actual cause

System
Cause
Analysis

(Deep)

Other affected
mgt. policies

Control Barrier Analysis

(Defect/Detection Root Cause)
How did the problem
escape the process
and/or organization?
Was the problem
anticipated in advance?
Were controls defined
to recognize and
contain the problem?
At which process are
the planned controls
applied?

Were the planned

controls in place?
Were the planned
controls working?
What is the capability
of these controls?
Assists in identifying
appropriate interim
actions as well as
identifying the
defect/detection root
cause

Control Barrier Analysis Worksheet

Results of Control Barrier Analysis

May recognize missing controls or controls not working as
planned
Interim actions represent solutions to addressing these
concerns but should not be accepted as the permanent
solution
When the results of this analysis uncover additional
problems, refer these to the team champion for direction on
addressing
Teams main focus at this point is to implement some type
of control to protect downstream processes from continuing
to experience the problem
Solutions based on this level of root cause investigation
mainly are reactive in nature; they only improve our ability
to detect the problem condition but dont typically do
anything about addressing the root cause!

Direct Process Cause

Relates one or more factors of the affected
process, (process of origin), not behaving as
required to obtain the desired output result at
that process
Use Cause & Effect diagram, (fishbone
technique)
Direct process causes, (trigger causes), are the
starting point for identifying root cause
Some action may be required to address the
direct process/trigger cause but actions should
not be taken until actual root cause is known

Cause & Effect Diagram

Apply to problems
process of origin
Gap is head of fish
Major cause categories
5Ms
Potential causes
brainstormed are
process factors existing
at the problems
process of origin
Define potential causes
specifically
When confirmed, these
will be known as direct
process/trigger causes

Fishbone Diagram

Fishbone Process
Involve personnel from process of origin in
brainstorming of potential causes at the process of
origin triggering the problem
Develop a sketch/list of the process factors, (man,
material, machines, methods, mother nature), related
to the process of origin
After brainstorming, review each identified cause to
establish:
If the cause is actually a factor at the process of origin
If the cause makes sense based on the operational definition
of the problem

Prioritize remaining causes as to their possible

contribution to the problem condition
Develop hypothesis test to evaluate each potential
cause at the process of origin

Direct Process Root Cause

Investigation Plan & Results
Process of Origin:

Problem Understanding Tools

(especially useful in identifying system causes)

Task Analysis reviews process in detail;

helpful for operator dependent process
Change Analysis identifies differences;
extension of Is/Is Not analysis; expands
on application of timeline
Both these tools must be applied with a
location context, (process of origin)

Task Analysis Worksheet

Change Analysis Worksheet

Actual Root Cause

Explains why trigger cause/condition exists at
the process of origin of the problem
Typically found in previous planning processes
Many problems have multiple causes
Usually only one over-riding cause that when
addressed, can significantly reduce the
problems impact on the organization
Very complex problems may have interacting
causes but these are typically viewed as isolated
problems that only repeat infrequently, (often
managed as Just Do It), until resources allow
necessary time to discover interaction through
data collection, analysis and experimentation

5 Why Analysis

Ask Why does this

happen? for each identified
process cause from Cause &
Effect diagram
Differentiates between
process, (direct) cause and
underlying root cause
Each level of causes
identified in 5 Why analysis
must also be confirmed via
testing in order to verify root
cause
Deeper levels of 5 Why
Analysis which get into
Planning processes will
require interview-type data
collection

Test Potential Root Causes

Validating cause
guesses by
collecting and
analyzing data
Test under controlled
conditions
Turn the problem on
and off by
manipulating the
suspected cause

Hypothesis Testing
Design hypothesis and select methods for testing
hypothesis - state how potential cause could result
in described problem; decide what data to collect that
would prove potential cause; establish acceptable
risk of decision outcome; determine sample size;
develop action plan for study
Prepare to test hypothesis - organize and prepare
materials required to conduct study; collect data
during study
Analyze results of test - analyze data using
appropriate statistical tools, (t, F, Chi-squared tests)
Interpret results - conclusions from study; does data
establish potential cause as reason for problem?

Root Cause Analysis Plan

Identify causes to be investigated
What data supports each cause?
Can cause be introduced and removed to
confirm presence/absence of problem?
What tests will be performed to confirm root
cause?
What is the statistical confidence of these
tests? (i.e. how much data is needed?)
Results of tests recorded and analyzed with
conclusions drawn

System Causes
What in the system allowed this problem/cause
to occur
Identifies why the process root causes occurred
based on current management policies/practices
Often not readily measurable
Data obtained through interview
By identifying system causes, systemic
improvement can be made in order to prevent
recurrence of problem in other similar processes
Typically addressed once process root causes of
problem are known and confirmed

Problem Solutions
There are always at least
3 possible solutions
related to each level of
cause
Therefore, at least 12
possible solutions could
be identified for a
problem investigation if all
levels of cause are
investigated!
Management provides
solution selection criteria
as basis for evaluating
possible solutions

3 Possible Solutions
Eliminate root cause preventive control; often
referred to as error-proofing; eliminates causal factor
leading to problem condition
Control root cause process detective control;
implement actions to monitor cause condition so
action can be taken on process factor before problem
occurs
Do nothing reactive control; continue
monitoring for problem condition; defect detection
solution; may be required when root cause cant be
eliminated or controlled economically or technically;
this solution may include accepting interim action as
permanent solution

Solution Selection
Allow brainstorming of possible solutions at all
levels of confirmed causes and the 3 possible
categories of solutions
Then apply solution selection criteria provided by
management to evaluate each possible solution
as well as refine the brainstormed ideas
Have data available re: actual costs associated
with problem, (initial impact, revised impact
based on data collection/analysis, anticipated
future impact if no action is taken)

Implementing Solutions
Actions to eliminate
and control causes
require change
Change management
tools should be
applied when
implementing
solutions

Change Management
Tools
FMEA
Risk assessment
Resource planning
Contingency planning
Training
Evaluation
Verification

Plan, Implement
& Verify Solutions

Brainstorm
possible solutions
for each confirmed
root cause
Permanent
solution
implementation

4/8/2007
Establish solution
selection criteria

Evaluate results of
permanent
solution
Evaluate possible
solutions vs.
solution criteria
Remove interim
actions
Develop action
plan to implement
selected solutions
Team verification
of solution vs.
goals
Evaluate solution
risks and impact
on other
processes

Independent
verification of
problem solving
effort

Develop
contingency plan
for solutions
Finalize problem
solving report,
lessons learned
Establish solution
effectiveness
measures
Team celebration
and disbanding of
problem solving
team
Trial plan for
solution
implementation

Evaluate trial plan

results

Revise solution
implementation
plan as necessary

Other Opportunities
Identified typically while collecting data for Is/Is Not
Analysis, Root Cause investigation/confirmation, solution
evaluation
Record these other problems/opportunities
Share these problems/opportunities with team champion
to get direction on how to address: (change scope of
current problem solving effort to include; management
assigns another team to address)
Dont allow these other opportunities to distract from the
focus of the problem solving effort
These Other Opportunities become the Bonus of an
effective problem solving effort

A Key Outcome of Every Problem

Solving/Root Cause Investigation. . .

Expansion of Knowledge

Failure Modes & Effects Analysis

(FMEA) A Tool for Cataloging Problems
Process
Function
Requirements

Potential
Failure
Modes

Potential
Failure
Effects

Potential
Failure
Causes

Current
Product &
Process
Controls

Process of
origin

Technical
definition of
problem

Symptom

Process
factors = root
causes

Interim
actions

Managements Role

System
Establish problem solving
culture
Provide problem solving
process
Ensure training of all
personnel in problem
solving process and related
tools
Prioritize/categorize
problems based on
magnitude/risk
Audit/review effectiveness
of problem solving system

Each Problem
Appoint Team Champion
Define SMART goals for
problem solving effort
Provide resources and time
to support problem solving
team
Establish solution selection
criteria
Authorize Team Plan as
contract for problem solving
effort
Periodically review progress
of problem solving teams

Problem Solving Culture

Problem solving is a value-added process
Problem solving supports improvement of
every aspect of the business
Time should be dedicated to problem
solving on a daily basis
Everyone in the organization is involved
in problem solving
Use problem solving survey to measure
effectiveness of problem solving system

For Further Information, you

are welcome to contact
DIEGO CELY
Quality Improvement Advisor
(786) 979-3237
dcely2007@gmail.com