Wrongly Doing Design For Six Sigma
A single, common misunderstanding drives failure of the Design for Six Sigma (DFSS) methodology. Use DFSS to proactively control the variation of products. Do not use DFSS to control the variation in your product development projects.
Design for Six Sigma is a very powerful design methodology. For a successful Six Sigma program, it is an essential success element. It is good, and properly instituted and executed, it works.
Unfortunately, a common misunderstanding or mistaken institution of DFSS drives more waste and cost than it solves. We must remember that DFSS is a design methodology. It is not a rigid, inflexible, dictation of a product development checklist.
Let’s understand what Six Sigma and DFSS are so we can discuss what they are not. Six Sigma is a philosophical methodology of business decision-making based on the belief that variation is the enemy.
Six Sigma declares war on variation: variation in process, design, behavior, and performance. A successful integration of Six Sigma recruits the entire workforce to battle variation in every aspect of the business. This is a solid principle. It is true that chasing and managing variation will unnecessarily consume time, energy, resources, and money. Getting rid of it does make us more efficient.
DFSS is the battle plan that proactively drives variation out of the products and the production processes for those products. As such, it is a vital part of the Six Sigma strategy because the root of business performance and variation stems from the product and its production.
When such is understood, DFSS works. However, many integrators of DFSS miss that understanding and instead apply the variation-prevention intent to the wrong target. They, instead, try to eliminate variation in product development project execution.
Before we start arguing about the observation that product development is certainly one of the major business processes that can experience a great deal of variation and unnecessary cost let me agree. It is, and we should make it as stable as possible, but we should do so at an elemental level, not at a process level.
The fact is no two product development efforts will ever be the same. They will, and should be different. They will include different scopes, complexities, expertise, disciplines, suppliers, processes, technologies, and people. If we ever do the same project twice, we have made a horrible mistake.
Therefore, it does not make sense to dictate one rigid process that every project shall follow to the letter of the law. We do not want to force a 3-month firmware update effort into the same sequence of tasks necessary for a 3-year total mechanical-electrical-software-systems design effort. It’s not wise, but often it is what we do.
It is good to remove variation at an elemental level. Use the same templates. Use the same file structures. Remove variation from the engineering change order process. Remove variation from all of those processes we use every day to execute product development.
Do not build an inflexible, one-size-fits-all process for your product development process overall. We must expect and accommodate different sizes. It is one place in our business where variation is good.
Yes, DFSS comes with a framework for solving problems, typically PIDOV or DMADV. We have tools for each step of those frameworks too. But, we should use the tools we need, when we need them. We should not use every tool every time.
To successfully integrate and perform DFSS, DFSS must be an enabler for the problem-solving and creative effort that is product design and development. It is a method and a skill set to enable us to predict and eliminate the variation of our products and our production processes for those products.
If we try to dictate control over creativity and problem-solving we often disable it. I’ll write it one more time for emphasis. We want every one of our product development efforts to be different. If they aren’t different, then what’s the point? Therefore, we must accommodate those differences by using only and specifically what we need to battle variation in the product performance. That does not mean that we want to force every project to do exactly the same checklist tasks every time.
While doing exactly the same checklist every time will certainly will make most of our projects look much more alike (less varied), it won’t save us any money, or necessarily make our products better. Remember the purpose of DFSS and Six Sigma. They are here to enable us. They are our means and our method for removing variation where it is bad. Don’t make the mistake of forcing what should vary into a fixed formula.
Stay wise, friends.