| March 2007 |
| By Chris Wain |
When we in Information Technology roll out something new, the benefits might be second nature to us. Our end users, however, may find the changes threatening. That’s where my job, Transition and Change Manager (TCM), comes in. People don’t necessarily resist change, but they do resist the loss of familiar tools and processes.
TCM consists of leadership and management practices that help users and their organizations absorb the changes, so that we enable the organization to more rapidly realize the benefits of our IT investments. TCM takes into account changes in three areas: processes, tools, and people’s jobs.
Here’s a sample scenario: IT is planning to deploy a new software application (for example, a new CRM module). The software will change how our business end users do their jobs, and the users are anxious about the change. For example, what IT touts as a “productivity improvement” could translate to our end users as a potential for “downsizing” (because not as many people will be needed to do the same amount of work).
Because changing things (like processes or tools) is faster and easier than changing people, I’ll start working with an IT project team early in the development process. There’s a rule of thumb that when announcing a change, we have to communicate it seven times in seven different ways.
For those communications to be credible and effective, however, we have to deeply understand the extent of the change. In one IT program, we identified over 200 different business process changes. Even after categorizing them as high-medium-low impact, some job functions still had over 50 major change impacts.
Armed with information like this, we develop TCM plans that include communications, then active engagement, and finally actual training on the new tools.
We communicate as early and as often as feasible in multiple forms: email blasts to users, newsletters, and manager communications. Research shows that information from an employee’s manager is the most credible, so we work to ensure the managers are on board, and develop presentations that they can deliver to their teams. This positions the business managers to help people deal with their losses and explain the potential gains the changes would bring.
Next, the active engagement phase is where we get traction. A typical approach is to have a series of sessions where the program team briefs the business users on changes. We ensure that it’s a two-way dialog; there’s time built in for the users to process the changes—and to tell the IT team where they need the most help, clarification, or (when possible) actual changes in the tool or process.
Training is most effective when held within 72 hours of the actual deployment of the application or tool. The earlier groundwork (communications and direct engagement) will ensure that the actual training can focus on “how-to” rather than “why-to.” And it helps ensure that the training session won’t degenerate into a series of complaints.
Also, as we approach the actual deployment date, we’ll have tracking systems and metrics in place that ensure that the vast majority of users have gone through the readiness steps (training, installing software, converting reports, etc). This ensures that when the change goes live, the business and the individual users are ready to run with it.
The bottom line - changes must be carried out by individuals or groups of human beings, and there are predictable human dynamics involved. Ignore the dynamics, and we compromise the business results. Make the human dynamics work FOR the change, and we get a faster return on our investments in new IT capabilities.
If you would like to submit an article providing an insider’s view of your tech or engineering job, please send your article to us at ITtrenches@dice.com.
Comments on this article? Share your feedback on our discussion forum, Dice Discussions.
*Please note, you must be a registered job seeker in order to submit your question to Dice Discussions.
|
|
|
