DMADV starts with the decision to redesign
Lean Six Sigma teams use DMADV to design a new process or replace one whose design prevents it from meeting requirements. ASQ distinguishes DMADV from DMAIC by assigning improvement of existing processes to DMAIC and new development or complete overhaul to DMADV. The phases listed on asq.org are Define, Measure, Analyze, Design, and Verify.
A sponsor reviewing a proposed DMAIC project needs to establish whether its scope allows the team to deliver the required performance. That depends on which constraints the team has authority to change. A charter that preserves every existing handoff and approval rule deserves scrutiny when those arrangements are themselves under investigation.
Capability evidence should precede the redesign decision
A poor process capability result establishes a performance gap; the case for redesign requires further evidence. NIST’s capability guidance compares stable process output with specification limits and identifies centering and variation reduction as possible responses to inadequate capability. The conventional capability indices described at itl.nist.gov also depend on distributional assumptions.
The DMAIC-to-DMADV review needs to separate evidence of underperformance from evidence of a design constraint. A team’s root cause analysis should identify what prevents the existing process from meeting the requirement. “Previous projects disappointed us” provides no basis for deciding which parts of the process need replacing.
| Evidence available | Proposed project decision |
|---|---|
| The performance gap is known; its causes remain uncertain | Continue diagnosis before committing to redesign. |
| Changes within the existing process offer a testable way to close the gap | Retain DMAIC and evaluate those changes. |
| The required process is absent, or meeting requirements requires a replacement design | Scope a DMADV project and define its acceptance criteria. |
At this review, the project charter should identify the unmet customer requirement and the evidence supporting the choice of method. For DMADV, the sponsor also needs to approve the limits of the team’s redesign authority, including which handoffs or approval rules it can change.
A manufacturing site needed a space-planning process
In Ó Longaigh and colleagues’ 2023 study of strategic facility planning, a manufacturing organization had operated a Lean Six Sigma program for more than 20 years. It lacked a robust strategic facility-planning process to improve, so the team selected DMADV to design one. The study, published on tandfonline.com, covers a single site in a highly regulated manufacturing environment.
The DMADV team used SIPOC to clarify an ad hoc process and stakeholder analysis to identify approval and communication needs. Their account on tandfonline.com describes a documented roadmap connecting the production build plan with the space-request process. The project addressed a gap in how an established site coordinated space decisions.
For a Lean Six Sigma team facing similar space constraints, the charter needs to distinguish between improving a local layout and designing a site-wide allocation process. Those projects give the team different authority over space decisions. Settling the scope before approving a facilities solution also gives the sponsor a basis for choosing between DMAIC and DMADV.
Build the DMADV evidence through five phase reviews
ASQ’s DMADV sequence begins with customer requirements and proceeds through concept selection and detailed design. Verification completes the sequence described on asq.org. In a Design for Six Sigma project, each phase review gives the sponsor a decision to make about the proposed process.
Define the boundary of the new process
In Define, the charter should specify the required outcome while leaving the team room to compare solutions. For the facility-planning problem, “design the space-allocation process” leaves that room. Naming a software platform in the objective commits the project to a solution and needs a separate justification. A SIPOC review helps the team and sponsor agree where the redesign begins and ends.
Measure: translate VOC into acceptance criteria
The Measure review should connect each voice-of-the-customer requirement to an operational definition and a proposed test. A requirements register records the metric and its acceptance threshold. It should also specify the evidence needed at Verify, so the sponsor and team agree in advance how the design will be judged.
Concept selection belongs in Analyze
Analyze gives the team a point at which to compare alternative process designs against the same requirements register, with unresolved assumptions stated for each proposal. For a space-planning DMADV project, I would compare who holds allocation authority under each design and how competing requests are resolved. These are proposed review questions; the case study does not report them as findings.
Design with failure modes in view
ASQ recommends starting FMEA during early conceptual design. Its guidance on asq.org calls for continuing the analysis through the process lifecycle. Within DMADV, the team therefore needs to conduct failure mode and effects analysis before final design approval. Unresolved failure modes should reach the Design review with named owners and planned tests.
Verify against the agreed requirements
ASQ defines Verify as confirming that design outputs meet customer requirements and specifications through testing and validation, as described in its DMADV guidance on asq.org. The sponsor should assess pilot testing against the acceptance criteria agreed in Measure.
DMADV handover should depend on an operating owner accepting the control plan. The handover review needs to assign responsibility for monitoring each critical requirement and specify the response to a failure. It also needs to identify unresolved issues that prevent release. A requirement still supported only by an assumption remains an open verification item.
Sources
- NIST/SEMATECH (undated online reference; accessed 2026), “What Is Process Capability?”: https://www.itl.nist.gov/div898/handbook/pmc/section1/pmc16.htm
