With this Column we will begin a series on how to succeed at integrating process management into an organization. Since the beginning of the “process movement” in the 1980's and 1990's, it has been recognized that installing a process management system into an organization is a necessary condition for its becoming “process-centered” and realizing the long-term results of process improvement efforts. Both Geary Rummler and Michael Hammer, in their landmark books, posited that process management was not only desirable but the key to organizational sustainability.
But compared to the sometimes-amazing results that many organizations have realized from process improvement initiatives, the success rate for effective process management is not high. The barriers to installing effective process management are many. In this Column we will explore some of them In future Columns we will propose a way of doing this delicate work that avoids or at least minimizes the difficulties, and then get into detail about exactly what to install and how to go about it.
“Who Asked You?”
In our earliest endeavors in process work, our entré into virtually all our client organizations was to conduct process improvement projects. This period—of the late eighties and early nineties—was when the notion of business processes was novel enough by itself, and the best way to convince an organization that they should care about their processes was to tackle a big but troubled cross-functional process and make it better. Quantifiable improvement tended to come swiftly and dramatically. During those projects we identified the performance metrics necessary to track and report process performance, and we would do a little work to identify who should be monitoring those metrics. That was the beginning of developing our approach to process management. But we didn't push it, for two reasons: one, because we weren't asked to get into the mechanisms of management—we were there to redesign work; and two, because we weren't yet sure how to go about it ourselves. Process management was a notion back then. Nobody had a model for what it was, much less how it should work on a daily basis.
But slowly and surely it became evident to us that process management was essential in order for an organization to sustain the improvements it had achieved. Without process management in place, performers could slip back into old habits and in effect revive the old flawed process. The other indication was that when an organization went from its first process improvement effort to the next one, and even more when it attempted to tackle several at once, there had to be some oversight of all these efforts and some collaboration across them, or else chaos would result.
The solution was a process management system on top of the processes. But our first barrier—when we started talking with clients about the need for process management—was that we were viewed as intervening where we hadn't been asked to help and perhaps didn't belong. We were process experts, not management experts, we might be told. We were pigeonholed by our own success and our own self-labeling.
This barrier exists today, for any process excellence practitioner who might be doing “process work”. Such work can be viewed as unrelated to management, but instead as “technical stuff”, “down there in the weeds”. This has become even more of an issue where process work has migrated to IT and so any “process stuff” is mistaken for technology.
“What do you mean by management?”
But assuming the client did invite us into the process management space, the next barrier we had to tackle was the many and varied interpretations of the word management when combined with the word process. The various stakeholders all had in mind something that “process management” would do for them and several things that it would not do to them.
In the early days before BPM systems, some of our sponsors had great value for the artifacts and information that were produced during the process improvement projects, and they wanted an ongoing system that would manage and update that information as the process evolved over time. They merely wanted a process documentation/information management system. Now that BPM systems have become so prevalent, there is a new variation on this interpretation of management. Many IT BPM groups are only interested in maintaining the process information needed to aid in executing changes related to the IT systems supporting business processes.
Other sponsors wanted a process compliance system. They were looking for tools and practices that would aid them in their role as process police. This was especially true of process improvement projects that were sponsored by support functions such as IT, HR and Procurement. They wanted to roll out the newly designed global procurement process and, by golly, they wanted to be sure it was followed to the letter by all those “misbehaving business people” who needed to procure things. The metrics focused on compliance much more than performance.
But there were a few enlightened sponsors who truly wanted a process management system that would ensure the process was performing as the business needed it to perform. They bought into the notions of process performance metrics, process management teams and process ownership. They began to meet on a regular basis to review troubleshoot process performance. That's when we ran into the next and perhaps most difficult barrier.
“There’s Process Management and then there’s Real Management”
These process roles, data and meetings were outside of the day-to-day management practices of the organization. They were bolted on: extra duties existing in a bubble for the few process proponents in the organization. The regular management system marched along, wherein leaders continued making decisions and plans and allocating resources, oblivious to decisions regarding process performance. Process requirements weren't included in the annual planning cycle and processes usually didn't get the resources required. Managers of functions participating in the process were assessed only for how well their own function performed. Nobody got rewarded for how well the cross-functional process performed once the improvement project was over. Made irrelevant and underutilized, eventually the bolt-on appendage was rejected.
The good news about encountering barriers is that whatever doesn't stop you dead, becomes a learning experience. So with lots of attempts, many failures and eventually many achievements, we were able to identify the success factors, tools and practices which gave us the best results in building and sustaining process management systems in our client organizations. We look forward to sharing these with you in our next few Columns.