DMAIC Process vs Cycle: Why Process Wins Every Time

Michael Cousins

DMAIC is a 5-step method for improving processes, and it is itself a process. However, it is nearly always described diagramatically as a cycle in terms of the Activities involved, these being:

What is the DMAIC Methodology?

Diagramatically, DMAIC is often represented as a cycle, indeed DMAIC is a direct descendant of the Plan-Do-Check-Act cycle. A typical representation of a DMAIC cycle is given below, but a quick web search will soon reveal hundreds of similar diagrams.

DMAIC.png

Image sourced from: cdn2.hubspot.net

However, a cycle does not convey the richness of the DMAIC model, or the real purpose of each step. To do so, it needs to be described as a process. As Deming himself said:

Triaster quote
If you can't describe what you are doing as a process, you don't know what you're doing.
W. Edwards Deming
 
Free process mapping software
 

For Triaster, the 5 DMAIC steps are in fact Activities - they are clearly the Verbs of the DMAIC process. But where are the Nouns? Where are the outputs of each step defined? Where are the supporting working document templates?

For more on the Noun-Verb process mapping methodology please read the article: Noun-Verb: A Simple Process Mapping Methodology.

To really understand DMAIC, and to be able to fully utilise it, it is helpful to augment the DMAIC model with Deliverables from each of the 5 Activities, and to show clearly how the Activities in the DMAIC process interrelate and depend upon each other. DMAIC can then be described not just in terms of the steps involved, but in terms of the outcomes it delivers. DMAIC can and should be described as a Process.

So, let's do precisely that!

Define

Typically, a DMAIC process is triggered because a problem exists, and the problem is important enough to justify expenditure of time and money to solve it. Prior to the DMAIC process being started the problem is not well defined, the solution method is not clear and the objectives are not specified. All that is known is the problem exists and it causes issues. There is therefore the beginnings of a business case, but not the real substance required to justify investment.

For a strong DMAIC process, there needs to be a clear Input to the Define step, and this input is the information that is known prior to the process starting. This will be called the Draft Project Charter.

In terms of Outputs, the Define step of the DMAIC process really is about completing the Project Charter (or Project Contract) as its key Deliverable. The Project Charter, typically just one or 2 pages, in turn contains several sections such as the scope, statement of objectives and the problem definition. In a process map however, we can draw just the key Deliverable at the high level, and leave the detailed breakdown to the lower levels.

So, instead of

Define Deliverable

we have

Project Charter Process Map

instantly making it much clearer what is needed to enter the Define step, and what must happen as a consequence.

Verbally, this can be read as "The Define step transforms the Draft Project Charter to the Project Charter", or, "The purpose of the Define step is to create a Project Charter, and to do so a Draft Project Charter is required".

Measure

I have always felt Measure to be a slight misnomer as the purpose of the Measure phase is to capture as much relevant information as possible about the problem being solved. However, a lot of DMAIC users are interested in understanding which tool is most commonly used in DMAIC Measure phase. This entails two sectors:

  1. A Process Map
  2. A Data Analysis

The process map contains all the flow information, and answers the Ws of the process (who does what with what and delivers what to whom and when via which means). The process map can be a collection of models in different forms appropriate to the problem area and is one of the most common tools used in DMAIC. For more on process mapping, download our white paper or here for the best beginner process mapping tools. The data analysis is concerned with the costs, cycle times, bottlenecks, sources of error, points of duplication, single points of failure and so on, in short, any data that supports a deeper understanding of the problem, and enables testing of proposed solutions.

In order to map the right process, and analyse the right data, the Project Charter is required as in Input to the Measure step.

So, instead of

Define and Measure Deliverables

we have

Project Charter Process Map

Analyse

The purpose of the Analyse step is to identify the cause of the problem - it is a root cause analysis. This cannot be achieved without first understanding the process and the relevant data of the process, the Process Map and Data Analysis are therefore pre-requisites to be able to perform the Analyse step properly.

Typical outputs from the Analyse phase will be documents and diagrams that define or describe the root cause, for example, an Ishikawa diagram or notes from a brainstorming session. We will refer to these documents as a Cause and Effect Analysis. Ultimately however, the goal is to identify the root cause(s) of the problem being solved, and for this to be described in a Root Cause Analysis.

So, instead of

Define, Measure and Analyse Deliverables

we have

Project Charter Process Map

Improve and Control

The process map of the DMAIC process can then be extended to include the Improve and Control steps

Clearly, the goal of the Improve phase is to implement a revised process that solves the problem. This is a significant undertaking which is likely to involve several steps such as shortlisting potential solutions, testing, evaluating, gaining buy-in and feedback and so on, but the ultimate Deliverable should be a new way of doing things, that solves the problem defined in the Project Charter. Please note the Improve step should not be solely a modelling exercise, it should be very much concerned with the practical steps of implementing a new way of working, confirming it is a real improvement, and decommissioning the old way of working.

The Control step is all about cementing the new way of doing things, and ensuring the gains made are improvements that last long into the future, not short-term gains that quickly fall by the wayside. To do this is largely an exercise in documentation and training. There will be a multi-faceted set of documentation, comprising process maps, working documents, procedures, flows and so on that define how work is to be performed. The top level process can be used to hide this detail, which would then be revealed on the drill-down of the more detailed process. Typical outputs therefore are:

  1. a revised Process Map
  2. a "User Guide" to the new process
  3. a Control Plan

Conclusion and Next Steps in the DMAIC Process:

By building a DMAIC process, instead of a DMAIC cycle, much greater clarity is achieved on the purpose of each DMAIC step. This in turn helps the members of the DMAIC team focus on the things that really count. The DMAIC process map becomes a useful learning and implementation aid to the DMAIC process itself, instead of a a cycle that really fails to capture the essence of the required outputs of each step (and hence the purpose of the step itself).

Triaster has developed both the Noun-Verb process mapping methodology mentioned above and the process mapping software Process Navigator. Process Navigator is the ultimate drag-and-drop process mapping software, which enables the practical application of the Noun-Verb process mapping methodology,  is full of functionality and really easy to use.

It is also entirely free. I suggest you download it now.

New call-to-action

Related Articles:

What is Process Mapping, Who Does it and Why Use it?

How To Process Map For Free with Process Navigator

What is the Noun-verb methodology of Process Mapping?

Lean Vs Kaizen Vs Six Sigma

Related White Papers:

Business Process Management Terminology

The Ultimate Guide to Business Process Mapping

 

This is an updated and refreshed edition of an article originally written in 2017.

Written by Michael Cousins

Mike founded Triaster in 1994. A thought leader in business improvement, he has led Triaster ever since, spearheading its development of beautifully engineered business improvement software, that is both full of the functionality required by business analysts and that end users find really easy to use.