A Problem Statement is a concise factual description of the gap between the current condition and the required condition.

A strong problem statement helps the team investigate the right problem.

A weak one can send the team directly toward assumptions, blame, or premature solutions.

Describe the gap

The statement should make clear:

  • what should happen;
  • what is actually happening;
  • how large the gap is.

For example:

Packaging Line 2 should produce 95% first-pass acceptable cases, but averaged 87% during the last four weeks.

This is stronger than:

Packaging quality is poor.

The first statement can be measured and investigated.

Define where the problem occurs

Scope matters.

Useful details may include:

  • process;
  • product;
  • machine;
  • customer;
  • location;
  • shift;
  • transaction type.

5W1H Problem Definition provides a practical structure for describing what, where, when, who, why it matters, and how the problem is observed.

Define when the problem occurs

Time can reveal important patterns.

Ask:

  • When did the problem begin?
  • Is it continuous or intermittent?
  • Does it occur on a specific shift?
  • Is it tied to a product or supplier lot?
  • Is there a seasonal pattern?

Change Point Analysis can be useful when the problem appeared or changed significantly at a known time.

Quantify the impact

The statement should explain why the problem matters.

Possible impacts include:

  • safety risk;
  • customer complaints;
  • scrap;
  • downtime;
  • delay;
  • cost;
  • capacity loss.

The impact creates a reason to solve the problem without prescribing the solution.

Keep causes out of the statement

Avoid statements such as:

Defects increased because operators are not following the procedure.

Unless the cause has already been verified, this embeds an assumption into the problem definition.

A better statement describes the observed gap and allows the investigation to determine why it exists.

Root Cause Analysis should verify causal relationships after the problem has been defined clearly.

Keep solutions out of the statement

Avoid:

We need a new inspection station.

That is a proposed countermeasure, not a problem statement.

The real problem may be:

Customer escapes increased from 0.4% to 1.7% during the last six weeks.

Separating the problem from the preferred solution protects the investigation from confirmation bias.

Use evidence

The statement should be supported by:

  • process data;
  • physical observation;
  • customer records;
  • quality data;
  • maintenance history.

Operational Definition helps ensure the measure is interpreted consistently.

The team should be able to trace the statement back to evidence.

Keep the scope solvable

A statement such as:

Improve plant performance.

is too broad for structured problem solving.

A useful scope is large enough to matter but narrow enough for the team to investigate and influence.

A3 Problem Solving depends on a clear initial problem definition so the current condition and cause analysis remain focused.

Common mistakes

Using vague language, embedding an assumed cause, embedding a solution, using no baseline, making the scope too broad, relying only on opinion, and confusing the symptom with the full problem are common mistakes.

Practical sequence

  1. define the expected condition.
  2. define the actual condition.
  3. quantify the gap.
  4. identify where it occurs.
  5. identify when it occurs.
  6. define the impact.
  7. remove assumed causes.
  8. remove proposed solutions.
  9. verify the evidence.
  10. confirm the scope is actionable.

The practical lesson

A strong Problem Statement creates discipline before analysis begins.

Define the gap clearly enough that the team can investigate facts instead of debating what problem it is trying to solve.

This topic also connects with Problem Priority Matrix. Use that method when the improvement requires the related operating or management discipline.