Solving problems

Start with a problem statement

A good problem statement is a measured and scoped gap between the standard and the current condition. It says what is happening, where, when and how much. It leaves out the cause, the blame and the solution. Those come later, and putting them in early closes the question before you've looked.

Compare three statements about the same trouble:

• "We need a second packaging scale." That is a solution.
• "Packaging staff are careless with labels." That is blame.
• "Label errors are too high." That is vague: too high compared with what, and where?

Now a real one:

If you can't state the problem in a sentence or two with a number in it, you don't yet know enough to start solving it. Go and look first, as in Lesson 2.

Plan, do, check, act: try it small

PDCA is a loop for changing things carefully:

1. Plan: decide what to change and what result you expect.
2. Do: try it, on a small scale first.
3. Check: compare what happened with what you expected.
4. Act: keep it, adjust it or drop it, and go round again.

The idea goes back to Walter Shewhart's 1939 book. It reached Japan through W. Edwards Deming's lectures. Many people credit Deming with "Plan-Do-Check-Act", but he credited Shewhart, and said the Plan-Do-Check-Act wording was a later change by others. Deming later taught Plan-Do-Study-Act, because "check" can sound like holding something back and "study" means looking at what you learned. You'll see both names. The idea is the same: a change is a test, not a decree.

Trying a change small is the point. A small trial costs little if it's wrong, and teaches you a lot if it's right.

Contain first, then find the cause

When something has gone wrong, there are different kinds of response, and they do different jobs:

• Containment protects the customer while you look for the cause: hold the suspect product, stop the shipment, segregate it.
• A correction repairs the thing that went wrong: rework it, adjust it, replace it.
• A corrective action removes the cause, so the problem doesn't come back.
• A preventive action removes the cause of a problem that hasn't happened yet.

The FDA's quality guidance for drug makers uses the last three terms in just this way. Toyota says countermeasure. One way to read the word: a response to a cause you've tested, not a final answer.

Stopping at containment is a common mistake. Fixing this jar, this batch or this count doesn't fix the reason it happened.

In a licensed operation, some clocks don't wait for you

• Incidents. The regulations require notice to the Commission and law enforcement immediately and within 24 hours of listed events, including inventory discrepancies. A written incident report is due within ten days, and it includes the corrective action taken (935 CMR 500.110(9)). An unusual weight, count or inventory discrepancy in transport is also reported within 24 hours (500.105(13)(b)). Don't wait for your analysis to be finished before you report. Ask your compliance lead what counts as reportable at your site.
• Failed contaminant tests. The rules limit what you can do: reanalyze, with a confirming test at a second lab, remediate with a new full-panel test a limited number of times, or dispose (500.160(13)). If a batch can't be remediated, the Commission has to be told within 72 hours (500.160(4)). The Commission plans to rewrite its testing rules, with a draft vote targeted for December 2026 and a final vote for March 2027, so check the current text. Don't retest over and over until a batch passes. Testing for yeast and mold is known to vary between labs and between states, so a passing retest doesn't prove the first result was wrong.
• Recalls. Cultivators and manufacturers must have written voluntary and mandatory recall policies (500.120(12)(b), 500.130(5)(b)).

935 CMR 500 doesn't use the words "root cause" or "CAPA." The nearest phrases are an "assessment of the source of contamination" (500.160(4)) and the "corrective action taken" in the incident report. A written record of containment, cause, fix and check is your evidence trail. Lean adds the learning loop and one named owner.

Five whys, and when they mislead

The 5 whys is a way of asking "why?" about a fact you've checked, until you reach a cause you can change in the system. Taiichi Ohno's well-known example starts with a machine that stopped. The chain ran through a blown fuse, a dry bearing and a worn pump shaft, to a missing strainer that let scrap into the pump. Fitting the strainer fixed more than replacing the fuse.

"Five" is not magic. The Lean Enterprise Institute says the number is arbitrary, and that the method suits problems where something has drifted from a known standard. Critics also point out its limits: it follows one path, stops where you stop, and tends to find a single root cause when there may be several.

Two rules keep it honest:

