05M-373

Program Level Design for Six Sigma

Thomas C. Judd
VP, Six Sigma Solutions Cognition Corporation

Copyright 2005 Cognition Corporation and SAE International

ABSTRACT
Design for Six Sigma (DFSS) has been an initiative within product development for over 5 years now. Most companies start out implementing DFSS by using a collection of tools within marketing and engineering. Even though this often yields isolated, or localized improvement in the development of the product, overall product performance, cost, and producibility are not significantly improved at launch. Furthermore, focus on the customer delighters is often neglected, or even lost. DFSS needs to be recognized as a process within the product development process and applied at the program level to fully realize its total potential value. This paper will identify key issues that need to be addressed to achieve the full value from DFSS implementation.

manufacturing. These fires are typically a direct result of the design team not doing a diligent and robust effort to accurately predict the performance, producibility and cost of the product within engineering. In fact, the development of the product is usually based on the design teams use of the prototype hardware and the pilot production run to identify performance, cost and producibility problems. Note the typical split of a programs engineering budget where the majority of the budget dollars are spent on post launch support as illustrated in Figure 1. Remember the old carpenters adage, Measure twice, cut once. One of the core philosophies of DFSS is to abide by that carpenters adage. Due diligence of employing proven methods and tools further upstream in the product development process will yield a tremendous reduction in the post-launch fire fighting effort as illustrated in Figure 1. This has been proven and documented by industry leaders, such as GE, 3M, Cummins, Seagate, Raytheon, GM, Maytag, Honeywell, Delphi and many others. Most, corporate leadership, even those not actively implementing DFSS, recognize that the overall cost of the engineering effort within a product development program is somewhere between 5-10%. Furthermore, the belief is that once the product performance and configuration is defined and released by engineering, the cost to make a significant change to the product is overwhelming and will cut into the planned profit margin, as shown in Figure 2. Product development budgets are tightly set a project inception with a small fraction of the budget allocated to problem resolution during manufacturing pilot and program launch. In reality a large fraction of the development cost occurs during product launch. The goal of DFSS is to convince management to plan a small increase in time and dollars during the design phase in order to avoid the large cost over runs typical during product launch. Transitioning the product development curve based on the promises of DFSS requires a significant cultural shift

INTRODUCTION
Most companies have implemented a Product Development Process that uses a stage gate methodology to guide program managers in developing a new product. Furthermore, most stage gate product development processes are very similar since they essentially cover the five fundamental steps of developing a product; market identification, concept design, detail design, design optimization, and design validation and launch. When a program manager develops the resource requirements for a new product, the resource demand typically follows a classic bell shaped curve between program inception and product launch, with a small amount of time planned for post-launch activity as illustrated in Figure 1. Unfortunately, time and time again, the actual resource deployment to fully launch a product follows a much different curve. The slow ramp up of resources typically follows the initial program plan, but when the product is launched for production, chaos ensues with a vengeance. Fire fighting becomes the protocol for the design team until the production of the product is stabilized and it can be totally turned over to

and tremendous support from all levels within the organization. Even with compelling case stories and common engineering sense, this is much easier said than done. However, more and more companies are discovering that approaching DFSS as a process thread within the product development process and employing a systems engineering approach to the development of the product enables teams, methods and tools to work together in making this transition, and thus reducing overall time to market and development cost Transitioning the product development process from a slow engineering ramp up with serious post-launch fire fighting to one that employs more up front predictive engineering using DFSS methods and tools requires new initiatives with significant commitment and effort from virtually all levels within the organization. These can be categorized under five major headings: Management Engagement at all Levels Weave DFSS in the Product Development Process Program Launch and Management Considerations Just-In-Time DFSS Training Program Implement Critical Parameter Management

