What is Governance and Escalation Model – IaaS Application Migration Project
A governance model is the mechanism used by the project management to translate the elements of the governance framework and policies into practices, procedures, and job responsibilities within the boundary of the project. An escalation plan is a set of procedures set in place to deal with potential problems in a variety of contexts. Example: Project team need to reach out a key stakeholder in the program to make a decision of a go-live/roll-back.
Why Governance and Escalation Model is important
- To understand clear direction
- To make key decisions
- Clear roles and responsibilities
- Stakeholder visibility and assistance
- Escalation path is defined to assist
- Budget tracking
- To track the delivery of project
IaaS Application Migration Project Governance Model
Below is an example of a governance model.
Application Migration – Escalation Matrix
Below is an example of an escalation matrix, which is helpful to escalate from those 3 levels when required.
Application Migration – Incident Management Process
Typically, the IaaS project will use the existing incident management process but will provide project support assistance if required to resolve an incident related to new migration or roll-back. These activities occur during post go-live warranty periods or when an application is rolled back but caused an incident.
Application Migration – Telephone Conference Details
It is important to provide telco details to jump on conference calls. These are for technical and non-technical management and resolution activities.
Warranty Period – Definition
- Provision of IaaS project resources to provide assistance to the BAU teams, in the event that incidents require support and or resolution for an agreed period of time. By definition BAU teams can constitute application teams, vendor A and vendor B infrastructure teams.
- A warranty entails an obligation to eliminate any defects in the operation of a product directly related to production workloads and as a result of project activity. During the warranty period the project must fix all defects within the agreed time limit, provided that the following conditions are met:
- evidence of system issue(s) is given;
- agreement that the issue occurred due to a project activity;
- no unwarranted interference with the migrated application;
- application feature is covered in the requirements.
Application Migration – Warranty Support Activities
Typical warranty period activities can be,
- Warranty support from project will be provided at least minimum of 14 days of application being successfully migrated or the period agreed by steering committee / IT owners.
- Project team will update Service Desk with newly migrated application details prior and post application being migrated.
- Project team will be available from 8am post migration day, to provide support if required, including to participate in warranty meetings.
- Project team will assist to resolve migration related incidents during the agreed warranty period.
- Project incident queue will be created via <TOOL> to direct required project support to incidents. These incidents will be clearly tagged by BAU team to separate from other BAU incidents to assist IT scorecard.
- TOOL group needs to be monitored after a cutover during warranty period.
- Existing incident management and major incident management process will be followed, project team will be notified by BAU team to participate if required.
- A change freeze period is agreed before and after migration with application owners.
- If significant changes are expected to resolve an incident due to project activity, the effort/Charges will be absorbed by the project team.
- If required, project team will participate in the Daily Operational Forum.
- Go/No Go – at agreed point of no return after successful cutover and during warranty period, rollback/fix forward will be performed if pending issues. Final decision maker will be the sponsor, while the contributors are Project, Service Delivery Team and IT owners.
Go/No Go – Decision 2 (During Warranty Period) – Criteria for Consideration – Rollback/Fix Forward
Exit Criteria – Warranty Period
Example of exit criteria’s when we exist warranty,
- All critical issues have been resolved.
- All project related incidents have been updated/resolved.
- All necessary and required knowledge and documentation have been updated.
- Evidence of testing details available from testing tool.
- IT Owners sign-off obtained.
- BAU acceptance obtained for migrated applications from organisation’s SDM
Summary
I hope that above examples are useful to your project to create an effective governance, escalation and warranty period model. Thanks.