Project Cutover-A vital step in Project Go

Live
Preface

Through the rough and tumble of a project, when all the hardworking on solution design,
Integration and  testing is done, QA has satisfactorily passed the results, the time comes to
setting the product or result of the project into real life use. The real life has never been tested for
this unique work so there shall be challenges and issues. To make sure that transition from the
DBT (Design, Build and test) stage to real life happens as smooth as possible, a project needs a
cutover process. Though PMBOK doesn't elaborate much on the subject, but refer to transition
as an output of the 'Close Project or Phase' process group, as Final Product, Service, or Result
Transition.

Cutover is vital process as it involves placing the product or service or result of a project to its
operating lifecycle, so that initial issues/pitfalls could be monitored, minimized and managed
effectively, thus in context of Project Management it is important to understand the 'Cutover
Process'.

Definition

Cutover process involves a series of steps need to be planned, executed and monitored in order
to make the project golive. It encompass Cutover Strategy, Cutover Plan, The Cutover Date,
Agile Monitoring of the cutover activities and Controlling undesired variations. Its a crucial
process and sets focus of the project on important activities which are necessary to make project
result for actual use by the end user.

'Cutover' as defined -'rapid transition from one phase of a business enterprise or project to

another'. It follows approaches that are emanated from various project experiences and aligned
with the organisational policies and procedures for better execution and control. In simple terms,
when a project or product completes a development stage, it needs to transit into operations
stage or another phase.

Though cutover process is more associated with or pertinent to the IT processes, but it is equally
relevant in all types of products/projects, the scale and volume of activities may vary.

For example, rolling out a designed and tested ERP application, a well laid out Cutover process
needs to perform in order for the system to work uninterruptedly from the date of its going live,
similarly, for rolling out a new train service between two stations also need cutover planning and
execution but the activities and steps might be different than the ERP project, same can apply for
any infrastructure project etc.

 
Why do we need to 'Cutover'?

This is very relevant to know why do we need cutover? We have following key aspect of a
Cutover Process:

1. Migration from the development cycle where transition of the product/service from the
controlled, cockpit kind of environment to real operating environment needs to
happen.

2. Establishing or finalising a predefined cutover date from where onwards, new

operating procedures/processes comes into effect.

3. The product/service standard operating procedures are going to be changed from the
previously used methods/steps and operating instructions these must be prepared
and put to use, so 'Cutover' entails user trainings, Handholding and Post Live issue
handling procedures.

4. Where it is legally required to follow some different rules after a given date so as to
ensure compliance, for example, Govt. brings in law to implement GST instead of
VAT w.e.f. 01/04/2017, this becomes imposing date for all the organisations to adopt
GST from this date, so this becomes natural Cut Over date for all the organisation to
follow.

5. Where support of a product/service is obsolete after a certain date, the obsolete

product service must be replaced cutover needs for implementing the new
product/service.

6. So that product support function can be activated to support the project during its life
cycle

New Product Launches, New Service Launches, New Market Launches, New
Software Implementation, Replacing Old system with New improved system, all
involves cut over process in order to enter to the real life it a well planned approach so
that the transition becomes smooth.

Following are pre-requisites which must be met in order to cutover:

1. All the customer requirements have been incorporated into product or service design
and all change requests have been implemented.

2. Testing of the product or service has been completed to the satisfaction of the
appropriate team of the customer , as per the acceptance criteriaset up in the Validate
Scope process

3. Quality Audit by competent expert(s) have been satisfactorily carried out and their
results have been considered by the customer

4. Pre production mock drill have been carried out by the project team along with the
customer core team

5. Trainings to the end users of the customer have been completed

 6. Any other completions or conformance criteria set out in the SOW or Contract has
been vouched and confirmed by the customer

7. All the documentation for use of the new product/service/result is ready in the form of
technical documentation as well as the user manual which can be used as a ready
reference to any issue faced during the post go live stage.

8. All the Go-Live critical issues have been resolved and their resolution is documented
to assist in future recurrence.

9. All legal formalities such as Government Clearances/License fees/ Taxation has been
properly dealt with.

The cutover process:

The Cutover process includes strategy, planning, execution and monitoring and control, the
whole process is elaborated in following paragraphs:

1. Cutover Strategy

Cutover strategy is the core guiding principle of the organisation, which requires certain
organisational objectives to be achieved by putting up the outcome of a project for end use. The
cutover strategy is set out in the Initiating phase and developed an insight by project planning
phase. It is revisited and revised and finalised  before the cutover plan is worked out.  Cutover
strategy provides critical facts which aligns organisational activities to the objectives relevant to
project rollout.

Key aspects of a cutover strategy are:

1. Timing and market conditions or other environmental aspects necessary in order to