new product development gate deliverables, faith based investment of additional product development funds, investing in new point solution and infrastructure tools, and keeping the initiative focused on the strategic goals for success. The management groups illustrated in Figure 3 are the primary contributors to successful implementation and deployment of DFSS. The engineering and program office is separated since this represents a classic matrix organization where engineering supplies the personnel to the product development programs. The CEO Office The CEO Office is the obvious originator and owner of the corporate level vision and strategy of the DFSS initiative. The CEO Office include such positions as the CTO, COO and CFO, all of which need to fully support the corporate vision for the initiative. However, the bulk of the engagement will come from the CEO and CTO. The CEO Office will need to visibly show their support of the tactical projects that are implemented to accomplish the strategic vision for DFSS. They must become actively engaged in these projects so the entire corporation sees that DFSS is important to them and that they are serious about its success. This characteristic is present at every company that has been successful in shifting the product development culture via the DFSS initiative. People need to see their leaders engaged at a hands on level to realize that change is not being dictated to them, but rather change is being promoted and supported by every level within the leadership team. Some examples include having the CEO routinely visit and talk with the people that are in the trenches implementing the various projects in support of the initiative, sit in on gate review meetings, monitor the various tactical management teams, personally present awards, and publish periodic articles or videos in support of the initiative. Engineering Management Engineering management at the vice president and director level are the primary owners of the DFSS initiative, and ultimately the DFSS process when implemented. Their implementation responsibility is to set new policies and procedures, define new methods and tools, support the training and awareness programs, and develop a plan to transform the engineering culture into a more proactive and predictive mind set via DFSS. Engineering management needs to work with the program managers to show them how DFSS will improve the program deliverables and add value to the bottom line of the program. They must also keep a more strategic view of how the DFSS deployment will add value to the overall engineering knowledge base and how to leverage this knowledge for future programs. They must be ready to invest in the training of the

This paper presents an overview of each of these topics.

MANAGEMENT ENGAGEMENT AT ALL LEVELS

Management commitment, and engagement, at all levels and from several disciplines is imperative for successful DFSS implementation and deployment. Figure 3 illustrates some of the key management positions that must be actively involved in this initiative. This is required to shift the product development culture from a reactionary, fire fighting mind set to one that is proactive and predictive in nature. There is a profound difference between management commitment and engagement. Many corporate management teams have proclaimed their commitment to a new initiative and even support the implementation of that initiative via mandate memos, training funds, establishing core focus teams on overhead funds, setting up new procedures and policies, and much more. This is, indeed, imperative to get momentum behind the new initiative and to align the corporation with the goals of the initiative. But this is just the first step for management to ensure success. The real test of management is their response during the deployment of the DFSS initiative. Once the DFSS initiative is committed, several more difficult and complex issues will emerge that will test the true level of management commitment, which will put the managements passion and faith in this new initiative to the ultimate test. New issues such as setting new personnel and program performance metrics, enforcing

engineering personnel as well as the new tools that will be needed to support the DFSS methods and practices. As part of the implementation leadership team, engineering management must show their engagement in all the aforementioned activities by personally working with the various engineering disciplines within their own organization as well as cross functional disciplines such as marketing, supply chain, manufacturing and quality. Since they are the primary owners of this initiative, engineering management must be the most visibly engaged with the passion, belief and enthusiasm to make the DFSS initiative a success. The Program Office Most large companies have a matrix organization within engineering where engineering services support the product development programs; hence, the program office of program managers is a separate group. In other companies, the program manger may be a discipline, or role within engineering. But in either case, the program manager has the responsibility to develop a product that has a high level of quality within budget and on schedule. The program manager can make, or break the DFSS initiative. They typically have a tremendous amount of influence since they are the ones who ultimately are responsible for delivering products to the market, and they dont want anything to get in their way. Program managers often push back on the DFSS initiative since they see it as yet another layer of work for them to do on top of their already overburdened schedule. Thus, two important things must be done to win over the program managers, one is a pull technique, and the other is push. The best way to get program managers to adopt DFSS is to show them the value add it will bring to their bottom line. Showing them the value of predictive engineering to reduce the amount of engineering changes, optimization of the product performance to ensure on time delivery, minimizing the risks of rework at launch and meeting the stated customer needs will develop a pull from program managers. Once some of these success stories are presented to the program office, more and more program managers will want to apply the DFSS process to their programs. However, generating pull from program managers is often not enough to fully implement DFSS across the program since this will typically result in point solution, or Black Belt level projects only. Upper management must also push the program managers by setting new metrics for program success and holding the programs accountable to those metrics. The program management must also be held accountable for the new DFSS inspired deliverable at the gate reviews. Too often the metrics for program success is to release the product to manufacturing on time and within budget. The quality

