I’ve recently been involved in a discussion on LinkedIn related to research on why process improvement initiatives such as lean Six Sigma (LSS) fail, and one of the top reasons suggested by the research is a lack of leadership support. This conclusion doesn’t surprise me, probably you either, because almost every study I’ve read on this topic tends to suggest leadership as one of the reasons for failure and / or success.
I commented in the discussion that leadership support is no doubt critical to success, but argued there is a deeper cause to why leadership is not supporting, or better yet moving from support to being fully engaged, in process improvement – poor project selection.
My argument is that one reason for a lack of support and engagement by leaders is directly linked to what I would argue is thee most important element of success – great projects! LSS is no different than any other initiative in that if it yields results that are tied to what leaders care about they will be engaged. One of the key elements of selecting a “great” project is being able to link it to dollars; something leadership cares deeply about.
Talk in a language leaders understand.
While I’m in agreement there is some value in having a “language” for what we do in the LSS profession, I’m finding myself becoming less of a proponent for a lot of the lingo we use (i.e. kaizen, jidoka, gemba, etc.). If you want to get someone engaged in an effort such as LSS it’s unlikely you will do so by using confusing language, acronyms, etc.
Most of us tend to run away and not toward what we don’t understand (i.e. increased work complexity). I have yet to find anyone to tell me they are looking for ways to increase the complexity of their work life, which for many is exactly what LSS does, if we are not careful in how we use it!
I’d love to see the day we put all the lingo away and just talk in terms business leaders understand, but until that day perhaps we can start with the concept of cost of poor quality (COPQ).
This has long been a pet peeve of mine in that COPQ is just too confusing, and from my experience most leaders tend to think of COPQ in terms of defects and manufacturing, which in some cases it is, but more and more as LSS moves into the transactional world it’s becoming less about what most of us typically think of when we hear the word defect.
If you want to talk to business leaders about COPQ I suggest simply describing this concept as your “business case” for doing a project. This is a language all leaders understand. Can we make a business case? What’s the business case? How do we establish the business case? These are all questions, if you’ve been working in the business world for more than a few years, you will no doubt have heard on numerous occasions.
7 questions for building your business case.
1. What’s the problem?
I’ve written previously on developing a good problem statement, and this is where it all begins. You have to know what it is you are trying to improve before you can start to put together a business case.
2. How will the problem be measured before and after improvements have been implemented?
To determine the size of your problem you need to measure it. I’ve written on how to measure your problem previously. This is a critical step in the process that will later be used to turn process performance into financial performance so take the time to determine how the problem can be quantified.
3. What is the goal?
How you establish your project goal needs to be objective. If you aim at nothing you’re bound to hit it, and that’s exactly what you do when making subjective goals such as “getting better” or “streamlining” a process.
One of the simplest, but yet very effective, ways of establishing your project goal is simply determining where you want your primary metric (answer to question #2) to end up when you finish the project.
4. What will happen or stop happening when the goal is achieved?
This is a step / question that often gets overlooked in this process. Often times when I work with a client they jump straight to the dollars, which if you can do so is great, but most often it’s not a straightforward approach such as counting up the defective widgets we currently get from the process and converting each bad widget to a dollar amount.
Much of the frustration is because this step in the process is skipped, and teams struggle to create a “formula” to turn the problem into dollars. Most of us tend to think in actions, behaviors, etc., and not in formulas and logic when it comes to change.
Instead, I like to brainstorm with teams using post-its and / or a white board by asking two simple questions, a) “What good things will happen when the goal is achieved?”, and / or b) “What bad things will happen less when the goal is achieved?”. These two questions will lead to variety of ideas that feed into question five.
5. What do the words equate to in dollars?
This is where “rubber meets the road” and we start to get into some “real” dollars. With the list from question #4 you can start to ask who is doing what was described, how frequently are they doing it, and how long does it take them to do it as a good starting point.
Who is doing the work will give some insight into the cost per hour for those involved in the problem. How frequently they are doing it will provide a measure of how big the problem is, and how long it takes to fix, rework, etc. the issue provides the last piece of the puzzle to estimating the business case.
6. How can the dollars be counted?
This question gets at describing the process by which we could validate the estimated business case. The question will also lay out the approach the team will use to get the actual data to make the business case and also to count the real money once you enter into the control phase at the end of the project.
Don’t overlook this question because I often see teams get eager about solving a problem only to find out it takes more effort than it’s worth to compile the data, and without the data it will be hard to convince management a real financial impact actually took place.
7. Who will validate the method by which the dollars will be counted?
A final question to consider is how the dollars will be validated. Most businesses I work with have someone independant to the project and LSS process review the financial data to validate the dollars. Having an outsider who has less chance of being biased in the calculations will give greater credibility that the savings are legitamate.
One final consideration is to have the process by which the estimated dollars were estimated validated before getting out of the measure phase. The last thing you want to happen is believe your project has saved millions only to find out the approach your team took wasn’t accurate in capturing the financial costs. Get finance involved earlier rather than later!
Shifting from support to engagement.
I would argue there is no better way to sustain a LSS effort than to help your organization’s leadership look like rock stars, which means getting at the heart of what matters to them and then using LSS where it makes sense to help them achieve what matters to them.
This truly is the holy grail of getting leadership to move from an attitude of “support”, which is just another way of saying, “I’m here if you need my help, but I have other more important things to focus on”, to an attitude of engagement, which means, “Wow, this stuff really worked in helping me accomplish what matters to me….I want more of this!”.
When you’ve reached a tipping point you’ll know it becasue instead of you going to your leaders and asking for project ideas they will instead be coming to you asking for your help in accomplishing their goals! This won’t happen overnight, but it’s more likely to happen if you focus on talking in a language they understand, and solving the problems that matter most to them.