5 Why Root Cause Corrective Action Course Objectives What is Root Cause? Benefits The Problem Solving Process Examples and Exercises

© 2013 Brooks Automation, Inc.
Supplier Training
8D Problem Solving Approach

What is the 8D method?
8D stands for the 8 disciplines or the 8 critical steps for solving
problems.
It is a highly disciplined and effective scientific approach for
resolving chronic and recurring problems.
This approach uses team synergy and provides excellent guidelines
to identify the root cause of the problem, implement containment
actions, develop and then implement corrective actions and
preventive actions that make the problem go away permanently.
The 8D:
• Isolates and contains the most basic causes of any
undesirable condition.
• Identifies the factors that contribute to the problem.
• Eliminates systemic factors that cause the condition
• Keeps teams from jumping to conclusions too early.
• Prevents problem recurrence.

What are the 8Ds?
Pre 8D: Once a problem has been recognized, the 8 disciplines used
to solve it are:
1) Team Formation
2) Problem Description
3) Implementing Interim Containment Actions
4) Defining Problem Root Causes
5) Developing Permanent Corrective Actions
6) Implementing Permanent Corrective Actions
7) Preventing Reoccurrences
8) Recognizing and Congratulating the Team
Post 8D: Once the problem has been resolved, the team should
publish and release a final report along with lessons learned.

When is an 8D used?
The 8D approach is used to solve critical, major, chronic and recurring
problems. The 8D use is typical when:
• The problem complexity exceeds the ability of one person (an expert)
to resolve the problem.
• Communication of the problem resolution (during & after) must go
across company levels, other departments and/or to customers.
• The customer or management requests 8-D
However, the 8D is not effective for:
• Non-recurring problems or problems which can be solved quickly by
individual effort.
• Problems with known root causes.
• Making a decision between different alternatives.
• Problems where the simplest and most obvious solution is likely to be
the best or adequate solution.

Why not apply the 8D to all problems?
 The 8D approach takes several weeks to several months in order to
solve a problem.
 It takes a minimum of (4) people from at least 4 different organizational
areas to effectively apply the 8D team problem solving approach.
(Product Quality, Product Engineering, Product Marketing,
Manufacturing, Supplier Quality, etc…).
 The 8D team requires senior management support for allocated
time/resources and the authority to make the appropriate and required
changes.

Pre 8D
This is the preparation step that needs to be done before starting the
8D process.
What kind of preparation is done here?
 A deeper understanding of the problem and its history are necessary
to determine if the 8D is the right method to be used for solving the
problem.
Recognizing the problem:
 Is it a new problem? Is it chronic?
 Has it occurred before?
 What is the history of the problem?
 How was it solved before?
 Why didn’t the solution prevent the problem from happening again?
 What problem solving method was used?
 Does the problem warrant/require an 8D? If so comment why and
proceed.

1- Team Formation
Team formation is the first discipline of the 8D approach. This
discipline is very important as the 8D is based on the foundation of
team synergy. FORM, NORM, STORM, PERFORM is the model. This
first discipline will establish a small group of people with the
process/product knowledge, allocated time, authority and skill in the
required technical expertise to solve the problem and implement
corrective actions.
Why is team approach important?
• A team can perform more effectively than individuals trying to
solve problems.
• A group of people can communicate and think creatively.
• Brainstorming as a group can stimulate ideas giving the team a
better perspective of the problem.

1- Team Formation (continued)
Who should be on the 8D team?
An 8D team consists of 4 to 8 people who are closely related to the problem. It usually
involves people from different functions/departments in the organization coming
together to solve a common problem.
 A champion (i.e. an executive sponsor not a working team member) that is ultimately
responsible for fixing the problem.
 A team leader (i.e. Quality engineering or Product Manager) - The person who
coordinates the entire 8D project through-out all of its disciplines. Makes sure the team
is on track and all team members are working together to resolve the problem.
 An 8D expert (i.e. Quality Engineering) - A person who knows the 8 disciplines. He/she
guides the team through the 8 disciplines using the appropriate quality tools at each
step.
 A subject matter expert (i.e. PCBA expert, SW controls expert, bearing specialist,
vacuum specialist, etc…)
 Supporting Cast (i.e. Supplier Quality, Electrical Engineering, Mechanical
Engineering, Manufacturing Engineering, Operations, Field Service, RMA, Technical
Support, Marketing, SW /Application Engineering, etc…) - people who have practically
experienced the problem and understand the pain it causes.

