mcgill it services change management process guide

McGill

IT Services

Change Management Process Guide Version 3.2

Frank Pettinicchio

May 31, 2013

McGill IT Services Change Management Process Guide

May 31, 2013 Draft Version 3.2 Page 3

Table of Contents

Table of Contents .......................................................................................................................................... 3

Change Management Overview ................................................................................................................... 8

Change Management Process Principles .................................................................................................. 9

Basic Concepts .......................................................................................................................................... 9

The Approval Process .............................................................................................................................. 10

RFCs ......................................................................................................................................................... 10

CAB Meetings .......................................................................................................................................... 11

Post Implementation Review (PIR) ......................................................................................................... 12

Change Categories ...................................................................................................................................... 13

Emergency Change.................................................................................................................................. 13

Standard Change (aka standard operating procedure - SOP) ................................................................. 13

Normal Change ....................................................................................................................................... 13

Change Categories and Impact Levels ........................................................................................................ 13

Change Models and Work Flows ............................................................................................................ 14

Change Management Process Flow ........................................................................................................ 15

Basic workflow for Normal, Emergency and Standard changes ............................................................. 17

Examples of changes ............................................................................................................................... 17

Factors used to evaluate the Impact/Risk Complexity of Change .............................................................. 18

Factors that raise or reduce risk and impact .............................................................................................. 19

Emergency Change Models ......................................................................................................................... 20

Emergency Changes Model Sub Processes: ............................................................................................ 22

Changes that involve security issues and/or confidentiality: ..................................................................... 23

Unified view of Change Categories ......................................................................................................... 24

Process Roles and Responsibilities ............................................................................................................. 25

Process Role Descriptions in Brief ........................................................................................................... 25

Charting definitions ................................................................................................................................. 25

ITSM Owner - CIO .................................................................................................................................... 27

ITSM Executive Committee ..................................................................................................................... 27

Change Management Process Owner (CPO) .......................................................................................... 27



Change Management Process Steering Committee ............................................................................... 29

Change Process Manager ........................................................................................................................ 29

Change Advisory Board (CAB) ................................................................................................................. 30

Emergency Change Advisory Board (ECAB) ............................................................................................ 31

Change Owner ........................................................................................................................................ 31

Service Owner ......................................................................................................................................... 32

Change Requestor ................................................................................................................................... 32

Change Implementer .............................................................................................................................. 33

Creating and Modifying Change Task Lists ................................................................................................. 34

Change Categories and Impact Levels .................................................................................................... 34

IT Units Role and Responsibilities: ......................................................................................................... 34

Requestors (RFC Submission) Role and Responsibilities: ....................................................................... 34

Changing and Reappraising the Impact of Change Tasks ....................................................................... 35

Change Categories and RFC Processing .................................................................................................. 36

Lead Times for RFC Processing .................................................................................................................... 37

View of Timelines for Significant and Major RFCs .................................................................................. 39

Process Metrics ........................................................................................................................................... 40

Disposition Metrics ................................................................................................................................. 40

KPI Lifecycle............................................................................................................................................. 42

SSA System Status Alerts .......................................................................................................................... 43

Notes for SSAs for RFCs: .......................................................................................................................... 44

Appendix A: Creating an RFC ...................................................................................................................... 45

Select the Change Task for the RFC: ....................................................................................................... 46

Select the CI(s) for the change ................................................................................................................ 47

Step2: Identification ................................................................................................................................ 48

RFC Title: ............................................................................................................................................. 48

Priority:................................................................................................................................................ 49

Risk: ..................................................................................................................................................... 49

Impact: ................................................................................................................................................ 49

Approved by manager:........................................................................................................................ 49

Approved by owner: ........................................................................................................................... 49

Implementation duration: .................................................................................................................. 49



Back out duration: ............................................................................................................................... 49

Service Disruption: .............................................................................................................................. 49

Description of change: ........................................................................................................................ 50

Who will be affected: .......................................................................................................................... 51

Effect if change will not be implemented: .......................................................................................... 52

Test plan and test results: ................................................................................................................... 53

Risk analysis: ....................................................................................................................................... 54

Alternate solutions considered: .......................................................................................................... 55

Back out plan: ..................................................................................................................................... 56

Communication plan: .......................................................................................................................... 57

Budgetary impact: ............................................................................................................................... 58

Verification checklist: .......................................................................................................................... 59

Appendix B: Closing an RFC ......................................................................................................................... 60

Basic Flow of the RFC Implementer Close .............................................................................................. 60

Implemented with no problems ............................................................................................................. 61

Cancelled ................................................................................................................................................. 61

Implemented with incident .................................................................................................................... 61

Backed out .............................................................................................................................................. 61

Implemented with Exception .................................................................................................................. 61

Final RFC Closure Status .......................................................................................................................... 62

Using IT Service Motion to Close the RFC ............................................................................................... 63

Use the link https://itservicemotion.campus.mcgill.ca to begin a session with NCS Motion and follow the instructions provided to close an RFC. By hovering (dont click) the mouse over My Stuff tab, as shown (below) and select either My Open RFCs or My group open RFCs. ............................................ 63

Appendix C: Risk Assessment ...................................................................................................................... 64

High risk............................................................................................................................................... 64

Moderate risk ...................................................................................................................................... 64

Low risk ............................................................................................................................................... 64

No risk ................................................................................................................................................. 64

Testing and Validation Recommendations Based on Impact and Risk ................................................... 65

Risk and Impact ....................................................................................................................................... 66

Appendix D: Selected ITIL Glossary (source ITIL Foundation) .................................................................... 68



Appendix E: Current Change Advisory Board Members (as of July 16, 2010) ............................................ 71

Appendix F: Document Changes ................................................................................................................. 72

New RFCEmergency

Change(ECAB)

CM Review

CAB Review

Implementation

RFC rejected

Change Review Change completed

Test the change

Urgent

ChangeCompleted

ExceptionalSignificant or Major Change

Exception to

process cycle

CAB Rejects

Back out

Implement Emergency

Change

Self-approved Change

MinorChange

CM Rejects

Reopen RFC

Test Failed

QA Testing

Review the Change

Expedite

Change Management

New

Tier 1

Tier 2-N

Investigation & Diagnosis

Resolved (Customer approval)

Pending Change

Closed

Resolved

Major

Request for Change

Resolved - Close

Implement Change

Resolved - Close

Request Change

CM Rejects Change

Incident Management

Assigned

Functional Escalation

(Tier 2)

Major Incident

Procedure

Change completed

Resolved Re-assign to

Tier 1

Report Problem

Resolved Notify customer

Resolved

Resolved Re-assign to

Tier 1

Management Escalation

Hierarchic Escalation

Hierarchic Escalation

Create aLinked

Change)

New

New Problem

Classification

Investigation & Analysis

Known Error

Problem Closed

Request Change

Change Implemented

Problem Management

Create problem record

Classify Problem

Investigate Problem

Pending Change

Successfully

Known ErrorWorkaround

Known Error

Request Change

Resolved

Unsuccessfully

Rejected Change

Link Incident

Resolved Problem