of the product is an unspoken expectation. Delivery of product performance and producibility quality needs to become a stated demand via the new set of deliverables that ensures program management is using the process, methods and tools in DFSS to ensure product performance, reliability, manufacturability and of course, meets customer needs. Marketing The old saying, Garbage In, Garbage Out, applies to the inclusion of marketing in the DFSS initiative. Too often, marketing is not adequately involved in the DFSS initiative. One problem is that the D, that is Design in the DFSS acronym allows marketing to claim that DFSS is for engineering and does not apply to marketing. Actually, maybe DFSS should be renamed to SSPD, Six Sigma Product Development, to avoid the innuendo that it belongs only in engineering. Of course, nothing could be farther from the truth. It is imperative that marketing is included as an integral team in deploying DFSS. They are responsible in gather meaningful and accurate customer requirements for the new product development. They need to be trained and mentored on all the methods and tools that apply in their domain. They need to supply the guiding light to engineering so that the delivered product meets the customer expectations. Without this guidance, engineering will still produce a robust product, but will be forced to make assumptions of what will please the customer. The marketing executive management must become a true ally with engineering executive management to ensure a successful DFSS implementation and deployment program. Without marketing involvement, DFSS ends up becoming nothing more than a set of technical tools for engineering. Manufacturing Since manufacturing is the recipient of the product developed by engineering, they inherit all the problems that are buried in the product due to a lack of predictive engineering. Hence, manufacturing is typically a tremendous supporter of the DFSS initiative and should be included in championing the DFSS implementation initiative. To make matters worse, it is the manufacturing budget that typically is used for the fire fighting effort during product launch. Some companies even have an entire group, or department whose sole responsibility is to debug the product launch into production. This effort will never go away since even with the best effort in predictive engineering, there will still be some issues during production launch. But DFSS will significantly reduce this effort and capture the residual from the manufacturing budget as pure bottom line profit.

The DFSS process also mandates the involvement of manufacturing during product development in such activities as Design for Manufacturability& Assembly, process capability studies, tolerance allocation and process controls to meet design specifications. Again, manufacturing typically welcomes this participation with open arms since they will have some influence on setting the design specifications to meet manufacturing process, thus minimizing surprises during product launch. In summary, management at all levels must display their commitment by visibly engaging in the DFSS implementation and deployment activities and by holding their subordinates, their peers and themselves accountable to the execution of the implementation and deployment plan.

are mandatory to analyze, monitor and validate progress throughout the product development process. This would drive the behavior to use such DFSS tools as Affinity Diagrams (i.e. KJ Analysis), Quality Functional Deployment (i.e. House of Quality), and Design Failure Mode Effects Analysis (DFMEA). On the other hand, if use of these specific tools were listed as the stage gate deliverables, then the behavior could be to just use these tools just before the gate review to prove that they were done, which in turn, hence the check box scenario. But doing a good job at defining stage gate deliverables with good, quantifiable metrics is only the beginning. Holding the programs accountable for those deliverables is absolutely mandatory for behavior change success. There are many companies that go to the effort of redefining gate deliverables, but when a program shows up at the gate review without the deliverables, the review board succumbs to the pressures of product release schedules and budget constraints. This is a critical juncture in DFSS deployment where upper management must become engaged to enforce the accountability of program deliverables at gate reviews. This is also a key area where program management performance metrics must include abiding by the new set of gate deliverables, again, a mandate from upper management. This is one of the most telling issue where the rubber meets the road for upper management commitment and engagement. Some companies, however, have developed a method to give some flexibility in allowing the stage gate review boards to pass programs that have a critical mission to get to production as fast as possible. The deliverables are ranked, or weighted as to how important they are for program success. These rankings are also set as a metric in the product development process gate reviews. An example would be that of ten gate deliverables, three of them require a director level approval to be waved at the review in order to proceed to the next gate, four would need a vice president level approval to be waved and the remaining three deliverables are absolutely mandatory to proceed on to the next gate. In summary, the DFSS process needs to be woven as a thread into the existing product development process that will inevitably require new, or modified deliverables at the gate reviews. However, management enforcement to hold the programs accountable to these new deliverables is the key to successful implementation of this new process.

WEAVE DFSS INTO THE PRODUCT DEVELOPMENT PROCESS

