Originally published in Dr. Eric Maass's Predictive Engineering Newsletter (Design for Six Sigma and Supply Chain Resilience). Dr. Maass is Six Sigma BELT Guru's Master Black Belt certifying partner. Republished with credit.

This edition is about sequence. When I develop a DFSS Green Belt program, it is very often customized. I first try to get a general understanding of the business, the products and the challenges. Certain tools are most useful for certain challenges, and the sequence of the tools often makes as much a difference as the tools themselves. An article in MD+DI this week makes a similar case for the final phases of DFSS in medical devices.

The anchor: The DFSS (Predictive Engineering) Flowchart

DFSS Predictive Engineering flowchart from charter and VOC through requirements flow-down, transfer functions, optimization and verification

When I assemble a proposed DFSS Green Belt program, I use this DFSS Flowchart as a starting point, with the predictive engineering tools and methods in a specific order, but with some flexibility. Some tools and methods build on what comes before; if used too early, some tools and methods can give the team an inflated sense of confidence.

Product development starts with the Voice of the Customer, and "Customer" includes stakeholders: the business executives, the regulatory agencies, and the people who will be affected by the product and who will affect product acceptance. The expectations of these stakeholders are gathered, compiled and prioritized, then translated into measurable requirements. Requirement flow-down carries those requirements from system to subsystem to component; the P-Diagram can help identify the control factors, the noise factors, intended results and the error states.

A key P-diagram insight: if the development team controlled everything, if there were no noise factors, nothing outside their control, they would always achieve the intended results. So if there are things that go wrong or not according to plans, those failures are necessarily due to the noise factors. Robust design means identifying those noise factors, and designing the product or process to be virtually immune to them.

After the team has translated the expectations of the customers into measurable requirements, the team must trust those measurements. Measurement System Analysis tells you how much you can trust your measurement system.

Next come methods and tools to have a robust design: a design you can trust will meet or exceed customer expectations regardless of noise factors outside of your control. Predictive Engineering combines engineering modeling with probabilistic thinking. If the team already has an engineering model they can trust, they can use Monte Carlo simulation and/or variance transmission to predict the distributions for the measurable requirements by showing how variability in the inputs drives variability in the outcomes. I share six ways to reduce the vulnerability to variability and build confidence in successful outcomes. Similar probabilistic modeling applies to the five key manufacturing metrics: yield, cycle time, on-time delivery, throughput and cost.

If the development team does not already have engineering models they can trust, Design of Experiments (DOE) can identify which factors significantly affect the outcomes, and can provide regression equations relating the factors to the measurable requirement outcomes. Combining the regression equations from DOE (or its more advanced version, Response Surface Methodology, RSM) with probabilistic methods is a very impressive and remarkably effective predictive engineering approach. If a requirement is Pass/Fail, Logistic Regression provides a way to optimize the probability of success, such as passing an inspection or test. Multiple Response Optimization builds on DOE and RSM, allowing the team to co-optimize multiple requirements that are affected by some of the same factors.

Design for Reliability and Availability carries the question forward in time, to the probability that a product will continue meeting requirements over time and usage.

In some cases, the company's challenges involve qualitative expectations or other complications that can be addressed using Bayesian Belief Networks, which probabilistically model how both quantitative and qualitative factors influence outcomes. BBNs were the original artificial intelligence.

DFSS candidates learn by doing, by applying these tools and methods to a real challenge, from VOC interviews and requirement flow-downs to using tools and methods that provide impressive results.

— Eric Maass

From the field: Verify, Validate, and Transfer Are Three Separate Jobs

Infographic comparing DFSS, DMADV and DMAIC and stating Verify is not Validate, Validate is not Transfer, and a DFSS tollgate is not a Design Review

In a new MD+DI article, Khalid S. Mekki, PhD, a DFSS Master Black Belt whose career runs from reliability engineering at Ford to DFSS deployment at Baxter Healthcare and MedImmune/AstraZeneca, argues that medical device programs too often fold design verification, design validation and IQ/OQ/PQ into a single DFSS "Verify" box.

His answer is a seven-phase spine: Define, Measure, Analyze, Design, Verify, Validate, Transfer. Validate asks whether the device meets user needs in actual or simulated use, while Transfer covers design transfer, process validation and production readiness. Each user need is traced through CTQs and design outputs to the specific method that will verify or validate it.

Why it matters: the phases follow the same logic as the tools in this week's Anchor. When verification is asked to stand in for validation or transfer, the gaps tend to surface late, in tooling, labeling or the field. Read the full article

Links worth bookmarking

© Proprein Labs 2026. Learn more at 6sigmaexperts.com or connect with Eric Maass on LinkedIn.