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 Categories and 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
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
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 Management Policies & Practices Process steps
(Methods)
Input
(Materials)
Actual Output
(Desired outcome:
targets, goals, specs)
Equipment
(selection,
Maintenance, etc.)
People
(training, skills)
Environment
(space, layout, etc.)
Evaluation
(plan, gages, etc.)
Management Policies & Practices

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.

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

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 Problem’s 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 Defect/Detection Cause = Product level
System Root Cause = management system
policy/practice contributing to Actual Root Cause
Actual Root Cause = previous process factors
contributing to Process Root Cause, (planning)
Direct Process Cause = at Process of Origin
Defect/Detection Cause = Product level

37. Dig! How Deep?
Management decides on depth of root cause investigation through the establishment of SMART goals for each problem solving effort.

38. Effective Problem Solving is based on
Problem Solving Goals
Define problem’s 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
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

43. Root Cause Analysis Levels
(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
Team’s 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 don’t 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 problem’s process of origin
Gap is head of fish
Major cause categories – 5M’s
Potential causes brainstormed are process factors existing at the problem’s 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

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

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 can’t 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)

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

69. 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)
Don’t 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. Management’s 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

76. For Further Information, you are welcome to contact
Cathy Fisher
Quality Improvement Strategies
(704)