8D Problem Solving

Goal

8D problem solving is a team method: starting from a defect found at the customer, the team corrects its cause, then updates the system that let the defect through.

When the complaint arrives, the problem owner, then the team, decide what protection to put in place while the cause is still unknown. Once the cause is verified, the team decides which correction to make and over what scope.

The deliverable is the 8D report. It has one section per discipline, from D0 to D8, which the team fills in as it goes. The report is the formal answer to the customer, the audit trail and the archive for the next similar problem.

Usage

When to use it

• Customer complaint or warranty return: the customer is already affected by the defect and needs protection before anyone understands it.
• Safety or regulatory compliance problem: the D3 containment limits exposure while the team looks for the cause.
• Scrap, internal nonconformities or test failures above the tolerated threshold: the defect is measurable, so D2 starts from figures.
• A defect that returns despite one-off fixes: D4 requires a verified cause and D7 extends the correction to the system.
• A supplier whose customer asks for an 8D report: the expected answer follows the D0 to D8 numbering.
• A production incident in an IT or administrative department: the method applies outside the factory as soon as a defect affects a customer.
• Data available on the defect: tickets, logs, change history. Without them, the D2 grid fills up with opinions.

When not to use it

• A process whose performance needs improving, with no reported defect: there is no customer to protect, so prefer DMAIC.
• A failure that could happen but has not happened yet: analyse the design or the process with an FMEA.
• A cross-functional or strategic management problem: run A3 problem solving.

Description

Where the eight disciplines come from

Ford's management wanted to give its Powertrain division a team method for recurring problems. The work began in 1986. The manual it produced, Team Oriented Problem Solving (TOPS), appeared in 1987. Christoph Roser sees the probable influence of a standard that Ford knew as a supplier to the US military: MIL-STD-1520C of June 1986, which organises corrective action on nonconforming material. The D0 discipline and the concept of the escape point came later. The method kept the name 8D all the same.

It spread through the automotive supply chain because the customer requires the 8D report from its supplier. Roser describes it today as widely used in industry, in particular for quality problems.

The nine disciplines

The disciplines run in sequence and each builds on the one before.

D0. Prepare. Before forming the team, the manager who receives the problem gathers the symptoms with a list of questions and decides whether the case warrants an 8D. An 8D is warranted when the customer is exposed, when the defect recurs or when the cause is unknown. When the cause is known and the fix obvious, the manager fixes it directly. The manager also decides on an emergency response action if the customer remains exposed: block a shipment, withdraw a lot, disable the function in production. This action protects the customer from the moment of the complaint. It corrects nothing.

D1. Form the team. The team is cross-functional and brings together knowledge of the product, the process and the data. The team leader knows the method and guides the team from one discipline to the next, without necessarily being the person who knows the problem best. The sponsor is the person who can approve the changes the team will propose and fund the containment. Without a sponsor, the 8D produces recommendations that nobody acts on. In an IT or administrative department, the business analyst walks the team through the process and the data that D2 and D4 need.

D2. Describe the problem. The team describes the problem in measurable terms: what, where, when, how many. It starts from the symptom stated as object and defect, for example "premium invoice, discount missing", then makes it more precise. The D2 tool is the is / is not grid, taken from Kepner and Tregoe's problem analysis. For each dimension, the grid records where the problem shows up and where it could show up but does not. Each "is not" cell rules out possible causes before the analysis begins. The description talks about the problem. The solution waits for D5.

D3. Contain the problem. The team puts in place an interim containment action, which shields the customer from the defect until the permanent correction: sort the stock, inspect every part before shipment, check every affected invoice by hand. This action is expensive and leaves the cause untouched. The team verifies that it works. A containment that lets defective parts through has moved the problem without containing it. As soon as the containment is in place, the team sets the criterion for removing it. The team also marks the first lot or the first billing run known to be good: from this reference point, D6 proves that the defect no longer gets out.

The method places D3 before D4 because every day the defect keeps getting out costs the customer and the supplier.