CreateLinkedChange

Create Linked ProblemLinked Incident

Significant and Major

Change Management Overview

The goal of the Change Management process is to ensure the efficient and prompt handling of all changes to IT infrastructure through the use standardized methods and procedures. The process ensures the ability to measure the impact of service changes within IT infrastructure and to minimize the impact of change-related incidents upon service quality.

ITIL V3 Service Transition defines Change Management as the addition, modification or removal of authorized, planned or supported service or service components and its associated documentation. In this way Change management is responsible for managing change involving:

Hardware Communications equipment and software System software All documentation and procedures associated with the running, support and maintenance of IT

services.

Benefits of Change Management

Risk Reduction

Change Management minimizes the risk of introducing harmful changes into the production environment.

Service Quality Improvement

The proper assessment of the impact of changes prevents unscheduled service outages. This increases service quality. Change records allow for continuous process improvement and facilitates the resolution of issues related to change.

Cost Reduction

Effective change management reduces rework and back outs.



Change Management Process Principles The following section is a description of how Change Management is deployed and practiced at McGill. Here is outlined the standards and procedures adopted over time to frame and guide the process these are the rules. Detailed discussion on various concepts and guidelines is found in later sections.

Basic Concepts 1. An RFC (Request for Change) triggers the process. 2. The RFC becomes a change record that tracks the change through the process. Key events and

timeframes are made available to stakeholders (the Service Desk is critical in this goal) so end users can be kept informed. At completion the change is reviewed.

3. Two key change activities are change prioritization and change categorization. Prioritization is used to establish the order in which changes are considered. Categorization examines the impact of the change on the organization.

4. Minor Changes are approved by the Change Manager or the Change Manager can delegate the approval authority to the technical teams.

5. For Significant and Major Changes, the Change Manager will consult the Change Advisor Board (CAB) before approving the change.

6. In order to streamline the approval process, the concept of a Delegated Change is introduced. Delegated changes are changes that are frequent in nature and low in risk/impact. The CAB can designate a change task as a Delegated Change if a) precedent setting Minor change has been assessed and successfully implemented and b) the technical team requests delegated status for the task. If granted, the approval of such a change rests with the technical team. In effect, Delegated Changes are pre-approved. The unsuccessful implementation of delegated changes will result in withdrawal of the delegated status and a return to Minor. These should be develop whenever possible in the change management process - reduces red-tape, increases efficiency

7. Urgent and Emergency changes are dealt through appropriate change models to expedite their path through the process. This typically requires a meeting of the Emergency CAB (CAB/EC).

8. Inputs to the Change Management process:

A request for Change (RFC) CI data from Configuration Management Change implementation procedures

9. Process Outputs:

Detailed change records Implemented change Change Advisory Board (CAB) minutes and actions Change Management reports Information provided to Configuration Management for updates to Configuration Items

(CIs)



The Approval Process 1. All changes to CIs must follow the Change Management Process. 2. All RFC submissions must respect the process lead times. Failure to do so may result in the

rejection of the RFC. See Lead Times for RFC Processing for more detail. 3. RFCs for third parties (vendors or non-McGill IT staff) will be submitted by the McGill IT staff

responsible for the service or infrastructure in question. This will ensure that process standards and objectives are respected.

4. The RFC will fit into one of four predefined categories (see the Change Categories and Impact Levels section for more details)

a. Standard changes are self-approved and may, with the consent of the CAB, be removed from the Change Management process.

b. Delegated changes are Minor changes that have been proven to be safe, predictable and repetitive. The technical team will petition the CAB for delegated status for such Minor changes. Delegated changes are self-approved.

c. Minor changes are approved by the Change Manager (CM). d. Significant and Major changes are approved by the Change Manager after consulting

the CAB. 5. The CAB has a standing meeting time of every Wednesday at 10:00 AM in BH201. Significant and

Major RFCs are presented and discussed. 6. Most RFCs are approved (with or without conditions) through consensus. Should the need arise

a vote will be taken. RFCs may be approved or rejected based on the content of the RFC and the testimony provided by the requestor, the change sponsor and attending CAB members. Objections, reservations and issues of note will be entered in the CMs notes and placed in the RFC. Approval may also be conditional in that the requestor may be mandated by the CAB to make changes to the RFC before it can be finally approved.

7. Should strong disagreement arise that cannot be resolved among the CAB, upon the discretion of the Change Manager the issue may be escalated to the directors level.

8. In the case of urgent changes or changes that cannot wait for a CAB meeting, upon the requestors or the CMs initiative, the CM may schedule a CAB consultation via email. The RFC is emailed for deliberation with a time limit for response. At the end of the time allotted the CM will approve the RFC should no objections be raised. Should an objection be raised the Change Manager will notify the rest of the CAB and the requestor of the objection. The CM will negotiate with the requestor the necessary changes to meet the ECABs objections. The same rules apply for approval or rejection as stated in item 5.

RFCs 1. RFCs and their content are the responsibility of the line manager. The requestor and his or her

manager (the accountability extends to the Unit Director) are responsible for the accuracy of the facts contained and any analysis (e.g., risk) that is provided. This includes the following:

o A valid case for implementation o A well planned and documented method for implementation o Valid test results (where applicable) of the proposed change o A risk analysis that includes what how many users, and how users and services are

affected by the change o A well-documented and tested back out plan should the change fail at any point of

implementation



o Appropriate communication plan ready for delivery to ICS, Operations and affected stakeholders. ICS will be responsible ensuring communications standards and for executing the portions directed at users or other segments of the McGill community.

o A post verification plan 2. All RFCs that contain planned service outages must be accompanied by an SSA (System Status

Announcement). This will serve to disseminate among IT staff the time and purpose of the outage and allow for a reaction to the planned outage either to support the work or plan around the work.

3. The CM and the CAB will use the content of the RFC to make decisions. 4. When the information appears incomplete or inaccurate, the CM or the CAB can ask for

clarifications, further preparatory work (testing, risk appraisal, communication plans, etc.) or a rescheduling of the change. These changes must be updated in the RFC before the approval process can resume.

CAB Meetings 1. The CAB meetings are chaired by the Change Manager. 2. Given the importance of the CAB activities:

o Meetings are relatively formal. A well planned and executed meeting saves time and effort attendance is not compulsory and we want members to keep coming back.

o It is highly recommended that no competing meetings are scheduled by other standing or ad hoc committees during the weekly CAB meeting day and hour (Wednesday at 10:00 AM). This ensures that the CAB will be attended by the core members and by invitees to provide subject matter expertise.

3. Meetings that do not have RFCs for consideration are usually cancelled within 24 hours. If procedural issues or other important matters dictate, the meeting will include these on the agenda.

