How the 8D method solves problems permanently

Here’s something that honestly drives me crazy about how most teams handle problems. Something breaks. People scramble. They patch the symptom. Everyone moves on. Then the same problem comes back three months later, wearing a slightly different hat.

Ford Motor Company figured this out decades ago with their Team Oriented Problem Solving (TOPS) program. They built a structured method called 8D - eight disciplines that force you to actually fix things instead of just making them temporarily less painful.

The 8Ds target three basic aims: identify the problem, correct it, and make sure it never happens again.

Since the original eight disciplines were defined, a ninth step (D0) was added to cover emergency preparedness. So it’s really nine steps now. Don’t let the word “discipline” scare you - this is a straightforward problem-solving template that doesn’t require special training or certification.

I learned this the hard way at Tallyfy working with manufacturing and aviation organizations, the framework itself matters less than the commitment to follow it consistently. One aerospace company we worked with needed to track corrective actions across multiple divisions - from flight training to maintenance operations - and the biggest challenge wasn’t defining the 8D steps. It was making sure managers closed out findings with proper documentation.

Tracking corrective actions and making them stick requires structure. Here’s how process improvement software can help.

D0 through D3 - finding and containing the problem

Nobody enjoys putting out fires. But the D0 step exists because panicking isn’t a solution.

The problems you’ll address with 8D aren’t predictable. A supplier ships defective raw materials. A software release breaks a critical integration. A regulatory change invalidates your current procedure. You can’t prevent every crisis, but you can be ready to respond without losing your head.

D1 - Build the right team. You need people who are closest to the broken process or product. They understand the nuances, they’ve seen the warning signs, and - here’s what most people miss - they’re already feeling responsible. That guilt works in your favor. Let them be part of the solution instead of the scapegoats.

D2 - Define what the problem actually is. This sounds obvious. It isn’t. “A component is faulty” tells you nothing useful. You need the 5W2H approach to get the full picture:

• Who is directly affected? Was this caught internally or reported from outside?
• What specifically failed? Pinpoint it as narrowly as possible.
• When was it first detected?
• Where did it happen? Think of it like a detective story - location matters as much as timing.
• Why did it happen? Your team might have multiple theories. Record all of them.
• How did it happen? Circumstances are crucial because they might reveal scenarios you’ve overlooked.
• How many/much? Quantification creates the baseline you’ll measure your solution against.

D3 - Contain the damage. While you’re investigating, you can’t just let a broken system keep running. Interim measures could mean stopping production entirely. That sounds drastic, but shipping a defective product is worse. Full stop.

This is messy damage control, not a permanent fix. But it keeps the problem from growing while your team works toward a real solution.

Root cause analysis and the 6M method

Turns out, finding the root cause is trickier than most people expect. There’s usually a chain of events, and you have to trace it all the way back to the original trigger.

Here’s a practical example. A clothing manufacturer discovers jacket seams coming apart. Easy to blame the stitcher, right? But maybe the machine was miscalibrated. And maybe the machine failed because the wrong thread was loaded. And the wrong thread was loaded because of a mix-up in the warehouse. And the warehouse mixed things up because the supplier mislabeled packages.

That’s five links in the chain. Blame the stitcher and you’ve solved nothing.

Kaoru Ishikawa’s 6M method gives you a systematic way to trace problems back to their source:

• Manpower - Was the operator trained properly? Were they physically capable of the task? Did they understand what was required? Machine - Right equipment? Correctly calibrated? Properly maintained? Materials - Right quality, correct physical or chemical properties? Method - Well-trained people with maintained machines and good materials can still fail if the process itself is broken, which is often the sneakiest root cause of all. Measurement - If you’ve ever added a tablespoon of salt to a recipe that called for a teaspoon, you know why standardized measurement matters. Environment - Temperature, humidity, lighting, cleanliness. These get overlooked constantly, and they shouldn’t.

You could also try Sakichi Toyoda’s 5 Whys analysis - a simpler approach where you keep asking “why” until you’ve drilled down to the real cause.

This is where the mega trend hits hard. Process quality is performance. Can you just automate past it? No. If your root cause analysis is sloppy and you automate the output, you’re just automating the wrong fix at machine speed. One misconception we see constantly is that automation can substitute for diagnosis - teams rush to automate before they’ve properly figured out what’s broken. The 8D method forces you to slow down and get the diagnosis right before you touch any automation.

