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
- Who? Who observed the
problem? Who is affected by
- 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
- 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
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
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
- "The packaging department has
failed to meet its planned
production due to equipment
- "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
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
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.)