Journal Search Engine
Search Advanced Search Adode Reader(link)
Download PDF Export Citaion korean bibliography PMC previewer
ISSN : 1598-7248 (Print)
ISSN : 2234-6473 (Online)
Industrial Engineering & Management Systems Vol.11 No.4 pp.346-352

A Design for Six Sigma: A Robust Tool in Systems Engineering Process

Jai-Hyun Byun*, Hee-Kweon Yoon
Department of Industrial and Systems Engineering, Engineering Research Institute, Gyeongsang National University, Jinju, Korea
Research and Development Division, Korea Aerospace Industries Ltd., Sacheon, Korea
(Received: February 8, 2012 / Revised: August 29, 2012 / Accepted: November 16, 2012)


While systems engineering has been widely applied to complex system development, some evidences are reportedabout major budget and schedule overruns in systems engineering applied. On the other hand, many organizationshave been deploying Design for Six Sigma (DFSS) to build Six Sigma momentums in the area of design and developmentfor their products and processes. To explore the possibility of having a DFSS complement systems engineeringprocess, this process reviews the systems engineering with their categories of effort and DFSS with its methodologies.A comparison of the systems engineering process and DFSS indicates that DFSS can be a complement to systemsengineering for delivering higher quality products to customers faster at a lower cost. We suggest a simplifiedframework of systems engineering process, that is, PADOV which was derived from the generic systems engineeringprocess which has been applied to the development of T-50 advanced supersonic trainer aircraft by Korea AerospaceIndustries (KAI) with technical assistance of Lockheed Martin. We demonstrated that each phase of PADOV frameworkis comprehensively matched to the pertinent categories of systems engineering effort from various standards.


 The systems engineering process has been applied iteratively throughout the system life cycle to translate stated problems into design requirements, providing an integrated system solution consisting of people, products, and processes that provides a capability to satisfy customer needs (US Department of Defense, 1991).

 Systems engineering is regarded as an established, sound practice, but it has not always delivered effectively because of space systems document major budget and schedule overruns (INCOSE, 2007). Judd (2005) addresses the typical split of a program’s engineering budget where the majority of the budget dollars are spent on post-launch support.

 On the other hand, many companies around the world apply Six Sigma to their business processes. Six Sigma is a quality methodology which aims quality goal of no more than 3.4 defects per million opportunities (DPMO). Six Sigma enables them to dramatically reduce defect rates and quality costs in their products and services, which leads to customer satisfaction and a potential edge over competitors. Six Sigma is evolved into Design for Six Sigma (DFSS) which is applied not only to product design and development but also to service systems design. Antony (2002) regards DFSS as a powerful approach to design products and processes in a cost effective manner.

Although both the systems engineering process and DFSS aim at the same objectives, literature reviews out of 417 referred journal articles on Six Sigma by Aboelmaged (2010) do not show that there is an article which addresses some relationship between DFSS and the systems engineering process.  

 Therefore, we explore whether DFSS can be a robust tool to strengthen the systems engineering process for delivering higher quality products to customers at lower cost and faster time.

 This paper is organized as follows. In Section 2, the systems engineering process is reviewed for its various categories of effort. In Section 3, DFSS is outlined for its applicability to any product development programs. Section 4 compares DFSS methodology and systems engineering process. Section 5 applies DFSS to the systems engineering process. Concluding remarks are given in Section 6.


2.1 Standards of Systems Engineering Process

Sheard and Lake (1998) discussed the similarities and differences among five systems engineering standards and three systems engineering capability models. Honour and Valerdi (2006) advanced an ontology of systems engineering through useful quantification of desired correlations. They show and compare the content of the current standards, in the context of an ontology that describes the relationship of various categories of effort that are widely viewed as “systems engineering.” 

Table 1. Systems engineering (SE) effort categories evident in the standards (Honour and Valerdi, 2006; Kasser, 2010)

