5W1H is a simple structure for defining a problem before investigating its causes.

The letters typically represent:

  • What;
  • Where;
  • When;
  • Who;
  • Which;
  • How.

Some organizations use slightly different wording, but the purpose is the same:

Describe the problem with observable facts before asking why it happened.

Why problem definition matters

Poorly defined problems create poor investigations.

Statements such as these are too vague:

  • quality is bad;
  • the machine keeps failing;
  • customers are unhappy;
  • delivery is late;
  • operators are making mistakes.

They contain judgment but little diagnostic information.

A stronger problem definition narrows the condition.

For example:

On Line 3, Product A shows a surface scratch at Station 40, primarily on the night shift, beginning after the tooling change on July 8.

That description does not explain the cause.

It tells the team where to investigate.

What?

Define exactly what is wrong.

Ask:

  • What object, product, service, or process is affected?
  • What defect or abnormal condition is observed?
  • What requirement is not being met?
  • What is the magnitude?

Use facts.

If the problem is dimensional, include the measured value and specification.

If the problem is downtime, include the lost function and duration.

Where?

Identify the physical or process location.

Ask:

  • Which plant?
  • Which line?
  • Which machine?
  • Which station?
  • Which process step?
  • Which customer location?
  • Which system screen or transaction step?

Location can sharply narrow possible causes.

When?

Time patterns often reveal important clues.

Ask:

  • When did the problem first appear?
  • Is it continuous or intermittent?
  • Does it occur on a particular shift?
  • Before or after changeover?
  • At startup?
  • After maintenance?
  • During a specific product mix?
  • At a certain time of day?

The timing relationship may point toward process conditions that should be investigated.

Who?

“Who” should describe involvement, not blame.

Ask:

  • Which customer group is affected?
  • Which role performs the work?
  • Which shift?
  • Which supplier?
  • Which team handles the transaction?

Avoid turning the question into “Who caused this?”

The purpose is stratification.

Which?

“Which” helps compare affected and unaffected conditions.

Ask:

  • Which product families are affected?
  • Which machines?
  • Which tooling?
  • Which material lots?
  • Which suppliers?
  • Which work methods?
  • Which conditions are not affected?

This comparison can be especially powerful.

If Product A fails but Product B does not, the difference between them may contain useful causal information.

How?

Describe how the problem appears or how it is detected.

Ask:

  • How is the defect observed?
  • How does the failure develop?
  • How often does it occur?
  • How is it measured?
  • How large is the gap?
  • How does the condition differ from normal?

This connects problem definition to measurable evidence.

5W1H comes before 5 Whys

5 Whys is used to investigate causal mechanisms.

5W1H is used to define the problem.

If the team begins asking “why” before defining what, where, and when, the investigation can become speculation.

A strong sequence is:

  1. Define the problem with 5W1H.
  2. Observe the actual condition at the Gemba.
  3. Stratify the data.
  4. Generate possible causes.
  5. Investigate and verify causes using Root Cause Analysis.

Use is / is not thinking

A useful extension is to compare where the problem is and where it is not.

For example:

  • occurs on Machine 2;

  • does not occur on Machine 1.

  • occurs after warmup;

  • does not occur at startup.

  • occurs with Supplier B material;

  • does not occur with Supplier A material.

The differences between affected and unaffected conditions can narrow the investigation.

Common mistakes

Including the assumed cause in the problem statement

“Operator error causes scratches” is already a conclusion.

Using emotional language

“Terrible quality” is not measurable.

Defining the problem too broadly

“Delivery performance” may cover many different failure modes.

Asking why too early

First establish the facts.

Ignoring unaffected conditions

What does not fail can be as informative as what does.

Practical problem statement

A strong problem statement usually includes:

  • the affected object or process;
  • the requirement;
  • the actual condition;
  • location;
  • timing;
  • magnitude;
  • relevant comparison.

It should describe the gap without claiming an unverified cause.

The practical lesson

5W1H slows down one of the most expensive habits in problem solving: jumping to causes before the problem is clearly defined.

Define the condition first.

Then investigate why it exists.