4. The standard CAB agenda will contain the following items: o Approval of the agenda o Approval of the minutes of the previous meeting o Business arising from the previous meeting (includes reviewing the status of RFCs

presented in the previous meeting o Update on up-coming events or special issues that affect change management o Candidate RFCs for that days deliberation o Other business (discussion items)

5. Attendance is recorded for each meeting. 6. The Chair sends out the proposed agenda one or two days before the meeting. CAB members

may suggest additional items for discussion prior to the meeting or during the approval of the agenda. The CM will ensure that the agenda can be executed within the scheduled hour. The CAB can set priorities for agenda items to ensure that the most important items are completed during that meeting.

7. The minutes of the previous meeting are sent out with the new agenda. 8. The agendas and minutes are published on a SharePoint site (see below). 9. The requestor has an open invitation to attend the meeting at which his RFC appears on the

agenda. Stakeholders may attend to support the RFC or contribute to the discussion. The requestor will be asked to summarize the change and provide pertinent information. The CAB members may pose questions to clarify any ambiguity or for more specific detail about the RFC.



10. At each meeting the status for the RFC candidates of the previous meeting are reviewed. 11. The CAB or the CM may call for a more formal Post Implementation Review (PIR) in cases for

emergency changes or where major failure or error occurred. It is expected that the requestor and other contributors be in attendance for questions from the CAB members. A CAB PIR template may be sent to the requestor prior to the meeting.

12. The SharePoint site contains the IT Services Change Management documents as well as other resource materials. https://agora.mcgill.ca/cio/itsm/cm

Post Implementation Review (PIR) Post Implementation Reviews ensure that the cycle of Continuous Service Improvement is addressed. The results of changes are assessed to find reasons for why the changes have been unsuccessful or failed (in one or more aspects). It is the means for arriving at recommendations to prevent recurrence of unsatisfactory aspects a change and, when applicable, recommendations for adoption of best practices.

A Post Implementation Review should be conducted for all changes. The level of detail of the investigation is suggested by the impact, risk, complexity and poor outcomes. Significant and Major changes require greater scrutiny. Minor and standard changes will require only cursory review except for circumstances where the change encounters difficulties.

A Post Implementation Review will be conducted on all changes using a consistent format and shared electronically, with a greater focus on the following types of change:

Urgent-Unplanned changes

Emergency changes

Backed Out changes

Failed changes

Changes resulting in incidents

A standard form consisting of a series of questions will be used to gather information about the outcome of the RFC. Based on the responses to this initial PIR form, the CM may determine that a more formal and detailed PIR is required.

A formal PIR will consist of a standard report detailing:

Recommendations for technology or infrastructure improvements Lessons learned leading to Knowledge Records Recommendations for process improvements.



Change Categories ITIL V3 defines three change categories (types) Emergency, Normal and Standard. Each type follows a process model (workflow).

Emergency Change An emergency change is a change that must be introduced as soon as possible: e.g.

o To resolve a major incident (Priority 1 or 2) o To implement a security patch o Business need or constraint

These changes often cant wait until the next scheduled CAB.

Standard Change (aka standard operating procedure - SOP) A standard change is a preapproved change that is low in risk, common and follows a well-documented procedure or work instruction

It is not necessary to submit an RFC to implement a standard change o Standard changes are logged and tracked using a different mechanism (e.g. using

Service Requests) o Ensure standard changes are integrated with other service management processes. (e.g.

Incident Management ticket system and Request Fulfillment) Master criteria is Risk/impact and not complexity/frequency

Normal Change Neither an Emergency change nor a Standard change It is the addition, modification or removal of anything that could have an effect on IT services.

ITIL version 3 has introduced the concept 'Normal' change. It follows the full-blown ITIL Change Management process- assessment, authorization, CAB approval, scheduling before implementation. Based on the scope, complexity and impact, a normal change can be further categorized as minor, significant or major.

Anything refers to Configuration Item or CI. A CI is (ITILv3): [Service Transition] any Component that needs to be managed in order to deliver an IT Service. Information about each CI is recorded in a Configuration Record within the Configuration Management System (known generically as the CMS and IT Services Motion at McGill) The Configuration records collectively known as the Change Management Database or CMDB) are maintained throughout its Lifecycle by Configuration Management. CIs are under the control of Change Management. CIs typically include IT Services, hardware, software, buildings, people and formal documentation such as Process documentation and SLAs.

Change Categories and Impact Levels The creation and submission of RFCs is done via IT Services Motion web application ([email protected]). Appendix A provides a detailed discussion on how this is done. It begins with the selection of a task from a list of work that the units have provided for their respective units.



The tasks are applied against a service and have been analyzed by the units senior staff for impact and risk. The section Change Categories provides detailed guidance on how this is done.

Change Models and Work Flows Change Models refers to the method used to make a change. Broadly, there are three change models defined by ITIL (as discussed above) each of these can be refined into more change models as the need arises and opportunities of streamlining the execution of repetitive changes is identified. In the discussion below we continue to define and enhance our understanding of the three main ITIL change models (Standard, Normal and Emergency) and the three subcategories into which Normal changes are divided: Minor, Significant and Major. The important concept to retain is that the workflow, in broad terms, differs for Minor changes as opposed to Major changes. For example Minor changes are approved by the Change Manager, while Major changes are processed by the CAB and require greater rigor in planning and execution.

We can create our own change models to deal with changes that are repetitive and well understood and need specific handling and requirements. These models can be developed for either normal (of any subcategory) or emergency changes. The workflows for these locally defined models are a sequence of predefined steps to be taken in an agreed way. The model would include:

steps to be taken (activities, actions e.g. testing, assessing a change, approving a change), the order in which the steps are to be followed roles and responsibilities (who is going to do what), timelines (time needed to deal with a change at its various stages), thresholds (e.g. cant approve a change before next CAB then the change becomes an Expedited

change) and escalation (who to inform, from whom do we get additional authorization)

On the following page is a diagram illustrating the broad flow of RFCs through their lifecycles. For full detail of each change category please consult the discussion above.

Change Management Process Flow



q

Basic workflow for Normal, Emergency and Standard changes

Change Categories Change Model (work flow) Change Authority Normal Changes Must test

Must have back-out plan Assessed at regular intervals

(CAB meetings etc)

Change Manager Change Advisory Board

Emergency Changes Should test Should have back-out plan Assessed when they occur Fast-tracked once approved

Emergency CAB

Standard Changes Repetitive Low-risk Well-tested Defined outcomes

Pre-approved

Figure 1 Change Types

Examples of changes

Emergency Standard Normal Critical error in a vital business application

Creating a standard user in a directory service

Proposed upgrade of a software module

Updating of virus definition (outbreak)

Workstation relocation Adding terms and conditions to a contract or agreement

Network switch fails Password change Add a network switch to a wiring closet

Examples of the three basic change types



Factors used to evaluate the Impact/Risk Complexity of Change Change is applied against a Configuration Item (CI). CIs refer to any component that is part of the IT infrastructure. These include any hardware, software and documentation. CIs can be broken down into smaller tokens that are also known as CIs. Each CI has an implicit impact that is defined by the visibility of a change applied to it. This is measured by

The number of users that would lose service should the CI fail. The importance (value) of the service The cost incurred by the disruption.

Change Category

Authority Description Examples

Standard

Self-approved

A Standard Change has little or no external visibility, no external dependencies or no operator intervention. There is no associated risk or impact with the change.

