12. Design for Six Sigma and Robust Design

Introduction and Context

Traditional Six Sigma improvement methods generally begin with an existing process and seek to reduce defects, variation, cost, or cycle time. Their central logic is corrective: measure current performance, identify causes of failure, improve the process, and control the gains. Design for Six Sigma (DFSS) addresses a different managerial and engineering problem. It is used when a product, service, or process is being newly designed, substantially redesigned, or developed for a fundamentally different customer requirement. At that point, historical process data may be limited, and correcting defects after launch may be expensive or strategically damaging.

DFSS therefore shifts quality responsibility upstream. Instead of asking how an existing process can be repaired, it asks what customers value, how those needs can be translated into design requirements, how alternative concepts should be evaluated, and how the resulting design can remain capable under real operating conditions. Robust design extends this logic by making performance relatively insensitive to sources of variation that cannot be economically eliminated.

This chapter examines DMADV and related DFSS frameworks, Quality Function Deployment (QFD), failure analysis, reliability, tolerance design, design of experiments, and Taguchi-inspired robust design. These methods are not isolated tools. They form an integrated approach in which the voice of the customer is converted into measurable technical characteristics, risks are anticipated before production, and product or process performance is optimized for both nominal value and variation.

Learning Objectives

After studying this chapter, students should be able to:

1. Distinguish DMAIC from DMADV and select an appropriate DFSS approach.

2. Explain the logic and application of QFD, FMEA, reliability analysis, tolerance design, and robust design.

3. Translate customer requirements into measurable design specifications.

4. Use risk, capability, reliability, and experimental evidence in design decisions.

5. Evaluate managerial, ethical, technological, and implementation issues in DFSS.

6. Apply an integrated DFSS framework to a product, service, or process design problem.

From Process Improvement to Design Prevention

Quality cannot be inspected into a design after the important design decisions have already been made. Material selection, architecture, interfaces, software logic, process sequence, maintainability, and safety margins frequently determine most of the eventual cost and performance. Later inspection may identify failures, but it cannot always remove their underlying causes.

DMAIC is appropriate when a stable process exists and a meaningful performance gap can be measured. Its stages—Define, Measure, Analyze, Improve, and Control—rely substantially on current-state data. DFSS is appropriate when:

• a new product or service is being created;
• an existing design cannot meet strategic customer requirements;
• a process is being developed for a new technology or market;
• redesign would be more effective than repeated correction; or
• failure prevention, safety, reliability, or regulatory performance must be designed in from the beginning.

The distinction is not absolute. A redesign project may use DMAIC to understand the weaknesses of an existing offering and then use DMADV to create its successor. Similarly, DFSS projects use many familiar Six Sigma tools, including process maps, statistical analysis, risk assessment, measurement-system evaluation, and design of experiments.

DMADV: A Design-Centred Framework

DMADV stands for Define, Measure, Analyze, Design, and Verify. It is a widely used DFSS framework, although organizations also use variants such as IDOV (Identify, Design, Optimize, Validate) and DMEDI (Define, Measure, Explore, Develop, Implement). The names differ, but the underlying logic is similar: understand requirements, generate and evaluate design alternatives, and verify performance before full-scale implementation.

Define

The Define phase establishes the business case, customer or stakeholder groups, scope, constraints, objectives, governance, and project responsibilities. A good project charter should state the problem in design terms rather than prematurely prescribe a solution. “Develop an electronic approval service that reduces customer effort while meeting security requirements” is more useful than “install a mobile application.”

The phase should identify critical-to-quality characteristics (CTQs), key regulatory obligations, expected volumes, cost boundaries, risks, and the relationship between the project and organizational strategy. Cross-functional participation is essential because design quality depends on marketing, operations, engineering, procurement, finance, information technology, service personnel, and customers.

Measure

Measure in DFSS does not simply document current process performance. It establishes reliable evidence about customer needs, competitive performance, use conditions, existing failure modes, and the measurement systems that will assess the new design. Methods may include interviews, observation, complaint analysis, surveys, benchmarking, conjoint studies, service data, field-return records, and voice-of-customer research.

