In this article, we will cover the cutover plan, its purpose and provide guidance for the setting up the structure and agreement. The objective of the cutover period is to ensure the service that has gone in production fulfills the expectations of its users and that the organization can deliver the needed operational quality.

 

Start & Entry Criteria

The cutover period starts when the IT service starts to be used operationally (operational use of the system by a representative number of end-user). The project delivery organization remains accountable until the exit criteria have been met and service operations has accepted ownership. Entry criteria for the cutover period is the “Operational Readiness Confirmation” or ORC from IT Operations

Duration

As mentioned the objective of the cutover period is to assure user satisfaction and operational capability. Here counts: “the proof of the pudding is in the eating”, you cannot evaluate quality when something is not being used. So, we should allow sufficient time for all workflows to be completed. This also prevents the buildup of technical debt caused by undiscovered and unresolved issues.

Our advice is that the cutover period should include a minimum 2 full workflow cycles.

Examples:

• 2 weeks — when used daily and the workflow cycles are no longer then one week
• 10 weeks — when the workflow cycle duration is monthly
• 15 weeks — when the workflow cycle duration is quarterly
• For a yearly workflow cycle (for instance fiscal year end reporting) two full cycles is “a bit unpractical”. Try to find a “fit for purpose” solution.

In all cases make risk based decisions. The publication of the yearly earnings for a publicly trading company justifies larger investments than the Christmas time “pick your own present” app. How can you best assure user satisfaction and operational capability within justifiable efforts? With the yearly earnings report, you maybe should do a simulation with dummy data and you can arrange for a hyper care team to standby when the business cycle runs. For the Christmastime app, maybe you just accept the risk.

End

The cutover period ends when the agreed duration is completed or upon successful completion of the exit criteria, whichever is the later. Once the cutover period/exit criteria are completed successfully, the operational accountability can be handed over to IT Operations. The project delivery request an “Agreement to Take operational Ownership” or ATO

Exit Criteria

#	Condition	Required Outcome
1	Conditions raised at ORC -or any new conditions raised after ORC- for reaching ATO are closed	Confirmation from IT Ops that the conditions raised have been closed
2	Positive verification Quality Requirements	Confirmation IT Ops on positive verification
3	Core functionality (critical tasks) of the application as agreed and identified is adequately exercised by a representative number of users	Confirmation from the Business Owner that a representative proportion (ex: 50%) of the user base is using the IT solution correctly as expected
4	All support teams are ready (have the budget, capacity and capability) and have demonstrated their ability to support the service without the help of project delivery	Confirmation from the IT OPS that the Support Model and Fulfillment Plan agreed for ORC are still valid and that all identified Support teams can support the IT solution without any further help from the project
5	The delivered functionality and associated interfaces are stable	All Incident tickets closed or agreement from IT Ops to take over the open tickets. No priority 1 or 2 incidents in the last two weeks All change and enhancement request are either closed or ownership transferred outside the delivery project.

During the cutover period, we prevent project delivery discharging (all) skills and capacity without confirmation of a stable service. The exit criteria empower IT Ops to direct project delivery effort in order to ensure that IT Ops is able delivering the quality the organization needs. As with all things in Opsasto, the exit criteria are for guidance purposes and should not be used as a dictate. Key is managing the risk and being aware of the organizational long(er) term context. The lifecycle of a service stretches far after the point where the delivery project finishes.

Service cutover plan

In some situations, one long cutover period leaves to much opportunity for misalignment occurring. This can be the case with large scale introductions that involves large and diverse user groups. You can choose to divide the cutover period in multiple phases and where with each next phase, you gradually move more of the operational activities to the IT Ops team.

Figure – Service Cutover Plan

Hypercare phase

Entry Criteria

Follows Operational Readiness Confirmation & Go-live

Operations Factors (examples given below – tailor for your project)

