You’ve probably heard that people hate change. Not true. People choose change all the time. What people rebel against is coercion and forced change. What people resist are requests that come from someone who said, “Trust me, it will be a seamless transition,” the last time.
What can you do to ease the change when there’s a mandate to migrate to new software? You should involve people in planning, mitigate time spend fooling around with the tool, and make it as easy as you can to get people back to being productive at work.
But that’s not as easy as it sounds, especially since the people who are receiving this wonderful new software are not like you (and me). Most people who have self-selected into technology careers — the ones writing and rolling out new software — don’t mind playing around to learn new software. In fact, we rather enjoy it.
The rest of the world ain’t like that.
To most of the world, software is a tool, a means to an end. Anything that forces someone to pay attention to the tool rather than their goal is fodder for frustration. If you’re leading a migration project, keep these points in mind:
- Futzing: Poking around and figuring out by trial and error is only fun when it’s a choice. Leaving people to learn new software by trial and error experimentation is inefficient and ineffective. Beyond that, it’s a pain in the tush.
- Fiddling: Trying out new settings to see how they work is fun, right? Not so much. Suppose you don’t know the meaning of all the settings and options, you forgot what you learned last time you had to set up a computer, or you frankly don’t care because you just want the dang thing to work. Then fiddling with software settings so it works the way you want feels like being lost in a maze.
- Finding: Where the heck to things go, between one major release and another? Why does new navigation make it impossible to find stuff? I don’t know; I do know that the time spent finding items that used to be under one menu and is now three levels down in another is a pain.
Any of these — futzing, fiddling, finding — is enough to cause Frustration. Pile them on, and you have one big #FAIL.
Beyond getting new software on to the computer, we need to focus on ways to minimize tool time and get people comfortable and capable with the new software.
One of the most successful e-commerce sites in the world rolls out new features to their least valuable customers first. That may seem backward, initially; but when you think about it, the decision makes perfect sense.
Each new feature makes it debut where there is least risk of depressing revenue. Engineers study the crap out of each small experiment so they understand the positive, negative, and utterly unintended effects. Then they make refinements until they have the feature ready for prime time. For example, they know that the people who are least likely to spend much money are people who don’t have a web cookie on their browser. But they don’t try with all the cookie-less people who visit the site. Their first experiments are with fewer than 1% of their least valuable customers.
And you should follow this philosophy in your Windows 7 migration.
Start your roll out with an area that doesn’t have first-line contact with customers, high-finance, critical deals, or operations. I do not want to imply that any group is unimportant to a company’s viability — but will revenue plummet if human resources, legal, or accounts payable slows down for a few days to learn new software? (You may choose differently if your company is in the middle of a lawsuit or due diligence for a merger. But then, both of those count as critical deals.)
When you do your early experiments, notice what people struggle with, where they get stuck, and what they take to like a duck to water. Notice responses that are unexpected and surprising. Fold all that information into the next rollout round.
Once you’ve done a few experiments, you will know more about the problems people are likely to encounter. And you’ll have some success stories to share. Now is the time to plan for the big rollout.
Chances are that the demands of the business will not slow down while people learn the new software. New software isn’t an exciting new opportunity; it is a stressor. There is no perfect time to transition to new software — but there are worse ones, and those are the ones you want to avoid.
Involve the people who are affected in identifying the least bad times, and schedule installation for least over-lap with periods of high-volume or tight timeframes. People don’t resist change, they resist coercion. So let the people who will feel the pain pick the time. They will be more inclined to make things work when they’ve had a say. Funny that.
Customize and Focus Training
Most people use a fraction of the functions in any piece of software. Some of those functions will be the same across the company. But some of the frequently used features will be unique to a work group. Customize the software training to focus on the features that are relevant to each group. Start with the functions they rely on most, and cover the rest in priority order.
This will help reduce the futzing and finding factor.
Also, tell people what won’t change. A colleague told me about a major organizational redesign at a chip company. The lab layout changed, job responsibilities changed, reporting relationships changed. Everything changed, except the color of the static coats worn in the lab. That may seem trivial; to the people experiencing the change, it was their one bit of solid ground.
Leave Some Help Behind
A one-hour overview isn’t usually enough to bring people up to speed. Neither is a one-day workshop. People need time and practice to integrate new learning. But don’t make them look everything up in the binder, manual, or on-line forum. That’s tool time that takes people away from their goals.
A custom cue-card that matches each group’s need will reduce futzing and finding.
Better yet, leave a power user behind in the department for a few days to be on-site and available immediately to answer questions, guide, and coach. A power user is the kind of person who can cut the fiddling factor.
The stay-behind-support person can also create Information Radiators to make it easy for people to find answers to their questions. Information Radiators work on two levels. First, a question and solution Information Radiator lets people know they aren’t alone in having questions, which makes it easier to speak up rather than struggle on. Second, when questions get answered quickly, the anxiety level goes down. It’s even better if someone from within the group can provide the answer. That expands the pool of knowledge and begins to establish confidence that group members can help each other. It also shows they are building proficiency.
Is this more work for the implementation trainers? You bet. But it also means accelerated productivity for the groups who keep the business afloat. And that’s what it’s all about.
Direct costs of the software conversion are easy to count. Costs of lost productivity are harder to count. The cost of damage to the partnership between business and IT organizations is catastrophic. You can’t eliminate the pain of a software conversion; however, you can reduce the time people have to spend futzing, fiddling, and finding. Sure, some people will be frustrated. That’s inevitable. But when you focus on the people, you’ll avoid the big #FAIL. You may even learn something useful and make some friends along the way.
Want more like this? Sign up for the weekly IT Expert Voice newsletter so you don’t miss a thing!