Are you solving the right problem?

Using a structured problem solving process like the A3 method requires time and resources. The last thing you want to do is to begin such a process and then spend more time than you need to on it, or reach an advanced stage of the problem solving exercise only to find that you have gone down the wrong path, and need to rip it all up and start again. This can happen easily when you don’t take the time to define your problem carefully.

The "lighthouse" for any problem is the problem statement. When I coach frontline operational staff in manufacturing businesses, I stress that I should be able to arrive at the factory gate, be handed their problem statement, and then be able to seamlessly begin problem solving, even with little prior knowledge of the problem. The idea I’m communicating here is that your problem statement needs to be crystal clear and simply articulated. Some of my key guidelines for high-quality problem statements are:

·       Be as specific as possible

·       Keep it short and to the point

·       Only one problem to be addressed per problem statement

·       Don't mention possible causes or solutions

Some of the key pitfalls when solving problems is to begin the process with preconceived notions of what the root cause is or to be vague about why you are embarking on problem solving in the first place. A good problem statement allows you to neatly negotiate the first part of your journey without tainting the steps to come and ultimately reduces the time from problem detection until an implemented solution can be evaluated.

So how does one go about formulating a problem statement?

The following are key questions to be asked once a problem has been detected:

1.     WHAT is the problem? The existence of a problem implies a gap between a desired and an achieved level of performance. Use data to identify the gap and to define it, in as specific a manner as possible.

2.     WHERE is the problem? Try to pinpoint this location, but don't speculate too much on where the problem is if this is not precisely known. Indicating an incorrect problem location can be disastrous.

3.     WHEN does the problem occur? Some problems are seasonal, or occur at specific times of the day, week or month. This timing provides important clues.

4.     WHO is associated with the problem? It may be that an individual or shift team may perform at a distinctly different levels to other staff where the problem is concerned.

5.     How big is the problem? This is important to know upfront, as it dictates the amount of resources that should be committed to solving the problem. It is useful to think about how the problem will be measured and tracked, and to use this unit of measure to express the size of the problem.

6.     Has anything changed that may have sparked the occurrence of the problem? Often a plant has been modified or a new raw material has been brought into use, coinciding with the onset of the problem.

7. What happens upstream and downstream of where the problem is observed when the problem occurs?

8. Is the problem linked to a specific product, raw material, machine, process or other unique factor?

For the sake of brevity, not all of the information gathered here will need to be reflected in the problem statement. Some of this information is important context and will be used as input when root cause analysis is undertaken. The key elements that differentiate the problem do however need to be included. For example, if there is a yield problem on a specific production line, focusing on that line is important. However, the problem may only be on one product or one pack size on that line. That distinction would make a world of difference to the data gathering and analysis necessary to solve the problem. There is therefore a balance between keeping the problem statement short and making it precise.

Formulation of a problem statement is one of the simpler aspects in the problem solving process. Often, problem solvers want to quickly bypass this step, paying it little attention in the rush to get into the more technical aspects of problem solving, such as root cause analysis. Don’t make that mistake. Invest the time upfront and reap the rewards later.

Craig van Wyk is the Founder and Managing Consultant of VWG Consulting. Through VWG’s Performance through Problem Solving Programme and the company’s other problem solving training offerings, Craig has trained and coached many groups of manufacturing professionals, across disciplines and levels of responsibility. These groups have included plant operators, lab technicians, artisans, engineers, production managers, technical specialists and executives. As performance gaps are closed, client companies benefit from intensive capacity building with the added benefit of tangible performance improvement across dimensions of cost, product quality, safety, plant reliability and environmental performance.