Responsibility remains with Project Delivery Team Incidents are all raised by the end user, super user or process focal point via the Service Desk to the project delivery team All incidents are tracked in Service Management Tool All incidents are investigated and resolved by project delivery team Change Management is followed for all changes Project team execute changes to source code and central configuration IT Ops attend weekly incident meetings Project delivery team is responsible for all support activities, including any processing or maintenance tasks.

Exit Criteria (examples given below)

Application services have been enabled and have been operable for at least 1 week Move to the next support phase signed off by IT Ops lead Incident status: No Severity 1 incidents still open and none have been opened in the previous elapsed 5 days. If the system is stable and a Severity 1 incident has been opened in the previous elapsed 5 days, IT Ops can decide to forego this criteria and move to the next support phase, pending approval from the IT Ops Lead.

Anticipated Duration

n weeks (although criteria driven)

Project Support Phase

Entry Criteria

See exit criteria for Hypercare Phase

Operations Factors (examples given below – tailor for your project)

Responsibility remains with Project Delivery Team Incidents are all raised by the end user, super user or process focal point via the Service Desk to the project delivery team All incidents are tracked in Service Management Tool All incidents are investigated and resolved by project delivery team Change Management process is followed for all changes Project execute changes to source code and central config IT OPs shadow incident investigation and resolution (to assist KT and training) Conversations and meetings with support groups other than the project team must include IT Ops. Project delivery team is responsible for all support activities including any processing or maintenance tasks.

Exit Criteria (examples given below)

Key Knowledge transfer for IT Ops staff completed — as agreed by IT Ops lead All necessary access has been set up for the IT Ops team Move to the next support phase signed off by IT Ops Lead Incident status: No severity 1 incidents open and none have been opened in the previous elapsed 7 days

Anticipated Duration

n weeks (although criteria driven)

Assisted Project Support Phase

Entry Criteria

See exit criteria for Project Support phase

Operations Factors (examples given below – tailor for your project)

Responsibility remains with Project Team Incidents are all raised by the end user, super user or process focal point via the Service desk to IT Ops Team All incidents are tracked in Service Management tool Change Management process is followed for all changes Project execute changes to source code and central config IT Ops team assist in incident identification and restoration of services (to assist KT and Training) Project delivery team assists in incident identification and resolution when requested by the IT Ops team. IT Ops team is responsible for all support activities, including any processing or maintenance tasks.

Exit Criteria (examples given below)

Support processes all set up and known (support processes defined as routes by which incidents can be passed between support teams is known and updates received) All knowledge transfer has been completed successfully to all support groups Incident status: No severity 1 or severity 2 incidents raised in the previous 7 elapsed days Less than 3 incidents raised per day (of severity 3 or higher) Move to the next support phase signed off by IT Ops Lead

Anticipated Duration

n weeks (although criteria driven)

Assisted OPS Support Phase

Entry Criteria

See exit criteria for assisted project support phase

Operations Factors (examples given below – tailor for your project)

Responsibility remains with the project delivery team Incidents are all raised by the end user, super user or process focal point via the Service Desk to the IT Ops Team All incidents are tracked in Service Management Tool Change Management process is followed for all changes IT Ops team receive calls and perform incident identification and restoration of services Project delivery team are available to assist on request in incident identification and resolution IT Ops team is responsible for all support activities, including any processing or maintenance tasks.

Exit Criteria (examples given below)

ATO Exit criteria

Anticipated Duration

n weeks (although criteria driven)

Interim process workflows during the phases

Maybe you will need to modify workflow for incident, change and request processes. It is generally a good idea to document and share these “interim” workflows.

Figure — Example Interim Process

Effective issue management in projects.

The Opsasto guidance is quite simple and effective. Do a risk assessment on the issue and then prioritize. Categorisation takes place using a Risk Assessment Matrix that in turn drives the prioritisation following a Prioritization Matrix. Once you agree on this approach, the debate can be about the impact and you can prevent wasting energy debating different perspectives of the truth.