D4. Identify and verify the root cause and the escape point. The team carries out a root cause analysis. It compares the "is" and "is not" columns, notes what distinguishes them and what has changed, then derives cause hypotheses. Where needed, it widens the field with a fishbone diagram or traces a chain back with the five whys. It then verifies each hypothesis with data or a trial. A verified root cause can be switched on and off at will. A hypothesis that fails this test remains a hypothesis.

The escape point is the closest point in the process where the root cause could have been detected and was not. The root cause explains why the defect appeared. The escape point explains why it reached the customer. French-speaking practitioners also speak of the cause d'apparition and the cause de non-détection: the cause of occurrence and the cause of non-detection.

D5. Choose and verify the permanent corrective actions. The team chooses a permanent corrective action for each of the two causes. The first removes or changes the condition of the product or process that produced the defect. The second improves the control at the escape point. The team assesses the risk of each option, for example with an FMEA, then chooses against acceptance criteria. As in Kepner and Tregoe's decision analysis, these criteria split into musts and wants. The team verifies both corrections before deploying them, through a trial, a pilot run or a test environment.

D6. Implement and validate. The team deploys the corrections to a plan that sets the steps, the communication to stakeholders and the measure of success. The D5 verification showed the effect on a trial; the D6 validation measures it in production. Once the correction is validated, the team removes the D3 containment.

D7. Prevent recurrence. D5 and D6 corrected one product and one process. In D7, the team looks for where the same defect can occur elsewhere: similar products, related processes, other sites. It updates the procedures and work instructions, the FMEA and the control plan, which sets the process controls.

D8. Close and recognise the team. The team archives the report, records what it learned about the way it solves problems and compares the state before and after. Management recognises the work of the team and of each member. The archive serves the next 8D: the search for a returning defect starts in the closed reports.

Finding the escape point

The team starts where the cause occurred and follows the process downstream. It lists every control the defect passed through: inspection, test, review, reconciliation, goods receipt. For each one, it asks whether that control, at its place in the process, could have detected this particular cause. The first one that could have is the escape point. If it let the defect through, the team repairs it: its coverage, its threshold, its sample or its data set. If no control exists between the cause and the customer, the escape point is the step closest to the cause where a control would have detected it, and the team adds one there.

In an IT project, the escape point is often a test: a case the acceptance test did not cover, a data set that did not contain the faulty configuration. The second correction then falls first to the analyst who wrote the acceptance criteria.

Three actions, three lifespans

The D0 emergency response action protects the customer from the moment of the complaint and holds until the D3 containment takes over. The D3 interim containment action shields the customer from the defect until the D6 validation. The permanent corrective action, chosen in D5 and deployed in D6, removes the cause and stays. The first two cost money for as long as they last.

Common mistakes

Presenting containment as the correction. A 100% sort that has run for months hides an 8D stalled at D3. The customer no longer receives defective parts, but the plant still makes them and pays for the sort.

Declaring a cause without verifying it. The team settles on the most plausible hypothesis and moves on to D5. If the cause cannot be switched on at will, the correction rests on a guess and the defect returns.

Closing D4 with a single cause. The report names the root cause and says nothing about the control that let it through. The D5 correction is then complete on paper and the control stays blind.

Stopping the analysis at a person. "Operator error" describes a symptom. The team goes on to ask why the process made the error possible and why no control stopped it. 8D asks a team to state what it let through, including in its own controls. When the people behind the complaint want someone to blame, the team tends to settle on the first cause that implicates none of its members.

Stopping at D6. The product is corrected, and its twin, made on the next line with the same tooling, keeps the defect. D7 exists for this case.

Filling in the report instead of solving the problem. David Verble, of the Lean Enterprise Institute, makes the point: an 8D report describes problem solving after the fact; it does not produce it. A report filled in over one evening to answer the customer has the format of the method and none of its work.

Boundaries with neighbouring methods

8D contains a root cause analysis. iSixSigma lists the five whys and the fishbone diagram among the D4 tools. 8D adds what surrounds D4: containment before it, then the two corrections and prevention across the system after it.

FMEA works before the defect, on a design or a process, and rates possible failures. 8D starts from a defect that has occurred. The two methods meet twice: D5 can rate the correction options with an FMEA, and D7 updates the existing FMEA with the failure mode the case revealed.

