How to Roll Out a Change at Work

Planning how to roll out a change at work starts with listing every group whose work changes and what changes for each. Tell each group what changes and when. Test it with one group first. Before go-live, check that people know what to do and have help. After go-live, check whether each team is working the new way.

The decision is made and the go-live date is set. You're running the rollout, and most of the people whose work will change report to someone else.

What Does It Mean to Implement a Change at Work?

Katherine Klein and Andrew Knight separate two parts of putting something new in place at work (Klein and Knight, 2005, Current Directions in Psychological Science). Adoption is the decision to use it. Implementation is the period after that decision, in which the people expected to use it ideally become more skilled, consistent and committed in using it. They wrote that teams and organizations often adopt something new and then fail to implement it.

Rolling out a change is the work of getting from the decision to the point where the people affected use the new way as part of their routine. It includes planning, telling people, training, go-live and the checks after go-live. A rollout can reach everyone on one date or go to one group at a time.

Why Do Change Rollouts Fail?

John Kotter described eight errors he saw in company change efforts that didn't succeed (Kotter, 1995, Harvard Business Review). They include communicating the new direction far too little, leaving obstacles in place, and declaring victory too soon. One obstacle he named is a pay or performance-review system that makes people choose between the change and their own interests.

Klein and Knight listed reasons implementation is hard. They include new technology that's unreliable or awkward to use, new skills people have to learn, a decision made by people above the ones who have to use it, and work that slows down while people learn.

The people affected can also have specific reasons for objecting. Labeling a failed rollout "resistance" names none of the reasons change initiatives fail, so it doesn't tell you what to fix.

A good strategy can still roll out badly when communication with the people doing the work breaks down, such as unclear scope or vague dates.

Who Needs to Be Involved in a Change Rollout?

Write down who holds each part of the rollout before it starts.

• The sponsor owns the decision, the budget, and the obstacles that need a decision from someone senior.

• Each affected team's manager sets that team's priorities and tells the team whether the change matters.

• The people whose work changes know what the new way will cost them in time and where it won't fit their work.

• The people who support the change, such as IT, training and HR, own the systems, the training and the policies it touches.

• You own the plan, the dates, the updates and the checks after go-live.

Klein and Knight wrote that without strong, convincing and visible support from managers, employees are likely to conclude that the change is a passing interest that will go away if they ignore it.

Prashant Bordia and his colleagues studied uncertainty during a change in a public-sector organization (Bordia et al., 2004, Journal of Business and Psychology). Taking part in decision making went with less uncertainty about the organization's structure and about people's own jobs, a greater sense of control, and less strain. Ask the people whose work changes to help decide the parts of the rollout that affect their work, such as the order of the steps or the training schedule.

Agree who can change the scope, the dates and the requirements, and who has to be told when they do. Then name one person whose job is to keep every team working from the same plan.

What Goes into a Plan to Roll Out a New Process?

A plan to roll out a new process, a new tool or a policy change has one row for each group whose work changes. For each group, write down these things.

• What changes in their work, and what stays the same.

• The date they start working the new way.

• The training they need, and when they'll get it.

• Who they'll go to with questions on the first day and in the weeks after.

• Which of their systems, reports, targets or policies have to change first.

Klein and Knight described the policies and practices an organization uses to put something new in place, such as the amount and quality of training, help for users when they need it, rewards for using the new way, and how easy the new technology is to use. In their account, no single practice seemed essential, and the overall quality of the set predicted success. In a study they describe, manufacturing plants with many high-quality practices were more successful at putting a major new computer system in place than plants with few practices of lower quality.

They also wrote that implementation takes money, for training, ongoing help for users, explaining the change, and relaxing performance standards while people learn. If a team's targets stay the same while they learn the new way, ask the sponsor before go-live whether the targets can change for that period.

What Should Each Group Be Told before the Change Starts?

Before each group starts, announce the change to the team using that group's row in the plan, and say why the change is happening. Brief each team's manager first, with the questions the team is likely to ask and the answers.