Password reset Keyboard replacement Installation of a network Jack Adding removing a telephone

feature

Minor

Change Manager

A minor change is not transparent, but is minimal in risk and impact.

Oracle Database Parameters Change New virus signatures Server additions, modifications,

removals SAN storage

additions/deletions/modifications to a client

Delegated Self-approved (approval is delegated to the technical team by the CAB)

Minor change delegated to the technical team by the CAB as self-approved.

Network port additions, moves San storage additions to a client Backup client additions Routine database administration

tasks Data backups and/or restores

Significant

Change Advisory Board (CAB)

A significant change may impact a large number of users. It is a high risk change and may require a significant effort to back-out.

Internal database schema changes Network topology changes Server role changes Power shutdown

Major

CAB A major change has major impact on IT services (affects most if not all users). If a problem occurs during installation or the installation is complex and lengthy, the back-out is difficult or impossible.

Firmware upgrades on all switches and/or routers

New service/feature deployments, terminations

New technology or type of device introductions, decommissioning

Operating system, application software/firmware releases, upgrades

Change categories as implemented at McGill



Factors that raise or reduce risk and impact The table below illustrates how factors can increase risk and compound the impact of the work being done. It also shows how factors can mitigate the risk and overall impact of the proposed change. An analysis of these factors as applicable to the CIs in the proposed change is used to arrive at a comprehensive risk/complexity/impact profile for the change. The CM and the CAB rely on this analysis during the RFC approval process.

Factor Aggravation to risk/impact Mitigation to risk/impact Procedure applied to the CI (Configuration Item)

Major upgrade Major configuration changes

Reboot Minor configuration change

Impact on other systems or applications (interdependencies)

Several systems or applications are related to the change

Two (or less) systems or applications are related to the change

Degree of visibility to clients

Service disruptions are expected and user experience is affected

Transparent to users; i.e. Minimal or no service disruptions

Time scheduled During high peak usage During key high usage cycles of

academic activity or business processes

At the same time as other complex changes

During low peak hours and yearly cycles

Testing No testing done Testing not done on comparable

hardware/software Incomplete testing

Testing performed on a test or development bed

Testing is comprehensive and simulates workload

Change experience (familiarity with task)

New technology: limited or no experience

Existing technology: Considerable or some appreciable experience

Back-out effort duration

Back-out is Difficult, impossible or

undesirable Possible but not easily executed

(complex and lengthy)

Back-out is Well defined and easily executed minimal

