Mapping is Situational

I've been noticing a pattern lately when our work with clients and improvement professionals involves mapping for understanding and designing work systems. Whether new to improvement or seasoned, many people attempt to force a fixed methodology onto the mapping process. And on the surface, the mapping books I've co-authored with Mike Osterling, Value Stream Mapping and Metrics-Based Process Mapping appear to promote a fixed methodology. But if you read carefully, we mention over and over that mapping is situational.

Maps are nothing more nor nothing less than a visual problem-solving tool that needs to be tailored for solving the specific problem at hand. There are many questions you need to answer, such as: What degree of granularity do you need to surface the obstacles to flow that will then be addressed? Is the improvement cycle best served by beginning with a leadership-level, macro view of a cross-functional value delivery system to establish an improvement strategy before tactical work begins? If so, value stream mapping is called for. Are the problems to be solved more tactical in nature and require an "in the weeds" view? Then swimlane-style process maps, such as our metrics-based process mapping method, may be called for.

Or you may need to create a "mid-level" map that falls somewhere between a value stream map and a metrics-based process map. We recently opted for a mid-level map to surface obstacles to flow in Phase 2 of a surgery services transformation project after the first round of value stream level improvements were made. The team needed greater granularity to surface the remaining obstacles to flow, but they needed to prioritize the remaining problems (gaps to be closed) before digging into the weeds.

Another decision you need to make is which metrics to include on the map. The three go-to metrics Mike and I talk about in our books are lead time (LT), process time (PT), and percent complete and accurate (%C&A). Much of the time we put all three on maps, whether value stream maps, process maps, or something in between. But rigidity isn't your friend. You have to serve the problem to be solved.

For example, we recently co-facilitated a senior leadership-level value stream mapping effort as part of an emergency care services transformation project and opted to forego process time at this stage of the improvement cycle. The lead times for each process block provided sufficient clarity for the mapping team to see what needs to be done strategically to improve patient throughput. In this case, including process time on the value stream maps would have consumed a lot of high-valued team time and wouldn't have provided enough additional insight to warrant the time it would take to "follow the rules." We may come to a point where it does make sense to add process time to the value stream map. Dunno. Time will tell.

There are many more decisions to be made regarding maps. At the value stream level, is it relevant to include all of the IT systems and applications that contribute to information flow or not? Do you need to dig into processes performed by third parties or not? Should you put include lead time on every process block or is it just as effective to view lead time in larger chunks? At a process level, are swim-lanes the most helpful format? How granular should you go? And so on.

It's important to remember that the purpose of maps is to provide clarity and a shared understanding, which then drives meaningful conversations and reaching consensus about necessary improvements. At the end of the day, it's not about the maps. It's about transforming work systems and achieving results. Maps are merely enablers and is situational vs. prescriptive. It's as much art as science. Since you need to learn the rules to know when and how to break them, practice is key. You may over-engineer your maps at the beginning but if you focus on relevance every step along the way, you're more likely to get more meaningful results in less time. Keep asking the questions: What problem needs to be solved? And what do we need to know to solve it properly?

And, finally, remember that mapping is only one of many means to understand current state work systems and processes. Most of the improvement work we're involved with also require data analyses, interviews, extensive observation, and so on. Mapping is an important means--but it's only one of many means. And when you use them, relevance is key.

While I don't address mapping and metrics flexibility explicitly in any of my webinars, the webinar Value Stream & Process Mapping: When You Opt for Each may serve as a useful springboard for a thought exercise regarding mapping relevance.