Most problems at work get fixed once and then come back. Say a payroll run misses a batch of raises. Someone sends out the corrected payments and everyone apologizes. But a few months later the same thing happens to a different group of people. The first fix dealt with the damage. It never touched the reason it happened, so the reason is still there.
The 8D report is built to stop that second time. It takes one problem through a fixed series of steps. First you protect the people affected, and next you work out why it happened and why nobody caught it. You fix both, and weeks later you check that the fix actually held. Each step has a simple test it has to pass before you move on. That stops a team jumping from “something went wrong” straight to “we’ve sorted it”.
The method came out of Ford in the 1980s, where it was used to deal with defects on production lines. It’s a quality-engineering tool, and here we’re carrying it into teams that make nothing physical. That works because the report is really a record of problem solving done in a fixed order. It also helps that a repeat payroll error has the same shape as a repeat defect on a car part: it happened before, it hurt someone, and nobody caught it in time.
Below you’ll find a blank template you can copy. After it comes the same template filled in for an illustrative payroll run that left 31 people $3,658 short. The sections after that cover who belongs on the team and how to review the cause without blaming the person who ran the payroll. The last one covers when a lighter tool would have done the job.
What is an 8D problem solving report?
An 8D problem solving report is a structured record that takes one problem through nine steps. It starts with planning the response (D0) and ends with closure (D8). Containment, root cause, a permanent fix and prevention come in between. Each step has to pass a check before the next one starts, so the finished report does two jobs. It guides the team while they work, and afterwards it’s the evidence that the problem was properly dealt with.
Quality-One names the nine steps like this: D0 Prepare and Plan for the 8D; D1 Form a Team; D2 Describe the Problem; D3 Interim Containment Action; D4 Root Cause Analysis (RCA) and Escape Point; D5 Permanent Corrective Action (PCA); D6 Implement and Validate the Permanent Corrective Action; D7 Prevent Recurrence; and D8 Closure and Team Celebration.
Here is the same list in plain words. You decide whether the problem deserves this much effort and pick the people. You write down exactly what went wrong and put a temporary patch in place so nobody else gets hurt. Next you find the real cause and choose and test a lasting fix. Once it’s tested you roll it out and make sure the same cause can’t strike somewhere else. Finally you close the report and thank the people who did the work.
The “D” stands for discipline, and the name tells you where it came from. Quality-One’s 8D guide gives the origin: “Ford Motor Company developed this problem solving methodology, then known as Team Oriented Problem Solving (TOPS), in the 1980s.” AllAboutLean’s history of 8D dates the manual (“the Team Oriented Problem Solving Manual by Ford was first published in 1987”) and records what came after, “with a ninth D, D0 or D-Zero for emergency responses added later, as well as the concept of escape points to understand why the problem was not detected earlier.”
That last idea is called the escape point, and it’s the one most worth carrying out of the factory. Most teams that look into a mistake ask one question: why did this happen? An 8D makes you ask a second one as well: why didn’t anyone catch it before it reached the people it hurt? The answers are usually different, because something goes wrong in one place and the check that should have spotted it is missing somewhere else. If you only fix the first, the next different mistake will slip through the same gap.
The 8D report template (copy and paste)
The template has three parts. There’s a short header that says what the report is about and who’s responsible. The report itself follows, with one row per step. Last comes an action log where you track who’s doing what. You’ll fill them in roughly in that order, though the action log grows as you go.
Table 1: Header
The header is the part someone reads when they pick up the report cold, perhaps months later. It tells them what the problem was and who owned it. It also says who backed it, whether it’s finished and who the report was written for. The champion (sometimes called the sponsor) is the senior person who clears obstacles and frees up people’s time. The last row matters more than it looks, because knowing who’ll read the report tells you how much detail to put in it.
| Field | Fill in |
|---|---|
| Report title | |
| Date opened | |
| Date closed | |
| Problem owner | |
| Champion (sponsor) | |
| Team leader | |
| Status (Open / Contained / Closed) | |
| Customer or reader of this report |
Table 2: The report
This is where the work gets recorded, with one row for each step. The middle column tells you what to write in that step. The right-hand column is Done when, and it holds the test the step has to pass before you move on. That column is the most useful part of the whole template. Teams that work without it tend to fill in every box with something and call the report finished. But once the column is there, anyone can look at a row and see whether the step was really completed or just written about.
| Step | What to put in it | Done when |
|---|---|---|
| D0 Prepare and Plan for the 8D | Is this worth an 8D? Has any emergency response already been taken? What time and people are available? | The go or no-go decision is recorded, and any emergency action is logged with a time. |
| D1 Form a Team | Names and roles (champion, leader, the person who does the work, the system owner, a customer of the process) and the hours each person can give. | Every named person has said yes and has the hours cleared. |
| D2 Describe the Problem | What happened, where, when it was first seen, how big it is in numbers and dates, and what it should have been. Facts only: no cause, no name. For the longer version, see writing a good problem statement. | A stranger could tell what to measure, and the text contains no cause and no person. |
| D3 Interim Containment Action | A temporary action that protects the people affected now: who does it, by when, how you’ll know it worked, and the date it comes off. | The effect is confirmed with a number and the removal date is written down. |
| D4 Root Cause Analysis (RCA) and Escape Point | The cause that made it happen; the escape point, meaning where it should have been caught and wasn’t; the method used; how each cause was verified. The 5 Whys technique is one method. | Each cause has evidence behind it, not opinion, and both the cause and the escape point are answered. |
| D5 Permanent Corrective Action (PCA) | The options considered, the option chosen and why, and how you tested it before committing. | The chosen fix targets the verified cause and the escape point, and it has been tried on a trial run. |
| D6 Implement and Validate the Permanent Corrective Action | Actions, owners, due dates and the evidence each one worked. Remove the D3 containment. | Validated with the same measure used in D2, and the containment is removed. |
| D7 Prevent Recurrence | Where else the same cause could act; which standards, procedures, calendars or training changed; who now owns the control. | Similar processes are reviewed and the change is written into the standing procedure. |
| D8 Closure and Team Celebration | Lessons learned, before and after, documents archived, each person’s contribution named, and the 30-day and 90-day check dates. | The sponsor has signed off, recognition is done and the check dates are in calendars. |
A few of these rows are worth a word of explanation, because they’re where first-timers usually go wrong.
D2 asks for facts only, with no cause and no names. That feels odd at first, because by the time anyone writes D2 they usually have a theory about who or what is to blame. The point is to keep that theory out until D4 can test it. A problem statement that already names a cause has quietly skipped the investigation.
D3 is a temporary patch, not the fix. It exists because the real cause might take weeks to find, and the people affected shouldn’t have to wait that long. That’s also why it needs a removal date. A patch with no end date tends to become a permanent workaround that nobody owns.
D6 asks you to check the fix using the same measure you used in D2. If D2 said “31 people were paid the wrong amount”, then D6 should be able to say how many people were paid the wrong amount on the next run. Measuring something different makes it too easy to declare success.
Table 3: Action log
The action log is the to-do list for the whole report. Every action that comes out of D3, D5, D6 or D7 gets its own row. Each row has one named owner, a due date and its current status. The last column asks for evidence that the action worked, which is a higher bar than “done”. A form that went live is done. But a form that went live and caught the problem it was built for has evidence behind it.
| Action | Owner | Due | Status | Evidence it worked |
|---|---|---|---|---|
You’ll see the steps named slightly differently in other places. Some sources number the steps D1 to D8 and leave out D0, and Siemens is one of them. This template uses Quality-One’s names because they include the D0 planning step. That’s the step where you decide whether the problem deserves an 8D at all.
Using the template is simple: copy the tables into a doc or a spreadsheet, and keep one report per problem. You don’t need to fill everything in at once. An empty Done when cell is useful in its own right, because it tells whoever reads the report exactly what’s still missing.
8D problem solving report example: a payroll error, filled in
This is an illustrative report. The company, people and numbers are made up to show how each step reads; they are not Risely data or a real incident.
The company is a 240-person professional-services firm that pays its staff twice a month, on the 15th and on the last working day. It ran a pay review in March 2026, with the raises taking effect from 1 March. That month the 15th fell on a Sunday, so the mid-month payroll went out early on Friday 13 March.
When it did, 31 employees were still paid at their old salary. Their raises had been approved, but they never made it into the payroll. Here’s how the team worked through it, step by step.
Header, D0 and D1
Staff started querying their payslips on Tuesday 17 March. Petra Whitfield, the HR operations manager, opened the 8D that same day. She filled in the header first, so that anyone picking up the report later would know what it covered and who was responsible. Here’s how it read by the time the report closed.
| Field | Fill in |
|---|---|
| Report title | March 2026 mid-month payroll, pay review changes not paid |
| Date opened | Tuesday 17 March 2026 |
| Date closed | Wednesday 22 April 2026 |
| Problem owner | Petra Whitfield |
| Champion (sponsor) | Elena Brooks |
| Team leader | Petra Whitfield |
| Status | Closed, with the 30-day and 90-day checks still open |
| Customer or reader of this report | Elena Brooks and the finance and HR leads’ meeting |
The status row can look confusing at first, because it says the report is closed while two checks are still open. That isn’t a contradiction, because closing the report means the fix is in and has worked once. The follow-up checks are there to prove it keeps working.
D0 asks whether the problem is worth a full 8D in the first place, and Petra had three good reasons to say yes. The first was that it had happened before. An October 2025 run had missed an allowance change for 9 employees in the same way, so this wasn’t a one-off slip. The second was that real people were short of money they were owed. The third was trust. Anything that touches pay is sensitive for the finance team, and a repeat would damage trust in payroll. No emergency action was needed beyond the catch-up payment, which the report records under D3.
Petra put together a team of five for D1, and each person was there for a specific reason.
Elena Brooks, the Finance Director, agreed to be the champion. She doesn’t do the investigation herself. Her job is to clear blockers and to hold the time and budget. In practice that means deciding whose other work waits while the team does this.
Petra herself led the team, as the person who owned the problem.
Silas Hale is the payroll specialist, and he ran the 13 March payroll. Pay changes reach him in a spreadsheet sent by email. He knew more about what happened on the day than anyone else, which is exactly why he needed to be on the team.
Rowan Becker is the payroll platform administrator. He owns the system, so any fix that involved changing how the payroll software worked would go through him.
Hannah Moore is an operations manager who approves raises for her team. That makes her a customer of the process: she sends changes in, and her people feel it when they don’t come out the other end. Because she’s on the receiving end, she could also say whether a fix actually worked.
Each of them needed time cleared to do this properly (the figures here are illustrative too). Petra set aside about 6 hours a week for five weeks, from 17 March to 22 April. The other four each gave 2 to 3 hours a week.
D2 and D3
On 17 March the first question anyone asked was who had run the payroll. The answer was Silas, and it would have been easy to stop there. D2 is designed to stop exactly that. It keeps the question of who or why out of the report until D4 can answer it with evidence, so the problem statement holds facts only. Here’s what Petra wrote:
31 employees were paid at their pre-review salary on the 13 March pay date. Their correct salaries took effect on 1 March. The underpayment is $3,658 in total, an average of $118 per person. First reported on 17 March. Same kind of failure as an October 2025 run, in which 9 employees had an allowance change missed.
There’s no name in that statement and no guess at a cause. A stranger could pick it up and know exactly what to measure, and that’s the test D2 has to pass.
D3, the containment step, is about protecting the 31 people while the cause is still unknown. Petra messaged all 31 on Wednesday 18 March to explain what had happened and tell them when they’d be paid. On Thursday 19 March they received an off-cycle payment, checked against a list that Hannah and Petra had both approved. The report records how they knew it worked: none of the 31 sent a further query after 19 March. That’s the “confirmed with a number” part of the Done when test.
Containment also has to guard the next payroll run, because the cause was still out there and the 31 March run was coming up fast. So before releasing that run, Silas compared the list of approved changes against the payroll change log by hand. The report marks this check as temporary and gives it a clear removal condition: it comes off once the 15 April run shows that the permanent fix works. Writing that down at the start is what stops a stopgap from quietly becoming part of the job forever.
D4: two causes, not one
D4 is where the team found out what actually happened. It has to answer two questions rather than one: what caused the problem and why nobody caught it in time.
The team’s method was straightforward. They built a timeline from the email timestamps and the payroll change log, so they could see exactly when each thing happened. After that they asked “why” three times, and each answer led to the next question. (For more on how that works, see our guide to the 5 Whys technique.)
The obvious suspect from day one was Silas, because he ran the payroll and the payroll was wrong. But the timeline told a different story. The deadline for getting changes into the March mid-month run is called the cut-off, and it was Tuesday 10 March at 17:00. The last of the raise approvals didn’t come through until Thursday 12 March at 16:40, almost two days later. The payroll was already closed to new changes by the time the raises were approved, and there was no route for a late change to get in. Silas never received them, so he couldn’t have entered them.
That moved the question upstream. Why did the approvals land so late? It was because HR had set the pay-review calendar without looking at the payroll calendar at all. Nobody had ever lined the two up. The team then pulled the October 2025 incident file and found the same pattern. A change had been approved after the cut-off, and there was nothing to catch it.
The table below sets out the chain of reasoning, and it reads from top to bottom. Each row asks why the row above happened, then gives the answer and says what evidence proves it. The last two rows are the conclusions the whole chain leads to.
| Question | Finding | How it was verified |
|---|---|---|
| Why were 31 employees paid their old salary? | The raises were never entered in payroll. | The payroll change log has zero entries for the 31. |
| Why were they never entered? | Approvals finished on Thursday 12 March at 16:40, after the Tuesday 10 March 17:00 cut-off, and there is no path for late changes. | Email timestamps show the approvals landed almost two days after the cut-off (1 day 23 hours 40 minutes). |
| Why did approvals land after the cut-off? | The HR pay-review calendar was set without reference to the payroll calendar. | The October 2025 incident file shows the same pattern: a change approved after the cut-off, and no reconciliation. |
| Root cause | No one owns the link between the pay-review calendar and the payroll cut-off. | All three rows above. |
| Escape point | No step compares the approved-changes list with the payroll change log before a run is released. | The October 2025 file again: no reconciliation then either. |
The two bold rows are the two answers D4 asks for, and they’re different problems. The root cause explains why the raises were late. The escape point explains why nobody noticed before 31 people were underpaid. The calendars could be lined up perfectly and some change would still arrive late one day for some other reason. If there were no check before release, it would slip through just the same. That’s why the fix needed to deal with both.
The team confirmed the root cause on Tuesday 24 March.
It’s worth being clear about where this left Silas. He released a run that matched every change he’d been sent. The raises weren’t in what he was sent, and the process gave him nothing to check against. The timeline that showed all of this was also the one he built himself.
D5 and D6
D5 then asked what the permanent fix should be, now that the cause and the escape point were both pinned down. The team looked at three options.
The first was to move the cut-off two days later, which would have caught this particular batch of raises. They rejected it because payroll genuinely needs that time to process the run. Moving the date also wouldn’t stop late changes, because they’d just arrive late against a new deadline.
The second was to ask managers to approve raises earlier. That sounds sensible, but nothing would enforce it. A request with nothing behind it tends to fade after a cycle or two, so they rejected that too.
The third option dealt with both halves of what D4 had found. It created a proper route for late changes, so they’d be paid rather than lost. It also added a reconciliation before every payroll release, signed off by a second person. That second signature matters, because it turns the check from something Silas does on his own into something that’s visibly done. This was the option they chose.
Rowan and Silas tested it before the team committed to it. They ran a trial on a copy of the 31 March run and planted 3 late changes in it, to see whether the new reconciliation would spot them. It caught all 3. That trial is what the D5 Done when test asks for: proof that the fix works before you roll it out.
D6 is where the fix actually goes in, and the table below is the action log for that step. Each row is one action, with the person responsible and the date it was due. It also gives the evidence that the action worked, rather than just a tick to say it was done.
| Action | Owner | Due | Status | Evidence it worked |
|---|---|---|---|---|
| A change-request form replaces the emailed spreadsheet | Rowan Becker | Friday 27 March | Done | The form went live on 27 March. |
| Pre-release reconciliation, signed by Petra or Elena’s delegate | Silas Hale | The 15 April run | Done | 0 mismatches between the approved list and the payroll log on the 15 April run. |
| Late changes paid in an off-cycle adjustment within 2 working days | Silas Hale | The 15 April run | Done | Written into the payroll procedure (D7). |
| Remove the D3 interim check | Silas Hale | After the 15 April run | Done | Replaced by the signed reconciliation. |
The last row matters more than it looks. Removing the temporary check from D3 is listed as an action in its own right, with an owner and a date. If it weren’t there, Silas might have kept doing his manual comparison alongside the new reconciliation indefinitely. Nobody would have noticed the duplicated effort either.
The team validated the fix with the same measure as D2: did the approved changes reach the payroll? On Wednesday 15 April, all of them did.
D7 and D8
D7 asks a broader question: where else could the same cause strike? The cause here was a change approved on one calendar and paid on another, with nobody linking the two. So the team looked for every other process that worked the same way. They named four: bonuses, expense reimbursements, benefit deductions and new-hire start dates. Any of them could fail in exactly the same way.
The changes went into the standing payroll procedure rather than a one-off memo, so they’d still apply after the people involved had moved on. The pay-review calendar is now set backward from the payroll cut-off, so approvals are planned around the deadline instead of ignoring it. Hannah’s team and the other approving managers were briefed on the cut-off dates. The rule that a second person signs off the reconciliation is written into the procedure as well, so it can’t quietly lapse. Petra now owns both the calendar and the control. That closes the gap D4 found, because before this nobody owned the link between the two calendars.
D8 closes the report, and Elena signed it closed on Wednesday 22 April. The recognition was written into the report and read out at the finance and HR leads’ meeting, and it named what each person actually did. Silas was thanked for building the timeline that showed the cause sat upstream of him. Rowan was thanked for the trial run. Hannah was thanked for getting her team’s approvals in by the new cut-off.
The report also set two follow-up dates: a 30-day check on Friday 22 May and a 90-day check on Wednesday 22 July. These aren’t a formality, because one clean payroll run doesn’t prove much on its own, however encouraging it is. Failures of the October 2025 kind in the bonus process also haven’t been shown to be fixed yet, and the 22 July check is where that gets reviewed.
Who goes on the 8D team (D1)?
You need a handful of people, not a committee. The example has five people, one for each role in the template. Those roles are the champion and the team leader, the person who does the work, the person who owns the system and a customer of the process.
The customer of the process is the one most often left off, and that’s a mistake. They’re the person on the receiving end, so they can tell you whether a fix actually works in practice and not just on paper.
Before you name anyone, it helps to work through four questions. Who can clear blockers, and who holds the time and budget? Who does the work every day, and who owns the system it runs on? Who receives what the process produces, and so can tell whether a fix has worked? Finally, whose hours will the 8D take up, and who’s going to cover their usual work while they’re on it?
Manager time
That last question is the one people skip. Petra’s 6 hours a week for five weeks came from somewhere. Something else she would have done in those hours either waited or was handed to someone else. Deciding which is the champion’s job. If nobody makes that call, the 8D gets done late in the evening or not at all. The report shows it when that happens.
The person closest to the error
Silas knew more about the run than anyone, and he was also the most exposed person in the room. People dread being blamed, and a payroll specialist invited to a meeting about a payroll error will assume that’s why he’s there.
So say it out loud at the first meeting: he’s on the team for what he knows. It sounds obvious, but it changes how he behaves. If being named to the 8D feels like a sentence, people do the minimum and keep their heads down. They volunteer nothing, and the report ends up thinner for it. Here it went the other way: the timeline Silas built was the thing that cracked D4.
The function that “caused” it
Hannah sits on the side that sends the changes in. It’s tempting to leave the sending side out, because the error showed up in payroll. But the late approvals that D4 found came from the sending side. If you leave Hannah out, the whole fix lands on payroll. Meanwhile the thing that actually needs to change sits somewhere payroll can’t reach.
How do you run an 8D review meeting without blame?
Plan to hold the review twice: once when the D4 findings are ready, and again at D8 closure. The first one matters most, because if it goes badly you’ll lose the second. The person closest to the error won’t speak freely in a room where they were treated as the cause last time. That’s the same psychological safety problem any team has, just with a written report sitting on the table.
Here’s a 60-minute agenda for the D4 review, and the reasoning behind each part.
- Timeline, 15 minutes. The person closest to the error speaks first and walks everyone through what happened, in order. They describe events, and nobody asks them to defend a decision. Letting them go first gives them control of their own account, and it means the room hears the facts before anyone’s theory.
- What the process showed, 20 minutes. Go back through each point on the timeline and ask what the process gave people to work with at that moment. This is where you find out that Silas had nothing to check against, for example. It’s the longest slot because it’s where most of the useful findings come from.
- Cause and escape point, 15 minutes. Write each one down as a condition of the system, not as something a person did or didn’t do.
- Next steps, 10 minutes. Agree what D5 needs to test, and by when.
The questions you ask in that room make a big difference. Questions like “What made this the easy thing to do at the time?”, “What did the process let through?” and “What did the process show you?” all point at the process. That invites people to explain rather than defend. The ones to retire are “Who missed it?” and anything that starts with “Why did you”. They put one person on trial, however gently you say them.
Once you’ve written the cause down, test it. If it reads as a person’s name, D4 isn’t finished. The same goes if it contains words like “careless” or “did not follow procedure”. Those phrases describe someone’s behavior, but they don’t tell you what to change. The line “Silas released the run” fails that test. It’s true, but it leads nowhere except to blame. “No step compares the approved-changes list with the payroll change log” passes, because it points at something you can fix.
The opening minute sets the tone for the rest of the hour, and it’s the part most managers find hardest to get right. You can rehearse that opening with Merlin in Slack or Teams before the meeting. Merlin knows only what you choose to tell it, so bring the timeline and the first sentence you plan to say.
How do you close the report and recognize the team (D8)?
Quality-One describes D8 as closing the loop. That means archiving the documents and recording lessons learned. It also means comparing before with after and celebrating the team. The celebration is the part that tends to shrink to a team lunch and a quick “thanks, everyone”.
Recognition that people actually remember does three things. It names the specific contribution and happens in front of whoever sponsored the work. It’s also written into the report. “Thanks, everyone” doesn’t tell Silas that building the timeline is what moved D4 forward. A written line that says so does, and it stays in the record. Our guide to recognizing contributions covers the wording.
Two more closing items are easy to drop, and the first is the follow-up checks. The 30-day and 90-day checks need real dates in someone’s calendar. A line saying “we’ll review” doesn’t count, because nobody will.
The second is removing the containment. Quality-One notes that containment is temporary and is normally removed once the permanent corrective action is in place. Silas’s manual check in the example stopped after the 15 April run, once the signed reconciliation had replaced it. A containment step that’s left in place turns into a permanent workaround that nobody owns. Someone ends up doing extra work for years without knowing why.
Where the 8D report breaks
The 8D has real critics, and the sharpest objection comes from inside the quality world. Phil Thompson made it in a January 2026 article for Kepner-Tregoe: “8D is not a problem solving method. It never has been.” He describes 8D as “essentially a project management scaffold for problem investigation.” He also points at the step that does the real work: “8D doesn’t tell you how to determine the root cause. It doesn’t specify which analytical method you should use.” His verdict on that step is blunt: “D4 is a placeholder.”
He has a point, and it’s worth taking seriously. The 8D gives you a structure, but it doesn’t do the thinking for you. A report with every box filled in and a weak D4 looks finished and fixes nothing. Our own example’s D4 is only as good as its verification column. Its claims rest on the timestamps, the empty change log and the October 2025 file. If you took those away, “no one owns the link between the calendars” would become a plausible guess with a table around it.
A report can also turn into a punishment. That tends to happen when it exists mainly to answer a customer or a boss. The report then gets written after the decision has already been made, with the boxes filled in to match. This is our editorial judgment rather than a sourced finding, but the warning signs are easy to spot. Look for a D4 that names a person, a D5 that just says “retrain” or a D8 with no dates.
Sometimes 8D is simply the wrong tool. AllAboutLean’s guide on when to use 8D lists the cases where it isn’t worth it. Three of them stand out:
- “Minor problems: The pain is not worth the effort of an 8D.”
- “Overly vague problems: The 8D needs a starting point.”
- “If management doesn’t care (and doesn’t support)”
The first is about proportion: nine steps and a five-person team is a lot to spend on something small. The second is about focus: if you can’t write a clear D2, you’re not ready for an 8D yet. The third is about support: without a champion who’ll free up time, the team won’t get the hours it needs.
Our own example carries a limit too, and it’s only fair to name it. The fix held on the 15 April run, but that’s only one run. The 90-day check on 22 July is still open, and the bonus process hasn’t yet been shown to be safe from the same failure.
8D, 5 Whys or A3: which one should you use?
The 8D isn’t the only structured way to tackle a problem, and it’s worth knowing how it compares with the two tools people most often weigh it against. The 5 Whys is a much lighter technique where you keep asking why until you reach a cause. The A3 is a one-page problem-solving report that comes from Toyota and the lean tradition. It’s named after the paper size.
“I don’t believe the 8D process goes as deep into monitoring results or checking what happened during execution, reflection, and making decisions on next steps.” That’s David Verble, comparing the two methods for the Lean Enterprise Institute. He adds: “The 8D process seems to be more frequently used at the operational and staff levels to investigate and resolve problems within their work environments.” He sees A3s differently, because they “are most often used for management level problems which are often cross-functional or strategic.”
The table below sorts problems by what they look like, and suggests a tool for each. Start at the top and stop at the first row that describes your problem. The right-hand column shows where each recommendation comes from, so you can tell sourced guidance from our own judgment.
| Situation | Use | Basis |
|---|---|---|
| The fix is obvious and one person can do it | Just fix it | AllAboutLean: for well-understood problems, “Just do the solution then.” |
| The cause is unknown, but it sits in one team, it’s contained and it follows a single causal thread | 5 Whys | Our rule of thumb |
| It repeats, it’s serious, it crosses two or more functions, or someone outside the team will read the report | 8D | AllAboutLean on when 8D fits |
| It’s a management-level, cross-functional or strategic problem, or you want the plan, do, check loop | A3 | LEI and Verble |
| It’s a one-off, minor, vague or too broad, or management won’t back it | None of them yet. Narrow it or drop it | AllAboutLean on when not to use 8D |
The hardest call is usually between the 5 Whys and the 8D. Our rule of thumb is to write the 8D if more than one function has to change something for the fix to hold. The same goes if someone outside the team will read the result. Otherwise, run 5 Whys. The payroll example needed an 8D on both counts. The fix involved HR, payroll and the managers approving raises, and the finance director was also going to read the report.
The two also aren’t really rivals. The 5 Whys is a method you can run inside D4, and the 8D is the report that wraps around it. That’s exactly what happened in the example. Our guide to problem solving skills for managers covers the wider skill set behind all three.
If you’ve got a problem in mind that keeps coming back, copy the template and fill in D0 and D1 today with the team you’d name.
If the blame-free review is the part you’re dreading, practice its opening with Merlin in Slack or Microsoft Teams before you walk into the room.