Customer statements are often ambiguous. “The device should be easy to use” must be translated into observable measures such as task completion time, number of errors, training time, or percentage of users completing a task without assistance. The measurement plan must also consider sampling bias. A survey of only expert users may conceal difficulties experienced by first-time or physically constrained users.

Analyze

Analysis converts needs into design priorities and compares possible concepts. QFD, functional analysis, morphological charts, benchmarking, decision matrices, FMEA, fault-tree analysis, reliability prediction, and preliminary economic analysis may be used. The team evaluates not only whether a concept can meet a target, but also whether it can be produced, serviced, regulated, upgraded, and supported over its life cycle.

Concept selection should make assumptions visible. A weighted decision matrix, for example, is useful only when criteria, weights, rating scales, and evidence are transparent. Excessive precision in scores can create a false appearance of objectivity. Sensitivity analysis should test whether a small change in weights would reverse the decision.

Design

The Design phase converts the selected concept into detailed product, service, process, and control specifications. It may include parameter design, tolerance allocation, prototype development, simulation, design experiments, human-factors evaluation, supplier planning, mistake-proofing, and control-plan development.

Design reviews should occur at several levels: system architecture, subsystem interfaces, detailed components, process realization, software, safety, and service delivery. Verification criteria should be defined before testing so that teams do not modify acceptance rules after observing results.

Verify

Verification establishes whether the design meets its specified requirements under expected and, where appropriate, stressed conditions. Validation asks a related but broader question: whether the product or service meets the real user need in its intended environment. A design can pass a laboratory specification and still fail in field use because of environmental conditions, misuse, accessibility problems, maintenance constraints, or unanticipated interactions.

Verification activities include pilot production, reliability testing, usability testing, measurement-system confirmation, process capability studies, supplier qualification, software testing, regulatory approval, and customer trials. A successful DFSS project ends with controlled transfer to operations and a documented learning loop, not merely a prototype demonstration.

Translating the Voice of the Customer through QFD

Quality Function Deployment is a structured method for translating customer requirements into technical and operational characteristics. Its best-known representation is the House of Quality, although QFD can be deployed through a sequence of linked matrices covering product design, component design, process planning, and production control.

The first matrix generally contains customer requirements, often called the “Whats,” and design characteristics, or the “Hows.” The relationship section indicates how strongly each technical characteristic affects a customer requirement. The roof examines interactions among technical characteristics, identifying synergies and conflicts. Competitive assessment compares the organization’s offering with alternatives. Importance ratings and strategic priorities help determine where design attention should be concentrated.

For example, a hospital appointment service may receive the customer requirement “easy to obtain an appointment.” Relevant technical characteristics might include number of steps, average waiting time, availability of appointment slots, clarity of confirmation messages, and accessibility compliance. Increasing security authentication may improve privacy but add steps, creating a design conflict that must be consciously managed rather than ignored.

QFD is not merely a scoring exercise. It is a cross-functional dialogue and traceability mechanism. It makes visible the chain from customer language to measurable design decisions. Its weaknesses arise when customer categories are assumed rather than researched, weights are manipulated to support a predetermined solution, or the matrix becomes so elaborate that participants stop discussing the underlying meaning.

Anticipating Failure: FMEA and Related Risk Methods

Failure Mode and Effects Analysis (FMEA) is a structured method for identifying how a design or process might fail, what effects those failures could produce, why they might occur, and how they can be prevented or detected. Design FMEA focuses on product or system design; Process FMEA focuses on manufacturing or service-delivery processes. Software, healthcare, and service applications may adapt the method to suit their failure mechanisms.

A conventional FMEA records the failure mode, effect, cause, existing controls, and ratings for severity, occurrence, and detection. Historically, organizations multiplied these ratings to produce a Risk Priority Number. That calculation is convenient but limited: ordinal ratings are not naturally multiplicative, and two risks with the same number may have very different consequences. Contemporary practice therefore emphasizes action priority, severity-based escalation, explicit prevention controls, and documented rationale rather than relying mechanically on a single product score.

Effective FMEA is preventive. “Operator error” is not a sufficient root cause; the team should ask what feature, interface, training condition, workload, or process weakness permits the error. Actions should favor elimination or reduction of the cause, followed by robust detection and recovery. High-severity risks require special governance even when their estimated occurrence is low.

