Q&A: Real-life examples of successful change in the workplace

The biggest challenge to executing change successfully isn't culture, strategy or systems, but getting people to change their behavior. And people are more apt to change their behavior if they are shown a "compelling truth" that influences their feelings, rather than a data printout.

So say John P. Kotter and Dan S. Cohen, co-authors of The Heart of Change: Real-Life Stories of How People Change Their Organizations (Harvard Business School Press). The book, which will be released next month, was drawn from interviews with senior managers at more than 100 companies around the world.

Computerworld caught up with Cohen, a principal at Deloitte Consulting LLC, to talk about the mistakes managers often make when instituting change and steps IT managers in particular can take that lead to successful change within a company.

Q: What's the thrust of the book?

Author and consultant Dan S. Cohen
Author and consultant Dan S. Cohen
A: To take the eight-step model that John Kotter introduced in 1996 -- to increase urgency, build the guiding team, communicate the vision, communicate for buy-in, empower the workforce, create some short-term wins to reinforce progress, not letting up and making it stick. When you think about those eight steps, the theme throughout the entire model is how do you maintain energy.
The difference we've seen from successful change to not-so-successful change is that the people in the successful organization can make people in the organization see what's going on with eye-catching, dramatic encounters that helped individuals visualize problems and how to solve problems. That type of deep, emotional power. The excitement and the will to make the change happen as opposed to organizations that were less successful that took an analyzed approach where they simply dealt with numbers.
Q: What's an example of one of these "eye-catching" encounters?
Everybody wants to reduce the number of vendors and suppliers they work with. One heavy manufacturer was looking at its suppliers. They were using approximately 424 different styles of gloves throughout their plants, being bought at widely varying costs.
The team got a pair of every one of those gloves and they tagged them with the price and where they were purchased. They then laid them out on a boardroom table, showed them to executives to see what was going on in the organization. If they could reduce it to three or four gloves to meet most situations, they could reduce the costs of buying these gloves by 80% and save the company millions of dollars. That's the kind of visualization we're talking about.
Q: What is the "don't let up" step all about?
Classic story: A manufacturing company spent tens of millions of dollars, up around $80 million in the U.S., [starting with] two preliminary implementations of SAP overseas that went fairly well. They said, 'This is great, this is going to go in smooth as silk in the U.S.' And then the wheels fell off the trolley because people made the assumption that this is a piece of cake.
It took the CIO and several key managers to look at where they'd made a mistake in the configuration and testing of the software. The CEO of the division went after virtually every customer to talk about the delays they were experiencing.
But the CEO didn't leave it there. Once they got it fixed, he would call plant managers early in the morning to ask about inventory, production, why some products were overstocked, why they had outages of other products, etc. Eventually, the plant managers couldn't answer his questions. Plant managers said they didn't know how to view real-time information on their screens. So the CEO had the training manager call each of the plant managers about using the system, and eventually the plant managers were able to answer [the CEO's] questions, since they were able to use the systems effectively.
Instead of berating them about being unable to use the system, the CEO demonstrated to them why they needed to learn how to use the system and the benefits it could provide them.
Q: What are some of the key lessons for IT managers?
There's the whole issue of how they're managing the project. It really gets back to the issue of how they're involved. If the CIO is the executive sponsor on the engagement, and if that individual is not intimately involved in what's going on, the other executives [on a steering committee] will snipe at him or her. The project will run into problems.
To the extent that the CIO is able to work with the other executives, it's the active involvement in the project that's needed. So when the other executives comment that a project is behind schedule or didn't go right, the CIO can say, "Jack, this isn't behind schedule. We're actually two days ahead of schedule in closing the books." It's the knowledge of being able to recount that on an ongoing basis.
Q: What are some of the biggest mistakes that IT managers make with respect to change?
While change is important, most IT managers don't want to deal with change. What they'll focus on is that change is the technical solution. They don't want to hear about skepticism, they don't want to hear about reluctance [among end users to move to a new system].
Everybody will say that change is important, and when you look at the teams that are put on these large projects, the change team is typically a token team, just one or two people on it, to look at the soft stuff. The team members will look at the technical stuff, like the computer software. But they'll rarely look at how they're going to deal with resistance to a project. You put a change program in and you end up finding out that several times, the employees are just not ready for it because they haven't been trained properly or communicated to what their job changes are. So the project keeps moving on, and you backfill.
Q: What steps should IT managers take to prevent this from occurring?
One tip is to look at why you're doing [a project]. Is the software the driver or the enabler? Most people would say it's the enabler. If that's true, then the focus needs to be around the implications for the organization. What are the likely outcomes for the organization and how should they be approaching it, so that the project becomes the business leader's project and not the IT manager's project. When you look to sustain it, it has to be the business manager who's driving it, who's making sure it's implemented and being used in the organization.
The other thing that IT managers need to get focused on is the training that needs to occur and when it needs to occur. The training often trails the configuration. You get into unit testing, stress testing, etc., and you find you have some problems. Since the timing [between testing and training] is typically so close, do the training people have time to adjust to train the people? That's where you have problems, and IT managers need to be more aware of what's happening on the training schedules.

Copyright © 2002 IDG Communications, Inc.

7 inconvenient truths about the hybrid work trend
Shop Tech Products at Amazon