The standard of ANSI/EIA-632 enables an enterprise to strengthen its competitiveness in the global market by engineering and quality systems, and by delivering its products on time at an affordable price or cost, and they also focus on conceptualizing, creating, and realizing a system and the products that make up a system (EIA, 1999). On the other hand, the standard of ISO/IEC 15288 provides a common process framework covering the life cycle of man-made systems, and it also can be used in one or more of the following modes: by an organization, by a project, or by an acquirer and a supplier (ISO, 2002). And the standard of IEEE Standard 1220–1998 focuses on engineering activities necessary to guide product development (IEEE, 1999).  

 From Table 1, these standards show that a product is developed through decomposition from mission requirement to functional and physical components which are integrated into the product and verified to meet this requirement. While these standards do address the mission/ purpose definition activities to some extent, they do not cover the conceptual activities in the early stages of systems engineering process (Kasser, 2010).

2.2 Generic Systems Engineering Process

 Lockheed Martin deployed a generic systems engineering process for the development of their highly complex systems, which is subdivided into two processes: technical development process and technical management process (Dean et al., 1997). Korea Aerospace Industries (KAI) successfully developed T-50 advanced supersonic trainer aircraft by applying this generic systems engineering process with the technical assistance of Lockheed Martin.

 The technical development process consists of subprocesses of analyzing customer requirement, defining architectures, optimizing design, and verifying the system. Analyzing customer requirement includes analyzing customer’s operational mission requirement or system level requirement. Defining architecture encompasses functional analysis to breakdown the system level requirement into required low level functions like subsystem and component level. And also it incorporates the selection of candidate architecture of physical, functional, and interface baseline. Optimizing design is to trade-off design parameters to achieve the best system effectiveness like life cycle cost, reliability, and so on. Verifying the system is to ensure that the synthesis satisfies functional performance requirement at each level.

 The technical management process consists of planning technical effort, managing risks, assessing and controlling technical effort, and controlling baseline. Planning the technical effort is to have tasks and plans defined, organized, coordinated, and integrated. Managing risks is to identify, assess, and handle risks associated with schedule/cost/performance for all phases of the technical development process. Assessing and controlling technical effort includes various kinds of design reviews and monitoring/controlling program defined technical performance measures (TPMs). TPMs are used to trace the progress or status of the design and development process. Controlling baseline is to manage configuration of the system.

2.3 Simplified Framework of Systems Engineering Process

By placing planning phase of the technical management process, that is, ‘planning technical effort’ prior to the technical development process as well as imparting other sub-processes of the technical management process to each phase of the technical development process, we can formulate the framework of a new simplified design and development process. This framework (abbreviated as ‘PADOV’) is shown in Figure 1. 

Figure. 1. A simplified framework of design and development process (PADOV).

Table 2. Systems engineering (SE) categories and PADOV

The phases of PADOV framework can be matched with the elements of these systems engineering standards. In Table 2, it is shown that the PADOV framework covers various categories of effort of the current systems engineering standards. This implies that PADOV framework can be applied to the development of products and services as one of the systems engineering processes.


3.1 Introduction of DFSS

Six Sigma define, measure, analyze, improve, control (DMAIC) process focuses on the improvement of manufacturing or servicing processes. A new methodology is required to exceed five sigma levels of performance because campaigns to improve existing products and processes encounter a barrier as they approach five sigma under DMAIC process (Chowdhury, 2002). In addition, a new process is required to be introduced so as to handle the quality from the beginning of a product development program, as Kiemele (2003) mentions that the relative cost of design change at production stage is approximately one thousand times higher than that of design change at research stage. DFSS is used for new processes or when the existing processes are unable to achieve business objectives such as customer satisfaction (Andersson et al., 2006). The first DFSS roadmap was proposed by Motorola to extend the realm of Six Sigma to the design and development of products and processes (Park, 2003). DFSS approach enabled General Electric (GE) to introduce a light speed medical computed tomography scanner which was nine times faster and ten times more reliable than other contemporary scanners. From the successful deployment of the DFSS for the new scanner, GE expanded the application of the DFSS process to all corporate areas (Harry and Schroeder, 2000). Nowadays many organizations are adopting DFSS not only in product design and development but also in service system design. Chung and Hsu (2010) showed that the implementation level of DFSS activities has significant influence on business competitiveness (cost reduction and differentiation). 