place the product/service or result to end use

2. Determining the need and assess the requirement with respect to Blackout period and
devise clear guidance to the project team

3. Requirements with respect to organisational preparedness and orientation in terms of

competencies and resource availability

4. Ensuring alignment of cutover plan to organisational objectives

5. Setting up the Organisational Communication in order to clearly defined

roles/responsibilities and accountability

2. Cutover plan: All rigor of a project goes into creating a product, service or a result. The time
when we have completed the execution of the project activity, all testing of the product or service
with respect to Customer Requirement and Product Characteristics and Project Quality is
completed and this product/service or the result is to ready to be launched for commercial
purposes, we need to roll out to a step called Cut Over planning.  For every project the cutover
requirements differs as per the requirements or the nature of the product and the project, but the
procedure of the cutover remains generic. In a typical project plan the cutover date is set up
based on the baseline scope/schedule dates. So the cutover planning begins with the original
project plan and it is essentially elaborated at a later date when project execution is in the last of
its leg. Normally detailed cutover planning is started at around 2-3 months before the date of the
rollout date depending upon the size and complexity of the project.

The cutover plan needs to be well laid out and needs to be elaborated enough not to leave
anything to speculation because cutover involves phasing out the old product/service/result or
setting out new product or service as the case may be, so as to minimize on the issues of post
go live. Cutover plan, as a sub component of main project plan needs to incorporate following
actions:

1. Planning of the availability of Hardware/Software and other material resources and

people necessary for the rollout

2. Declaration of Going Live and other subsidiary communications as per the

communication management plan from the executives to relevant user group, its
timing and content

3. Setting up issue management protocol, alignment of organisational functions with the

new requirements

4. Determining Blackout period in alignment with the Cutover Strategy and layout dos
and don'ts during this period.

Blackout Period: It is important step to roll out a new product/service or the result
that we need to create some space in the ongoing environment of the existing
product/service or result so that new product/ service or result can be placed before
start. The context of this step is known as 'Blackout Period' where in the current
product/service or business as a whole needs to be stopped for predefined period of
time  in order to roll out the new product/service or result.

It is important to differentiate among the IT objects/software products, physical

product rollout such as a good, machine or other material or an infrastructure such as
a road or bridge or a building or a new service such as mobile phone service or rolling
out a chain of super stores etc. where concept of blackout to be appropriately
modified

5. Setting up focused core group for monitoring and controlling variations from the
transition process and technical and functional support teams

6. Setting up key success criteria to help measure the success/completion

7. Risk reassessment and devising a fallback plan in case of unforeseeneventuality

 

It is the responsibility of the project manager to ensure adherence to the cutover plan once it is
approved by the project sponsor or the steering committee.

3. Cutover  Procedure

Cutover procedure involves series of activities that are  carried out in adherence to the cutover
plan. This the execution of Cutover Plan and  needs active participation from senior
management.

Cut over procedure entails below mentioned steps:

1. Freezing Cutover date- Once the product or result is ready, planned cutover date or
new date is finalized at an appropriateforum

2. Formulating Cutover Strategy and communication to relevant stakeholders

3. Detailed Cutover Plan and communication to relevant stakeholders

4. Ensuring all steps defined for validation of the deliverables have been achieved and
any of parked issues to be taken up after going live have been acknowledged and
documented

5. Orientation of the Project Team and The Core User Group for better execution has
been ensured

6. Detailed procedure of events and tasks to be carried out in blackout days (if any) and
allow for suspension of activities to adapt to the procedure take place with stop, look
and go strategy.

7. Big bang opening of the first output of the new product/process recording and
acknowledging the start of new process or product life cycle and communication of
the success in order to carry the positive message and boost themorale of the teams
involved

8. Monitoring and Controlling of the Execution of the Cutover activities

9. Announce the completion of cutover activities and sending out success stories and
developing lessons learnt documentation

4. Successful go live and post live support

Once the cutover procedure is executed and the product/service or result went live, all the initial
issues have been settled and user has started working on new procedures, the project Go-Live
happens to be successful. Now the post Go-Live support is crucial for some time lets say for a
month in order to stabilize the new process and hand over completely to the operations teams.
After successful go live, product  support is taken over by the specialised support team to
support the ongoing operations. On successful transition, appropriate management
communication must be issued to all relevant stakeholders so that the project team can proceed
with other Project Closing activities.
 

Conclusion:

A strong cutover strategy followed by a well defined cutover plan is indicator of success in
transiting the product/service/ result into real life. It ensures  issues are minimized and controlled,
operating becomes easy and a speedy recovery of costs and ROI. A diligent planning ensures
that all steps/activities required for transition has been taken into account and uncertainties has
been duly accounted. All risks have been duly noted and response plans are weighed and
appropriately adjusted.  While we execute the cut over procedure the care must be taken to
adhere to the plan and any deviations noticed must be duly communicated to the relevant
stakeholders in order to take any corrective steps as required. An active participation by senior
management is imperative for success of a cutover process.

