The DMAIC framework, with its Define, Measure, Analyze, Improve, and Control phases, is the most common method used in Six Sigma projects. Most Green Belts (GBs) and Black Belts (BBs) are trained to execute Six Sigma projects using this framework.
Following the DMAIC steps, the project team can think rigorously and approach the problem systematically. Books and training materials include applicable tools for each phase and checklists for tollgate reviews. Organizations often have DMAIC templates that define mandatory and optional deliverables for each phase. All of these are supposed to help the GBs and BBs to determine the right questions to ask and the right tools to apply along the DMAIC process.
In reality, the templates are not as helpful. I observe many project leaders either confused with what to do in each DMAIC phase or doing the wrong things. For example,
- Project teams include a tool or analysis simply because it’s a “required” phase deliverable, even if it doesn’t improve the process or our knowledge.
- The project leaders are more concerned with presenting visually impressive slides to the management than understanding the process. They re-create a SIPOC or Fishbone diagram on a slide from the flipchart or white board when a snapshot is perfectly legible.
- Project teams go to a great length to document the current state electronically (e.g. in Visio) as a single process (which is futile), rather than spending the time “Go Gemba” to understand the variation.
- The project continues even after the evidence and analysis show that the project baseline or business case is no longer valid. Instead of using the tollgate to stop or re-scope the project, the team shows various tools and analyses to justify the value of going forward. They are afraid that terminating the project will reflect negatively on them.
- The project team is sent back to complete a deliverable at the tollgate because it is not satisfactory to the management even when the deliverable is not critical to the next step in the project. As a result, teams always overprepare for the tollgates in fear of imperfect deliverables.
- Instead of seeing an inadequate measurement system as an opportunity re-scope the project to address it, the team is asked to demonstrate an adequate measurement system before closing the Measure phase. They are stuck in Measure to perform Improve activities.
Why are these happening?
I discussed in my earlier blogs about some related challenges in “Starting Lean Six Sigma” and “The First Six Sigma Project.” By understanding how Lean Six Sigma fits in the organization’s objectives, strategy, and capabilities, the leaders can choose the right deployment approach for the organization. By selecting the right candidates and projects and by providing the right training/coaching to both sponsors and GBs/BBs, the leaders can avoid many common mistakes when the organization is in the low continuous improvement (CI) maturity state.
While the experience of the project leaders is a factor, I attribute the main cause of many Lean Six Sigma deployment issues to the organization, not the individual GBs or BBs.
Beyond the initial stage of the deployment, the organization’s chance to achieve and sustain a CI culture and high return on investment depends on its leaders. Many Lean Six Sigma challenges simply reflect the existing organizational and leadership issues. Using the DMAIC methodology as a “plug & play” solution by the leaders only exacerbates the underlying problems.
DMAIC templates and tollgate reviews can help guide newly trained GBs and BBs as they practice scientific problem solving. But when they become prescriptive requirements and project performance criteria dictated by management, it discourages dialogue and organizational learning, which are basic elements in a CI culture. Judging project progress against a fixed set of DMAIC phase deliverables without understanding the applicability and true contribution in each case only causes confusion and fear. It reinforces the “fear of failure” mindset in many organizations.
The DMAIC stages are not linear, but iterative within the project, e.g. if a solution in Improve is insufficient to solve the problem, the team can go back to Analyze. A DMAIC project should not be run like a “waterfall” project, but an Agile project with rapid learning cycles. With reasonable justification, the team should be allowed to decide to pass the tollgate and continue to the next phase. Empowering the teams is risky and comes at a cost, but they should be given the opportunities to learn from their mistakes (if it’s not too costly). Competent coaching will minimize the risk.
Compounded by the fear, poor training, and lack of experience, project efforts are often driven by management expectations at tollgate reviews. A polished presentation with a complete set of phase deliverables beautifully illustrated with tables and graphs shows team’s accomplishments and satisfies untrained reviewers. But it often fails at facilitating critical analysis and deep understanding required to address root causes – it sends the wrong message to the organization that the new CI methodology is all about presentation not substance.
If any of the examples sounds familiar or if you are concerned with building a CI culture and capability, one area for improvement might be in your DMAIC stage-gate process.