Changing how you manage and communicate change

Focusing on the human side of change

Naomi Karten

• Publisher: IT Governance Ltd
• Year: 2009
• ISBN:
  9781849281270
• Topic: Business
• Subtopic: Management
• Index: Business

Transform the way you manage and communicate change in your business

How has your organisation changed recently? How did the people in it or associated with it react? Was it in exactly the same way?  Do you have more changes coming up?

People’s reactions vary depending on a number of factors, including personality types, misconceptions, their personal circumstances and the influences of their work and life experiences. This new book will enable you to recognise and accept these differences, and even harness them for the benefit of the business.

‘Changing How You Manage and Communicate Change’, written by speaker and consultant, Naomi Karten, is specifically for IT professionals and those working closely with IT. However, you will find that the experiences highlighted in this book apply equally to anyone in any industry who needs to lead change.

 

CHAPTER 1:
COULD THIS BE YOU?

The residents of a small village reelected the dead mayor. According to one resident, ‘I know he died, but I don’t want change.’¹

Whenever I mention this quote to people, they laugh. But often the laughter is accompanied by a nod of recognition. As amusing as this resident’s comment is, the wish that things could be otherwise is a universal yearning. Who, after all, hasn’t, at one time or another, wished that things could return to the way they once were?

People don’t like change. Obviously, it would be inaccurate to claim that no one ever likes change. Life is one change after another. If we couldn’t handle change, we couldn’t survive. Most of the time, in fact, we just go with the flow and adjust slowly or quickly to each new thing that comes along. But changes that divert people from their chosen path can be unsettling, even frightening, and every one of us has experienced changes that threw us off balance.

The customers of IT organizations accept some changes readily and others less so; not surprising, perhaps, given the vast number of business, staffing, regulatory, workload, and other changes they contend with regularly. But it may be the changes driven by IT that pose the biggest challenge for these customers.

At a seminar I once conducted for an IT department and one of its customer departments, an IT project manager

¹Boston Globe, 21 June 2008.

complained to the customers that they often took too long to respond to IT’s needs. The customer manager’s response: ‘IT is 100% of what you do. It’s not 100% of what we do. We have numerous responsibilities that have nothing to do with IT.’ Several IT people looked stunned, as if they hadn’t previously realized that their customers had any priorities other than the next IT-enabled change.

Surely, then, given IT’s role as an agent of change, one might reasonably conclude that IT professionals accept change readily and with ease: new development methods, changes in hardware and software, new requirements, outsourcing, and all the rest. In my experience, however, and as I’ll relate in this book, IT professionals are no less resistant to change than their customers – when it affects them.

So how do you respond to change when it’s happening to you? And how do you handle change efforts that will affect your employees and colleagues, your customers (if you’re in IT), or IT personnel (if you’re one of its customers)?

To help you answer these questions, this chapter describes four change efforts – all true stories – that ran into serious problems because of a lack of consideration for the people affected. As you read these stories, think about whether anything similar has ever occurred in your own organization. The chapter then proposes some explanations for why helpful communication is so often lacking during change.

A case study of a painful change

This story illustrates what can happen when IT personnel fail to take company employees – their internal customers – into account in implementing a major change. Sadly, it’s just one of many situations I’ve encountered of a difficult change made worse by the failure to communicate.

An IT organization planned a company-wide desktop upgrade, one that entailed on-site adjustments to most of the company’s desktop computers. The upgrade would be a considerable effort, but a worthwhile one that would benefit the company in cost savings, more reliable technology, and improved capabilities.

Glenn, the project manager of the upgrade implementation team, repeatedly asked his CIO, Russell, to send out a company-wide notice to alert everyone about the upgrade.² Russell refused. Trying to compensate for his CIO’s failure to inform employees, Glenn notified department managers himself, but he lacked Russell’s status and clout, and many managers ignored or dismissed his notice.

As a result, employees lacked an understanding of:

1 the reasons for the upgrade

2 how they would benefit

3 when the process would begin

4 how long it would take

5 who would carry out the upgrade

6 how departments could prepare

7 what would be different as a result of the upgrade

8 what they could do to minimize disruption to their work.

² The names of all individuals whom I describe by first name only have been changed, so that we can draw lessons from their experiences without embarrassing them.