Scope of change (# of CIs changed)

Hardware, software and network across one or more platforms

Two components on one platform

Single component Business process change (effect on usage)

Considerable and complex change required by IT and/or customers

Little or no change required

Stakeholder approval Little or no advanced notice and Planning did not include

stakeholders

Stakeholders have agreed to service disruptions and to the schedule

Stakeholders have influenced the RFC content and build

Verification plan (checklist)

Post implementation verification plan is weak

does or not include all major components of the service

Plan is comprehensive Staff has been assigned to verify

their areas of responsibility



Emergency Change Models Change management is a series of controls as contained in a formal RFC - to help manage the risk of making or not making a change. Emergencies, due to time pressures, make it difficult to follow the criteria set out for normal changes. Rather than suspend the change management process for emergency changes, this section outlines the emergency change models to be used. Caution should be exercised in appraising the state of the service. Our customers may be better served if the change could wait for a more opportune time or a better planned solution. The when in doubt reboot method as a process is vague (amorphous and changes day to day and individual to individual) and the outcomes are neither predictable nor repeatable. There is no sustained effort to ascertain the root cause so as to prevent recurrence and by extension disruptions in service, nor is there an abiding concern for how users experience the randomness of the delays and interruption to services.

All emergencies are a result of Priority 1 or 2 (P1, P2) incidents or related to a business requirement. In all cases, Emergency changes require an RFC. Whether an RFC should be raised pre or post implementation depends on the nature of the emergency. Action taken to restore service may be a definitive solution to the incident or a workaround to restore service. By definition a simple reboot is a workaround.

Business requirements arise when there is a request from the business or a process is triggered that demands immediate changes to IT infrastructure. For example, the universitys crisis managers ask that wireless access in a building be turned off as a response to a security threat. Urgent business needs not for immediate action will be processed as Expedited changes.

The RFC, before or after the fact must be submitted in a timely fashion. It will serve to maintain a clear chain of changes to the services in question. The Table below (next page) outlines the emergency conditions where an RFC is required before the work is done and when it can wait till after the service has been restored. Consult table 1 for guidance on how to evaluate the emergency situation and follow the general guideline described below.

Steps to observe:

For emergency conditions 2, 4, 5 and 6: Create an RFC that outlines the change along with why and how it will be made. Time permitting; include an analysis of the cause and long-term solutions as applicable. Best effort is expected within the constraints of the situation. If the service in question has an applicable predefined emergency change plan, you should follow it. If an RFC is submitted for an emergency change prior to implementation, you must contact the Change Manger to brief him on the emergency Operations has the contact information. He may approve the change directly or arrange for an ECAB consultation. He will inform you of the decision at the earliest moment.

Brief your supervisor on the situation. Escalate to the appropriate level for the incident. Inform your stakeholders use the method best suited to the circumstances (telephone, pager,

email, distribution lists) and should include an SSA. Make the change. Inform the appropriate stakeholders when completed close the SSA.



For emergency conditions 1 and 3: Create an RFC that outlines the change along with why and how it was made. Include an analysis of the cause and long-term solutions as applicable.

Response to Incidents and Emergency Business Requirements

Emergency Models (EM) P1 or P2 Incident or a business need

Action to be taken

RFC Approval Authority

1. Service Down Entire service is down or unusable for all users

Correct fault and/or reboot

Post Technical Team Manager

2. Service Partially Down Service is unavailable or unusable for some but not all users

Implement plan per RFC

Pre Change Manager, ECAB*

3. Cluster Node Down Server/node is down or unresponsive, impacting all users serviced by the affected server/node.

Correct fault and/or reboot

Post Technical Team Manager

4. Cluster Node Partially Down Server/node is down or unresponsive, but there is no perceivable impact on users

Implement plan per RFC


5. Business Requirement Implement plan per RFC


6. Predefined Emergency Model* Technical teams may be granted by the CAB the application of a specific set of actions for a service.

As specified in the procedure



Notes:

The reboot must not cause impact or degradation, even if only for the duration of the reboot, to any user not already affected. If it is expected to impact previously unaffected users, the approval authority escalates to the Change Manager.

* For known problems and recurring incidents the approval may be delegated to the technical team manager. The conditions for such approval are that the incident is recurring, the root cause is not known, the fix/reboot is predictable in its scope and duration and finally that there be a predefined maintenance window for the fix/reboot. In addition, technical teams may develop predefined change models for specific services so as to react to emergencies using standard predefined methods. The technical team must apply for permission from the CAB to use such specialized change models. Once approved, these become Delegated.

Emergency Changes Model Sub Processes:

Changes that involve security issues and/or confidentiality:

When changes are contemplated that expose a sensitive issue (security or confidentiality) the CAB should be consulted on the nature of the exposure. When tighter security is indicated, the CAB will be represented by the Change Manager. It is understood that on rare occasions security issues may necessitate the exclusion of CAB consultations prior to the change and related events.

In all circumstances an RFC must be submitted. RFCs relating to such issues, but do not in of themselves compromise security or confidentiality should be submitted prior to the change in the normal manner. These can easily omit sensitive information while preserving the core technical specifics of the change. One simple strategy is to omit the overall objective. For example, the RFC can describe the creation of a VLAN, but not mention that it is to be used to alter network traffic for streaming a high profile presentation on campus.

When an RFC is not issued prior to making the change, the RFC must be submitted after the fact. Information that is sensitive may be redacted to preserve confidentiality.



Unified view of Change Categories



Process Roles and Responsibilities Specific roles are necessary for the proper operation and management of the process. This section lists these roles and their responsibilities. Only one role is accountable for each process activity. This one role may assign one or more people who are responsible to carry out the task. It is ultimately the job of the person who is accountable to ensure that the job gets done.

Process Role Descriptions in Brief Change Requestor creates and submits the RFC for processing. The CR is responsible for content (facts and analysis) of the RFC. In McGills context the Requestor is usually, but not always, the Change Implementer.

Change Implementer is responsible for executing the change plan and for recording the results of the change implementation. In our context the Change Implementer is usually the Change requestor.

Change Owner is the Change requestors manager. The CO is accountable for the quality and effectiveness of the work done by the CR and the CI.

Service Owner is the de facto sponsor of the change. The SO may have initiated the change or may have approved of the initiative. In all cases the SOs permission is required to proceed with the submission of the RFC. The SO is consulted on the change plan and the content of the RFC before submission. Post submission the SO is informed as required about the RFCs execution, status and outcome.

Change Manager is responsible for verifying that the RFC conforms to the process guidelines. The CM will verify the risk/impact analysis. The CM may reject, require revisions, or approve the RFC.

Change Process Owner is accountable for the overall quality and effectiveness of the Change Management process. This includes The CPO supervises the work of the Change Manager.

Change Advisory Board assists the Change Manager in his role in appraising the completeness, validity and the risk/impact analysis for significant changes.

Charting definitions Responsible (The Doer)

The doer is the individual who actually does the task. The degree of responsibility is determined by the individual with the A.

Accountable: (The buck stops here) The individual accountable is the person who is ultimately answerable for the activity or decision.

Consult These are stakeholders or subject matter experts to be consulted before a final decision or action is taken. The communication is two-way and input from these individuals is required.

Inform These individuals are to be informed after a decision or action is taken. As a result of the action taken they may have to respond with an appropriate action. This is a one-way communication.



Legend Process Roles Acronym

Responsible,

Accountable

Consult before doing

Inform after decision taken

Change Requestor CR Change Implementer (may be same as CR) CI Change Owner (CRs supervisor) CO Service Owner (Sponsor) SO Change Manager CM Change Process Owner CPO Change Advisory Board CAB

Procedure CR CI CO SO CM CAB 1. Identify, assess need; response to incident or

problem A,R R

2. Build RFC a. Impact and risk assessment b. Testing c. Communications and stakeholder

engagement d. Post implementation verification checklist e. Back out plan a. Documentation

R A C

3. Check the validity and completeness of the RFC R A R

4. review impact and risk R A R

5. Approve/reject/return for revision C I I A R

6. Execute implementation plan C R A I,C

7. Cancel RFC C R A,C C I 8. Post implementation verification and acceptance C R A R I

9. Initiate back out C R A,C I I

10. Record implementation results I R A I I

11. Monitor change I R A I I

12. Record incidents I R A I I

13. Update RFC with monitoring status and results I R A I I

14. Post Implementation Review (PIR) C C C I R,A C

15. Document findings of PIR and set closure code I I I I R,A C

16. Close RFC (completed) R A I I I



ITSM Owner - CIO The CIO has overall authority and responsibility for the policies establishing governance of IT infrastructure and the services it delivers. The CIOs role is to build an IT Function that delivers value to the organization. The CIO ensures that IT is a strategic business partner in the organization and not just a provider of service. In the adoption and implementation of ITIL, the CIO ensures that ITIL informs and guides in the design, development and implementation of service management as an organizational capability and a strategic asset.

ITSM Executive Committee The ITSM Executive Committee oversees the design, development and implementation of IT governance infrastructure and policy. The committee is composed of the CIO, the IT unit directors and ITIL process owners.

ITSM executive Responsibilities: Set and oversee strategies for implementing ITIL at McGill. Provide the various process owners guidance and input from the respective units. Review reports from the process owners Advises the CIO on ITIL issues of development and implementation strategies.

Change Management Process Owner (CPO) The CPO is the owner and sponsor of the Change Management process. The CPO is responsible for the process design, documentation and outcomes. The CPO ensures the efficacy of the Change Process, its continual improvement and metrics. The CPO is responsible for ensuring that the Change management process is working well and ensuring that corrective action is taken when the process falters.

CPO Responsibilities: Establishes overall direction and communicates the organizations vision and the processs strategic

goals. Supervises the Change Manager (CM); sets goals and priorities to be followed by the CM. Seeks guidance from the Change Manager and various stakeholders on issues relating to the Change

Management Process. Act as a liaison between the Change Process structure and the directors and CIO.



ITIL Process Owner Responsibilities (Source: adapted from itsmcommunity.org, generic for all processes)

Ensuring that the Process and Governance Structure is fit-for-purpose Defining the Business Case for the process Ensuring there is optimal fit between people, process, technology (tool) and steering Ensuring proper Key Performance Indicators are set Ensuring quality reports are produced, distributed, and utilized Integrating the Process into the line organization. Taking a helicopter view, overseeing and ensuring integration between the specific Process and

other Service Management processes. Staying informed about developments of the business of Reuters Staying informed about new ICT and / or ITIL developments

Activities Analyze and distribute reports Review proposed changes to the Process and Governance structure Initiate improvements in the tool, process, steering mechanisms, and people Review integration issues between the various processes Communicate changes to the Process and Governance Structure Promote the Service Management vision to board level / Senior Management Function as a point of

escalation when required Approve and initiate training when required Recruit and coach staff to support the Process where needed Schedule and attend meetings according to the Process and Governance Structure

Authority Has the authority to approve proposed changes to the Process and Governance Structure Cannot enforce the use of the Process, but can escalate any breaches to board level management Can organize training for IT employees and can nominate staff, he/she cannot oblige any staff to

follow training, but can escalate to line management should training be required Will negotiate with the relevant Process Owner if there is a conflict between processes Has the authority over Process staff where process activities are concerned Can initiate research into changing tooling, however, the tool owner is responsible for the tool and

will have the final say Will negotiate with the relevant Process Owner if there is a conflict between processes



Change Management Process Steering Committee Provide leadership for the Change Management Process. Ensure that the vision and mission of the Process are fulfilled. Act as a reference group for the Change Manager and the Change Process Owner on various issues as they may arise. Determine ways to address emerging requirements and other issues identified by the ITSM Executive Steering Committee, and report back for strategic direction. (Source: McGill Its Change Management Steering Committee)

Steering Committee Responsibilities: Represent the views of their respective IT units. Deliberate on issues and provide guidance. Assist in creating and refining process rules. Establish and maintain CAB by-laws. Attend regular meetings and be well prepared for discussion on agenda items. Report to their management and colleagues the activities of the committee and to seek their

counsel so as to provide the Committee with the viewpoint of their respective IT units.

Change Process Manager The Change Manager (CM) oversees and manages the change process and ensures that only authorized changes are implemented. The CM is responsible for verifying that the RFC conforms to the process guidelines

Change Managers Responsibilities Is responsible for monitoring compliance with the Change Process and resolving day to day change

issues. Approves changes. Ensures that all changes are reviewed and all changes meet basic requirements before approval Important Changes, he will refer the authorization of Changes to the Change Advisory Board. Will recommend, in consultation with the CAB, process changes to the Process Owner and the CMP-

SC. Chairs the Change Management Process Steering Committee (CMP-SC) and the Change Advisory

Board (CAB. Convenes and chairs regular weekly CAB meetings and when appropriate the ECAB. Chairs the

monthly CMP-SC. The CM is responsible for the composition of each CAB consultation. The CM ensures that each CAB

or ECAB has essential subject matter experts and stakeholders to properly process the RFCs at hand. Maintains an online site for Change Management documentation and resources. Plans agendas for the CAB and the CMP-SC. Produces and publishes agendas and meeting minutes. Conducts Post Implementation Reviews (PIR) of changes with a focus on changes that have caused

incidents or had reported difficulties in implementation. Participates in other ITSM process initiatives. Produce Monthly reports.



Change Advisory Board (CAB) The mission of the CAB is to review and prioritize requests for change, keep track of the change management process, and provide feedback to the Change Manager. The CAB gives the Change Manager the support necessary to help make the best decisions for proposed changes to the universitys IT infrastructure. The CAB makes recommendations for approval, further analysis, deferment, or cancellation of RFCs. The CAB will also make sure that all the stakeholders (including non-IT business units) are aware of proposed changes and have provided their input.

The CAB is composed of a representative cross-section of IT as well as other stakeholders. The Change Manager may invite individuals who either are subject matter experts or have a major stake in the changes appearing on the agenda. This ensures that any disruption is minimized and well planned to reduce the impact on users.

CAB attendance is not compulsory. However, to ensure the completeness and confidence levels of the discussion and decisions taken by the CAB, key areas of responsibility and/or expertise must be represented at all CAB meetings. The following groups should arrange to have at least one representative at Each CAB.

Networking Windows support Enterprise systems ISR database administration ISR applications ISR Business production Information security Service desk CCS

CAB Members Responsibilities

CAB Members must:

Attend regular CAB meetings. In their absence a suitable representative of their respective unit should attend.

Reflect the views of the unit or group they represent. Members must keep their respective unit or group informed on change management issues.

Prepare for the CAB meeting by reading meeting materials in advance of the meeting. Participate in the discussion so as to provide subject matter expertise, relevant observations of

caution and to arrive at a decision on the approval of the RFCs under review. Reply to email or other electronic forms of consultation on Expedited change requests with

observations, criticisms, and suggestions for improvement of the RFC build, approval or rejection of the RFC under consideration.



CAB members, as a shared responsibility with the Change Manager, must:

Ensure that service owner has agreed to the change Ensure that the RFC has the required information:

o The change is described and a valid case is made for implementation. o A well planned method for implementation o A suitable blackout plan. o The Risk and impact analysis is provided o A communications plan has been provided that alerts all stakeholders (technical and

user communities) of potential impact to services. The appropriate management approval has been obtained.

Emergency Change Advisory Board (ECAB) For urgent changes there may not be enough time to convene the CAB for processing an RFC. In fact, a completed RFC may not be possible with the timeframe of the urgently required change. The ECAB is a smaller organization authorized to make emergency decisions. The ECAB is a subset of the CAB. The ECAB members duties and responsibilities are identical to the regular CAB. The ECAB members must be prepared to be available after hours as emergencies arise. The ECAB consultations will take place electronically. The CM will ensure that the appropriate ECAB members (as subject matter experts) are included in the discussion. The CM, when required, may include other subject matter experts who may not be part of the CAB. The CM, in cases of major impact, may also require escalation to the appropriate authority for consultation.

Change Owner The Change Owner (CO) is the individual who is responsible for the service or infrastructure to which the change will be applied. In practice the change owner is a line manager of a technical group tasked with the administration and maintenance of some aspect of the IT infrastructure.

Change Owners Responsibilities The change Owner is:

Accountable to the Change Manager for carry out changes as defined in the McGill IT Change Management Procedures Guide.

Ensures the Change Management process is followed for building, testing and implementing the change.

Responsible for all issues and inquiries for the changes under his management. Accountable for the successful implementation of the change. Ensures active involvement of appropriate technical groups and other stakeholders during

planning. Manages the resources used to build, test and implement changes, working with other technical

teams when required. Provides additional information regarding the change when requested by the Change Manager. Participates in the Post Implementation Review process. Performs the initial impact and risk assessment of the change, to assist the applicable change

authority in accepting and classifying the change.



Service Owner The Service Owner (SO) is the de facto sponsor of the change. The SO may have initiated the change or may have approved of the initiative. In all cases the SOs permission is required to proceed with the submission of the RFC. The SO is consulted on the change plan and the content of the RFC before submission. Post submission the SO is informed as required about the RFCs execution, status and outcome.

The Services Owners Responsibilities The Service owner:

Provides the Change Owner clear expectations of the outcome of the change. Provides guidance on the proposed schedule for the change. Communicates with his customer base the effect of the change and any planned disruption to

service and the potential risk of unplanned disruptions. When required, provides the Change Manager and the CAB with information to assist in

appraising the impact of the change and its scheduled time of implementation.

Change Requestor The Change Requestor follows the Change management Process for submitting an RFC under the supervision of the Change Owner. The Change requestor is responsible for the accuracy of the information and the appropriate detail to allow the Change Manager and the CAB to assess and process the RFC.

The Change Requestors Responsibilities The Change Requester provides:

A clear description and a valid case for implementation. A well planned method for implementing the change A suitable blackout plan. A risk and impact analysis of the change. A communications plan that provides alerts to all stakeholders of potential impact to services. Completed documentation required for the change. Participation in meetings concerning the change. The CR may call and conduct such meetings to

advance the accuracy of the RFC. Develop a test plan to demonstrate the quality and utility of the change. With the Change Owner and Change Implementer present the RFC to the CAB Updates the RFC as required and requested.



Change Implementer The Change Implementer follows the Change management Process for submitting an RFC under the supervision of the Change Owner. The Change implementer will follow the plan as outlined in the RFC that was built by the Change Owner and the Change Requestor.

Change Implementer Responsibilities The Change Implementer:

Responsible for implementing the approved change as outlined by the approved implementation, testing and back out plans.

Communicates with stakeholders and colleagues to ensure that the change is on time and any cross unit support is available as planned.

Participates in planning for the change. Participates in risk and impact assessment. Participates in building the RFC and testing the change. Participates in post-implementation testing, change validation and back out activities Following Implementation, Updates Change Record and sets Status accordingly Provides updates on the status of the change to Change Owner, the Change Manager and the

CAB as required.



Creating and Modifying Change Task Lists When creating and RFC for submission, the requestor must select from a list of tasks that have been added and vetted by his unit or team. The Change tasks list have been analyzed and categorized based on risk and impact that the task may have on services.

Change Categories and Impact Levels A change refers to addition, modification or removal of anything that could have an effect on IT services.

Changes that do not conform to a change task can only be implemented after the change task has been added or with the approval of the Change Manager, the CAB or the units director as necessary.

Change tasks are added by Motion support staff upon request from the designated CAB representatives of the units.

All hardware and software components (referred to as Configuration Items or CIs) to be modified must be catalogued in the Change Management Database (CMDB). These can be entered by NCS Operations staff upon request.

IT Units Role and Responsibilities: Each IT unit is responsible for creating change tasks and assigning them an appropriate impact

level for their respective staff to use. This serves to establish the standards for implementing change.

The units senior staff will do the risk analysis of the change category that is based on the probability that the change could fail either during implementation or post implementation.

The unit will have done an impact assessment on the effect of the change in both how it changes service if successfully implemented and the damage it may cause should it fail. The analysis should include who is affected, how, how many users, the length and complexity of a back out, and the costs associated. See attached Risk and Impact section.

Requestors (RFC Submission) Role and Responsibilities: The requestor must select from NCS Motion a category that best fits his or her change.

Choosing lesser categories to avoid scrutiny or effort is forbidden. The requestor will have done the analysis for the change in question to ensure that it fits the

general criteria. When necessary, given special circumstances, the requestor will set the impact at a level higher than the categorys predefined impact. The requestor cannot arbitrarily lower the impact level. This is to ensure adherence to the standards set by his respective unit. Exceptions can be made with the approval of the Change Manager, the CAB or the units director as necessary.



Changing and Reappraising the Impact of Change Tasks As changes are attempted, the appraised risk and impact become clearer and may require adjustment.

Unit(s) can request changes to their own task list as they see fit. The same criteria for creating a new change task are applicable.

Other unit(s) may ask the CAB to reassess a change task outside their purview. The CAB will discuss the proposed change and make a decision through consensus. Should the CAB not reach a consensus or the decision is challenged by the owner unit, the matter will be resolved at the directors level.



Change Categories and RFC Processing

Start Create/editTask list

Task list use and maintenance

Continue with RFC submission End

Confer with unit managers, the

CM and the CAB as required

Select Task that best fits the

change

Yes

NO

Task has correct impact

level?

Task matches work

described?

Found it?

YesNO

NO

Yes

Each Unit must create a list of Change Tasks and tag each with

one of four impact change categories.

The CM or the CAB may challenge the Task chosen as not matching

the work described.

Further analysis of the change may indicate that the Task chosen

is not at the correct impact category. A new Task or an

update of the current Task is required.

Abbreviated view of the RFC

submission process



Lead Times for RFC Processing In order to allow due diligence in the consideration and processing of all RFCs, there are rules for lead times. Lead times refer to the time spanning the submission of an RFC and the proposed scheduled time of implementation. For significant and major changes the RFC must be submitted at least 24 hours before the CAB meeting. For Major changes it is highly recommended that the submission for CAB approval occur several days in advance of the CAB meeting at which the RFC is to be considered.

These time lines are intended to provide the Change Manager ample time to consult the forward schedule, for stakeholders to react to the RFC and for any preparation that other teams may need to make to support the successful implementation of the change plan this is especially important for announcements and service desk preparedness. Upon the discretion of the Change Manager and, where applicable, the CAB, lead times may be extended or reduced to best reflect the impact and risk of the RFC.

Should there be a late submission for CAB; the requestor will have to get his unit director to ask for derogation. The RFC would then be added to the agenda for that weeks CAB. Should the CAB have been cancelled before the request for derogation, a decision would be made to either process the RFC as an exception or delay to the next CAB.

Impact Level Minimum Lead Time Required

Approval Authority Before Approval Between Approval and

Implementation

Delegated None None Self

Minor hour1 & 2 None CM

Significant 1 day, at or before 10:00 Wednesday

2 days4 CAB

Major 1 day, at or before 10:00 Wednesday

3 days5 CAB

Expedited Significant and Major changes5

At or before 2:00 PM6 2 days7 CAB

Emergency changes8 Best effort9 Best effort9 ECAB



Notes: Days refers to business days. The regular CAB meeting is every Wednesday at 10:00 AM. The CAB may withhold approval of an RFC if it does not provide appropriate lead times. It may

require more than the stated minimum. The CAB may approve shorter lead times than the stated minimums when required by

extenuating circumstances and the shorter lead times do not jeopardize the safe implementation of the change. This is greatly mitigated by a negotiated agreement between the requestor and the appropriate stakeholders.

Each IT unit notifies their direct customers. Typically, IT technical units customers are not end-users but rather other IT support personnel.

The responsibility for announcing changes and service interruptions to end-users falls on ICS.

Footnotes: [1] Minor changes for same day or overnight. These must be submitted before 5:00 PM to be considered for same day, that evening or overnight (before 9:00 AM). When submitted after 5:00 PM, these Minor RFCs can only be implemented the next morning at start of business (9:00 AM).

[2] Minor changes for overnight or next day that require ICS or Operations intervention. The alert or request must be made at least 3 business hours before the scheduled implementation time.

[4] Scheduling constraints may require shorter lead times for significant changes. This should be with the consent of the stakeholders and must be approved by the CAB. In such cases every effort should be made to communicate relevant details to stakeholders and especially ICS as early as possible to compensate for a lead time shorter than two days.

[5] Major changes require planning and early communication to ensure success. Part of that success is mitigating service disruptions and allowing users to make alternative plans well in advance of the change. Whenever possible the lead times should be far greater than the minimum three days.

[6] Urgent, Significant and Major Changes may be required before the next CAB meeting. Scheduling constraints, mandated upgrades by vendors, or other remediation may not fit the weekly CAB schedule. These will be dealt with by an email consultation with CAB members.

[7] For Expedited Significant and Major Changes the CAB still requires at least three hours for the email consultation. ICS and Operations will require a minimum of two days lead time more is better.

[8] Emergency changes are a response to a service that is down, operating at greatly reduced efficiency or will fail within a very short period. The change to be made is urgent remediation and does not require normal lead times. See Section on Emergency Change Models.

[9] Best effort must be applied to informing the stakeholders of the problem and the proposed remedy. See Section on Emergency Change Models.



View of Timelines for Significant and Major RFCs The CAB has a standing meeting every Wednesday at 10:00 AM. The cycle starts Tuesday at 10:00 AM with the 24 hour minimum lead time between submission and processing by the CAB. Significant changes must have a minimum of two business days post approval lead time to implementation. Major changes must have a minimum of three business days post approval lead time to implementation. This is the timeline for the shortest processing, approval and implementation for Significant and Major changes. It is desirable and encouraged to have RFCs for CAB approval submitted as early as possible ahead of the submission deadline and to be scheduled for implementation more than three business days after the CAB meeting at which the RFC is processed. This would afford time for all concerned to perform their tasks with deliberate care.

Figure 4 illustrates the CAB approval cycle for Significant and Major changes based on an arbitrary week. The cycle begins on deadline Tuesday (marked with a flag). Should the RFC be approved on CAB Wednesday, Significant changes can be scheduled for implementation no earlier than 10:00 AM the Friday of that week. Major changes cannot be scheduled any earlier than the following Monday at 10:00 AM. Either Significant or Major changes can be scheduled well past these minimum milestones as is indicated by the arrows.

Figure 2



Process Metrics Change management metrics provide indicators of the processs effectiveness and efficiency. These are divided into three general categories disposition (status), lifecycle (tracking time spent in the process) and outcome (results and effects of the implementation). These metrics will be automatically collected by IT Services Motion. There will be a monthly report generated based on these numbers.

KPI Disposition

Disposition Metrics The disposition refers to the various states and characteristics of the RFC. This set of KPIs describes the outcome of the implementation of the change plan. It will help to identify areas improvement in how RFCs are planned as executed.

Metrics for disposition Description

# Submitted by impact category Report the number of RFCs submitted for all change types Delegated, Minor, Significant, Major, Emergency and Expedited. This basic metric is the foundation for other KPIs.

% Approved Most RFCs will be approved. The contrasting items to this metric are the rate of rejection or cancellation.

% Rejected Though rare, some RFCs will be rejected because they either fail to meet process guidelines or conflict with other work.

% Canceled Reason for the cancellation must be provided. Possible reasons for cancelling are that:

The case for making the change is no longer valid The state of the software /hardware has change and the

plan is no longer viable in its current form New information requires a redesign of the plan Resources were not available (staff or hardware) to safely

complete the change Scheduling conflict with another RFC

% Implemented with no Problems

The RFC was executed as planned and results of the implementation were as expected. The contrasting metrics to this are RFCs Implemented with Incident and RFCs implemented with Exception.



Metrics for disposition Description

% Implemented with Incident The change caused one or more P1 or P2 incidents. These may be recorded and attributed to the change long after the implementation. The incident ticket number must be entered when and as it is available to the implementer. The RFC may be re-opened to attach this information, should the incident occur after initial close.

Backed out The change was backed out. May have had to restore software and data.

% Implemented with Exception The implementation was carried out with difficulty or not completed as planned

a) Deviated from plan The RFC plan was not followed- e.g. steps omitted, added or taken out of order.

b) Did not achieve objectives

