THURSDAY, FEBRUARY 23, 2017
Font Size
New to Six Sigma Design for Six Sigma (DFSS) DMAIC and DFSS Roadmaps: How to Connect and Integrate?

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.

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.

High-Level
Thought
Process

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

Define


Project Goals? 


Business Case? 


Scope?


Customers/
Stakeholders?


As-is Process? 


What Are Key
Requirements?
 



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
(Focused)


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
service)


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


Measure


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
requirements)

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


Analyze


What has the
team learned
about current
performance/-
capability?



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
relationship

Improve


What is the
best solution
choice?


How should
the solution
be detailed for
best practical
implementation?


How will it
work?



Selecting among solution options 


Some use of modeling, depending on the
case


Pilot





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


Control


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


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





Similar considerations


Process management
Process control
Dashboards

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.

Register Now

  • Stop this in-your-face notice
  • Reserve your username
  • Follow people you like, learn from
  • Extend your profile
  • Gain reputation for your contributions
  • No annoying captchas across site
And much more! C'mon, register now.

Leave a Comment



Comments

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.

Reply
Lee Dwyer

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

Reply
Finbarr Sheehy

Good overall summary.
Well done
Finbarr

Reply


Login Form