It is human nature to see or hear about something we call a “problem” and think right past the situation to a solution. This causes us to miss some critical information that we need to figure what exactly what the problem is. And, as we tend to assume that we know what’s going on with whatever it is we think is a problem situation, we often don’t go see what is specifically is not working as it should.
Why does this matter? Not looking to see exactly what is not working as expected in a situation we are concerned about—be it process, procedure, policy, or system—lessens our chances of effectively changing the condition we want to eliminate. In a work situation the conditions or events that we describe as problems (missed deliveries and deadlines or information, rework, defects, errors. costs overruns, poor coordination, frustrated and resentful employees) are the result of something happening (or not happening) in the way the work is organized and being done. If we don’t stop to figure out what part of the operation is under performing, we have little chance of changing the specific things that are creating the performance gap.
It is a simple fact: you can’t improve results until you identify and change what is not working as planned. Therefore, to address a work-related problem, you first have to recognize that what you are concerned about does not exist in isolation. This is where A3 thinking becomes incredibly useful and powerful.
Understanding How to Approach A3 Problem Solving
The first challenge in A3 problem solving is to grasp the performance situation in which the unwanted condition exists. This usually means answering some key questions:
• How is what I am concern about related to needed performance?
• Why does this issue in performance matter?
• What performance results are we currently getting in the situation?
• What performance results do we think we should be getting?
• What part of the work system is not performing as we expect?
Answering these depends on realizing that whatever we call a problem is part of a work process created to produce certain results that it is not currently able to produce. Which brings us back to understanding the real problem…
What seems to you to be a problem may not necessarily be a problem in the way a problem is defined in A3 thinking. And what is a problem to you may not seem a problem to others. Fortunately, if you can show something is a problem in A3 problem solving thinking. there’s a good chance it will look like a problem to others in your company or operation.
In A3 problem solving, a problem has to meet two requirements to “qualify” as a problem:
- First, it must be an issue of performance in the workplace. The greatest concern for a business is performance in delivery of a product or service to a customer as planned. Continued operation as a business depends on achieving intended results to survive and thrive. A problem needing attention is one that indicates that is not happening in some way.
- Second, the problem must be defined as a clear gap (ideally measurable) between a specific work condition or event and an agreed to performance expectation or goal. These established expectations are usually described in the form of a standard, specification, procedure, process, target, policy or system. Demonstrating that a performance problem exists depends on bringing a precise picture of what is or is not happening into comparison with an accepted description (ideally documented) for what should be happening in the situation.
Sounds relatively easy, but in my 30 years of experience, the hardest part of the problem solving process is saying precisely (ideally visually) what problem you are trying to solve. The challenge is to bring together the facts (and data!) to clearly complete the problem statement “equation” – current level of performance compared to expected performance equals a gap or problem the operation or business needs to be address.
Getting Clear
Let’s take a closer look at why we often struggle to meet the two requirements in the “standard” for an A3 problem statement. Why is it difficult to demonstrate in performance terms that a clear gap between what is happening and what should be happening exist in a work situation? Let’s look at a couple of examples of the way we often describe problems versus how they could be described (for easier problem solving):
Example 1
In touring a worksite once I noticed a completed fishbone with this problem description in the fish’s head: “Inaccurate Weekly Work Plans.” I assume everyone in the brainstorming session knew what that meant. At least a dozen causes were identified and almost that many corrective actions planned. But, with such a non-specific problem statement, the team was taking a shotgun approach to improvement and hoping that by shooting at every possibility they would hit the real reasons that the work plans were inaccurate.
A PDCA/A3 problem solving approach to that problem situation would be to ask, “Exactly what’s wrong about the work plans we are creating currently?” That would require asking, “What do we know about what needs to be in an accurate and complete work plan? And how is it supposed to be created?”
The answers to those questions bring us to the fundamentals of lean/A3 thinking. If you want to improve the work plans, you need to know how they are different from what they are supposed to be. Then you look at the process that produced the work plans and ask what is happening (or not happening) in the way the process is being performed that created them. With some digging into the facts of what was happening (also known as the “dirty details) you might come up a statement of the problem such as the following:
41% of weekly work plans created by Production Team 4 are repeatedly inaccurate or incomplete in 7 critical ways. Those 7 discrepancies from the standard for work plans are: 1, 2, 3, 4, 5, 6, 7…
I was not working with that team so I don’t know what happened next, but I am confident that the team could learn exactly what the discrepancies are. It was seeing those errors and missing points that led them to describe the problem as “Inaccurate Weekly Work Plans” in the first place. In A3 problem solving, it is essential to know what those specific discrepancies from the standard are because you need to be able to track them back to the places in the process where the mistakes were made.
Example 2
The manager of a Medical Lab announced to Director of the Emergence Room (ER) that the experiment of having nurses do routine blood draws was not working. The purpose of the experiment was to reduce patient length of stay in the emergency room by having nurses draw samples of patients’ blood when they started their IVs. It often took 20-30 minutes for phlebotomists to come from the lab to collect samples.
A team of nurses, phlebotomists, and medical technicians developed a procedure and course of training to prepare nurses for the new responsibility. After the ER nurses collected samples and labeled tubes, they were to put them on designated carts for pick up by the lab. The nurses were trained and after three successful trials took over routine draws. Special blood draws which were still done by phlebotomists. But the Lab Manager’s claim threatened to derail the new procedure which had proven to reduce average length stay in the ER for patients.
The Director of the Emergency Room asked the hospital Continuous Improvement team to investigate before the procedure was abandoned. They asked the Lab Manager for clarification of what was wrong with the samples drawn and were told that a number of samples from the ER that were unusable had gone up by nearly 50%. A blood lab rejects samples as unusable if the blood has coagulated before it is tested.
The team examined the records and found that before the procedure was changed the number of samples rejected as coagulated was at an average of 8 per 100 samples (2 were drawn by phlebotomists, the rest stored too long in the lab to be used.) After nurses took responsibility for routine blood draws, the number increased to 12 per 100 samples. The team asked the phlebotomists and technicians to help confirm the accuracy of the training given the nurses.
First, they reviewed the procedure itself and the materials used in the training. Next they observed the training that the nurses received and watched them practicing. Then the CI team asked the phlebotomists and labs technicians to observe the nurses doing the draws, labeling the tubs and placing them in the carts for pickup.
Eventually, one of the phlebotomists noticed a nurse laying a sample tube on its side and asked why she was doing that. The nurse replied that sometimes it was necessary when the rack was full (he wanted to be sure the tube didn’t roll off the cart). Blood samples tend to coagulate faster lying on their sides rather than standing up right because more blood is exposed to the air in the tube. Documentation for the procedure and the training were checked, and there was no mention of the importance of tubes being placed upright in the racks. The phlebotomists and technicians had not thought to include that instruction in the procedure because it was just automatic for them. The procedure was revised as was the training. The new standard was communicated and checked by the lead nurses. And the Medical Lab decided technicians make their rounds to collect samples more frequently.
These two examples demonstrate, ironically, the problems created by a poorly stated problem. In the first example, the team likely created a lot of extra work (maybe even wasted work) for themselves because they did not start their problem solving effort by getting clear on exactly what problem they needed to solve. The second example illustrates the potential damage that can be caused by poorly stated problems that are assumed to be fact. Fortunately, in this case, investigation of the Lab Manager’s claim prevented a value improvement being discarded.
Why does it matter to share a problem in the form of problem statement with the help of this clear problem statement “equation”? As so many of us already know, “A problem clearly stated is half solved.”