Design for Six Sigma (DFSS) is not intended to replace an organization's current design process. Instead, DFSS methodology should be used as a framework at the macro level for deliverables and performance criteria for the design process already in place. We determine when estimates for profitability, suitability, marketability, capabil- ity and reliability should be called for during the new product development process and add those criteria to the appropriate checkpoints.



We shouldn't tell our engineers we're discontinuing the process they've been working with for 10 years and replacing it with DFSS. We should integrate DFSS deliverables into the current development process and ask project managers to commit to providing them.

Define, measure, analyze, improve and control (DMAIC) oriented Six Sigma Black Belts need a working knowledge of DFSS because they will likely redesign existing products, processes and services to achieve the desired performance levels.

Traditional design teams, on the other hand, require a more in-depth knowledge of DFSS. The development of a new product, process or service requires an in-depth analysis and management of risk to successfully meet time to market, quality, cost and schedule constraints.

Disruptive technologies are technologies that change the market so much the customer has little reason to buy anything other than that product. One of the common mistakes practitioners make is to assume DFSS is a disruptive technology. It is not. DFSS relies heavily on the voice of the customer to determine the appropriate design approach and required level of performance. Customers often don't know what the next leap in development will or can be; therefore, an organization may be eternally destined to make only incremental improvements if it relies solely on the voice of the customer to dictate product development strategies.

Proper Training

Because there is no standard approach for DFSS, many corporate executives will attempt to deploy DFSS on their own. These executives hire people with statistical and design backgrounds, ask them to develop some training and then cycle the engineers through the training. I have personally seen this happen in three organizations, and each time, the result has been mixed, at best. Six or nine months into the deployment, the organization has not only spent significant money on training, but it has also delayed R&D projects by diverting the engineers' attention to training even though there is no significant change to show for the invested money and time. The problem is none of the trainees' managers participated in the training and, therefore, were not able to ask for the appropriate DFSS deliverables. I believe this type of failure in the deployment of DFSS can be prevented by following certain key guidelines.

First, managers need to be trained before engineers. Many organizations focus on training people to use DFSS tools and processes at the tactical level, before they've brought the people who are managing the process on board. If we're going to make a difference with DFSS, the people managing the projects the cross functional teams that lead the development processes have to be the first people trained in the methodology. These teams should then put together a plan for DFSS implementation on a project by project basis. Then you can focus on training engineers and designers on specific tools and deliver the training at the appropriate time in the development process.

Second, training shouldn't be done in waves unless it really makes sense. When an organization introduces DMAIC based Six Sigma, it will follow a standard training approach and train waves of employees in DMAIC improvement methods by offering one week of training per month for four months. DFSS, however, needs to be applied at the project level. An organization might fill a room with laptops and software and bring in waves of employees to go through DFSS training. But simply introducing the engineers to DFSS serves no purpose if the development process takes two years and the designers forget most of what they were taught before they have had a chance to apply it. For example, it might take 15 months to design a computer scanner, while it might take anywhere from three to five years to design an If DFSS is not driven by top automobile. Training people on a level objectives, it is difficult to project-by-project basis or integrating the training with the new make things happen in the product development schedule is a better approach.

If DFSS is not driven by top level objectives, it is difficult to make things happen in the lower levels of the organisation

Ensure Success

As with DMAIC projects, we must remember to link DFSS to policy deployment by taking top level objectives

and pushing them through all levels of the organization. This means executives, senior management, middle management and cross functional project managers must all understand their roles in the DFSS deployment. But the initiative is more than simply training everyone on how to use the technical tools. If DFSS is not driven by top level objectives, it is difficult to make things happen in the lower levels of the organization.

The problem is the financial objectives that drive a DMAIC policy deployment cannot be applied to DFSS because it is a cost avoidance, revenue enhancement approach, not a cost reduction approach. With DMAIC, a cost saving objective is set for the entire company, which then translates into cost saving objectives for specific functions and specific departments within those functions. With DFSS, however, it is more difficult to set financial objectives because the goal of DFSS is to avoid costs 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 truly quantify the cost avoidance. Therefore, attempting to track savings for DFSS projects is not useful in relation to successes with DMAIC project tracking.

Another way to ensure DFSS is properly applied in an organization is to link DFSS activities to high impact design projects in which DFSS skills can be nurtured among the technical contributors and the design management team. In other words, go for the low hanging fruit. Pick out some low risk, high impact projects, turn them into successes and publicize those successes extensively. If you can leverage those successes into support and acceptance, you can tackle the more difficult tasks. A client recently wanted me to implement DFSS on the toughest project in the company's portfolio to see if DFSS worked. I said that would be the best way to kill the program.

Service Organizations

DFSS is not limited to the design and development of products and processes. The majority of the tools, concepts and methods in the DFSS approach can also be applied to service and industrial industries and processes (see figure 1). You ay encounter greater resistance in the service sector, however, because you are asking nonanalytical people to apply analytical tools. However, typical service applications can be successful through the use of simple tools.

In service DFSS, customer and business requirements are organized and linked to the attributes of the new service based on a process map. Then the process is modeled and optimized using a simulation engine. Failure mode and effects analyses are generated for each node on the process map, and root causes are identified using the cause and effect matrix. Lastly, corrective actions, control plans and management scorecards are devel oped to mitigate the risks.