Process maps are tools for change

The clarity of a process map may lead management to believe that an updated flowchart is an excellent tool for on-boarding instruction. “Each step of the process is painstakingly accounted for,” a manager might reason, “so why don’t we give this chart to new hires so they know how to do their jobs?” There’s enough truth in this sentiment to make it attractive to those who aren’t familiar with the process in question, but those who actually perform the work incorporate other influences outside the flowchart’s context. Only machines do work so routine that a flowchart can accurately describe the program’s behavior every time. The user knows instinctively what the manager may not recognize; that “all models are wrong, but some are useful (George Box, referenced in (Damelio, pg. 35)).”

When a manager or any other person in authority who is unfamiliar with a process directs his direct report to document their work as a process map, he shows that he doesn’t grasp the purpose of a process map or the complexity of the process context. Process maps are not primarily to document an existing process for posterity; they’re a tool to collaborate and make changes that every stakeholder agrees will make the process better. Process maps are for process improvements and work when they are used as such. They can even be used for instruction (sparingly), but are best served by the user with appropriate caveats, not as raw data to be directly ingested by a new hire. Therefore, break out the whiteboard and get drawing when a process isn’t satisfying customer needs or is unnecessarily slow, but be ready to erase the whiteboard once the change is agreed upon and executed.

This strikes me as important primarily because my manager (Relativity) has asked me so many times to create flowcharts of the processes I follow. As I’m ordinarily a detail-oriented person, the project may have been interesting, but I’ve always put off the request. When I trained Kevin to perform the same role, I used diagrams sparingly. Instead, I gave Kevin principles and insights from my own experience that would apply to many circumstances he was likely to encounter. To give him a flowchart invites trouble since it inaccurately describes the context of our work and limits the available options and the freedom to choose the customer’s best interest over a formulaic process. In the world of software, if a process is formulaic it should be automated.

References