Designing a Lean Problem-Solving System with Purpose

Some of the key elements could, or should, be organizational standards. But someone needs to set these standards, and senior management should be highly engaged in this process. How much to standardize across an organization is worthy of some debate and depends on the organization, the existing culture, the change strategy and the level of maturity.

However, even if you adopt a strong bias toward organizational standardization, there is still much work to be done by each director or manager for their own team’s work. Standards for this work are rarely much more than guidelines, perhaps with a few IT tools thrown in. The reason for this is that all problem-solving is contextual, and you must shape your systems for the nature and content of your work.

The Landscape of Problems

We begin with what I like to call the landscape of problems. There are many sources of problems and many sources of finding those problems. Yet most teams end up deciding what problem to engage with next rather randomly, without respect to the entire landscape. Consider these many sources:

You probably have key metrics, or Key Performance Indicators, 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 hits an abnormal level, problem solving could be initiated.

You may have standard work that helps you consistently perform your team’s tasks. However, sometimes there is a problem and the standard cannot be followed or ceases to work as designed. This condition could drive problem-solving.

You do audits of the work, ranging from a simple 5S audit to a complex customer process audit. These audits generally produce findings, each of which can be defined as a problem.

You develop a culture of identifying waste using the lens of the seven wastes and perform waste walks of the process. Each waste occurrence found is a problem that could be solved. 

You fail to meet a deliverable to a customer, internal or external. You are asked 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 persistent topic of conversation and drag on the team. They would like the problem fixed.

And there are more sources of problems. Here is the challenge: if each source of potential problems is managed and reacted to independently, you have no strategy for what problems you really should be solving. The simplest way to manage your landscape of problems  strategically is to have a single list of problems regardless of where the problem is found, but a single list does not have to be your solution. As a leader, you must have an awareness of all the sources of problem identification and a system of work for examining and engaging   with them in a balanced and purposeful way. You must have a systematic approach to managing your problem landscape. Otherwise, your team will react to each next problem that pops up in their inbox, which gives you extraordinarily little control of managing your improvement path.

The Andon, or Help Chain

A core element of your system is how you connect help to any problem as it occurs. Andon is a Japanese word meaning “lantern,” which relates to our situation as a signal light to indicate that there is a problem. If you prefer words that are more descriptive for your use, I like to call this the help chain because it is what connects help to the problem occurrence. While not every problem in your problem landscape will receive systematic problem-solving, every problem should receive attention.

To do this, you must define all of these five elements that are context-specific to the environment in which you work. First, you must define those problems that should be escalated and those that should not. For example, if your process takes five to six days, is that a problem or just natural variation of your work? More importantly, if I think you have a problem at four days and you don’t think it is a problem until you reach seven days, then in between those two markers, we are going to have plenty of frustrating tension. We should have the same definition of what is a problem.

Next, you need a way to notice the problem. This is one of the reasons that, in a lean environment, we strive to make the work as visual as possible so it is easier to detect the problem. Again, this is extremely specific to the nature of the work and must be solved at a local level.

Third, you need a method to escalate the problem. What is the one, and ideally only, way to surface that problem? The reason for the term “andon” is that the original creation of this approach was in a manufacturing environment at Toyota where a light would turn on and music would play. But a pilot declaring “Mayday” is a code word that accomplishes the same task, as is an error message popping up on your computer. There are many ways to create a signal, but it should 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. We must determine who is the right person to respond. This is often assumed to be the immediate manager, but this is the case only if they are able to provide the necessary help. Make sure the right resource is connected, either to coach or to solve. And finally, how do they respond, and just as importantly, when do they respond? This should be standardized so the other end of that help chain is not wondering whether, when, and in what form that help is going to arrive.

Managing and Prioritizing the Problems

Whether you are managing 10 problems or a hundred, you need some method to ensure they are captured and being worked on. If they exist somewhere in an email thread from five days ago or scrib- bled in the margin of someone’s notebook, that is not a very reliable or transparent system. You may determine you want a single team list that is easy for everyone to monitor, but again, the details should fit your needs and your team’s work environment.

There are a couple of elements that are important to include. Ownership of the problem should be clear. A team cannot own a problem, because when it stalls, who do I look to for an explanation? Even if the person who owns it is doing only a small portion of the work, there has to be a person clearly accountable for pushing the problem forward.

Progress made is also important to understand. It is easy for problems to stall, but they must be pushed through whatever barriers were holding them back. All of this should be transparent. Knowing what is being worked on, and what is not, is not only useful inside the team, but it is also useful to those higher up the organizational chart and out to your internal customers and suppliers.

Within that system, prioritization is also important. If your team is very proficient at both solving problems and keeping them small, then first in, first out is a great and simple system. You manage the inbound on the problem landscape, and then once you start them, you push through to the end without interruption.

However, if your problems are too large or your capacity to solve them is too small, problems tend to linger. Then you need to dynamically prioritize the set of problems being worked on. I suggest focusing on prioritizing what to finish rather than what to start. It is easy to start new problems, but what needs to get finished? Getting finished means you are able to realize the performance benefits but also the learning and the sense of accomplishment. The latter two are the fuel that allows you to get the next problem done as well. Focus on getting problems finished.

Build Capacity and Capability

No matter how well-developed your system for managing problems, it will perform only as well as your team’s capacity and capability to solve problems. As a leader, it is your responsibility to build both. Capability is relatively straightforward. Who is trained? Who is practicing? Who is at what level of competence? The most important aspect that you must determine is where everyone will go for coaching help. Coaching is the main lifeblood of problem-solving capability. Everyone in your organization should be, ideally, one step removed from a coach. Maybe you, as the leader, are going to act as the coach. Are you prepared for that? Will you make yourself available on their terms and not your terms? It is usually not the willingness to coach, but the willingness to design your own work around being available to be a coach that is the bigger challenge.

Maybe the coach is someone within your team. They will have the same challenge. When you say, “Lisa will be our coach,” then through whatever means you manage your team’s workload, that must be taken into account. Coaching cannot stop just because Lisa has a busy month ahead.

Capacity is a bit trickier. Over time, as we solve more problems, our work becomes more stable, and we end up with greater capacity. But today, we still must “carve out” or “make” time for problem solving. This is much easier to do at the team or organizational level than at the individual level.

Building capacity begins with properly valuing time spent in problem-solving relative to other work. The work never all gets done before everyone goes home at the end of the day. Therefore, some stuff gets done and other work does not. How do you decide? Based on what you value! If you value polishing PowerPoint and attending every meeting you are invited to more than you value problem-solving, then that is the work that will get done and problem-solving will have to wait. As the leader, you have to first decide, and then communicate, how much problem-solving is valued.

Then you must develop a system that ensures the work gets done. If you look at your employees’ calendars and they have five review meeting notices from you but nothing carved out for problem solving, it sends a pretty clear signal of what is important. The easiest way to signal the importance is to commit the team’s time. This could be done by blocking off an hour a day, or an afternoon, or some form of clear capacity commitment. It is your system of work and your system of priorities. How will your decisions signal what you value? How will you design your team’s system to drive the priority?

We all work as part of a system. As a leader, you are responsible for this system of work getting the right things done. Your role is to be an architect and design your system with purpose.

The founder of JFlinch, Jamie Flinchbaugh has helped purpose-driven leaders craft effective, resilient organizations at over 300 companies. Jamie has helped leaders across a wide spectrum of industries including healthcare, utilities, technology, consumer products, and professional services, including Harley-Davidson, Intel, Mars, Amazon, Crayola, Fidelity, Whirlpool, among many others.