The intended purpose for the change was not met did not have the expected results.

c) Partially implemented One or more aspects of the change were not implemented may or may not have resulted in executing the backout plan.

d) Exceeded Implementation Window

The change took place outside the requested time window. The change Started early or late or the plan exceeded the implementation window requested.

e) Exceeded expected Service Disruption Window

The change caused disruption to service in excess of the state durations in the RFC plan. In addition, any component that is rendered unavailable and was not scheduled to be, constitutes an incident. These must be reported as Heat tickets.



KPI Lifecycle All RFCs are submitted and exist through various states until they are closed. This set of metrics tracks the duration of the RFCs speed or delays during processing. These will help to identify the efficacy of the process are we going too fast or too slow for each change type. For example, is there a correlation between the lifecycle length of Major changes and the rate of incidents and issues that arise from their implementation? These metrics can be used to identify problems with teams or areas of activity.

Metrics for Lifecycle Description

CSI Opportunity

Avg. time submission to approval

This is the time from the submission of the RFC till the time it is approved by the CM (with or with the CAB).

Identify bottlenecks in the approval process or lack of due process (too fast). Either poses risk to IT services.

Avg. time approval to scheduled time

This is the time from approval of the RFC to its scheduled time.

Identifies inadequate delay between the approval process and the implementation. This can compromise preparedness and proper communications among technical teams and stakeholders. This can be compared to timelines established via baseline or policy.

