Solve Problems with Definitions, Part 1

Simply providing a clearer expectation of what “good enough” looks like can solve many problems we encounter.

By ALAN NICOL, Executive Member, AlanNicolSolutions LLC

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:

  1. How do you know the process is broken?
  2. What is the failure?
  3. 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:

  1. Identify the primary output or purpose of the process.
  2. Determine if the process is successfully meeting that expectation.
  3. If not, then the purpose of the improvement is to make it meet that expectation.

At the end of that three-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 two 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.

Please tune into the Chemical Equipment Daily for part two of this two-part series. What’s your take? Please feel free to comment below! For more information, please visit