Preparing for go live: change management considerations of your deployment approach.
Introduction
The deployment of a new system or the cutover from an old one to a new one is not only a technology shift but also a transformation in the way people work and organise themselves. Historically deployment has been considered the responsibility of the technology team or system integration (SI) partner. It’s easy to get lost in the technical intricacies of the process and tasks involved in cutover and overlook the people elements at play. But if the most critical measure of success is people’s adoption of the change, then surely, it’s important to consider the people implications of the deployment approach.
What is deployment?
In a business and project context, deployment (also commonly called cutover) is the process of transitioning an organisation from one way of doing things (people, process, technology) to a new way of doing things. Examples include implementing a new software system, launching a new product or service, or adopting a new business process. Typically, the term describes the series of technical steps that must be taken during the ‘go live’ of a system implementation (i.e., when the system starts to be used by its intended users).
Typical deployment approaches and the change management implications
There are four common deployment approaches that are typically used to deploy a new system into an organisation, each with vastly different change and people implications that are often overlooked due to a (perceived) focus on risk mitigation and a desire to speed up benefits realisation.
1. Pilot
A pilot approach (sometimes called a test) is when the change is deployed only in one part of the organisation, typically a specific location or region, as a way of testing in ‘real-life’. Once the pilot performs satisfactorily, the system is then rolled out across the remainder of the organisation in a big bang, parallel or phased approach.
From a people perspective, the positioning and approach to running the pilot is important. Often there is a reluctance to ‘go first’, however finding the right area of the business to be the early adopter and supporting them appropriately can go a long way to selling the approach. There are benefits to being the first cab of the rank, namely having the focused support of the entire program team, and the opportunity to provide feedback and suggestions ahead of the broader rollout.
Clear communication to those involved in (and equally, those not involved in) the pilot is also essential so that everyone understands what’s happening when, and what they need to be ready for. Sharing learnings and celebrating success from the pilot can also help to generate a sense of excitement and enthusiasm ahead of the broader release.
2. Big bang
A big bang deployment approach is the equivalent of ripping the band-aid off; the old system is deactivated, and the new system becomes the default for everyone with no transition period.
This approach is considered risky as it removes the safety net but also has the benefit of not needing to operate or support multiple systems in parallel.
From a people and change perspective, it can be easier and simpler to plan for a big bang approach as everyone is going through the change at the same time. Whilst the leap can be difficult, it also means that people aren’t needing to work in two systems or across different processes and lends itself to a shorter implementation time. That said, a big bang approach will require more change management resources as a large audience will need to be supported.
3. Parallel
In contrast, a parallel deployment approach is when a new system is run simultaneously with the old system until the accuracy and reliability of the new system can be verified.
This mitigates risk but adds complexity for end users and support teams to work in multiple systems and processes. You are essentially asking people to do the same thing in two different ways, creating additional workload for those involved. Like a big bang approach, a parallel approach will be more change resource-heavy to support a large audience through a complex period, in addition to the costs and data integrity involved in maintaining and supporting two systems in parallel.
4. Phased
A phased approach is similar to a pilot, in that different parts of the organisation are ear-marked to go live at different times. This might be based on geography (such as state or region), function (such as business units), or by functionality (module by module).
Because changes are made incrementally in a phased rollout, the program team is better placed to deal with any implementation issues as they arise, rather than all at the same time. Learnings from earlier phases also inform and guide the subsequent phases, reducing the likelihood of issues as the deployment continues.
For the people involved, based on the type of phased deployment, it may allow users to adjust to the new system gradually and to have adequate support available during each phase. It can also be confusing to have different groups of users working with different systems at the same time or have people using multiple systems for a module-based deployment.
Simple and clear instructions about what is going live and when are required to support people through a phased deployment approach and to reduce the burden of a longer implementation window.
How to manage the change
So often the change management effort in large-scale digital transformations is focused on the future or ‘to-be’ state. Ideally, this is positioned within the context of how things are done currently or ‘as-is’, with the focus on the change impacts or gaps between the current (as-is) and future (to-be) states.
The risk in purely thinking about what the shiny new world looks like and how that differs from today is that you lose the focus on how we are actually going to get there – i.e., what does the deployment itself look like, and how will we transition from how we work today to how we should work in the future. Time and time again, the deployment approach and cutover plan are considered from a technology perspective, with change and engagement activities considered as an after-thought. Some examples of this include:
“Oh yeh, we should let our suppliers know that they need to submit their invoices early so we can pay them on time before we move to our new AR/AP system.”
“We need to take the current core platform offline for 48 hours, but we haven’t engaged with the business about the timing of this or any workarounds that might be required.”
It’s very easy to get stakeholders offside by giving them little notice about substantial impacts on their business and day-to-day operations. So regardless of what deployment approach is selected, ensure that the people implications are clearly understood, key stakeholders are engaged early, and there are simple and clear messages to the people impacted.
Conclusion
In a large-scale technology deployment, it's easy to get lost in the intricacies of technical tasks during system deployment. However, it's crucial to remember that people are at the core of any successful deployment. If you fail to recognise this, you are unlikely to realise the sustained adoption that you are looking to achieve.
The choice of deployment approach can have significant implications for the people involved in the transformation. It’s important to consider not only the technical and financial risks associated with the different deployment approaches, but also the vastly different people implications and to plan and manage them accordingly.
Often there is a trade-off between risk mitigation (and having the appropriate opportunity to test, refine and even roll back), cost (reaching benefits realisation as soon as possible), and what is going to be easiest and simplest for end users. Every transformation program needs to find the right balance point for the context, organisation and people involved.
Regardless of which deployment approach is chosen, it’s essential to carefully plan, engage and manage the people aspects of cutover to minimise disruption and ensure a smooth transition.
If you would like to discuss your transformation, please reach out – we’d be happy to share our experiences.
Anna Mevel, Director