February 1, 2020

By Darren Dolcemascolo

Whether we are tackling an A3 / Lean Problem Solving, a DMAIC project, or even a Corrective Action for a customer; the most important thing we can do is define the problem correctly. Before we talk about the process for defining a problem, let's begin by defining what a problem is.  We might think of a problem as the gap between the current condition and a target condition or a standard. It is impossible to overemphasize the importance of properly defining a problem. Charles Kettering once said "A problem well stated is a problem half-solved." With this in mind, how do we go about defining a problem?

In order to define a problem, Toyota folks would rightly say that we need to "grasp the situation."  One tool that might help with this is the 5W's and 2H's - a very simple set of questions designed to ensure that the problem solver does not jump to conclusions.  The 5W's and 2H's are:

• Who?  Who observed the problem?  Who is affected by the problem?
• What?  What type of problem is it?  What has the problem?  What is happening?
• When?  When was the problem first discovered?  When has it been observed since?
• Where?  Where was the problem discovered?  Where does the problem occur?
• Why?  Why is it a problem?  (NOTE: We do not ask why it happens to discover the cause at this point- that happens later in the problem solving process)
• How Much / How Many?  How much is the problem costing us in time, dollars, etc.?  How many times has it occurred?
• How Often?  How often does the problem occur?  Is there a trend?  Can we quantify this?

To answer the questions, we must go to the gemba (where the work happens), observe the process, and collect some facts and data.  These include metrics, production process records, work instructions, purchase orders,blueprints, specifications, etc.  The observation must include discussion with people who do the work and should include observation of the process and even flowcharting/mapping the process.   After we have thoroughly answered these questions, we can formulate a problem statement.

A good problem statement will describe the actual condition, target condition or standard, and characteristics of the problem discovered through the above analysis.  For example, we might have a problem statement such as "The packaging department has failed to meet its planned production during normal working hours 70% of the time over the past three months, resulting in excessive overtime.  The target condition is to meet plan 95% of the time and reduce overtime to less than $1000 per month.”

 Major pitfalls in constructing a problem statement include assigning causes or blame, combining multiple problems into one statement, and including countermeasures or solutions.  We should examine our statement with our team to ensure that we haven't committed any of these errors; note that many times they are hidden in the statement. Examples of poor problem statements include:

• "The packaging department has failed to meet its planned production due to equipment downtime."
• "New packaging equipment is needed in the packaging department."

The first of these statements includes a possible cause.  While it may be true that equipment downtime is a cause, it should not be part of our problem statement in this case.  (We might want to bring the problem statement down a level to address equipment downtime, but that would be a different problem statement.)  The second of these statements is actually a solution to an unstated problem.  "More equipment needed" cannot be the problem.

Another pitfall that we need to consider is the level of problem. Are we too high level (too vague/broad) or too low level/specific?  When someone proposes a problem statement to me, I generally think in terms of "therefore."  In other words, ask if this is the problem, what happens as a result of this problem?  Asking "therefore" is the opposite of asking "Why" as in the "Five Why's."  Asking "Why" takes us toward the root cause, which we will eventually do.  Asking "Therefore?" takes us up a level, where we might consider solving a larger problem.  For example, if we frame a problem as "The packaging machine is down 10% of the time," we might want to find out if this is the right problem to solve.  The packaging machine is down 10% of the time; therefore, we are unable to meet planned production.  We might want to start with not meeting planned production as our problem, and then determine which factors are the top contributing causes.  Perhaps downtime is not the most important issue to consider.  It is worthwhile thinking about this when framing a problem.

In summary, defining the problem is the most important part of problem solving.  In order to do this effectively, we should consider thinking through the 5W's and 2H's, avoiding key pitfalls, and identifying the right level of problem to address.  If we do this successfully, we are halfway to solving the problem, at least according to inventor Charles Kettering.  (If you don't know who he is, Google it.)

 

Click here to subscribe to our free e-newsletter Learning to Lean and receive up to three articles like this one each month.