Design for Six Sigma the Wrong Way

Executive Summary:

The right way to use Design for Six Sigma (DFSS) is to proactively mitigate or eliminate variation in product quality and performance and, by association, production processes.  The wrong way to use DFSS is to turn it into a rigid, inflexible product development checklist that forces every project to execute exactly the same tasks, every time.

The Rest of the Story:

The purpose of the Design for Six Sigma method is to proactively predict and minimize the variation in our products.  Particularly, we want to minimize variation in performance and quality.

When things vary we are inviting something to occur that is outside of acceptable norms.  Something will be too big, or too slow, or too weak, or too late, or too red, etc.  When that happens we must expend energy, time, resources, and money dealing with or correcting the fact that something was too something.

This recognition that variation is a root cause of unnecessary expense or cost or waste within a business is the philosophic principle behind the Six Sigma methodology and DFSS.  Six Sigma declares war on variation.  Design for Six Sigma is the battle plan for eliminating variation from our products.  Good.

As we institute Six Sigma and DFSS we naturally come to the realization that product development is a business process that experiences a great deal of variation, and also unnecessary expense because of those things that tend to vary out of control.  Naturally, we aim our Six Sigma and DFSS tools and methods and skills at that process and we fire away.  “Be gone thou wicked process variation!”

Our intent is good.  Our insight is good.  Unfortunately, our most common solution is poor.  Often, we make the mistake of turning our DFSS problem-solving framework into a product development process and checklist with a declaration that every project shall follow the process exactly the same way every time.  That should eliminate the variation, right?  Wrong!

Put your problem-solving expertise to work on that for a moment.  Where does the variation come from? 

There are two sources.

1. Variation in the various tasks and processes and behaviors that we engage to design and develop products
2. Variation in the scope and complexity and needs of each product development effort

If there is variation in our engineering change order process, or in our supplier selection process, or in how we establish and document our requirements, or how we organize our drawings and documentation, that variation will greatly impact our performance with regard to developing product designs.  Such variation, by all means should be reduced or eliminated and our ability to execute will improve.

However, no two product development projects should ever be the same.  They should always be different.  We should never expect to do the same project twice because every new product should be new and different from every other.

The scope, complexity, technology, expertise, people, time, resources, suppliers, and production processes for a new project will be and should be different from the other projects.  This kind of variation is good!

Now, let’s back up just a little.  How, by dictating that the DFSS method is now a process and associated checklist that, by policy, shall be followed the same way for every project, did we reduce or eliminate either of the two sources of variation we identified above?  We didn’t!

All we accomplished by establishing such rigidity is force every little, simple project to suddenly become a great big project.  Oops!  We don’t even know if we really put in the right details for our really great and complex projects to be done well.  Lastly, we just made everyone associated with product development really turned off about DFSS.  Does that sound right to anyone?  Am I the only one to have experienced this?

By all means, we should attack the sources of wasteful variation we identified.  We should absolutely apply our Six Sigma and DFSS expertise to reducing variation in how we execute engineering change orders, supplier selections, requirements identification and management, etc.  Doing so will definitely help.  But we must understand that these things will continue to vary because our project demands will always vary.

It’s OK.  Remember, it is good that our product development projects should vary in scope and complexity.  With that in mind, our DFSS execution should not be fixed and rigid, but should also vary.

Some projects will require designed experiments, some will not.  Some will need statistical sample sizes and new process capability studies from suppliers or new manufacturing processes, but some will not.  Remain vigilant and protect and promote the understanding that DFSS is a skill and a tool set to help us solve the problem of designing products that do not vary.  We use only the tools and methods we need, not all of them every time.

Take a good look at your own DFSS practice.  Did your organization get the right message, or did it make the common mistake?  Don’t be embarrassed to answer truthfully.  It’s happened to the best of us.  Recognize it and work your influence in your organization to help others recognize it and help you correct it.

If you have not instituted DFSS because you are afraid of stifling creativity or driving an overabundance of rigor, understand that it is not DFSS that creates what you fear.  It is how people and organizations institute it that creates what you fear.  Used properly, it is a powerful tool with excellent stimulus and tools for enabling and driving creativity and improved designs.  It is only when DFSS is used the wrong way that it becomes a burdensome roadblock to execution or innovation.

Stay wise, friends.