Why Effective Problem Solving Begins With a Good Problem Statement

“Hey everybody, let’s ‘A3’!”  

Let’s solve world peace or let’s state our predetermined solution as a problem, as in “we need to develop a problem solving culture” or “the problem is we need the new software upgrade.” These are two of the most common issues I see. 

A problem well-stated is a problem half-solved.

Charles Kettering, Head of Research at General Motors from 1920-1947. 

Everyone is doing it and certainly no other tool in the lean toolbox epitomizes the scientific method or PDCA way of thinking more than A3 for problem solving. We know that a problem solving A3 is a representation of the A3 thinking process applied to a specific problem. My observation from decades of doing A3s is that one of the biggest challenges in A3 thinking is deciding exactly what the problem is that we are trying to solve and boiling that problem down to a good problem statement.

Another is a problem statement that is so broad that it can’t be reasonably measured or observed, as in “we have too many errors in our patient record files.” A good problem statement in its simplest form is a clear statement of the difference between our target condition and our actual condition stated in observable and measureable terms. For example, something like “30% of patient immunization records are missing at least one entry” or better, narrower, and more specific yet: “10% of patient immunization records are missing the date of birth.”

The smaller the scope and the more specific the description of the gap between current and target/standard, the easier it will be to get to root cause and solve the problem. Getting from the broad and unspecific “we have too many errors in our patient records” to the more specific “10% of patient immunization records are missing the date of birth” allows us to get to the root cause of why DOB is missing. This helps us implement a countermeasure to that specific root cause and run the experiment to see if it works (remember, nothing ever goes according to plan) and then adjust based on what we learn. Eliminating the 10% DOB omission problem helps us to make progress against the broader issue of omissions and errors in patient records.

So, what’s the take away from all of this? When we write our problem statements, let’s try to be more specific. In my years of problem solving I don’t ever remember anyone complaining that we were working on a problem that had been scoped too narrowly. If you’re feeling stuck, try to think: What is the current condition versus the target or standard in observable and measureable terms? Get the problem stated well and you’ll have it half solved. State your problem in such a way that your team members can understand and articulate it in the same terms, and you may be three quarters of the way there.

What difficulties do you experience in creating problem statements?