It's getting close to Halloween, so I'll lead off with a really scary statement:
"We need to make this process as simple as possible for our Green Belts so that they will follow it. They need a checklist of tools to use in each phase of the DMAIC process."
— Lean Six Sigma Deployment Leader
The objective is reasonable, and the statement seems benign on the surface, but until you step into it, quicksand looks pretty safe. In this case, it's the assumed solution of a "checklist of tools" that causes problems.
Checklists are powerful and useful tools for managing complexity. They help reduce variability and prevent errors. But checklists are only warranted when you have a group of items or sequence of actions that are KNOWN TO BE SIGNIFICANT. Examples include pre‐flight checklists, pre‐surgery checklists, software implementation plans, and even grocery lists.
But when you DON'T KNOW WHAT IS SIGNIFICANT, then you are on a mission of discovery, and discovery is driven by QUESTIONS, not pre‐defined answers or prescribed tools. Lean Six Sigma DMAIC projects are such voyages of discovery. They are about developing new knowledge, not implementing known solutions, and such discovery must be question‐driven. Only the questions are known to be significant at the outset; neither the answers nor the exact methods (tools) necessary to determine those answers can be pre-determined. There is no short‐cut past thinking.
Adding to the confusion, sometimes answers are mistakenly referred to as Deliverables — a predefined desirable output or work product — but that misses the point a bit. Deliverables are the EXPRESSION OF ANSWERS, not the answers themselves.
So what does that mean? Let's take the project charter as an example. The charter is a deliverable. If crafted correctly, it should embody the answers to critical questions like "What is the problem?", "Why are we working on this?", "Who is going to do the work?", "What does success look like?", and "When does the project need to be completed?".
I've seen project management templates that consist solely of required tools and deliverables, but no mention of the questions being answered by those tools and embodied in those deliverables. Skipping the important questions causes a loss of context and retards the development of critical thinking skills.
Grouping the critical questions of an improvement project into a useful sequence facilitates organized thinking and efficient project management, and that's just what the DMAIC road map does. It's not a roadmap of tool usage, it's a roadmap of questions to be answered to uncover the truth and implement change. There are certainly lots of tools used in answering those questions, and the tools must be taught and learned in coherent fashion, so DMAIC is often confused as a checklist of tools rather than a checklist of critical questions. In my opinion it should be all about the questions.
Thinking Still Required
In a recent guest blog, Mike Carnell makes a strong case for critical thinking that is adapted to the circumstances rather than rigid rubrics for process improvement. Mike also spoke at our annual Best Practices in Blended Learning Conference, and made an interesting observation: "First we tell people that we want them to think outside the box, then we put them IN a box and wonder why they are not creative". Checklists of things to do are the antithesis of creativity — that's the whole point after all — to drive out variability when it is unwelcome. You really don't want variability when confirming that a plane is ready to fly over a large body of water.
A discovery process, on the other hand, is dependent on creativity because it's about developing new knowledge and inventive solutions. A checklists with an item that reads "generate creative solution" is not useful. But critical questions can drive that creative process when those questions are used as the guiding principle of DMAIC rather than checklists of tools to use by phase. It's harder to teach project leaders, or "belts" to think critically — to ask the right questions and then pick the proper tools to answer those questions — but you end up with people who actually think about what they are doing and why they are doing it.
And thinking is still the driver of process improvement!