Six Sigma Beyond DMAIC

There is a strong tendency for Six Sigma programs to forge an inextricable link between project management roadmaps, notably DMAIC, and statistical tools. This has never made much sense to me. In my experience, Six Sigma programs can not only exist and survive without the use of typical roadmaps, but prosper and flourish.

In the vast majority of Six Sigma environments, it borders on heresy to even ponder whether some, if not all, projects couldn’t perhaps be completed without the use of a roadmap. While it is probably the case that the DMAIC framework is efficient and appropriate for a certain subset of projects in most organizations, I have never been able to accept it as the panacea that most people in the field seem to. And by people, I mean consultants and executives. Not experienced practitioners, because by the second or third Six Sigma project most folks on the front lines eventually realize that toll-gate driven roadmap processes consume enormous amounts of time and energy in the form of meetings. In fact, I suspect the majority of seasoned Black Belts would abandon toll gate reviews in a hurry if they had the choice.

Handpicked Content:   Are All Six Sigma Deployment Models Equal?

Consider a class of 24 Black Belts, all of whom will complete 2 projects in a year. Suppose (conservatively) that each project team has 5 members, and (again conservatively) that each toll gate review will take 30 minutes. That adds up to 120 hours of time spent in meetings involving those who are supposedly the best and brightest in the company. And what do those meetings produce? Certainly they gather stakeholders together to inform and discuss aspects of the project. But do they make a material difference to the outcome of the project? In other words, would the end result be better, worse, or the same if we gave the Black Belt responsibility and authority to organize the project and team meetings as they saw fit, as opposed to imposing a DMAIC structure? I submit that in my experience there are few negative consequences to abandoning the toll-gate-roadmap approach, and numerous positive consequences. Fewer meetings are one such benefit…admittedly one of my favorites!

It is undoubtedly true that DMAIC and other roadmaps are: a) easy to teach; and b) easy to administer. This makes the roadmap approach a darling of consultants (who see a consistent and portable program that can easily be taught in many different environments) and executive management (who see that DMAIC in particular lends itself to tidy dashboards and displays). But do the steps add value to a product or service? In most organizations I suspect the Lean folks would consider canceling toll gate meetings an easy, quick-win project. My hunch is that they would be correct in most cases.

Handpicked Content:   Changing the Clutch in the Paradigm Shift

What’s the null hypothesis here? If the tacit assumption taught by consultants and embraced by executives asserts that roadmaps and tollgates are necessary, the hypothesis that needs testing is something to the effect of “does a program without any toll gates or roadmaps result in any statistically significant differences compared to a program based on DMAIC or some other roadmap?” And if there were differences, would they be positive or negative? In short, what are we getting for all the time spent on toll gate reviews and roadmap compliance, if anything?

My own view is that there is an infinite variety of improvement opportunities out there, and it’s nonsensical to suggest that any single roadmap will serve a significant portion of them well. Tacit agreement with this view is provided by the flurry of supplemental roadmaps that have appeared (and continue to appear) over the years since DMAIC was first introduced. So the test for the null hypothesis is both simple and audacious: run a Six Sigma program that does not depend on any particular roadmaps and see what happens; teach the tools of Six Sigma without the framework of DMAIC (or any other framework) and evaluate the results; trust practitioners of Six Sigma to decide for themselves how projects should be managed, when meetings should happen, what stages are appropriate for a project. In short, let go of structure and embrace flexibility.

As organizations turn more and more to innovation as a wellspring for continuous improvement, what we ought to be creating is not wave after wave of people who can follow roadmaps well, but rather creative map-makers who can and do chart new paths to any destination. To do that, we need to explore Six Sigma beyond DMAIC.

