DMADV: The 5 Phases of Design for Six Sigma

DMADV (Define, Measure, Analyze, Design, Verify) is the Six Sigma framework for creating something new from scratch at near-perfect quality, rather than patching what already exists. Where most improvement tools start with a broken process and try to fix it, DMADV starts with a blank sheet and designs quality in from the beginning. Teams use it when they're launching a new product line, building a new service delivery process, or replacing a process so fundamentally flawed that incremental fixes won't cut it.

The method belongs to a broader family called Design for Six Sigma (DFSS). If you've used DMAIC before, the logic will feel familiar but the direction is different. DMAIC improves. DMADV designs.

What Is DMADV?

DMADV is a structured, data-driven methodology for designing new processes and products to meet customer requirements at Six Sigma quality levels. The name is an acronym for its five sequential phases: Define, Measure, Analyze, Design, and Verify.

The core idea is simple: instead of discovering defects after launch and scrambling to fix them, you understand exactly what customers need before you build anything. You then design the process or product around those needs, test it rigorously, and only then release it into the real world.

Design for Six Sigma (DFSS) is the umbrella term for a family of methodologies that includes DMADV. Other DFSS variants exist (IDOV, DMADOV, ICOV), but DMADV is the most widely adopted, partly because its five-letter structure mirrors the familiar DMAIC framework that most Six Sigma practitioners already know.

Key Facts

• Six Sigma targets a defect rate of just 3.4 defects per million opportunities (DPMO), representing 99.99966% accuracy. (Source: American Society for Quality)
• Six Sigma was pioneered at Motorola in 1986 by engineer Bill Smith and formally named by Mikel Harry. It became an industry standard after General Electric adopted it company-wide in the mid-1990s. (Source: Motorola Solutions / ASQ)
• The DFSS family (which includes DMADV) is distinct from the DMAIC family: DFSS applies when a product or process does not yet exist, or when the existing one is so far from target that redesign is the only viable path. (Source: iSixSigma)

DMADV vs DMAIC

This is the question teams ask most often, and it's worth being precise about it. Both are Six Sigma methodologies. Both are data-driven. Both follow a five-phase structure. But they solve fundamentally different problems.

A simple heuristic: if you're staring at a process that already exists and is mostly working, use DMAIC. If you're staring at a whiteboard, use DMADV.

There's also a useful middle case. Sometimes a process exists but is so broken that no amount of improvement will get it to Six Sigma quality. That's when teams switch from DMAIC to DMADV mid-project. The decision point usually comes at the end of the Analyze phase in a DMAIC project, when the data shows that redesign is the only realistic path forward.

The 5 Phases of DMADV

1. Define

The Define phase sets the scope, purpose, and success criteria for the entire project. Teams use it to answer three questions: What are we building? Who is it for? And how will we know we've succeeded?

Key activities in Define include writing a project charter (the one-page document that captures scope, timeline, team, and business case), identifying stakeholders, and mapping the critical-to-quality (CTQ) requirements at a high level. The CTQ tree is a particularly useful tool here: it connects broad business goals (reduce customer complaints) to specific, measurable requirements (response time under 4 hours, 99% first-contact resolution).

A well-run Define phase saves enormous time later. If the team doesn't agree on what "success" means before designing, they'll argue about it after the product is built.

Tools used: Project charter, stakeholder analysis, voice of the customer (VOC) interviews, CTQ tree.

2. Measure

In Measure, the team quantifies exactly what customers need. The goal is to translate customer language ("I want it to be fast") into measurable specifications ("order processing time not to exceed 24 hours for 99.7% of orders").

This phase involves structured customer research: surveys, interviews, focus groups, and analysis of complaint data. Teams often use Quality Function Deployment (QFD), also called the House of Quality, to map customer requirements against potential design features and rank them by importance.

The Measure phase also establishes the baseline: what does the current state look like, if anything comparable exists? This gives the team a reference point when they evaluate design options later.

Tools used: Voice of the customer (VOC), Quality Function Deployment (QFD), benchmarking, measurement system analysis (MSA).

3. Analyze

Analyze is where the team explores the solution space before committing to any single design. Rather than jumping straight from customer requirements to a design, teams examine multiple potential approaches, assess trade-offs, and select the best path forward.

This phase uses techniques like Design of Experiments (DOE) to model how different design variables interact, and risk analysis tools like FMEA (Failure Mode and Effects Analysis) to identify where a design might fail before it's built. Teams also benchmark competitors and analogous processes to understand what "excellent" looks like in comparable contexts.

The Analyze phase ends with a documented decision: here is the design concept we're moving forward with, and here is the data supporting that choice.

Tools used: FMEA, Design of Experiments (DOE), benchmarking, design concept evaluation, risk assessment.

4. Design

Design is the hands-on build phase. The team takes the chosen concept and works out every detail: workflows, system architectures, staffing models, training requirements, technology specifications, and control mechanisms.

The key discipline in Design is prototyping early and often. Pilot tests, simulations, and small-scale trials let teams catch problems while changes are cheap. A new customer onboarding process, for example, might be tested with a single cohort of 20 customers before rolling out to thousands.

This phase also involves detailed documentation: standard operating procedures, control plans, training materials, and the measurement systems that will track performance after launch.

Tools used: Detailed process maps, value stream mapping, simulation, pilot testing, prototype development, control plan design.

5. Verify

Verify is the final gate before full deployment. The team validates that the new design actually meets the customer requirements established back in Define and Measure. This isn't a one-time test: it's a systematic validation across realistic conditions.

Verification typically includes a pilot launch (a controlled rollout to a real but limited set of customers or operations), statistical validation that the process performs at or near the Six Sigma target, and a transition plan for handing off the process to the operational team who will run it day-to-day.