Nerina Jimmieson, Deborah Terry and Victor Callan followed government employees through an 18-month regionalization (Jimmieson, Terry and Callan, 2004, Journal of Occupational Health Psychology). At the first measurement, information about the change was linked to employees' well-being, their engagement with clients and their job satisfaction, through its link to their confidence that they could handle the change.

Use the same core reason for the change with every group, and change only the detail about each group's work. Different reasons for different audiences are one way the reason for the change keeps changing. To answer the team's "why now" question, name the event that led to the decision, such as a vendor ending support for the old system.

Should You Test a Change with a Pilot Group First?

A pilot gives the change to one group before everyone else, so you can find and fix problems while few people are affected.

Trisha Greenhalgh and her colleagues reviewed research on how new practices spread, mostly in health care organizations (Greenhalgh et al., 2004, Milbank Quarterly). They found that people adopt a new practice more easily when they can try it on a limited basis first, and that setting aside room to try it can encourage people to experiment.

Choose a pilot group whose work looks like the work of the groups that follow. Before the pilot starts, write down what you'll check at the end, such as whether the group used the new way on their usual tasks, what went wrong, and what they needed help with. Keep a list of every change the pilot makes to the plan.

How Do You Roll Out a Change beyond the Pilot Group?

Klein and Knight listed how success or failure in one team spreads through an organization among the questions research hadn't yet answered. A pilot result shows what happened under the pilot group's conditions, and the next groups may have different ones. Before each group starts, compare its conditions with the pilot group's.

• Did the pilot group volunteer?

• Do the next groups do the same tasks?

• Did the pilot group have time set aside to learn the new way, and will the next groups?

• Who helped the pilot group with problems, and will that person be available to the next groups?

With AI tools, differences like these are one reason for teams not using AI tools you paid for after a pilot that went well.

Marcie Tyre and Wanda Orlikowski studied new process technology in three manufacturing and service organizations (Tyre and Orlikowski, 1994, Organization Science). They found a fairly short period after the technology was first put in place in which users had the chance to explore it and change it. After that, use became routine, and problems that hadn't been solved by then often became part of everyday practice. Have help available during each later group's first weeks with the new way, and fix the problems the group reports before its use of the new way becomes routine.

Greenhalgh and her colleagues also found that people adopt a new practice more easily when they can adapt it to their own needs. Before the next group starts, agree with the sponsor which parts of the change every group has to follow and which parts each team can adjust.

They found that adoption was more likely when key people in a person's network at work supported the new practice. They also found very little direct evidence on how to find these supporters and involve them systematically. Ask people from the pilot group to answer questions from the next group.

How Do You Know If People Are Ready for Go-Live?

Bryan Weiner proposed a theory of readiness for change in organizations (Weiner, 2009, Implementation Science). He described readiness as the shared resolve of the people involved to put a change in place, and their shared belief that together they're able to. In his account, that belief depends on whether people know what the change will take, whether they have the people, money, materials and information it needs, and the situation, such as whether there's enough time. He proposed that when readiness is high, people are more likely to start the change, put more effort into it, and keep working on it for longer. His paper is a theory with no data, and he wrote that it fits best where many people have to change how they work together.

A few weeks before go-live, ask these questions for each group.

• Can each person say what they'll do differently on the first day?

• Have they tried the new way on their own work, outside a training session?

• Do they know who to ask on the first day?

• Has their manager told them the change is a priority and given them time for it?

• Are the systems, logins and reports they'll need working?

The answers show whether your organization is ready for go-live. If a group isn't ready, take what you found to the sponsor with options, such as moving that group's date, adding help for its first weeks, or going live with fewer groups.

How Do You Keep People Updated during the Rollout?

In Bordia and his colleagues' study, communication from management went with less uncertainty about the organization's strategy. Send updates on dates you set in advance. To update the team when nothing is final, say where things stand, what hasn't changed, and when the next update will come.

Say which parts of the change are decided and which are still open, and ask for input only on the open parts. When people can't tell what's decided, the team keeps reopening a decided change.

Questions that bring new information, such as a step that doesn't work on one team's system, show a gap in the plan. When a question repeats one already answered, point to the answer and say whether anything has changed. The difference between the two tells you when to stop answering the same questions about the change.