1- Team Formation (continued)
Responsibilities:
 The team leader must generate a list defining the team structure in order to
ensure that a team was actually formed for the 8D project. This list is also
useful to define the function/role each team member will play in the 8D project.
 The team leader must schedule meetings periodically to review progress of the
8D project and discuss action items in order to meet all expectations.
 The team leader must maintain minutes of the meeting documenting all that
happened in the meeting. Meeting minutes may include:
o Team progress.
o Key decisions reached in the meeting.
o Planned versus actual completion dates for all actions.
o Who needs to take what action? When? Where? How?
 Team leader may change any member’s roles and responsibilities once the
problem statement is further refined and understood.
 Team members must complete their actions and report back to the team
leader.

2- Describe the Problem
Describing the problem starts with a well-thought-out problem statement.
The problem statement will:
 Communicate the scope of the problem that the team is working on and get
the team focused.
 Provide information relevant to the problem: data and information on what the
problem is and what the problem isn’t.
 Clarify the role the team should play (determine root causes and implement or
recommend a solution), specify the deadline and include monetary limits for
the team.
 Lays down expectations from the team and deliverables that will be measured.
 Be the output of a process used to amplify the problem statement in terms of
Who, What, Why, Where, When, and How Big (how much, how many, how
often - level of pain).
Tools to be used:
 Data collection for background information (is / is not analysis).
 Pareto charts.

2- Describe the Problem (continued)
IS IS NOT
Who
Who is affected by the problem?
Who first observed the problem? (internal/external)
To whom was the problem reported?
Who is not affected by the problem?
Who did not find the problem?
What
What type of problem is it?
What has the problem?
What is happening?
Do we have physical evidence of the problem in our possession?
What does not have the problem?
What could be happening but is not?
What could be the problem but is not?
Why
Why it is a problem?
Is the process where the problem occurred stable?
Why is it not a problem?
Where
Where was the problem observed?
Where does the problem occur?
Where could the problem be located but is not?
Where else could the problem be located but is not?
When
When the problem was first noticed?
When has it been noticed since?
When the problem could have been noticed but was
not?
How Much
/ Many
Quantity of problem?
How Much is the problem causing in dollars, people, & Time?
How many could have the problem but don’t?
How big could the problem be but is not?
How Often
What is the trend (continuous, random, and cyclical)?
Has the problem occurred previously? (If so attach previous
analysis)
What could the trend be but is not?

3- Containment Actions
An interim containment action means that a “band-aid” is put in place to
prevent the effect of the problem or to prevent the full effect from impacting
customers and/or employees while a permanent solution is being developed
and implemented. Interim containment may include: quality alerts, inventory
purge and inspection, sorting bad parts from good ones, adding short term
operations, reviewing current procedures, using additional labor on the
process, additional inspection and tests, etc…
Why is interim containment necessary?
 While the problem solving team is trying to find the root cause of the problem
and implement corrective actions, there will be some defective products
produced by manufacturing.
 It is important to prevent these defective parts from reaching the customer.
Interim containment guarantees that the defects are contained in the facility till
the problem is completely solved.
 If defective parts make it to the customer, it may result in field failures,
warranty claims and customer complaints.

3- Containment Actions (continued)
Check Points:
 Have the interim containment measures been verified to work?
 Are they appropriate? Are they effective?
 Has the impact of the interim containment measures been tested to ensure
that no additional problems are being created?
 Are the actual additional costs of the containment measures known? Have
they been verified that they are “worth” it?
 Never allow an interim containment action to cover the gravity of the problem
thus reducing the need for a permanent solution.
 Interim containment if left alone will become part of the process. It can become
a hidden action that does not add any value, but ads only cost. In lean
manufacturing this is a waste that needs to be removed.
 Containment is NOT a solution, nor is it a corrective action.
 Containment actions could be implemented internally (local inventory, WIP,
finished goods), globally (spares depot, repair sites, etc…) at a supplier site or
at a customer site depending on the nature of the problem.

