Tell us, what is the first rule of thumb when you’re dealing with change management in your organization?
That goes along with what I’ve heard you say before too, in a past interview, that change management is about psychology not technology.
Ideally, you should start this process of change management before you ever implement any new technology. Would that be accurate?
That would especially be true with training, because if users don’t know how to properly manage the system, they get confused. They get frustrated. Naturally, they’re going to start resisting the system, resisting the change. Proper and thorough training must be critical to change management success then.
I see this idea of the internal advocates being like a tree where you start off with a small group of people and as more people learn about it, become trained on the system, and hopefully become really excited about how the technology is actually helping them. It’s like a tree branching out. You get more and more internal advocates then helping others in the change management process so they’ve even become more invested in the whole idea of helping to change the organization.
That’s a great story. There’s a lot of different ways that people can obviously manage change and brainstorm new and unique ways to do that. I also love that you said don’t forget about change management on the upstream because you have to lead by example, too.
Is it just the change itself that so many people are resisting? What is it that people are so resistant to?
But the devil is in the details!
Overview: 10 Tips for Change Management
1. Make the people part of the change
2. Start change management before you even begin implementing
3. Offer thorough training and make sure users understand the system
4. Identify, support and foster the success of your internal advocates as early as possible
5.Communicate internally the benefits of the system and any successes
6. Ensure upstream support and advocacy
7. Give people options that work for them and the organization
8. Utilize incentives often and counter-incentives when necessary
9. Identify and mitigate FUD up front-Fear, Uncertainty & Doubt
10. Don’t overlook change management-develop a complete plan before the system ever gets implemented
Welcome back everyone. I am here with Steve Weissman again. Today, we are talking about the issue of change management, and since Steve is the expert here, I’ll let him take it away.
Tell us, what is the first rule of thumb when you’re dealing with change management in your organization?
Well, I hit upon a formula a number of years ago that anyone with children will certainly understand.
I’m a consultant. I have to write on a whiteboard which we don’t have one of, but imagine the formula that change management equals parenting. That’s pretty much all you need to know.
Fundamentally, change management, like parenting, is all about trying to get people to do things they fundamentally don’t really want to do, except that you know it’s good for them if they do. It could be eat your vegetables. It could be clean your room. Don’t touch the hot stove, which is glowing red and oh, so pretty. Make sure you add the appropriate meta tags to your content, et cetera.
Anyone with children, or even without children but close to young nieces and nephews or the like, will recognize this pattern. That, without the condescension perhaps or the attendant frustrations perhaps that show on a day in and day out basis as a parent, you really want to approach behavior change in an organization the same way you would approach behavior modification with a young child.
Sounds silly, but it actually is true.
|That goes along with what I’ve heard you say before too, in a past interview, that change management is about psychology not technology.|
There’s no question that implementation success, beyond even just change management, is all about psychology, not technology. Poor attitudes, user resistance, certainly, cultural change that may be required because we’re looking at different ways of doing things all of that has more to do with the psychology of the people involved than the technology that you’re implementing.
This isn’t to say that not getting your hands around it means your implementation will fail. It’s rarely that dire where the initiative simply stops dead in its tracks, but you certainly will receive diminishing returns by not paying attention to the psychology piece.
It’s just so critical to make sure that people feel that they’re part of this process of change, that it’s not just senior management with some other big idea that’s being forced down their throats that they have to adjust to and, “Nobody even asked me.”
It has worked very well as a little bumper sticker over the years, this notion of, “It’s psychology not technology,” because the technology by and large is pretty good. It’ll do what you tell it to do. People, unfortunately, aren’t quite so open to raw instruction.
|I imagine that, ideally, you start this process of change management, then, before you ever implement any new technology. Would that be accurate?|
Yes. The earlier you get people involved in the process, the better.
So much of human reaction to change, even impending change stems from whether or not they feel like they’ve been listened to at any point along the way. Certainly, the sooner the better.
Let’s go back to “change management is parenting.” If you want to get your four year old son to leave the playground with a minimum of fuss and kicking and screaming, one thing that we often have done as parents is we will say to the child, “Two more runs down the slide, and then we have to go.”
“Oh, OK,” and they do their two more runs. Doesn’t mean they’re happy about leaving, but at least they may not make a scene, because you’ve involved them in the process rather than simply yanking them off the playground.
The same thing is true when it comes to technology implementation.
It’s just so critical to talk to people from all affected areas of the business about what their needs are and their impressions are, and dreams and aspirations, so that they do feel not even just that they feel but that they are actually involved in charting the course that this changes will take.
Then, you continue that throughout the process as you iterate your prototypes, or your interface screens, or whatever the issue happens to been at the moment. You want to continue to get that feedback, and you want to involve them at the backside by putting in place really good training materials, and help desk support, and the other things that they need to know that you are invested in their success, because it’s their success that will drive the success of your project.
|I imagine that would especially be true with training, because if users don’t know how to properly manage the system, they get confused. They get frustrated. Naturally, they’re going to start resisting the system, resisting the change.|
You can’t realistically expect people to embrace something new if you haven’t shown them how.
I know this from my youth baseball coaching. You send the kid out in the field, and you expect that they’re going to catch the ball, and throw the ball, and do everything they’re supposed to do, but if you haven’t taught them how, chances are they won’t be terribly effective at it. Doesn’t mean they can’t do it, or can’t pick it up on the fly, but to expect them to not throw the ball into the grandstand probably isn’t realistic.
You might get lucky, but who wants to plan for luck?
So, yeah, the training piece…You want people to know that this is different, and we’re going to make it easy for you to make the transition. By the way, we want people to know that we’re open to their inputs and suggestions. This guards against what I like to call, “We know what we mean syndrome,” which is to say that a lot of training manuals are written by people who helped build the system. They know exactly what they mean when they write something down about how to use the new technology.
They know where the buttons are on the interface screen. They know what’s going to happen next. They know how long it’s going to take.
We don’t as new users. So listening to what the users have to say, besides the fact that it makes them feel better, can be quite instructive for you, too, as the project manager, or the implementer, because they don’t necessarily know what you mean. So that’s huge.
|What’s the power of internal advocates?|
Well, you’re really looking to foster two things as early as you can.
As you mentioned, finding early adopters, or early converts to the new philosophy, to the new system, amongst the people, if you will, is vital because their colleagues are going to get more out of dealing with one of their own than they will by listening to even the most beloved of bosses. That certainly is key.
In a lot of cases, what you want to do is you want to identify that person, support them, and foster their successes.
Pick pieces of a process, for instance, that are almost guaranteed to work better once you apply the new tool and let that person become a hero in terms of his or her willingness to be the guinea pig and to celebrate his or her successes and to make it known that this person may not have been on board at first, even, but now is.
Here’s the great example. In a class that I taught to weeks ago, I heard a story about a group that proceeded floor by floor of the building that they worked in, in terms of rolling out the system. They identified such a person on each floor and actually produced a poster featuring that person and all the goodness that that person enjoyed by coming around and using the new system.
It was so effective, not in small part because one of the first people they chose to feature was a man approaching retirement age who barely knew how to turn his computer on. Once he understood what was happening, he seized the new philosophy and made it his own.
What ended up happening is everybody else on that floor said, “Really!? George adopted this thing? That’s unbelievable! He doesn’t even know how to turn his phone on! There must be something going on here I need to check out. That’s just too wild.”
There’s a great example of making a hero out of an early adopter and allowing that buzz to be created and that cross fertilization to occur.
The flip side of that is you want to do the same thing upstream. The bosses that had given you the green light to go and do whatever it is that you’re going and doing, you want to make sure that they too are in the loop, that they too understand what the successes are when they come along.
You really must be an internal marketing person. Not that you’re going to hide any of the tribulations that you face, because you’ll blow your credibility if you do that.
You really want to promote inside what you’re doing. When people are understanding and the results are being achieved, you want to feature those in the company newsletter. You’re going to tweet about it if you’re using an internal social media program or you’re going to produce posters. Whatever is suitable for your culture and your organization.
Make people heroes and let the world know about it. You can really make your life a whole lot easier.
|You mentioned that organizations should not forgot about going upstream. If you’re trying to change your employees, but the boss or the manager isn’t properly using the technology or isn’t using it at all, then that’s not really going to help foster the change effectively either, right? What are the best ways to guarantee success?|
The upper level executives don’t necessarily have to be users themselves, although that certainly helps.
More than their adoption of the technology or the process…A lot of this lives below where they operate, but having them on board… First of all, you need them on board even from the beginning or you can only get so far. What they can do, really, is open doors. If they understand what the goals are and they can appreciate the successes, they can do much more, perhaps, than you can to smooth out the rough spots.
If there are particular departments or people that are especially resistant…Here, we get into the notion of incentives and, frankly, counter-incentives.
If the senior vice president in charge of operations comes to you or your department and says, “You have to use this thing,” that’s going to get a lot more of a reaction than if you said it.
It’s not just usage as it relates to managing change upstream. It’s attitude. It’s support. It’s active participation in helping to effect that change.
Unless you work in the human resources department, you can’t just insert into the performance review of affected employees the fact that they will use the new system. There’s no better way to incent people to use a new system than to make sure they know they’re going to be graded on it.
You do need that buy in at upper levels, and across. as well; into HR, for instance. The flip side, the counterincentive, although you would try to avoid being that heavy handed about it, is, “Look. We’re not going to talk about this forever. You’re either going to use this or you’re going to get out.”
Again, change management is parenting. You try not to send your child to his room, but sometimes, you have to.
I come back to that same metaphor because it is just so applicable. You set it up for success. You give people choices but only choices that you can live with so that whatever they choose, it moves the process forward. The famous joke is you say to your child, “Why don’t you clean your room or something?” They go upstairs. Then you go upstairs later on, and they’re not cleaning their room. They say, “You said, ‘Or something.’”
It sounds goofy, but it’s a rule of parenting. Give them choices. They feel invested. But whatever they choose, it’s all goodness for you.
You don’t want to say to an employee, “Use it or you’re fired,” especially if you can bake the usage into performance reviews. Even just contests, employee of the month kinds of things. You get a free lollipop or a good parking space, some kind of positive recognition. It becomes clear who’s doing it and who isn’t.
If you have people who aren’t, the boss or whomever can take them aside and say, “Look. What’s going on? Nobody likes change, but there are reasons that we are doing this. Can I explain them to you better?”
Or something that makes clear that notion of just sitting there with your arms grossed going “Hmph!” is not going to be tolerated beyond a certain transitional period.
|Is it just the change itself that so many people are resisting? What is it that people are so resistant to?|
People don’t like change because it’s an unknown, whatever that’s coming next. The devil you know. That kind of thing.
But, a lot of times, if you can peel back the layers a bit, it’s a fear that they’ll under perform and be fired.
Especially in this economy, the notion that something unknown is happening that may cost you your job is really terrifying.
For others, it’s a matter of control, actual or perceived. Value to the organization. “Nobody knows what I know. How dare management foist this thing on me! They don’t know what I do.” It’s an invasion of their self esteem in some ways. “They didn’t even come and ask me,” which is why you have to start involving people early on to take that one off the table.
It’s fundamental insecurity. Maybe they already feel a little bit lost, and now there’s going to be this new thing. What if they can’t do it? Others thrive on it. Others see it as an opportunity to do more, to get noticed better, to become a hero and rewarded and recognized for it. You have to play into both.
The whole notion of FUD fear, uncertainty, and doubt. You have to find ways to build programs to mitigate that, while at the same time looking to build those incentives and the recognition in.
Positive reinforcement. That’s how we train our pets. Yes, I know. It sounds demeaning. I don’t mean it that way at all. But human psychology is such, people like to be stroked. A kind word from an unexpected place goes so far towards toward making your day.
What you want to try to do is build in opportunities for those kind words and that recognition. A surprise cookie on somebody’s desk when they’ve participated in somebody’s usability study or something. It’s not hard but it’s often overlooked because there’s so many other moving parts.
We come back to where we started, the notion of, “It’s psychology, not technology.” So much of the emphasis in redoing a technology based system is on the technology tools themselves. Do the integrations work? Does the metadata flow through? Is the findability where we need to have it? Does the process have bottlenecks, or have we ironed those out? We forget about the people side.
You can automate it to within an inch of its life. If people aren’t even that comfortable but willing to be open to embracing it, you’re only going to get so far an then we leave that extra value on the table.
|Interesting point. I always assumed change management must be hard, but you’re saying that it isn’t difficult, unfortunately it’s just often overlooked.|
There’s one other little gotcha. Another story I really like to tell. My students have heard this going back quite ways. Sometimes your incentive programs backfire if you don’t think them through. I know of a company that was offering I always forget if it was a Ferrari or a Maserati but some really hot car as a sales incentive. None of the sales people wanted to win. They didn’t want to win because the winner had to pay taxes on the car.
It isn’t hard, but it requires some dedicated thought and an actual program. The same way that you would document the roadmap for the technology or the governance structure for the content, you also have to articulate clearly what the change management program’s going to look like, what communications are involved, and by whom and at what stage. If you leave it to chance or to fate, it probably won’t happen, at least not to the right degree.
|What would be that very first step you would do to start mapping out that change management plan?|
That’s a really good question. I hate to default to the consultant answer, but it really does depend.
Change management has so much to do with the existing organizational culture that’s it’s hard to articulate a universal starting point.
If there is one, it has to be put on the table at the beginning. You have to make sure that it is as much a part of your project plan as the software development is. For sure, you can put on the task list, “We need to involve people from all over the organization that are going to be touched by this, as early as we can.”
Maybe that’s step 1A. Step one is have a plan.
Step two is start taking an inventory of where you want these people to be drawn from. You’re going to need end users. You’re going to need IT. You may well need your records managers. You’ll probably want someone from finance and HR. If this is a legal or e discovery oriented initiative, you’ve got to get somebody from that end of the world.
What about business partners, people on the outside that need to have access to your system and are going to be touched by this? There are a lot of questions to be asked that are hard to answer as a universal.
I guess I come back to step one. Have a plan. Step two, figure out who needs to be included in that plan, and then go from there.
|Do you have any final thoughts you need to leave us with here?|
Just to reinforce: If you have to simplify, remember that is psychology and not technology in most cases, and that that psychology boils down to parenting.
Have some fun with it, too. Just like with your kids, if you have fun with them, they’re more likely to internalize the lessons you want them to learn. I think the same thing is true here.
Meet the people where they are. Don’t force them to change, but make it easy for them to change by having some fun. Play games. Have contests. Do something silly. The work is, of course, very serious, but if they’re having fun, they might not even realize they’re doing something different because of the nature of beast. It becomes different and a lot less onerous. Have fun, I guess.
More by Steve Weissman: