Problem Solving & Quality · State

Deviation Statement

Write one sentence: object, defect, expected value, observed value, since when. No cause, no culprit, no solution inside.

Time20 min
FormatSolo
StageState

Deviation Statement: what it is and why it works

A deviation statement expresses a problem as the gap between what should happen and what does happen, in a single sentence. It names the object precisely, describes the defect in observable terms, gives the expected and observed values with units, and states since when and how often, with the source of the data. It deliberately leaves out any cause, any person and any solution. The result is a statement that anyone on the team can check against records and that does not steer the analysis toward a favored answer.

The method works because the wording of a problem shapes the search that follows. 'Maintenance is not greasing the conveyor bearings' already names a culprit and a fix; 'Conveyor C-7 tail-pulley bearings have failed four times in 12 weeks against an expected life of several years' leaves room for the real cause to emerge. A quantified gap also provides the baseline for closure criteria and the headline of an A3 report. Compared with a free-text description, a deviation statement is faster to review and harder to dispute. It usually follows 5W2H, which gathers the facts, and comes before Is / Is-Not, which adds contrast.

What you need

The problem description from 5W2H or the initial report
The applicable standard, specification, design value or target
Measured data with units, dates and source
Exact identification of the object: part number, equipment tag, product grade or process step

What you get

A one-sentence deviation statement with expected and observed values
A documented data source for the observed value
A baseline figure reusable for closure criteria and the effectiveness check
A shared problem definition that the team has heard read aloud and accepted

When to use it

When the problem statement already contains its favorite solution.

How to do it, step by step

Name the object precisely: part number, equipment tag, product grade or process step.
Name the defect in observable terms: “turbidity above limit”, not “bad water”.
Write the expected value or standard and the observed value, with units.
Add since when and how often, with the source of the data.
Delete every word that suggests a cause, a person or a solution, then read it aloud to the team.

Worked example: Gloss complaint on a black automotive compound

Illustrative scenario — figures are realistic but not from a real company.

A plastics compounder producing black talc-filled polypropylene for automotive interior trim receives a customer complaint about shiny parts. The first internal write-up reads: 'The new colorant supplier is causing gloss problems; switch back.'

Object: the team replaced 'gloss problems' with the grade and property concerned: compound PP-T20 black, 60-degree gloss measured on molded test plaques.
Defect and values: the customer specification is 2.5 to 3.5 gloss units (GU); lab records show 4.1 to 4.8 GU on affected lots.
Since when and how often: the QC gloss log showed the first out-of-spec lot on June 3, and 7 of 19 lots out of specification since then.
Cleanup: the words 'new colorant supplier' and 'switch back' were deleted because they asserted a cause and a solution nobody had shown. The final sentence read: 'Compound PP-T20 black: 60-degree plaque gloss 4.1 to 4.8 GU against a 2.5 to 3.5 GU specification on 7 of 19 lots since June 3 (QC gloss log).'

Result. With the cause removed from the wording, the team reviewed all changes since late May and found that the colorant change coincided with a change of talc grade. Plaque trials pointed to the talc, not the colorant. Switching back to the old colorant, the original proposal, would have cost a qualification cycle and fixed nothing.

Open it in the FieldKit Problem Solving app → Get the Problem Solving template pack — join the waitlist

Common pitfalls and how to avoid them

Hiding a cause in the defect wording, such as 'contamination' or 'operator error'.Describe what is measured or seen, for example 'black specks above 0.2 mm on 5% of parts', and let the analysis find the cause.
Leaving out the expected value.If no written standard exists, state the design value, the customer requirement or the historical baseline, and say which one you used.
Packing several problems into one sentence.Write one statement per deviation; if two defects share a cause, the analysis will show it.
Using vague time words like 'recently' or 'always'.Give a start date and a frequency from records; if the start is unknown, say from when data is available.

Frequently asked questions

What should a problem statement include?

A good problem statement names the object, the observable defect, the expected value or standard, the observed value with units, and since when and how often the problem occurs, with the data source. It leaves out causes, blame and solutions. If a reader can check every element against a record, the statement is precise enough to start the analysis.

What is the difference between a problem statement and a deviation statement?

In practice they are often the same thing. 'Deviation statement' stresses one specific form: the gap between an expected standard and an observed result. Many problem statements are looser and describe symptoms, business impact or even proposed actions. Writing the problem as a deviation forces both the expected and the observed value into the sentence, which makes it measurable and harder to argue with.

Should the problem statement include the business impact?

Keep the core statement factual and short, and record impact separately: cost, customer risk, safety exposure, hours lost. Impact justifies priority and resources, and it belongs in the project charter or the background section of an A3. Mixing it into the deviation sentence tends to make the statement long and emotional, which works against the neutral tone the method depends on.

Origin

Problem defined as a deviation from an expected standard — Kepner–Tregoe problem analysis (1965); also central to Toyota problem-solving practice.

Used in these playbooks

Customer complaint closure 4 weeks

Four weeks to answer a complaint the way customers expect: a structured 8D, a clean problem statement, causes of occurrence and escape, an error-proof fix and deployment to sister lines.

Related methods

More in “State”

Describe the problem as a measurable gap — no cause, no culprit, no solution yet.