Six Sigma Project Turkeys

I’ve looked at thousands of projects in the 20 plus years that I’ve been reviewing projects for Six Sigma Green Belt or Black Belt certification. I personally review all certification projects for Pyzdek Institute Certification Candidates. I’ve seen fantastic projects which have saved millions of dollars, launched exciting new products and services, delighted formerly dissatisfied customers, and created processes that blew away the competition. I’ve seen successful projects that were started and completed in a few days and multi-year projects that helped businesses grow and evolve. I’ve also participated first-hand in my share of Six Sigma projects and other improvement projects in my 40+ years in the quality improvement field. In this article I’d like to share some of what I’ve learned from these experiences.

DMAIC versus Just-Do Projects

Six Sigma Belts are people who have mastered a set of skills that they use to go from an important opportunity vaguely defined by the organization’s leaders, to a project that addresses the opportunity, to a deep understanding of what needs to be done and why, to a fully implemented solution that is better than its alternatives, to a permanent change for the better. Six Sigma projects are projects that require this skill set. The framework used is called DMAIC: Define, Measure, Analyze, Improve and Control. What is DMAIC Methodology?

• Define the opportunity, the priorities, the plan, the process and the drivers.
• Measure using valid metrics, determine if you need to address special causes of variation, establish the current baseline, drill down on the drivers to critical causes, determine what customers think and want.
• Analyze the problem. Develop theories of cause and effect, test the theories with data and statistical tools, model the cause and effect relationship, use the models to identify improvements, analyze costs and benefits to choose the best improvement alternative.
• Improve by implementing the new approach, gathering data as you do so to identify unexpected outcomes. Develop contingency plans to address possible risks.
• Control the new system by changing procedures. Identify the person who will own the new system and transfer ownership to her or him. Follow up to see if the changes had the desired effect.

DMAIC is not the only game in town. In fact, most improvement projects do not require the formal DMAIC approach. Generally DMAIC is used when more direct approaches have already failed. The “Just-do” approach is usually tried first. For example, a worker might point out to their supervisor that what they are doing is already being done by someone else. Such obvious waste can simply be eliminated by changing the work instructions, after making sure that it’s truly waste. Sometimes the solution to “Doctor, it hurts when I do this” is simply, “Stop doing it.”

Of course, when the Just Do project doesn’t get the job done permanently, DMAIC may be needed to identify the true causes. Sometimes the obvious solution is wrong. You “stop doing it” and something goes awry somewhere else. Or you make the obvious change to fix the problem but the problem stubbornly refuses to go away.

The rigor of DMAIC has often helped identify less obvious causes, or interactions among two or more causes. For example, the existing process for processing checking account deposits might work fine except for small business customers on Friday afternoons or after holiday weekends. Such complex, interacting causes of problems are often difficult to identify without a thorough evaluation of data by people trained to do so.

Derailed DMAIC Projects

I often see projects where the DMAIC framework was the original idea, but it got derailed part way through. Or the DMAIC framework was still followed, but it became distorted along the way. Here are some of the ways I’ve seen projects go off of the tracks.

DMA projects

This is one of the most common. The Belt gets through Define, Measure and Analyze just fine, but then stalls out. Sometimes the Belt is engaged in a futile pursuit of certainty. Six Sigma is a practical, pragmatic approach to making improvements. It’s not Academic research. We usually have to be satisfied with results that provide a reasonable degree of confidence that we are headed in the right direction. We must often act when the analysis says “Go East-ish,” rather than “Head 75°.” Business processes are highly dynamic so it is unlikely that we will ever discover permanent truths anyway.

Another cause of the DMA project is reluctance to pull the trigger. The Improve phase is where the rubber meets the road. Until then it’s all about learning and speculation. Everything is abstract. Improve involves making actual changes to the work, and it’s the first time that real failure is possible. Perhaps there is a harsh critic who is sure that the project is doomed to fail and the Belt doesn’t want to prove her right. Perhaps there was no real support for the project in the first place and the Belt expects resistance from middle management when the team begins to implement changes. Regardless of the reason, a project that only suggests changes but doesn’t result in any change is not a bona fide Six Sigma project.

