Cutover Preparation

Cutover workshops

The objectives

• Cutover Approach Definition
• Cutover Technical and Business Detailed Steps
• Define the dependencies
• Address Business Impact
• Business Communication Plan

Kick-off meeting over, Stakeholders list in hand, it is time to sit together and start building the Cutover Detailed Plan

Based on the Cutover scope, we will define different groups of 7-10 persons to join and discuss the cutover steps. Like with any meeting, it is highly important to set up the agenda and the objectives. (How to Run Efficient Meetings?)

The group can be defined by technology, by functionality or by IT / Business Workstreams. The goal is to highlight any dependency between the workstream and anything that can impact the business activities. 

The Cutover Approach

“Get everyone on the same page!”

The document lists all key principles which we are going to use during the deployment. The document has to be understandable by anyone from the technical to senior stakeholders, and Project/Program Steering Board persons. 

It sets the project context, the cutover roadmap, the high-level sequence of events, the business impacts and mitigation, the timeline, the Rollback criteria and process, the communication plan and the escalation process. 

It helps the cutover teams to get the full picture. Furthermore, it helps to maintain the vision, the path to Go Live. It helps to review hard dependencies between 2 majors events and the Business impacts.

Along with the Cutover Detailed Plan, that’s the documents most reviewed during the whole Cutover Preparation. Most of the time, it is the entry point to the detailed steps.

Communication is one of the key factors for a smooth Go Live (whatever Cutover tool you use). The Cutover approach will be used to share with everyone from the company, including the support teams, to make sure everyone is aligned with the upcoming event.

The Cutover Detailed Plan

“The Master Piece”

Whatever the tool you use, if you prefer excel, or can afford more automation tool available now, the way you capture all the detailed steps is critical for the Go Live success. 

Don’t underestimate the Task Description. So often, we see in the middle of the execution and someone asks: “What does that mean?” 

If you can’t explain it simply, you don’t understand it well enough.

ALBERT EINSTEIN

As the Cutover Manager, we are the “Gatekeeper” of the overall plan, if we cannot explain the task, we have not understood enough. If we have not understood enough, we have missed something during the workshops. 

Don’t be afraid to challenge the expert. Don’t hesitate to ask questions to clarify the tasks. Make sure that the task description is understandable by other technical people, not only the expert person who is responsible for that task.  2 objectives: 

1. Other Cutover actors would be able to better identify if there is a dependency with one of their tasks
2. Backup Plan. If by any circumstance, the expert is not available the day of the execution, it will be easier to back up the tasks with another person. 

The MVP, in that case, the Minimum Viable Plan, contains the below information: 

• Task Date
• Task Start Time
• Task Duration
• Task Area
• Task Description
• Task Owner

Dress Rehearsal

(as known as Dry Run or Mock Cutover)

“Validate the Assumptions”

The main objective is to test and validate the sequence of events and the assumptions: Task Duration, Task Description, Task Dependencies., last by not least, the Communication between the Cutover team members. 

The goal is to highlight any discrepancies, any issue that could happen during the Production Cutover. 

It also helps to review and validate the task owner responsibilities. It is good practice to confirm with the Cutover team members if they have well understood the Cutover timeline when they are expected to start and finish and the way to communicate within the team. 

The rehearsal, as known as Dry Run, happens in a Non-Production environment which is ideally different from the Dev and Test environments. A Like-For-Like Production environment is required to be the closest to the reality before the execution. 

Not all organization can afford different several non-production environments. If it is the case, the potential actions are: 

• Segment the plan with the part that can or cannot be tested, and test the sequences which can be tested
• Make sure to identify into the plan the tasks which have been part of the Dry Run execution and the one which did not. 
• Analyse the potential risks of not testing a particular part
• Add the risk to the RAID document and share the details with the Program Manager or the project sponsor
• Make sure the risk is also highlighted in the Go No Go criteria in order to remind everyone while taking the Go No Go Decision

In large organizations, the project and the support teams are different. There are different access rights depending on the environment. If it is the case, make sure to get the same group of people executing the rehearsal and the Production cutover. 

If not possible, you will need to plan a proper knowledge transfer ahead of the deployment. Don’t hesitate to plan several ones, even when the persons say: “I have understood”

Additional Tips: 

• If you don’t have an automation tool, make sure to capture properly each task duration
• Make sure to capture all types of issues, it will be the support of the next phase below. 

Cutover Retrospective

“Validated Learning or Lesson Learned”

Similar to an Agile Sprint Retrospective activities, the goal is to find improvement by identifying what worked well, what didn’t and why. 

Preparation: 

• You can use any collaboration tool like Sharepoint, GoogleDrive or Trello, so the team members can start updating the document before the meeting.
• Define the categories: What Worked well | What Did Not Work | Improvement and Actions
• You can start filling each column, so the other team members can follow the same example. 
• Don’t forget to add all the issues captured during the Dry Run execution 
• Set the agenda in the meeting invite, see the example below: 

The meeting

For the ones who are not familiar with the retrospective methodology, it can be a challenge to speak up and share his/her point of view. At the beginning of the meeting, the Cutover Manager reminds the agenda and the organization of the meeting. Setting clearly the expectation and the goal of the meeting gives clarity to the attendees.

Cutover Manager Key skills in that meeting:

• Listen with an open mind
• Active listening
• Ask open & powerful questions
• Facilitate Root Cause analysis

1. Listen with an open mind

Communication & Organization within the team are one of the key factors for a successful Go Live. If there is an issue on one of these 2 or both, it does not necessarily mean it was wrong, I can simply mean it wasn’t the appropriate way with that team. The retrospective gives a chance for everyone and also the Cutover Manager to adjust and improve the way of working as a team.

2. Active Listening

Listen with the intent to summarize and find a strategy. Show your audience you are there for them, that you consider what they are saying. It helps to get more information, to be able to raise more powerful and relevant questions and to save time avoiding asking the other person to repeat.

3. Ask open & powerful questions

Questions that stimulate reflective conversation and critical thinking. Associated with active listening, it helps to get more information and identify improvement.

Examples:

• What can be the impact of doing (or not doing) this activity?
• What would you need to support your task?
• What can be done upfront to reduce the task duration?

4. Facilitate Root Cause Analaysis

One process really useful is the “The 5 Whys Process“. It has its origins in the Toyota Production System and posits that behind every supposedly technical problem is actually a human problem. The method is remarkably simple: when a problem occurs, you drill down to its root cause by asking “Why?” five times. Then, when a counter-measure becomes apparent, you follow it through to prevent the issue from recurring. In IT world, it can appear like this:

1. A new release broke a key feature for customers. Why? Because a particular server failed.
2. Why did the server fail? Because an obscure subsystem was used in the wrong way.
3. Why was it used in the wrong way? The engineer who used it didn’t know how to use it properly.
4. Why didn’t he know? Because he was never trained.
5. Why wasn’t he trained? Because his manager doesn’t believe in training new engineers, because they are “too busy.”

Example from: The Five Whys for Start-Ups, Eric Ries, Harvard Business Review