How Your Rollout in Waves Can End in a Tsunami

14. November 2022
Kategorien
Newsletter abonnieren

How Your Rollout in Waves Can End in a Tsunami

Many multinational organizations are bringing larger system implementations to a screeching halt because they misunderstand what it means to do a rollout in waves. 

We’re probably all familiar with the “phased rollout”. A phased rollout means you roll a project out to all targeted users at once but don’t deploy all of its planned functionality.

A good example of this would be rolling out a new CRM system to your organization. You go live in the first phase with Contact, Client, and Opportunity Management, and Account Management and Pipeline Management follow in the second phase.

Another popular type of rollout is the so-called staged rollout (also known as a rollout in waves). A rollout in waves or stages means that all the planned functionalities will be rolled out at once, but not for all users.

A rollout in waves gives you time to analyze the system’s quality, stability, and performance against your business goals. You can then decide if you want to roll out the system to more users, wait for more data, or stop the rollout. 

A rollout in waves is one of the core building blocks of making continuous delivery a reality. Facebook, Netflix, Microsoft, Google, and similar companies all rely heavily on staged rollouts.

One wave rollout method frequently used by multinational companies for new system implementation is the rollout by country or geographical territory. 

This is the preferred approach by companies implementing a new CRM, ERP, HCM, or some other key business application. Sometimes it’s combined with a phased approach.

Rolling out in waves is usually a good idea, especially compared to a “big bang” rollout. 

But before undertaking a rollout in waves, you have to carefully consider the following three realities:

1) The moment you switch on a new system in one country, you’ll need to address a bunch of Business As Usual (BAU) activities including Release Management, Change Management, New User Training … you name it. Your users will also discover bugs in the system and/or interfaces that weren’t discovered during testing. Many of them will be critical and need to be fixed ASAP. You’ll probably find that performance issues will be more common than not. Some companies call the first few months “Hyper Care” or some equivalent, but it is nothing else as BAU. 

2) As is always the case with a new system, it won’t work completely as expected. In addition to the bugs that need to be addressed within the BAU process, you’ll have a high number of Change Requests, because only now will users realize they need additional or different functionality to do their work. Again, a number of these requests will be critical and/or urgent. Users will probably ask for many additional reports because they don’t understand the data they see in the new system. If you combine your rollout in waves with a phased rollout, you’ll need to build and test the functionalities for the next phase.

3) At the same time, you’ll want to proceed with the next waves of your rollout, and you’ll need people to work on this. Think about discovery, migration, configuration, training, etc. for each new country that needs to be onboarded. The big idea is always to have one system for everyone, but local legislation and regulations and differences in how business is done in each country will force you to implement additional Change Requests in the system.

The number-one mistake I see is that organizations allocate a single team to accomplish all of the above tasks after the first-wave rollout. This approach always fails miserably and will bring the rollout to a screeching halt.

For a successful rollout in waves, you’ll need three different teams after the first wave:  one for BAU activities, one to deliver Change Requests, and one to onboard additional waves. Some people may work on more than one team, but this really should be the exception.

You’ll need to plan and budget for these teams, hire and train people for them, and define their organizational setup. 

And you’ll need to do all of this before you go live with the first wave – not after!

In a nutshell: You will need three teams for a successful system rollout in waves.

Tags

Das könnte Sie auch interessieren

Scaling Agile: SAFe

2. November 2015

This is the fourth of six articles on approaches that try to help to scale Agile. For the introduction to this series please read the first article Scaling Agile: Nexus Framework. The second article is about Disciplined Agile Delivery (DAD) and the third about Large Scale Scrum (LeSS). This article will present the Scaled Agile

Weiterlesen

Scaling Agile: LeSS

29. Oktober 2015

This is the third of six articles on approaches that try to help scaling Agile. For the introduction to this series please read the first article Scaling Agile: Nexus Framework. The second article is about Disciplined Agile Delivery (DAD). This article will present Large Scale Scrum, or LeSS. The creators of LeSS, Bas Vodde and

Weiterlesen

Product Backlog Stories …

26. Oktober 2015

Last few weeks I had a few experiences around Product Backlog Items and user stories that made me write this article. Let’s start with a simple observation: many teams I have worked with and people I have met still have the notion that every Product Backlog Item should be in the form of a user

Weiterlesen

Scaling Agile: DAD

21. Oktober 2015

This is the second of six articles on approaches that try to help scaling Agile. For the introduction to this series please read the first article Scaling Agile: Nexus Framework. This article will present Disciplined Agile Delivery, or DAD. Contrary to for example Nexus or LeSS, DAD is not Scrum, it wants to be far

Weiterlesen

Scaling Agile: Nexus Framework

19. Oktober 2015

This is the first of six articles on approaches that try to help to scale Agile. One of the most popular Agile methods is Scrum. Scrum is a very simple framework that describes an one iteration, one increment, one team product development effort. The framework leaves the more complex application of Scrum to the user.

Weiterlesen

Estimating with Wideband Delphi and Monte Carlo Simulation

18. Oktober 2015

During the LeSS training in Berlin last week with Craig Larman he mentioned the best estimating method he knows for any big software project. Wideband Delphi with Monte Carlo Simulation. I agree with him on this one hundred percent. This article will explain what Wideband Delphi and Monte Carlo Simulation is (Part 1 & 2),

Weiterlesen

Budgeting a Scrum Project

11. August 2015

A few weeks ago, I took the training for «Agile Estimating and Planning» with Mike Cohn on FrontRowAgile.com. The training was very good and I think it’s an excellent start for all estimation and planning-related questions. But even after this training, it is still unclear for many on how to make the leap from estimations

Weiterlesen

Scrum Project Success Metrics

30. Juli 2015

Last week I was reading „The 2015 State of Scrum Report“ from Scrum Alliance. In February 2015, Scrum Alliance surveyed almost 5000 people about their use of Scrum. The survey respondents make up a diverse group, representing 108 countries and 14 industries. They reflect a range of functional areas, including IT software development, product development,

Weiterlesen
Previous