Figure. 2. Benefits of Design for Six Sigma (DFSS) deployment.

Figure 2 shows that DFSS can dramatically reduce the number of engineering changes after the drawing release and product delivery. While the traditional product development process is a reactive design, where frequent firefighting against quality issues occurs, DFSS is a proactive design to prevent the fire (Chowdhury, 2002). The former provides quality “tested in,” but the latter has quality “designed in.” 

3.2 DFSS Methodologies

 Although organizations consider DFSS as a powerful tool for the design and development of their products and services, they found that there is no standard methodology in DFSS. Therefore, they need to consult with a consulting firm which can review their products and processes and recommend a proper DFSS methodology. If organizations have strong enthusiasm for developing and applying their own DFSS methodology, they benchmark other organization’s cases and invent their own roadmap which can be efficiently and effectively deployed in their organizations (Soderborg, 2004).

 While Six Sigma has a well defined roadmap of DMAIC, DFSS has various roadmaps like; identify, design, optimize, validate (IDOV), define, measure, analyze, design, verify (DMADV), define, measure, analyze, design, optimize, verify (DMADOV), concept, design, optimize, verify (CDOV), identify, characterize, optimize, verify (ICOV), define, measure, explore, design, implement (DMEDI), invention and innovation, develop, optimize, verify (I2DOV), etc. This diversity originates from the fact that each company has been trying to adopt the DFSS process in alignment with its own respective product development process under its own business environment.

Antony (2002) explained that IDOV roadmap has four stages: 1) Identification stage ensures that the organization understands the criteria for success; 2) Design stage translates parametric requirements into the actual and effective design; 3) Optimization stage involves the further consideration of design to ensure effective “makeability”–so that the organization is confident the product can be manufactured within the identified design parameters, and the agreed budget; 4) Validation stage checks that the process is complete, valid, and will meet requirements in practice.  

DMADV is the most prevalent DFSS roadmap at the rate of 47% (Atwood, 2005). As Agarwal (2006) states that the DMADV roadmap can be employed if a current process requires more than just incremental improvement, this roadmap can be applied to product/service improvement projects based upon previous design and process like cost reduction, efficiency increase, and optimization of previous design and process.  

Case studies of Delphi Thermal Systems (Chatt et al., 2008), GE Power Systems (Vandervort and Kudlacik, 2001), and Xerox (Hilderbrand, 2007) using IDOV/IDDOV roadmap show that: 1) This roadmap is more applicable to new product development projects because these projects require new concepts or architectures from beginning; and 2) This roadmap is more matched to generic product design and development process from conceptual design through introduction into services. IDOV/ IDDOV can be adopted for introducing a new product in a new market.  

The customer driven product/service development is critical for creating a new market. For product/service model change in pursuit of increasing the market volume, define, customer, concept, design, implement (DCCDI) can be employed because this roadmap is suggested for putting more emphasis on investigating voice of customer than DMADV (Tennant, 2002). New model changes with a common platform cannot be successful without investigating customer needs.  

For the new technology developments, I2DOV is suggested by Creveling et al. (2003). The phase of invention and innovation enables us to construct technology roadmaps, define product line strategies and family plans, and conduct innovation.  

 Wong (2007) presents various Six Sigma approaches in Motorola which use DMADV for developing a new process, CDOV for hardware product design, and I2DOV for developing the technology platform for the identified product portfolio.


