refresher: A process map is a communication tool, first and foremost. As with so many communication tools, it is hard to develop a complex communication that is easy to understand. In this last post of my process mapping series, I highlight some common technical pitfalls in process mapping.

1. Choose actions, not milestones

Your process is a series of actions (or inactions); you need verbs. Teams go astray when they focus on the result of the actions, which are milestones. Milestones look back and say what has been done. “Specimen arrives at lab.” vs. “Specimen carried to lab.” See the difference? It’s a best practice to capture the time consumed by each step. If the time is very short, it’s possible you mapped the milestone. How long does it take for a specimen to arrive ? How long to be carried ?

2. Choose the right owners

This is only a big deal if you discover it after the map is built. If you discover the mistake early, no big thing; just change them. Use Post-its for owners too. Remember the Purpose Rule? The Purpose Rule helps here if you ask, “What are we trying to see?” Ask the team to consider whether the ownership should be differentiated at the individual level or in groups. Individual roles might be inpatient nurse, respiratory therapist, HUC, HCA, etc. A logical grouping might be pre-op clinic, OR pre-op, OR, PACU, inpatient unit, etc.

3. Carefully choose the beginning and end of your process

Pro tip that supports the Purpose Rule: Define the specific milestones that mark your process’s start and stop points. If you’re mapping a clinic visit, does it begin when the appointment is made? And when is the appointment really “made”? When the scheduler clicks save in Epic? Or does the process in question only concern the day of the appointment? Now when does it start? When the patient parks her car? When she is done with check in? It’s hard to be too specific when identifying these two critical points. They’re critical because they bound the discussion and keep the team from wandering.

4. Follow the process (not the people)

We’re referencing both Rules here. You are mapping a single instance…a single run of your process. If the coding/billing process is the topic, you are mapping the path and transformation of data from a single case. If the post-op stay is the topic, you are mapping the process experienced by a single patient. You are not mapping a day in the life of a coder or a nurse or HCA. When that patient is waiting for an employee there’s a natural desire to show how busy that employee is. Resist this. It clutters your map and misrepresents the stay as experienced by the patient.

5. Make sure you make the invisible visible

The Purpose Rule must be decided and confirmed before the first Post-it goes on the dry erase board. If you don’t know what you’re trying to see, you’re very unlikely to map it. Is your team tackling excessive turnaround times? You need to show delays. Too many errors? You better show the specific points that generate those errors and what conceals them until their discovery. Is your team wearing out their shoes too fast? You need to show employee travel as discrete process steps (and later a spaghetti diagram can geographically show employee travel). Does information seem to disappear? Show how the information moves from someone’s brain, to an email, to idle time in an inbox, to a phone call, to a sticky note hanging on the computer monitor, to an Epic order.

6. Make it easy to read

Process maps inherently have limited real estate. Be conscientious of word choice, spacing, arrow direction (up and/or down is fine, but only left-to-right please) and box alignment. All of this helps the viewer and supports the Clarity Rule.