• No results found

Change Management Process

N/A
N/A
Protected

Academic year: 2021

Share "Change Management Process"

Copied!
13
0
0

Loading.... (view fulltext now)

Full text

(1)

Change Management Process

(2)

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 Sandy Stout Gemma Tungul

1.0 Document Creation August 13, 2015

Ken Merkel Sandy Stout Gemma Tungul Caroline Schulte 1.0 Document Publication August 31, 2015

(3)

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.

(4)

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.

(5)

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.

(6)

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.

(7)

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

(8)

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:

(9)

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.

(10)

7 Inquiries

Refer your inquiries to ict.change@gov.ab.ca.

8 Definitions and Acronyms

Term Definition

Change 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.

Change Board Classification

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 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 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

(11)

Term Definition

received by the Service Owner or alternate approver and it must be attached to the ticket.

Customer The recipient of a service. In this environment, the ministries of the Government of Alberta are the customers.

End-user or user 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. Impact 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. 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.

Lead Time 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 Time

Description

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.

(12)

Term Definition

Distribution

Priority 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 long-term

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

Priority Urgency

Critical High Medium Low

Imp

ac

t

Extensive Critical Critical High High Significant Critical High High Medium Moderate High High Medium Low Minor High Medium Low Low Request for Change

(RFC) or Change Request

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 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.)

(13)

9 Reference

Change Management Documentation is located here. Change Management Sharepoint site is located here.

References

Related documents

In theory, FRET is a radiationless energy transfer process, so ideally, a single emission spectrum of the output fluorophore should be observed, as illustrated in Fig.2.7

The study results demonstrate that youth with hemo- philia who obtained annual care at HTCs, and who en- rolled in the UDC surveillance project, had high levels of insurance

Complete Remission Rates and 7-Year Overall Event-Free Survival Rates in Adult Acute Promyelocytic Leukemia Patients in the Japan Adult Leukemia Study Group Studies From 1987 to

Drawing a selection of indicators from the master indicator list, the manage- ment dashboard informs your management team and board, while any program-level dashboards

Clearly indicate the necessary steps, including appropriate formula substitutions, diagrams, graphs, charts, etc. Utilize the information provided to determine your

A guideline to using portable XRF according to EPA method 6200, basic overview of the technique of x-ray fluorescence (XRF), appropriate data quality assurance protocols and

For helpful overviews of the global situation, see Steven Hahn, "Class and State in Postemancipation Societies: Southern Planters in Comparative Perspective,"