dojo 4 why not dmaic
Why Don't We Use DMAIC?
After all, we are a lean six sigma operation, and DMAIC is a standard methodology. At Utah, we’ve adopted a revised improvement methodology. In this week’s post of Steve’s Dojo (or continuing Lean Six Sigma education), Steve explains why.

he traditional six sigma methodology is DMAIC (“duh-may-ick”): Define, Measure, Analyze, Improve, Control and it has been around since the 1980’s.

Utah’s methodology is based on DMAIC and refashioned to better reflect what happens in a project.

What’s different?

dmaic dojo

Steps 1, 2, 3:

We changed the language of the first three steps.

More on Step 2:

Baseline Analysis confirms the perceived problem your team is planning to fix, or it may expose the problem to be a mirage, in which case you would gate the project. Baseline Analysis defines the current state quantitatively and qualitatively. At the end of Baseline Analysis, any blanks in your SMART goals should be filled in with numbers. I always hope to see some histograms and run charts backing those numbers up. A current state process map should be complete at this point.

BTW—you can use the term "current state," like I just did, but six months later it won’t be the current state and the language becomes confusing. You can avoid all this by adopting "baseline".

More on Step 3:

Investigation is merely the application of LSS tools beyond what you used in Baseline Analysis. Perhaps a Pareto analysis is in order, and maybe a gemba walk followed by manual data collection with a check sheet. Maybe you have a regression analysis to complete. I’d say all of these elements belong in the Investigation phase. (Others would argue that gemba is part of Baseline Analysis. If we were to argue about it, it’d purely be academic.)

More on Steps 4 and 5:

We split DMAIC’s Improve into the two phases (Design and Implementation). Why? Traditionally, you design the improvement, perhaps with multiple iterations, and only when you have appropriate approvals, do you begin to implement. We believe design and implementation deserve to be separated because they involve different skill sets and different levels of effort.

We chose chronology over function and placed some of Control’s functions in Improvement Design and Improvement Implementation. DMAIC’s Control is a mish-mash of improvement design, implementation, and monitoring activities. You design forcing functions (guiderails to ensure your new process is followed) as you design your new process or just after, and then implement them. Likewise, the team designs and implements metrics, probably embedded in a scorecard. DMAIC places all those activities in Control which is their function, but it’s not where they fall in a project’s sequence.

More on Step 6:

When we say a project is “done,” we’re talking about the transition from the end of Improvement Implementation (typically marked by a successful pilot) to the Monitor phase. If you’re in Monitor, the hardest work is over and the team can disband.

We need to ensure our process and its controls stay working as planned, thus the three year Monitor phase. The three year rule assumes a quarterly scorecard was built. Some projects have shorter Monitor periods if data collection is unusually cumbersome. If the metrics don’t reflect the expected value improvement, we revisit with a second PDSA cycle.



Steve Johnson

Director, Value Engineering, University of Utah Health

Subscribe to our newsletter

Receive the latest insights in health care improvement, leadership, resilience, and more.