Overusing DMAIC

We are more than halfway through the countdown of our exploration of the kooky, and expensive, mistakes people make in implementing Six Sigma, and I want to talk about something that’s so fundamental people rarely see it—Stupid Six Sigma Trick #4: Overusing DMAIC.

DMAIC stands for define the opportunity, measure the current state, analyze potential source causes, improve the process and control the improved process. If you think about it, the DMAIC method and the jillion other problem-solving methods are just refinements of the scientific method for the business environment.

So, how can it be overused? I mean, you have problems and you want them solved, right?

Well, it turns out DMAIC is most useful when you don’t have a specific process or prior guidance to resolve the issue. It’s a method that uses a high level of abstraction in order to be generally applicable. There are multitudes of special-purpose ways that already exist to fix many common issues, however. You don’t have to use DMAIC in these cases: someone else has done that and arrived at a procedure for dealing with the issue. For example, you generally don’t need to use DMAIC to reinvent strategic planning. A lot of other people have thought about, and practiced and refined doing this and have come up with a time-tested procedure. An academic looking to refine strategic planning might very well use DMAIC concepts, but the rest of the world just uses what has been shown to work.

In these cases, DMAIC helps only trivially and provides only the weakest direction. Yet, once we learn this method, powerful when correctly applied, we tend to see it as a Swiss army knife, when it’s really a hammer: Useful for many things, but blunt.

Example 1—The case of the surface defect

We’re making a product that occasionally has defects on the surface. We want these defects to be eliminated. This is a classic case for DMAIC. In the define phase, we establish that we should be working on this to the exclusion of all other projects, based on our strategic plan. We estimate the expected resources to be used, the time it will take, the benefits at the end. In the measure phase, we make sure that we can reliably and efficiently convert observations into data, so we know what to work on and if we improved it. In the analyze phase, we generate hypotheses about what might be causing the problem, then test these hypotheses with experimental data. In the improve phase, we finalize our countermeasures, implement them in the process and validate the effect. In the control phase we put monitoring systems in place to prevent the problem from recurring. This is a nice, simple use of the DMAIC method.

Example 2—Running a process

I once had a discussion with an expert in Six Sigma (he told me that, so it must be true). We were talking about DMAIC, and he said something like, “DMAIC is the best way to do anything.”

I hate disillusioning people, but I thought of a lot of examples where DMAIC isn’t an efficient way to go. So I raised the topic of the ongoing daily running of a process, and said that surely there were already extant systems that described how to monitor, control and improve a process that would be more useful than starting from scratch with DMAIC.

His reply was that no, in fact, DMAIC was the way to run a process. First you define the process, then you measure it, then you analyze it to improve it and you put systems in place to control it.

He was a pretty smart guy, but perhaps suffered from smart person syndrome, because it sure sounded good, but I didn’t think that a lot of people would be able to use that sentence to generate a daily management system. I asked him how using DMAIC would help to determine who does those things. What system is built to identify, prioritize, select, and allocate those improvements? Who reviews standard operating procedures (SOPs) and how frequently? How are the workers given ownership of their process? He replied that all of those things could have DMAIC applied to them to arrive at a system to do that.

Well, that is true, but you could apply DMAIC to the problem of finding a way to move large masses around on the ground easily and eventually come up with a round, rotateable load bearing device as well, but that doesn’t mean reinventing the wheel is the best use of your time. To some expert practitioners of DMAIC, it makes no difference if a lot of people had worked on this problem in the past and come up with a framework for daily process management—DMAIC can do it all.

Example 3—Reducing variability

Let’s say that we have a process that produces continuous data, which can be measured on a continuum and can theoretically take on any value. This process measure has a specification, but you’re having difficulty meeting the specification requirements. If you’re in manufacturing, it could be a part dimension, temperature, whatever. If you aren’t in manufacturing, perhaps it’s your budget variance per month or time to respond to customer requests for quotes.

In this case, you aren’t trying to eliminate a condition or close a gap, you’re trying to take a process or product characteristic and get it in specification.

DMAIC purists will say, “Well sure, you just define what you’re working on, measure it to see where you are, analyze why it isn’t there, improve the process so that it gets there and control it so it stays there.”

Again, it sounds great—that is until you start going through the process. What you will find is that those broad categories leave a lot of room for interpretation and leave a lot of gaps for errors. There’s a difference in approach between projects to eliminate a problem and projects seeking to reduce variability, which is often not clearly delineated in training. The problem is that if I give this assignment to different Black Belts, I will get different approaches based on their experience and training with this type of problem.

For instance, the experienced Black Belt, having been burned before, will probably start with verifying that the specification they’re trying to meet is needed and sufficient—that it has high design quality. Newer Black Belts wouldn’t even think to do this, because the project has already been defined for them and they could find themselves, after a lot of effort, with a partly or completely done project on a measure with a specification that’s irrelevant or incorrect.

Another aspect of projects to reduce variability is that the process data themselves give you clues on where to look for improvement. Putting the data on a control chart in the early part of the project may show you that the process is in control, which means improvements will have to come from changing the process, or that it isn’t, which means that initial improvements can come from preventing atypical events. In problem elimination, I want to make all of the occurrences go away, not stabilize the occurrence rate. With continuous data you might examine the capability indices (or potential capability indices if you lack statistical control) which can tell you if you simply need to move the average to target (sometimes straightforward), reduce the variability (usually pretty tough), or both, to meet the specification. With problem data you aren’t trying to meet a specification for how many problems you have (at least in mature industries).

The DMAIC-for-everything person will point out that all these activities fit perfectly well into DMAIC. And you know what, I agree. DMAIC does not and should not provide guidance specific to reducing variability, however. A quality improvement strategy, focusing as it does on that very thing, can and should provide that level of detail as well as a different focus on similar steps. This way, when two Black Belts go at a similar project, they will have equally high probabilities of success.

Other strategies and systems

In my experience, many people use the general-use DMAIC steps to try to address things that have already been built, a few of which are:

• Strategic planning and policy deployment
• Daily management
• New product or process design (this is why design for Six Sigma came along and has different steps than DMAIC)
• Employee involvement
• Customer and supplier quality assurance
• Cross-functional management
• Variability reduction or quality improvement

I’m sure you can come up with lots more in your experience.

While using any of these techniques, you could very well find that you run into a mini-problem on which there is no guidance. In that case, you would use DMAIC within the context of that technique to solve it.

I want to be clear here, though. A process genius can take a step back from these systems, apply the scientific method—a.k.a. DMAIC—and find improvements. But in the business world, if you aren’t doing what you know you should be doing, this isn’t the time to try to invent a better way of doing it. You should try first to put your house in order by seeing what others have tried and found useful. Then, given the time and resources, wallow in intellectual stimulation and invent the next big thing (NBT™). If you’re already doing what the experts say should work, and it doesn’t, you probably have a specific problem to be solved, and now is the time to re-examine your process with DMAIC.

Effect of SSST #4

Using DMAIC to solve every problem leads to wasted time and effort, as well as variation in results from practitioner to practitioner. DMAIC is most useful when you’re trying to solve a problem for which there’s no established process for resolving the issue. For many situations, there’s already an established and effective process that’ll lead to a solution, so you don’t have to start from scratch as you do with DMAIC. Although DMAIC can provide guidance, it doesn’t tell you specifically what to do, and the steps are very general by design—it’s a method to follow when you don’t know what to do to solve your problem.

When confronted with a problem, take a moment to think about the best approach, maybe even take a look at the literature to see if someone else has a way to attack such problems. You might find that it saves you time and effort, and your company a lot of money.

But I could be wrong.