Sunday, November 22, 2009

Defining the Problem Statement

Einstein is quoted as having said that if he had one hour to save the world he would spend fifty-five minutes defining the problem and only five minutes finding the solution.

This quote illustrates an important point: before jumping right into solving a problem, we should step back and invest time and effort to improve our understanding of it.

The problem statement is a clear and concise statement that describes the symptoms of the problem to be addressed. Defining the problem statement provides three benefits for the team:
creates a sense of ownership for the team
focuses the team on an accepted problem
describes the symptoms in measurable terms

The following four guidelines are effective in creating a problem statement that is clear and concise:
Define the problem - In the problem statement, team members define the problem in specific terms. They present facts such as the product type and the error made.
Identify where the problem is appearing - Identifying where the problem is appearing, or manifesting, as specifically as possible helps the team focus its improvement efforts.
Describe the size of the problem - The size of the problem is described in measurable terms.
Describe the impact the problem is having on the organization - The description of the problem's impact on the organization should be as specific as possible.

The truth of the matter is that the more specific the statement, the better the chance the team has of solving the problem. An inadequate problem statement can lead the team down a dead-end path. When defining the problem statement try to avoid these four common pitfalls:

The problem statement should not address more than one problem.
The problem statement should not assign a cause.
The problem statement should not assign blame.
The problem statement should not offer a solution.

A simple and effective method of defining a problem is a series of questions using the five W’s and one H approach (5W1H: who, what, where, when, why, how).

Who - Who does the problem affect? Specific groups, organizations, customers, etc.
What - What are the boundaries of the problem, e.g. organizational, work flow, geographic, customer, segments, etc. - What is the issue? - What is the impact of the issue? - What impact is the issue causing? - What will happen when it is fixed? - What would happen if we didn’t solve the problem?
When - When does the issue occur? - When does it need to be fixed?
Where - Where is the issue occurring? Only in certain locations, processes, products, etc.
Why - Why is it important that we fix the problem? - What impact does it have on the business or customer? - What impact does it have on all stakeholders, e.g. employees, suppliers, customers, shareholders, etc.
How - How many parts are involved? How are you going to solve the problem? Using what method or techniques?

Each of these answers will help to zero in on the specific issue(s) and define the problem statement. Your problem statement should be solvable. That is, it should take a reasonable amount of time to formulate, try and deploy a potential solution.

A well-stated problem statement speeds a robust corrective action process. It helps identify potential root causes and eliminate bias and noise. Accurate problem statements save time and effort by focusing the team on root cause identification. Continuous improvement happens when root causes are found and permanently eliminated. Defining the problem statement is the first step in this process.


  1. I think this is critical and way under-appreciated. People think the problem is obvious - "can't you all see it?" Why spend so much time defining it? Yet a poorly defined problem statement is like a poorly defined goal.

    I even dedicated a whole column to the subject a few months back:

    Jamie Flinchbaugh

  2. In my experience, problem statements are never done that well. The desire to launch into the search for a solution often means the team rushes through the problem statement in the desire for action and movement. Often, problems DO end-up getting solved but NOT necessarily the ones which needed to be solved at the onset. Perceived inactive time at the front-end on a problem statement saves many hours later on in the process.

  3. I agree with Rob. We in America and esspecially in my own plant have a "Ready, FIRE, Aim" approach to problem solving.

  4. I miss an essential element or at least I'd like to see it back in more specific terms:
    a problem is a deviation from the expected; the what is vs. the what should be; the result of the experiment vs the hypothesis; the case vs the standard.
    This is where both specifics of the case should be recorded as well as that the team jointly defines what was expected in the 1st place. Sometimes, just doing that is part of the puzzle...

  5. Great points. Lean is very mush about solving problems and teaching everyone to be able to do so well. The first place to start is a good problem statement. Rob S. so often we struggle to collect data to define the problem. Certainly you can't solve the problem without this necessary fact finding information. Certainly a good problem statement means the problem is half solved.

  6. A common challenge in formulating a problem statement is knowing where to put a stake in the ground.


    A = the impact
    B = the problem
    C = the direct cause

    You can always ladder up or down, i.e.,

    A = (out of scope)
    B = the (newly defined) impact
    C = the problem (used to be direct cause)
    D = the new direct cause


    Z = a (larger scale) impact
    A = the problem
    B = the direct cause

    Don't know if that makes sense in print. :-)

    But, I see a lot of people spend too much time going in circles, rather than picking a spot, deciding what is in/out of scope, and then moving on.

    Walter Reade

  7. Walter, Thanks for sharing. I think I follow your ladder logic. I like to use the 80/20 rule rather than perfection. It is better to move forward solving the problem then get stuck in analysis paralysis.

  8. Great post.Worth considering using the IS/IS NOT approach as well as 5W1H per Kepner Tregoe problem solving.E.G.Who has the problem: Shift A Who doesn't Shift B,C,D inference:- it's something specific to Shift A.If all Shifts experience problem the implication is that the problem is not due to the people. if you aren't 100% confident on answering the Is Is Not you need to gather more facts and data. If you apply the Is-Is Not to all the 5W1H it is very powerful in directing towards root cause. I recently used this approach with a manufacturing team and we have eliminated some long standing customer quality issues now even the Quality Manager tells me she is convinced in the power of the problem solving methodology.

  9. which one is correct --- 5W1H or 4W2H for exact problem statment. because during investigation we use 5why for all the possible cause that came from cause and effect diagram. ???

    1. They are variations of similar approaches. They are attempting to define the problem statement so that you can get to root cause. In some cases using tools like is/is not, fishbone, trend data, etc are necessary to help define the problem. I recommend you pick a method you are happy with and use that.

      I learned from my friend Ron Pereira to ask "so what" after 5 Why analysis and working backwards to confirm root cause.