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.
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:
If you can't describe what you are doing as a process, you don't know what you're doing.
W. Edwards Deming
In 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?
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!
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
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".
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:
- A Process Map
- 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
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
Improve and Control
In an obvious way, the process map of the DMAIC process can be extended to include the Improve and Control steps. Rather than use the limited space of a web page, a process map has been created in Triaster's showcase Process Library here. Access the library by clicking the link, then search on the term DMAIC.
Clearly, the goal of the Improve phase is to implement a revised process that solves the problem. This is a significant undertaking involving many steps such as shortlisting potential solutions, testing, evaluating, gaining buy-in and feedback and so on, but the ultimate Deliverable is a new way of doing things that solves the problem defined in the Project Charter. Note the key word is "implement" - the Improve step is not solely a modelling exercise, it is 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:
- a revised Process Map
- a "User Guide" to the new process
- 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).