What's the problem?

What's the problem? Before we can start solving a problem, we need to understand the scope of the issue. Let's hear from Einstein.

“If I had one hour to save the world, I would spend fifty-five minutes defining the problem and only five minutes finding the solution. “ ​– Albert Einstein

Structuring a good problem statement sets the tone for the overall problem-solving activity. A good problem statement also ensures alignment amongst team members and stakeholders. So, how do you structure a good problem statement? The key is in understanding the Who, What, When Where, (*Why, high-level if obvious), and How. This can be done by answering the following questions: Who discovered the problem? What happened? What went wrong? When did the problem occur? Where did the problem occur? *Why did the problem occur? (*caution: don't get into the root cause analysis yet, just provide a high-level sense of why, if this is obvious) How was the problem detected? Once you have answered these questions, you can begin structuring your problem statement. Before we get into examples, I want to emphasize some considerations. A problem statement states the effects, not the causes or symptoms. It should state the gap between what happened and what should have happened. It should be written in a timely, measurable and specific manner, using facts and data wherever available. It should be written in a positive manner, not placing blame. It should state the impact to the customer, what "pain" has been felt. And it should not imply a solution. Ok, so that's the framework. Let's look at some examples. Consider each example and whether or not the problem statement hits the mark. Problem Statement #1: Verification testing was initiated prior to the test protocol being approved. This does not follow our procedure and introduces risk should the protocol be declined and need to be re-written. There was no planned deviation approved. Well, what do you think? For me, there are some gaps. Which test protocols? How big of a risk? Is this an expensive verification test that would cost a lot of money in waste? When did this occur? Who discovered the problem and how was it detected? Yep, this one could have gone a bit further to help the problem-solvers understand the scope of the issue. Problem Statement #2: Part number xyz123 accounted for 28% of the scrap in February. The actual defect rate was 11% of parts produced which is higher than the typical scrap rate of 5%. This caused 200 hours of overtime to rework defective parts or remake new parts to complete the order. How did I do on this example? I'd say this one is pretty good. It's helpful to translate cost into dollars or yen or euros, to emphasize the risk of letting the problem continue. Otherwise, I'd say this one meets the mark. Remember, as a wise man once said "We cannot solve our problems with the same thinking we used when we created them." ~ Albert Einstein