The Real Fear Factor

When asked what makes them most anxious, people may answer public speaking, flying, heights or even spiders. But from my observations, the one thing that causes the most stress is change.

I happen to like change, even embrace it, and believe change is necessary. Without change, there would be no innovation; no new technology. And since working with technology is both my profession and passion, change is extremely important to me.

So why do many people resist change? What are they afraid will happen?

Fear Factor

One reaction to change is fear of the unknown. On the whole, people are comforted by the familiar and wary of the unfamiliar. Even when the familiar is flawed and change promises improvements, fear of the unknown seems to take precedence and causes some to resist change.

In fact, some people are so fearful of change they will fight to prevent it. At the very least, change raises the stress level for most people, even if they recognize that change is necessary.

In any event, these reactions raise significant issues for project managers effecting changes. Addressing people's reactions to change is perhaps the greatest challenge for project managers.

The Change Compromise

An interesting phenomenon I've observed over the years is what I call the change compromise. This typically occurs when problems with existing processes or services become so intolerable they override the fear and anxiety of change.

But there's a twist. Changes made in this situation are usually very simple and generally ones that were made before. This makes the change more familiar, which somewhat mitigates the anxiety. Unfortunately, these changes are usually inadequate and rarely fix the underlying cause of the problems.

One example of change compromise I experienced was at a former client. The company had been struggling with ongoing problems with their consumer-class hosted email service. Messages were delivered late or not at all, and there were many service outages.

These email problems were cyclical, occurring every few weeks over an 8-year period. When the problems became intolerable, the company would just change their email provider. It was a simple change and one they had made before.

Changing to the new email service provider seemed to alleviate the problems—at least for a while. The perception that the new email service fixed the problems regrettably reinforced the viability of the change, making it the familiar and acceptable response to their ongoing email problems.

A New Approach

After repeatedly changing their email provider only to experience the same problems over and over again, the company realized they needed help and hired me to fix their email problem once and for all.

When I learned of their previous attempts to fix their email system, it was obvious that simply changing email providers was not effective. I decided the best approach was a root cause analysis to determine exactly what was causing their email failures. This included researching and documenting the current email system to gain a thorough understanding of how it worked, which was very time consuming.

My approach shocked some of the client stakeholders. Their expectation was that we just needed to replace the email provider again, relying on my knowledge and expertise to pick a "good one." I assured them that this was part of my approach, but we needed to go further.

I was about to break their comfort level by introducing a new and unknown change. It was very unsettling.

I discovered the client had a more complex email system than they realized. They were using two separate providers (one for sending and one for receiving email) for some locations, and two locations were each using their own internal Groupwise servers. Plus, some people were using their personal email services such as AOL since the company email service was so unreliable.

The final solution was to implement a single business-class hosted email service for sending and receiving email that was used by the entire company. This greatly simplified email system administration and maintenance and reduced the number of potential points of failure. The new service reduced spam, improved email security and storage management, provided a 99.9% service level, and was fully documented.

But the new email system wasn't accepted at all levels. Some people were unsure of the new system and preferred the old one, even if it didn't work well. The AOL and personal email users were reluctant to switch. It was understandable given their prior experiences with changing email providers.

Although we kept the stakeholders in the loop during the project, we were still faced with the challenge of acceptance. But, as people used the new email system they realized its value and most everyone overcame their fear of change.

The ITIL Relationship

If you've read this far and have knowledge of ITIL service management, you may have recognized some familiar terms. ITIL describes processes for addressing service failures or disruptions (Incident Management) and resolving underlying problems (Problem Management).

To resolve a problem, ITIL suggests determining and documenting both the problem and the root cause, developing a work-around and ultimately a full resolution. A root cause analysis finds the fault in the service that caused the failure or disruption to occur.

By following these guidelines, you can greatly improve the success of your efforts to resolve service problems. Successful problem resolution can lessen the anxiety that accompanies change, especially if people are confident that the change will improve their ability to do their job.

This is the promise of ITIL. Rather than a "hit or miss" approach that may or may not work, the guidelines described in the ITIL framework will help you improve your IT services. And with the advent of the V3 lifecycle model, ITIL brings continual service improvement to the forefront utilizing a Kaizen philosophy.

Hopefully, we will finally be able to ease the fear of change. Now, if we can only do something about spiders?

By Harry Hiles, HBH Technology LLC — 9 Dec 2008

---