4- Develop Root Cause
Defining the root causes of a problem is the core of the 8D problem-solving
process. This is normally the toughest aspect of the problem-solving
process; if the root causes of the problem were obvious, then the problem
would have been solved already. There are usually two families of causes at
work when we know there is a problem:
 The first, the causes that appears to be the problem, are frequently
symptoms, not root causes.
 The second, the specific causes that allowed the apparent symptoms to
occur, are the root causes and often buried deep in the process.
Tools to be used:
Pareto Charts Affinity Diagram Brainstorming Session
5-Whys Process Fishbone Diagram Fault Tree Analysis
Statistical Analysis ANOVA DOE
Regression Analysis Hypothesis Testing GR&R
Flow Charts Audits FMEA

4- Develop Root Cause (continued)
Check points:
 Make sure the cause identified is not just a symptom but is the actual root
cause.
 Do not cure the symptom, as this may be the reason for the problem to
recur.
 Ask the Root Cause Question: “Do these causes explain all that is known
about what the problem is, as well as all that is known about what the
problem isn’t?” This is really a two-part question: make sure the root causes
found fit both the “is” and the “isn’t” sections of the question. If the causes
being tested don’t fit both, then they are probably not the root causes.
 Have the root causes identified been verified? Verification may require a
series of confirmation runs.
 Can you induce the failure? (turn the failure mode on/off)
 How did it happen? How did it get out?

Why part is defective? (6M) Why did it get out? (6P)
Man Materials Machine People Product Part Supplier
Method Management Measure/Test Process Policies Procedure
Failure
Mode

5-Why Process?
Failure mode root cause:
 FMRC1: Add 1st why
 FMRC2: Add 2nd why
 FMRC3: Add 3rd why
 FMRC4: Add 4th why
 FMRC5: Add 5th why
Escape root cause:
 ERC1: Add 1st why
 ERC2: Add 2nd why
 ERC3: Add 3rd why
 ERC4: Add 4th why
 ERC5: Add 5th why

5- Develop Permanent Corrective Actions
Often the solution or solutions become obvious once the root causes are
known. However, sometimes, a systematic approach is needed to use the root
cause analysis to develop a solution. If the solution is obvious, select the best
solution or mix of solutions that will lead to a robust, yet cost-effective,
resolution. If solutions are not yet evident, follow the data trail. When solutions
are not obvious, often the root cause has not been found.
Criteria for choosing the best solution:
 Practical - The 8D team should be able to implement the solution practically.
 Feasible - The solution must be feasible.
 Cost effective - Implementing and using the solution must be cost effective.
 Robust - The solution shouldn’t fail when used in production. Robustness of
the solution is an essential characteristic (error proofing, impact-effort matrix)
 Team Champion must have full buy-in to Permanent Corrective Actions and
facilitate their implementation.

5- Develop Permanent Corrective Actions (continued)
Validating the solution is important:
 It is necessary to establish that the solution will make the problem go
away without leading into other unwanted issues. That is why the 8D
team should try out the solution with small quantities first to verify its
effectiveness.
 A design verification test (DVT) and/or a reliability demonstration test
(RDT) may be required depending on the solution.
 The solution is first to be tried on small lots to validate that it has
indeed solved the problem prior to full implementation.

5- Develop Permanent Corrective Actions (continued)
Check points:
 Do not develop solutions that do not consider the practical aspect of
production.
 Never forget to consider the capability of manufacturing (machines, people,
etc…) when developing solutions.
 Never forget to consider the capability of the supplier when developing new
parts or tighter specifications.
 Has the solution passed the tests of practicality, feasibility and cost-
effectiveness?
 Is the solution robust and capable of preventing a recurrence of the problem?
 Does the ROI (return on investment) or the payback of the solution justify the
cost of implementing the solution?
 Can the solution be implemented within the required deadline?
 Is training required? If yes, have plans been generated?
 Is the solution in violation of the copy exact terms or POR? If yes, have plans
been communicated with customers?

6- Implement Permanent Corrective Actions
Once the solution and its implementation are approved, the next step is to create an
Action Plan. The Action Plan outlines what steps are needed to implement the solution,
who will do them, and when they will be completed. A Simple Action Plan merely
documents what needs to be done, who will do it, and when will it be done by. A complex
solution needs more thorough planning and documentation.
Check points:
 Is a Simple Action Plan (who will do what by when) adequate or will a Complex Action