Fault-tree analysis works in the opposite direction from FMEA. It begins with an undesirable top event and logically decomposes combinations of failures that could produce it. Event-tree analysis begins with an initiating event and examines possible consequences under different response conditions. These methods are particularly valuable for safety-critical systems and complex interfaces.

Reliability as a Design Requirement

Reliability is the probability that an item performs its required function for a specified time under stated conditions. The definition is important because reliability has meaning only when function, duration, environment, and failure criteria are specified. “Reliable” is not an adequate engineering requirement.

For a constant failure rate, an exponential model is sometimes used: R(t) = e^(-λt), where λ is the failure rate and t is time. This model is not universally appropriate. Mechanical products may exhibit infant mortality, useful-life failures, and wear-out failures, often represented more flexibly by the Weibull distribution. Series systems fail when any critical component fails, whereas parallel redundancy can maintain function when at least one component remains operational. However, redundancy may introduce common-cause failures, maintenance complexity, or hidden dependencies.

Reliability allocation distributes a system-level reliability target among subsystems. Accelerated life testing subjects an item to increased stress to obtain information more quickly, but extrapolation must be supported by a credible physical failure model. Reliability growth testing uses successive design improvements to reduce failures during development. Maintainability, availability, serviceability, and safety should be considered with reliability because customers experience the total service system rather than an isolated component.

Tolerance Design and Capability

A nominal design specifies target values; tolerance design specifies acceptable variation around those targets. Tightening every tolerance may improve conformance but increase material, machining, inspection, and assembly cost. A sound design uses the least restrictive tolerances that still protect function, safety, customer value, and downstream process capability.

Tolerance analysis may use worst-case, statistical, or simulation-based approaches. Worst-case analysis assumes all dimensions simultaneously reach their limiting values and is conservative. Statistical tolerance analysis considers distributions and independence assumptions, but it must not be used casually when dimensions are correlated or when failure is governed by an extreme combination. Monte Carlo simulation is useful for nonlinear systems and complex distributions, provided that input assumptions are credible.

Tolerance allocation should consider process capability. A specification may appear reasonable but be unrealistic for the intended supplier or production process. Conversely, a highly capable process may permit a less expensive design tolerance. Capability indices such as Cp and Cpk summarize the relationship between process variation, centering, and specification limits, but they are meaningful only when the process is stable and the measurement system is adequate. Capability is therefore a design–process interaction, not a property of the drawing alone.

Robust Design and the Reduction of Sensitivity

Robust design seeks a product or process whose performance is relatively insensitive to noise factors. Control factors are variables the designer can set, such as material, geometry, algorithm, temperature setting, or assembly sequence. Noise factors are sources of variation that are difficult or expensive to control, such as ambient temperature, user behavior, component aging, supply variation, or vibration.

The Taguchi perspective distinguishes nominal-the-best, smaller-the-better, and larger-the-better quality characteristics. Signal-to-noise ratios provide a way to evaluate both average performance and variation, although the selected formulation must match the quality objective. Orthogonal arrays can reduce the number of experimental runs needed to study several factors. The method is most powerful when it is connected to physical understanding rather than treated as an automatic table-selection exercise.

Robust parameter design typically follows three steps. First, identify performance measures and noise conditions. Second, use designed experiments or simulation to identify control-factor settings that reduce sensitivity. Third, adjust tolerances and center the design so that the output remains within customer and regulatory requirements.

Consider a temperature-control device whose output varies with room temperature. Increasing component precision may reduce variation, but a design change that reduces temperature sensitivity may achieve greater robustness at lower life-cycle cost. This is the essential insight: prevent variation through design before attempting to control every source of variation in production.

Designing Experiments for DFSS

Design of experiments (DOE) provides a disciplined way to learn how inputs affect outputs. Screening designs identify influential factors; factorial designs reveal main effects and interactions; response-surface methods support optimization; and mixture designs apply when inputs are proportions that must sum to a constant.

A DFSS experiment should begin with a clear response definition, factor ranges that are technically and ethically acceptable, a randomization strategy, replication or repeated measurements where appropriate, and a plan for analyzing interactions. Blocking can control known nuisance variation. Center points may help detect curvature. Statistical significance should not replace engineering significance: a small effect may be statistically detectable but economically irrelevant, while a practically important effect may require improved measurement precision.

