They say failing to plan is planning to fail and that very much applies to cutover planning. Projects might do a great job right from the start – good requirements documentation, good design, testing and change management – but fail when it comes to cutover planning. This is the equivalent of running the 110 metre hurdles perfectly, only to fall at the final one.
Failures at cutover are often highly visible within the organisation, and risk eroding confidence in everything else the project has achieved and impact the reputation of project managers. In this sense, an effective cutover plan can make or break a project.
First, some context. All projects should have some form of cutover or implementation plan but the level of complexity for these varies depending on the project. For some projects there may be a change from an incumbent system with a long history of transactions that need to be migrated into the replacement application. Even new system implementations require cutover planning to ensure that existing business functions are not interrupted by the adoption of the new application.
What does effective cutover planning look like? Here are a few tips learnt from the extensive experience of Glisk’s team.
It’s not an afterthought
Thinking through the approach to cutover should be included in the solution design template. Ideally, this is part of your architectural review, and should include not just the end-state solution description but what is involved in moving from the current state to the end state. Operational constraints should be identified and formally acknowledged, for example, can the solution only be implemented at a period-end, or does it require an extended outage to finalise cutover.
While the detailed cutover plan or checklist will be elaborated towards the end of a project, time needs to be allocated to what the cutover might entail much earlier. This thinking can manifest in the form of a Cutover Approach document prepared around the same time as the Solution Design or as a section in the Solution Design document.
Involve the entire project team
The entire project delivery team should be involved in the cutover planning process – not just the architects. This includes business owners, subject matter experts, and user representatives who can advise on appropriate downtime windows, inform how Post Verification Testing (PVT) might be conducted, identify impacted stakeholders for change and training purposes, and so on. It is about identifying key constraints that inform the plan.
Others on the project team with less technical knowledge about the system being implemented often provide different but critical perspectives. Change Managers might look at a cutover plan through the lens of who needs to be notified and trained. Test Managers might look at the cutover in terms of when test results need to be signed off and what needs to be presented at a Change Advisory Board. Project Managers would think along the lines of resources, and backup resources, required for the successful cutover.
The cutover plan should identify specific roles for each task and, ideally, nominate secondary resources should the primary ones not be available during the cutover period.
Proper rehearsal
Having a preliminary Cutover Plan or Checklist available when the application is moving into the test environment allows the project team to validate and iterate the plan and identify gaps. Typically, it is not possible to undertake a full-scale test of the cutover process in the test environments because replicating the entire production environment is impractical. Still, practice runs of the cutover undertaken against a subset of activities or for a subset of transactions, products, or users is normally possible, and this should be planned.
It is best practice to ensure that the users involved in the cutover rehearsal are the same users that will be performing the cutover tasks in the production environment. You don’t want people doing a cutover task for the very first time in production.
One of the main objectives of a cutover practice run is to establish timings for each task in the cutover plan. It is important to recognise testing as the period to evolve and mature the cutover plan because it will not capture all items, in sufficient detail, the first time the plan is executed.
Checkpoints and communications
Cutover plans can often be a shopping list of tasks required to enable the end-state solution, but it is important to insert checkpoints into the plan to ensure stakeholders who are not involved in the cutover process are reassured that appropriate risk management is being applied.
The number of checkpoints depends on the complexity and duration of the cutover process, the nature of the cutover tasks, and the number of stakeholders. Typically, high-level communications regarding the cutover will be distributed widely, while more granular communications will be tailored for project participants.
Communication plans of this kind are often developed by the Change Manager, who will work with the Project Manager and Project Steering Committee to define and agree the checkpoints in advance and make stakeholders aware of the triggers for contact and the method of contact.
Rollback and escalation plans
Any cutover plan ultimately needs to include both a rollback plan and an escalation plan or pathway.
The Rollback Plan might include several components or phases of rollback. For instance:
- Rollback Plan A: For use up to and including Cutover Task 14.
- Rollback Plan B: For use after Cutover Task 14 but before Cutover Task 30.
- Rollback Plan C: For use following Cutover Task 30.
The Escalation Plan outlines who makes the decision on whether to invoke rollbacks and how this decision is to be made. An example of an escalation path might be:
- The person performing cutover task sends a Teams message to the cutover team if there is a failure or delay performing a particular action.
- The Project Manager brings the team into a Teams call to discuss any issue and agree whether to recommend proceeding or rolling back.
- The Project Manager notifies the Project Sponsor of the issue and the team’s recommendation including the associated risks and cost.
- The Sponsor decides whether to accept the recommendation.
- The Outcome is documented and acted upon.
During cutover the plan or checklist should be actively updated and visible to everyone. There is no point documenting a detailed plan if it is not followed on the day.
There’s a great scene in the movie Apollo 13 where they need to figure out a way to use the carbon dioxide scrubbers built for the command module in the lunar module. There’s a team of people back on earth who work out the steps involved to implement a solution. This was a real-life square-peg, round-hole scenario. The ground crew practiced the solution and provided the astronauts with a step-by-step process once they were confident in the results. There’s a great infographic of the steps involved on the Houston Space Centre website here. Not all ‘cutovers’ here on earth are quite as critical but the principles of documenting the process, rehearsal and communication are universally applicable.
If you want to find out more about cutover planning, get in touch here.
