8D Report Guide: All 8 Disciplines with a Worked Example

8D at a glance

The worked example

This case continues the scenario from our PFMEA guide. There, low copper-pillar height was a potential failure. Here, it has reached a customer.

All values, dates, and events are fictional teaching data.

D0 — Prepare and respond

Question: Is this a one-off issue, or does it need structured problem solving?

The defect reached the customer, affects function, and the cause is unknown. That meets most companies' criteria for starting an 8D.

Emergency response happens immediately, before the team is fully formed. Here, the plant puts a hold on Product A shipments and notifies the customer that containment is under way.

Output: Decision to open the 8D, emergency actions taken, and when.

D1 — Form the team

Question: Who has the knowledge to find the cause and the authority to change things?

A useful test: could this team change the recipe system, the sampling plan, and the procedures? If not, someone is missing.

Output: Named team with roles.

D2 — Describe the problem

Question: What exactly is wrong, and what is the boundary of the problem?

A weak description: "Pillar height low, customer complaint."

A better one:

Product A wafers from lots L-0412, L-0415, and L-0418 had copper-pillar heights of 41–44 µm against a 48–52 µm requirement. The shortfall was uniform across the wafer. Lots were plated on tool P2 between 3 and 5 March.

The Is / Is Not table narrows where to look. The "Is Not" column matters as much as the "Is" column: each difference points to something that changed.

Output: A problem statement with data, plus Is / Is Not.

D3 — Contain the problem

Question: How is the customer protected until the root cause is fixed?

Define the scope first, then act on each location:

Containment must be verified, not just announced. Record how many units were checked and how many failed.

Containment is temporary. A 100% measurement rule is expensive, and it stays in place only until D6 proves the permanent action works.

Output: Scope, quantities checked, results, and start date.

D4 — Find the root causes

Question: Why did the defect occur, and why did our controls let it escape?

This is where most 8D reports are weak. There are two root causes to find. Ford's Global 8D formalizes the second one as the escape point: the earliest control in the process that should have caught the problem, but didn't.

Occurrence chain:

1. Pillars were short. → Plating time was shorter than intended.
2. Why? → Recipe revision C was run instead of the approved revision D.
3. Why? → Revision C was still selectable on tool P2 after revision D was released.
4. Why? → The recipe-release procedure did not require old revisions to be deactivated.

Escape chain:

1. Short pillars were not detected. → The three lots were not measured.
2. Why? → The sampling plan measured one lot in every five ("skip-lot").
3. Why? → The skip-lot rule had no trigger to return to every-lot measurement after a recipe change.

Verify the root cause, don't just argue it. The strongest evidence is turning the problem on and off. Here, the team plated test wafers with both revisions under controlled conditions:

The result reproduces the defect and matches the complaint.

It also roughly agrees with Faraday's law. At the same current, deposited thickness scales with plating time. Revision C plates for 26 minutes instead of 30, so it should give about 50.1 × 26/30 ≈ 43.4 µm. The measured mean was 42.6 µm.

The two values are close but not identical. Current efficiency, bath condition, and measurement variation all move real deposits away from the ideal calculation. That is the point of verification: theory tells you whether a cause is plausible; the test shows whether it is real.

To check the calculation from your own recipe parameters, see copper electroplating and Faraday's law or use PlatingMate.

Output: Occurrence and escape root causes, each with verification evidence.

D5 — Choose and verify permanent actions

Question: What action removes each root cause, and does it work before full rollout?

Every root cause needs its own action:

The interlock was a proposed action in the PFMEA example. This is where it becomes a real control, once it has been verified.

Output: Actions mapped one-to-one to root causes, with verification results.

D6 — Implement and validate

Question: Now that the action is in production, did it actually work?

D5 verification shows the action can work. D6 validation shows it does work in production.

For this example, the team collected:

• Interlock logs: 4 blocked attempts in the first month, all mismatched selections.
• Pillar height for 30 consecutive lots, plotted on an I-MR chart: stable, no lots below 48 µm.
• A capability estimate from the same data. Check whether Cpk or Ppk is the right index before reporting it. The SPC & Capability Analyzer can generate both from this data.

Once validation is accepted, the D3 containment (100% measurement, manual recipe check) is removed. Record that date too.

Output: Implementation date, production data, and the date containment ended.

D7 — Prevent recurrence

Question: Why did our system allow this, and where else could it happen?

D4 found causes in one tool and one procedure. D7 asks the broader question.

"Retrain the operator" is not a D7 action. Training rarely fixes a system that allowed the wrong choice in the first place.

Output: Updated documents, plus the list of other processes and products checked.

D8 — Close and recognize

Question: Is it really finished?

Typical closure conditions:

• D6 validation data accepted.
• Containment removed.
• D7 documents released.
• Customer approval, if required.

Recognize the team's work, and record what the organization learned. This feeds future PFMEA reviews.

Output: Closure date and approvals.

Common mistakes

Before you submit

Read the report as the customer would:

• Does D2 describe the problem with data, so someone outside the plant understands it?
• Does D3 show quantities and results, not just intentions?
• Does D4 have both an occurrence and an escape root cause, each verified?
• Does every D5 action point to a specific root cause?
• Does D6 contain data from production, after the change?
• Does D7 change the system, not just the people?

A good 8D report is not long. It is one where every claim has evidence behind it.

Sources and further reading

• ASQ — Eight Disciplines (8D). An overview of D0–D8, with a downloadable report template. (asq.org)
• VDA — 8D: Problem Solving in 8 Disciplines (1st edition, 2018). The German automotive industry's guidance on the 8D method, process, and report. It covers 8D itself, not the wider complaint-handling process. (webshop.vda.de)
• AIAG — CQI-20 Effective Problem Solving Guide (2nd edition, 2018). A general problem-solving guide, not an 8D-specific document, but often referenced by automotive customers for problem statements, root cause, and verification. (aiag.org)

This guide explains the reasoning behind each step. It does not replace your customer's required 8D format or template, and it does not reproduce content from the publications above.