The A3 process begins with the problem statement. This initial step is the foundation for the entire improvement story. If you get it wrong, everything that follows—from your root cause analysis to your countermeasures—will be built on shaky ground.
Too often, teams inadvertently sabotage their own efforts right at the beginning. They write a "problem statement" that isn't a problem statement at all; it’s a pre-baked solution, a vague complaint, or a thinly veiled accusation of blame.
A great problem statement doesn't solve anything. It simply and clearly defines the gap between where you are and where you need to be. It is the "What" and the "So what?", not the "How" or the "Who."
Let's break down the common mistakes and provide clear examples of how to get it right.
The Anatomy of a Bad Problem Statement
A weak problem statement is easy to spot once you know the signs. It often:
- Contains a Solution: It jumps to a conclusion about what needs to be done.
- Assigns Blame: It points fingers at a person, team, or department.
- Is Too Broad or Vague: It lacks specifics and can't be measured.
These errors shut down the problem-solving process before it can even begin. If you've already decided on the solution or who to blame, there's no need to investigate the true root cause.
The 4 Elements of a Good Problem Statement
A powerful problem statement, on the other hand, is focused and factual. It aligns the team on a clear, measurable issue.
- It is Specific & Factual: It describes what is happening without emotion or opinion.
- It is Measurable: It quantifies the problem. It clearly defines the gap between the current performance and the target performance.
- It is Attainable: It describes a problem that is within the team's scope to solve.
- It is Customer-Focused: Where possible, it describes the impact of the problem on the end customer (internal or external).
Examples: Bad vs. Good Problem Statements
Let's look at some real-world examples to make the distinction clear.
Example 1: Manufacturing Defects
- BAD: "We need to retrain the 2nd shift operators because they are producing too many defects."
- (Why it's bad: It contains a solution ("retrain") and assigns blame ("2nd shift operators").)
- GOOD: "In the last 30 days, the scrap rate for Part #X-123 on Production Line 2 has averaged 4.2%, which is above our target of 1.5%. This has resulted in a monthly cost of $12,000 in wasted material and labor."
- (Why it's good: It's specific, measurable, time-bound, and quantifies the business impact.)
Example 2: Office/Service Process
- BAD: "The accounting department is too slow at processing invoices."
- (Why it's bad: It's vague ("too slow") and assigns blame ("the accounting department").)
- GOOD: "Over the last quarter (Q3), the average time to process a vendor invoice, from receipt to payment approval, was 21 days. Our service level agreement (SLA) with vendors is 10 days. This delay has resulted in 15 complaints from key suppliers and an increase in late payment fees."
- (Why it's good: It defines the process, quantifies the gap between current and target state, and describes the impact on both internal process and external partners.)
Example 3: System Downtime
- BAD: "The main server keeps crashing, and we need to buy a new one."
- (Why it's bad: It contains a very expensive solution ("buy a new one").)
- GOOD: "The primary CRM server has experienced 4 unplanned outages in the last two weeks, resulting in a total of 6 hours of downtime for the sales team during peak calling hours. The target is zero unplanned outages."
- (Why it's good: It's specific about the "what," "how often," and "impact," without assuming the cause or the solution.)
Crafting a clear, concise, and data-driven problem statement is the essential first step in any A3. It aligns the team, focuses their efforts, and creates the solid foundation required for a successful investigation that leads to lasting improvements.
