At one of my former employers it was mandatory for every engineer and manager to be Lean Six Sigma Certified to at least Green Belt level. Most executive managers also needed to be Black Belt certified.

(One of my team on my last project is a real black belt – in Aikido – he finds the copying of terms somewhat problematic. I’m not going to argue with him!)
The company was heavily manufacturing-oriented; producing machinery for oil & gas, jet engines, power station systems, white goods, medical equipment and more. You name it, they probably made it somewhere around the world.
The Lean aspect of the certification was a later addition but made it worthwhile – at least for me. However most of the “engineers” I worked with at my main site were purely software engineers. (A few of our other sites I worked with had software, firmware and hardware for the same products under one roof). The software teams didn’t see the value in a (rather rigorous) mandatory certification – and given the way it was taught and introduced I don’t blame them.
A Green Belt certification requires a week of training, book study, completion of an exam and delivery of a full end-to-end process improvement project following one of the Lean Six Sigma improvement cycles (typically DMAIC – Define, Measure, Analyze, Improve & Control). Beyond this, the DMAIC project has to use a broad selection of statistical process control and measurement tools for each of about 15 steps throughout the project.
Certification candidates had to identify a real (but small enough to be achievable) process improvement project on their site and deliver it through this process. A challenge with our software teams is that many felt they were already following continuous improvement practices and that the overweight nature of the certification projects was entirely unsuitable for the work and improvements they were doing.
In many ways they were right.
The problem was that nobody ever explained why the projects needed to be so rigorous and what eventual value they would see. All they were told was “By becoming Lean Six Sigma certified you can talk with staff and managers across the company at any level using a common language and understanding.”
That’s a great ideal – except that their management chain already spoke the language of software.
As a manager at the site, I too had to run a DMAIC project. It took nearly a year to complete as I had to use “borrowed time” on top of all the other projects and initiatives we were all responsible for. Funnily enough it was only after I left that company that I discovered how valuable the experience was.
Picture working in a garage for a high-end specialist motor vehicle company.
You have an array of tools in front of you. As a novice you don’t know how to use anything but a spanner. You barely recognise what some of the tools even do but as an apprentice, you’re trained up, taught the proper way to use each tool and in what situation and context. (You don’t – after all – use a sledgehammer to crack a nut).
This is where my Six Sigma training and certification failed significantly.
You’re required to prove you can use all the tools in the box but nobody actually explains that once you’ve learned how to use them, you only need you to use the right tools at the right time.
As a result, the indoctrination of Six Sigma churned out a high number of people that believed it was mandatory for every process improvement project to follow the same rigorous steps and use all the tools in the box. (I believe this culture has changed significantly now though)
The problem was exacerbated further by introducing a specific Six Sigma career path. Staff could apply for “Black Belt” roles that were a 2 year rotation through various parts of the business. These were amazing roles focused on delivering rigorous process improvement programs all over the world however they had some dangerous flaws.
The 2 year rotation was actually the time it took to complete a Black Belt certification. Much like the Green Belt, it required completion of projects. In this case, two major process improvements for a business. Plus teaching and facilitating Six Sigma and Lean events.
Most (but not all) staff in Black Belt roles were not actually certified yet. Their personal goal for the 2 years rotation was to attain their certification such that they could move on to become a “Lean Leader” or similar roles elsewhere.
Imagine the distortions in behaviour you’d see if the primary motivation for the person leading your major process improvement program was to complete 2 projects in 2 years in order to attain certification.
I personally experienced one particularly bad instance toward the end of a project at my site where a team of unqualified Black Belts were parachuted in to “fix” our out of control defect backlog. On the whole, these people were not experts – but they knew how to work the system.
In this particular case; toward the end of the project when it became clear their original quality target was not physically achievable they actually moved the goalposts.
Rather than a defect fix being declared “done” when shipped and accepted by a customer, “done” was redefined to mean “code complete”. They fast-tracked nearly a thousand bug fixes in 6 months through engineering (and our outsourced partner) with no capacity for test and release resulting in significantly more code churn than our customers were willing to tolerate in the same time frame. The development teams couldn’t actually ship the fixes to customers and at the end of the project, the Black Belt team were hailed as heroes for “fixing” the problem and process.
Statistically, according to their measurement system, they had!
The Irony is, the new process they introduced was great. They used a construction and manufacturing management concept known as “Line of Balance” to plan and deliver fixes according to customer “want dates”. If the team had the freedom to ship specific releases to the right customers and customers had the ability to install them it would have worked amazingly well however their analysis stopped within the building without awareness that those customers generally had many years and millions of dollars worth of product customizations meaning they were unable to take “raw” product releases any more.
They missed the critical context of our customers and users.
Anyway… I digress!
It’s worth learning how to use as many tools and techniques as you can. Understanding the powerful combinations available to you across different theories and practices allows you to combine and apply that knowledge in valuable and novel ways.
But just because you know how to use all those tools, doesn’t mean you need them all the time – choose the right tool and process for the job at hand and remember to keep things as simple as possible.