From MIKE2 Methodology
| This deliverable template is used to describe a sample of the MIKE2.0 Methodology (typically at a task level). More templates are now being added to MIKE2.0 as this has been a frequently requested aspect of the methodology. Contributors are strongly encouraged to assist in this effort.
|
| Deliverable templates are illustrative as opposed to fully representative. Please help add examples to this template that are representative of the proposed output.
|
The Deployment Plan provides the major tasks and timelines for implementing the solution into production. It includes a strategy for how the solution will be implemented, success factors, go/no-go checkpoints, contingency measures and procedures for system maintenance and outages. The complexity of the Deployment Plan depends greatly on the type of solution being implemented, especially factors such as number of users, whether it an operational system, its availability and number of downstream systems that would be impacted.
Examples
Listed below is an example Deployment plan:
Example for a sample Deployment plan
Introduction
The purpose of this document is to identify the deployment requirements and approach for the deployment of Client Asset Management Suite (XYZ) Phase 2 to users within Client. XYZ Phase 1 is currently running in a live production environment. XYZ Phase 2 will add the following three modules to the existing Phase 1 installation:
- Indication
- Origination
- Maturity
This deployment plan document includes deployment approach, training requirements and operational readiness checks for deployment of XYZ Phase 2.
Deployment Pre-requisites
Indication and Origination
Deployment for the Indication and Origination need to be at the same time. It will not be possible to deploy only one of these two modules separately.
Maturities
Maturities can be deployed separately to Indication and Origination. The current plan (v3) is to deploy Maturities at the same time as Indication and Origination.
Training Plan
Training will be required as part of the XYZ deployment. Training will be conduced by Client.
User training will be required as part of the XYZ deployment.
The table below identifies the users involved in managing the XYZ environment and the areas they would require system training
| User
| Location
| Responsibilities
| Training Needs
|
| John Smith
| London
| Super user
| Super user
|
|
|
|
|
|
Deployment Scope
This section defines the scope of the system deployment in terms of objectives and sites.
Production cutover is the transfer of the XYZ solution from the project team to the Client business.
XYZ is deployed via a browser. The users will be provided with a URL that needs to be entered into the address bar of a Web Browser. The URL will take the user to the XYZ login screen. As XYZ is a browser based application no software is required to be installed on the users desktop.
XYZ is a hosted application. This document does not include any XYZ installation notes.
XYZ Deployment Process and Release Notes
Client software will issue release notes in advance of each new code drop to the staging environment. The diagram below shows the logical view of the environments and the logical environment promotion view.
Deployment Calendar
Key Dates:
| Dry run
|
| Sunday 18th July
|
| Deployment
|
| Saturday 22nd and Sunday 23rd July
|
| Business as usual
| Monday 24th July
|
The below diagram shows the cut over approach for Indications, Originations and Maturities:
Go-Live Resource Plan
The following resources are required on the cutover weekend:
| Resource
| Role
| On-site requirement
|
| John Smith
| Client lead
| On-site
|
| Joan Smith
| Deployment lead
| On-site
|
| John Green
| Post deployment support lead
| Remote support
|
| Test Team
| Deployment test and sign-off
| On-site
|
| Test Team
| Deployment test and sign-off
| On-site
|
Cut Over Weekend Activities
| Date / time
| Activity
| Owner
|
| Fri 21st July 5pm
| Client users stop making any more changes and updates to the XYZ system
| John Smith
|
| Fri 21st July 6pm
| Client make a back-up of the XYZ database
| Client sofware
|
| Fri 21st July 7pm
| Client begin the upgrade which includes Data Load as mentioned in Section 3.1 below
| Client sofware
|
| Sat 22nd July
| Client run through user acceptance testing scripts to check the deployment is successful
| John Smith
|
| Sun 23rd July am
| Client run through user acceptance testing scripts to check the deployment is successful (if required based on progress made on Saturday)
| John Smith
|
| Sun 23rd July 4pm
| Decision made on deployment status
Sign-off based on successful execution of user acceptance testing scripts
OR
Decision made to revert back to backup made on Friday and continue business as usual from 5pm on Friday
| John Smith
|
| Mon 24th July 8.30am
| Revert to business as usual
| Client
|
| Mon 24th July 8.30am
| Revert to business as usual
| Client
|
Data load
There will be approximately 2 additional data tables that will be loaded into the XYZ database. First table will be used for staging the initial data uploaded from RAP, the second table is the table that has the exact number of columns and information needed for operating within XYZ User Interface.
Success Process
The following is a list of go-live success criteria:
- Performance testing passed
- User acceptance testing scripts passed
Decision Tree on Deployment Cut Over
From Client Software, the following team will manage the go-live cut over:
- Joan Green – Overall management of cut over
- John Smith – Project management and documentation. John will work close with Joan to ensure details of project objective are met, and all outstanding items have been delivered.
- John Smith – XYZ Support
- Joan Green – Standby for any emergency support items
- Peter Green - Facility support, this includes platform, network, and connectivity.
Backout Procedures
In the event that following execution of user acceptance testing scripts during the cutover weekend problems were found a decision will be made that the deployment cannot take place.
The XYZ system will revert back to the backup made on Friday and business as usual will continue from the point where the backup was made (scheduled for 5pm on the Friday before the deployment weekend).
In the event that backout procedures are applied the following should take place:
- Document the decision to delay the system go-live date and the reasons why
- Execute a number of user driven tests to confirm the prove backout process was successful and that status is at 5pm on the Friday prior to the go-live cut over.
Transition to Operations
xxx
Go-Live Resource Transition Plan
The table below identifies resources that will transition as XYZ is moved from development into a live operational environment.
| Resource
| Role
| Roll-off date
|
| John Smith
| Client lead
| TBC
|
| Joan Green
| Business Analyst
| July 14th
|
| John Brown
| Project Manager
| July 23rd
|
Post Deployment Support During the First Week
Starting with the creation of the production instance the process will close when the acceptance criteria for "live" system are met
The table below shows the Operate activities during the first week of Phase 2 running in Production.
After Friday 28th subject to sign-off support reverts to standard support procedures as agreed with XYZ and Client.
Operational Model Effective Date
Following acceptance that the deployment is stable the proposed business as usual operational model will be effective from the Monday July 21st 2000.
This marks the end of the Production cutover process will mark the beginning of application support per the Go-Live and then cutover to the On-going Support Plan.
XYZ Support, Alerting and Monitoring Procedures
XYZ application support and application alerting and monitoring procedures in the vent of application outages will be covered in separate documents
BlogMarks
del.icio.us
digg
Furl
Simpy
smarking
