et’s see... we’ve touched on the rules and guidance of process mapping. We hit on why process mapping is important. Today, let’s talk about the non-technical pitfalls of mapping. We’ll call them the facilitation issues.

Four Facilitation Tips

1. Your process map might have a few iterations

We tell you to go the gemba to watch the process, but it’s often impractical to facilitate a mapping session where the work happens. “Dr. Finlayson, I brought the whole team into the OR to watch the process.” But don’t kid yourself: you’re going to miss things in a conference room. For finer details, some of you will need to go to the gemba (e.g.: Dr. Finlayson’s OR) to see the work as it happens. This reality is why we say process mapping is easy but also hard. It often requires iterations. If iterations pose a logistical obstacle you could ask a sub-team (including you) to develop a draft map which you hope is 80% correct. Sometimes its saves time to give the larger team something to edit rather than start with a blank page.

2. Include the people who do the work, not just leadership

If this is the attendance pattern at your mapping session, you may have forgotten that processes are improved best by the experts who do the work. You may hear, “They’re too valuable to take away from the work.” On the other hand, the dominant hand, they are the experts and they can best tell you about the process. We highly recommend they have a seat at the table for the most accuracy. Start by asking these for questions.

3. Speaking of accuracy... Map the actual state, not the “sposda” state

Rarely does process execution perfectly reflect its design. You plant your garden in neat rows and then nature, darned nature, creeps in. Before you set your team loose to make their process visible, equipped with Post-it pads and Sharpies, remind them that they’re mapping the current state. The real state. The as-it-actually-happens state. The sposda state is dangerously misleading. The sposda state is one of the many opposites of the Clarity Rule. There are many rational reasons for a team to present the way the process was designed rather than expose the warts of how it really goes down every day, but you need to get past this tendency if clarity is to be achieved.

4. Start low-detail, then add details later

If it doesn’t add, it takes away; there is no neutral. Sometimes less is more. Go back to the Purpose Rule and turn it into a couple questions. What process problem are you trying to solve? What do you want to see with this map? In this case, Purpose is a catalyst to Clarity. Too much detail can blur the map’s message; not enough detail and your map won’t be helpful. Discovering the sweet spot takes practice. Sometimes it makes sense to start low-detail and add details later, especially if those two questions remain unanswered.

Next time: Common mistakes when process mapping.