What is the “Analyse” stage of DMAIC?
Many Lean Six Sigma projects use the 5-step improvement model of DMAIC (Define – Measure – Analyse – Improve – Control). This method is often chosen where an existing business process requires improvement, and a team-based project approach has been deemed appropriate.
DMAIC provides a logical sequence of steps for teams to follow as they endeavour to improve process performance. I have summarised the five steps in another blog but here I want to describe the third step, “Analyse”, in a little more detail.
The aim of the “Analyse” step is to gain a deep understanding of what’s currently going on in that process. With that knowledge, improvement teams are better placed to create effective solutions.
The Analyse stage is where we try to:
- Gather a comprehensive understanding of everything that’s working and not working within a process
- Identify the key factors driving the current performance of the process
- Uncover the root causes of problems
- Prioritise the elements of the process that need improvement
- Prepare for the next stage of DMAIC, namely “Improve”
Teams who miss out the “Analyse” stage run the risk of treating only the symptoms of a problem. They are likely to implement partial solutions to process issues and fall short of project goals.
The temptation of the solution
The “Analyse” stage requires some discipline of thought.
When confronted with a business problem, human nature can drive our tendency to rush to solution. Perhaps this is a characteristic of our evolutionary development. In ancient times, if we were in danger, we needed to react quickly to survive. We are left with the natural response of being predisposed to “act first”. This was useful when we lived in caves, but in a 21st century business context it can lead to failure.
At the “Analyse” stage, it’s very likely that members of your team will immediately suggest solutions and will want to start working on them. Any ideas with merit should be formally recorded, but not acted on until the analysis is fully completed. We need to develop the patience to “think first”.
Favourite analysis tools
There are many tools that can be used at the “Analyse” stage, particularly if sophisticated data analysis is required. Here I will touch on 3 non-technical tools that are widely used and can be successfully applied in the vast majority of improvement projects.
- Process Mapping is a diagnostic technique where we create a diagram of the steps within a process and then use that diagram to identify problems. The method relies on having the right cross-functional group involved in the mapping process. Capturing the steps can be insightful in itself, but once complete, the team can then ask questions such as:
- Is every step necessary, are some steps missing
- Where do we have wasteful activity, duplications, bottlenecks, process breakdowns
- Where in the process flow are there opportunities for improvement
As the team answers these questions, the map is annotated to highlight the position and nature of problems and opportunities. Once complete, the map shows the whole picture of the process and gives us new perspectives on it.
- Cause – Effect Analysis is another diagramming technique aimed at identifying the root causes of problems. We first write down the problem of interest (the “Effect”) and then get our team to brainstorm potential causes of this. The ideas are categorised on the diagram using headings such as:
The categorisation is useful because it encourages the team to consider the problem from a number of different perspectives. It avoids the conversation going down only one track.
When the idea generation comes to a natural halt, the team can then prioritise which causes to investigate further.
- The 5 – Whys is a popular method of getting to the root cause of problems. First, a statement of the problem is agreed by the improvement team and written up, perhaps on a whiteboard. The team then simply ask the question “Why does that happen?”.
The answer is written up under the problem statement. The same question is then asked of the answer, i.e. “Now, why does that happen?”.
There may be more than one answer at each level of “Why”, and so the captured answers spread out like the roots of a tree.
Some would argue that the “Why” question must be asked 5 times. I believe that the process should continue only until the team believe they have uncovered a root cause and have identified something practical that they can work on.
Analysis not paralysis
The quality of your process analysis will determine the quality of your future solutions.
Be disciplined to complete the analysis instead of rushing to implement the first solution someone comes up with. It’s equally important not to get bogged down in the analysis process. At an appropriate point you need to call a halt and move to the next stage of D.M.A.I.C. where we implement solutions.
“Whatever failures I have known, whatever errors I have committed, whatever follies I have witnessed in public and private life, have been the consequences of action without thought.”
Millions saw the apple fall, but Newton was the one who asked why.