While DMAIC is applied to all Six Sigma projects, DFSS has various roadmaps, which makes it hard to apply a proper DFSS roadmap for the product/service design and development. When organizations try to deploy DFSS, they encounter such issues as the following: 1) Which DFSS roadmap is proper to be integrated into the organization’s previously established product development process?; 2) How DFSS methodology can be effectively applied to the organization’s project ranging from technology development to a new product development?; and 3) If a new DFSS roadmap needs to be created for the organization, what phases are necessary for the roadmap?  

 Soderborg (2004) tried to create a DFSS methodology for product development entailing at least three different categories of scope: the creation of a new product or technology, the evolution of a next generation product from a current design, or the enhancement of an existing product. He stated that the effort of devising a single DFSS flowchart is abandoned due to the failure to adequately address different project categories and represent iteration in the process.

Watson and DeYoung (2010) pointed out that distinctions in the way that DFSS is applied will vary by organizational business model and the application of a specific logical model needed to comprehend the distinctions in product design and development process for various types of businesses. However, he challenges developing the standard logical models for DFSS as those for Six Sigma.  

Perceiving that systems engineering process has been widely applied to product design and development including the above three project categories of scope, we may explore to examine whether PADOV–the generic framework of systems engineering process–can be equivalent to DFSS methodologies which are applied to organization’s product/service development projects.  

 Each DFSS roadmap needs to be composed of essential phases of the process of product and service development. Table 3 shows that the phases of each DFSS roadmap match with those of the simplified PADOV process.

Table 3. DFSS roadmaps matched with PADOV

A respective phase of DFSS roadmaps like DMADV, DMEDI, and IDDOV corresponds to a respective phase of PADOV in terms of phase sequence of project lifecycle. Phases except the first phase of IDOV, CDOV, and DCOV are equivalent to the corresponding phases of “DOV” of PADOV. The first phase of IDOV, CDOV, and DCOV covers the first two phases of PADOV.  

Figure. 3. Interconnection diagram through PADOV.

 Figure 3 shows various methodologies such as project management (PM), product development (PD), quality management (QM), DFSS along with systems engineering (SE). From the viewpoint of scope, all the other methodologies are enclosed by QM, SE by PM, and PD by SE. However, from the viewpoint of concern, QM focuses on improvement of quality of all the matters of enterprise, PM on resource management and project control, SE on allocation and integration of interdisciplinary works for system development, and PD on the product design and development process. These are complementary to each other. DFSS and SE share common process through PADOV so that DFSS can complement SE more effectively than other methodologies.

Figure 3 shows various methodologies such as project management (PM), product development (PD), quality management (QM), DFSS along with systems engineering (SE). From the viewpoint of scope, all the other methodologies are enclosed by QM, SE by PM, and PD by SE. However, from the viewpoint of concern, QM focuses on improvement of quality of all the matters of enterprise, PM on resource management and project control, SE on allocation and integration of interdisciplinary works for system development, and PD on the product design and development process. These are complementary to each other. DFSS and SE share common process through PADOV so that DFSS can complement SE more effectively than other methodologies. 


5.1 Application of DFSS Tools

Vanek et al. (2008) addressed that evidence from the fields, such as QM or Design for Six Sigma, suggests that techniques from these fields that resemble SE techniques have already been contributing to project and organizational success. Hasenkamp (2010) clarified the contribution of DFSS to the different stages of a systematic engineering design process.  

 Honour et al. (2004) stated that we know that SE is useful in general, but don’t know “which practices are useful under what conditions.” In contrast to the unnoticeable practice, DFSS methodologies specify many tools as available.

 There are many DFSS tools available from planning stage to verifying stage. As for tools of each phase of PADOV framework, Table 4 lists most kinds of tools which have already been used for the various DFSS methodologies. Some of the tools like design of experiment (DOE) or failure modes and effects analysis (FMEA) can be applied in many phases if needed while complex system development DFSS tools can be selected to be applied to a certain issue area.

