A well-framed problem statement opens possibilities, while a bad problem statement closes down alternatives and quickly sends you down dead ends of facile thinking.
Consider a few typical problem statements you might hear during a management review:
- We have too many deviations
- We do not have enough people to process the deviations we get
- 45% of deviations are recurring
You hear this sort of framing regularly. Notice that only the third is a problem, the other two are solutions. And in the case of the first statement it can leave to some negative results. The second just has you throw more resources at the problem, which may or may not be a good thing. In both cases we are biasing the problem-solving process just as we begin.
The third problem statement pushes us to think. A measurable fact raises other questions that will help us develop better solutions: why are out deviations recurring? Why are we not solving issues when they first occur? What processes/areas are they recurring in? Are we putting the right amount of effort on important deviations? How can we eliminate these deviations?
If a problem statement has only one solution, reframe it to avoid jumping to conclusions.
By focusing on a problem statement with objective facts (45% of deviations are recurring) we can ask deeper, thoughtful questions which will lead to wisdom, and to better solutions.
To build a good problem statement:
- Begin with observable facts, not opinions, judgments, or interpretations.
- Describe what is happening by answering questions like “How much/How many/How long/How often.” This creates room for exploration and discovery.
- Iterate on the problem statement. As you think more deeply on the situation modify your first version. This is a sign that you understand more about the situation. This is the kind of data that will join with the facts you discover to lead towards sound decisions.
The 5W2H tool is always a good place to start.
| 5W2H | Typical questions | Contains |
| Who? | Who are the people directly concerned with the problem? Who does this? Who should be involved but wasn’t? Was someone involved who shouldn’t be? | Roles and Departments |
| What? | What happened? | Action, steps, description |
| When? | When did the problem occur? | Times, dates, place In process |
| Where? | Where did the problem occur? | Location |
| Why is it important? | Why did we do this? What are the requirements? What is the expected condition? | Justification, reason |
| How? | How did we discover. Where in the process was it? | Method, process, procedure |
| How Many? How Much? | How many things are involved? How often did the situation happen? How much did it impact? | Number, frequency |
Remember this can be iterative as you discover more information and the problem statement at the end might not necessarily be the problem statement at the beginning.
| Elements | Problem Statement |
| Is used to… | Understand and target a problem. Provide a scope. Evaluate any risks. Make objective decisions |
| Answers the following… (5W2H) | What? (problem that occurred) When? (timing of what occurred) Where? (location of what occurred) Who? (persons involved/observers) Why? (why it matters, not why it occurred) How Much/Many? (volume or count) How Often? (First/only occurrence or multiple) |
| Contains… | Object (What was affected?) Defect (What went wrong?) |
| Provides direction for… | Escalation(s) Investigation |
Investigations of a Dog 
Absolutely right. A good problem statement starts you on the path to a happy resolution to your CAPA. For the golfers present it’s exactly what Harvey Penick said in his “Little Red Book”: If you have a bad grip, you don’t want a good swing.
The grip is the starting point for a complex process. If you start it wrong, errors propagate until the ugly end.
LikeLiked by 1 person