The "belting" of Six Sigma practitioners has been going on since the mid 1980's. Does it matter what we call these people? How far into the organization can the "belting" paradigm effectively reach? Hint: It doesn't belong everywhere!

What comes to your mind when you hear the word Black Belt? You might wonder what Karate has to do with a Six Sigma program.  It seems incongruent. Today it is an accepted title for a person who has completed approximately four weeks of training and two substantial cost-reduction projects. In this context, a Six Sigma Black Belt's job is quite clear -form a team to save big money by completing process improvement projects that are a big deal to the company's bottom line. Quite a list of "belt" titles and responsibilities has grown up around Six Sigma initiatives. Master Black Belt, Black Belt, Green Belt and Yellow (or White) Belt are some examples. The meaning of these designations may vary between companies, but standardization of the nomenclature and belt behavior is relatively mature these days and substantive differences are pretty rare. There has been surprising acceptance of these names and their roles - for the most part. Once a few famous companies embraced the paradigm, mainly GE, this approach and vocabulary caught on.

What really made DMAIC Six Sigma belt certification popular was the underlying capability of the DMAIC steps and their enabling tool sets. Jack Welch, in his book, Winning, says, "Nothing compares to the effectiveness of Six Sigma when it comes to improving a company's operational efficiency, raising its productivity and lowering its costs." People readily sign up if the method really works and management rewards its use. For process improvement/cost reduction DMAIC Six Sigma programs, the use of "belt" certification is widely accepted.

What if your use of Six Sigma is not within the DMAIC Methodology?

There is likely to be resistance to the Six Sigma "belt" titles and certification process if it is applied to the Phase-Gate worlds of product development, technology development and research processes. We are not referring to using the DMAIC Six Sigma methodology to solve some wasteful process problem within these environments, such as leaky Erlenmeyer flasks. A product development project is not a DMAIC project!

In these arenas, Six Sigma, also called Design for Six Sigma or DFSS, is used to enable tasks during the phases of product development. Technology Development for Six Sigma (TDFSS) is used similarly to apply DFSS tools to develop robust and tunable technology platforms and modular technologies useful across families of new products. DFSS tools can even be applied within the phases of the scientific method as research scientists invent new science and transfer it to technologists. Research scientists are best served by not calling this DFSS because they rarely design anything, except measurement systems from time-to-time.

So, if you really look at how the people who develop new products, or technologies or science actually work - it bears little resemblance to the methodology of DMAIC Six Sigma. But corporate Six Sigma folks may not appreciate these differences, and still try to force the "belt" certification paradigm into these arenas. This is a BIG problem. The further upstream into product development and research, the bigger the problem gets with the people who are forced to fit the classic DMAIC training, project execution and project timing mold. This has really damaged Six Sigma's credibility across many enterprise deployments since 1986.

Do not under any circumstances try to create any kind of "belt" in research or technology development organizations. End of story on that issue. Leave the technologists and the scientists alone in this regard. A research scientist may value a subset of the Six Sigma tools, and by all means, teach and mentor those who do, but don't bug them about getting certified as a "belt".

If certification and granting a "belt" status or title is important in your culture, engineers working in product development are more likely to accept the title. Call them a DFSS-Belt; no particular shade of color is necessary. For engineers in product development, the following advice applies:

Tie certification to a candidate's ability to produce credible results (positive or negative) from selected DFSS tools on a real product development project. Require the selective and appropriate use of the DFSS methods on their actual product development project. Assess their results at peer reviews and design reviews to prove the tools are delivering appropriate results in alignment with the requirements of your product development process. Your certification could also include mandatory attendance at training sessions and/or passing a test, but don't go overboard with this; they already have an engineering degree!

Use judgment on which DFSS tools are required; it is NEVER "all of them". Use only the tools that fulfill specific requirements on each specific project.

Do not discriminate between GB and BB levels for engineers. If a degreed engineer is going to be certified, send them through the entire DFSS curriculum - usually around 120 hours of topics taught in rigid alignment with your product development process phases and gates vocabulary.

Train all of them. Do not train and certify some of your engineers and call them DFSS Belts - while others are kept out and told they have to consult the DFSS Belts for any help they might need. If you want your engineering teams to be loaded with distracting dynamics and an "us versus them" attitude - just set some apart, certify and bestow special titles (BB or MBB) and let the fun begin.

This topic is explored in more depth in PDSS President Skip Creveling's upcoming book, whose working title is The Rise and Decline of Lean and Six Sigma, from which this article was adapted.

Have a comment on this article? Please "reply-to" this newsletter email.