Advertisement
Blogs
Advertisement

The Everyday Usefulness of the Problem Statement

Fri, 05/24/2013 - 2:59pm
Alan Nicol, Executive Member, AlanNicolSolutions

Last week I wrote about how our continuous improvement and process improvement tools and methods can be used any time and discussed the Parameter Diagram or P-diagram as an example. Let’s continue that thread and look at the ubiquitous usefulness of the problem statement.

In my opinion, the problem statement is the most useful and important element of any problem-solving effort. It quickly and concisely focuses our own mind and those of our teammates on a clearly described problem. It removes or reduces uncertainty and confusion and rapidly enables understanding and engaging to address the issue. That is incredibly powerful.

With such a simple and powerful tool at our disposal, why shouldn’t we foster a habit of using it every day, for every problem? Let’s look at how we can do so.

The problem statement is a simple thing. That is not to say it is always easy or obvious. It takes some practice, but it is not complicated.

A good problem statement includes three things.

  1. What is the problem?
  2. Where and when does it occur?
  3. How do you know?

Similarly, a good problem statement excludes four things.

  1. Opinions
  2. Solutions
  3. Conclusions or causes
  4. Actions or directions

The easiest way to think about the problem statement is to ensure that it is nothing more than a declaration of the problem so that it can be solved. As soon as we start inserting background information, possible solutions, directions, or opinions, we have stepped beyond the objective of communicating the problem itself. We also invite debate and argument, which is not what we want.

Let’s look at some examples to get the hang of this. Consider the following statement.

“Defective Marketing inputs cause product brochures to be scrapped after publishing.”

The above statement says what the problem is; brochures are scrapped. It says when the problem occurs, after publishing. However, there is an alarm word in the sentence, “cause.” We don’t want to declare a cause in our problem statement. We want to focus on determining the cause correctly, not jumping to conclusions or accepting assumptions or opinions. Do we really know that defective Marketing inputs are the root cause?

The statement would be better if it read as follows.

“The Pareto chart of scrapped material indicates that product brochures are scrapped after publishing because the information is inaccurate.”

The “because information is inaccurate” part of the sentence fits the where/when criteria for the problem statement. Likewise, including the source of the information is important. Do we know that we have a costly problem, or are we just chasing someone’s pet peeve or a rumor? Including information about how we know we have a problem helps us start our problem solving investigation in the right place.

Now that we have refined one statement, take a look at this one. Decide if it is a good one or not.

“Failure Modes and Effects Analyses (FMEAs) take too long, are non-value-added, and should be eliminated.”

It is a poor statement. It is all of the wrong elements and none of the right ones. It is opinionated and it declares an action or a solution.

Here is another example.

“Technical writers re-work instruction sheets 7 to 13 times during the Design and Review stages of the process.”

The statement is probably adequate to help a person or team focus on eliminating rework steps for technical writers. However, it would be better if it were clearer as to why this is a problem. Is it something we need to fix, or is it good that technical writers rework the instructions?

“Walking the technical writing process reveals the most wasteful step involves the rework of instructions during the Design and Review stages, which occurs 7 to 13 times per product and could reduce 30 to 80 man hours of work if eliminated.”

The last example is a complete problem statement. It explains the importance of addressing the problem in the form of exposing an opportunity in terms of man hours, it says how we know, it clarifies where and when the problem exists, and it states that the problem is rework steps that waste man hours.

I made that statement the last one for a reason.  It makes an easy example for the everyday usefulness of the problem statement as much as it makes an example of a good problem statement. Any time we need someone to take action to address an issue is a good time to break out a solid problem statement.

In the last example statement, we can imagine a scenario where the technical writing team wants to improve life for itself by eliminating a great deal of painful rework and a process aggravation that often leads to last-minute, late, or less-than-perfect delivery of instructions. The team lead could say to the management team, “I want to change the tech-writing process to eliminate rework.” Management would of course say, “Go ahead.”

That isn’t what the tech-writing lead needs though. She needs cooperation from engineering and marketing teams to change how they are doing things. She needs the participation and cooperation of others. The problem statement above will quickly and clearly communicate the opportunity. Her request for changes to be made to everyone’s processes and behaviors are more likely to be taken seriously and approved.

We can use a problem statement for any request or proposal. Suppose you feel that you are overdue for a raise and need to get your leadership to address your concern. Suppose you want a budget for reward and recognition purposes. You need to call the executive leaders together to address spending rates that the current cash reserves cannot support.

