Solve Problems with Definitions
Simply providing a clearer expectation of what “good enough” looks like can solve many problems we encounter. Sometimes we create problems simply because we haven’t provided a clear expectation of roles and responsibilities. Sometimes we spend ridiculous amounts of time trying to solve problems we can’t clearly communicate. Many times we have no idea if we even have a problem.
See if this scenario or conversation sounds familiar. I’ll be surprised if it does not. Imagine you are in your current role and you are invited to participate in an “improvement event.”
I’m not a big fan of “improvement events.” I believe that improvements should just happen and shouldn’t require events, but events are a very common practice.
So you are invited to participate. As an aspirant of effective communication, you decide to go talk with the event leader and find out more before giving your, “I really don’t have time for another event” response. After all, you do have more important things to do than sit through a several-day event with dubious promise of meaningful success.
You approach the event leader and ask the very reasonable question, “So, what is this event all about?”
“We are going to improve the [whatever quality assurance] process.”
“What do you mean? Improve it how?”
“Well, that’s the first thing on our meeting agenda. We are going to make a list of the problems with the process, then prioritize them and pick the most important ones to address.”
By now your alarm bells should be ringing so loud you are putting your fingers in your ears. Still, this is how many process improvement events start. Someone complains or someone in a leadership role dictates that the process needs fixing and a team is assembled and put to task.
The problem is that the entire exercise is about to be kicked off by an assumption that the process is broken. Then, the team is going to invent or otherwise brainstorm a bunch of ways in which the process might be broken. Finally, the team will try to rewrite the process to fix those things it identified.
Does this sound familiar? Have you ever participated in an event like this? I don’t know of a single veteran of process improvement that has not. Unfortunately, the whole thing may be a fabrication. It may be a meaningless exercise.
Here are some very important questions that should be answered before calling for process improvement.
- How do you know the process is broken?
- What is the failure?
- Is the process followed in the first place?
Creating an event in which you are going to identify the failures is like taking your car to the mechanic and saying, “Will you please fix my car?” Your mechanic will ask what is wrong with it, but you say, “I think it’s broken. Tear it apart and see what you can find wrong.”
You had better believe that a mechanic with any business ethics would first demand answers to the above questions before opening the hood. You wouldn’t just task a mechanic to fix our car without a compelling reason. You certainly wouldn’t dare him, at $100/labor hour, to have fun trying to find something wrong just because someone suggested that your car might not be as efficient as it could be. If he gave you a bill and said, “all fixed,” how would you know?
The next time you find yourself in one of these conversations about fixing a process in which the problem isn’t clear, offer the following exercise to put the team or the event leader back on track.
- Identify the primary output or purpose of the process.
- Determine if the process is successfully meeting that expectation.
- If not, then the purpose of the improvement is to make it meet that expectation.
At the end of that 3-step drill, your improvement team will suddenly have a real purpose and won’t need to brainstorm one. Maybe the whole thing ends with step 2 and no improvement is necessary.
In the scenario above, you were invited to participate in a potential disaster whereby an improvement team would follow a recipe of process improvement, would brainstorm some things that might be wrong, map the existing process, analyze it, use words like “muda” and measure “takt time”, make some changes to it, then deploy a new process. Unfortunately, the new process may not be any more successful than the existing one.
We have all learned a great many recipes for process improvement and a great many tools to go with them. Remember though, that recipes and tools are not there so we can use them. We don’t, typically, go fix our car just because we have a new tool.
The tools and methods are there to help us solve problems. So first, we have to have a problem.
Many times, when we think we have a problem, it’s really just a misunderstanding. In these cases we don’t need a lot of tools; we just need some clarity. We produce clarity with simple definitions.
Using the scenario above, here are a whole bunch of examples where some definition can shortcut the whole “improvement event” time, energy, and expense, and solve some very common problems. Take a good look at these and see if you aren’t surrounded by these opportunities in your own organization.
Imagine the scenario described above. A quality process is apparently not working properly because poor quality product has escaped to the customer in some recent instances. You go through the 3-step drill, instead of getting sucked into the nonsense improvement event, and come up with the following opportunities.
The purpose of the process is to identify incorrect assemblies or poor quality and prevent them from being shipped. So, the problem is that several escapes have occurred recently. Therefore, the purpose of the improvement event is to determine how poor product escaped and correct the process to prevent such in the future.
With a simple definition of the problem, the event no longer needs to spend precious time with large amounts of people complaining about everything they don’t like. An improvement event should never be triggered without first defining the problem.
A good problem definition has three parts. What is the problem? Where or when does it occur? How do you know? The answers to these three questions should consist of facts, not opinions or judgments. They should define a problem, not a solution.
The “how do you know” question is another opportunity to shortcut or solve a problem. Sometimes we don’t even know if we have a problem because we haven’t clearly defined what a good output looks like. Sometimes a simple measure or acceptance criteria is all that is required for everyone involved in the process to fulfill expectations. Solve the problem by clearly defining what are the expectations.
Sometimes a process is perceived to be problematic because it isn’t followed, or isn’t followed consistently the same way. In other words, have we clearly defined a process? If we want things done a certain way, we have to communicate or define that way.
Yes, process maps or work instructions have become our go-to solutions for defining processes, but that isn’t always necessary. If there are only three people responsible for a particular function, for example, and that function isn’t especially complicated, do those three people really need a detailed process map and set of work instructions, or do they just need to know how to produce a consistent output and how each does it is his or her own part?
Maybe we just need a digital form to fill out and we don’t need to map out a detailed process for how they procure or produce the information. Sometimes we just need some guidelines, not a whole process map. Defining guidelines and expectations for how particular calculations or estimations are conducted may be more important than drawing maps that show the step must occur. If we know what we are expected to produce, we don’t always need to waste time drawing flow charts that show that those things get produced. We just need to fill in a blank.
Let’s say that you do decide to participate in the improvement event in the scenario above, now that you have helped to define a purpose and goal for it. The team discovers that the process is already very clearly defined and carefully mapped, but the process steps aren’t always done. Even a clearly defined process will fail if the roles and responsibilities of the people involved are not clearly understood.
Sometimes all that is necessary to fix a “broken” process is to clearly define the roles and responsibilities of the people involved. Sometimes, a detailed process isn’t necessary if the roles and responsibilities are clearly understood. Many quality, engineering, management, logistical, and other “office” type problems can be solved quickly with clearer role and responsibility definition.
Many of our problems and potentially broken processes can be fixed very easily and quickly by simply defining a few important elements. Misunderstanding can be the sole source of problems, particularly in office-type scenarios or processes, though also for production processes.
Before declaring a process improvement event and breaking out all of your tools and methods, do a concerted screen of the definitions involved.
- Define what success looks like (so you can know if you even have a problem)
- Define roles and responsibilities and see if the process suddenly works after all
- Define guidelines and output formats to clarify procedural expectations
- Define the process or procedure if you want or need standardization
- Define the problem, if you actually have one, before trying to fix it
Save yourself and your organization a great deal of process improvement exercise by making clear definitions. Solve many of your problems by providing missing definitions or by clarifying definitions. Stop the behavior of process-improvement-without-a-purpose by first defining the problem.
Misunderstanding is a very common cause for performance shortcomings. Use clarity of communication and clear definitions to eliminate the phenomenon of misunderstood expectations. It is often a simple and quick way to solve problems and save time and energy on lengthy process improvement events.
Stay wise, friends.
If you like what you just read, find more of Alan’s thoughts at www.bizwizwithin.com .