Design for Six Sigma is more than a collection of tools. In fact, the vast majority of tools prescribed in DFSS has been around for many years, and have been recognized by other organizations, such as AIAG. (e.g. QFD, DFMEA, DFM/A, Tolerance Analysis, Robust Design, DOE, MSA, etc.). Unfortunately, many companies treat DFSS merely as a collection of tools for design engineering and thus, do not reap the benefits of deploying DFSS at the program level. DFSS is actually a process that prescribes these tools in an orderly method that matches the common product development process. Hence, DFSS can be viewed as a process thread within the product development process. Critical Parameter Management (CPM) is, in turn, a process thread within the DFSS process, which will be covered in more detail later in this paper. Figure 4 uses the AIAG APQP to illustrate the concept of mapping the classic five steps of the DFSS process as a thread within a product development process. In order to effectively develop the DFSS process thread within the product development process, the process owners need to establish a cross functional team to initiate this change. Team members would include representatives from such groups as engineering, marketing, manufacturing, regulatory control, quality, purchasing and supply chain management. Each team member will contribute to specific areas within the product development process. The starting point is to determine new, and modify some existing stage gate deliverables. These deliverables must be developed to drive behavioral change rather than a mere check box of items. The deliverable must state quantitative metrics that require the use of DFSS methods and tools rather than specifying the use of DFSS tools themselves. An example of this would be to require the submission of a list identifying the most critical, top level system requirements (i.e. CTQs) that

PROGRAM LAUNCH AND MANAGEMENT

Implementing DFSS within a product program entails two fundamental requirements; mapping out a plan for success and selecting an initial product program that will ensure success.

There are several aspects to program implementation planning that need to be addressed to ensure successful DFSS integration into the product development program: Upper management support and engagement is crucial for the program to be successful. As mentioned before, this includes the CEO Office and the Vice Presidents of Engineering, Marketing and Manufacturing. This group of people needs to support the program via funding and resources and be engaged in the program activities by enforcing accountability of the established success metrics. Develop specific DFSS deliverables and metrics that can be used to determine the progress and success of the program. It is imperative to do this to set proper expectations at all levels and to ensure that everyone is on the same page. This will also assist in the assignment of tasks to the various individuals and teams within the program. This is sometimes very difficult since many DFSS success metrics are either somewhat intangible or for cost avoidance, which does not allow for a definitive cost benefit during the execution of the program. Most of the benefits of DFSS come from statistically improved production launch and in customer satisfaction. DFSS does have definite ROI, albeit long term after the completion of the product development program. Thus, setting quality predictive metrics for product performance, reliability, producibility and affordability with a constant customer focus should be implemented during the product development program. For the first several DFSS Programs, augmenting the program budget and resource pool will be necessary. A team led by a seasoned DFSS Black Belt, or Master Black Belt needs to be assigned to the program team to ensure proper execution of the DFSS deliverables. The funding for this team is usually not charged the program, but rather out of general engineering overhead. Funding will also be necessary for additional engineering tools such as, software and testing equipment. This is one of the biggest challenges to upper management and will be a definite indicator of their support to shift the product development culture. Implementation of a DFSS Training Program to match the program deliverables is another key aspect to success. The Just-In-Time training method, as described in the next section, is a very effective way to transfer the DFSS tools and methodology knowledge to the program engineers, designers, technicians and managers. But additional Subject Matter Expert (SME) training will also be necessary for such complex tools as DOE, statistical tolerancing and measurement system analysis. Finally, as the program is under way, there should be a method to capture and document all the DFSS knowledge and lessons learned that resulted in this

