8D problem solving: the eight disciplines, step by step

Each discipline has a clear output before the team moves on:

Not every problem needs eight disciplines. A missing label on one internal form needs a quick fix. A repeated shipment of bad parts to a customer needs an 8D. Before opening one, check:

• The problem is real: Confirmed by more than one unverified report.
• The scope is known: The product, process, site or customer affected.
• Urgency is clear: Whether containment has to start before the first team meeting.
• An owner is named: Someone who can coordinate actions and dates.
• First evidence is collected: Samples, photos, logs, complaints and inspection records.
• The output is agreed: A customer response, an internal corrective action or an audit record.

Keep the team small enough to move fast but broad enough to cover the process. A common mistake is handing the whole 8D to the quality department when the cause may sit in design, purchasing, maintenance or scheduling. Typical roles:

Agree decision rights at the start: who can approve containment, who can change the process and who signs off the validation.

A vague problem leads to vague causes. 'Quality was poor' gives the team nothing to test. The is/is not method narrows the scope by comparing where the problem shows up with where you would expect it but it does not. Here is an illustrative example for damaged deliveries:

The problem statement follows from the table: product A cartons have arrived with crushed corners in 3.1% of northern deliveries since the week 14 carton change. It does not name a cause yet, but it tells the team exactly where to look.

Containment is a temporary control that stops the problem spreading while the team investigates. It might mean holding stock, sorting inventory, adding an inspection or giving customer support a clear script. Strong containment is:

Containment costs money. Extra inspection and rework are a good reason to finish the 8D rather than live with the patch.

A complete 8D usually finds two causes:

Fixing only the occurrence cause leaves the detection gap open, so the next wrong part escapes too. Fixing only the escape cause means paying to catch defects you keep making.

Pick the tool that clarifies the problem, then verify what it suggests:

Verification is what separates a root cause from a good guess. Use one or more of these checks:

• Turn it on and off: Reproduce the failure under controlled conditions, then remove the cause and show it stops.
• Compare cases: The cause is present in affected units and absent in unaffected ones.
• Check the records: Timing, batch, shift or supplier data line up with the problem.
• Inspect the evidence: The physical part, the log or the screen shows the mechanism.
• Ask the people doing the work: They confirm the explanation matches what really happens.

One question sums it up: if we remove or control this cause, should the problem stop? If the answer is unclear, the team has not reached the root cause yet.

A permanent corrective action removes a verified cause. Reminders and retraining rarely do that alone. In the Uptime Institute's 2025 outage analysis, 85% of major data center outages caused by human error stemmed from staff not following procedures. Compare weak and stronger actions:

Test each action on a small scale before rollout and look for side effects, such as slower work, new error types or safety issues.

Implementation means the actions are done. Validation means they worked. Many weak 8D reports stop at the first. A validation plan covers:

1. 1

   Set success criteria. State the result that would show the action is effective, for example zero wrong parts in the next 10,000 units.

2. 2

   Watch the right measure. Track the defect, complaint or detection result tied to the original problem.

3. 3

   Allow enough time or volume. Run long enough to see whether the problem returns.

4. 4

   Remove containment last. Take temporary controls out only once the permanent fix is proven.

5. 5

   Record the evidence. Keep the data, audit results, test results and customer feedback with the report.

D7 asks where else the same failure could happen. Fixing one station while five identical stations stay exposed is only partial learning. Typical D7 actions:

• Standards updated: Procedures, work instructions and control plans reflect the new method.
• FMEA revised: The failure mode, cause and new controls go into the design or process FMEA.
• Similar processes checked: Other lines, products, sites and suppliers with the same risk get the fix.
• Design rules changed: Checklists and review criteria stop the issue at the design stage.
• Audits updated: Audit questions check that the new control stays in place.
• Training refreshed: Onboarding and launch reviews include the lesson.

This example is illustrative. A customer finds the wrong bracket fitted in 6 of 2,400 assemblies.

A template helps, but the thinking behind each field is what matters. A useful 8D report holds:

• Reference details: Problem title, customer, part or service and dates.
• Team: Members, roles and the owner.
• Problem statement: With the is/is not evidence.
• Containment: What was done, by whom, and how it was verified.
• Root causes: Occurrence and escape, with the verification.
• Corrective actions: Owners, due dates and test results.
• Validation: Data showing the problem stopped.
• Prevention: Changes to standards and similar processes.
• Closure: Approval, final notes and team recognition.

Keep the form short enough that people fill it in properly. Root cause analysis software and CAPA software can hold 8D reports and track the actions.

All three structure problem solving. They differ in focus:

Most weak 8Ds come from skipped steps rather than a lack of skill:

1. 1

   Starting with a solution. The team already has an answer before the problem is defined.

2. 2

   A broad problem statement. With no is/is not, there is nothing specific to test.

3. 3

   Containment as the final fix. Extra sorting protects the customer but leaves the cause in place.

4. 4

   Stopping at operator error. Human error usually points to design, labels, workload or tooling.

5. 5

   Ignoring the escape cause. The next defect slips through the same gap.

6. 6

   Actions that cannot be checked. There is no evidence they worked.

7. 7

   Standards left unchanged. The lesson fades with the people who learned it.

8. 8

   Closing too early. Finished tasks are treated as proof the problem is controlled.