A problem statement says what is wrong, where, how much and since when, in numbers and facts, without a cause, a name or a fix in it. It is the first thing written on an 8D or corrective action, and everything after it is judged against it. If a stranger could read it and go and find the same problem, it is good. If it already blames someone or already names the cause, it is not a problem statement yet.
Why this one paragraph matters
Most weak 8Ds are weak at line one. The problem is written as “quality issue on housings” or “operator error on line 3,” and the whole report builds on that fog. The containment is too wide or too narrow. The root cause drifts. The effectiveness check has nothing to measure against. A sharp problem statement fixes all of that before you start.
It also does a second job. It is the sentence your customer, your supplier and your own team all read first. Get it right and they stop asking you what happened.
What goes in it
- What. The part number and the defect, in words that match the drawing or the spec. “Burr on the cross hole,” not “bad parts.”
- How much. The count and the size of the sample. “14 of 240,” not “some.” Add the size of the defect if it is measurable.
- Where it was found. At the customer, at final inspection, in process, at receiving. This tells everyone how far it escaped.
- When. The date it was found, and the first date you know it could have started, such as a date code, a lot or a change.
- Where it is not. What you checked and found good: other lots, other lines, parts made before the change. This is what narrows the search, and most people skip it.
- The requirement. What the part was supposed to be. “Drawing calls for 0.2 mm maximum burr height.”
What stays out
- A cause. “Scratched because the totes have no dividers” is a guess in a statement’s clothing. Causes come later and need proof.
- A name or a team. “Night shift missed it” turns the report into a blame list. Say what happened and where, not who.
- A fix. “Needs better packaging” closes the question before you have asked it.
- Adjectives. Terrible, major, serious, frequent. If it matters, put a number on it.
A bad one and a good one
These are made-up examples, but they are close to what lands on a quality manager’s desk.
| Statement | What is wrong or right | |
|---|---|---|
| Bad | Housings are scratched again. Operators need to be more careful with the parts. | No count, no date, no part number. Names a cause and blames a group. |
| Good | On October 6, the customer rejected 14 of 240 housings, part 4471-B, for a scratch longer than 12 mm across the sealing face. Drawing allows no scratches on the sealing face. All 14 were packed after September 28. Lots packed before that date show no scratches. Final inspection records for the rejected lot show all parts passed. | Says what, how many, where found, the requirement, when it started and where it is not. Says nothing about cause. |
Look at the last two sentences of the good one. They are what tell the team to look at packing and not at machining, and they cost nothing to write.
How to write it
Go and look at the part
Handle it. Measure it. Take a photo with something for scale. A problem statement written from an email is a statement about the email.
Write the facts in plain sentences
What, how much, where found, when, and the requirement. One sentence each is enough.
Add where it is not
Check at least one good lot, one other line or one earlier date, and write down what you found.
Strip out cause, blame and fix
Read it once looking only for those three. If any is there, cut it and move it to your notes for later.
Run the stranger test
Hand it to someone who was not there. Could they find the same defect from this alone? If they would have to ask you a question, answer that question in the statement.
Keep it fixed unless the facts change
If you learn the problem is bigger, update it and write down the date and why. Do not quietly rewrite it to match a theory.
Mistakes that make a statement useless
- Copying the customer’s wording. “Quality issue” is their summary, not your measurement. Restate it from the part.
- No denominator. “14 scratched housings” could be 14 of 20 or 14 of 20,000.
- No requirement. Without the spec, no one can say whether the part is wrong or the drawing is.
- Several problems in one sentence. Two defects usually have two causes. Write two statements and run two analyses.
- Writing it last. A statement written after the 8D is finished describes the answer, not the problem.
The Free 8D starter form has a place for it at the top, and the 8D Corrective Action Form carries it through every section. For logging the complaint it came from, see the RMA Customer Complaint Log.
Questions people ask
How long should a problem statement be?
A short paragraph. Three to six sentences is usually enough. If it takes a page, you are explaining, not stating.
What is the difference between a problem statement and a problem description?
In practice the terms are used loosely. What matters is that it is factual, measurable and free of cause, blame and fix.
Should the problem statement include the root cause?
No. The root cause is the answer, and it comes after investigation. Putting it in the statement shuts down the investigation.
Can I change the problem statement later?
Yes, if the facts change, such as more affected lots. Record what changed and when, so the history is clear.
What is an is/is not analysis?
A simple comparison of where the problem is and where it is not: which parts, lots, lines, dates and places. The “is not” side is what points to the cause.