8D (Eight Disciplines of Problem Solving) is a meticulous process used to solve complex problems. This is a popular method for problem solving because it is reasonably easy to teach and effective. 8D uses composite problem solving methodology, by borrowing tools and techniques from various approaches. The original 8D process was pioneered by Ford Motor Company and called TOPS (Team Oriented Problem Solving). The process is documented on a form with attachments; however, following the form does not complete the 8D process and will not yield desired results.

What are the Steps Used in 8D?

What is the Relationship Between 8D and FEMEA?

How Can I Learn More About 8D?

What Are the Steps Used in 8D?

The 8D steps and tools used are as follows:

D0: Prepare for the 8D

  • Collect the Symptoms
  • Symptoms Checklist
  • Emergency Response Action

D1: Form a Team

  • Core Team Structure
  • Team Preparation

D2: Describe the Problem

  • 5 Why
  • Problem Statement
  • Affinity Diagram
  • Is / Is Not
  • Problem Description

D3: Interim Containment Action

  • Verification of Effectiveness

D4: RCA (Root Cause Analysis) and Escape Point

  • Differences and Changes
  • Root Cause Theories
  • Verification
  • Process Flow Diagram
  • Escape Point

D5: Permanent Corrective Action

  • Acceptance Criteria
  • Risk Assessment / FMEA (Failure Mode and Effects Analysis)
  • Balanced Choice
  • Control Point Improvement
  • Verification of Effectiveness

D6: Implement and Validate

  • Project Plan
  • Validation of Improvements

D7: Prevention

  • Similar Products and Process Prevention
  • Systems Prevention
  • Standard Work or Practice
  • Procedures / Policy Updates

D8: Closure and Team Celebration

  • Archive Documents
  • Team Lessons Learned
  • Before and After Comparison
  • Celebrate Successful Completion

The 8D process or Global 8D, as it is known by Ford, alternates inductive and deductive problem solving tools to steadily progress towards a solution. The Quality-One approach uses a core team of three for inductive activities with data driven tools and a larger SME (Subject Matter Expert) team for the deductive activities through brainstorming.

What is the Relationship Between 8D and FMEA?

FMEA is a tool used in the planning of product or process design. The Failure Modes in a FMEA are equivalent to the problem statement or description in an 8D. Causes in a FMEA are equivalent to potential causes in an 8D. Effects of failure in a FMEA are problem symptoms in an 8D. The relationships between 8D and FMEA are outlined below:

  • The problem statements and descriptions can be linked between both documents. An 8D can be completed faster by utilizing easy to locate, pre-brainstormed information from a FMEA to solve problems.
  • Possible causes in a FMEA can immediately be used to jump start 8D Fishbone or Ishikawa diagrams. Brainstorming information that is already known is not a good use of time or resources.
  • Data and brainstorming collected during an 8D can be placed into a FMEA for future planning of new product or process quality. This allows a FMEA to consider actual failures, occurring as failure modes and causes, becoming more effective and complete.
  • The design or process controls in a FMEA can be used in verifying the root cause and Permanent Corrective Action in an 8D.


The FMEA and 8D should reconcile each failure and cause by cross documenting failure modes, problem statements and possible causes. Each FMEA can be used as a database of possible causes of failure as an 8D is developed.

How Can I Learn More About 8D?

Q-1 provides problem solving expertise and training in the 8D method. 8D is useful for problem solving in any industry or application. We have transferred 8D knowledge to thousands of users, offering Training and Facilitation customized to your unique business needs.

Symp·tom noun /ˈsim(p)təm/ A sign of the existence of an undesirable state.A symptom is always required for a problem solving activity to begin. The symptom may be detailed or vague. The first step in 8 Disciplines for problem solving is to define the symptom in as much detail as possible through communication with an internal or external customer. The ”problem symptom” coming from a customer requires some factual detail in order to begin the 8D. The 8D process typically converts the symptom to a simple “OBJECT and DEFECT” for further analysis.

Symptom Quantification

Symptoms and Effects of Failure

Emergency Response Action (ERA)

Symptom Quantification

Initial fact gathering, details the symptom in more quantifiable terms. Without data, the problem solving effort can wander aimlessly showing little or no progress. Additional information required for quantifying the symptom may include:

  • Date of Manufacture
  • Lot numbers
  • Quantity
  • When it was first noticed?
  • If the problem is noticed by multiple users and facilities

Symptoms and Effects of Failure

A “Problem Symptom” in 8D, A “Customer Verbatim” in Warranty and A “Potential Effect” of a Failure Mode and Effects Analysis (FMEA) are roughly equivalent to one another. They are not the actual focus of the problem solving activity. The Root Cause of a problem is rarely the problem symptom communicated by the customer. Integrating the Problem Symptoms into FMEA, as Effects of Failure, assures the Lessons learned in problem solving will eventually be collected and added back into the problem prevention tools like FMEA.

Emergency Response Action (ERA)

Symptoms are often relieved through an Emergency Response Action (ERA). The ERA (Emergency Response Action) simply addresses the current level of “Pain” and is not to be confused with addressing the root of the problem. In all cases ERA is Verified and Validated to relieve the “PAIN” of the problem.

Defining the problem with available facts keeps the cross-functional team focused on discovering the root cause.The process is similar to that used by CSI investigators and medical professionals and removes possibilities with the available collective facts.

Three Step Process

Problem Statement and FMEA Relationship

Problem Description

What is the Is / Is Not Approach?

Three Step Process

