Last week, I mentioned that I would talk more about the lean forum I attended. The theme of the forum was leading lean. Several speakers presented and they all did a fantastic job. One of the speakers was Jamie Flinchbaugh of the Lean Learning Center. Jamie outlined five leadership moves that demonstrate lean leadership.
- Build Tension, Not Stress
- Eliminate Both Fear and Comfort
- Actively Engage, Don’t Just Delegate
- Apply Lean to Your Work
Over the next few posts, I thought I would share the message and how I personally have exhibited the behavior positively and negatively, because we all must learn from our mistakes.
Build Tension, Not Stress
Tension is what compels an organization to take action. Tension will cause the organization to improve. Stress is what causes the organization to freeze because it doesn’t know what to do. The stress will cause the organization to break.
There are two components top create tension. The first is current reality. We must fully understand current reality and more importantly be very honest about what is current reality.
The second component is having a definition of the ideal state. What does perfection look like? Not what is best practice or best-in-class, but what is perfection.
This gap greats tension to move the organization forward.
I have always been a harsh critic of my own work and where I believe an organization stands. Sometimes to a point where I have offended others in the organization because they believe we are better than my assessment. I have even been called negative because I don’t see the current reality as ever good enough.
Where I have struggled in the past was defining the ideal state. I didn’t always do this. I would define a future state which is somewhere between current reality and the ideal state. This led to teams not improving as much as they could have. The team may have gotten a 20% improvement but we could have gotten more if we would have defined the ideal state and stretched ourselves.
By building a future state and not an ideal state or by believing you are better than you are, you take all the tension out of the organization. The loss of tension creates an culture of no action.
What are you doing to build tension in your organization?
The other day I was catching up on reading some blogs. I came across one on the Harvard Review Blog titled “Seven Questions to Ask Your Data Geek.”
The title drew me in because I can be a data geek myself sometimes.
The seven questions caught my eye very quickly. When you read them you can see they are related to what good problem solvers with lean thinking ask.
- What problem are you trying to solve? You want to be sure there is a problem to solve and not just a band aide or a just going and implementing something the customer wants. You want to truly understand what is needed. This is the first question to ask because it helps to define the problem.
- Do you have a deep understanding of what the data really means? Read between the lines and it says to get off your rump and go and see what is really happening. The data is a good directional start, but how are people gathering the data? How are people using the data? The person needs to understand what is really happening.
- Should we trust the data? Now that you have gone out and seen how the data is really gathered, can we use the data to help with the problem we are trying to solve? Do we need to gather different data to better understand the problem?
- Are there “big factors”, preconceived notions, hidden assumptions or conflicting data that could compromise your analysis? This is still getting at drilling deeper and understanding the current state for the data. During the problem solving process you should be spending about 75% of the time just understanding what is really going on before looking for solutions. As you can see the first four questions are about understanding the current state.
- Will your conclusions standup to the scrutiny of our markets, moderately changing conditions, and a “worst-case scenario?” Now that you have deeper understood the current state, you start looking for solutions. Will the solution hold up? Are you getting to the true root cause of the problem? Will the problem be eliminated?
- Who will be impacted and how? Now that you understand the problem and have a solution you need to know how this will affect the business. Change management should always be a piece of the problem solving process, because changes always affect people. Sometimes they embrace the change it if helps them a lot. Sometimes they don’t embrace the change, so always be aware.
- What can I do to help? Always be willing to help fix the problem. Don’t always leave it to someone else.
These are seven great questions to ask anyone when problem solving, not just your data geek.
Kaizen events are multi-day improvement activities aimed at creating change to a process. During the event, the improvement team understands the current state, defines an ideal state and then develops a plan to create change headed in the direction of the ideal state.
Sounds simple enough, right?
Most teams don’t have any trouble discussing the ideal state. The team can state the ideal state of a process but don’t necessarily believe they will get there anytime soon.
The hard part comes when discussing how the improvements they can make happen will change the process. Too many times I have seen groups scale back the improvement ideas. They try to just change a few things within the current process. The team has a hard time making bigger changes, even if it is just a recommendation. In organizations where lean is not prevalent and traditional management behaviors have created silos and squashed improvement ideas from the employees, the employees do not believe the bigger changes they want will be put into action.
There can be time during the event spent convincing the team it is the right thing to recommend the bigger changes even if they think the leadership will not accept the changes. It is about painting a picture. The team has to walk the leadership through the current state and have them understand where they are. Then paint a vivid picture of the ideal state. More times than not I have seen the intermediate future state accepted by leadership when a vivid picture is painted and current and future state maps are made to make the process come alive.
Improvement teams cannot be afraid to recommend what they believe is truly the best option. If the team feels strongly the leadership will not like it, then there is nothing wrong with having a Plan B. But, never start with Plan B until you have tried everything to get Plan A bough into.
Joe Wilson has worked in a variety of continuous improvement, problem solving and engineering roles in manufacturing and distribution functions in the automotive, electronics, and food/grocery industries. He was responsible for site leadership of Lean implementation during the launch and ramp up of becoming a supplier to Toyota and was able to work directly with their personnel and the Toyota Supplier Support Center. His training background includes courses in Lean/TPS through TSSC and the University of Kentucky’s Lean Systems program. He is a Six Sigma Black Belt and a Shainin Red X Journeyman in addition to training in Kepner-Tregoe problem solving techniques. Joe also has a BS degree in Engineering Management from the University of Missouri-Rolla.
Lean teachers have taught us things like “go see”, “ask why”, and “thoroughly understand what is happening at the gemba”. Enough practice with these mindsets can teach you how to quickly and effectively evaluate current states and identify where our gaps may exist on the way to our ideal state.
If you are like me, you probably really enjoy touring other people’s operations or even watching shows like “Ultimate Factories” or “How It’s Made” on TV to see how other people do what they do. You’ve also probably tried to copy an idea or two that you’ve seen doing one of those things. I know I’ve tried several tips, tricks, or notions that I’ve picked up through these observations. Some have been fantastic. Some have been total, immediate failures. And some others may not have worked right off the bat, but have triggered discussions that have led to some really great solutions. Those types of activities aren’t really what I think of when I picture benchmarking. I would put those in the same group as reading a book or taking a class and applying an idea from one of those. Great places to get a seed to plant or to identify rough milestones, but you shouldn’t really be finding blueprints in them.
The danger in a benchmarking mindset from some circles comes from looking at similar processes or industry data and working in a “We should do it just like they do” mindset. Don’t get me wrong, it is extremely valuable to have an understanding of where the competition is or where the bar is set at. One of my favorite examples of this in lean lore is how, in the early days, Toyota believed that German manufacturing was 3 times as productive as Japanese manufacturing and the Americans were 3 times as productive as the Germans. Toyota then determined they had to become 10 times better than they currently were to be better than the best manufacturers and compete on a global scale. This scale wasn’t used as an excuse to copy American manufacturing, it was used as a line in the sand to set a goal.
Another mantra that I continually remind myself of comes from statistics/data analysis guru Dr. Donald Wheeler who says “No statistic has any meaning apart from the context for the original data.” All of our observations or industry data studies or side by side comparisons of plants only work if we can phrase them in terms of the context. If they lack context or we don’t understand the context well enough, we may not get any valuable information from which to build. In the wrong hands, this can lead to a tremendous waste of time and resources to try to be like someone else. I don’t think that’s why we do what we do as Lean thinkers. Our greatest abilities as lean leaders don’t lie with our ability to recognize and copy someone else’s answers. Our greatest strengths come from our ability to thoroughly understand our own states and solve our own problems.
One of the most common tools used in lean is a Value Stream Map (VSM). During this process a team draws out the current state using certain mapping techniques. The second step is to draw out a future or ideal state map, then add improvement ideas to the current state that would help to get to the future state.
What if part of the future state is given to the team ahead of time? An example might be, the lead time must be X. What if you suspect the team will shoot for the target exactly, saving anything extra for the next year because they know they will have to keep improving?
I have found drawing the future state can impede stretching the limits of improvement. When I suspect this to be the case, I have the team ‘empty their pockets’ of all their improvement ideas. I do this after the current state map but before the future state map.
I then take the team through a vetting exercise. What would be the benefits? The hurdles? What kind of resources would be needed? Then as a team we decide on the top ideas to implement.
The next step is to draw the future state map showing all the benefits of the top improvement ideas. Did we reach the goal given to us? Or exceed it? If so, we are done. If we fell short then we go back to the ideas not selected and pick more to add to the future state map. So far, in every case the future state map has shown bigger improvements than the targets that were set. Now the team has a little wiggle room for error and still hit the target.
Like every lean tool, we have to think about the purpose of the tool and our situation in order to use it best.
Over the years, I have been fortunate enough to have been certified/trained in many different methods of problem solving. Some of them include Shainin Red X, Kepner-Tregoe Is/Is Not, the basics of Six Sigma and DMAIC, PDCA, SPC, and the list goes on and on. Quite frankly, I have lost track of all the problem solving methods and tools I have used.
After many years of using all of these techniques, I have boiled problem solving down to just 4 basic steps that can be used/seen with any of the methods I mentioned above.
1. Identify Current State
2. Identify Ideal State
3. Analyze the Gap between Current and Ideal States
Identify Current State: I firmly believe that you have to know where you are and what is happening before you can think about improving. I have seen people throw everything out and just do step 2 and 4. I don’t understand this, because they have almost always re-created some of the same headaches that they currently have or had in the past and then have to re-fix these issues. You have not gotten where you are because everything was bad or wrong. So what is good? What is value added? What is non-value added? How does the process work? Understand these things about your current situation and you will learn a lot about the process.
Identify Ideal State: I see some people want to identify the future state instead of the ideal state. That can work, but I prefer the further sighted ideal state. You won’t necessarily get to the ideal state by solving just this one problem, but you want to make sure you are heading in the direction of the ideal state. You don’t want to create a countermeasure to a problem that is heading in a different direction than your ideal state. Have you ever had a future state that isn’t aligned with your ideal state? Do you want to start working in one direction only to be redirected later? Define the ideal state, even if it is just bullet points, so you know that any countermeasure you put in place is directionally correct.
Analyze the Gap between Current and Ideal States: Now you must understand what it will take to get from where you are at to where you want to get. How do we close the gap? It may not fully close the gap but we are making progress towards the ideal state. Sometimes you may find that you have to do a major process redesign or a big project. Sometimes you may need to do smaller more manageable tasks to get there. It is OK to not close the entire gap in one jump. Just make progress. If you make progress and have a plan, my experience has shown that you will get a lot of understanding.
Attack!: Now it is time to implement. By implementation, I mean try out the countermeasures, verify the results, and make adjustments base on what was learned or make the new countermeasure part of the standards. Basically, the Check and Act of PDCA.
This approach can work for simple problems like needing to reduce walking in a process.
1. Identify Current State – I walk 10 steps between my desk and the fax machine, 20 times per day = 200 steps.
2. Identify Ideal State – I don’t want to walk at all to the fax machine
3. Analyze the Gap – 200 steps per day is the gap, I can’t get a fax machine for my desk (not in the budget), but I can move the fax machine closer but I need to talk with others to make sure I’m not making more work on them.
4. Attack – Others are OK with me moving the fax machine. I move it. I am now walking 5 steps per trip, 20 times per day = 100 steps. 50% reduction. That is the new standard now.
It also works for complex problems like creating single piece flow
1. Identify Current State - A common tool used here is a Value Stream Map
2. Identify Future State – Create a future state Value Stream Map
3. Analyze the Gap – What projects and kaizen events do I need to do to reach my future state. Develop an action plan.
4. Attack – Implement action plan. Reflect on results and process of implementing and make adjustments as necessary.
I know this boils it down very simply, but there is a lot of work that has to happen in each step. There are many tools/concepts that can be used to complete these steps, but remembering these four steps is a great start.