Many organizations make a mistake when trying to replace their design process with Design for Six Sigma. DFSS was never intended to completely replace an organization’s existing design process. The DFSS methodology should be used, at the macro level, as a structure for deliverables and performance criteria for the design process already in place.

Organizations shouldn’t ask their engineering teams to abandon the process they’ve grown accustomed to using for years and replace it with DFSS. Rather DFSS deliverables should be integrated into their current development process.

One of the more common mistakes practitioners make is to assume DFSS is a disruptive technology, but it is not. (A disruptive technology is one that displaces an established technology that creates a completely new market, product, or industry. As an example, the PC displaced the typewriter.) DFSS relies significantly on the voice of the customer (VOC) to determine the appropriate design methodology and expected level of performance. Customers generally don’t know what the next leap in development will or can be; therefore, an organization may be destined to make only incremental improvements if it relies strictly on the VOC to guide them through product development strategies.

Since there is no standard approach many organizations attempt to deploy DFSS on their own, which is another error in judgment. The tendency is to find people with statistical and design backgrounds, ask them to develop some training and then cycle their engineering teams through the training.

There are many examples of this happening with, at best, mixed results. A few months into the deployment, the organization has spent a lot of money on training with little to show for it. Typically, one of the reasons is that few, if any, of the managers participated in the training; therefore, they were not able to ask for the appropriate deliverables. Following simple guidelines can prevent this type of failure in DFSS deployment.

Managers should be trained before their engineering teams are. Many organizations focus on training people to use DFSS tools and processes at the tactical level, before they’ve trained the project leaders and those managing the process. Also, DFSS training shouldn’t be done in waves unless it’s considered imperative. This approach might make sense when introducing DMAIC based Six Sigma since it generally follows a standard training approach in improvement methods. DFSS, however, needs to be applied at the project level. It certainly is possible to fill rooms with computers and software so waves of employees can go through DFSS training. However, simply introducing engineers to DFSS serves little purpose when the development process is months or years. People, even designers, will forget most of what they’re taught before they’ve had a chance to apply what they learned. As an example, it might take 12-14 months to design a new cooling system, but it might take three to five years to design a new automobile platform. With this in mind, training people on a project-by-project basis or integrating the training with the product development schedule would be a better approach.

Organizations must realize that DFSS defers from DMAIC. While the latter is primarily driven by the reduction in process variation and cost, DFSS is mostly a cost avoidance, revenue enhancement approach. It is more difficult to set financial objectives for DFSS because the goal of DFSS is to avoid cost in the first place. While we can guess how much more expensive the development of a new product would have been without DFSS, we cannot accurately quantify the cost avoidance; therefore, attempting to track savings for DFSS projects is not useful in relation to successes obtained with DMAIC project tracking.

To ensure DFSS is properly applied in an organization, DFSS activities should be linked to high impact design projects in which DFSS skills can be nurtured among the technical contributors and the design team.  To kick start the DFSS process, and to gain knowledge and acceptance, it has proven valuable to pick out a few low risk, high impact projects, and turn them into successes which are extensively publicized. When organizations can leverage those successes into support and acceptance, they can tackle more difficult projects. It might be tempting to start out attacking high risk, high impact (tougher) projects, but that’s the best way to kill any program, including DFSS.

 DFSS is a powerful tool that can be used in service as well as manufacturing industries. But to get the most benefit from it organizations should work to integrate DFSS with existing design processes. If top and middle management aren’t on board with the transition, the DFSS initiative will eventually fade away to be remembered as just another failure. It’s up to everyone to see that this doesn’t happen.