9 Apr 2011

THE PROJECT GO/NO-GO CHECKLIST

~ By James W.J. Hutt

Many projects have failed at the last hurdle due to poor implementation
planning or inadequate analysis immediately prior to go-live. It is the project
manager's responsibility to ensure that the implementation has been planned
out and communicated to stakeholders, and that sufficient due diligence is
undertaken before the project proceeds. This second point is often
overlooked. Many project managers put together some form of
implementation or cutover plan yet fail to carry out the necessary rigorous
analysis to determine whether they should proceed. This article focuses on
this analysis - what is termed the 'go-live decision'.

The decision to go-live or not should not be taken lightly; it is without doubt
one of the most important decisions in the project lifecycle and getting it
wrong can jeopardise the success of the entire project.

Going-live without everything in place may result in:

 Unresolved defects
 Inadequate testing
 Insufficient training
 Business processes not understood
 Procedures not written
 Stakeholders missed
 Lack of communications
 Data migration failure
 Interfaces not working
 System administration and support not in place
 Business areas not ready for the changes
 No contingencies in place
 Workflows and exceptions not mapped out
 No backups and disaster recovery in place
 Inadequate system security
 Unclear responsibilities, accountabilities and ownership
 Inadequate implementation strategy

And ultimately…

 System/application failure
 Impact to the business/organisation
 Project failure
Whilst the project manager is always under pressure to deliver within
schedule, sometimes it is prudent for them to step back and delay go-live
rather than risk the consequences of steaming ahead.

What due diligence needs to be done?

Ideally the project should secure an independent resource to perform the

readiness assessment. If the analysis is undertaken by the project manager, or
people closely associated with the project, there is a risk of bias or influence
from the pressure to implement on time. Using an independent resource
provides a level of impartiality and therefore credibility to the decision
making process. It is also useful to get an outsider's perspective, especially if
it's from someone with years of project experience and knowledge. Well
funded projects often employ outside consultants to perform audits and
health checks throughout the project lifecycle, including the go-live readiness
assessments.

Unfortunately not all projects have the means or desire to employ

consultants, and therefore need to utilise internal staff. In this case it's best to
use a resource with prior project experience (e.g. another project manager),
but with no vested interest in the outcome of the project. This improves the
chances of an objective outcome and recommendations. Remember, it is in
the project manager's interests to get an honest assessment of where the
project is really at, as any major deficiencies must be either addressed or
mitigated against before go-live. If the outcome of the assessment is pre-
determined or intentionally slanted, there is little point in doing the
assessment!

If it's not possible to secure an independent internal resource to carry out the
readiness assessment, the project manager can do it themselves. However
they need to make sure that they give an honest account of the situation, ask
searching questions of people and don't hide issues. These assessments
should never be conducted without extensive consultation, as it's vital to
speak to as many project people as possible to find out the true state of play.
Some people may hide issues or only tell you the positives. It's important to
get the 'warts and all' view, as any major issues and roadblocks must be
uncovered and addressed before a decision is made.
Go/No-Go Checklist
What should the assessment cover? Rather than starting from scratch, it's
easier to use a Go/No-Go checklist. This provides a starting place, based
upon common best practice, and ensures that you won't miss any key areas in
your review. Use what's in the checklist to prompt other questions and checks
that may be relevant to the project.

The project does not have to tick all of the boxes to proceed, and there is no
required score or pass/fail mark. However, if there are several glaring gaps
the decision becomes fairly obvious. The checklist helps to identify serious
gaps and deficiencies to be addressed before go-live. It may also provide
support for further funds or resources if a particular area needs addressing.
The checklist should support the decision making process, rather than form
the basis of a decision. Whoever makes the decision (normally a steering
committee) must also consider the bigger picture and include other factors
such as external pressures, urgency to proceed, appetite for risk,
consequences of delays, etc.

If significant gaps are identified, it is usually far better for all concerned to
delay implementation until these gaps have been addressed/mitigated. The
implications and costs of a failed or troublesome go-live are often far worse
than a minor delay in the schedule. The only exception to this is if there is a
non-negotiable implementation date (e.g. a response to legislation changes
that have to be in by a certain date). In this case the gaps on the checklist
should be prioritised and addressed in order of importance and ability to
resolve. In this case by going-live the steering committee would essentially
be accepting the risks identified in the assessment, on the basis that meeting
the implementation date is more important than mitigating the risks and
having a smooth go-live.