To recap a previous post, an A3 can be developed in nine steps, the first four having to do with analysis and the last five with corrections/fixes and follow-up. In this post, I discuss the steps involved in analysis.
Developing an A3 step by step: analysis
Step 1: Defining the issue
Start on the upper left side of the A3.
a) Define the issue first. The issue is not that “the MD is unhappy.” The issue is what causes this situation (ex. delays experienced by MD in locating pt info, etc.)
b) Keep it fairly narrow. State impact if issue were not to be addressed. Patient at risk? Lost revenue? A “must”, or just a “nice to have”?
c) You can do this in two sentences, one for the issue, one for its impact. Strive for clarity and conciseness.
Why do you need to state the impact? Managers deciding which of many A3s to assign limited resources to need to know the impact up front to be able to prioritize properly.
Step 2: Presenting background information
Move down. Give some background info to the reader. Ask yourself:
a) What has led to the situation?
b) What else may be important — and perhaps not immediately obvious — for the reader to understand?
Remember, context information helps to “paint the picture.” Others without your access to information may look at the A3 later, and have to reach a decision. Be thorough, clear, and concise.
Step 3: Describing the current state
Move down. Describe the current state or condition.
a) Use the best means you can think of to state what is going on. Use a process map / flowchart / swim-lane, a more general picture, a graph showing a trend, a table summarizing figures, etc.
b) A simple block diagram may suffice. Show each process step in its own box, and link the steps in a sequence with arrows.
c) Follow established convention. Describe each problem symptom in words within a “spiky cloud”, and draw these next to the process step where they occur.
d) Do not link spiky clouds with arrows, or to the process boxes.
e) Be clear, but do not obsess about neatness, since rewrites are likely in your future.
Summarizing, if you draw a process diagram of some sort, it should look like connected boxes (each showing a process step), with spiky clouds (problems) “floating” around it. See the post on useful PI symbols.
Step 4: Drilling down to the root cause
Move down to the analysis/root cause section.
a) With a clear picture of the current condition from the previous step, you will know the symptoms of the problem. This is not enough. You want to address its underlying causes, not its symptoms.
b) This is where asking yourself “Why is this going on?” several times can pay off — but only if you try to answer it.
c) Develop each symptom identified earlier — and described inside a “spiky cloud” — into a sequence of cascading “why’s”, and try to come up with a root cause per symptom. The 5 in “5 why’s” is just a guideline.
d) Write each successive “why” down in indented fashion from the one preceding it. Stop when you think you’ve drilled down enough (to the root cause).
e) An Ishikawa/fishbone diagram is a viable alternative to the text-based “5 whys”, if well done.
NOTE: Do not skip this section, or pay it lip service because you think you know what the problem fix is. Dig deep, and verify.
You are now done with the analysis part, and the left-hand side of the A3. Remember:
- Clear, succinct communication takes time. Work at it. This means rewriting, redrawing, etc. as your understanding of the issue at hand improves. A good analyst is a sort of detective, digging for evidence. So, start digging.
- Do not skip any section.
- Developing an A3 is an iterative process, and the A3 is your sketchpad.
And now, on to the Action/Correction development phase of the A3.