Many businesses begin their cloud journey with a basic migration of existing infrastructure. But they soon find that the cloud can have a transformative effect on innovation, enabling them to bring new products and services to market more quickly and efficiently. That’s especially true of “born in the cloud” applications, which can help a company rewrite the rules of competition in its markets. On the other hand, the more transformative the impact, the more people that are affected and the more disruptive the move can be for the business.
That’s why, like all transformations, success in the cloud ultimately hinges on how effectively change is managed.
It’s critical to understand who’s likely to have the greatest issues with the transformation and mitigate those issues before they become show-stoppers. If the people who are affected don’t buy into and support the initiative, the company won’t get the results it’s looking for.
Change management in cloud migration versus on-premises
But change management in a cloud migration is completely different from change management in traditional on-premises application developments or infrastructure upgrades. And that’s because the approaches to the developments themselves are equally divergent (see below).
Managing traditional on-prem change is fairly direct: These kinds of projects follow a linear progression of activities (the “waterfall” approach). We know exactly what we’re getting into and what kinds of impacts we will face. So, from a change perspective, we’re not surprised by anything.
Think about requirements gathering. In a waterfall approach, we typically look at requirements at the outset and rarely, if ever, revisit them as development progresses. Change managers start from the same functional and technical requirements that the application coder started from, and base everything on the original engineering specification document. Change management is as linear as the development itself, progressing from point A to B to Z in lock-step with the waterfall methodology.
In the cloud …
On the other hand, the journey to the cloud is agile, flexible and iterative, with many moving parts to track. Engineering sprints for the cloud, which could number three or four per quarter, are very different from those involving legacy data centers. As we go through these sprints, more activities will be layered onto previous ones and we’ll discover more stakeholders being affected. We must stay open and flexible to new business drivers and opportunity, because we know we can’t predict the end state with 100 percent accuracy.
In an agile methodology, requirements gathering is all about “stories.”
User stories, application stories and system owner stories are core to change management in the cloud. Listening to these stories is vital to understanding people’s needs, which may evolve as sprints unfold. You might have a high-level understanding of where a person is coming from—a few stories to begin with. But then you need to put on your investigative hat and follow the stories to their logical conclusion. This enables you to check the pulse of end users as they go through the sprints, continue to monitor performance metrics, and keep track of stories from an engineering perspective. Unlike in waterfall, you’re not executing a plan you developed six months ago that hasn’t changed since. You’re constantly checking in, and you have to be able to respond to the current drivers.
Traditional Adoption Approach
Linear, structured, progressive change management
Agile Adoption Approach
Rapid, iterative, flexible change movement
Change management used to be all about adoption.
Back in the day, if I were a change manager for an ERP implementation, my number-one measure, what I’d be held accountable for, is adoption:
Are all the users who are supposed to be using the system actually doing so?
Are they using it as designed?
Are they happy with it?
Can they accomplish their tasks with it as well as before?
If the answers are yes, then I’ve done my job.
Today, we’re affecting users’ ability to access software.
With the cloud, we’re not concerned about whether an end user can perform the same task as well with different software. Because we’re affecting users’ ability to even access that software, the questions we ask are different:
Are we getting the data centers nearest our facilities?
Do we have it architected properly so we have failover?
Can users access everything they need?
In other words, it’s not as much about adoption as it is about noticing application performance criteria. If, for instance, the architecture and failover aren’t right, end users might find the applications aren’t performing well. “It used to be really fast—I clicked and it went. Now, it just spins and spins, and times out for different things.” So, we need to make sure all the applications that people rely on are still live, all compliance concerns are addressed, and everything’s performing in line with the Service Level Agreements.
The key point is this.
When migrating to the cloud, you can’t use the same change management methodology that you used in the past. It must be cloud specific to keep pace with the agile, iterative nature of cloud migrations and evolving user needs as they progress through the effort (see figure). And there’s more than one methodology that’s right for the cloud. For instance, Accenture factors in the kind of cross-border selling compliance requirements we may face and the Title 21 CFR Part 11 credentials we may need. The political, geographical and industrial variations are as robust as the business requirements driving them.
Moving to the cloud is a fantastic opportunity for a company to digitally transform its business and disrupt its markets. But transformational change is different in the cloud. Ensure your change strategy is “cloud first” and you will be too.
Accenture Delivery Methods for Agile Change Enablement