Corrective action and implementation

D5 - Decide on the right fix

Now that you and your team are confident you’ve found the root cause, it’s time to figure out what to do about it. Generate options, thin the list down, pick the ones most likely to work.

Your aim is to remove the cause - not mask it, not work around it, but eliminate it. That could mean anything from a simple procedural change to a multi-step improvement plan.

Actually, elimination isn’t always realistic. Whatever solutions you choose, they need to stick long-term. After watching hundreds of teams try this with process improvement, the solutions that survive are the ones embedded directly into daily workflows rather than documented in binders nobody opens. This might mean additional quality control checkpoints, new approval steps, or restructured handoffs between teams.

D6 - Implement and verify

Having reached the sixth discipline doesn’t mean celebration time. You’re not even close to done.

Implementing corrective action is more important than deciding what ought to be done. Talk to affected team members so they understand why you’re making changes, what problem you’re fixing, and how their work shifts.

But here’s the part most teams skip - verification. Keep monitoring the original problem. Has it disappeared? Don’t just check once. Track your outputs over weeks or months. Problems have a bit of a nasty habit of pretending to be solved.

Workflow templates for structured problem resolution

Example Procedure

Customer Complaint Resolution Workflow

1Acknowledge the Complaint

2Categorize and Prioritize

3Investigate the Root Cause

4Propose Resolution to Customer

5Implement the Resolution

+2 more steps

View template

Example Procedure

Customer Complaint Escalation Process for Service Teams

1Listen and Empathize

2Be Objective

3Be Helpful

4Solve the Problem

5Document the Issue

+3 more steps

View template

Preventing recurrence with embedded workflows

D7 - Entrench the new standard

This is where most 8D efforts die. You’ve identified the cause, implemented a fix, verified it works. Then six months later, someone new joins the team, doesn’t know about the change, and the old broken process creeps back in.

The changes you’ve made represent a new standard. Your company’s reputation depends on maintaining it. No pressure.

There will be changes to policies, procedures, and workflows - even if it’s something as simple as adding one quality-control step. The change management process can be brutal even for small adjustments. You need everyone on the same page, and you need follow-up.

This is where workflow software earns its keep. Instead of explaining the new process to every employee manually - and hoping they remember - you embed the change into the workflow itself. With Tallyfy, the corrected process becomes the only process. Nobody can accidentally revert to the old way because the old way doesn’t exist in the system anymore.

You can also document your new processes or adopt workflow management software that enforces changes automatically. The difference between a process that sticks and one that fades is usually whether it’s embedded in how work actually flows or just written down somewhere.

D8 - Celebrate with your team

Without your problem-solving team, none of this works. They deserve recognition - formal, organization-wide, genuine.

Each team member contributed something essential. Acknowledging that isn’t just good manners. It fuels future problem-solving efforts across the organization.

We got this wrong at first - assuming teams would naturally celebrate after solving a tough problem. But in pharmaceutical and life sciences organizations, this step gets skipped far too often. One pattern we’ve noticed: companies that build recognition into their review workflows see better compliance rates down the line. People want to be heroes. Let them.

Why 8D matters more in the age of AI

I probably sound like a broken record, but this point matters. Every team rushing to automate their operations should run the 8D framework first. Not because it’s fancy, it’s the opposite of fancy, but because it’s methodical, sometimes tedious, and requires patience that forces you to understand your processes deeply enough to know what’s worth automating and what needs fixing first. At Tallyfy, our whole philosophy starts here: define the process, track it, improve it, then - and only then - automate it.

The 8D method fits perfectly into this sequence because it’s designed to produce processes that are actually correct before you scale them. The organizations we’ve watched succeed with AI aren’t the ones that rushed to automate. They’re the ones that slowed down long enough to get their 8D analysis right, and then the automation part became almost trivial.

Think about it this way. If your corrective action from D5 is embedded in a Tallyfy workflow, and your D7 prevention is enforced by that same workflow, you’ve closed the loop. The fix doesn’t depend on tribal knowledge or someone’s memory. It’s structural.

The eight disciplines approach isn’t glamorous. It won’t get you excited at a conference. But it works - and in a world where everyone’s racing to bolt AI onto broken processes, the teams that take time to fix things properly will be the ones still standing when the dust settles.

Who doesn’t want to be in that group?