Avg. Time scheduled to close out

This is the time between the scheduled time and the RFCs close out.

Identifies inadequate attention to monitoring and RFC record updates when done too quickly. When prolonged it may cause loss of relevant information events and conditions can be forgotten.

Avg. Total time Submission to close

Total lifecycle of the RFC. This is an indicator of process efficiency. Delegated changes should have a short lifecycle in the process while Major changes should have long cycles in the process. Aberrations or trends away from the norm (established McGill IT baseline) can be discovered via these metrics.



SSA System Status Alerts All changes that disrupt service, in whole or in part should have a System Status Alert (SSA) issued. The SSA serves to inform other IT colleagues of the status of services for both planned and unplanned disruptions.



Notes for SSAs for RFCs: The SSA should be issued at least three hours before the scheduled service interruption no

later than 2:00 PM for same day, same night or before the next business day. The title and the description of the SSA item should be identifiably similar if not identical to

the RFC that corresponds to the item. The SSA must reference the RFC for which it is issued.



Appendix A: Creating an RFC Use the link https://itservicemotion.campus.mcgill.ca to begin a session with NCS Motion and follow the instructions provided to create an RFC. By hovering (dont click) the mouse over RFC tab, as shown

in the illustration below, you can select Create RFC from the list.

Once you have selected Create RFC, you will be ready to select the change task appropriate for your RFC. IT Services Motion will remember the unit and team that you belong to and will display the task list for your team. Should the list displayed not be your teams list you may change it by using the pull down list that appears at the right top corner of the task list menu.

