Change Management Process

Change Management Process Version 1.0 1

Table of Contents 1 About This Document... 3 1.1 Document Objective... 3 1.2 Process Objectives... 3 2 Change Request Lifecycle Stages... 4 3 Change Request (CR) Requirements... 5 4 Approval Requirements... 5 5 Change Board (CB) Requirements... 5 6 Requirement Definitions... 6 6.1 Risk Assessment:... 6 6.2 Service Impact Assessment:... 7 6.3 Install Plan:... 7 6.4 Backout Plan:... 8 6.5 Test Plan:... 8 6.6 Communication Plan:... 8 6.7 Approvals:... 8 6.8 Install Results Details... 9 6.9 Post Implementation Review (PIR)... 9 7 Inquiries... 10 8 Definitions and Acronyms... 10 9 Reference... 13 Revision History Author Version Description Date Ken Merkel 1.0 Document Creation August 13, 2015 Sandy Stout Gemma Tungul Ken Merkel Sandy Stout Gemma Tungul Caroline Schulte 1.0 Document Publication August 31, 2015 2

1 About This Document 1.1 Document Objective The Change Management Process document provides guidelines in order to conduct a change according to the Service Alberta Change Management process. This document applies to the changes that are managed under the Government of Alberta (GoA) Change Management control. 1.2 Process Objectives The primary objective of the Change Management process is to enable beneficial changes to be made, with minimum disruption to IT services. The Change Management process has several other objectives: To standardize Requests for Change (RFC), and formalize their handling. To investigate the impact and risk of the change to the existing infrastructure or processes, and assess the appropriateness of the change. To obtain authorization for the change by the appropriate approver(s). To schedule the implementation of the change into production. To coordinate multiple changes across the GOA service providers and customers 3

