{"id":75,"date":"2026-08-30T17:42:05","date_gmt":"2026-08-30T22:42:05","guid":{"rendered":"https:\/\/www.windyhillpartners.net\/?p=9004"},"modified":"2026-10-12T17:10:57","modified_gmt":"2026-10-12T21:10:57","slug":"dmaic-vs-dmadv","status":"publish","type":"post","link":"https:\/\/www.windyhillpartners.net\/blog\/lean-six-sigma\/dmaic-vs-dmadv\/","title":{"rendered":"DMAIC vs. DMADV: One Question Decides Which You Need"},"content":{"rendered":"

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

Does the process already exist?<\/strong><\/p><\/blockquote>\n

If yes \u2014 you improve it with DMAIC. If no \u2014 you design it with DMADV. Nearly everything else about the decision is commentary. Here’s the commentary that matters.<\/p>\n

DMAIC: fix what exists<\/h2>\n

DMAIC<\/strong> \u2014 Define, Measure, Analyze, Improve, Control \u2014 is the workhorse of Six Sigma project frameworks, built for processes that are running today but underperforming: too slow, too error-prone, too inconsistent.<\/p>\n

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

    DMADV: design what doesn’t exist<\/h2>\n

    DMADV<\/strong> \u2014 Define, Measure, Analyze, Design, Verify \u2014 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).<\/p>\n

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

    Side by side<\/h2>\n\n\n\n\n\n\n\n
     <\/th>\nDMAIC<\/th>\nDMADV<\/th>\n<\/tr>\n
    Use when<\/strong><\/td>\nProcess exists, underperforms<\/td>\nNo process exists (or beyond repair)<\/td>\n<\/tr>\n
    Data source<\/strong><\/td>\nCurrent process performance<\/td>\nCustomer needs and requirements<\/td>\n<\/tr>\n
    Last two steps<\/strong><\/td>\nImprove \u00b7 Control<\/td>\nDesign \u00b7 Verify<\/td>\n<\/tr>\n
    Typical trigger<\/strong><\/td>\nDefects, delays, rework, cost<\/td>\nNew offering, new regulation, greenfield build<\/td>\n<\/tr>\n
    Risk of choosing wrong<\/strong><\/td>\n“Improving” something that never existed<\/td>\nRedesigning what needed a root-cause fix<\/td>\n<\/tr>\n<\/table>\n

    When to use DMAIC \u2014 the practical test<\/h2>\n

    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 \u2014 the purpose itself has changed, or there’s nothing to measure \u2014 you’re in DMADV territory.<\/p>\n

    Choosing wrong is expensive in both directions. We’ve watched teams spend months “improving” a process that never actually existed as a process \u2014 just accumulated habits \u2014 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.<\/p>\n

    Same discipline underneath<\/h2>\n

    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<\/a> \u2014 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.<\/p>\n

    Frequently asked questions<\/h2>\n

    Can a project switch from DMAIC to DMADV midway?<\/h3>\n

    Yes, and it’s not failure \u2014 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.<\/p>\n

    When should I use DMAIC instead of just fixing the obvious problem?<\/h3>\n

    If the cause is genuinely known and proven, just fix it \u2014 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.<\/p>\n

    \n

    Pick the right first project<\/h2>\n

    The framework matters less than choosing a project worth doing. Our free First Win Selector ranks up to five candidates on impact, effort, data, sponsorship, and visibility \u2014 and recommends where to start.<\/p>\n

    Explore the Free Toolkit →<\/a><\/p>\n

    Prefer a conversation? Let’s talk<\/a> — 610-316-4056.<\/p>\n<\/div>\n