8D Process

D0: Prepare for Problem Solving

Initiate the 8D process when a responsible function becomes aware of a problem symptom that warrants
an 8D.  

Awareness of a problem symptom may come from feedback from the field, repair centers, through failure
analysis, or negative trends in metrics (e.g., PPM).  An 8D is typically warranted when the cause of the
problem is unknown, the complexity exceeds the ability of one person, and the priority is great enough to
fix the problem at the root cause level and to prevent recurrence.

Define and quantify the problem symptom as experienced by the customer, using the customers words
and terminology. 

Identify the customer(s) and other parties affected by the issue.

Determine if Emergency Response Action (ERA) is required.  ERA is directed toward product that is already
in the field and is intended to protect the customer from any additional impact from the problem
symptom.  If an ERA is determined to be necessary, select an appropriate action, develop an
implementation plan, implement the plan and validate its effectiveness. 

Key D0 Elements

 Define and quantify the symptom

 Identify the customer and affected parties (e.g., distributors, etc.)
 Emergency Response Action (if necessary)

D1: Establish a Team

Appoint a team champion who has authority to make process changes, make resources available to the
team, and monitor team progress. 

Appoint a team leader who will direct the team and the use of the 8D methodology as well as coordinate
team activities with the business and functions. 

Select cross functional team members based on their skills, technical knowledge relative to the problem,
and ability to represent the stakeholders involved.

Key D1 Elements

 Identify a champion
 Identify a team leader
 Select team members

D2: Problem Description

Create a problem statement that answers the question "What is wrong with What?" (e.g., Product XYZ fails
in a brittle fracture mode under installation torque). 
Where feasible, perform a failure analysis to understand intermediate causes and provide detail.  Include
pictures, sketches or marked up drawings of the issue.

Add detail through an Is/Is Not Analysis, answering the questions What?, Where?, When?, and How Big? 

Understand the process through a process map documenting the operations and control points of the
process. 

Additional tools that may be useful are: timeline, cause/effect diagram, drill-down, concentration diagram,
and statistical analyses. 

Create a formal problem description by adding the additional information to the problem statement.  The
problem description defines the boundaries of the problem in terms of what it is and what is not, but
could be.

Key D2 Elements

 Problem Statement
 Failure analysis
 Is/Is Not analysis
 Process flow with control points identified
 Problem Description

D3: Interim Containment Actions

The purpose of Interim Containment Actions (ICA) is to protect the customer from further effects of the
issue, to limit exposure and potential liability.  ICAs may include suspension of the process and/or
shipments, 100% inspection, sorting, rework, substitution or additional operations.  Consider stock at or in
transit to: customer locations, finished goods warehouse, subcontracted service providers and in
quarantine. 

Notify personnel in the area from which the nonconformance originated that the nonconformance has
occurred, including written instructions and visual aids as appropriate.

Choose the best ICA option and verify the effectiveness of the ICA by answering the questions: "Does it
detect the issue?" and "Does it cause another issue?" with supporting data.  Implement the ICA and
validate the effectiveness of the ICA in preventing the issue from reaching the customer using the same
indicator(s) that made the issue apparent.

As long as the ICA is in place, monitor the effectiveness and take remedial action if nonconformities
continue to pass the control point(s) or if nonconformities are found in reworked material.

Key D3 Elements

 Defined ICA

D4: Diagnose Root Cause

Review the Is/Is Not Analysis created during D2, and identify differences between the Is and the Is-Not,
but could have been. 
Review or create a timeline of changes made to the process, product, procedures, etc. and compare the
timing of these changes to the timing of the issue.

Develop theories of possible root causes that could explain the differences and the timing.  A tool that
may be useful in developing theories is the cause and effect (fishbone) diagram.

Test the theories against the problem description.  Look for theories that help explain the differences
between the Is and Is-Not for the questions What?, Where?, When?, and How Big?  If no single theory can
explain the entire problem description, consider the possibility of multiple causes.  A fault tree analysis is a
useful tool for developing multiple root causes.

Document the theories and the process of elimination using a diagnostic tree.  Continue developing the
diagnostic tree to approximately 4 - 6 levels deep.  Stop when the level of detail becomes less actionable
(i.e., outside local control).

When the diagnostic tree has been completed, prune the branches of all theories that have been
disproven to create a 5 Why (Problem causal).

When the 5 Why (Problem causal) is complete, develop a 5 Why (Escape causal) for the root cause of how
the issue escaped local control points into the field.

Key D4 Elements

 5 Why (Problem causal)

 5 Why (Escape causal)
 Diagnostic Tree

D5: Identify Solutions (Planned PCA)

Establish decision criteria for permanent corrective action(s) (PCA) to address both the problem root
cause and the escape root cause.  The decision criteria will consist of Must Have (i.e., mandatory,
measurable and realistic) requirements as well as Nice to Have (i.e., desirable, flexible and realistic) wants.

Identify possible corrective actions for both the problem root cause and the escape root cause.  Compare
the choices against the Must Have requirements and discard the options that fail to meet the Must Have
requirements.  Evaluate the remaining choices against the Nice to Have wants using a relative scale.  
Select the option that meets all Must Have requirements and best meets the Nice to have wants without
creating an unintended consequence.

Verify through testing that the action will resolve the problem at the root cause level allowing for variation
in the frequency or patterns created by the cause.  Evaluate the action over the full range of production
variation and operating conditions.

Key D5 Elements

 Permanent corrective action

 Verification of PCA

D6: Implement, Verify & Validate Corrective Actions (Actual PCA)

Develop an action plan for implementing the Permanent Corrective Action.  The plan should include key
steps, identification and prevention of potential barriers, contingency plans (including triggers and
responsibilities for implementation).

Implement the Permanent Corrective Action plan then remove the Interim Containment Action put in
place during D3.

Validate the effectiveness of the PCA for both the problem and the escape using the same metric that
previously identified the problem.  Useful tools for validation include: SPC, capability studies, audits, etc.

Key D6 Elements

 Implementation plan
 Contingency plan
 Validation of effectiveness

D7: Prevention

Review everything learned in steps D0 through D6, analyzing how the problem occurred and escaped. 

Identify policies, procedures, methods and systems that allowed the problem to occur and to escape. 
Identify temporary corrective actions that should have been replaced with permanent solutions.  Look for
undocumented or non-standard practices, lack of coverage, or blanket policies with no exceptions.

Identify similar products run through the same operation/process as the root cause variable, similar
processes that are susceptible to the same problem root cause, and similar control points that are
susceptible to the same escape root cause.

Identify other potential root causes that could result in the same failure mode.  Use Fault Tree Analysis to
identify other potential causes followed by a Process FMEA to assess and manage the risk.

Identify and choose preventive actions that may be applied to other products, processes or facilities,
including improved controls, using the same "Must Have" and "Want" process described in D5.

Document these preventive actions through revised PFMEAs, control plans, policies, procedures,
instructions and lessons learned.

Key D7 Elements

 Implementation plan
 Updated PFMEAs, control plans, policies, procedures, instructions

D8: Congratulate Your Team

Update lessons learned database

Recognize the entire team's collective effort.