5.2 Application at Project/Program Level

The military/aerospace industries have several decades of experience in the application of SE (Vanek et al., 2008). Likewise DFSS is recently and widely implemented project by project among industries. However, DFSS has not been widely and fully applied to complex system development at program level (Creveling et al., 2003; Judd, 2005; Yang and El-Haik, 2003; Treichler, 2005).  

DFSS could not be deployed at program level in complex system development due to factors of complexities, organizations, resources, schedules, and requirements (Yoon and Byun, 2011). The highly complex and very conservative characteristics of a development program in the complex product industry like the aircraft industry keep DFSS from being deployed at program level.  

 Program structure, engagement of top management, phases and gates, and traceability for critical parameters are main considerations for the program level deployment. A program is to be subdivided into many DFSS projects whose schedules and tasks need to be integrated into the DFSS program. Top management needs to be involved in making all participants from disciplines empowered. Phases and gates need to be planned to incorporate the major reviews and related DFSS tools for each phase. Critical parameter management (CPM) needs to manage system performance parameters complicatedly correlated with the variation of design parameters and process variables.

Table 4. Design for Six Sigma (DFSS) tool matrix applied to PADOV


In this paper, a simplified framework of systems engineering process, i.e., PADOV was derived from the generic systems engineering process which has been applied to the development of T-50 advanced supersonic trainer aircraft by KAI with technical assistance of Lockheed Martin.  

We demonstrated that each phase of PADOV framework is comprehensively matched to the pertinent categories of systems engineering effort from various standards of ANSI/EIA-632, ISO/IEC 15288, and IEEE Standard 1220–1998.  

 PADOV can be a kind of DFSS roadmap as a result of comparative analyses that a respective phase of DFSS roadmaps, including DMADV, IDOV, DMEDI, and DCCDI, corresponds to a respective phase of PADOV, and that all the DFSS tools are specifically applicable to each phase of PADOV.

 These findings led us to conclude that the DFSS methodology can complement systems engineering process at specific project level rather than at complex program level.


