Defining the Problem

"A problem clearly stated is a problem half solved." - Dorothea Brande (1893 - 1948), American Writer and Editor

Define the Problem. Sound easy doesn't it? I often have people come to me with a problem statement that looks like some variant of the following, “Improve process efficiency by reducing downtime due to PM”

For the Six Sigma problem solver, there is something very wrong with this problem statement. Do you know what it is?

I guess this may be a trick question. The answer is the classic Black Belt answer. “It depends”

Unless you as the problem solver are almost ready to leave the “Define” phase of your project, a problem statement should never include an assumption of the solution. In the statement above we are directing our work exclusively to PM downtime.

Never forget that we, as Black Belts, are data-driven problem solvers. We need to make sure that the right questions were asked before PM was identified as the best area to work on. Why PM? What does the pareto (or pie chart) of total downtime for the plant look like? Plot these charts by hours down, and by cost of downtime. Is there a difference. Do these two charts give you any clues? Does the downtime pareto change when you break it down to look at department to department, line to line, shift to shift, process to process?

Often these type of assumptions are made by managers -- not from data -- but from listening to apocryphal stories told to them during their visits to the lines or plants. But don't blame them! That is why they have you as their Black Belt. To question. To explore. To “DEFINE” a problem. *

Alternately, even if PM is the largest piece of the plant's downtime, your delving into the data may uncover that one area (for instance, molding processes) comprise 90% of the downtime, and that this PM is fully justified and needed. So, does that mean you are done with your project? If you've done your homework and have all the other data, you may decide that value can be found in looking into the second highest level of downtime.

In the initial stages of defining a problem, we need to keep our problem statements simple. Think if them as only having a verb and a noun. For instance, Reduce Downtime, Increase FTQ, Decrease Variation.

Oh, go ahead and add an adjective or two at this phase, just be careful that you don't narrow your scope too much at this initial stage of 'Define'.

Reduce Molding Downtime (if you are only assigned to help that department). Increase FTQ at Electrical Test (but be wary that you don't mistake Test FTQ as reality unless you've done your MSE!) Decrease Variation in Length of Molded Parts (this amount of focus often occurs with a customer complaint).

Let the data lead you to the problem statement. When you leave the Define Phase, your statements may very well include some details of how the task will be accomplished. But those details won't be assumptions. They will be data driven!

"If you do not ask the right questions, you do not get the right answers. A question asked in the right way often points to its own answer." - Edward Hodnett (1871 - 1962), British Poet

Did you enjoy this article? Come back again to see more. And feel free to send this blog link to your problem solving colleagues. I will post something new about once per week.

John

* - of course if you're told directly by your manager to work on PM, then work on PM. But have keep the detailed data in your CYA file.