1. Root Cause Analysis Course
Introduction
This course is designed to give you an overview of Root Cause Analysis and how it can improve company performance.
This class is best taught using your company’s specific examples, allowing for interaction among the students
Feel free to modify and change this course any way you like. Simply click
View  Master  Master Slide
to edit the master slide so that all slides show your company logo and name. You may also teach it exactly as it is. We recommend about 4 hours to teach the course.
This course is intended to teach an individual or group with no prior knowledge of root cause analysis, as well as provide the knowledgeable individual an excellent review of the concepts. We recommend that someone with prior experience and training with root cause analysis teach the course. If not being used as a course, valuable information can still be obtained by following through the presentation.

2. Problem Solving Process Examples Root Cause “Hints” Review
Course Content
Course Objectives
What is Root Cause?
Benefits
Problem Solving Process
Examples
Root Cause “Hints”
Review
Additional Resources
Here is an overview of the course content.
We will review the definition of root cause,
the benefits of performing root cause analysis,
review a recommended problem solving process that contains the root cause analysis step,
provide examples of problems addressed to root cause,
things to keep in mind when performing this analysis,
And finally a summary review of the course

3. Upon completion of this course, participants should be able to:
Course Objectives
Upon completion of this course, participants should be able to:
Understand the importance of performing root cause analysis
Identify the root cause of a problem using the problem solving process
Understand the application of basic quality tools in the problem solving process
Upon completion of this course, participants will be able to:
Understand the importance of performing root cause analysis
Identify the root cause of a problem using the problem solving process
Understand the application of basic quality tools in the problem solving process

4. What is root cause?
ROOT CAUSE =
The causal or contributing factors that, if corrected, would prevent recurrence of the identified problem
The “factor” that caused a a problem or defect and should be permanently eliminated through process improvement
The factor that sets in motion the cause and effect chain that creates a problem
The “true” reason that contributed to the creation of a problem, defect or nonconformance
Root cause definitions. Feel free to add your own

5. What is root cause analysis?
A standard process of:
identifying a problem
containing and analyzing the problem
defining the root cause
defining and implementing the actions required to eliminate the root cause
validating that the corrective action prevented recurrence of problem
Root cause analysis is part of a complete corrective action process. Getting to root cause is only half the battle. Preventing the root cause requires many more additional steps

6. Less rework = Increased profits!
Benefits
By eliminating the root cause…
You save time and money!
Problems are not repeated
Reduce rework, retest, re-inspect, poor quality costs, etc…
Problems are prevented in other areas
Communication improves between groups and
Process cycle times improve (no rework loops)
Secure long term company performance and profits
Here are the benefits for why your company should take the time, on every problem, to analyze down to the root cause $$ $$
Less rework = Increased profits!

7. When should root cause analysis be performed?
When PROBLEMS occur !!
Supplier Defects
Out of Control Process
Excess Inventory
Computer issues
Scrap Problems
medical errors
Human Error
Audit Finding
When should we perform root cause analysis?
All the time!
When you do not dig deep enough into the detail of these problems, you should expect them to continue to reoccur time and time again
Add your company lingo and terminology!
Missed Deliveries
Safety Issues
Machine Defects
Overspending Budget
Workmanship Defects

8. How does it differ from what we do now?
USUAL APPROACH
Problem Identified
Firefighting! Immediate Containment Action Implemented
Problem reoccurs elsewhere!
PREFERRED APPROACH
Here is the usual versus preferred approach to problem solving.
In most companies, when a problem surfaces, we firefight and try to put out the “fire” immediately. This involves some kind of quick fix or work around to keep the process moving. Just as we find an acceptable “band aid” fix that works, another “fire” starts somewhere else and we rush to fix it.
We never take the time to revisit these “fires” to figure out why they happened in the first place. We keep dealing with the same problems over and over again.
The preferred approach is similar. First, we develop a quick fix for the problem. However, instead of rushing to the next issue of the day, we take some extra time to do root cause analysis so that same problem is not tomorrow’s big “fire”
We then implement the process change and check to see that is does not return, we institutionalize the solution so other areas and groups do not have the same problem as well.
Which one of these approaches will take longer to complete?
Obviously the preferred approach will take much longer, so why should we take the time? We must think in the long term. In six months or a year from now, do we want to be dealing with the same number of problems as we are today, or do we want to have more time available to work on improving the process and other value added activities.
Immediate Containment Action Implemented
Defined Root Cause Analysis Process
Solutions validated with data
Solutions are applied across company and never return!
Problem Identified

