Should Your Lean Journey Include Certification?
This article was originally published in March 2021.
I’ve been asked to help dozens of clients with their lean certification plans at some point in my engagement. How should we design our lean certification program? This is often the question presented to me.
Before you get to design, you have to ask yourself these important questions:
- Should we utilize certification at all?
- What should we certify?
Let’s start with the second question, for a couple of reasons. First, I believe answering what you want to certify will help you explore the purpose, which is what is needed to answer the other question. Second, when people pursue certification, they often make leaps of assumptions surrounding this question. This limits their strategic options and ultimately hurts the effectiveness of their programs. There are three different “things” you can certify: individuals, capabilities, or organizations. We will examine each in sequence.
Certifying individuals
This is often the first, and only, option that people consider. Certifying individuals is relatively straightforward and needs much less sponsorship and direction than other options. It can run on autopilot, and sadly often does, as a standalone program not tied to leadership expectations or organizational strategy.
The most common example of this is the “belt” program that is common for Six Sigma and has been carried forward into what is sometimes called Lean Six Sigma. The project nature of Six Sigma fits well with this approach, with projects often employing a wide range of tools and taking months to complete. It easily integrates teaching, coaching, application, and ultimately certification. However, there is tremendous evidence that the majority of participants’ best projects was their certification project, leading us to question the value of what comes following certification. Most of the time the Lean Six Sigma programs are just Six Sigma programs with a little lean language mixed in, as evidenced by their “one large project” completion criteria, not fitting to most perspectives on lean. This points out one of the problems: the need for certification can shape the content at the risk of distorting the true learning.
A long time ago, I acted as an advisor for the creation of the Lean Certification program spearheaded by SME, and partnered with the Shingo Institute and AME. This certification would be a third party so that individuals could get certified beyond their company-specific programs. It offers three levels: Bronze, Silver, and Gold. The program launched well, but had trouble catching on. Certification of a portfolio was labor-intensive and required context. The exam needed to be achievable, and therefore the bar was low enough so as not to be truly distinguishing. Numerous companies have looked to it as a solution, but few ultimately leverage the option.
Certifying individuals is the easiest option because you generally manage them through a process. One entry point, flow through the work, and one exit. However, I see two major flaws with certifying people. First, when completed, people go back to their organizations as an island in a sea of others who are not certified, or in a sea of others also certified. In either case, they are not part of a system. Too often they flounder, directionless, and have an underwhelming impact. I’ve seen organizations with up to 20 percent of the population certified, but you would never know it from observing the culture and rate of improvement.
The second problem is that the short-stint, push-through, transactional aspect of certifying the individual does not reflect the learn-by-doing, lifelong learning journey of a true lean thinker and practitioner. This gap shapes lean to be too transactional and project-based, ensuring it doesn’t build a culture of everybody everyday lean.
Certifying capabilities
Lean involves a plethora of capabilities, and there are many ways to slice that pie. You could look at large slices of pie such as problem-solving and standardization, or get down to smaller slices of pie such as process mapping or 5 whys. This is the first thing that makes certifying capabilities a challenge: what do you certify and what do you not? How you decide to slice the pie ultimately will shape the toolset, or capabilities, that the organization utilizes. Certify these 5 tools, and not those 5, and you will have determined what people use. You are creating an explicit preference for certain tools.
When thinking about certification of capabilities, there are generally at least two levels that are important to certify. Of course the more capabilities and levels you include, the more complex your system of certification. The first level is being capable of utilizing the method, and the second level is being able to coach it for others. These are often distinct differences and it is often important to include both levels, particularly for methods such as problem-solving that are coaching intensive.
Building a scheme of certifying capabilities is a more natural fit with how an individual learns and applies through their personal lean journey. However, that also means it is harder to navigate. It doesn’t fit in a nice little box, with a time-bounded learning cycle and a clear end in sight.
Because it is usually less linear, certifying capabilities provide more opportunities to build custom plans and to integrate the learning plan with the organization’s needs. This means that the leaders of any particular group must be strategic in how lean fits their needs, and therefore how the lean capabilities fit their needs. Depending on your situation, this is either very good news or very bad news.
Certifying teams or organizations
We build lean-capable people on the way to building a lean organization. We want our team, our unit, our organization to function in a way consistent with lean principles. So…why not certify the end result? Why not certify the organization?
This requires having a clear and holistic definition of how you want to operate. You need an operating system that defines what good looks like. One of the greatest benefits of this approach is forcing you to define your operating system. This generally involves different dimensions and different levels of maturity. I prefer models that include targets to the ideal state. This essentially ensures that a perfect score is impossible so that there is always some tension driving you forward. If you only compare your team to other teams around you, then regression to the mean is more likely than a forward drive towards the ideal state.
Once you design the maturity model or assessment rubric, then you have some key design decisions to make. Should assessments be self-assessments, done by leaders and their teams, or done by resources external to the team? Outside the team doesn’t have to mean outside the company. It could be peer reviews, or internal lean resources, for example. They might offer an objective viewpoint. On the other hand, the purpose of this process is for the leader of that team to drive improvement. Do they benefit more by doing their own analysis?
Another key question is whether to keep results private or make them public? When they are public, you can create some competition between different parts of the organization. Is that a good thing driving others to improve, or a bad thing leading to manipulation and defensiveness? It depends on your underlying organizational culture and the leadership tone set around the activity. If leaders focus more on blaming their team for their gaps or accusing others as not being as good as the assessment implies, rather than learning from those doing well, the whole practice will deteriorate.
United Technologies had a program called ACE, or Achieving Competitive Excellence. Interestingly, it had both an organizational certification structure, and a capability-driven structure. There were tremendous resources invested in ACE, and they even certified their suppliers. ACE was a mixed-bag of success, but overall provided longevity of direction to the organization for leaders and gave new leaders something clear to focus on. While their models include culture, it really focused primarily on performance results and the adoption of certain tools. Local levels of commitment varied, as did the underlying culture, but the commitment from the top was unwavering. While ACE drove a minimum level of acceptable engagement for leaders, I would argue it also capped the potential, as few leaders sought to make the journey their own, going beyond the expectations laid out by the ACE process. Furthermore, the amount of resources committed to training and auditing was massive, and while results surely followed, I can only imagine what else could have been achieved investing those same resources in another direction.
Should we have certification?
Once you have gone through the previous three options of certifying people, their capabilities, or their teams and systems, then you have at least declared a desired objective of certification. You can now move on to the question of whether or not you should proceed with such a program. There are a few questions that are worth debating before deciding.
Will our company culture value certification? After investing a lot of resources into the program, what if it doesn’t get people’s attention or help shape their behavior? They may not care about certification, because they are more focused on customers and the market, or on their real problems, or their financial incentives. Just because you offer, or even mandate, a certification program does not mean that it will be well received. Make sure that it fits your specific company culture.
Is our lean journey more programmatic or more organic? There is always a balance between having a lean journey that is shaped by individual ownership and learning, versus one run as a structured program. It is usually a bit of both, and swinging the pendulum too far in either direction can be counterproductive. But where is your balance, and is it where you want to be? There is no question that having any certification will shift your lean journey towards the program-driven variety. Does that fit? Is that what you want?
What else could those resources supporting certification be doing? No matter what, both the development and the ongoing execution of such a program requires resources, and sometimes those resources are significant. Where do they come from? Who do they report to? And most importantly, what else could you do with those resources? Could you do more teaching, more coaching, or solve more problems?
What’s the right answer?
This I cannot tell you. There is likely a right answer for each organization, and even for different points in your journey. I have sometimes been simultaneously helping one organization build their certification while helping another dismantle theirs.
My most important advice is to go down this path with your eyes wide open. Once you start to certify anything, it is hard to take away or halt the momentum. Are you prepared to support this over the long haul? Like all problems in the lean journey, you must think about your own ideal state and whether this decision is moving you closer or further from it. I have no personal bias. My only bias is against uninformed or unthoughtful decisions. And so, go forth, in whatever direction is best for your organization.