A Problem Definition Quality Review checks whether a problem is defined clearly enough to begin meaningful analysis.
The purpose is not to make the wording elegant. The purpose is to ensure the team is solving an observed gap rather than a vague concern, assumed cause, or preferred solution.
Start with the gap
A strong definition shows the difference between expected condition and actual condition.
Problem Statement helps describe the gap using observable facts.
Weak examples include “operators need training,” “supplier quality is poor,” or “machine is unreliable.” These statements may already contain assumptions about cause.
Define where the problem occurs
5W1H Problem Definition helps organize what, where, when, who, why, and how information.
Useful location detail may include process step, machine, product family, shift, or customer segment.
Specific location helps reduce the search space.
Define timing and pattern
Ask when the problem began, whether it is continuous or intermittent, whether it is tied to a change point, and whether it occurs by shift, product, or condition.
Problem Stratification helps separate broad performance gaps into more specific patterns.
Averages can hide the real problem population.
Define the scope boundary
State what is included and excluded.
Is-Is Not Analysis helps compare where the problem is present and absent.
This prevents analysis from expanding into every related issue.
Separate facts from assumptions
List what is known from evidence and what is still suspected.
Problem Solving Evidence Plan helps identify what evidence is required before strong causal conclusions are made.
Avoid starting root-cause analysis with the suspected cause embedded in the problem statement.
Quantify the condition
Where practical, include frequency, magnitude, rate, duration, or customer impact.
The level of quantification should match the decision risk.
Check whether the problem is actionable
A problem may be too broad if the team cannot identify where to observe the condition or what evidence would show improvement.
Refine the definition before generating causes.
Common mistakes
Embedding the cause in the statement, using broad labels such as “quality issue,” mixing several problems together, defining no scope boundary, relying on averages, starting analysis without evidence, and rewriting the problem after the team discovers an easier issue are common mistakes.
Practical sequence
- define expected condition.
- define actual condition.
- quantify the gap.
- define where it occurs.
- define when it occurs.
- stratify useful patterns.
- define what is and is not included.
- separate facts from assumptions.
- identify missing evidence.
- begin causal analysis only when the problem is observable and bounded.
The practical lesson
Problem Definition Quality Review improves the work before root-cause analysis begins.
A well-defined problem gives the team a smaller, evidence-based search space and reduces the risk of solving the wrong issue.