If you’ve read some of my previous blog entries, you’ll know I’m no fan of roadmaps. I used to think this was a radical proposition in the Six Sigma community. But more and more, when I talk to practitioners – the people on the ground who do the hands-on work of process improvement – I am finding that this opinion is perhaps not a minority view after all.
Yes, this is even true of DMAIC, the Lord’s Prayer of Six Sigma that is etched into Black Belt brains around the globe. And to be perfectly clear, I realize that in many places DMAIC is considered past its prime, having been supplanted by various Lean-Six Sigma hybrid roadmaps, or design roadmaps like IDOV and DMADV. To be fair to acronyms of all stripe, I’ll go on record and confess that it’s not any one specific roadmap I have an aversion to, it’s the use of roadmaps in general.
To be sure, roadmaps do have several advantages. They’re easy to teach. They lend themselves well to dashboard displays. They provide and easy point of reference for senior executives and other stakeholders. They make projects seem like they are progressing. And they’re a crutch, especially for beginners. But beyond this last point (which I’ll get to in a minute) I don’t think they’re especially useful for the people actually doing the work. In fact, in my experience, they lead to a lot of waste as folks “check off the box” on various tools in each stage of the roadmap as opposed to doing strictly what is necessary to advance the project. And on the flipside, they let people get away without thinking through the best approach for themselves. Think of it this way: the roadmap is an a priori answer to the question of “how should this project be done” that utterly ignores variation in circumstances. For the life of me, I can’t understand why we as a community believe it’s going to be the right answer in more than a few lucky cases.
Then again, maybe we don’t believe it. When I’ve asked around, I’ve found that projects that truly follow a roadmap are far and few between. This is puzzling, given the standard Six Sigma dogma. But it has been my experience that the vast majority of good work going on out there involved subverting whatever roadmap it’s supposed to be following. Experienced Black Belts regularly skip stages, do them out of order, repeat them, and add new ones of their own invention. Master Black Belts speak in hushed tones about projects that succeeded after a simple visual display of data showed what changes needed to be made. Green Belts sometimes find that they need to work on the measurement system again after doing some “improve” work. Gasp!
My point is that disregard for roadmaps is an open secret. Turns out my views are probably within the distribution after all. Given this is the case, what I can’t figure out is why roadmaps are still peddled so aggressively in the Six Sigma community. If every project is an exception to the process, why are we still teaching the process? Why not embrace the freedom of a non-roadmap approach?
Don’t get me wrong: I love organizing concepts for continuous improvement work, and understand the necessity of having something more than a random collection of tools. I’m especially enamored of iterative models like the scientific method and PDCA. (Even DMAIC becomes a lot more palatable to me if we admit MAI are likely to iterate along parallel paths between D and C, but that’s a pretty messy acronym.) But beyond that, I think what we ought to be doing is encouraging folks to understand data: collection, display, analysis, uses and abuses of data. We ought to be encouraging them to think for themselves what sequence of steps are necessary to get through a project, what data are required, and how those data should be collected and analyzed. And if we want folks to truly get good at this, I contend that handing them roadmaps when they start out hinders rather than helps the journey.
