What is a Problem Statement Template?
A problem statement is a concise, factual description of a problem — what is happening, where, how often, and what the impact is. It does not include causes or solutions. It is written in plain language and supported by data.
A strong problem statement does three things: it focuses the team on the right problem, it prevents jumping to solutions, and it gives the sponsor a clear picture of what is broken and why it matters.
It is the first output of the Define phase and forms the basis for the goal statement, the business case and the project scope. Get this wrong and everything that follows is built on the wrong foundation.
When to use a Problem Statement Template
Write a problem statement before you do anything else on a project. Use this template when:
- You are starting a DMAIC project and need to define the problem clearly before scoping
- Different stakeholders have different views on what the actual problem is
- The team is already discussing solutions and needs to step back to the problem
- You need sponsor sign-off and they want to understand what is actually broken
Who should use a Problem Statement Template
- Green Belts and Black Belts — as the first written deliverable of any DMAIC project
- Yellow Belts — for smaller scoped improvements where clear problem definition is needed
- CI Coaches and Facilitators — to help project teams who are stuck in solution mode
- Operations and Quality Managers — when commissioning improvement work from a team
How to write a strong problem statement
A good problem statement answers four questions: What is happening? Where and when? How big is the problem? What is the impact? Use data to answer all four before you write a single sentence.
How to write a strong problem statement — step by step
-
1Start with what, not why
Describe the symptom — what is actually happening — without stating causes. 'Machine downtime is averaging 4.2 hours per shift' is correct. 'Machine downtime is caused by poor maintenance' is not.
-
2Anchor it in data
Find the number that proves the problem exists. Average, frequency, rate, cost — whatever is measurable. A problem statement without data is an opinion.
-
3State where and when
Be specific about the location, time period, product line or team. 'At the Birmingham site, Monday to Friday, January to March 2026' is specific. 'In our operations' is not.
-
4Quantify the impact
What does this cost? How many customers are affected? How many complaints, escalations or failures does it produce? The business case depends on this number.
-
5Remove causes and solutions
Read it back and remove any word that implies a cause ('because', 'due to') or a solution ('we need to', 'by implementing'). Save those for later phases.
-
6Test it with someone outside the team
Read it to someone who does not know the project. If they understand the problem without asking for clarification, you have written it well.
Worked example — Complaint Response Time Problem
A fully written problem statement for a customer complaint response project, showing how to quantify impact and avoid causes and solutions.
Common mistakes — and how to avoid them
Including a solution in the problem statement. 'We need a new CRM system' is not a problem statement. Neither is 'the process needs redesigning'. Describe the gap between current and expected performance only.
Being too vague. 'Customer service is poor' cannot be measured, scoped or solved. Use specific metrics, locations and time periods.
Stating a cause as the problem. 'Staff are not following the process' is a cause. The problem is the output that suffers as a result — late responses, errors, escalations.
Using internal jargon. Write for a reader who does not work in the department. If they cannot understand it, it will not land with a senior sponsor.
Tips for getting better results
Use the format: What / Where / How big / Impact. This four-part structure forces you to answer every question a sceptical sponsor will ask. Fill each part separately before combining into a paragraph.
Write it before you look at root causes. If you already know the cause, your problem statement will be biased towards it. Write the statement first, then go looking for causes in the Analyse phase.
Revisit it after your baseline measurement. The Measure phase often sharpens the number. Update the problem statement if the data shows a different picture than you expected at the start.
Download the Problem Statement Template
A clean, editable Excel template for immediate use — structured, professional and ready to fill in.
Frequently asked questions
How long should a problem statement be?
One to three sentences. It should be concise enough to read in 30 seconds but specific enough to define the gap, the impact and the timeframe. If your problem statement runs to a paragraph, it usually means it contains the cause or the solution — remove those and it will shrink.
Can the problem statement change during the project?
Yes — it is normal to refine it once you have more data. The version you write in Define is a starting point based on what you know. After Measure, you may have better numbers to replace estimates. Update it, but always confirm the change with your sponsor.
What is the difference between a problem statement and a goal statement?
The problem statement describes the current state — what is wrong, by how much, and the impact. The goal statement describes the desired future state — what you want to achieve, by how much, and by when. Write the problem statement first; the goal statement follows directly from it.
Should the problem statement mention the cause?
No. Including a cause in the problem statement is one of the most common mistakes in Define. It pre-judges the analysis and can bias the team. The cause is discovered in Analyse — keep it out of the problem statement entirely.
Who writes the problem statement?
The project lead (Green Belt or Black Belt) drafts it, but it should be reviewed and agreed by the sponsor and the team. A problem statement that only the project lead understands will not get buy-in. Write it in plain language that anyone in the business can read.
Advanced Toolkit Packs — available now
Structured, ready-to-use template packs designed for real improvement work. Pick the pack that matches your project and get started straight away.
Process Improvement Starter Pack
A starter pack for identifying improvement opportunities, measuring baselines and planning action.
Root Cause Analysis Toolkit
A practical RCA toolkit for defining problems, finding causes, validating evidence and creating action.
A3 Template Pack
A clean A3 problem-solving pack for concise, visual improvement thinking and follow-through.
