A typical response to problem solving is to contain the issue and consider getting to the root cause. From my experience, this is because people don’t know the difference between root cause and containment.
It can be easier to see in a tangible manufacturing environment.
Problem: A group of products have a broken screw that will cause the product to fail
Containment: Sort all product to find the ones with the broken screws and replace the screws.
Root Cause: Find why the screws were broken in the first place. Were the screws torqued too much? Weak screws?
Most people understand the difference when an example like the one above occurs. But in a business environment, people seem to miss this difference.
Problem: The numbers on paper say the budget is $10 million, but the manager says the budget is $6 million.
Containment: Get an answer to which budget is correct. $6 million or $10 million?
Root Cause: What caused there to be a discrepancy between the numbers on paper and what is being said?
I see a lot of answers around poor communication or people getting the containment answer and believing they got to the root cause. We should be finding a root cause to why there was a discrepancy so there isn’t another one in the future that causes delay in the process.
Just because you are able to move the process forward, does not mean you got the root cause. Take the time and find the root cause. It may take more time now, but it will save a lot of time in the future.
During some recent blog reading, I was spurred to think about a past situation when a company I worked for was buying new equipment and how WRONG this decision was.
I had been with the company for about four weeks when I heard about a capital expenditure my director had just approved to buy nine more of a patented machine. My company owned the patent. That would give us a total of 99 of these machines.
First question I asked, “Why are we buying more of these machines?”
The response was a typical one, “We they need more capacity because we are meeting the demand.”
I didn’t ask anymore questions at that point. I decided to go and see for myself. This was easy because the corporate offices we were in was part of the main manufacturing building. I had to walk about 100 yards.
During my observations I found two things:
- The overall OEE of the 90 machines was around 35-40% when it was running.
- At anytime I never saw more than 50 of the 90 machines running. This was because we never had enough people to run all the machines.
After a few hours of direct observation, it was clear there was no understanding of what was really going on.
First, attack changeovers and downtime to get the OEE of the machine up to the 75% range.
Second, why buy more machines if we can’t staff them?!
By my calculations, if the OEE was raised to the 75% range, not only would we not have to buy more machines we could get ride of about 20-25 machines we already had. That would mean our current staffing would be pretty close to what we needed.
I presented this to my new boss and the director, but by this time it was too late. The money had been cut and were pretty much crated and on the road to our facility.
This is why companies should question any new capital expenditures. Companies should be maintaining and using what they have first. The OEE should be at least 70% if not higher before considering adding more capacity through spending.
Do not make any decisions about capital expenditures until the current state is thoroughly understood. The best way to do that is to go and see for yourself.
Last week I got to spend some time with my coach, Jamie Flinchbaugh. It has been awhile since I have seen him and the time was very well spent.
He met with the entire group I work with. During that time, we talked about problem solving and how important it is to have a coach when learning good problem solving.
The quote that stuck with me was:
“Practice doesn’t make perfect. Practice makes permanent.”
He reiterated that this is why practicing with a coach is so important. Just like in sports, a player practices with a coach so he knows he is doing the right things. The same is true for problem solving and lean.
My first coach was Dennis Mouser. He spent about 3 days a week with me helping me learn a good problem solving methodology and making sure I practiced it correctly. It has been eight years since we have worked together but what he taught me is embedded in what I do when solving a problem.
Speaking from experience, a coach is an investment that everyone learning lean and problem solving should make. They will help you practice the right things so it becomes permanent.
Like so many that started learning and implementing lean in the late 1990s/early 2000s, I started applying lean principles and concepts in manufacturing. I spent nearly 15 years applying lean thinking in a manufacturing environment. I absolutely loved seeing the immediate change in material flow or the feedback from operators that someone listened to them and they were able to make things better.
It is no secret. A manufacturing environment is a tangible environment to see the improvements and get quicker feedback back on how you are applying lean thinking because of the immediate visual results.
A couple of years ago, I moved from the manufacturing environment to the office/project management environment. This was quite a change and one I looked at as a new challenge. I took it on. I have worked with product development and retail management teams. Not even thinking twice as to what I was doing…until recently.
This summer I took on the role of project manager. I am managing the deployment of technology to our retail environments. The changes are not as immediate and not as visual as a manufacturing environment. After a while, I questioned whether I was still applying lean principles to my work. Finally, I took a step back to have a serious reflection and what I discovered is my previous 15+ years have engrained the thinking and principles without realizing it.
I have been directly observing the work as activities, connections and flows by sitting with the teams developing and testing the technology. I see how the work and how the product works. I have gone to a few retail stores to see the technology being used so I can bring those observations back to the team. I also went to other retail stores using similar technology and talked with the store managers about what is working and what isn’t working for them.
The principle of systematic problem solving comes to light with using visual boards to status the project and highlight the problems that need to be worked on in the next 24-48 hrs. We are trying to surface the problems quickly, so they can be resolved. We have broken the issues down into categories to know which are the highest priority.
Systematic waste elimination comes from defining new processes that will continue once the project is launched. We are working to improve and make them as efficient as we know how today.
Each day at standup, we are establishing high agreement on what we are going to be working on and how we will go about working on it. This establishes clear ownership of the work and an expected due date.
Finally, we are learning about the product, the technology and our processes with every iteration. Getting feedback incorporated into the product as quickly as possible.
The reflection helped me understand how I am using the lean principles everyday even if it is not in a tangible manufacturing environment.
How about you? In what type of environment are you using the lean principles?
One of the fundamental differences in a lean company versus a traditional company is how they go about problem solving. In a traditional management company, problems are hidden and managers want the problem “solved” and move on. This usually leads to problems having band-aides being put into place. Later the same problem surfaces again and another band-aide is put on again.
In a lean management company, problems are looked as a way to get better and are not hidden. Managers want the root cause of the problem found so the issue doesn’t arise again.
In both traditional and lean mindsets, I do believe that managers want the issue resolved so that is never arises again. It is there behaviors that truly dictate whether a band-aide is put on the problem or if the root cause is found.
A traditional mindset manager continually asks, “Is it solved yet?” or “When will it be solved?” or something very similar. They are pushing for action to be taken without understanding anything about the problem. It is a ‘just solve it and lets move on’ mentality. Hurry up!
A lean mindset manager asks questions also, but more to get an understanding of how your process is coming along and driving to complete the next step of the process. Questions might be something like, “What have you discovered about the problem?” or “What have you learned?”. The manager understands there will be a lot of time spent in the discovery mode investigating the problem. The manager supports the process and helps the person through the process.
An example from my personal experience. I was working on an issue that had been around for 40 years. Everyday my manager asked, “When are you going to have that solved?” Finally, I said “The problem has been around for 40 years and no one has solved it. I think I get 3 months not a week.” Not the smartest thing to say to your manager but in this case it gave me some room to find the root cause, which the team did.
Later that year there was another issue that we had to work 16 hour days to solve but we followed the process and we nailed it.
After that extremely hot issue, my manager saw the benefit of following the process. He then would ask, “Where are you on that problem? Are there roadblocks I can help with?”
It really changed the environment to problem solve. In fact, the problem solving process started moving faster and he ended up getting the results he wanted faster.
The lesson was the manager’s mindset, attitude and support around problem solving creates the type of results gotten.
What is your mindset towards problem solving and supporting your employees?
During the past weekend, I end up reflecting on how I have spent some summers of the past. I don’t know why. I just did for some reason. There was one summer 17 years ago that ended sticking in my mind that I thought I would share.
I was working for a consumer electronics company that had manufacturing in the U.S. and in Mexico. One fall, I was asked to help design a new manufacturing facility to be built in Mexico and they wanted it to be a Just-In-Time facility. This was my first time hearing about JIT, so I read up on the concept. Of course, 17 years ago almost all the material was about what it was and not how it worked.
The goal was to only have 2 hours of production materials at the production lines. I made a super fancy spreadsheet that showed how much square footage was needed in each area based on line speed, shelving, component size, packaging, etc…
In July, I was approached again and asked if I would spend the month in Mexico straightening out what was going on. The JIT system wasn’t working. There wasn’t enough room for everything.
My boss and I went over the spreadsheet three times before we went on our visit and verified all the calculations and formulas. It was all fine.
When we arrived the first day, we toured the plant. We where horrified. Televisions that were designed to stack 3 high were stacked 6 or 7 high. Boxes were being crushed and leaning. They looked like they could fall at any minute. Areas that were not designed for storage were stuffed and there were approximately 100 trailers in the parking lot with materials in them.
This was a brand new facility. It had only been open about 1 or 2 months. It was a disaster.
The first thing I learned was there was no ramp up period. On a Friday, one facility was closed. The following Monday this facility was opened and expected to run at full capacity. I had never seen any company do that before or since. There is always a ramp up period.
The second thing we learned and more importantly was there had been no training on JIT, what it was or how it worked. The facility was operating under old batch-n-queue mentality causing space to quickly fill up.
My manager and I were able to get the inventory under control through some strict inventory management processes and even get a more consistent delivery of materials to the assembly lines.
In the end, the company was not ready to run any differently. It was a shame. They ended up expanding the building and continued to run in a batch-n-queue manner. I believe the facility has been closed in the last 3 or 4 years.
It was my first exposure to JIT and all that it takes to run a JIT system successfully. I call it a system because it isn’t just about space and delivering parts. It is the management mentality to reduce changeovers, run in much smaller batches and solve problems. It really showed me how everything must work together.
Does anyone else have any horror stories from trying to implement a just-in-time system?
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.
If you are a male like me you may hate shaving as much as I did. I saw it as a chore. Something that had to be done because I didn’t want a huge ZZ Top beard. Because I didn’t want to do it, I took the short cut. I used an electric razor and then used a multiple blade hand razor to get what was left. The results…lots of ingrown hairs, a super sensitive face that stung when any lotion was applied and bleeding through my neck area. Not cuts but blood seeping through almost like a scrap.
A few weeks ago, my wife talked me into going into a shave specialty shop. I spent a good 30 minutes with the sales woman. She showed me their natural shaving products and then talked about the proper process for shaving. I learned that for most men, the multi-blade hand razors are still very irritating to the skin. The best are the old school single blade razors that you screw into the handle, not the cheap disposable kind.
So what is the proper process for shaving?
- Wash your face
- Apply an essential oil to help the hairs stand up and to lubricate
- Apply shaving cream to a shaving brush in a small amount. I learned that badger hair is naturally anti-bacteria.
- Use the shaving brush to apply the shaving cream to your face
- Shave face going WITH the grain. Use short strokes and rinse.
- Apply more shaving cream with the shaving brush
- Shave face going AGAINST the grain. Use short strokes and rinse.
- Rinse face and dry
- Apply after shave balm for soothing and moisturizing
If you are like me, you are thinking, “really?! That seems like a lot and over the top.”
My wife convinced me to give it a try, so I bought the brush and the oil, shaving cream and after shave balm.
It has been a few weeks and I have to say the results are amazing. I get a much closer shave so I don’t have to shave as often. I have had zero ingrown hairs, my face is less sensitive and I don’t bleed when I shave.
You might be thinking, “Great to know, but in the world does this have to do with lean?”
The answer is…a lot.
Too often we don’t want to follow the process because it seems long, over done or a pain, so we take short cuts. We may end up getting some good results once, but that won’t be repeatable. Take the problem solving process. We may short cut investigating the current state and what the problem truly is. One time we may get a good solution in place, but other times it is patchy results at best.
As tedious as it may seem at times, we should always follow the process when we know it will give us good, sustainable results.
In an earlier post I mentioned the similarities in agile and lean from a problem solving perspective. Lean and agile are also the same when it comes to the learning cycle.
One of the principles of lean that I have learned is Create a Learning Organization through Learn-Apply-Reflect. This principle helps drive home the importance of reflection. Many people and organizations do a great job of learning something new and then trying to apply it. Where most people and organizations fail is forgetting to reflect. The reflection step is where all the learning and applying comes together to understand how what was learned can best be applied in the organization. What worked? What didn’t work? What should be kept? What should be changed?
A sign an organization is doing this well, is the reflection is planned and not a reaction because something went wrong. The reflection is part of the project plan and will is scheduled upfront with no agenda but to learn and improve.
Agile has a methodology and a term it uses for this reflection and learning. It is retrospectives.
Agile uses planned retrospectives, usually once a week, to take a time out and gather the team to understand what is working and they should continue doing. As well as what is not working and should be changed or thrown out. It takes a monumental act to cancel a retrospective. These retrospectives are ingrained in the methodology and help the agile teams continue to improve on their process and work.
This is a great of example of Lean-Apply-Reflect. The agile team takes the learnings from the week, apply them and then have a planned reflection time a week later. The agile methodology does a great job of fostering the principle of creating a learning organization.
Do you have any examples of planned reflection in your organization?
I have been learning about agile as of late. I know how agile has gotten its roots from lean thinking as it is applied to software development. It has been very interesting and fascinating to learn.
One common thread problem solving and agile have is making it important to break down the issue.
Good problem solving breaks down a large problem into smaller and very manageable problems to solve.
Agile does the same. It is important to break an epic story (or very large story) down into manageable stories that can be built and tested in 2-3 days.
This is just one similarity between lean and agile I saw as I was in my class. Seems simple but it really takes team to master to bet able to break stories and problems down to the appropriate sizes.