What employees knew about the upgrade was basically nothing at all. Even managers knew almost nothing until Glenn contacted them to schedule the upgrades for their departments’ computers. Still, such things don’t remain secret for long. As soon as the upgrades began, the rumor mill went into action, circulating inaccurate information and distorting key details.

So, how did employees react to the upgrade? According to Glenn, they were furious, accusing him and his team of tampering with their computers and interfering with their work. They became even angrier – enraged in a few cases – when they had to cope with degraded system performance as the team resolved bugs and fine-tuned the network.

In addition, the help desk personnel, burdened with calls even during calmer times, were inundated. Their inability to keep up with questions and complaints exacerbated employees’ anger.

Why, oh why, are customers so unhappy?

I help organizations manage customer expectations and improve customer satisfaction, and I learned about this fiasco when I was invited in – by Russell, no less, who wanted to know why his customers were so unhappy with IT. Amazingly, he seemed clueless about IT’s contribution to his customers’ distress and dissatisfaction.

When I met with managers of several of the business units affected, I discovered that the experience was even worse than Glenn had portrayed it. Many of these employees didn’t realize the upgrade was a company-wide effort, convinced instead that their department had been singled out for technology abuse. They saw the upgrade as being done to them, rather than for them; as being forced down their throats; as being foisted on them with no consideration for their priorities and obligations.

Having spent many years in IT and many more years as a consultant to IT organizations, I know how difficult these large-scale efforts can be. I was hoping to find something in the situation that would enable me to empathize with IT and come to its defense. But I was unable to do so. In this situation, IT blew it.

The outcome? The reputation of the implementation team was damaged. But more than just their reputation was hurt. Unable to distinguish one part of IT from another, business unit employees now viewed everyone in IT as a bunch of blundering, thoughtless tech-heads.

So, who suffered in this botched effort? The employees who used the upgraded computers, of course. But clearly Glenn, his team, the help desk, and all the rest of IT suffered too. Employees in many departments had previously had no contact with IT. Now, with this first exposure to IT, their impression was decidedly negative.

Although advance notification from Russell about the upgrade would have lessened the damage, Glenn and his team were guilty of focusing entirely on the technical issues while ignoring the human impact of the change.

Moral of the case study

Change is disruptive. Even if you do everything right, major change usually generates a good bit of grumbling and grousing from those on the receiving end. But ignoring the impact of a change on those who will be affected, sets the stage for an experience that will be far worse for them – and also for those implementing the change – than it might otherwise be. And a failure to communicate appropriately and adequately with those affected, both in advance of the effort and as it proceeds, is a major flaw in a great many change efforts.

Making matters worse, the negative aftereffects of a failure to communicate significantly outlast the duration of the event in which communication was lacking. And you can be certain that how you implement a change this time will affect how people respond to future changes. A reputation, once damaged, is tough to recover.

How you implement a change this time will affect how people respond to future changes.

Three other painful experiences

Here, more briefly, are three other change efforts in which situations were made worse by a lack of consideration for the people affected, particularly in terms of communication.

Example 1: Just fill out the forms

Recognizing the need for a more rigorous approach to systems development, two IT directors introduced a new development methodology and sent IT personnel for training to learn how to use it. The training consisted of a sales pitch for the methodology, followed by a headache’s worth of slides depicting the detailed, mind-numbing forms that either IT personnel or their customers would need to fill out in the course of a development project.

In addition to the training … well, there was no ‘in addition.’ This so-called training was the extent of the preparation for this major change. Many developers quickly became loophole specialists, devising reasons why their project was an exception that could ignore the methodology or bypass some of its steps.

And IT’s customers? Never mind training; they weren’t even told that IT was implementing a new approach to development. Instead, customers started receiving forms from IT filled with questions they’d never before had to answer. Lacking an understanding of the questions, they simply left these sections blank. Use of the methodology remained lackadaisical for years, and systems continued to face delays and bugs that the methodology was intended to prevent.

Example 2: Spare them the distraction

Debbie, a marketing manager, was informed by her director that her department was going to be moved to another building where they would have more space than their current cramped quarters allowed. But she decided not to distract her staff with the news. They we...