When we make requests to talk about issues we may or may not be taken seriously. People may not feel urgent about what we are urgent about, or people may not understand why we feel it necessary to talk with them at all about our problems. The problem statement format and discipline is an excellent way to clearly and concisely communicate why a problem is everyone’s problem and why it needs to be addressed.

Here is a real example that a friend of mine experienced this week. A shipment of products to a specific customer had not shipped and could not ship because the qualification and regulatory requirements were not confirmed. The problem that caused the delay is a systemic one, not an isolated incident.

The problem has been discussed many, many times, but no action to correct it has been decisively undertaken. Part of this is because the regulatory expert is a detail-minded personality and few people have the patience or desire to try to understand the history, background, complexity, enormity, or pain that he does, but would like to share. Unfortunately, my friend is the one who conferred with the Quality department that the product could not ship and needed to both explain and start getting the problem corrected.

The details of the problem were so confounded that she didn’t know herself where to start. She needed to find a way to simplify and focus. She wrote a problem statement. Changing the names to protect the business, it read something like this.

“The shipment of X to customer Y is delayed due to a lack of data to prove conformance to customer specified requirements and regulatory standards.”

Her problem statement very easily explained the issue. It also immediately helped everyone understand why the decision to delay the shipment was necessary. However, it requires some background to fulfill her real purpose, which is to get the root problem addressed.

Fortunately, with the problem statement established, she could conduct her own exercise to address the obvious questions. She did a quick 5-why root cause analysis thought process to fill in the blanks.

Why is data missing? We don’t have test and conformance data for the material and adhesive combination in the product.

Why don’t we have test and conformance data for the adhesive? The supplier of the system changed the adhesive.

Why did the supplier change the adhesive? The drawings specify adhesive Z, “or equivalent.”

If the adhesive is “equivalent” why is this a conformance problem? “Equivalence” is not specified and there is no way to know if the chosen adhesive, with the system, will react poorly to certain regulatory or reliability tests.

Her proposal to the management team, to address the existing problem of the late delivery included her 5-why analysis, though I paraphrased it somewhat for those of us that don’t share the common knowledge and background that her team members share. In a simple e-mail and follow-up conversation with her management and the product team she quickly explained the problem and her rationale.

Likewise, it was easy for her to explain to the management team that the same problem is likely to affect any or every product to be made going forward until “or equivalent” was removed from every drawing, or “equivalency” is clearly defined and measurably specified. A problem that had been debated and argued repeatedly many times before suddenly had focus.

I wish I could relate to the reader the excitement in my friend’s voice and manner when she told me about her experience. Her management team was engaged because they finally understood the problem and the relationship between drawing notes and emergency testing and delayed shipments. The program manager finally understood and could communicate clearly to the customer what was the issue.

Most importantly, an effort to change the notes on the drawings was finally triggered, assigned, and resources had a short-term due date to find and eliminate the problematic notes. A problem that had gone unsolved and that harbored potential for disastrous business affects was finally getting resolved because she stopped, sat down, and wrote a problem statement followed up by some background information.

Do not doubt the power of a good problem statement. My friend managed to get addressed what had been a problem for a long time and it took her less than an hour to do it. It happened because she brought clarity to the issue.

Hopefully, the power and everyday utility of the problem statement tool is apparent from the real-life example. So, let’s address another assertion I made above before we close. I said it is simple, but not always easy or obvious. I think the example problem statements above shed some light on this thought.

Let’s look at what to do when we are staring at that blank page and we have a dozen or more ideas, issues, challenges, possible causes, possible solutions, and other thoughts standing in the way of clarity. This is how it was for my friend. She did a brilliant thing, so I’ll pass it on.

She began answering the basic, fundamental questions: Who? What? Where? When? Why? How? Although not all of the answers to those questions belong in the problem statement, it helped her to organize her thoughts, articulate them, and then filter through them to pick out the pieces that did make up the problem statement.

I often begin my planning and process improvement or process or product design efforts with those same questions. It is a very good practice.

Some time this week you will need someone else to focus his or her attention on an issue, or you will want to propose an action, or you will need approval for a request, or you will have a problem and you won’t know where to start to solve it. In any and all of these cases take a few minutes and write the problem statement. Once you have the problem statement fill in the background and analysis knowledge that you have or can deduce.

Use the problem statement and your information to quickly and clearly communicate your needs to yourself and to your teams. It is a very powerful tool because it produces clarity and focus without inviting argument and debate. Use it. Use it every day and make yourself more effective, immediately.

Stay wise, friends.

If you like what you just read, find more of Alan’s thoughts at www.bizwizwithin.com

Advertisement

Share this Story

X
You may login with either your assigned username or your e-mail address.
The password field is case sensitive.
Loading