If Verify reveals gaps between the design's actual performance and the requirements, the team cycles back to Design (and sometimes to Analyze) to address them. Verify only closes when the data confirms the design is ready.

Tools used: Pilot studies, capability analysis, acceptance testing, transition planning, control plan handoff.

When to Use DMADV

DMADV is the right choice in four situations:

1. You're building something entirely new. A new product line, a new service offering, a new market entry. There's no existing process to improve because the process doesn't exist yet.

2. The existing process is too far gone. Sometimes DMAIC analysis reveals that an existing process is so structurally flawed that fixing it would cost more than designing a replacement. When the data shows this, switching to DMADV is the rational move.

3. Customer requirements have shifted fundamentally. A process designed for a different customer base, a different technology environment, or a different scale may simply not be salvageable. If requirements have changed by 40% or more, redesign often beats incremental improvement.

4. You're replacing a process to meet new regulatory or quality standards. If new compliance requirements mandate capabilities the existing process can't deliver, DMADV gives you a clean path to building the compliant version from scratch.

What DMADV is not suited for: fixing a process that's mostly working but has a specific, identifiable defect. That's DMAIC territory, or sometimes Total Quality Management continuous improvement cycles.

Benefits of DMADV

Quality designed in, not inspected in. Traditional product development catches defects after launch. DMADV catches them before the first customer ever sees the product, because requirements are validated before design begins.

Lower total cost. The cost of fixing a defect escalates dramatically through the development lifecycle. A flaw caught in the Analyze phase costs a fraction of a flaw caught after full deployment. DMADV's upfront investment in requirements and prototyping almost always pays back.

Customer alignment. Because the Measure phase systematically captures what customers actually need (not what the team assumes they need), designs produced by DMADV tend to land better with real users.

Clear accountability. The structured five-phase gate system means every team member knows what decisions belong in which phase. This reduces the "design by committee" drift that derails many new product launches.

Scalable. DMADV works at every scale, from designing a single internal workflow to launching a global product line.

Common Mistakes

Starting in Design. Teams that skip Define and Measure and jump straight to designing are guessing at what customers need. Guesses produce rework.

Treating Verify as a checkbox. Verify isn't a sign-off meeting. It's statistical validation under real conditions. Teams that rush Verify often discover post-launch that their design performs fine in testing but falls apart at scale.

Confusing DMADV with DMAIC. Starting a DMAIC project on a process that should be redesigned wastes months. The decision point is early: if the existing process is irreparably broken, switch frameworks before investing in improvement work.

Neglecting the control plan. DMADV produces a design, but someone has to run that design for years. A weak handoff to operations means the new process drifts back toward the defects it was designed to avoid. The control plan and training materials matter as much as the design itself.

Skipping FMEA in Analyze. Risk analysis in the Analyze phase is where teams find the catastrophic failure modes before the product is built. Teams that skip FMEA or treat it superficially discover those failure modes in production instead.

DMADV Example: Designing a New Client Onboarding Process

A B2B software company has acquired 3x its normal volume of new clients through a major partnership deal. Its current onboarding process was built for 20 new clients a month. It now needs to handle 60, and client satisfaction scores for recent onboardees have already dropped 22 points. The team determines the existing process can't be scaled without fundamental redesign. They launch a DMADV project.

The redesigned process handled the volume and hit every CTQ target. Critically, none of the three critical failure modes identified in FMEA during Analyze appeared during the pilot, because the design had already addressed them.

Frequently Asked Questions

What does DMADV stand for?

DMADV stands for Define, Measure, Analyze, Design, and Verify. Each word is one of the five sequential phases of the methodology.

Is DMADV part of Six Sigma or Lean?

DMADV is a Six Sigma methodology, specifically part of the Design for Six Sigma (DFSS) family. It's separate from Lean, though teams sometimes combine Lean principles with DMADV when designing processes. It's also distinct from the Lean-focused DMAIC methodology, though both share the first three phases' names.

Can a small team use DMADV, or is it only for large enterprises?

DMADV scales down well. A team of three or four can run a condensed DMADV project on a new internal workflow in six to eight weeks. The rigor of each phase scales with project complexity. What doesn't scale down is the data discipline: you still need to measure customer requirements and validate your design against them, even on a small project.

How long does a DMADV project take?

Timelines vary with scope, but most DMADV projects run three to nine months. Define and Measure together typically take four to eight weeks. Analyze and Design take the bulk of time (eight to sixteen weeks combined), and Verify runs four to eight weeks including the pilot. Complex product designs or large-scale process redesigns can run longer.

What certifications relate to DMADV?

DMADV is covered under the standard Six Sigma certification track. Green Belt certification introduces the framework; Black Belt certification trains practitioners to lead DMADV projects. Some organizations offer specific DFSS certifications. The American Society for Quality (ASQ) and IASSC are the most recognized certifying bodies.

---

When you're designing something that doesn't exist yet, or replacing something too broken to fix, DMADV gives you a structured path from customer need to validated design. The five phases force the right conversations at the right time: what do customers actually need (Define and Measure), what are the best ways to meet those needs (Analyze), how do we build it (Design), and does it actually work (Verify).

For teams already running DMAIC improvement cycles, DMADV is the natural complement: one framework for improving what exists, one for designing what doesn't. The practitioners who lead these projects earn their credentials through the Six Sigma belt system, and they validate a finished design against quality targets like DPMO and sigma level. Together with tools like value stream mapping, FMEA, and Total Quality Management practices, DMADV fits into a complete quality management system oriented toward getting things right the first time.