9. State the problem in terms of dollars!
Money Talks
State the problem in terms of dollars!
Determine how much each occurrence of the problem costs the company
$$$ speaks the language of management
Justifies any spending on root cause analysis and corrective actions
Prioritizes financial impact of problems
If the problem is not stated in terms of money, you will have a harder time convincing management that it is worth fixing. It will also help you prioritize problems that have the biggest impact financially. Typically, we go after the most frequent problems, and we may be missing those infrequent problems that really hurt the company financially.

10. “Customer” can be Internal or External
How does it work?
Defect found at “Customer”…
PROCESS A
PROCESS B
PROCESS C
PROCESS D
Here is a basic example of how to attack a problem with the problem solving process. These are television sets with a defective screen that escapes to the customer. Customer can be used as the internal customer (another process area) or the typical external customer (who pays for the product or service)
CUSTOMER
“Customer” can be Internal or External

11. Nothing is allowed to further escape to the customer
How does it work?
Contain the problem…
PROCESS A
PROCESS B
PROCESS C
PROCESS D
Contain the problem. Make certain that the group (customer in this case) that finds the problem does not see it again!
CUSTOMER
Nothing is allowed to further escape to the customer

12. Nothing is allowed to further escape to the next process
How does it work?
Contain the root process…
PROCESS A
PROCESS B
PROCESS C
PROCESS D
Once we better understand where the problem originates, we isolate our containment around that process, and allow the other processes to operate normally. These processes should not see the problem return.
CUSTOMER
Nothing is allowed to further escape to the next process

13. Prevent the problem… How does it work?
PROCESS A
PROCESS B
PROCESS C
PROCESS D
Finally, once root cause is determined and prevented through process changes, the containment efforts should be lifted and the new process should no longer create defects resulting from the same root cause.
CUSTOMER
Corrective action implemented so root cause of problem does not occur again!

14. 3 types of Corrective Action:
Corrective Actions
3 types of Corrective Action:
Immediate action
The action taken to quickly fix the impact of the problem so the “customer” is not further impacted
Permanent root cause corrective action
The action taken to eliminate the error on the affected process or product
Preventive (Systemic) root cause corrective action
The action taken to Prevent the error from recurring on any process or product
There are three types of corrective actions.
Immediate is the action done to “stop the bleeding”
Permanent is typically done on a specific area or product to prevent the root cause from recurring. This is where most companies stop.
Preventive is changing the process so that problem does not reoccur again in that area, or any other area in the future. This forces departments and groups to break down walls and communicate for the good of the company.

