Struggling With Process Ownership? Perhaps It's a Failure to Communicate

Does your business struggle with process ownership? Are your process improvements not “sticking”? The failure of an organization to have in place well-functioning process owners is a common occurrence these days. The root causes (if anyone cares to do a full postmortem) are numerous. We’ve heard it all before; “the organizational structure won’t allow for it”, “incentives are misaligned”, “leaders don’t understand what it takes to be a process owner” etc. I’m sure we can all relate to some or all of these statements.

While all of the above may be valid root causes as to why a process owner is not performing as expected, the focus of this article is to highlight one additional root cause which I feel is much more specific, often gets overlooked and is entirely in the control of the process gurus themselves making it quite easy to rectify. I call it a failure to communicate. The specific lack of communication I am referring to in this case is the complexity with which we as process gurus capture business processes and the language we choose to depict it. What do I mean by all this? Let me explain.

Businesses (and some process gurus) often pay little attention to the true value of proper decomposition of their core processes and as a result, they often jump to tools like Visio (or worse MS Word or PowerPoint) to map their processes at painstakingly low levels of detail as part of their process mapping efforts. Simply put, I often see businesses document their processes at excruciating levels of detail without first (or ever) documenting the higher level process flow leaving business leaders and process owners frustrated and suffocating in the details. Don’t get me wrong, mapping out these details are absolutely essential in certain circumstances, but without a higher level process map existing, your extremely detailed process map simply dangles in the wind like a loose thread never being anchored to any core business process. Why is it important to tether your maps hierarchically rather than just map to whatever level of detail you prefer? For two fundamental reasons:

1. The comprehension of a process map increases dramatically if you are at the right level of abstraction for the given audience. Processes should be deconstructed from a top-down approach as this helps bring context to the project teams and more importantly the business users. Some folks need tremendous details while others need higher level activities to “get the picture”.
2. Traditional process mapping (horizontally driven, swim lane etc.) tends to get very complex very fast. They are typically created at the same level of abstraction (very detailed level) and can sometimes be large enough to wallpaper a small gymnasium. While this is useful for detailed problem solving, it’s a disaster if you want to drive process ownership, accountability and control using these maps. Even if the detailed process map is accurate it will come as no surprise that the destined process owner will never pick up and read it again let alone own and manage it. A process that can only be explained in hundreds of complex process steps is simply not going to be used again. It will gather dust on the shelf once your process initiative is over and that will spell disaster from a process ownership perspective. Process mapping is both a skill and an art. The artistry comes from maintaining accuracy while looking for conciseness. After all, there is only so many boxes and images on a page that one can digest. The more effort the process practitioner places on building accurate and concise maps my experience has shown that the more likely the business is to take the responsibility of improving and managing their process in the long run.

​Another aspect of process mapping communication that dramatically affects process ownership is with respect to the mapping language that process practitioners use when it comes to process mapping. Process & technology teams are so quick to jump to complex mapping notations that business leaders simply do not understand which also contributes to the businesses inability to properly “own” and manage their processes. After all, how can one take responsibility for something which they don’t fully understand? Sure, you might argue that we should teach all process owners BPMN 2.0 mapping language, or that we should have all our business users take training on how to map using UML mapping language, but is this really feasible? Is this even logical? I don’t think so. My experience has been to leverage the most basic and self-explanatory symbols as possible to remove any impediments the business has to actually read, interpret and own their processes. Not everyone in a company is a process guru, nor do they need to be.

Unless we as process practitioners want to own all these processes ourselves in the future then I suggest we rethink the language we use when the processes get mapped in the first place. Fear not my process colleagues, there is a solution! Consider leveraging a more intuitive mapping notation. One of the better notations I’ve seen is called UPN (Unified Process Notation…a great write up on UPN is found here) although well labelled boxes and arrows work just as well. Don't forget for whom we map these processes for and why we map them in the first place. If technology and the process gurus are your customers, by all means pick a mapping language of your choice. If the general business user, leader or executive is your audience, best go with something simpler.

So the next time you are challenged with a lack of process ownership or processes that slowly diverge back to their original state of ineffectiveness, I might suggest taking a look at the artifacts that have been left behind to see how easy (or not) we as process practitioners have made it for the business users to actually interpret, manage and own their processes.