How to Write a Problem Statement for Root Cause Analysis (with Examples)
- timothyferguson1
- Jun 13
- 4 min read
June 13, 2026
Ask ten people to investigate "the line is having quality issues" and you'll get ten different investigations — most of them wrong. Not because the team lacks skill, but because the problem was never actually defined. A vague, biased, or solution-loaded problem statement is the single most common reason a root cause analysis goes sideways.
The good news: writing a strong problem statement is a learnable, repeatable skill. This post gives you the formula, the two techniques that make it reliable, plenty of good-vs-bad examples, and a free template to start from.
New to RCA overall? Start with our https://www.fsquaredconsultinggroup.com/post/root-cause-analysis-guide, then come back here to nail the first step.
What a problem statement is — and isn't
A problem statement is a short, factual description of what is wrong, for whom, where, when, and how big. That's it. It is not:
- A cause. "Unsealed cartons because the sealer is mis-calibrated" smuggles in a conclusion you haven't proven. If your statement contains the word because, you're probably stating a cause.
- A solution. "We need to buy a new sealer" skips straight to the fix. Capture fixes later, as corrective actions.
- A feeling. "Quality is a mess on Line 3" isn't measurable, so you'll never know if you solved it.
A problem statement's only job is to point the whole investigation at the same, well-bounded target.
The problem statement formula
A reliable structure you can reuse:
[Object/process] is experiencing [observable deviation], seen at [where], since [when], at a rate of [magnitude/metric], resulting in [impact].
You won't always have every element — but aim for at least an object, a measurable deviation, and a timeframe. A quick test of a strong statement: it usually contains a number, a location, and a time reference, and no presumed cause.
Two techniques that make it reliable
5W2H — gather the facts
Answer these before you write the statement:
- What — the object and the deviation (what's wrong, with which item or process)
- Where — the location or process step
- When — since when, and any pattern (shift, day, batch)
- Who — who is affected or who detected it (not who's to blame)
- How — how it shows up or is detected
- How much / how many — the magnitude: rate, count, %, cost, or time
Notice there's no "why." That's deliberate — why is the cause, and the cause belongs in the analysis (the fishbone and 5 Whys), not the definition. Baking a cause into the problem statement is exactly how investigations get anchored to the wrong answer.
Is / Is‑Not — bound the scope
Borrowed from Kepner‑Tregoe, this technique sharpens the edges of the problem by stating what it is and, just as importantly, what it is not:
Dimension | IS | IS NOT |
What | Unsealed top flaps | Crushed or mislabeled cartons |
Where | Line 3, carton sealer | Lines 1 and 2 |
When | Since the May changeover | Before May |
Extent | ~6% of units | The whole product family |
The "is not" column is where the magic happens — it stops a narrow problem from being described as a broad one, and the contrasts often hint at where to look later.
Good vs. bad problem statements
❌ Too vague: "Line 3 has quality problems." ✅ Specific & measurable: "Line 3's carton sealer is leaving the top flap unsealed on ~6% of units, up from <1%, since the May changeover — driving rework and two missed shipments."
❌ Contains a cause: "Cartons are unsealed because operators are rushing." ✅ Neutral: "~6% of Line 3 cartons have unsealed top flaps since the May changeover." (Whether operators, the sealer, or the material is responsible is for the analysis to determine.)
❌ Contains a solution: "We need to recalibrate the sealer to fix carton quality." ✅ Problem only: "~6% of Line 3 cartons ship with unsealed top flaps; target is <1%." (Recalibration may or may not be the answer.)
A quick checklist before you start analyzing
- Does it name a specific object/process and an observable deviation?
- Is it measurable (a number, %, rate, or cost)?
- Does it say where and when?
- Is it free of any presumed cause (no "because")?
- Is it free of any solution (no "we need to…")?
- Could two different people read it and investigate the same thing?
If you can check all six, you're ready to move to the fishbone.
From problem statement to root cause
Once your statement is sharp, the rest of the RCA flows from it: brainstorm possible causes on a fishbone diagram https://www.fsquaredconsultinggroup.com/post/how-to-make-a-fishbone-ishikawa-diagram-step-by-step , drill the strongest one to its root with 5 Whys https://www.fsquaredconsultinggroup.com/post/5-why-examples-and-a-free-template , and document the whole story in an A3 report. https://www.fsquaredconsultinggroup.com/post/how-to-write-an-a3-report A precise definition makes every one of those steps faster and more accurate.
Do it in seconds, free: The F Squared Problem Statement Builder walks you through 5W2H and Is/Is‑Not, drafts a sharp statement for you, checks it for the common mistakes above, and sends it straight into a fishbone. Try it free →
Prefer paper? Download the free RCA Starter Kit — it includes a printable Problem Definition worksheet plus fishbone, 5 Whys, and A3 templates.
Frequently asked questions
What is a problem statement in root cause analysis?
A short, factual description of what is wrong, where, when, and how big — with no presumed cause or solution. Its job is to point the whole investigation at the same, well-defined target.
What is the format of a good problem statement?
A reusable formula: [object/process] is experiencing [observable deviation], at [where], since [when], at [magnitude], resulting in [impact]. Aim for a number, a location, and a timeframe.
Should a problem statement include the cause?
No. The cause is what the analysis is for. If your statement contains the word "because," you've likely stated a cause, not the problem — which biases the whole investigation.
What is 5W2H?
A questioning framework — What, Where, When, Who, How, How much/how many — used to gather the facts behind a problem. In problem definition, "why" is intentionally left out and saved for the cause analysis.
What is Is/Is‑Not analysis?
A Kepner‑Tregoe technique that bounds a problem by listing what it is and what it is not across What, Where, When, and Extent — preventing over-broad or mislabeled definitions.
Comments