I have recently been involved with a community of users who
experienced a drastic change in one of their applications overnight. Even
though they had been warned of the impending changes, and some of the users
actually had input into the process, the change has been overwhelming to many
As to be expected, there has been much wailing and gnashing
of teeth and cries for things to go back to the way they were. While some have resigned
themselves to learning the new system (grudgingly), others swear they will never
use it and some have embraced it for all the reasons that initiated the changes
in the first place. So, was this a good roll out, a failed roll out, or
something in between?
Before we answer that question, let's talk about change in
general. Everyone tends to believe that people hate change. And while hate may
be a strong word, people often tend to look upon change with a less than
Why is that? There are dozens of reasons, but here are some of the leading candidates:
Fear of the unknown, loss of control, fear of being made to
look "stupid", loss of knowledge/feeling worthless because what you
knew is no longer relevant, change in your routine, forced learning, bad past
experiences with change, rigid thinking/lack of flexibility.
Given the reasons above, you have to wonder why we attempt
change at all. With all the negativity surrounding change, isn't any major
change destined to fail? The answer to that is not necessarily. The better way to phrase the question is "isn't
any major change subject to failure?" And that answer is a resounding yes!
As IT professionals, we must always be cognizant of the fact
that no matter what you are doing, change is a risk factor that must be
accounted for and managed. Even if the changes are completely and positively
for the better, they will be resisted, often quite vocally. And even the
smallest modification can cause a maelstrom of discontent far exceeding the
magnitude of the change, if it isn't handled right.
So how do we manage this change? To answer this, we must
look back at our reasons why people dislike change. One theme is fear of the
unknown and a loss of knowledge. You combat this with information. Unless you
have a VERY strong reason for surprising people with change (those situations
do exist) you should precede change with lots of information.
Inform those to be affected why changes are being made, what
they are, and how things will work differently. Don't be stingy with your
information either. While there should always be executive summaries available of
what you are planning to communicate, you should be ready with more verbose
explanations of the change. One behavior that people engage in to calm their
fears is to garner as much information as possible about it. Don't let people
starve for this kind of information. The more you can provide, the better the
Besides providing information, you need to control your
change schedule. Even people who are more accepting of change often dislike sudden change. If at all possible, make people
aware of the schedule, and make it as gradual as possible. Shock and awe might
work in a military campaign, but it is usually bad for change management.
Include change-affected users as much as possible in the
planning stages. Not all change fits this category, but if you can get active
participation in the development, you will have allies in the audience that can
share their knowledge with their coworkers and thus buffer the response to
Lastly, communicate during the change process. Listen to and
respond to comments, both good and bad. Even if you provided tons of
information prior to the changes, keep information flowing and show that you
are listening—even if it is just to say that you understand their concerns andyou will try to help them through any issues the best way you can.
As a government IT professional, you must be prepared to
deal with an enormous amount of change. From your role as a change agent in the
organization, to the fact that wholesale changes are often thrust upon you due
to politics and differences in administrations, you have to be prepared to
manage change to achieve successful outcomes.
As far as the example given to start this article, the
jury is still out. It sometimes takes a while to judge the results of changes,
but my gut tells me this is going to be one of those in-between roll outs.
Keep up with the issues and challenges that uniquely affect
public-sector IT with TechRepublic's free Government IT newsletter,delivered each Tuesday. Automatically sign up today!