Key Elements for Effective Root Cause Analysis

1
Key Elements for Effective Root Cause Analysis
Problem Solving

• Presented by
• Cathy Fisher
• Quality Improvement Strategies

2
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

3
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

4
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

5
Communication of Problems
6
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

7
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)

8
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

9
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

10
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

11
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

12
Problem Categoriesand Problem Solving Approaches
13
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

14
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

15
Troubleshooting
16
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

17
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

18
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

19
A Note about Fire-fighting!

• Fire-fighting is essentially un-prescribed
  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 fire-fighting is
  typically not known ahead of time
• Therefore, chaos is introduced into the process
• A very high-risk approach to problem solving!

20
Problem Type Considerations
Problem Type Process of Origin Method Considera-tions
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
21
Prioritize Problems

• Most organizations should only be actively
  working on 3-5 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

22
Process View of Problems
23
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

24
Components of Process
25
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?

26
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)
27
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

28
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.

29
(No Transcript)
30
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

31
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

32
(No Transcript)
33
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

34
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

35
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.

36
4 Levels of Root Cause
37
Dig! How Deep?

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

38
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

39
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.

40
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

41
(No Transcript)
42
(No Transcript)
43
Root Cause Analysis Levels
Level (Deep) 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 Other affected mgt. policies
44
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

45
Control Barrier Analysis Worksheet
46
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!

47
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

48
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

49
Fishbone Diagram
50
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

51
Direct Process Root Cause Investigation Plan
Results
Process of Origin
52
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)

53
Task Analysis Worksheet
54
Change Analysis Worksheet
55
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

56
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

57
(No Transcript)
58
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

59
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?

60
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

61
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

62
(No Transcript)
63
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

64
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

65
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)

66
(No Transcript)
67
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

68
(No Transcript)
69
Other Opportunities

• Identified typically while collecting data for
  Is/Is Not Analysis, Root Cause investigation/confi
  rmation, 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

70
A Key Outcome of Every Problem Solving/Root Cause
Investigation. . .

• Expansion of Knowledge

71
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


72
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

73
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

74
(No Transcript)
75
(No Transcript)
76
For Further Information, you are welcome to
contact

• Cathy Fisher
• Quality Improvement Strategies
• [phone]
• cathyf2_at_earthlink.net