Comments 9

  1. Andrew M. Hillig


    I would tend to agree that innovators are the greatest asset to an organization, but I would question the efficacy of a program that prides itself on structure and standard work if some sort of roadmap is not followed.

    I think without a plan, the standardization is lost and teams can get caught up in a paralysis by analysis situation.

    I only say this because this has been my experience when implementing in healthcare. If my champions don’t layout a clear vision of where they are and where they want to be, the teams tend to deviate from the task at hand and get caught up in details not essential to the implementation.

  2. Andrew Downard


    I am a big believer in structure, but I don’t believe roadmaps are the only way to provide structure to a continuous improvement program. Not having a pre-determined roadmap is not the same as not having a plan, or not having good project management skills. I’d never advocate not having a clear vision and plan up front, under any circumstances!

    In my experience most projects are sufficiently different from one another so that, in order to achieve maximum efficiency, a somewhat different sequence of steps is necessary from one project to the next. Rather than fight this by having many projects use the same roadmap, it makes sense to me to have the project leader write their own roadmap (in some form) as a first step. Any good Six Sigma training program should enable a Black Belt to do this while taking statistical principles into account.

    To be honest, I felt the same way you did until I had a chance to work in both systems. As you suggest, forgoing the roadmaps is very scary at first and requires some very disciplined program and project management. If this isn’t present what you end up with can become a giant mess. But the trade-off has been well worth it in my estimation.

  3. eric

    I think Andrew D. is talking about something other than project management, explicitly. Without the structure of the road map you can still effectively manage the project. Remember we are not after structure for its own sake, we are after results. Knowledge workers can plan their investigations in terms of the data acquisition plans, communicate how these data acquisition plans help answer questions to solve the problem presented in the goal. This is a more useful discussion than deciding if we are in M or A.

    A knowledge worker can keep their stakeholders engaged by communication. Data Acquisition plans help answer questions that will address the solving the problem at hand; this is more important than A or I. Enquiry proceeds from induction and deduction not by acronyms. Managing projects can still be conducted. This path can still permit discussion with stakeholders; What are you doing? Why? When will you be done? What might you do next and when? How close are we to solving the problem? This is better than discussing p-Values and even better than discussing “I am in the middle of step I”. This is especially true of organisations where immediate management is largely former technical people themselves.

    The highest technique is to have no technique. DMAIC and even the path Andrew suggests are techniques. Deciding a path is a function of the project, the knowledge worker and the needs of the business.

  4. Andrew Downard

    Eric said:

    "Deciding a path is a function of the project, the knowledge worker and the needs of the business"

    I couldn’t (and actually didn’t) say it better myself. This statement neatly summarizes the root cuase of my discomfort with setting up DMAIC or any other roadmap as a default.

    And to further agree with Eric, in my experience a high percentage of time in and out of DMAIC toll gate review meetings is devoted to exactly the kinds of non-value-added "is this A or I?" type questions he describes.

  5. Taylor Made


    I have a lot of respect for your thoughts and I look forward to reading more from you in the future.

    I would like to suggest one thought on top of yours. You asked, "So the test for the null hypothesis is both simple and audacious: run a Six Sigma program that does not depend on any particular roadmaps and see what happens; teach the tools of Six Sigma without the framework of DMAIC (or any other framework) and evaluate the results; trust practitioners of Six Sigma to decide for themselves how projects should be managed, when meetings should happen, what stages are appropriate for a project. In short, let go of structure and embrace flexibility."

    This test has been done. It was called Quality Circles, then it was called TQM, then it was called Reengineering, and so on. Why has Six Sigma lasted 20 years? I belive it’s due to the roadmap, and a helluva improvement program that has and continues to evolve over time.

    Continue to challenge everything. Thanks for the post.


  6. Andrew Downard


    You bring up a very good point. I’ve spent a lot of time pondering whether the roadmaps are the only thing distinguising Six Sigma from the CI programs that came before it. You could very well be right that my experiment has already been run in the form you suggest. To be completely candid, I haven’t been around long enough to have experienced those previous programs.

    There is a larger question here of why programs come and go; is it because they are truly evolving and improving, or is it because human nature demands that we have something fresh (at least in appearance) after a certain period of time. I don’t know the answer to that one either.

    There are actually two specific experiments I’d like to see. The first would be to take two instances of essentially the same improvement opportunity and attack it with and without a roadmap. This would likely require a large organization – large enough that two roughly equivalent Black Belts could be tasked with the same opportunity in two similar but distinct facilities, business units, etc. You can probably guess what my hypothesis on the outcome would be, but I don’t have any data to back it up. Maybe someone else knows if this has been done before?

    The second experiment would be to try the same thing on a deployment level – pick two similar but distinct business units or facilities, and run parallel deployments of different programs (i.e. with and without roadmaps) in each. Again, maybe this has been done?

  7. Taylor Made


    I’d like to see that experiment also! I think there may be more factors at work here, as you suggest. Roadmap, deployment plan, wave training with an evolutionary inclusion of related skills (such as project management, change acceleration process, team skills, etc.) for all levels (GBs through Champions and Executives), standardized (or somewhat) training, tollgates, financial analysis driven by the finance group within an organization, etc. You get the idea. I’d put down my 5 bucks and a beer at the next Six Sigma conference on which scenario would pay off.

    Heck, I look forward to sharing a beer with you at the next conference regardless. Keep up the good work.


  8. Mark

    DMAIC is simply a road map that has proven to be successful. The structure is more of a benefit to project team members that have not had any training for continuous improvement (keeps people focused). I would agree that an experienced change agent would experience success but without the experience you could set people up to fail.


  9. Andrew Downard


    While I respect your opinion, I just don’t believe what you are saying to be true. From what I have seen, programs that do use roadmaps perform no better or worse than program that don’t use roadmaps. The success of failure of a program (or a project) is affected far more by other factors than choice of roadmap. And since roadmaps inevitably increase paperwork and beaurocracy, you’ll got some motivation to toss them out the window. When I have seen that happen, the results have been…nothing. A program that is poorly organized and underperforming continues on that track, while a program that is well organized and delivering results keeps doing that. The presence or absence of roadmaps don’t make a difference.

    If you know of examples to the contrary, I’d be interested to hear about them.


Leave a Reply