Confirmation runs are essential. An optimized model must be tested at the proposed settings, preferably under realistic noise conditions. Overfitting, uncontrolled factor changes, inadequate randomization, and using a narrow laboratory range are common reasons why experimental gains fail during transfer.

An Integrated Applied Case: Robust Design of a Remote Patient-Monitoring Service

Background

The following is an illustrative case. A healthcare technology organization plans a remote patient-monitoring service for adults with chronic conditions. The service combines a wearable sensor, a mobile application, clinical alerts, and a support centre. The strategic objective is to improve timely intervention without creating excessive false alarms or user burden.

Situation and Problem

Existing pilot users report that device setup is confusing, alerts are sometimes delayed, and battery life varies substantially. Clinicians complain that too many low-value alerts obscure urgent cases. Management initially proposes a more powerful sensor, but the project team recognizes that the problem involves the entire service design.

Analysis

In the Define phase, the team identifies patients, caregivers, clinicians, support staff, regulators, and data-security personnel as stakeholders. CTQs include correct measurement, alert timeliness, understandable instructions, battery duration, accessibility, privacy, and low false-alarm burden.

During Measure, interviews and observation reveal that users have different levels of digital literacy. Field data show that battery drain increases when wireless connectivity is weak. A QFD matrix links “trustworthy alerts” to measurement accuracy, transmission reliability, alert rules, and clinician response time. Design FMEA identifies incorrect sensor placement, missed transmission, confusing messages, unauthorized access, and alert fatigue as important failure modes. A fault tree for “urgent event not acted upon” shows that sensor error, communication failure, software filtering, and delayed clinical response can combine to produce the top event.

Approach and Solution

The team develops three service concepts and evaluates them against customer value, clinical risk, feasibility, cost, and privacy. It selects a design with guided setup, a local data buffer, adaptive transmission, explicit escalation rules, and a clinician dashboard that groups related alerts.

A DOE examines control factors such as sampling frequency, transmission retry policy, alert threshold, message format, and battery-management mode under noise factors including weak connectivity, varying user movement, and temperature. The chosen settings reduce sensitivity to connectivity variation without simply increasing transmission power. Usability tests lead to larger visual prompts and a confirmation step that detects incorrect sensor placement.

Tolerance and capability work is applied to sensor accuracy, battery capacity, and software response time. Supplier agreements specify critical characteristics and verification evidence. Pilot verification uses simulated connectivity failures and controlled clinical scenarios, while validation involves representative users in their normal environments. The team also establishes post-launch monitoring for missed alerts, false alarms, privacy incidents, and usability complaints.

Outcome

The final design is not judged solely by sensor accuracy. It is evaluated as a socio-technical system whose performance depends on hardware, software, users, clinicians, suppliers, and communication infrastructure. The project demonstrates that robust design can reduce dependence on perfect user behavior and ideal network conditions. It also shows that a technically sophisticated feature may reduce overall quality if it increases confusion or clinical workload.

Learning Points

The case illustrates five principles: customer requirements must be operationalized; risk analysis should include service interfaces; reliability includes the complete delivery system; robust design addresses noise factors rather than merely tightening specifications; and verification must be complemented by validation in realistic use.

Managerial, Ethical, and Governance Considerations

DFSS changes organizational decision-making because it requires investment before revenue or production output is visible. Senior managers must protect early design work from premature schedule compression while demanding evidence-based reviews. Cross-functional teams need clear decision rights, escalation routes, and configuration control. Supplier involvement should occur early enough to influence design, not merely after specifications are frozen.

Ethically, customer research must respect informed consent, privacy, accessibility, and the interests of vulnerable users. Safety-critical requirements should not be traded against cost through informal scoring. Data used to train predictive models or optimize service rules must be representative and governed appropriately. A design that performs well for the average customer may disadvantage people with disabilities, limited connectivity, language differences, or low digital access.

Regulated industries require traceability from requirement to test evidence and change history. Design records should show why decisions were made, what assumptions were used, and how unresolved risks were handled. Professional responsibility includes communicating uncertainty honestly rather than presenting a favorable prototype result as proof of field reliability.

Digital Tools, Analytics, and Emerging Developments

