Problem solving methods: 8 compared, and which one to use

Methods and tools are not the same thing

The two words get mixed up, and the mix-up causes real trouble: a team runs a 5 Whys, calls it a method, and never contains the problem, checks the fix or writes a standard. The frame sets the order of the work and who owns it. The tool does one job inside the frame.

In practice you choose a method for the size of the problem and then pick tools for the cause step. A 5 Whys sits at D4 of an 8D, in the cause section of an A3, and in the Analyze phase of a DMAIC project.

The eight at a glance

A Pareto chart belongs next to all of these. It does not find a cause; it tells you which problem is worth a method in the first place.

5 Whys

Ask why a confirmed fact happened, then ask why of the answer, until you reach a condition the plant can change. Five is a rule of thumb, not a target. The weak point is that a chain follows one line of reasoning, so a problem with two causes shows only one of them. Check every answer against a fact before you ask the next why. The 5 whys guide covers the method, and when it works and when it does not covers the traps.

PDCA

Plan a change, do it on a small scale, check whether it did what you expected, then act: adopt it, adjust it or drop it. It is the oldest frame here and the one the others build on. A3 is PDCA laid out on a page, and DMAIC is a longer version for projects with data. The PDCA cycle post shows the four stages, and DMAIC and PDCA side by side shows how they relate.

A3

An A3 tells the whole story of a problem on a single sheet: background, current state, goal, root cause, countermeasures, plan and follow-up. One person owns it and a coach asks questions along the way, which is where most of the learning happens. It suits internal problems that take weeks, not days. See A3 problem solving and the A3 report post for formats.

8D

The eight disciplines run from forming a team to recognising it, with containment early so the customer is protected while the investigation runs. The cause step has to explain why the cause occurred and also why the defect escaped detection. Use it when a customer will read the report. The post on 8D problem solving goes through every discipline.

DMAIC

Define, measure, analyze, improve and control. It fits problems that come from variation in a process, where you have data and the answer is not obvious from walking the line. Because it measures, it can also size the result, and the DPMO calculator and first pass yield calculator are common early steps. Read the guide to the DMAIC process before starting.

Fishbone

A fishbone lays out possible causes under categories such as the 6 Ms, so a team sees the whole field and not only its first idea. It produces a list of candidates, not an answer: each one still needs a check against facts. Votes can set the order of the checks, not decide the cause. See the 6 Ms of production and how to perform an effective root cause analysis.

Is / is not

For each question about the problem (what, where, when, how much) you also write down the closest place, time or product where it could occur and does not. Any candidate cause that cannot explain the difference is struck out. It is the quickest way to cut a long list down, and it works only if the is-not column is filled from data. The post on is / is not analysis explains the contrast.

Fault tree analysis

Begin from the top event, such as a failure, and ask what could cause it, joining causes with AND and OR gates. It handles combinations that a 5 Whys chain cannot, which is why it is used for safety events and complex equipment. It needs more preparation than the other tools. See fault tree analysis for manufacturing.

A worked example: a label that keeps misprinting

This example is illustrative. It is not a customer case, and it has no figures because the point is the order of the steps. A packaging line applies a printed label to each carton. Every few days a run of labels comes out with the date code misprinted, and a pallet is held back at the end of the line.

1. 1

   Contain

   Hold and sort the suspect pallets, and add a check at the end of the line that the team has proved catches a misprinted date code. The customer is protected before anyone starts looking for a cause.

2. 2

   Problem statement

   "Since the new label roll was introduced, the date code prints cut off on some cartons on line 3, found at the end-of-line check." There is no cause in the sentence and no name in it.

3. 3

   Is / is not

   It is on line 3, not on line 4 with the same printer model. It is on the afternoon shift, not on days. It starts after a roll change. It is not on every roll. Each fact rules some causes out: the printer model alone cannot be the cause, since line 4 prints well.

4. 4

   Five whys

   Why is the date code cut off? The print head is applying too little heat on part of the label. Why? The head is dirty at one edge. Why? Adhesive from the new label stock builds up on it. Why was it not cleaned? The cleaning step is on the day shift checklist and not on the afternoon one. Why? The checklist was written before the roll change brought in the new stock, and nobody owns updating it.

5. 5

   Verify

   Clean the head and the misprint stops; leave the next one dirty on a scrap run and it comes back. The cause explains every is and is not fact: line 4 uses a different roll, and days clean the head.

6. 6

   Action

   Add the cleaning step to every shift's checklist, name the person who updates checklists when materials change, and check the misprint rate on this line for an agreed period before closing.

Notice what the 5 Whys did not do on its own. It never contained the problem or checked the cause, and it ended at a missing owner for the checklist, not at the operator. That last point is the usual sign the chain reached a condition worth fixing.

The same problem could run in a different frame. If the label supplier had to be told, the team would carry the work in an 8D and put the chain above in step D4. If the misprint were a small, rare fault, the whole thing would fit on a PDCA sheet. The tools stay the same; the frame changes with who has to read the result and how much is at stake.

Common mistakes

• Stopping at the first why. "The operator did not follow the procedure" is a stopping point for blame, not a cause. Ask what made the error possible.
• No containment. The investigation takes days, and the customer or the next process is still receiving the defect while it runs.
• Skipping verification. A fix that coincided with a good week looks like a fix that worked. Switch the cause off and on, or compare against the is-not side, before closing.
• Using one tool for every problem. A 5 Whys is a poor fit for a combination of causes, and an 8D is heavy for a one-hour stop.
• Closing without an effectiveness check. Agree what number should come back to normal, and for how long, before you start the fix.
• No standard at the end. If the new way is not written into the work instruction or the checklist, the old way returns.