Anita Collins has led ITS’ Change Management team for 12 1/2 years. The Chapel Hill resident is a Certified Change Management Professional (CCMP).
“One of the things I love most about my job is that I learn something new every day, whether it’s how a process works, how someone does their job or a new way to do something change management-related,” she said.
In this first-person piece, Collins introduces you to change management so you too can learn something new.
A quick Google search will result in hundreds of results explaining why change is hard, how we should have a better attitude about it, and how we’d better get used to the manic pace of change. Why is that, though, and what can we do about it?
Why change is hard
When thinking about IT projects and change, I really like Peter Senge’s quote: “People don’t resist change. They resist being changed.” The quote gets to the heart of one big reason people don’t like change. They want to choose to make changes, not be pushed into them. They also want to be prepared for change. That’s because as adults, we don’t like to be embarrassed by making mistakes. We want to be experts, not “newbies.”
When we roll out technical changes, we often can’t let people choose whether they want to adopt the change. Often, the software goes live, and everyone makes the change that instant.
We do have some options for helping people feel like they have some control, though, and we can help them feel prepared. For example, we can include representatives of the user community on our project teams. We can use surveys and other feedback mechanisms to gather input and hear concerns. To make people feel prepared, we can spread the word early. We can communicate often and in different ways to increase our chances of getting heard. We can provide support materials to help people remember what they’ve learned.
The more we prepare people and get them engaged, the more we might find that people don’t mind change as much as the internet says they do.
Change is a process
It’s easy to think of our user community as a single entity, one big group running to the finish line that is our project’s go-live date. But there are two important things to know about how our user community experiences change: change is a process, and each person goes through the change individually.
Let’s talk through that. You may have heard the acronym “ADKAR.” ADKAR stands for the process people go through to accept change:
- Awareness
- Desire
- Knowledge
- Ability
- Reinforcement
To accept a change, each person has to go through those steps in order. First they have to be aware that the change is happening and it will affect them. Then they need to want the change (or at least think it’s necessary). Then they need to learn about it, and so on.
For example, let’s say I hear about a change coming that affects me but I don’t think it’s a good idea (Desire). You can talk to me all day long about where to click (Knowledge and Ability), but I won’t hear you. Before I can learn how the new thing works, I need to believe it’s necessary.
To complicate this, remember how we said every person goes through change individually? Every person going through the change is going at a different pace. While some people have read everything we’ve put out and volunteered to be testers, others don’t even know the change is happening.
Understanding these things helps us plan for better communications. It’s why we need to communicate frequently and in different ways. It’s why we want to start communicating early. And it’s how we can help the first person across the finish line and the last have the best change experience possible.
The myth of “one size fits all”
When working on ITS projects, we often talk about “the users,” but it’s a rare project that lets us communicate with everyone as one big group. When preparing to communicate about a change, the first step is to understand who is affected and how. You want to identify the groups of people you’ll need to provide different information for. For example, let’s say you’re rolling out a change to a purchasing system. People who buy things need different information from those who approve purchases and those who process them in the central office.
It can be tempting (especially under deadline) to put all information together, thinking “they’ll figure it out.” But when people are learning about a change, they’re thinking, is this something new or does it not apply to me? To get the information to stick, we want to tailor communications to each group. It takes more time, but it increases our chances of being heard.
Why you’ll rarely see my name as the sender on a communication
I write a lot of communications, but I rarely sign my name to them. Here’s why. We’re all hardwired to trust certain people to deliver messages to us, and those people are usually not project managers, change managers or technical leads. If we’re hearing that our job is changing, we want to hear that from our managers. If there’s a change to our department (such as a reorganization to ITS), we want to hear that from our Chief Information Officer. If something is changing about the University, we want to hear that from University leadership.
There are some messages a project manager or technical lead can send. For example, if you’re working on a project and it’s behind schedule, you’d expect a project manager to send that message. But on the other hand, if that delay means you’ll be working on the project for several more months than expected, you’ll want to hear that from your manager.