Digital engineering supports DFSS through computer-aided design, finite-element analysis, digital twins, simulation, requirements-management systems, configuration control, and automated test environments. Data analytics can identify failure patterns from warranty, service, sensor, and complaint data. Machine learning may support anomaly detection or reliability prediction, but its outputs require domain validation, data-quality assessment, explainability appropriate to the risk, and monitoring for model drift.

Model-based systems engineering increasingly links requirements, architecture, interfaces, simulation, verification, and change impact. Additive manufacturing enables rapid prototyping and geometries that may improve performance, but it introduces new material, process, inspection, and reliability questions. Connected products allow post-launch learning, yet they also create cybersecurity, privacy, update, and dependency risks. Robust design in digital systems must therefore include uncertain data, network conditions, software updates, human interaction, and cyber threats as potential noise factors.

Common Failure Patterns and Best Practices

DFSS initiatives often underperform when teams confuse customer requests with validated needs, select a solution before analysis, treat QFD as a paperwork requirement, use FMEA only to assign scores, optimize a single response while damaging another, or verify prototypes under ideal conditions. Other mistakes include ignoring measurement-system error, assuming statistical significance proves business value, transferring an experimental setting without process capability evidence, and closing risks without objective evidence.

Effective practice includes:

• defining measurable CTQs and linking them to customer outcomes;
• involving operations, suppliers, service personnel, compliance specialists, and users early;
• combining QFD, FMEA, reliability analysis, DOE, tolerance analysis, and capability studies;
• prioritizing prevention and robust architecture over inspection;
• documenting assumptions, trade-offs, and residual risks;
• testing under realistic environmental, human, and supply conditions;
• using independent review for high-severity or regulated risks; and
• maintaining post-launch feedback so that design knowledge improves future projects.

Chapter Summary

Design for Six Sigma applies Six Sigma thinking before a product, service, or process enters routine operation. DMADV provides a structured path from project definition and customer measurement through concept analysis, detailed design, and verification. QFD translates the voice of the customer into technical priorities, while FMEA, fault-tree analysis, and reliability methods anticipate failure and support preventive decisions. Tolerance design links specifications to variation and process capability. Robust design reduces sensitivity to noise factors through sound architecture, parameter selection, and designed experimentation. Together, these methods help organizations create offerings that are capable, reliable, usable, safe, and economically sustainable. Their effective use requires cross-functional governance, ethical attention to affected users, realistic validation, and disciplined use of digital evidence.

Key Terms

DMADV: A DFSS framework consisting of Define, Measure, Analyze, Design, and Verify.

Design for Six Sigma (DFSS): A methodology for designing new or substantially redesigned offerings to meet customer and performance requirements.

Critical-to-Quality characteristic (CTQ): A measurable characteristic that has a significant effect on customer satisfaction or compliance.

Quality Function Deployment (QFD): A structured method for translating customer requirements into technical and operational specifications.

House of Quality: The principal matrix used in the first stage of QFD.

Design FMEA: A systematic analysis of potential product or system failure modes and their effects.

Process FMEA: A systematic analysis of potential process failure modes, causes, effects, and controls.

Fault-tree analysis: A deductive method that decomposes an undesirable top event into combinations of contributing failures.

Reliability: The probability that an item performs its required function for a specified time under stated conditions.

Failure rate: The rate at which failures occur under specified conditions, often represented by λ.

Reliability allocation: The distribution of a system reliability target among subsystems or components.

Tolerance: The permissible variation around a specified nominal value.

Capability: The extent to which a stable process can meet specification requirements.

Robust design: Design that reduces performance sensitivity to uncontrollable or difficult-to-control variation.

Control factor: A design or process variable that can be deliberately set by the organization.

Noise factor: A source of variation that is difficult or uneconomic to control directly.

Design of experiments (DOE): A planned method for studying the effects of multiple factors on one or more responses.

Verification: Evidence that a design meets specified requirements.

Validation: Evidence that the design fulfills intended user needs in its actual or representative environment.

Signal-to-noise ratio: A performance measure used in robust design to evaluate output level and variation together.

Review Questions

Short Answer Questions

1. What is the principal difference between DMAIC and DMADV?