Match each update to where people are in the change. Early on, they need the reasons. Once the change starts, they need to know how their own work changes. Later, they need help with the problems they run into. Repeating an early message at a later stage is one reason communicating more doesn't fix a struggling change.

Improvising change communication stops working once a change reaches more teams and conversations than one person can keep track of, and answers made up as questions come in differ from one audience to the next. Announcements sent before a decision is final, followed by corrections, can lead people to stop believing announcements.

What Happens When the People around the Rollout Change?

A reorg, a new stakeholder or a sponsor who leaves can each change who makes decisions on the rollout, where its budget comes from, and which teams do the work. Keep a written list of the decisions made so far and the reason for each, so the reasons stay with the rollout when people leave it.

After a reorg. List what the reorg changed for the rollout, such as who sponsors it and who manages the teams doing the work, and confirm each change with the person now in the role. To manage a project through a reorg, ask each new manager whether the work is still a priority for their team this quarter.

When a new stakeholder joins. To brief a stakeholder who joins mid-project, send them the list of decisions and reasons, the current status, and the one thing you need from them and by when, before your first meeting.

When the sponsor leaves. Find out who holds the decision and the budget after your project sponsor leaves. Then ask the remaining senior leaders to tell the affected teams whether the change is still a priority.

What Should You Do When a Rollout Stalls?

Find the point where it stopped before you decide what to do. Compare the dates in the plan with what happened, list the decisions that are still waiting and who owns each one, and ask the people doing the work what's in the way.

Status reports may not show that a rollout has stalled. Andrew Snow and Mark Keil built a model of how software project managers judge and report a project's status, using estimates from a panel of experts (Snow and Keil, 2002, IEEE Transactions on Engineering Management). It separated two reasons a reported status can differ from the true one, the project manager's errors in judging the status and bias added before reporting it. In their model, project managers were overly optimistic, and the authors concluded that executives should be skeptical of favorable status reports.

Klein and Knight also wrote that the more managers push for immediate output, the less time and energy employees can give to the new way. A team that has stopped using the new way may have been told to keep its usual output up.

To fix a stalled project you inherited, start with what was promised, to whom and by when, what's been done, and who is still working on it. If your projects keep stalling, compare where each one stopped and what it was waiting on, such as a decision, a budget or another team's work. If several stopped at the same point, take that list to your manager or sponsor and ask who can change what they were waiting on.

If a review of the stalled rollout concludes that you need better communication, ask what specifically broke, such as which group didn't hear what, or which question went unanswered.

What Needs to Happen after Go-Live?

Klein and Knight described a climate for implementation, the shared sense among the people affected of how important using the new way is. Where that climate is strong, people see using the new way as a top priority in their job. Two studies they cite found that this climate predicted people's use of the new way.

Set check dates after go-live and keep them. At each one, look at whether each team is using the new way on the work it's meant for, and ask what's in the way. To drive adoption of a new tool without authority over the teams using it, ask each team's manager for specific steps with dates, such as setting aside time to learn it and asking about it in team meetings.

When a team keeps a workaround alongside the new system, such as a spreadsheet, ask what it does that the new system doesn't. Fix what you can, and take the rest to whoever owns the system.

Greenhalgh and her colleagues found that accurate and timely information about the effects of putting a new practice in place made it more likely to become routine. Share what each check finds with the teams and the sponsor, including what isn't working yet. Keep the checks going after the first good results, and use them to keep a process change from sliding back.

After the last check, write down what you'd change on the next rollout and keep it where the next rollout's team will find it. Lessons kept only by the people who learned them are one reason organizations repeat the same rollout mistakes. When the same problems come back on every rollout, such as managers giving different answers or announcements going out before decisions are final, it may be time to decide whether change communication needs a system.

What Should You Do First?

Write the plan for your change this week, with one row for each group whose work changes, and send it to your sponsor. Ask the sponsor to correct what's wrong and to name an owner for anything left blank.

Frequently Asked Questions

How Long Does It Take to Roll Out a Change at Work?