Once the correct team name appears in the window the change task menu for your team will be displayed on the page.

Select the The category chosen must match the change you intend. If it does not appear on the list or you have questions about which to choose, you should consult with your manager and colleagues or the Change Manager. New categories or subcategories can be added as required. Below is sample menu of the main categories from which you choose. The RFC submission is a multi-step process from start to finish.



Select the Change Task for the RFC: In our example will select Wireless by clicking on > to expand the items in that sub menu of Wireless tasks. We now select Wireless: Firmware upgrade (Major Release) Highlight by the red box.



Select the CI(s) for the change Select the CIs that you will be changing. Please choose carefully so that the RFC reflects a true record of the work to be approved. If the CI is not in the CMDB, it will not be listed in the menu structure depicted. NCS Operations and the NCS SII groups can add configuration items. When in doubt, consult with the CM.



Step2: Identification This screen provides basic information about your RFC. Selected fields are discussed below.

Figure 3 RFC Start

RFC Title: The RFC title should describe the change meaningfully. Include the name of the item to be changed and any version numbers that are relevant. For example patch a wireless controller is totally inadequate. An appropriate title is the following: Patch update v3.3.1.29 for wireless-local31-wmc (M3 wireless controller)

mcgill it services change management process guide

Documents

normal change

change categories

change management overview

emergency change models

change management process

approval process

standard changes

examples of changes