Change and Getting to Return on Investment
Jayne Andersen, an expert on organizational change, stood before an assembly of managers in Seattle at the 2003 Best Practices conference hosted by the Center for Information Development Management (CIDM) last fall and pronounced the truth that many already knew from experience but continued to deny.
“When you introduce a change into an existing system, productivity is going to get worse before it gets better,” she asserted. “The disruption will cause a drop in productivity as people react to the change and learn how to do things differently. It will take time, sometimes months, before you start to see the increase in productivity you expected and begin to realize a return on your investment.”
That’s not the message that technophiles want to hear, especially at a conference with the theme “Innovation: Making It Happen” hosted by the system thinkers at CIDM. But that’s exactly why CIDM had invited Andersen to speak. It was the message technophiles needed to hear, a message not about technology and systems but about people and behavior and change.
Bricks and Bikes
Andersen, an internal consultant for HP, is a specialist in Management of Organizational Change (MOC). Many changes today come through the implementation of new or improved systems and processes. MOC is the soft side, the human factors side, of these types of implementations. It is the part that doesn’t fit nicely on an Excel spreadsheet or graph well on Microsoft Project printouts. Employees’ personal responses to these changes can’t be scheduled. But preparing for and managing the implementation to accommodate user reaction can make the difference between a success and a career-damaging flop.
“Suppose you have a job carrying bricks from point A to point B,” Andersen said. “You get paid by the brick. Your productivity is measured by the brick. One day your boss comes to you with a bicycle and says that you can carry more bricks and be more productive if you use that bicycle to carry bricks.
“Anyone who has ever learned to ride a bike knows that when you first start out, you aren’t going to be more productive. You’ll swerve all over. You’ll fall down. You’ll wonder who ever thought the bike was a good idea in the first place. Instead of being more productive-moving more bricks-you actually deliver fewer bricks. While you are learning to ride, your productivity goes down.
Now suppose you are the boss. You should expect a drop in productivity while your workers learn to ride their bikes. If you aren’t OK with that drop, if you pay your workers less or penalize them for taking time to learn to ride, then they will abandon the bikes and go back to carrying the bricks by hand. That way their productivity won’t drop but neither will it improve, and the money spent on bicycles will have been wasted.”
Though it seems counter-intuitive when a “better” system or process is introduced, managers and implementers should be pleased to see their precious metrics shudder after the introduction of a new system.
An initial drop in productivity may actually be a good thing. It doesn’t mean that the system is a failure. It means employees are engaging the system, trying out the new processes, and learning how to do things differently.
Andersen knows from personal experience that a productivity hit may be a hard pill for top management to swallow. She has seen organizations so sold on the benefits of their changes that they denied the impact on productivity. To anticipate only benefits, Andersen contends, is to deny human nature and people’s natural response to change.
The Transition Cycle
To help her audience better understand what happens during any change and how that relates to the drop in productivity, Andersen shared a model that she’s used and personally experienced. The challenges of change are nothing new, and they have very little to do with technology. We’re good at building new tools and processes, but change typically fails with regard to people and their behaviors in response to change-that is, the softer side of change. Andersen brought this point home with a quote from Niccolo Machiavelli, the 15th Century Italian philosopher and royal advisor whose trim little book on political expedience has become a classic.
In The Prince Machiavelli wrote, “It must be remembered that there is nothing more difficult to plan, more doubtful of success, nor more dangerous to manage than the creation of a new system. For the initiator has the enmity of all who profit by the preservation of the old institution and merely lukewarm defenders in those who would gain by the new one.”
Andersen shared a second timeless quote from another revered thinker, Henry David Thoreau, the 19th Century minimalist philosopher from Walden Pond.
“Things do not change,” Thoreau wrote. “We change.”
Standing up in front of a group of techno-advocates, Andersen could almost read their thoughts. “We change all the time,” they were thinking. “We change technologies every year. Heck, we change systems almost every month!”
Andersen was ready with an MOC counter. While everyone focuses on incorporating new technology and building new systems and processes, they perennially overlook the third component of change-behavior. This type of change isn’t a success until the behavior of the users changes from resistance to acceptance.
“There are many changes occurring within the content management world,” she said. “These changes are being brought about by the introduction of new and improved processes, systems, and tools. To reap the benefits and realize a return on investment, behavior changes are required.” See Figure 1.
Figure 1. Three Components of Change
Scholars of organizational dynamics have studied the way people react to change and found a predictable pattern that system designers would do well to heed if they want to realize a return on investment sooner.
MOC gurus Cynthia Scott and Dennis Jaffe, authors of the business bestseller Managing Change at Work, codified this pattern as the Transition cycle. The cycle is a map of individual reaction to change-a sort of sine wave of self-interest that starts with denial and resistance, then progresses as exploration of the new system leads to acceptance and commitment. See Figure 2.
Figure 2. The Transition Cycle-a Pattern of Reaction to Change
Looking out at her audience, Andersen knew that every manager there had personally ridden this roller coaster of change, some of them many times. And though they knew the truth of the Transition cycle for themselves, she was equally sure that they may well deny the users of their systems the time and grace to work through the Transition cycle for themselves.
Andersen posted the key points that she wanted the managers to remember about the Transition cycle:
- Transition will likely occur with any change, even if the change is a desired change.
- Every journey is personal. Each individual must work through the cycle in their own time, in their own way, and to their own degree.
- There are no “bad” steps in the Transition cycle. Each is important.
- You can’t skip steps. It’s important to process through each step to reach commitment.
- Most people find themselves oscillating between steps, especially between resistance and exploration.
- Avoid asking or requiring a jump from denial to commitment. Typically, that will result in compliance but not commitment.
At this point in the presentation Andersen had shared two important concepts. First, with change typically comes a drop in productivity, and second, there is a model that can explain how people process changes internally. Part of the drop in productivity is due to learning to do things in a different way. Part can be attributed to individuals processing the changes internally. In other words, going through the phases of the Transition cycle. Andersen didn’t want to stop there. She wanted to share what managers can do with this new information.
Prepping for Change
Andersen outlined simple, sensible steps that system designers and implementation managers can take that will ease and help prepare users for upcoming changes.
While any true change will always involve a transition period, there are things that you can do to start the process earlier, shorten the transition period, and minimize the degree of disruption during the transition. The good news is that these same things will also help to minimize the drop in productivity.
- Encourage participation. Provide opportunities prior to implementation for users to assist in the development of the processes and tools. Participation creates ownership.
- Communicate. Communicate throughout the development process, including after implementation. Use communication to set appropriate expectations. This minimizes the disruptions.
- Provide training. Provide training to give users the skills they will need to be successful. Helping users see how they can succeed will accelerate the change, and developing their new skills early will help them learn more quickly.
- Encourage hands-on play. Provide opportunities for users to “play” with the new tools and processes before they actually have to use them to do their jobs.
- Make a firm commitment to change. Maintain a high level of commitment throughout the development process, including after implementation. Change that is viewed as optional is rarely successful.
Implementation is a Beginning, Not an End
Most of the activities that occur during the development process involve creating or improving processes or tools. During this time, change is still only an intellectual experience; users are not yet required to change behavior.
A part of the change process that is often overlooked or minimized is what happens after implementation. Developers who focus on technology and systems frequently mistake the implementation or “go-live” date as the grand finale of their work. Yet, as Andersen pointed out, go-live represents a new starting line, not the finish line. The majority of the behavior changes actually must occur after go-live, a period during which change becomes experiential rather than intellectual. This period after go-live is also when the change is most at risk of being aborted or delayed. See Figure 3.
Figure 3. Transition and the Development Process
Andersen saw some knowing nods and a few uncomfortable smiles in her audience when she said, “You can’t just throw it over the wall and say, `We’ve done our job.’ Go-live represents the start of the Transition cycle, the place where users begin to shift their behaviors-the way they do their work-to accommodate and incorporate the new system and processes.”
Go the Last Miles Together
Too often, businesses pull designers off a project when the go-live date is reached, leaving no support for people as they begin working with the new systems and processes.
Andersen compared creating a system to running a marathon. It’s an exhausting 26-mile race, and go-live happens at about mile 24. We get our changes developed that far, then hand them off to users and expect them to walk the last miles on their own. It should come as no surprise when it doesn’t go well, and users reject the changes. Then all that effort is wasted.
If you keep your designers on the project after go-live-and walk those last miles together-you will greatly improve your chances of a successful implementation. You will achieve the desired business results sooner and achieve the return on investment that motivated the creation of the system in the first place.
Support after Go-Live
In the same spirit that Andersen helped her audience understand what they can to do prepare for change, she also wanted to give them some ideas about what to do after the change is implemented. She offered the following checklist:
- Recognize and understand that contribution levels will go down before they go up and why.
- Acknowledge the upcoming disruptions-expect them and prepare.
- Set appropriate expectations with business partners. Help them prepare by knowing what to expect and what support is in place.
- Allow and prepare for lower contribution levels immediately following implementation. Doing so will enable everyone to take the necessary risks to start using the new tools and processes.
- Understand and communicate that contribution levels have to come back up and eventually exceed current levels. Make it clear that you don’t have forever and that everyone has to do the hard work to get better.
- Ensure that there are backup plans to minimize business risk, and share this information with business partners and user communities. Creating and communicating backup plans helps everyone take the necessary risks to learn while also minimizing risk to the business.
- Maintain and communicate commitment: “We must figure this out. We can get through this.” Don’t waffle, don’t abort the change, don’t make the change optional anymore.
- Measure results and monitor acceptance. Without these measurements, you won’t know if you are succeeding.
- Keep the project team intact to support the user community until they can make it on their own. Without this support, users are very likely to revert back to their old ways. Little change will occur, which will result in few or no benefits being realized.
- Ensure that support systems and people are in place, including business and information technology. If support teams aren’t in place, the transition will be delayed and possibly put at risk.
At this point both Andersen and her audience were full. But there was one last surprise Andersen had up her sleeve for the group. She took them through a short but meaningful exercise through which they had a first-hand experience of a change in systems and processes. Just for fun, she also decreased the process time allowed and increased the minimum requirements for success. The audience members were able to personally experience much of what was talked about during the presentation. They watched their productivity go down, observed their tendency to opt out or give up, and felt their own resistance to change. For Andersen, this was the best part because it gave her audience a personal experience that can serve as a backdrop to remember and apply the information that she presented.
About the Authors