1.Aboelmaged, M. G. (2010), Six Sigma quality: a structured review and implications for future research, International Journal of Quality and Reliability Management, 27(3), 268-317.
2.Agarwal, R. (2006), Managing outsourcing: IT or business, Proceedings of the International Conference on Recent Trends in Information Systems, Thiruvencheery, India, 662-666.
3.Andersson, R., Eriksson, H., and Torstensson, H. (2006), Similarities and differences between TQM, Six Sigma and lean, The TQM Magazine, 18(3), 282- 296.
4.Antony, J. (2002), Design for Six Sigma: a breakthrough business improvement strategy for achieving competitive advantage, Work Study, 51(1), 6-8.
5.Atwood, J. (2005), Using design for Six Sigma, iSIXSIGMA Magazine, 1(4), 1-7.
6.Chatt, D. M., Hendricks, M. E., and Wintersteen, D. C. (2008), Joint design for electronics cooling heat exchangers project example, iSIXSIGMA Magazine, 4(4), 1-7.
7.Chowdhury, S. (2002), Design for Six Sigma: the Revolutionary Process for Achieving Extraordinary Profits, Dearborn Trade Publishing, Chicago, IL.
8.Chung, Y. C. and Hsu, Y. W. (2010), Research on the correlation between design for Six Sigma implementation activity levels, new product development strategies and new product development performance in Taiwan's high-tech manufacturers, Total Quality Management & Business Excellence, 21(6), 603-616.
9.Creveling, C. M., Slutscky, J., and Antis, D. (2003), Design for Six Sigma in Technology and Product Development, Prentice Hall, Upper Saddle River, NJ.
10.Dean, F. F., Bentz, B., and Bahill, A. T. (1997), A road map for implementing systems engineering, SAND 97-0412, Sandia National Labs., Albuquerque, NM.
11.EIA (1999), ANSI/EIA-632-1998: Processes for Engineering a System, Electronic Industries Association, Arlington, VA.
12.Harry, M. J. and Schroeder, R. (2000), Six Sigma: The Breakthrough Management Strategy Revolutionizing the World's Top Corporations, Currency, New York, NJ.
13.Hasenkamp, T. (2010), Engineering Design for Six Sigma: a systematic approach, Quality and Reliability Engineering International, 26(4), 317-324.
14.Hilderbrand, B. (2007), Photoreceptor belt tensioning system project example, iSIXSIGMA Magazine, 3 (4), 1-7.
15.Honour, E. C., Axelband, E., and Rhodes, D. (2004), Value of systems engineering, Technical Report, Lean Aerospace Initiative, Pensacola, FL.
16.Honour, E. C. and Valerdi, R. (2006), Advancing an ontology for systems engineering to allow consistent measurement, Proceedings of the Conference on Systems Engineering Research, Los Angeles, CA, 1-12.
17.IEEE (1999), 1220–1998 IEEE Standard for Application and Management of the Systems Engineering Process, Institute of Electrical and Electronics Engineers, Piscataway, NJ.
18.INCOSE (2007), Systems Engineering Handbook: a Guide for System Life Cycle Processes and Activities, International Council on Systems Engineering, Seattle, WA.
19.ISO (2002), ISO/IEC 15288: 2002-Systems Engineering: System Life Cycle Processes, International Organization for Standardization, Geneva, Switzerland.
20.Judd, T. (2005), Program level design for Six Sigma, SAE Technical Report 2005-01-1210, SAE International, Warrendale, PA.
21.Kasser, J. E. (2010), Seven systems engineering myths and the corresponding realities, Proceedings of the Systems Engineering Test and Evaluation Conference, Adelaide, Australia, 1-13.
22.Kiemele, M. J. (2003), Using the design for Six Sigma (DFSS) approach to design, test, and evaluate to reduce program risk, Proceedings of the NDIA Software Test and Evaluation Summit/Workship, Victoria, Canada.
23.Park, S. H. (2003), Six Sigma for Quality and Productivity Promotion, Asian Productivity Organization, Tokyo, Japan.
24.Sheard, S. A. and Lake, J. G. (1998), Systems engineering standards and models compared, Proceedings of the 8th Annual International Symposium of INCOSE, Vancouver, Canada.
25.Soderborg, N. R. (2004), Design for Six Sigma at Ford, Six Sigma Forum Magazine, 4(1), 15-22.
26.Tennant, G. (2002), Design for Six Sigma: Launching New Products and Services without Failure, Gower Publishing, Burlington, VT.
27.Treichler, D. H. (2005), Design for Six Sigma: lessons learned: embedding DFSS within an organization's culture, Technology Today, 1, 20-21.
28.US Department of Defense (1991), MIL-STD-499B Draft 910515: systems engineering, US Department of Defense, Washington, DC.
29.Vandervort, C. L. and Kudlacik, E. L. (2001), GE generator technology update, GE Power Systems, Schenectady, NY,
30.Vanek, F., Jackson, P., and Grzybowski, R. (2008), Systems engineering metrics and applications in product development: A critical literature review and agenda for further research, Systems Engineering, 11(2), 107-124.
31.Watson, G. H. and DeYoung, C. F. (2010), Design for Six Sigma: caveat emptor, International Journal of Lean Six Sigma, 1(1), 66-84.
32.Wong, P. W. (2007), Motorola and Six Sigma, Proceedings of ASTD International Conference & Exposition, Atlanta, GA, W110.
33.Yang, K. and El-Haik, B. (2003), Design for Six Sigma: A Roadmap for Product Development, McGraw- Hill, New York, NY.
34.Yoon, H. K. and Byun, J. H. (2011), A program level application of design for Six Sigma in the aircraft industry, Industrial Engineering and Management Systems, 10(3), 232-237.
Do not open for a day Close