It runs well past the go-live date. Klein and Knight describe implementation as the period after the decision in which people ideally become more skilled and consistent in the new way. Kotter wrote that until new ways of working are part of a company's culture, they can slip back, and that getting there can take years. Put check dates in the plan for the months after go-live, and decide in advance what result ends them.

Should You Roll Out a Change All at Once or in Phases?

Phases work when the old and new ways can both be in use for a while. The first group finds problems you can fix before the next group starts, and the people giving help aren't spread across everyone at once. All at once fits a change everyone has to make on the same date, such as a new system that replaces the old one. In that case, test it with a small group before the date.

How Do You Roll Out a Change When the People Affected Don't Report to You?

Work through their managers and the sponsor. Ask each manager for specific actions with dates, such as telling the team the change is a priority and setting aside time for training. Take anything that needs a decision or money you don't control, such as changing a team's targets while they learn, to the sponsor with a recommendation. Klein and Knight named visible management support among the conditions that help implementation.

What If the Change Doesn't Work for One Team?

Find out which part doesn't fit and why, such as different tasks, a different system or a busy season. Greenhalgh and her colleagues found that new practices that fit people's values, norms and needs were adopted more readily, and that people adopt a practice more easily when they can adapt it. Take what you found to the sponsor with options, such as adjusting that part for the team or moving their date.

If you're running a rollout and want a plan for each stage, The DANCE System gives you 29 tools across five phases, from defining the change to keeping it in place after launch.

Related Blog Posts:

Why do People Stop Believing Announcements?

When Does Change Communication Need a System?

Why does Improvising Change Communication Stop Working?

Why Does the Organization Repeat the Same Rollout Mistakes?

Why Does Good Strategy Still Roll Out Badly?

What Do I Say When the Team Asks "Why Now?"

How Do I Update the Team When Nothing Is Final?

What Does "We Need Better Communication" Miss?

Why Does the Team Keep Reopening a Decided Change?

When Do I Stop Answering the Same Questions about a Change?

Why Doesn't Communicating More Fix a Struggling Change?

Why Does the Reason for the Change Keep Changing?

How Do I Keep Every Team Working from the Same Plan?

Why Isn't My Team Using the AI Tools We Paid For?

How to Announce a Change to Your Team

References

1. Klein, K. J., & Knight, A. P. (2005). Innovation implementation: Overcoming the challenge. Current Directions in Psychological Science, 14(5), 243-246. https://doi.org/10.1111/j.0963-7214.2005.00373.x

2. Kotter, J. P. (1995). Leading change: Why transformation efforts fail. Harvard Business Review, 73(2), 59-67. https://hbr.org/1995/03/leading-change-why-transformation-efforts-fail-2

3. Bordia, P., Hobman, E., Jones, E., Gallois, C., & Callan, V. J. (2004). Uncertainty during organizational change: Types, consequences, and management strategies. Journal of Business and Psychology, 18(4), 507-532. https://doi.org/10.1023/B:JOBU.0000028449.99127.f7

4. Jimmieson, N. L., Terry, D. J., & Callan, V. J. (2004). A longitudinal study of employee adaptation to organizational change: The role of change-related information and change-related self-efficacy. Journal of Occupational Health Psychology, 9(1), 11-27. https://doi.org/10.1037/1076-8998.9.1.11

5. Greenhalgh, T., Robert, G., Macfarlane, F., Bate, P., & Kyriakidou, O. (2004). Diffusion of innovations in service organizations: Systematic review and recommendations. Milbank Quarterly, 82(4), 581-629. https://doi.org/10.1111/j.0887-378X.2004.00325.x

6. Tyre, M. J., & Orlikowski, W. J. (1994). Windows of opportunity: Temporal patterns of technological adaptation in organizations. Organization Science, 5(1), 98-118. https://doi.org/10.1287/orsc.5.1.98

7. Weiner, B. J. (2009). A theory of organizational readiness for change. Implementation Science, 4, 67. https://doi.org/10.1186/1748-5908-4-67

8. Snow, A. P., & Keil, M. (2002). The challenge of accurate software project status reporting: A two-stage model incorporating status errors and reporting bias. IEEE Transactions on Engineering Management, 49(4), 491-504. https://doi.org/10.1109/TEM.2002.807290