effort. This should also include debugging the DFSS Process Thread within the Product Development Process as well as establishing the key business benefits to implementing DFSS on a product development program. Selecting a program to ensure success relies on proper selection of the program itself and the qualifications of the program manager. In selecting a program, this may actually be a major subsystem within a very large, complex program, or it may be an upgrade to an existing product, or it may be a relatively small program, or it may be identifying the top critical parameters that will be developed within the program. The best scenario is to have a mixture of all these types of programs to get a variety of knowledge capture and lessons learned that would accumulate over time and be applicable to future programs. This concept is illustrated in Figure 5. In all cases, the program needs to be aligned with the current, well known DFSS applications. This specifically includes mechanical products, electro-mechanical products and chemical, or process based products. DFSS is not currently well defined in the industry for embedded software development and definitions of a new transactional service. The definitions of these DFSS processes will be developed within the next year, but until then, the initial DFSS programs should not include these applications. The program manager is another crucial ingredient for success. This person must believe that the program will reap several benefits by applying the DFSS process to the product development activities. This person will need to express their passion in their belief of DFSS and enforce the development of the stated DFSS deliverables. Ultimately, this person must have an open mind to change in order to brake the paradigm of thats the way is has always been done. Hence this person must have strong leadership qualities and have the respect of upper management, as well as their peers. Obviously, this will be a very unique individual, but theses characteristics are absolutely essential for success. Another new aspect to program management that is involved in implementing DFSS is the embracing of predictive engineering analysis as a core activity within the program. Since the DFSS process calls for predictive engineering with variations throughout the development of the product, an Analysis Roadmap will need to be developed to ensure collaboration between all the discrete analyses. Critical Parameter Management, as described in a later section, is a key methodology in developing this Analysis Roadmap. In summary, to ensure successful implementation and deployment of DFSS at the program level requires proper planning with definitive success metrics, selecting a program aligned with the DFSS methodology and having a program manager that believes in the benefits of applying DFSS to the program.

JUST-IN-TIME DFSS TRAINING PROGRAM

Most companies initially implement DFSS using the classic Wave Training approach used to implement DMAIC Six Sigma in operations. While this method has some benefits, it usually does not shift the product development culture at the program level. Some of the benefits to this approach is that the discrete DFSS tools will get applied at a very local, or Black Belt project level. This training will also allow for some of the key people within the organization to bubble up to become the DFSS technical leaders. This method also begins to establish a common language of statistics, root cause effects, and other classic Six Sigma themes within engineering and marketing. In some respects, this could be viewed as getting a DFSS Bachelors Degree But the only way to get a Masters Degree and on to a PhD in DFSS is to implement DFSS at the program level. Since this entails such a focus on the product development process, the classic Wave Training model does not fit. In fact, it can actually be a negative. Consider Person A, who is at the beginning of a program and Person B who is at the end of a program. In classic Wave Training, people are recruited to attend the DFSS Black/Green Belt Training, regardless of where they are in the program. So, in Week 1 of the DFSS Training, Person A will get significant benefit of learning those tools (e.g. QFD, Pugh Selection, TRIZ, etc.), but there will be no applicability for Person B, and being a busy engineer, may even get annoyed by wasting their time. Just the opposite is Week 4 of the DFSS Training where Person B will get significant benefit of learning those tools (e.g. Robust Design, Statistical Tolerancing, MSA, etc.), but Person A will get no immediate benefit from this since their program my not use those tools for months, or maybe even years. Just-In-Time (JIT) DFSS Training maps the training to the product development program as illustrated in Figure 6. General awareness training should be made available to all the members of the program. In fact, this awareness training may actually be split into technical and managerial agendas for the respective target audiences. In both agendas, DFSS as a process thread within the product development process must be the core theme. The goal of this training is to shift the culture and describe the changes required to do so. Note that the technical DFSS training is mapped directly to the stages in the product development process. This allows the trainees to immediately apply these new tools with the help of the assigned DFSS Implementation Team. This training can either be offered to each program as they are progressing through the product development process. Or, it can be set up on a more corporate level basis with one of the prerequisites of being at a certain stage phase within the product development process before taking the incremental classes.

This method of JIT DFSS Training has been proven to be extremely effective in both the transfer of knowledge of the discrete DFSS tools, as well as enforcing the philosophy that DFSS is a process thread within the product development process.

CRITICAL PARAMETER MANAGEMENT

Consider the definition and prediction of the product performance during a product development program, and pose these questions: How can focus on customer satisfaction be maintained during the development of a product, right down to the component and supplier level? Which design features control the top-level product performance requirements, and how much? Where is all the product performance information and data, and who controls this? How often does a product development program reinvent the wheel since there is no way to transfer or share this knowledge from previous products? How can the DFSS process thread be enabled within the product development process?

