by Jim Minihan, Document Magazine
09-05-2008
If ever a project demanded a “change management” program, it is a BPM (and yes, workflow) strategy. Like many other IT projects, the footprint of your BPM plan can be both large (meaning many people) and deep (meaning each of those people are interacting with it day to day). Equally important is the fact that the new BPM application will also be tied to some legacy application(s) as part of the implementation. Consequently, you have many potential dimensions for project failure. Of these, the people dimension is the most difficult to navigate. Therefore, that is why you need a change management program as a key ingredient for project success. Such a program must be part of the planning stage and not simply an implementation phase courtesy, as is often the case.
A change management program has three components associated with it. In the first phase, you will have to overcome organizational inertia by attempting to dismantle the current mindset and providing justification for opening up to the new system. While some practitioners would call for communicating the “why” of their actions, I look to enroll people into what I call the “destruction phase.” Simply put, as part of the process analysis, I ask for everyone’s view of what is wrong about the current process. Not in an antiseptic, “find out what is wrong” way. No. I mean in a “doesn’t that frustrate you? Give them a reason to hate the status quo” way. We want to dredge up the pain they have become numb to, which serves two purposes. First, I can get better information about what is wrong with the current process. The more you can expose all the ways a bad process affects their day-to-day performance, the more people will be reminded of how bad it has been and the ridiculous things they do because of the old adage, “We always have.” Second, this approach is ground softening for the arrival of change. You want people to hate the old way so they are more likely to embrace the new process. If you don’t overcome the usual organizational predisposition for leaving things alone, people are more likely to fight to keep it. This means the new process (and application) becomes the target of everyone’s ire. This is by far the number one reason for project failure, especially in BPM. Including as many people as possible in defining the new process and “how” it will be achieved goes a long way toward user “buy in” and should be accomplished during the analysis phase.
The second phase is the change itself. It starts with deploying the new system, training users and learning the ins and outs of the solution. There are many issues to discuss here, but the basic one is to resist the temptation to make modifications too early simply for the sake of responding to user issues that spring up from a lack of familiarity. BPM is never a static system. Let everyone know that you will be sticking to version one of the deployment for at least six months. This is a difficult time in the best of circumstances but can be made more so if phase one was not properly accomplished.
In the third phase, efforts are made to keep the momentum going to achieve routine operations. Sometimes called the “refreeze,” the focus here is to share success stories, shortcuts and the “cool stuff” that was not apparent initially. But be careful not to refreeze too hard. Entering the BPM world means you are never done optimizing and your organization has committed itself to agility… yet another change management message to get across.
Download: Full PDF Article