15. Examples of Corrective Actions
Immediate (step #3)
All current batch of paperwork re-inspected by another worker for same type of problem
Permanent (step #5)
Form changed to mandate completion of certain fields
Preventive (step #5)
Here is an example of a transactional process, showing the three types of corrective action
If there is a documentation error, the immediate action is the re-inspection of the paperwork for that specific error. This might also include reworking the document to get it back to an acceptable condition
The permanent action is the changing of the form so that it cannot proceed without the correct information going to the document.
The preventive action is the mistake proofing of all similar processes so that the error cannot be made again in the future
Similar forms with same fields used all over in company are changed to “mandatory”
If preventive not addressed, problem will return!!

16. Examples of Corrective Actions
Immediate (step #3)
Part removed and replaced in product, retested
Permanent (step #5)
Product redesigned to account for part variability
Preventive (step #5)
Here is another example…
Design process changed to require variation analysis testing on similar supplier parts
If preventive not addressed, problem will return!!

17. The Difference between Permanent vs. Preventive Corrective Actions
Made training a requirement to new employees working in that area
Changed design guidelines to not allow for use of part in full scale production
All documents that are critical to project are identified with red folders
Check for those software bugs added to checklist and performed prior to release of software
Process developed to identify “at risk” patients for falls who require assistant
Ethics training developed and provided to all employees
Permanent
Trained employee on proper machine use
Changed product design to make parts easier to assemble manually
Specific customer document critical to project is identified with red folder
Update all customers with latest software revision to fix problem
Fallen patient given full-time assistant to provide help moving around hospital
Employee fired for ethical violation
Here are some more examples of the difference between Permanent versus Preventive. Class attendees should start to see what we mean by root cause. Feel free to add your own company examples.

18. Problem Solving Process1
Validate
Follow Up Plan
Complete Plan
Action Plan
Root Cause
Immediate Action
Identify Team
Identify Problem
Problem Solving Process 8 2 3 7
A common, simple and highly recommended 8 step problem solving process.
NOTE: This graphic is used on other slides, so if you customize this graphic, you will have to make changes to the other process steps, or remove those smaller graphics 6 4 5

19. Clearly state the problem the team is to solve
Step #1 1 8 2 7 3 6 4 5
Identify the Problem
Clearly state the problem the team is to solve
Teams should refer back to problem statement to avoid getting off track
Use 5W2H approach
Who? What? Why? When? Where? How? How Many?
Very important!
The first, and one of the most important steps, is to identify the problem to address. Meetings can be drawn out and lose focus when the problem is unclear. It is very easy for teams to use the meetings as opportunities to address other issues at the same time.
The 5 W’s and 2 H’s approach can help you get there. Simply answer the who, what, where, when, why, how, and how many to help better define the problem.

20. 5W2H Step #1 Who? Individuals/customers associated with problem8 2 7 3 6 4 5
5W2H
Who? Individuals/customers associated with problem
What? The problem statement or definition
When? Date and time problem was identified
Where? Location of complaints (area, facilities, customers)
Why? Any previously known explanations
How? How did the problem happen (root cause) and how will the problem be corrected (corrective action)?
How Many? Size and frequency of problem
A description of the 5W2H questions

21. Step #2 1 8 2 7 3 6 4 5
Identify Team
When a problem cannot be solved quickly by an individual, use a team!
Should consist of domain knowledge experts
Small group of people (4-10) with process and product knowledge, available time and authority to correct the problem
Must be empowered to “change the rules”
Should have a designated Champion
Membership in team is always changing!
In most cases, a team of affected individuals should be brought together to discuss the issue. Problems can arise when the right people are not involved.
Try and keep the team between 4-10 people. More than that can slow down the process
It is recommended that the team assigns a “Champion” to oversee the problem until it is resolved. They may play an active role in the discussions, or simply make certain the teams are meeting and that progress is being made. May also be responsible for taking issues up to leadership
As the problems become more defined and analysis starts to drive the team in one direction, it is normal for the team members to change. Initially, step 1 will have the most team members, and towards the end of this process, maybe only one or two people are still actively working the issue. During the root cause analysis step, new members may be asked to participate based on their expertise in a certain area.

22. Key Ideas for Team Success
Step #2 1 8 2 7 3 6 4 5
Key Ideas for Team Success
Define roles and responsibilities
Identify external customer needs
Identify internal customer needs
Appropriate levels of organization present
Clearly defined objectives and outputs
Solicit input from everyone!
Good meeting location
near work area for easy access to info
quiet for concentration and avoiding distractions
The following are keys to success for working in a group. The first one is defining roles and responsibilities. Each member must know what they are expected to “bring to the table”. This assures the team that all needed areas are adequately covered before beginning.
The second note is to identify external customer needs. What outputs and results are expected from the customer, and how will they be communicated (at the end of the project, during, only when needed?)
Identify internal needs. What processes and procedures need to be followed, and what systems are available or required. This may include a corrective action process.
Without the appropriate levels of management supporting the effort, the team will have a hard time implementing any actions or activities that will result from the teams effort
Clearly defined objectives and outputs are essential, otherwise the team may try to attack issues outside the scope of the analysis or get sidetracked by other problems that each group may want resolved.
If all members are not involved in the discussions, there will be less buy-in to the resolution. Identify members who are not participating and ask for their opinions. Try to prevent certain individuals from dominating the discussion.
Good meeting location may not make the team perform any better, but will prevent other distractions and issues that can really impact the teams success

23. Roles and Responsibilities
Step #2 1 8 2 7 3 6 4 5
Roles and Responsibilities
Champion: Mentor, guide and direct teams, advocate to upper management
Leader: day-to-day authority, calls meetings, facilitation of team, reports to Champion
Record Keeper: Writes and publishes minutes
Participants: Respect all ideas, keep an open mind, know their role within team
The following is a list of roles and responsibilities

24. Immediate Action Step #3 Must isolate effects of problem from customer1 8 2 7 3 6 4 5
Immediate Action
Must isolate effects of problem from customer
Usually “Band-aid” fixes
100% sorting of parts
Re-inspection before shipping
Rework
Recall parts/documents from customer or from storage
Only temporary until corrective action is implemented (very costly, but necessary)
Must also verify that immediate action is effective
The third step is to address the immediate action needed to keep the problem from spreading any further.
Often times, this involves some sort of band-aid, or containment effort, such as: sorting of parts or paperwork, re-inspection, rework, or recall
Whatever immediate action is done, it should only be temporary, and not stay in place after the root cause has been corrected.
A check should also be made to see that the containment and immediate action actually kept the problem from spreading any further

25. Verify Immediate Action
Step #3 1 8 2 7 3 6 4 5
Verify Immediate Action
Immediate action = activity implemented to screen, detect and/or contain the problem
Must verify that immediate action was effective
Run Pilot Tests
Make sure another problem does not arise from the temporary solutions
Ensure effective screens and detections are in place to prevent further impact to customer until permanent solution is implemented.
More info about immediate action

26. Root Cause Step #4 Brainstorm possible causes of problem with team1 8 2 7 3 6 4 5
Root Cause
Brainstorm possible causes of problem with team
Organize causes with Cause and Effect Diagram
“Pareto” the causes to identify those most likely or occurring most often
Use 5 Why? method to further define the root cause of symptoms
May involve additional research/analysis/investigation to get to each “Why?”
Must identify the process that caused the problem
if root cause is company-wide, elevate these process issues (outside of team control) to upper management to address
Step 4 is defining the root cause.
First of all, brainstorm the possible causes of the problem with the team. We recommend the use of the Cause and Effect diagram. After brainstorming, use the pareto principle to determine which causes to focus on.
After selecting the most probable cause, there is still more analysis to perform. Use the 5 Why’s methodology until you get to the root cause. The root cause will be a process that initially caused the problem to occur. People, departments, groups or machines are not the root cause. Try to take the root cause one more step to make sure the team addresses the same problems at the company wide level, or outside of their own department or group.

27. Corrective Action Plan
Step #5 1 8 2 7 3 6 4 5
Corrective Action Plan
Must verify the solution will eliminate the problem
Verification before implementation whenever possible
Define exactly…
What actions will be taken to eliminate the problem?
Who is responsible?
When will it be completed?
Make certain customer is happy with actions
Define how the effectiveness of the corrective action will be measured.
(Pareto charts, Paynter charts, check sheets, etc…)
Verification involves testing of the proposed solution to make sure it will do what the team thinks it will prior to a full scale implementation. Often times, the solution can create additional problems. If the solution will not work, it is better to find out in a beta test environment, rather than under normal operating conditions.

28. Verification vs. Validation
Step #5 1 8 2 7 3 6 4 5
Verification vs. Validation
(Before) (After)
Verification
Assures that at a point in time, the action taken will actually do what is intended without causing another problem
Validation
Provides measurable evidence over time that the action taken worked properly, and problem has not recurred
Validation means that the corrective action not only worked, but it was effective long term (withstanding all possible process issues)

29. Complete Action Plan Step #61 8 2 7 3 6 4 5
Complete Action Plan
Make certain all actions that are defined are completed as planned
If one task is still open, verification and validation is pushed back
If the plan is compromised, most likely the solution will not be as effective
Step 6 is simply making sure to complete the action plans defined in Step 5. You cannot verify or validate until all actions have been completed.
If the actions are not fully completed, or only partially completed, the effectiveness of the solution will be jeopardized

30. Step #7 1 8 2 7 3 6 4 5
Follow Up Plan
What actions will be completed in the future to ensure that the root cause has been eliminated by this corrective action?
Who will look at what data?
How long after the action plan will this be done?
What criteria in the data results will determine that the problem has not recurred?
Step 7 involves preparing the team for action, once the data analysis of the solution is complete. Who should be collecting the data, and for how long? What type of data results will be deemed acceptable?

31. Validate and Celebrate
Step #8 1 8 2 7 3 6 4 5
Validate and Celebrate
What were the results of the follow up?
If problem did reoccur, go back to Step #4 and re-evaluate root cause, then re-evaluate corrective action in Step #5
If problem did not reoccur, celebrate team success!
Document savings to publicize team effort, obtain customer satisfaction and continued management support of teams
Finally, the team should review the data results to conclude whether the root cause was adequately defined, or that the corrective action put in place was effective. If the problem still exists. Go back to either Step #4 and redefine the root cause, or Step #5, to readdress the corrective actions put in place.
If the problem went away, formally close the problem and celebrate success. It is extremely beneficial if a financial savings impact of resolving the problem is calculated. Many companies will redistribute a percentage of the cost savings back to the team members to further support the importance of solving problems

32. Root Cause Analysis Example #1
Manufacturing
Root Cause Analysis Example #1
This is the first example. We will walk through this example using the quality tools and the problem solving process. The second example is a transactional process example. We highly encourage the use of your own company examples in addition to these.

33. Part polarity reversed on circuit board
Example #1 1 8 2 7 3 6 4 5
Identify Problem
Part polarity reversed on circuit board
Pareto
We identify the problem as part polarity reversed on a printed circuit board. This may have been one incident, or a recurring problem identified from a pareto chart

34. Team members: Team Leader – Terry Inspector – Jane Worker – Tammy
Determine Team
Team members:
Team Leader – Terry
Inspector – Jane
Worker – Tammy
Worker - Joe
Quality Eng – Rob
Engineer – Sally

35. Immediate Action
Additional inspection added after this assembly process step to check for reversed part defects
Last 10 lots of printed circuit boards were re-inspected to check for similar errors
The immediate activity implemented after the team gets together…

36. 5 Why's Root Cause Why? Part reversed
The problem is placed in the first box. We then ask the first why. Why was the part reversed?

37. Worker not sure of correct part orientation
Root Cause
Part reversed
Worker not sure of correct part orientation
Why?
The team determines that the factory worker was unsure of the correct part orientation when performing the task. Often times, teams will stop and assume that the problem is due to human error. This is NOT an acceptable root cause. Errors will always be made, so teams must dig deeper to find a way of making the process easier, or find a better way of catching the problem sooner.
We again ask why. Why was the worked unsure of the correct orientation?

38. Root Cause Why? Part reversed
Worker not sure of correct part orientation
Part is not marked properly
Why?
Continue with the 5 Why’s process until they reach a defective process

39. Root Cause Why? Part reversed
Worker not sure of correct part orientation
Part is not marked properly
The 5 Why’s implies asking why five times, but it could be more than 5. Asking at least five times forces the team to dig beyond their own knowledge of the process and make certain they don’t stop short of the root cause
Engineering ordered it that way from vendor
Why?

40. Root Cause Root Cause Part reversed
Worker not sure of correct part orientation
Part is not marked properly
The team determines that the engineering process does not adequately account for manufacturing issues during the selection or specification process. Notice that they did not put the blame on the individual engineer.
Engineering ordered it that way from vendor
Root Cause
Process didn’t account for possible manufacturing issues

41. Corrective Action
Permanent – Changed part to one that can only be placed in correct direction (Mistake proofed). Found other products with similar problem and made same changes.
Preventive - Required that any new parts selected must have orientation marks on them.
Here are the permanent and preventive actions. The permanent changes that part for that particular problem. The preventive truly addresses the larger issue of selecting the parts correctly the first time with orientation marks, instead of afterwards when the problem is found.

42. Root Cause Analysis Example #2
Transactional
Root Cause Analysis Example #2
Example #2 is geared towards transactional, or office related processes

43. Department didn’t complete their project on time
Example #2 1 8 2 7 3 6 4 5
Identify Problem
Department didn’t complete their project on time

44. Team members: Boss – Jim Worker – Tom Worker - Karen Project Mgr – Bob
Determine Team 1 8 2 7 3 6 4 5
Team members:
Boss – Jim
Worker – Tom
Worker - Karen
Project Mgr – Bob
Admin – Sally

45. No new projects started until Root Cause Analysis completed
Immediate Action
Additional resources applied to help get the project team back on schedule
No new projects started until Root Cause Analysis completed
The team applies additional resources to get the team back on schedule and no new projects were started until the root cause solutions of this project were completed.

46. Didn’t complete project on time
Root Cause
5 Why's
Didn’t complete project on time
Why?

47. Cause and Effect Procedures Personnel Didn’t complete project on time
Lack of worker knowledge
Poor project plan
Poor project mgmt skills
Lack of resources
Didn’t complete project on time
The team uses the Cause and Effect Diagram to identify possible causes of the projects delay. Each cause is placed into the appropriate category
Inadequate computer programs
Poor documentation
Inadequate computer system
Materials
Equipment

48. Cause and Effect Procedures Personnel Didn’t complete project on time
Lack of worker knowledge
Poor project plan
Poor project mgmt skills
Lack of resources
Didn’t complete project on time
The team decides, based on experience and the available data, to focus on the “lack of resources” as the major reason for the delay.
Inadequate computer programs
Poor documentation
Inadequate computer system
Materials
Equipment

49. Didn’t complete project on time Resources unavailable when needed
Root Cause
Didn’t complete project on time
Resources unavailable when needed
Why?
The team determines that the appropriate resources were not available when they were most needed to keep the project on schedule.

50. Root Cause Why? Didn’t complete project on time
Resources unavailable when needed
Took too long to hire Project Manager
Why?
In this example, the Project Manager was not hired in time, which had a huge impact on the project’s schedule.

51. Root Cause Why? Didn’t complete project on time
Resources unavailable when needed
Took too long to hire Project Manager
The team keeps asking why, this time determining that the specifics for the Project Manager position were not clear and caused the Human Resources department to contact and interview some candidates who were not fully qualified
Lack of specifics given to Human Resources Dept
Why?

52. Root Cause Root Cause Didn’t complete project on time
Resources unavailable when needed
Took too long to hire Project Manager
Instead of stopping and blaming the HR department, the team brings a representative from HR into the team to dig further. After some discussion, the team determines that there are some problems with the internal job posting process, which allows the job specifics for the position to be overlooked or not clearly defined.
Lack of specifics given to Human Resources Dept
Root Cause
No formal process for submitting job opening

53. Permanent – Hired another worker to meet needs of next project team
Corrective Action
Permanent – Hired another worker to meet needs of next project team
Preventive - Developed checklist form with HR for submitting job openings in the future
The permanent action involves adding an additional full time support person to the project.
The preventive action addresses the process issue so that the problem does not happen again!

54. Hints about root causes
One problem may have more than one root cause
One root cause may be contributing to many problems
When the root cause is not addressed, expect the problem to reoccur
Prevention is the key!
Here are a couple things to keep in mind when performing root cause analysis.
Remember, just as one problem may have multiple root cause possibilities, one root cause may be causing multiple problems. When you do root cause analysis on a problem, you will have one root cause. However, if you look at all the “possible” ways in which it could go wrong, you will find multiple things that need to be improved.
When you don’t get to root cause, the process that creates it continues to send more problems and the problem will eventually return. Many times a short period of time without reoccurrence does not mean the root cause has gone away
When at all possible, brainstorm what possible root causes might be, so that you don’t have to wait for a problem to arise before it is fixed

55. How to identify the root cause Why it is important
Review
You learned:
How to identify the root cause
Why it is important
The process for proper root cause analysis
How basic quality tools can be applied to examples
This is what the students should have learned in this course:
How to identify the root cause, why it is so important for company success, the proper process for root cause analysis, and how you can apply basic quality tools to the problem solving process