How To Write A Problem Statement: Examples & Template

Quoted on this wiki

Every place a page here uses this source, in the order the words come in it.

1. 06 Remove causes, blame and solutions Read the draft again and remove anything that explains the cause, assigns responsibility or recommends what should be done next. Watch for words and phrases such as because, caused by, operator error, poor maintenance, lack of training, need to, should replace or must automate. These may eventually prove relevant, but they belong to the cause-analysis or countermeasure stages. For example: Too early: Poor maintenance caused Line 3 to stop repeatedly. Evidence-led: During first shift in the first five working days of May, Line 3 recorded four unplanned main-drive stops totalling 127 minutes of downtime against a target of no more than 30 minutes. Check: Could several different causes still explain the problem described by the statement? If the wording points the team toward only one explanation, it may already contain an assumption. Output: A problem statement that remains open to investigation. Example: Replace “poor maintenance caused repeated stops” with the recorded drive-stop condition. “If a fact cannot yet be supported, identify it as an evidence gap rather than hiding the uncertainty with confident wording.” Move from a confirmed standard and observable condition to a bounded, measured and verified statement that remains open to causal evidence.

   In Credibility in cold emails

2. What is a problem statement? “A problem statement is a concise, factual description of the gap between the performance that should be happening and what is actually happening. It gives the team a shared starting point for investigation without assuming the cause, assigning blame or prescribing a solution.” In practical terms, a useful problem statement identifies four things:

   In Problem and outcome framing

3. In practical terms, a useful problem statement identifies four things: “Expected condition: What standard, target or requirement should have been met?” Actual condition: What was observed or measured?

   In Problem and outcome framing

4. Expected condition: What standard, target or requirement should have been met? “Actual condition: What was observed or measured?” Gap: How large or frequent was the difference?

   In Problem and outcome framing

5. Actual condition: What was observed or measured? “Gap: How large or frequent was the difference?” Scope: Where and when did the problem occur?

   In Problem and outcome framing

6. Gap: How large or frequent was the difference? “Scope: Where and when did the problem occur?” The practical rule is simple: define the gap before trying to explain it.

   In Problem and outcome framing

7. Scope: Where and when did the problem occur? “The practical rule is simple: define the gap before trying to explain it.” Factual problem statement: During the first five working days of May, Line 3 experienced four unplanned drive stops, causing 127 minutes of downtime against a target of no more than 30 minutes.

   In Problem and outcome framing

8. How and why it matters: How large is the gap, and what consequence does it create? “Use a count, rate, duration, percentage, value or another suitable unit. Keep impact separate when its calculation is not yet supported by evidence.” Evidence source and status

   In Quantified outcome proof

9. The actual condition is observable The wording describes what happened rather than what the team believes caused it. “The boundary is explicit The product, process, population, location and relevant operating boundary are clear.” The period and pattern are defined The reader can tell when the data was collected and what frequency or sequence is being examined.

   In Territory design

Quotes are verbatim and belong to their publishers. Where a quote has been translated, the original wording is kept below it.