DI projects (jumping to Improve)

When a Six Sigma project begins it is often the first time anyone actually sat down and thought deeply about the opportunity or problem. At the end of the Define phase there is a great deal more information about the opportunity than has ever been available, including a high-level drill-down from top level response metrics to drivers of them (CTQs.) The voice of the customer has been heard and documented. The temptation is that the team will now see an obvious solution to the problem. If they succumb to the temptation they will bypass the Measure and Analyze phases and begin implementing improvements straight away.

The problem is that the obvious solution is often not the correct one. The Define phase drill down to CTQs is only a partial definition of the cause and effect relationships. During the Measure phase the measurements will be validated and data collected to validate the CTQs. Also, the drill down will continue to root causes, which are often easier to measure precisely than the higher level drivers. Furthermore, the data will be stratified with tables, plots and charts to refine the theories of cause and effect.

During the Analyze phase the team will test the theories using powerful statistical tools and build models using the theories that pass statistical significance muster. The models will be vital in evaluating potential improvement approaches to find the best one.

When the team jumps to improve none of the above occurs. If they are lucky enough to stumble on a workable improvement, chances are it won’t be the best one. In addition, the improvements are usually not accompanied by a plan for preventing them from becoming undone at a later date, as would be done in the Control phase of a real Six Sigma project.

I projects

These are undefined or poorly defined improvement projects. Essentially the team just starts changing things in the hope that the changes will make things better. Since the team never bothered to identify the project properly in the beginning, there is a very good chance that they are working on an unimportant process, so even if their changes have an effect, they probably won’t have an impact on the organization.

I projects take place all the time in most organizations. They are a source of potential candidates for real DMAIC projects. Belts in search of good projects might ask around to determine if I projects are underway so they can inquire about what they are hoping to accomplish. However, since I projects are often unrelated to real opportunities, the Belt should guard against spending too much time trying to make these sow’s ears into silk purses.

DMAI projects

It’s surprising how often teams neglect the Control phase. I believe this is because they believe that the improved results speak for themselves and only a fool would go back to the old way of doing things. However, this isn’t the case. People and situations change constantly and processes that are not documented morph as time goes by. The new guy or gal may not appreciate why something is done in a particular way, and without the constraint of a documented procedure or policy they’ll feel free to do it a different way. If they are new, they may not remember that things were worse in the past. One way or another, a project that ignores the Control phase runs the very real risk of being undone in the future.

Partial C projects

Here the team completes the DMAIC cycle and disbands, happy in the knowledge that they did everything they were supposed to do to make changes for the better. However, they neglect to follow up at a future date to assure that the changes achieved the desired results long-term. They also didn’t determine if the Control plan they gave the new process owner is being followed and, if it is being followed, if it actually works. Part of any Control plan should be to drop in from time to time to check on things, and to reopen the project if things aren’t working out.

DAIC

Here the team skips the Measure phase. They trust the data implicitly and don’t do historical research to establish the current state or drill down to CTQs. They define the problem and treat the drivers as if they were the root causes. They perform analysis of the impact of the high level drivers on the process outcomes, assuming that their untested theories of cause and effect are correct.

The problem here is that without a historical baseline there is no way of knowing if things got better or not. There are also a great many missing drill down steps, making it difficult to identify exactly how to make an impact. For example, one might wish to improve the performance of their sales team, so they have a contest to increase the incentives for their sales people. Perhaps sales do increase. But sales are the result of a process. The process includes the number of leads obtained, how qualified the leads are, how the leads are contacted, how the leads are informed about the offerings, etc. etc.. When this drill-down is skipped the team is likely to leave a great many improvement opportunities unexplored.

Other Ways to Go Astray

There are many other ways in which a project can fail, such as:

• Project not linked to a business opportunity recognized by the leadership
• Project does not address a business priority. I.e., “We have more important things to do at this time.”
• Desired future state is not known. “I don’t like the way things are.”
• No project leadership from sponsor. Figurehead sponsorship.

Many Six Sigma project do not go wrong, of course. And many great projects are not Six Sigma projects. But being aware how project can go wrong can provide guidance to help you avoid going wrong in the first place.