DMAIC vs. DMADV: One Question Decides Which You Need

Every Six Sigma conversation eventually arrives at the same fork: DMAIC or DMADV? Teams agonize over this choice, but after two decades of projects, we can tell you it comes down to one question:

Does the process already exist?

If yes — you improve it with DMAIC. If no — you design it with DMADV. Nearly everything else about the decision is commentary. Here’s the commentary that matters.

DMAIC: fix what exists

DMAIC — Define, Measure, Analyze, Improve, Control — is the workhorse of Six Sigma project frameworks, built for processes that are running today but underperforming: too slow, too error-prone, too inconsistent.

• Define the problem precisely, with scope and a business case — not “billing is a mess,” but “22% of invoices require rework, costing $X per year.”
• Measure what’s actually happening. Real data, not opinions. This step regularly demolishes the story everyone believed.
• Analyze to isolate root causes — what actually differs between the times it goes right and the times it goes wrong.
• Improve with changes proven by evidence, piloted before they’re scaled.
• Control so the fix survives: standard work, monitoring, response plans. The step most organizations skip — and the reason gains evaporate by month six.

DMADV: design what doesn’t exist

DMADV — Define, Measure, Analyze, Design, Verify — is for when there’s nothing to improve yet: a new product, a new service line, a process being built from scratch (or one so broken that incremental improvement is lipstick on rubble).

The first three letters rhyme with DMAIC, but the center of gravity shifts: you’re measuring customer requirements rather than current performance, analyzing design options rather than root causes, then Designing the process against those requirements and Verifying — through pilots and validation — that it performs before you scale it.

Side by side

	DMAIC	DMADV
Use when	Process exists, underperforms	No process exists (or beyond repair)
Data source	Current process performance	Customer needs and requirements
Last two steps	Improve · Control	Design · Verify
Typical trigger	Defects, delays, rework, cost	New offering, new regulation, greenfield build
Risk of choosing wrong	“Improving” something that never existed	Redesigning what needed a root-cause fix

When to use DMAIC — the practical test

Choose DMAIC when you can answer yes to three questions: Is the process running today? Can we measure its current performance? Would hitting a better version of its current purpose satisfy the customer? If any answer is no — the purpose itself has changed, or there’s nothing to measure — you’re in DMADV territory.

Choosing wrong is expensive in both directions. We’ve watched teams spend months “improving” a process that never actually existed as a process — just accumulated habits — when they should have designed one deliberately. And we’ve seen teams force a full redesign onto an operation that needed one stubborn root cause found and fixed.

Same discipline underneath

Both frameworks share Six Sigma’s real DNA: decisions from data, causes before solutions, and verification before victory laps. If you’re new to the method, start with our plain-English guide to what Lean Six Sigma is — and whichever roadmap you choose, scope your first project deliberately: our free First Win Selector ranks candidate projects on impact, effort, data, sponsorship, and visibility.

Frequently asked questions

Can a project switch from DMAIC to DMADV midway?

Yes, and it’s not failure — it’s discovery. Sometimes Measure and Analyze reveal that the current process can’t reach the goal no matter how it’s tuned. At that point the honest move is to reframe as a design project rather than continue polishing something structurally incapable.

When should I use DMAIC instead of just fixing the obvious problem?

If the cause is genuinely known and proven, just fix it — DMAIC isn’t ceremony for its own sake. Use the full framework when the problem is recurring, the cause is disputed, or previous ‘obvious fixes’ haven’t stuck. Recurring problems with obvious answers are usually neither.