Category Archives: Problem Solving
In a previous post, I talked about learning a software package that allows people to model and simulate a factory before making any physical changes. After the building of the factory that failed to implement pull, my role was to model current production lines when changes were recommended and to model the proposed model lines for new products.
One of the new production lines that I modeled was for a new television technology. The Liquid Crystal on Silicone (LCoS) television sets. This technology was about a year ahead of LCD TVs and was cheaper to produce. It was only 18 inches deep which is laughable now but at the time was about half as deep as typical big scree projection TVs.
The manufacturing engineers came up with a design for the new production line. By all means, it looked like a line that would meet the production needs and on paper the number of stations and equipment needed looked perfect.
The model was built and simulated with actual unit testing data as well as workstation operation times. It was a great thing we did, because we could have had another fiasco if we didn’t.
The simulation showed the back of the line being severely starved and the front of the line being overwhelmed. The line would have produced at only 66% of the rate it needed to run. The animation of the simulation showed how many TV sets were being kicked out into the rework loop and the backup it caused. It was a perfect example of the Markov Chain in real-life.
We were able to redesign the production line to be 33% shorter and have the ability to produce at a rate high enough to meet demand and allow for growth with no investment.
This was a great example of fail fast, fail cheap. It took less than a month to build the simulation, test, analyze, rework and get approved. The company saved thousands of dollars and the product went to market on time.
I know simulation software packages aren’t cheap, but it was cheaper than building the production line seeing the failure in real-life and then scrambling to fix it or build a second line.
How does your company fail fast, fail cheap?
- The value of prototyping and understanding before going full out is ALWAYS understated
- Simulating with cardboard boxes to computer software is an important part of making changes, especially big changes.
- Always better to fail early on with something that doesn’t cost much vs. finding the failure in full production mode. Doesn’t matter if it is a new marketing idea (test in an area) or manufacturing.
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.
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.
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 regular reader of Beyond Lean, you may know that my wife has her own small business. It is just her and I. She runs the business 24/7 and I help where I can on nights and weekends.
Both of us have learned about a wide range of business aspects over the last couple of years from her small business. My wife has a background in marketing, but has learned a lot about IT and web design, materials, costing, production of a consistent product, using data to determine what the customers like and a lot more.
I have been working quite a bit with display booth setup and teardown (quick changeovers), preparing raw materials for usage and investment decisions.
When owning and running a small business a person can see everything from end-to-end. How a packaging decision can affect sales? How does shelf life of a product have an effect on the quality? How do certain ingredients react when mixing for production? Do they cause immediate quality issues? Do they cause quality issues over time?
In our experience, we have seen how lean thinking can be more natural for a small business. There is more of a concern about inventory and cash on hand, so there are many decisions that go into building to stock or building to order. Using visual management to make things easier to see when work needs to be done or not. I have some examples from my wife’s business that I will post at a later date as well as examples I have posted in the past.
I have learned numerous things from working with my wife in her small business that I carry on to my other job as lessons to apply.
Owning a small business is very hard work. You have to learn about things that don’t necessarily interest you, but if you want to be successful you have to get it done. In the end, it can be very rewarding and extremely educational.
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.
H&H Color Lab began in the basement of Wayne and Shirley Haub’s residence in a suburb of Kansas City, Missouri, in 1970. Wayne and his brother, Ted Haub, owned a portrait studio that had just landed its first high school senior contract. With a background in and love for color printing, Wayne chose to install his own color processing equipment in the basement of his home.
Business increased, and so did the need for additional space and employees. What began with Wayne doing everything from his basement has grown to 165 people and 55,000 square feet of space over 40 years later.
H&H customers are primarily school/portrait/wedding photographers. The offer a wide range of products from photo prints to books to Leather bound albums and digital products.
In 1999, H&H Color Lab started is Lean journey led by Lee Gabbert. Lee had been with the company for 5 years at the time and was chosen to learn more about lean and teach others at H&H. They started by reading “Lean Thinking” by James Womack and Daniel Jones. H&H also decided to get a sensei to help them learn as they traveled the bumpy road down the lean path.
H&H Color Lab started by setting up work cells, going away from a department mentality. H&H moved to smaller batches, moving cells closer to the monuments (that they couldn’t move), standard work, and lots and lots of 5S.
Muda (waste), lead times, late work and quality all had improved. In fact, the gains from lean had now freed up space that was once occupied by manufacturing departments. It allowed H&H to take the space and use it as a training facility to help customers from all over the United States. Thus, H&H University was born. Roughly 3,000 square feet of space was now designed and transformed into a learning center, working photographic studio with equipment, mock up photography sales room, photography studio work area, kitchen to host all day training, library sitting room with sample products that H&H produce on the book shelves and restrooms. By providing training for customers (mostly free of charge), you truly can engage in a partnership that can grow.
All of this work allowed H&H Color Lab to make a success transition from the “Age of Film” to the “Digital Age”. Understanding their customers and providing training and education others companies do not, shows how the most important part of lean, focusing on the customer, helps you innovate, grow and thrive.
Here are results that H&H Color Lab have seen from their lean implementation.
|% Shipped Late||
|Time in Plant||
I received this picture from a guy I worked with and coached for a couple of years. I am sharing this with his permission
(click on image to enlarge)
He and his wife would go to the store and if there was a sale, they would buy meat. They never knew what they had at home. When they got home from a recent trip they had bought meat they had plenty of…again. So my friend decided to get visual. He sorted out the meat that had gone bad and then created this visual board to better understand when he needed to buy a particular type of meat. He likes to barbeque so he keeps a variety of meat on hand.
The board is simple. Conveys one type of information. And anyone can understand it by looking at it.
What visual management have you used at home?