2 Change Request Lifecycle Stages These are the 5 Change Request Stages/Phases: Initiate A Request for Change (RFC) is initiated and populated by Change Coordinator/Change Implementer. Initial classification and impact/risk assessments are performed and the ticket is populated with the required information. Review & Authorize The Change Manager reviews the change for completeness, confirms the impact of the change and identifies the appropriate approvers for the change. Plan & Schedule The Change Manager approves and submits the change to the appropriate approvers ((optional) Change Board, Service Owner. If communication is required, the Change Manager requests the communication to be distributed. The change is then scheduled for implementation. Implement The Change Implementers perform and record the required tasks and activities to implement the Change. Closed The Change Manager will perform a Post-Implementation Review to determine if the Change met its objectives. The change is then closed. 4

3 Change Request (CR) Requirements In order to conduct a change, these change requirements must be entered into a Change Request (CR). These are required prior to CR implementation: 1. Risk Assessment 2. Service Impact Assessment (include ministries affected, if any) 3. Install Plan 4. Backout Plan 5. Test Plan 6. Communication Plan These are required after CR implementation 7. Install Results 8. Post Implementation Review (PIR) The CR Requirements are listed with guide in this site: https://sharedservices.gov.ab.ca/sm/cm/cb/lists/cr%20requirements/change%20types.aspx 4 Approval Requirements Approvals are required within the CR Lifecycle. 5 Change Board (CB) Requirements Change Board Requirements must adhere to the Change Board classification and follow the appropriate lead time. Change Board Review is required on all changes that falls under the following guidelines: All outages longer than 10 minutes. All changes visible to the end users. 5

6 Requirement Definitions 6.1 Risk Assessment: Risk Assessment is the risks to the service during the change implementation and the risks to the service should the change not be implemented. The risk assessment may include: 1. What is the risk level assessment (Low, Medium, or High)? 2. Have you done this before successfully? 3. Can you test before and after implementation? 4. Risk of not doing the change (optional). Examples: Risk is assessed as low. This is a repeatable process done many times before and has been tested in UAT. Risk is assessed as low. Switch and router reloads are usually uneventful with the device coming back online within 5 minutes. There is always a chance (though very remote) that a device will fail it s reload and not come back online. In such a case a new switch or router would be provisioned during the block time. The risk of this change is low as the changes of similar type has been completed on other parts of the network and implemented as planned. The risk of not doing the change is that the current infrastructure is aged and does not meet security requirements. This could lead to vulnerabilities that may be exploited to compromise our network. 6

6.2 Service Impact Assessment: Service Impact Assessment is the impact of the change to end user during and after the change. The Service Impact Assessment should include: 1. How does this impact users of the service during the change? a. Is there an outage? b. How long is the outage? (Change Board review is required for all outages longer than 10 minutes). c. What time is the outage? 2. Will this impact the users after the change, a. Will there be a visible change to end users? (Change Board review is required for all changes visible to the end users). b. Will they have to do something different? 3. What Ministries are affected by this change (change board requirement only). (Change Board review is required if more than one ministry is affected). Examples: No service impact & no outage are expected during the change window. This change will be implemented seamlessly as there are 2 devices are serving user traffic simultaneously and there is no need for reboot. During this change, email and file services will be unavailable. Outage should only be 15 minutes at the start of the change although I have scheduled the entire hour in case more time is required. Ministries affected are: Service Alberta, Energy. The switch will be replaced during the lunch with Ministry approval to be attached to this ticket. While connections are moved from the old to the new switch, workstations and printers will not have network access throughout the entire building. This change will affect the Ministry of Service Alberta. 6.3 Install Plan: Install Plan is the detailed description of the installation. The install plan should be detailed enough so that another team member can complete the change. Examples: 1-Rack new router; 2-power up the router: 3-Move cables from the old to the new router; 4-check network connectivity Alter Channel CLIENT.TO.QNA3 parameter HBINT from 50 to 300 using ISPF interface. Change QNA3.PARMLIB(QNA3SGCO) member HBINT parameter from 50 to 300 for channel CLIENT.TO.QNA3 definition 7

6.4 Backout Plan: Backout Plan is the detailed description of the backout. The backout plan should be detailed enough so that another team member can complete the backout. If backout plan is not required, describe the reason why. Example: Old router can be reconnected within 1 hour. 1-Rack old router back; 2-power up the old router: 3-Move cables from the new to the old router; 4-check network connectivity 6.5 Test Plan: Test Plan is the detailed description of the test. The test plan should be detailed enough so that another team member can organize the test. The test plan should include: 1. What is the pre-testing plan? (if no pre-testing can be done explain why) 2. If applicable, detailed information on what pre-testing was done and the outcome 3. What is the post-testing plan? Example: After the migration, logon to the SPIN2 prod database servers and verify they are working fine. 6.6 Communication Plan: Communication Plan should include detailed information on what communication is required and to who it is going to. If no communication is required enter no communication required and explain why. The communication plan should include: 1. Communication Email 2. Communication Distribution Checklist 3. Communication Approval (email) Refer to this site: https://sharedservices.gov.ab.ca/sm/comm/default.aspx 6.7 Approvals: The following approvals are required within the lifecycle of a change. 8

1. Review CR Requirement Completion Approval Approver: Change Manager 2. Business Implementation Approval Approver: (One or more of the following) Service Owner/Ministry/Change Board a. Service Owner approval is required for all changes prior to implementation b. Ministry approval is required for all changes that impacts one ministry only. c. Change Board approval is required for all changes prior to implementation according to predefined Change Board Classification 3. Close Down PIR Completion Approver: Change Manager 6.8 Install Results Details Install Results is the detailed description of the success of the change. The install results should include: 1. Information on whether the change was successful or unsuccessful (e.g. Change was successful and completed in the scheduled time frame). 2. Information on what post testing was done and the outcome. Examples: Change was Successful; Change was implemented with in the allowed time without any incidents. Communication task were successfully completed. Testing Plan was successfully complete. Change had to be backed out by restoring previous settings. This change was not successfully implemented. Will be recreated and scheduled at another time. 6.9 Post Implementation Review (PIR) Post Implementation Review is the final review completed by the Change Manager to ensure change management process compliance prior to closure. Examples: Post-Implementation Review Results - This Change implementation has been deemed successful. 9

7 Inquiries Refer your inquiries to ict.change@gov.ab.ca. 8 Definitions and Acronyms Term Change Change Board Classification Change Management Class Definition A change is the addition, modification, or removal of approved, supported or standard hardware, network, software, environment system, or associated documentation (collectively known as Configuration Items). The need for a Change can arise as a result of an Incident, Problem, Known Error and its resolution, or from proactively seeking business benefits. All Changes are classified into one of the following two classes: Operational changes are those changes which may impact the availability and/or quality of IT services while the changes are being performed, but which will not result in any visible change to customers and/or their end users once the changes are completed. Operational changes include regular maintenance and upgrades, expansion of the IT environment, etc. Business changes are defined as those changes which, once implemented, will result in a visible change in a service and its functionality to its customers and/or end-users. Business changes may include service support process and procedure changes, or upgrades or new releases of services which change the features of the service and/or how it is used by customers and/or end-users. Change Management is the process responsible for controlling the lifecycle of all changes. The primary objective of Change Management is to enable changes to be made, with minimum disruption to IT services. Class specifies the relative urgency of the change, so that the approvers can assess its magnitude. Normal is the default timing for a change. Approval from the Change Manager and the Service Owner is required. Emergency is a change which is required to resolve an incident or problem deemed critical to business continuity, or in some cases, to prevent an incident or problem that is about to occur. Change Management approval and Service Owner or alternate approver are required prior to implementation but Change Board requirements do not apply. Latent is a Change that has already been implemented. This class type should only be used for changes that were implemented without prior Change Management approval due to the urgency of the situation. Approval must be 10

Term Definition received by the Service Owner or alternate approver and it must be attached to the ticket. Customer End-user or user Impact The recipient of a service. In this environment, the ministries of the Government of Alberta are the customers. The person who uses the services on a day-to-day basis. In classifying Changes as operational or business changes, service provider users who are involved in the delivery of the service are not considered users of that service, although they are affected by the quality and availability of those services. Means the known or anticipated effect of a Change to service availability, service quality, business continuity, etc. Typically this will relate to the number and type of users affected by the Change being proposed. It is often equal to the extent of a distortion of agreed or expected service levels. Impact can be: Minor/Localized: The Change will have little or no effect to end users during working hours, but may require the service to be unavailable for less than 10 minutes during non-working hours. Moderate/Limited: The Change may affect a moderate number of users, probably limited to a single branch or large user group and may require the service to be unavailable for longer than 10 minutes or have a visible change to end users. Significant/Large: The Change may affect a single Ministry or several branches across multiple Ministries and may require the service to be unavailable for longer than 10 minutes or have a visible change to end users. Lead Time Extensive/Widespread: The Change affects multiple Ministries and may require the service to be unavailable for longer than 10 minutes or have a visible change to end users. Implementation Lead Time is the recommended amount of time the submission of a Change Request and the earliest time that the proposed Change implementation should begin. The following are the implementation Change Board lead times required by Service Alberta Change Management: Minimum Lead Description Time 7 business days - Must be submitted no later than Monday, 4:30pm in order for the change to appear on the Wednesday Change Board Agenda. - In case of holidays (ie. Holiday Monday) preference would be to have the CR ready by Friday, 4:30pm BUT CRs will be accepted until Tuesday at noon. - Additional 5 days for Communication 11

Impact Change Management Process Term Priority Definition Distribution Priority is an indicator of the relative importance of a change. It is used to determine the sequence in which a change needs to be resolved, and therefore the speed at which the resolution will be approved and deployed. It is based primarily on the Impact and Urgency, although the business risk of not implementing the change is another important criterion for determining the priority of a change. Priority can be: Low: A Change that impacts few users, and can be implemented in the longterm Medium: A Change that impacts a moderate number of users, and can be implemented in the medium-term High: A Change that impacts a significant number of users, and must be implemented in the short term Critical: A Change that impacts both a large number of users and must be implemented quickly Request for Change (RFC) or Change Request Risk Priority Urgency Critical High Medium Low Extensive Critical Critical High High Significant Critical High High Medium Moderate High High Medium Low Minor High Medium Low Low Form (or screen) used to record the details of a Change Request to any service and/or Configuration Item. This includes a description of the change, the affected components, the business justification, an impact and risk assessment, resource requirements, and approval status of the change. Submission of this form or screen is the required initial step in Change Management process. Risk assessment is concerned with analyzing threats and weaknesses that have been or would be introduced as a result of a service change. A risk occurs when a threat can exploit a weakness. The likelihood of threats exploiting a weakness, and the impact if they do, are the fundamental factors in determining risk. Risk Level 1-2 (Low): (E.g. Routine change with proven success; minimal impact if Change fails; no back out required or back out is simple) Risk Level 3-4 (Medium): (E.g. High probability of success; back out is involved but not difficult; moderate visibility potential to customers) Risk Level 5 (High): (E.g. Change is complex or high risk; implementation is difficult; back out is lengthy and/or difficult; high visibility potential to customers.) 12

9 Reference Change Management Documentation is located here. Change Management Sharepoint site is located here. Service Alberta Change Board Sharepoint Site (OCB/BCB) is located here. 13