Plain-language wisdom on Lean Six Sigma

Map DMADV onto a campaign the same way you’d map it onto a product: Define the CTQ as a number (cost per qualified lead, not “more awareness”), Measure the real baseline instead of assuming it, Analyze which levers actually move the number versus which ones just correlate, Design the funnel against that evidence, and Verify with a limited-spend pilot before the full budget commits.

The control-factor / noise-factor split carries over too. Creative, offer, targeting, and cadence are control factors — the team sets them. Seasonality, ad-platform algorithm changes, competitor moves, and sales-team follow-up capacity are noise — the market sets them. A campaign only ever tested under a good launch week has been verified at nominal, and that’s the same failure mode as a design that only ever gets tested at room temperature.

Download the full white paper (PDF)

A “Watch” status on a DV matrix is a diagnosis, not a fix. A normal DOE asks which control factors move the response. A robust parameter design DOE asks a sharper question: which control-factor setting makes the response stop caring about the noise?

• Put only the noise-sensitive control factors in the inner array — against an outer array built from the noise levels already defined in the P-Diagram and DV plan
• Look for the setting where the response stays flat across noise levels, not just the one that hits target at nominal
• Confirm the winning setting at the exact worst-case compound condition, then feed the result back into the DFMEA and verification plan

A “Watch” status is an instruction to run this experiment, not to retest and hope. Chasing the mean without measuring variance across noise just produces a design that passes today’s test and fails next year’s field conditions.

P-diagram helps in listing noise and control factors and becomes a bridge to a robust design verification Matrix.

• Control factors → your DV setup parameters (what you hold constant, what you deliberately vary to find the optimum)
• Noise factors → your DV stress conditions (what you must show robustness against, often via worst-case or combination testing)
• Ideal function / response → your DV pass/fail criteria

If a noise factor has no corresponding verification condition, that’s not a gap in your test plan — it’s a gap in your risk coverage. The P-Diagram doesn’t just explain how the system behaves; it tells you exactly what you still owe the design before you can trust it.

Download the full white paper (PDF)

Every noise factor you’ve mapped piece to piece variation, changes over time, customer usage, external environment, and systems interactions is a candidate stress condition for verification. Every control factor is a candidate lever you deliberately set and hold during that test. Together they define the envelope your design must survive, not just the inputs your design must accept.

The discipline is this: don’t let control factors quietly absorb what should be tested as noise.

1. Piece-to-piece variation
2. Changes over time/degradation
3. Customer usage/duty cycle
4. Environmental factors
5. System interactions

A failure mode with only single cause relationship hasn’t been fully analyzed, it is been partially analyzed. The real value of the P-Diagram isn’t the diagram itself, it is the forcing function it creates. It stops the team at each failure mode and asks, “have we checked all five sources, or did we stop at the first one that came to mind?” And that what is called MECHANISM OF FAILURE!

The habit to build: treat the five noise categories as a mandatory pass/fail checklist per failure mode not a menu to sample from. That is what turns a DFMEA from “what we’ve seen before” INTO “what could actually happen.”

A Design FMEA asks a deceptively simple question: how can this design fail? But “failure” only makes sense relative to an intended function. Without first mapping what the product is supposed to do, and everything acting on it while it does that, teams tend to brainstorm failure modes from memory and past experience alone. That approach reliably misses failure modes that haven’t happened yet which is exactly the population of risks a Design FMEA exists to catch.

The mistake I see most often: teams treat risk assessment like a checkbox. Run an FMEA once, file it, move on. Then they're surprised when the "fix" they roll out in Improve introduces a brand-new failure mode nobody caught.

Real risk management doesn't live in one phase. In Define, it's asking what could make this project fail before you've spent a dollar on it. In Measure, it's questioning whether your data collection itself is introducing bias or missing failure conditions. In Analyze, root cause and risk are the same conversation — every root cause you find is a risk source you haven't controlled yet. In Improve, the discipline is asking "what new risk does this fix introduce" before you roll it out, not after you've already broken something else. And in Control, risk management is the entire point — your control plan only works if it's built to catch the failure modes you already identified.

The tell I use: if your risk assessment is a document you produced once and filed away, it's compliance theater. If it's a question you're re-asking at every DMAIC gate, it's actually managing risk.

DMAIC (Define, Measure, Analyze, Improve, Control) is for fixing something that's already running. DMADV (Define, Measure, Analyze, Design, Verify) — the core of Design for Six Sigma — is for building something new, or for processes so far from capable that incremental fixes will never get you there.

Get that choice wrong, and here's what it actually costs: months spent optimizing a process that was never going to hit its target performance no matter how many DMAIC cycles you run — because you're refining a design flaw, not a process defect. Teams often end up paying twice: once for the failed improvement effort, then again when they finally admit they needed to design it right from the start.

The tell I look for: if you're asking "how do we make this better," you probably want DMAIC. If you're asking "does this need to exist in a different form entirely," you need DMADV.

A kitchen during a Friday dinner rush and a biologics production line have the same failure modes — unclear handoffs, no standard work, and everyone firefighting the same problem every week without ever asking why.

The tools scale up and down. The discipline of asking "why does this keep happening" doesn't change.