Knowledge Base · Tools & Terms
How do I write a good problem statement?
A good problem statement describes the gap between how things are and how they should be, with evidence, and names who is affected, where and when it happens, and what it costs. It contains no solution and no blame. If your statement argues for a fix, it is a proposal wearing a problem statement's clothes.
The CI Foundations course teaches problem statements with one rule up front: write the problem without smuggling in a solution. "We need a new ticketing system" is a solution. The problem underneath it might be that enquiries wait unassigned, customers chase for replies, and staff lose time searching threads. A team that starts from the solution can only debate that solution; a team that starts from the problem can find the best one.
Cover five elements. What is happening, stated as observable fact. Who is affected: customers, a team, a process downstream. When and where it happens, so the scope has edges. The impact, quantified where you can: time, cost, errors, complaints. The evidence behind each claim, so the statement rests on observation rather than frustration. The Solve pathway in ClarionEX uses the same shape: what, who, when, where, and the impact, in the form "In [timeframe], [what is happening] affecting [who]. This impacts [metric] by [how much]."
- State facts you have seen or measured, not opinions about why it happens. Causes come later, in root cause analysis.
- Name the gap: current performance against the standard or the customer's expectation.
- Keep the scope honest. One process, one problem. A statement that covers everything commits the team to nothing.
- Leave out people's names as causes. Statements that blame a person teach the team to hide problems from you.
The free Problem Statement Builder on this site walks the same ground: define the gap, evidence, impact, scope, and owner so the team solves the cause instead of chasing symptoms. A statement built this way becomes the first line of everything that follows: the 5 Whys starts from it, the project charter quotes it, and the final results are measured against it.
Draft one in the free Problem Statement Builder
Related questions
- What's the difference between a symptom and a root cause?
- How do I decide which problem to solve first?
- What is DMAIC, and when should I use it?
Source: Continuous Improvement in the Workplace, Ch. 3 and Ch. 4; ADX site content: the Problem Statement Builder.