• Check each answer. Go and look, count or read the record. A "why" nobody has checked is a guess.
• Don't stop at a person. "Human error" is a place to start asking, not a place to stop. Errors follow conditions, and the same errors repeat in patterns. The tools, the lighting, the workload, the humidity, the checks and the training are all conditions. FDA guidance on out-of-specification results says not to attribute a result to analyst error until an investigation clearly shows it. Training and reminders are among the weakest fixes, because the next person in the same conditions makes the same mistake.

The fishbone and the A3

The fishbone

A fishbone diagram, credited to Kaoru Ishikawa, sorts possible causes under categories that point at one problem. Common categories are people, machine, material, method, measurement and environment. It is good for getting a team to think widely.

But it lists possibilities, not evidence. The longest branch is not the cause. If nine items sit under Method and two under Machine, that tells you what people thought of, not what happened. Pick the likeliest causes, and test each against data or what you observe.

The A3

An A3 is one sheet of paper, about 11 by 17 inches, that tells the story of a problem. John Shook's description of the parts: a title, owner and date, background, current conditions, goals, analysis, proposed countermeasures, a plan, and follow-up. The format is flexible. Authors Sobek and Smalley argue that the thinking the page forces matters as much as the page. And Toyota doesn't write one for every problem. Simple problems get simpler forms.

If you use an A3, treat it as a way to tell the problem story to a person, not a form to fill. The conversation around it is where the learning happens.

Did it work?

Checking whether a change worked has two parts:

• Compare the result with the problem statement's own measure, over enough time. If the problem was "2.3% of jars mismatched," you check the same measure, the same way, for long enough to mean something. One good batch is not proof.
• Check the new method is actually in use. A result without the change in place may be luck, and a change that isn't used can't have caused the result.

A run chart helps. Plot the measure by week. Three patterns are signals worth acting on: six or more points in a row on one side of the median, five or more in a row rising or falling, and a single extreme point. Toyota's own problem-solving practice ends with evaluating both the result and the process, and the FDA asks drug makers to evaluate the effectiveness of a corrective action.

If the check shows the problem is still there, that's useful. Go round the loop again.

The arithmetic: a problem, start to finish

Everything below is made up to show the steps, including the events.

Notice the one extra mismatch in the six weeks. A good check doesn't promise zero. It shows the pattern changed, and the process check shows why.

Knowledge check

Your task: write a problem statement

This is a 30-minute walk, not a project. Solve nothing.

1. Pick one small problem you have seen recur: a reprint, a count mismatch, a stockout.
2. On one page, write the standard, then the current condition with one measure, where and when, and how you know.
3. Go and watch or count for ten minutes, or read an existing log.
4. Write three "why" questions you would ask. Answer none of them, and propose no fix.
5. Circle any word in your statement that is blame or a solution.

Use no names and no company figures.

Open the printable problem sheet

Sources

Where the facts in this lesson come from. Facts last checked October 1, 2026. If you find one that is out of date or wrong, tell me.

• Moen and Norman, Circling back: clearing up myths about the Deming cycle, Quality Progress (2010)
• Shook, Managing to Learn, chapter 1 (Lean Enterprise Institute, 2008), for the parts of an A3
• Lean Enterprise Institute lexicon: A3 report, with 5 whys and PDCA
• LaHote, Why effective problem solving begins with a good problem statement (LEI, 2015)
• Smalley: does Toyota write A3 reports for every problem?, and Toyota Business Practice
• Card, The problem with "5 whys", BMJ Quality and Safety (2017)
• Peerally and others, The problem with root cause analysis (2017), and Reason, Human error: models and management, BMJ (2000)
• Perla, Provost and Murray, The run chart: a simple analytical tool for learning from variation in healthcare processes (2011)
• FDA, Guidance for industry: quality systems approach to pharmaceutical CGMP regulations (2006), and Investigating out-of-specification test results (2022), used as analogies only
• 935 CMR 500, adult-use marijuana regulations (effective September 11, 2026): 500.105(13), 500.110(9), 500.120(12), 500.130(5) and 500.160
• Antoszewski and others (2026), Clinical Therapeutics: yeast and mold testing of cannabis across states
• Cannabis Control Commission: regulatory overhaul (September 2026)