2. Define a critical-to-quality characteristic and give one example.

3. What is the purpose of the relationship matrix in QFD?

4. Distinguish design FMEA from process FMEA.

5. Why are noise factors important in robust design?

Long Answer Questions

1. Explain each phase of DMADV and discuss the evidence expected at each stage.

2. Describe how QFD, FMEA, and reliability analysis can be integrated in a new-product project.

3. Explain tolerance design and its relationship with process capability and cost.

4. Discuss the assumptions, uses, and limitations of Taguchi-inspired robust design.

5. Compare verification and validation, using a product or service example.

Analytical / Application Questions

1. A new online banking service receives complaints about security, excessive login steps, and delayed transaction alerts. Develop a preliminary QFD logic and identify at least four CTQs and two likely design conflicts.

2. A manufacturer has a high-severity failure mode with low occurrence but weak detection controls. Explain how the team should prioritize and address it without relying solely on a Risk Priority Number.

3. Design an outline DFSS plan for a medical device or public-service process. Specify the noise factors, proposed DOE or validation activities, reliability concerns, and criteria for design transfer.

22. Multiple Choice Questions with Answers

Question 1

Which situation most strongly supports the use of DMADV rather than DMAIC?

A. A stable production line has excessive scrap with reliable historical data

B. A new service is being designed for a market with fundamentally different requirements

C. A control chart shows a temporary special-cause variation

D. An existing process needs routine monitoring after improvement

Correct Answer: B. A new service is being designed for a market with fundamentally different requirements

Question 2

In QFD, the primary purpose of translating customer statements into measurable technical characteristics is to

A. eliminate the need for customer research

B. ensure that every technical feature receives equal investment

C. create traceability between customer value and design decisions

D. replace verification testing with a scoring matrix

Correct Answer: C. create traceability between customer value and design decisions

Question 3

Which statement best describes robust design?

A. It eliminates every source of variation through tighter inspection

B. It makes performance less sensitive to difficult-to-control noise factors

C. It maximizes the number of product features

D. It uses only worst-case tolerance analysis

Correct Answer: B. It makes performance less sensitive to difficult-to-control noise factors

Question 4

A conventional FMEA Risk Priority Number is limited because

A. failure effects cannot be documented

B. ordinal ratings are not naturally multiplicative and may hide severity differences

C. it applies only to financial risks

D. it prevents teams from identifying causes

Correct Answer: B. ordinal ratings are not naturally multiplicative and may hide severity differences

Question 5

What is the main difference between verification and validation?

A. Verification concerns cost, whereas validation concerns staffing

B. Verification tests specifications, whereas validation tests intended use and user needs

C. Verification occurs after launch, whereas validation occurs before design

D. Verification applies to services, whereas validation applies only to products

Correct Answer: B. Verification tests specifications, whereas validation tests intended use and user needs

Question 6

A designer tightens every component tolerance without studying function or process capability. The most likely consequence is

A. guaranteed improvement in customer value

B. lower inspection cost and greater flexibility

C. higher cost without necessarily achieving the best system performance

D. elimination of all common-cause variation

Correct Answer: C. higher cost without necessarily achieving the best system performance

Question 7

Which method begins with an undesirable top event and logically decomposes combinations of causes?

A. Fault-tree analysis

B. House of Quality

C. Conjoint analysis

D. Response-surface methodology

Correct Answer: A. Fault-tree analysis

Question 8

In a robust-design experiment, weak network connectivity that cannot be economically controlled would be classified as a

A. control factor

B. nominal response

C. noise factor

D. specification limit

Correct Answer: C. noise factor

Question 9

Why are confirmation runs important after a DOE-based optimization?

A. They replace the need to define responses

B. They test whether the proposed settings perform as predicted under relevant conditions

C. They guarantee statistical significance for every factor

D. They remove the need for process capability studies

Correct Answer: B. They test whether the proposed settings perform as predicted under relevant conditions

Question 10

Which action best reflects preventive DFSS practice?

A. Increasing final inspection after a recurring field failure

B. Removing the physical or design cause of the failure before production launch

C. Changing the FMEA score without changing the design

D. Accepting a high-severity risk because its occurrence is low

Correct Answer: B. Removing the physical or design cause of the failure before production launch