DMAIC and DFSS Roadmaps: How to Connect and Integrate?

The roadmap has always been an important part of Six Sigma. It lays out the thought process for teams and leaders, and distinguishes the methodology from a parade of tools. With the original “Six Steps to Six Sigma” and then “Define Measure Analyze Improve Control” (DMAIC) as the improvement roadmap, plus the addition of Design for Six Sigma (DFSS), practitioners have evolved and expanded their view of how the steps and tools fit together and deliver results.

To make things interesting, DFSS is a lot less standard around the world than DMAIC. Roadmaps like “Define Measure Analyze Design Verify” (DMADV), “Invent/Innovate Develop Optimize Verify” (I2DOV) and “Concept Design Optimize Verify (CDOV) are similar in spirit, but with differences in nuance and detail. Add to this the common desire to map in other initiatives, like Lean and Business Process Management, and it’s easy to see why companies sometimes think about rationalizing and perhaps simplifying their roadmap view.

While there are numerous coexistence and integration questions, a combined core DMAIC-DFSS roadmap is possible.

How to Deal with Two Roadmaps?

Many companies begin their Six Sigma work with DMAIC problem-solving and improvement. This makes sense as DMAIC brings rapid improvement to existing processes – quickly returning significant dollars to the bottom line. Because DMAIC projects often point to problem root causes in the design of products or processes, interest in DFSS often develops in connection with improvement work. Thus leaders may find themselves struggling to manage two Six Sigma approaches and roadmaps.

In a world where “innovate and design” are naturally separated from “improvement work,” two roadmaps may work just fine. In many real-world cases, though, design is often interwoven with existing products and processes, and improvement often means revisiting fundamental design. In those situations, the project teams, Belts and Champions can waste energy worrying, “Is this a DMAIC or DFSS project?”

The Appeal – and Challenge – in Integrating DMAIC and DFSS

When a company feels that too much time is being spent sweating out the distinctions between DMAIC and DFSS, it may move to integrate and simplify things. Experienced Six Sigma practitioners may notice that the thought processes have some parallels, especially in the Define and Control phases. While it is tempting, and even possible, to integrate the approaches in new and creative ways, it is best to use some common approaches with an eye toward caution. Integrating the roadmaps requires special attention to the subtle ways they are different.

(For the purposes of this article, the common DMADV map is used as the frame of reference for DFSS.)

“Everything Is DMAIC”

Perhaps because people are more familiar with DMAIC, they seek to use it as the foundation for integration, with DFSS seen as a special sidebar. At one extreme, companies move to integrate with the theme, “Everything Is DMAIC+/-.” They view the DFSS distinction in the scope and nature of the improvement or innovation work that happens between the Analyze and Control phases. An accompanying theme is often “D, M and A Are the Same for All Projects.” The thinking is that during Analyze, a team figures out whether improvement or design is called for and they pursue an I-phase that tracks with either DMAIC (improvement) or DFSS (innovation/design). As Figure 1 depicts, after that roadmap branch, the similarities between DMAIC’s Control phase and DFSS’s (DMADV) Verify phase often bring things back together for a common last stage.

Figure 1: DMAIC with a Branch to Integrate DFSS

Figure 1: DMAIC with a Branch to Integrate DFSS

Figure 2: Improvement and Design at Each Step

Figure 2: Improvement and Design at Each Step

Risks in Viewing “D, M and A” as Identical for All Projects

While the high-level thought process for D, M and A are parallel for DMAIC and DMADV, they are not at all the same in practice. The mindset of a team and the nature of its curiosity in data gathering and analysis are different through D, M and A for projects with DMAIC scope versus DFSS scope. DMAIC problem-solving calls for a “detective” orientation, looking for clues and focusing on specific root causes. Innovation/design calls for an “anthropologist” orientation, looking for how people do things (or could do things), clues about latent requirements and measures that identify performance drivers. While both of these orientations move through a “D, M and A” stage, they have a different scope and flavor. Figure 2 illustrates the view that every stage, not just the I-phase, sits against a backdrop that could be Improvement (DMAIC)- or Design/Innovation (DFSS)-oriented. While the names of the steps, and in many cases the tools, are the same for all projects, a team’s practical work is guided by a project’s location on the improve-innovate continuum.

Handpicked Content:   Reducing Delays in the Cardiac Cath Lab with Six Sigma: An iSixSigma Case Study

Aligning DMAIC and DFSS With Attention to the Distinctions

The table below depicts a simplified view of what happens if the DMAIC and DMADV thought processes are distilled to a high enough level that one map might be laid out. The “Practical Translation” columns show distinctions that would be important to a particular team, depending on whether its current project was DMAIC or DFSS (or somewhere in the middle). The intended takeaway from this view is that D, M and A are where many of the DMAIC and DFSS distinctions lie. While they can be overlaid, it is important for each project to understand as early as possible where it is on the DMAIC-DFSS continuum. Some projects start out “thinking they are DMAIC” only to find (somewhere in D, M, A or I) that they are really more DFSS – or vice versa. The table is a first step in guiding a team toward the correct “edge,” no matter where on the map the team was when the project’s nature became clear.