Critical Parameter Management (CPM) answers all these questions, and more. CPM can become the go to resource for the product performance definition. For those involved in Systems Engineering, CPM is a subset of the classic Systems Requirements Management (SRM) activity that deals primarily with, which some systems engineers call, Technical Performance Measures (TPM). Another name for this subset of requirements that has been adopted within the general DFSS community is Critical to Quality (CTQ) parameters, a term that originated at GE. But in both cases, the Critical Parameters of CPM primarily focus on the key performance characteristics (KPC) of the product. CPM is the technical infrastructure thread that uses a disciplined methodology to capture all the product performance information and data into a structured repository. It also pulls together all the DFSS tools and information, which enables the DFSS process within the product development process. The fundamental concept of CPM is illustrated in Figure 6, which is sometimes referred to as the V Diagram. The left hand side illustrates the notion of flowing down the product requirements. This could be seen as the classic Systems Engineering activity that occurs in many companies and includes all types of requirements. However, in this environment, there are usually two shortcomings. The first is that in most cases, the Systems Engineering group architects the product

configuration and flows down requirements to a certain level within the product hierarchy and then dishes off the responsibility for a subsystem design team to develop their portion of the product to the stated requirements. Also, there is no traceability of the design specifications up to the system level requirements. Second, the studies, or analyses done at the system level to develop the architecture and requirements are not tied together to allow for contention management or for flowing up of design predictions. This paper will only focus on the flow down of performance requirements/parameters. Thus, the left side of the V Diagram in Figure 7 represents the technical performance requirements. The right side illustrates the concept of flowing up a prediction of these same performance parameters via quantitative, mathematical relationships, often referred to as transfer functions in the DFSS community. Note that these predictions include both the nominal and variations. The predicted results of these performance parameters can then be compared against the established target limits of the requirements to get a Cp and Cpk, a metric to measure the variability of the performance parameter. Of course, a Cp of 2, and a Cpk of 1.5 represent a parameter that will perform at the Six Sigma level. The first step is to capture a qualitative representation of the product performance into a hierarchy of parameters. This knowledge exists in every engineering organization since most companies are producing products that perform as intended by design (how well is another question). This is sometimes referred to as the Tribal Knowledge of the product performance. There are several resources of that knowledge, marketing, systems engineering, product design teams, subject matter experts, manufacturing, partners, and suppliers. The flow down of the performance parameters along with their interactions can be developed by simply interview all the aforementioned knowledge resources that make up the Tribal Knowledge. This is illustrated in Figure 8. Even thought this product performance information set is qualitative and a result of essentially opinions and gut feel of the various knowledge resources, CPM pulls all these groups and individuals together to take a top down, or systems level view point of the product performance. This reverses the approach of designing in silos, then trying to bring the silos together into the product. Also, it exposes all the interactions between the silos and enables a forum to discuss these interactions and to remain cognizant of them during the product design process. This CPM exercise alone brings tremendous value to the product development program and creates a template of captured knowledge that can be referred to throughout the program. Many of the classic DFSS tools directly assist in the development of this CPM tree, such as gathering the Voice of Customer, the House of Quality and the Pugh Selection Matrix. Other DFSS tools that indirectly

contribute to the development of this CPM tree are KJ and Kano analyses, TRIZ, and DFMEA. However, the holy grail of CPM is the development of the transfer functions to quantifiably relate the parameters. This will inevitably prove, or disprove the Tribal Knowledge relationship established in the flow down exercise of CPM. It also then allows for the flow up of product performance predictions, both to prove the design performance viability and to make the performance parameters robust against producibility variations, as well as use case variations. Figure 9 illustrates the flow up of performance predictions. Given the multiple interactions of both the individual contributors, as well as the transfer functions themselves, the program management will need to develop an Analysis Roadmap. This essentially maps the inputs and outputs of the multiple transfer functions, which are made up of several disassociated resources such as spreadsheets, point solution software and highend simulation modeling. The CPM tree essentially develops this Analysis Roadmap, as well as manages all the interactions and interrelationships. Even without transfer functions the qualitative CPM tree serves as an excellent investigative resource if a parameter fails a validation test. As shown in Figure 9 on the right hand side, if a parameter fails a validation test, the CPM tree allows the design team to first, investigate what this failure will affect (i.e. flow up from this point), and secondly, it will allow the design team to investigate those subordinate parameters that could possibly be modified to adjust the measured parameter to pass the test (i.e. flow down from that point). Of course, all the interactions between the design silos are also traceable. There are many benefits that CPM brings to the product development program, as well as to the individual team members: Maintains a customer focus via traceability to VOCs.

Determines where to focus resources to develop transfer functions. Assists in Roadmap. the development of an Analysis

Tracks performance predictions and test results. New, or replacement resources get up to speed quicker via the CPM Tree Communication tool for review meetings, reports, etc. Transfer to manufacturing to reduce post launch involvement.