Plan be needed?
 If a Complex Action Plan is needed, have Activity Plans, Gantt Charts and PERT Charts
been developed?
 Part of implementing a solution is to document new procedures or changes to
procedures as well as any changes that relate to the organization’s quality system; has
this been done?
 Has training to support the new system (s) been developed and provided?
 After people use the new or revised process a few times, they most likely will have some
improvement ideas. Have the suggestions been assessed, and have corresponding
adjustments been made to the process, has the documentation been updated, and has
retraining been provided?

7- Prevent Re-occurrence
The job of a problem-solving team is not complete once the solution is implemented. Preventing
recurrence is an important part of a problem’s solution. To prevent recurrence of the problem, the
team must verify that the outcome of their Action Plan works and they must validate that the
outcome is on-target. Verification is testing that the solution produces the desired outcome;
validation is ensuring that the outcome really solves the problem.
Check points:
 Has the outcome of the Action Plan been verified to work?
 Has the outcome been validated to be on-target?
 Have Action Plan results been documented, related procedures updated, and corresponding
changes to any affected quality system elements made?
 Have audits been established to assess the use and effectiveness of the solution to ensure that
the gains are held?
 Have the results been leveraged to prevent occurrences of like problems in all similar operations?
 Are all necessary controls for the solution are in place?
Tools to be used:
Control charts Control plans Histogram
Capability Analysis FMEA GR&R

8- Recognize the Team
Once a team has completed implementing the solution and ensured
that the solution works, all team members deserve to be
congratulated. Team members need to know that their efforts are
appreciated and that the organization knows about their
accomplishments.
 The organization (leadership group) shall recognize the team for
their efforts in a timely manner.
 The project team shall recognize those that have provided the team
with support and assistance.

Post 8D
Once the problem has been resolved, the team should publish and
release a final report along with lessons learned.
 The 8D report gives a quick snapshot of what was done in the
project and categorizes them under the 8 Disciplines.
 The report serves as a communication tool showing overall progress
of the 8D project along with actions taken.
 Also, a very useful tool to share is the "Lessons Learned" and
project findings.
 Completed 8Ds to be posted on the shared quality site (under 8D
reports).

8D Problem Report
Add Report Title
Add report author name
Add report date

8D Problem Report
Add Report Title Here
D1: Team Formation
Leader: Add team leader name
Members: Add team members (name / position)
D5: Develop Permanent Corrective Action(s):
Short Term:
List short term corrective action(s) identified
Long Term:
List long term corrective action(s) identified
D3: Containment Action(s):
Supplier: Add containment action(s) taken at supplier here
Stock: Add containment action(s) taken in parts in stock
WIP: Add containment action(s) taken on parts in WIP
FGI: Add containment action(s) taken on parts in FGI
Repair Centers: Add containment action(s) taken at repair centers
Customer: Add containment action(s) taken on at customer sites
D2: Problem Statement
Add team problem statement
D4: Develop Root Cause(s)
Failure mode root cause:
FMRC1: Add 1st why
FMRC2: Add 2nd why
FMRC3: Add 3rd why
FMRC4: Add 4th why
FMRC5: Add 5th why
Escape root cause:
ERC1: Add 1st why
ERC2: Add 2nd why
ERC3: Add 3rd why
ERC4: Add 4th why
ERC5: Add 5th why
Opened: <date>
Closed: <date>
D6: Implement Permanent Corrective Action(s):
List corrective action(s) implemented
D7: Prevent Re-occurrence:
List action(s) to prevent Re-occurrence
D8: Recognize the Team:
List action(s) taken to recognize the team
5
2
1 3 6
4 7 8

# Actions Owner
Date
Due
Date
Completed Comments Status
Action Item Table

5 Why Root Cause Corrective Action Course Objectives What is Root Cause? Benefits The Problem Solving Process Examples and Exercises

More Related Content

Similar to 5 Why Root Cause Corrective Action Course Objectives What is Root Cause? Benefits The Problem Solving Process Examples and Exercises (20)

Recently uploaded (20)

5 Why Root Cause Corrective Action Course Objectives What is Root Cause? Benefits The Problem Solving Process Examples and Exercises