It's common for folks in IT to claim stakeholders are resistant to change. But maybe the problem lies in the way the change is rolled out.
Ask anyone in IT management about change, and you will likely hear some tired bromides about how people inherently resist change, how change must be "managed," or perhaps how those darn users just won't "embrace change." You will also likely get some amateur psychology or allusion to the latest business book that discussed how deep within our DNA we inherently fear change.
It doesn't take a medical degree to realize that people don't inherently "fear" change. Should I offer to inflict some change on your life by giving you a check for one million dollars, I would imagine fear would be one of the last emotions you would feel. Rather than having an innate fear of change, the human race has evolved to constantly make the evolutionary equivalent of very rapid cost/benefit decisions. In the case of IT-driven change, the high cost of attending training sessions, learning about a new system, and adapting ones' daily routine to the new way of working usually outweighs the benefit an individual perceives they will receive. The user community on the whole is not a group of cowering curmudgeons; rather they resist change because you haven't done a compelling job of selling it on an individual basis!
Not only must you provide compelling benefits, but these must be presented at an individualized level, especially to key players who can shape opinion about the new system or process. While one or two people get excited about the litany of benefits and cost savings targeted toward the corporation as a whole, most take what seems like a more cynical approach, asking in effect: "What's in it for me?"
Traditional "change management" efforts lack the magic bullet of focusing their appeal to users on an individual basis. These efforts treat the community as a gelatinous mass, to be slowly coalesced and pushed in a single direction. When operating in this way, change is something you "do" to people, rather than an individualized appeal performed on a personal level. While at the end of the day, users have little choice as to whether they use a new system—without a personal appeal you are always on an adversarial footing. This nebulous blob rarely has a personal stake in an implementation's success and, as such, tends to hold the system to an unrealistic standard and, in some cases, relish each missed objective and secretly root for the implementation's failure.
While detailing the high-level benefits of a system is great and key to a successful business case, producing targeted, personal appeals to key stakeholders and your largest groups of users is far more important to successfully implementing change. No fancy books or methodologies are necessary here; the simple act of having ongoing individual conversations with key stakeholders, followed by spending personal time with each segment of the user community, will help you determine what individualized appeals are necessary, not to mention build trust that each group's needs are being listened to.
The latter is an underemphasized point within IT. We are perceived as "experts" tasked with implementing a new system or process and often don't see the need to spend a day or two in the shoes of those we are going to affect. Spend a half day in the call center listening to calls or jockeying the cash register at one of your retail outlets, and you will quickly learn what kinds of appeals are likely to sway each user group.
When you make a successful personal appeal, a magical thing happens: Users become personally invested in the success of your new system or process, as they now see themselves as individually involved and accountable for its success. The inevitable errors and omissions are disregarded or met with far more understanding than would be expected by an uninterested user being beaten into submitting to a new system. When the majority of your IT department starts presenting its activities in terms of the personal appeal, "change management" becomes embedded in your organization. The quality of your implementations also improves, since IT personnel are more able to understand, relate to, and address users' concerns.
At the end of the day, when your users see you as a collaborator with their best interests at heart, they embrace and run toward the new system. Change no longer is something to be "managed," but something your users relish and look forward to.