Change management: Getting your project past the wall of user resistance

Successful implementations depend on overcoming user resistance. The key is creating acceptance by making sure the stakeholders have the opportunity to choose the change and how it is implemented.

By Glen Ford

In everyone’s career, key experiences cause major attitude and habit shifts. One of these experiences happened to me when I was younger and thought I knew more than I do now.

One of my clients had a problem. The warehouse foreman was entering receipts and falling behind on his other work. The company president wanted a simple program that would enable purchasing to help enter the receipts.

Armed with the latest tools and techniques, I happily arrived to analyze the situation and determine the best solution. What was needed was a simple purchase order/receipt system. No big deal. Give purchasing the ability to gather the information without an increase in their workload. Everyone's happy, right?

Well, in a word, no. It started with complaints from the purchasing group. It was too much work, it was too slow, it was this, it was that—nothing substantial, just a bunch of bellyaches. My response was the typical IT one: resolve the issues where they meant something, bulldoze where they didn’t.

A month later, the programs were tested and passed all levels. Implementation was simple and took all of an hour. Everything was perfect…or was it?

The complaints started almost immediately. Purchase orders weren’t being entered in time. Purchase orders had the wrong product codes and quantities. The system was failing.

I went in to find the problem. The system itself was too simple to be buggy. It turned out that purchasing didn’t know what it was buying. They made orders based on requests from manufacturing, and the vendor would try to interpret what they wanted. The vendors were actually managing the company’s inventory. As a result, the warehouse would receive random orders of product, which more or less matched the requirements.

The system was a failure.

How it should be done
Let’s jump ahead a few years and look at a successful implementation. This organization was a not-for-profit in a monopoly position. For over 70 years, it had performed a required service under government mandate. Its leaders had always been engineers retired from the army. In short, it was tradition-bound, rigid, politically motivated, and highly resistant to change. Moreover, its systems reflected that. Effectively, they still used the same systems that the organization started with after World War I.

But life had changed. The organization was now in a competitive environment. It had to react quickly to the now-supreme market. And its systems had to change to meet that need.

First to change would be the core financial systems, which made up the base for our systems pyramid. The project would literally affect every computer and manual system and every individual in the organization. Making matters worse, politics in the organization had shifted. Decentralization was the word of the day. Worse, it was decentralization of people who had been mortal enemies. And it was my hot potato.

This time, I’d learned my lesson. I spent a great deal of time actively listening to legitimate problems and some bellyaches from those who would be affected by the changes. After I identified a pattern and researched the root case, I corrected it wherever possible. When a problem was brought to my attention, I acknowledged it, and then I asked for a solution. Instead of providing the solution myself or bulldozing past the problem, I assisted others in identifying a solution. In at least one case, I got into trouble because I wouldn’t limit the amount of time for discussion. Finally, the stakeholders and I spent a great deal of time communicating the issues. Rather than simply telling people what had been decided, I clearly communicated the “why” of the change and resolutions of the problems.

The result this time: a very successful implementation and a very strong team. Several of the team members remain friends to this day.

The differences in results
Why the difference? What happened to cause one project to be successful and the other to fail? Certainly, improved project management and team building abilities played their part. But the biggest difference was a shift in attitude. Previously, I had always treated the RC factor (resistance to change) as an enemy. In the second implementation, I accepted it as a natural part of the organization. I viewed it as an indication of other problems. Active listening and participation replaced “overcoming resistance.”

I’ve since learned that it wasn’t the organization at all. Of the four reactions to change—denial, resistance, avoidance, and action—resistance is one of the most valuable. It helps us to adopt only those changes that we perceive to be valuable. It prevents us from changing the status quo without good reason.

The concept that people naturally resist change is a fallacy. If it were true, we would never get married, move out of our parents’ basement, or have children of our own. In fact, people not only embrace change, they often seek it out.

We only resist change when it’s imposed externally, when we’re not given a choice. We attempt to reestablish the status quo and avoid the chaos that change sometimes involves. The key to acceptance is that the stakeholders choose the change and choose how to implement it. The best way to implement change without pain is by actively listening to the people who will be affected by the solution and ensuring that these people participate in the development of the solution.