Process Improvement: Solving Practice Problems Using A3 Methodology

As a follow up to my ‘Introduction to Dynamic Work Design’ article in the Spring 2018 issue, let’s discuss how you can go about appropriately assessing a problem and getting to the root cause of it before you begin to try to improve it.

There are many process improvement tools available and choosing the ‘right’ one can be a difficult task, particularly when an issue, and its root cause, is poorly defined. We’ve seen countless hours fruitlessly spent by teams attempting to improve the wrong thing. Therefore, it is important to gain a more complete understanding of what is causing inefficiencies in your process before launching into any improvement initiative.

One of my favorite approaches to root cause analysis, and subsequent improvement of it, is the ‘A3’ methodology. Now A3 may be an 11 X 17 paper size in Europe, but in Lean terminology it is much more than that. Typically we use A3 as a way to visualize that which is not readily apparent, and as a means to develop an improvement process to remedy it.

What’s so great about the A3? It walks you through a process designed to reduce bias and allow for insight through observation and suspended judgment. Succinctly put, it steps you through the following process in order to truly get to the heart of any issue:

• Help to identify the problem or need
• Allow for definition of the current ‘condition’ or process
• Guide assessment of the root cause of that condition
• Target the condition and allows measures to be deployed to reach it
• Encourage implementation of a plan to fix it

I cannot underscore enough the importance of spending the time needed to properly define the problem. Your ‘problem statement’ determines your area of focus and sets the course of your actions.

Here’s how to make sure that you get this right:

Make sure your problem statement is about an actual observable condition, and not about a perceived cause or solution, or what you think it might be.

Always focus on the problem, not what you think the solution ought to be. The simplest way to do this is to focus on an individual problem rather than trying to lump a bunch of issues together. Focusing on one issue will make it easier to hone in on a root cause for remediation. Solving a larger problem by breaking it down into its smaller parts is an effective way to solve problems permanently. g

Do your research. You will want to understand enough background information in order to comprehend the extent and importance of the problem. At a minimum, learn about the following:

• How was the problem identified?
• Why is the problem important now (and not before now)?
• What is the impact of the problem today and what will it be tomorrow?
• Which stakeholders (staff, departments, etc.) are involved?
• Is it important to the organization’s goals, mission, and strategy to solve this problem?

Once you’ve got a handle on the nature and extent of the issue, and what is causing the issue to be a problem at this particular moment (is it a new problem? Or an old problem that has been acute for particular new reasons?) then you can define your problem statement.

The Problem Statement

A well constructed problem statement might read like this:

• Patients’ insurance information is not getting input to the patient billing record every time a new patient is registered (The issue is defined)
• The problem has become more frequent in the last 6 months or so. (The time line is identified)
• The omissions seem to happen randomly. Some data is complete, other times the data is missing altogether. (The context is provided)
• This has resulted in billers having to call patients, claims being delayed going out for payment by the insurers, and is adding at least 30 to 40 minutes in follow up work with each biller per week. (The impact is quantified)

Now, you may be tempted at this point to jump to conclusions about what is causing the problem. But not so fast…

Current Condition

We need to define the current condition, and this requires you to go take a look at the problem. Go observe it in action and see what is actually happening. Map it out — even if that map is only the briefest sketch on the back of an envelope. Doing so will give you an in-depth and detailed understanding of the current process as it is actually performed, not how it should be done, or how someone says it is done.

Having someone describe how the process generally works or how it is supposed to work is not all that useful; it is the actual application of the process that reveals what deviations occur from the optimal process application that typically shows where the problems lie. The usefulness of direct observation creates your objectivity and renders it devoid of emotion or assumption.

While you may think that directly observing a process is enough to understand, take the time to draw it out, for three reasons:

• It will force you to organize the process steps into how it is actually being done,
• Any diagram quickly and effectively communicates the core issues to others. We are visual beings, and can much more readily absorb information when presented graphically,
• By diagramming the system, problem-solving efforts are focused on the system rather than the people.

All of this effort results in a much more objective approach and removes tendencies to blame individuals for systemic or process failures.

Root Cause Analysis

One of my favorite methods for defining any root cause is known as the “5 Whys.” This method can be irritating because it is probing and repetitive, but it uncovers the root of any issue by peeling back, layer by layer, the ‘why’ of the issue. By asking “Why?” five times, we can get all the way to the root of the issue. We aren’t asking ‘why’ 5 times about the same question though; each ‘why’ question is dependent upon the answer to the previous question.

Here’s an example:

Our receptionist, Daisy Mae, did not record the patient’s insurance information at check in, again. She really doesn’t understand how important it is to get that information before the patient is seen by the doctor.

Question 1: Why didn’t you (Daisy Mae) collect that information?

• Answer: I didn’t have enough time.

Question 2: Why did you not have enough time?

• Answer: The nurse was calling the patient to the back before I was finished gathering the information.

Question 3: Why was the nurse calling the patient so quickly?

• Answer: He wasn’t, but I was juggling three phone calls and registering another patient so it was taking some time.

Question 4: Why were you juggling so much at the same time

• Answer: It was Monday, we are always really busy on Mondays and I am the only one working the front desk.

Question 5: Why are you the only one working the front desk on a busy Monday?

• Answer: ?!

From this process, we switch from the assumption that Daisy Mae does not realize the importance of the task to a much more comprehensive understanding that the issue is really that the front desk is under-staffed, at least on Mondays.

Jumping to solutions before going through that process may have resulted in spending time and effort in training Daisy Mae to better understand the importance of how missing billing information can impact operations all the way down the line to the bottom line, when what was really need was to determine better coverage for busy patient times during the week. At the most, jumping to solutions would have resulted in mildly alleviating a symptom, but would not have solved the problem.

Target Condition

The ‘target condition’ is the ideal state that you are looking to achieve. Determining solutions to specific problems is one thing; designing a better process and outcome is entirely another. We want to not only alleviate the current problem but also use the good work we’ve done to determine if there is a better way to work the process in the future.

For example, we could hire more staff to help Daisy Mae at the front desk on Mondays. This helps solve the problem because Daisy Mae now has someone to answer the phones while she collects insurance data during the check in process. But is that really the best way to collect that data in the first place? When we develop a Target Condition, we are seeking to find a better, more efficient and more effective way to carry out a process. The ideal process should be free from inefficiencies.

Applying this to our insurance registration example, we can develop a target condition that might look like this:

• Insurance data should be collected and entered into the system by the scheduling team when the patient first schedules their appointment.

Rather than wasting time, energy, and resources in training Daisy Mae (the only front desk resource) to do what she does not have time to do, or adding resources to help reduce the issue by using more people to address the volume of the problem, it is possible to determine that the process should not sit with the front desk resources in the first place, but is better handled earlier in the patient intake process to the benefit of all.

This is what an A3 template looks like and here is where you can download an A3 template.