I was in a rather contentious meeting this month with a number of process participants who all disagreed on what the process hand offs should be. Each group took terms explaining their position on why the process item should leave their team’s queue when completing their task, but waiting on another group to provide documentation that may impact a future task. For the initial rollout of the process, it was agreed that instead of trying to define and automate every business rule, there would be a process group who would categorize and assign a priority to each process instance. Each group seemed to believe that the initial group assigned the instance should always own the task regardless of if that group determined supporting documentation from another group was necessary. The semantics became centered around the concept of sending a referal task versus sending an FYI notice. Most groups wanted to push for an FYI notice and not be required to acknowledge or act upon the FYI unless deemed necessary later. Finally, one of the attendees finally stated what I figured was the underlying issue, “Look, I want the credit for any work I do; I just don’t want people knowing how long I take to do it.”
While the virtues of visibility, agility, and transparency are fantastic benefits at the management level, there is still some staunch resistance from process participants who are scared of change, scared of being measured, or mostly scared of being replaced. I have experienced this behavior a number of times throughout the last decade, but this was the first occasion where someone was bold enough to actually articulate that they were not too keen on having their previously closed world pried open and laid out for the world to see. I think the project will ultimately be successful, but it is going to take a very strong client project manager, clear and unwavering support from the executive sponsor, and quick and responsive development iterations to prove the technology isn’t just Big Brother.
As the closer a process comes to being a core competency within an organization, it becomes exceedingly important to ensure that clear lines of communication are established, expectations communicated, and the desired end state is well known. As mentioned above, the use of an iterative development methodology provides an excellent tool to build early consensus and buy-in from the process participants. In implementations where the process participants have not utilized a BPMS previously, not knowing what the end result provides or will entail often drives a significant amount of the resistance to change. The playbacks at the end of each iteration go a long way in building faith in the development team, allow the process participants to become active members and provide early feedback, and, most importantly, identify any issues which may not have been previously known that could have derailed the end process.
While there will always be some people who prefer to live in the past and are exceedingly resistant to change, there are a number of techniques which can help to get a large enough community of people to embrace change and perhaps, just perhaps, even contribute to the continuous improvement of the process.