————————————————– Practical Translation —————————————————
(Improvement) (Design/Innovation)


Project Goals? 

Business Case? 



As-is Process? 

What Are Key

Removing or reducing a problem in an
existing process or work-product
(e.g. defects, delays)

Reducing costs of poor quality (e.g.
rework, scrap, waste) Returning savings
to the bottom line

Defined and bounded by the problem

Those involved in or impacted by the problem. Already familiar players

Studied to reveal: clues about the problem,
measurement points, and things not to
break in the course of improvement

“Must-be” and “satisfier” requirements –
to be sure the solution improves the primary
Y while maintaining or improving
performance across the board. The curiosity brought to VOC data-gathering
is that of a detective looking for what’s
important, but also clues about the problem,
its implications and its location(s).
Identifying and capitalizing on an opportunity
(i.e. a new or next-generation product or service)

Identifying and capitalizing on an opportunity
(i.e. a new or next-generation product or

Increasing business net value (sales,
profitability, market share). Bringing increased revenue to the top line

Defined by potential opportunity (Broad at
the outset)

Internal or external potential “markets”
connected with the opportunity. Could be
new players

Studied to reveal: compensatory behavior,
lead user “aha’s,” and future trends

“Must-be” and “Satisfiers” as a base, but
special attention toward identifying latent
requirements VOC data-gathering more widely exploratory.
Problems are interesting but, additionally,
quirks in how things are done and future
trends are pursued for their value in
uncovering latent requirements and robust
design clues


What are the
most important
measures and
their drivers?

What measures
to collect?
(where, how
much, etc.)

Y-to-x, prioritization, operational definitions
and measurement systems analysis (MSA)
are useful in all projects

Segmentation based on the location of the
problem and its symptoms

Data collected, using the as-is process
as the source of facts, to shed light on the
root cause drivers (for this project’s focused
problem or problems)

Y-to-x, prioritization, operational
definitions and measurement systems
analysis (MSA) are useful in all projects

Segmentation based on potential locations
of the opportunity

Additional measures used to model
“prospective value” (e.g. conjoint analysis)

Data collected, with or without an as-is
process, to characterize and prioritize
requirements (including prospective latent

As appropriate, data collected or
developed through modeling to shed light
on “design” drivers


What has the
team learned
about current

What can the
team learn from patterns and statistical
contrasts in the data?

Can the team
verify the root
cause or driving
impacts of the
x’s on the Ys?

This will apply directly, as there is a lot more
“current performance” to document for a
DMAIC-type project


“Peeling the onion” to get down to root
causes and fundamental drivers in order to
remove those causes and fix the problem
at its core – removing or reducing the waste
in the as-is process. The historic/current process data
is the key source of data and insight

In DMAIC the x-Y connections are part of
the known, existing system. The work here
focuses on quantifying that relationship

There may not be a current process for
the work under consideration – but
generally the performance of a relevant
as-is process helps document the state
of the art

Understanding the design drivers in order
to guide upcoming decisions about which
factors will be included in and adjusted;
to optimize business net value. Models, prototypes and industry benchmarks are key sources of data and insight.

In DFSS, the x-Y connection may be new
and may depend on the solution to be
selected. The work at this step may involve
prototyping or modeling the x-Y connection
in order to estimate the nature of the


What is the
best solution

How should
the solution
be detailed for
best practical

How will it

Selecting among solution options 

Some use of modeling, depending on the


Some modeling of solution optionsmay
have been started as part of the x-Y
relationship assessment in Analyze

For software, the “coding/construction”
happens here – realizing the design

Continued use of modeling,
prototyping/alpha release to predict and/or verify performance and reduce risk


What factors
are important to
control over the
life of the
or design?

How will
operation be
monitored at all
levels of the
process and
business, with
control signals
at every level?

Similar considerations

Process management
Process control

Conclusion: Being Well-Armed with Insight

All practitioners appreciate that roadmaps are needed to guide the work in Six Sigma, and that there is an understandable need to simplify and integrate when their complexity starts to get in the way. While considering a “branched” and a “parallel” approach to integrating DMAIC and DFSS, one must be armed with as much insight at possible before deciding what is best in their particular environment.

Comments 3

  1. jagin

    I particularly like your high level table detailing the differences in the teams thought processes between a DMAIC and a DFSS project. Well done.

  2. Lee Dwyer

    I have been Process mapping and creating value stream maps for years, and this is a concise and focused document-well Done

  3. Finbarr Sheehy

    Good overall summary.
    Well done


Leave a Reply