A3 problem solving differs in scope. Verble observes that 8D is used mainly at operational levels, on problems confined to the work of one team. At Toyota, A3 is used most often for management problems, cross-functional or strategic. Verble also judges that 8D does less than A3 to follow up results and close the PDCA cycle. Roser makes the same observation: 8D puts the emphasis on rapid reaction and containment; it does less with the check and act phases of PDCA.

DMAIC, the Six Sigma project approach, starts from a process whose performance needs improving and measures it before analysing it. 8D starts from a defect that has reached the customer. D3 separates the two methods: DMAIC has no containment step.

AI considerations

An assistant sorts complaints in D0 and D2. It groups tickets, emails and returns by symptom, product and date, then pre-fills the is / is not grid. The team checks every cell against the source data: a wrong "is not" cell rules out the right cause. In D4, the assistant proposes and ranks hypotheses from the grid and the change history. It does not verify them: verification is a trial that switches the cause on and off.

In D7, it searches for similar cases in a document base: the products that share the component, the procedures that contain the same step, the closed 8Ds that describe a similar defect. It drafts the report in the customer's language, German for a German carmaker, for the team to review.

Two uses are ruled out. A model that writes a complete 8D report from a complaint produces a plausible cause and consistent corrections without anyone having looked at any data. Verble describes this defect: a report without problem solving, obtained faster. The second use exposes data: a complaint carries the personal data of customers, and a supplier defect is often covered by a confidentiality agreement with the buyer. The Federal Act on Data Protection (FADP) and the contract decide which tool that data may go to.

Examples

The report below belongs to a fictitious health insurer in French-speaking Switzerland. After a release went live, its billing platform left the family discount off the premium invoices for supplementary insurance.

The correction of the escape point rectifies no invoice. It changes the data set of the acceptance test, so that the test catches the next mapping error, on any code, before production. Without it, the team would have fixed the RF mapping and left the acceptance test as blind as before.

Visualisations

The diagram of the discipline sequence shows at a glance the place of D3 before D4 and the fork from D4 to two corrections, which a table would line up in one column. A second diagram follows the flow of the billing case and places the escape point on it, at the first control downstream of the cause. The lifespan of the three actions reads as bars along the axis of the disciplines, from D0 to D8. The is / is not grid and the 8D report stay tables, their original form.

Cost

Tooling

An 8D report template, in a spreadsheet or a word processor, is enough for most teams. Many customers impose their own, sometimes to be entered on a supplier portal. In an IT department, the report belongs in the problem record of the IT service management tool. The spreadsheet also holds the is / is not grid and tracks the actions from D5 to D7.

Quality management software offers a corrective and preventive action (CAPA) module. It tracks each 8D and links the actions to their owners and their deadlines. It also archives the closed reports for D8. It pays off when the organisation handles several dozen 8Ds a year and wants to find a similar defect in past reports.

In D4, a whiteboard, physical or online, holds the fishbone diagram during the session. The data analysis of D2 and the verification of D4 call for a spreadsheet or statistical software. In an IT department, the incident management tool supplies the history of tickets and changes that the D4 comparison needs.

Sources

• Ford Motor Company (1987), Team Oriented Problem Solving (TOPS), internal training manual, unpublished: the origin of the method, known through Feldman, Verble and Roser.
• U.S. Department of Defense (1986), MIL-STD-1520C, Corrective Action and Disposition System for Nonconforming Material, military standard since cancelled, public copy on everyspec.com: the corrective action standard that predates the Ford manual.
• Feldman, Ken (2018), 8D Process, iSixSigma: the start of the work at Ford Powertrain in 1986, the publication of the TOPS manual in 1987, the addition of D0 to the original eight disciplines and the D4 tools.
• Verble, David (2020), Dueling Methods: 8D and A3, The Lean Post, Lean Enterprise Institute: the origin at Ford, the list of disciplines, the reminder that a report describes problem solving without producing it and the split of scope with A3.
• Roser, Christoph (2025), The History of the Eight Disciplines Problem Solving (8D), AllAboutLean.com: the probable influence of MIL-STD-1520C, the later addition of D0, the escape point and its place in D4, the emphasis of the method on rapid reaction and containment, as well as its widespread use in industry.