Developing a purposeful lean problem-solving system
The following excerpt is taken from the book People Solve Problems: the Power of Every Person, Every Day, Every Problem (2021: Old Dutch Group), the latest book by Jamie Flinchbaugh, an IndustryWeek contributor on the topic of lean leadership.
Often, managers at all levels operate during the lean journey in the same way they did before, merely adding a few lean expressions for effect. They may ask someone to do an A3 and feel they are doing their part in the journey. But a manager has responsibilities in the journey that go beyond using the right words and supporting the journey with resources. To begin with, they must be the architects of the work system that drives effective problem solving.
What does it mean to be the architect of the system? It means taking responsibility for and ownership of the work systems that expose problems, capture them, manage them, direct resources to them and, ultimately, solve them. Sending people to problem-solving training may fall into this category, but that is the easiest step and is far from enough to build an organization that is effective at solving problems.
Some of the key elements can or should be organizational standards. But someone needs to define those standards, and senior management must be highly involved in that process. How much to standardize across the organization is a question that deserves debate and depends on the organization, the existing culture, the change strategy and the level of maturity.
However, even if you have a strong inclination toward organizational standardization, there is still a lot of work to be done by each director or manager for their own team's work. The standards for this work are rarely more than guidelines, perhaps with a few IT tools added. The reason for this is that all problem solving is contextual, and you must shape your systems according to the nature and content of your work.
The Problem Map
We begin with what I like to call the 'problem map'. There are many sources of problems and many ways to find them. However, most teams end up deciding which problem to solve next in a fairly random way, without considering the whole map. Consider these various sources:
You probably have key metrics, or Key Performance Indicators (Key Performance Indicators - KPIs), that you monitor. When properly designed, they should have a clear definition of when things are normal and when they are abnormal. When a key metric reaches an abnormal level, problem solving can be triggered.
You may have standardized work that helps your team carry out tasks consistently. However, sometimes a problem arises and the standard cannot be followed or stops working as planned. That condition can drive problem solving.
You conduct audits of the work, which can range from a simple 5S audit to a more complex customer process audit. These audits usually generate findings, and each of them can be defined as a problem.
You develop a culture of identifying waste using the lens of the seven wastes and take walks through the gemba looking for waste in the process. Each waste found is a problem that can be solved.
You miss a delivery to a customer, whether internal or external. They ask what will be done about it, which means you have a problem that needs to be solved and reported back to that customer.
Your team is frustrated with something, and it is a recurring topic of conversation and an obstacle for the team. They would like the problem to be solved.
And there are more sources of problems. The challenge is: if each source of potential problems is managed, and the problems to be tackled are selected, independently, you will not have a strategy for defining which problems should really be solved. The simplest way to manage your 'problem map' strategically is to have a single list of problems, regardless of where they were found. As a leader, you need to be aware of all the sources of problem identification and have a work system to analyze them in a balanced and intentional way. You need a systematic approach to managing your 'problem map'. Otherwise, your team will react to every new problem that shows up in the inbox, which will give you very little control over your improvement path.
The Andon or Help Chain
A central element of your system is how you make help available for any problem as it occurs. Andon is a Japanese word meaning 'lantern', which relates to our situation as a light signal indicating that there is a problem. If you prefer more descriptive terms, I like to call it the 'help chain', because it is what connects help to the occurrence of the problem. Although not every problem on your 'problem map' will receive a systematic solution, all of them should receive attention.
To do this, you must define all five of these elements specifically for the context in which you work. First, you need to define which problems should be escalated and which should not. For example, if your process takes five to six days, is that a problem or just normal variation in the work? More importantly, if I think you have a problem at four days and you only consider it a problem at seven days, there will be a lot of frustration between us. We must share the same definition of what a problem is.
Next, you need a way to identify the problem. This is one of the reasons why, in a lean environment, we strive to make work as visual as possible, making problems easier to detect. Again, this is extremely specific to the nature of the work and must be worked out at the local level.
Third, you need a method for escalating the problem. What is the way, ideally a single one, to bring the problem to the surface? The term 'andon' comes from the original creation of this approach in a manufacturing environment at Toyota, where a light would turn on and music would play. A pilot declaring 'Mayday' is a code word that performs the same function, as is an error message that pops up on your computer. There are many ways to create a signal, but it must be simple, timely and very clear. These three elements make up the request for help.
The next two elements make up the response to that request for help. We need to determine who the right person to respond is. It is often assumed to be the immediate manager, but that is only true if they can provide the help needed. Make sure the appropriate resource is connected, whether to guide or to solve the problem. And finally, how and when do they respond? This should be standardized so that the other end of the 'help chain' is not left wondering whether, when and in what form that help will arrive.
Managing and Prioritizing Problems
Whether you are managing ten problems or a hundred, you need some method to ensure they are captured and being worked on. If they are lost in an e-mail thread from five days ago or scribbled in the margin of someone's notebook, that is not a very reliable or transparent system. You may decide to have a single team list that is easy for everyone to monitor, but, again, the details must fit your needs and your team's work environment.
There are a few elements that are important to include. Ownership of the problem must be clear. A team cannot own a problem, because when it gets stuck, whom do I turn to for an explanation? Even if the person responsible is doing only a small part of the work, there must be someone clearly responsible for moving the problem forward.
The progress made is also important to understand. It is easy for problems to stall, but they need to be pushed through, regardless of the barriers holding them back. All of this should be transparent. Knowing what is being worked on and what is not is not only useful within the team, but also useful for those in higher positions in the organization, as well as for your internal customers and suppliers.
Within this system, prioritization is also important. If your team is very efficient both at solving problems and at keeping them small, then the 'first in, first out' system is great and simple. You manage the intake of problems and, once you start working on them, you push them through to the end without interruption.
However, if your problems are very large or your capacity to solve them is very small, they tend to drag on. In that case, you need to dynamically prioritize the set of problems being worked on. I suggest focusing on prioritizing what needs to be finished rather than what should be started. It is easy to start new problems, but what needs to be completed? Finishing means obtaining the performance-related benefits, as well as the learning and the sense of accomplishment. The latter are the fuel for solving the next problem. Focus on finishing problems.
Build Capacity and Capability (Competence)
No matter how well developed your problem management system is, it will only work as well as your team's capacity and competence to solve problems. As a leader, it is your responsibility to develop both. Competence is relatively simple: who is trained? Who is practicing? Who is at which level of competence? The most important thing you must determine is where everyone will seek coaching help. Coaching is the main source of development of problem-solving capability.
Perhaps the coach is someone on your team. They will face the same challenge. When you say, 'Lisa will be our coach', then whatever method you use to manage the team's workload must take that into account. Coaching cannot stop just because Lisa has a busy month ahead.
Developing capacity is a bit more complicated. Over time, as we solve more problems, our work becomes more stable and we end up with greater capacity. But today we still need to 'carve out' or 'create' time for problem solving. This is much easier to do at the team or organizational level than at the individual level.
Developing capacity starts with properly valuing the time spent on problem solving relative to other tasks. The work is never completely finished before everyone goes home at the end of the day. So some things get done and others do not. How do you decide? Based on what you value! If you value preparing PowerPoint presentations and attending every meeting more than solving problems, that is the work that will get done, and problem solving will have to wait. As a leader, you must first decide, and then communicate, how much problem solving is valued.
Next, you must develop a system that ensures the work gets done. If you look at your employees' calendars and find five review meetings with you but no time set aside for problem solving, that sends a clear message about what is important. The easiest way to signal importance is to commit the team's time. This can be done by setting aside an hour a day, an afternoon, or some form of clear commitment to capacity. How do your decisions signal what you value?
We all work as part of a system. As a leader, you are responsible for ensuring that this work system executes the right things. Your role is to be the architect and to design your system with purpose.
Founder of JFlinch, Jamie Flinchbaugh has helped purpose-driven leaders build effective and resilient organizations at more than 300 companies. Jamie has supported leaders across a wide variety of industries, including healthcare, utilities, technology, consumer products and professional services, among them Harley-Davidson, Intel, Mars, Amazon, Crayola, Fidelity and Whirlpool, among many others.