The “Problem Description” is determined through a multi-step clarification process.

  1. Problem Symptom is Quantified and converted to” OBJECT and DEFECT”
  2. Problem Symptom is converted to Problem Statement using Repeated WHYs
  3. Problem Statement Converted into Problem Description using IS/IS NOT

The quantified Problem Symptom in the form of an “OBJECT and DEFECT” is refined by the Cross Functional Team (CFT)  into a Problem Statement. The Problem Statement is created by asking the question WHY as many times as available facts can answer the question.

Example: Problem Symptom is “Passenger Injury” WHY? (In every case the “SUV Rollover”) “SUV’s Roll Over”, WHY? (In Each Case it was preceded by a “Blown Tire”) “Blown Tire” WHY? Many explanations may be applied therefore we cannot continue with repeated WHY past the Blown Tire statement. The problem statement for the 8D is “Blown Tire”

The Repeated WHY (Similar to 5 WHY) is inductive, meaning facts are required to proceed to a more detailed level.

Problem Statement and FMEA relationship

Problem Statements are roughly the equivalent of Failure Modes on Failure Mode and Effects Analysis (FMEA) Quality-One has developed several approaches which can link problem solving with FMEA. The benefits are better lessons learned capture and faster Root Cause Analysis (RCA) and improved Containment Actions.

Problem Description

The Problem Description is created by taking the Problem Statement and combining available facts about:

WHAT, WHERE, WHEN and HOW BIG. The Description becomes a sentence which is used as a filter for all possible root cause theories to be tested against before permitting physical verification. This process saves time and effort by keeping the team focused on collecting data around what the problem IS NOT vs immediately looking or trying various possible solutions.

What is the Is / Is Not Approach?

8D is a counterintuitive approach to problem solving. As a problem is encountered, it is intuitive to try solutions to uncover what the root cause Is. 8D takes the opposite approach by removing possible causes that are not contributors. The Is Not approach limits the number of trial and error attempts at fixing the problem. 8D achieves this by defining the problem with increasing detail based on facts as they are available.

The problem description is the result of a scientific study of; what, where, when and how much. The Q-1 method develops theories with collected facts after removing possible causes not agreeing with the problem description. These root cause theories are compared to the problem description prior to physical verification. Trial and error is not permitted in 8D.


Discovering and isolating the Root Cause of a problem can have significant benefits to an organization.  When the Root Cause is known, it can be removed and prevented from returning through the use of Error Proofing techniques (i.e. Poka Yoké).  The Root Cause can only be determined through the removal of a recurrence of the problem at will.  This can be accomplished through experimentation and / or virtual means (i.e CAE).  The virtual models used must be correlated to real world data to assure they will confirm that a most likely cause is the Root Cause.

In Eight Disciplines of Problem Solving (8D), the Root Cause is discovered by determining which deductive Possible Cause agrees with the Problem Definition.  If all facts align, the Possible Cause becomes a Most Likely Cause (MLC).  To convert an MLC to a Root Cause, a theory must explain why the Capacity features of a Design or Process were inadequate when exposed to the Demand stresses at the time of failure.  The changes that explain the incapable Capacity when compared to the Demand stresses must also be part of the theory.

Tools used in finding the Root Cause:

  • 5 Why (3 leg)
    • Problem
    • Escape
    • System
  • Affinity Diagrams
  • Is/Is Not
  • Fishbone Diagrams
  • Risk Assessment / Failure Mode and Effects Analysis (FMEA)
  • Process Flow Diagrams
  • Experimental Design Techniques
  • Verification and Validation of the Root Cause

Formal Problem Solving Methods focus on Root Cause Analysis and Permanent Corrective Action.  8D takes it one step further by studying the Lessons Learned and then using them to prevent future failures. D7 – Prevention looks at preventing the actual problem from returning by reviewing the systems and management processes which contributed to the failure.  Changes must be made to prevent recurring problems.

Relationship Between 8D and FMEA

FMEA as a Problem Solving Tool

Preventing Systems Support Failure

Preventing Similar Problems on Similar Problems

Relationship Between 8D and FMEA

FMEA is used to capture the Lessons Learned in terms of the physical problem and the Escape Point.  The FMEA provides future Product Development teams the opportunity to prevent failure that has been experienced on similar products and processes.

  • The Effect of Failure in the FMEA parallels the Problem Symptom in D0
  • The Failure Mode in the FMEA is equivalent to the Problem Statement in D2
  • The Potential Causes in the FMEA are the Possible, Most Likely and Root Causes
  • The Current Process Controls in the FMEA is the appropriate place to put new controls required for the Escape Point

FMEA as a Problem Solving Tool

FMEA can also be used as the starting place for problem solving because the history of all known failure has already been captured. The FMEA should be consulted at D2, prior to brainstorming possible causes. It may have already been recorded in a previous activity and if available, will shorten the problem solving process. 

Preventing Systems Supported Failures

W. Edwards Deming once said that 85% of all problems are the “fault of management”.  Management systems contribute to failure through ineffective communication, lack of collaborative tool use or the omission of key process steps.  The root cause of a problem is often a poorly defined process or an absence of standard work.  The Prevention step in 8D discovers how procedures, policies and practices may be improved and standardized to avoid failure in the future.

Preventing Similar Problems on Similar Products

Once the problem has been solved and it has disappeared, the team must also look at similar products to implement improvements that have worked successfully.  This action prevents problems on other products or processes from happening by creating a standard practice to be replicated.