However the greatest benefit of implementing CPM is the reuse and sharing of the captured knowledge as illustrated in Figure 10. The left image represents capturing the original product knowledge that can then be reused for the following generations of that design. This will reduce the reinvent the wheel syndrome, especially since the engineering personnel are usually not the same from program to program. The right image represents developing the CPM knowledge tree for a product line with in a platform of designs, and then sharing this knowledge with the other product lines within the platform. Other examples of CPM knowledge sharing are the modular design methodology, transferring a new product innovation from R&D into the existing product line, and passing the CPM tree from engineering to manufacturing so they can investigate the effects of a process going out of spec. Think of all the cost benefits of this knowledge reuse, sharing and distribution, albeit very difficult to quantify. In summary, Critical Parameter Management is the technical infrastructure thread that supports the DFSS process, and ultimately the product development process. The disciplined capturing of product performance knowledge into a structured repository brings significant value to the product development program itself, but also tremendous vale to the company through the ability to reuse, share and distribute this product performance knowledge throughout the organization.

the DFSS process thread into the product development process serves as a guide to the program managers and will require the CPM infrastructure. Program management will require upper management support via funding and resources, will need the DFSS process thread documented for guidance, will require JIT Training to enable DFSS and will need CPM to serve as the infrastructure enabling agent for DFSS. JIT Training will be mapped to the DFSS process thread and use CPM as the enabling agent. CPM will require upper management support, a defined DFSS process thread, JIT Training to enable it and adoption by program management. Using all these ingredients, DFSS will eventually go away, and this new way of developing products will just be the norm within the organization.

ACKNOWLEDGMENTS
The author would like to thank the numerous companies for the opportunity to discuss, and in some cases participate in their DFSS implementation program, which contributed to the observations presented in this paper, most notably, Raytheon, Cummins, 3M, Maytag, Motorola, Casco Products, Boston Scientific, Becton Dickenson, Seagate, and Ethicon Endo Surgery. Special thanks also must go to Mr. Skip Creveling of Product Development Systems and Solutions, Incorporated, for the early years of training, mentoring, and now with his implementation partnerships at several clients.

CONCLUSION
Obtaining the full benefits of improved product development via DFSS demands that DFSS be considered a process thread within the product development process rather than a collection of tools. This paper has identified five important topics, when implemented, will indeed raise DFSS to the program level: Management Engagement at all Levels Weave DFSS in the Product Development Process Program Launch and Management Considerations Just-In-Time DFSS Training Program Implement Critical Parameter Management

CONTACT
Tom Judd is Vice President, Six Sigma Solutions at Cognition Corporation, and has been a DFSS Black Belt for over four years. Cognition is a supplier of consulting services and software tools that directly support the Program Level implementation of DFSS. Tom works with many companies to elevate their DFSS Implementation so it becomes a true thread within the product development process. He also mentors companies on Critical Parameter Management, the practice of identifying critical design parameters and optimizing the variations of these parameters to maximize customer satisfaction. He is currently working with several Fortune 500 Companies and top DFSS Consultants to assist in implementing an effective and successful DFSS environment. Tom has over 25 years of product development experience and a B.S.M.E and M.S.M.E in mechanical engineering from Michigan Technological University. Tom can be reached at (734) 542-9215 x200 or tom.judd@cognition.us.

However, it must be realized that these five areas of implementation intertwine with each other. Management engagement is required to change the culture that will adopt the DFSS process, establish new metrics for program management, and implement CPM. Weaving

APPENDIX -- FIGURES

FIGURE 1. THE PRODCUT DEVELOPMENT GOAL OF DFSS

FIGURE 2. PRODUCT COST BREAKDOWN

FIGURE 3. MANAGEMENT COMMITMENT TO DFSS

FIGURE 4. DFSS IN THE PRODCUT DEVELOPMENT PROCESS

FIGURE 5. DFSS PROGRAM SELECTION

FIGURE 6. DFSS JUST-IN-TIME TRAINING

FIGURE 7. THE CPM V DIAGRAM

FIGURE 8. DEVELOPMENT OF THE CPM TREE

FIGURE 9. THE ANALYTICS OF CPM

FIGURE 10. KNOWLEDGE CAPTURE AND SHARING VIA CPM