White Belt · 12 min
Writing a problem statement that does not contain its own answer
After this you can
- write a problem statement that contains no cause, no solution and no blame.
- tell a problem statement apart from a goal statement and write both for one issue.
Assumes you have done DMAIC: what each phase produces and why the order holds.
The problem
A hospital team spent four months implementing a new scheduling system because their project charter said: "Clinic waiting times are too long because the scheduling system is outdated." The new system went live. Waiting times did not move. The cause had been decided in the first sentence of the project, before anyone measured anything — and every month after that was spent proving a conclusion rather than finding one.
The idea
A problem statement says what is wrong, where, since when, and how big. That is all.
It must not contain:
- a cause — "because the scheduling system is outdated". You do not know that yet. That is what Analyze is for, and writing it down at the start quietly ends the investigation.
- a solution — "we need a new booking system". Same failure, one step further along.
- blame — "because reception staff are slow". Now nobody will help you.
The test is mechanical: read your statement and look for the word because, for any verb that proposes an action, and for any noun that names a person or team. If one is there, you have written a conclusion.
A good statement is uncomfortably empty. It should feel like it says less than you know, because at Define you genuinely do know less than you think.
Problem statement and goal statement are different sentences. Teams collapse them constantly, and the collapse is what smuggles the solution in.
- The problem statement describes the present, with evidence. "Between January and June, 34% of outpatients waited more than 60 minutes between arrival and being seen, against a target of 15%."
- The goal statement describes the desired future, with a number and a date. "Reduce the proportion waiting more than 60 minutes from 34% to 15% by 31 December."
Notice what neither contains: any statement about how. The how is the output of the project, not its input. If you already knew the how, you would not need a project — you would need a work order.
One more property worth insisting on: a problem statement should be checkable by someone who disagrees with you. "Waiting times are too long" is not checkable. "34% waited more than 60 minutes, measured from arrival timestamp to first clinical contact, January to June" is — and if it is wrong, someone can show you that it is wrong, which is exactly what you want to happen at the cheapest possible moment.
Worked example
Start with what the team actually said out loud:
"Waiting times are terrible because reception is understaffed and we need to hire two more people."
Three separate faults in one sentence. Take them out one at a time.
Remove the solution. "We need to hire two more people" is the answer to a question nobody has asked yet.
"Waiting times are terrible because reception is understaffed."
Remove the cause. "Because reception is understaffed" is a hypothesis. It may even turn out to be right — but it is Analyze's job to establish that, and stating it here means the Measure phase will only collect data that could confirm it.
"Waiting times are terrible."
Replace the judgement with evidence. "Terrible" is a feeling — the blame came out at the previous step. Replace it with what was measured, over what period, against what expectation.
Problem statement. "Between 1 January and 30 June, 34% of outpatients waited more than 60 minutes between arrival and first clinical contact, against a service standard of 15%. This affects approximately 4,200 patients per year."
Now the goal, as a separate sentence:
Goal statement. "Reduce the proportion of outpatients waiting more than 60 minutes from 34% to 15% by 31 December, without increasing clinic cost per patient."
Read the pair back. You now have a project that could discover that reception staffing has nothing to do with it — which the original sentence had made impossible.
And note the constraint in the goal: without increasing cost per patient. A goal with no constraint can always be met by spending money, which is not usually what anyone meant.
Your turn
Open the Problem Statement Builder and paste in a problem from your own work — a real one, written the way you would normally say it.
The tool flags causal connectives, solution verbs and person-attribution. It does not score you; it points at words. Rewrite until nothing is flagged, then write the goal statement separately and check that the how appears in neither.
If you cannot state the size of the problem, that is a finding rather than a failure. It means Measure has work to do, and you now know what.
Problem Statement Builder
practiceWhat is wrong, where, since when, and how big. Nothing else.
A baseline, a target and a date. Never the method.
These are prompts, not rules. This tool matches patterns in English and English will defeat it — a sentence can contain “because” innocently, and can smuggle a cause with no keyword at all. If you have read a flag and disagree with it, you are probably right. There is no score here on purpose.
Saved runs can be attached to a project deliverable as evidence. Both what you entered and what the tool computed are stored, so the result can be checked again later.
Check yourself
No hints. Wrong answers are explained, not softened.
Which of these is a usable problem statement?
A team writes: 'Reduce call handling time from 8.5 minutes to 6 minutes by Q4 by introducing a new call script.' What is wrong with it?
Which pair correctly separates problem from goal?
Apply it
Your operations director says: "Our returns rate is out of control because the packing team is rushing, and we need to slow the line down."
Write the problem statement and the goal statement you would put in the charter, and note one thing you would need to measure before you could write either properly.
Your answer is reviewed against a rubric, not matched to a keyword.
Worth remembering
What must a problem statement NOT contain?
A cause, a solution, or blame. If it contains 'because', an action verb, or a team name, it is a conclusion.
Problem statement vs goal statement
Problem describes the present with evidence. Goal describes the desired future with a number and a date. Neither says how.
The checkability test
A problem statement should be verifiable by someone who disagrees with you. If they cannot go and check it, it is an opinion.
Can you do this now?
Rate yourself honestly. We compare your rating with how you actually answered — the gap is more useful than either number alone.
I can write a problem statement that contains no cause, no solution and no blame.
I can tell a problem statement apart from a goal statement and write both for one issue.
Your rating is recorded alongside your drill results. Neither alone marks the competency as met.