McGill IT Services Change Management Process Guide

January 7, 2015 Version 4.0 Page 1

McGill

IT Services

Change Management Process Guide

Version 4.0

Frank Pettinicchio

January 7, 2015


McGill IT Services Change Management Process Guide


Table of Contents

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

Change Management Principles ................................................................................................................... 7

Change Triggers......................................................................................................................................... 7

Change authority ...................................................................................................................................... 8

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

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

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

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

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

Change Categories ...................................................................................................................................... 14

Emergency Change.................................................................................................................................. 14

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

Normal Change ....................................................................................................................................... 14

Change Categories and Impact Levels ........................................................................................................ 15

Change Models and Work Flows ............................................................................................................ 15

Change Management Process Flow ........................................................................................................ 17

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

Examples of changes ............................................................................................................................... 19

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

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

Emergency Change Models ......................................................................................................................... 22

Emergency Changes Model Sub Processes: ............................................................................................ 25

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

Changes initiated or required by a third party: .......................................................................................... 26

Expedited Changes: ..................................................................................................................................... 27

Reason Codes for Expedited Changes ......................................................................................................... 27

Unified view of Change Categories ......................................................................................................... 29

Process Roles and Responsibilities ............................................................................................................. 30

Process Role Descriptions in Brief ........................................................................................................... 30



Charting definitions ................................................................................................................................. 30

ITSM Owner - CIO .................................................................................................................................... 33

ITSM Executive Committee ..................................................................................................................... 33

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

ITSM Working Committee ....................................................................................................................... 35

Change Process Manager ........................................................................................................................ 35

Change Advisory Board (CAB) ................................................................................................................. 36

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

Change Owner ........................................................................................................................................ 38

Service Manager ..................................................................................................................................... 38

Change Requestor ................................................................................................................................... 39

Change Implementer .............................................................................................................................. 39

Creating and Modifying Change Task Lists ................................................................................................. 41

Change Categories and Impact Levels .................................................................................................... 41

IT Units’ Role and Responsibilities: ......................................................................................................... 41

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

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

Change Categories and RFC Processing .................................................................................................. 43

Lead Times for RFC Processing .................................................................................................................... 44

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

Process Metrics ........................................................................................................................................... 48

Disposition Metrics ................................................................................................................................. 48

KPI Lifecycle............................................................................................................................................. 50

SSA – System Status Alerts .......................................................................................................................... 51

Notes for SSAs for RFCs: .......................................................................................................................... 52

Appendix A: Creating an RFC ...................................................................................................................... 53

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

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

Step2: Identification ................................................................................................................................ 56

RFC Title: ............................................................................................................................................. 56

Priority:................................................................................................................................................ 57

Risk: ..................................................................................................................................................... 57



Impact: ................................................................................................................................................ 57

Approved by manager:........................................................................................................................ 57

Approved by owner: ........................................................................................................................... 57

Implementation duration: .................................................................................................................. 57

Back out duration: ............................................................................................................................... 57

Service Disruption: .............................................................................................................................. 57

Description of change: ........................................................................................................................ 58

Who will be affected: .......................................................................................................................... 59

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

Test plan and test results: ................................................................................................................... 61

Risk analysis: ....................................................................................................................................... 62

Alternate solutions considered: .......................................................................................................... 63

Back out plan: ..................................................................................................................................... 64

Communication plan: .......................................................................................................................... 65

Budgetary impact: ............................................................................................................................... 66

Verification checklist: .......................................................................................................................... 67

Appendix B: Closing an RFC ......................................................................................................................... 68

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

Implemented with no problems ............................................................................................................. 69

Cancelled ................................................................................................................................................. 69

Implemented with incident .................................................................................................................... 69

Backed out .............................................................................................................................................. 69

Implemented with Exception .................................................................................................................. 69

Final RFC Closure Status .......................................................................................................................... 70

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

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 (don’t click) the mouse over My Stuff tab, as

shown (below) and select either My Open RFCs or My group open RFCs. ............................................ 72

Appendix C: Risk Assessment ...................................................................................................................... 73

High risk............................................................................................................................................... 73

Moderate risk ...................................................................................................................................... 73

Low risk ............................................................................................................................................... 73



No risk ................................................................................................................................................. 73

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

Risk and Impact ....................................................................................................................................... 75

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

Appendix E: CAB and ECAB Membership by Role ....................................................................................... 80

Appendix F: Document Changes ................................................................................................................. 81


Change Management Principles

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® 2011 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 Triggers

Strategic changes originating from Service Strategy and Business Relationship Management are proactive. Changes to a service come from Service Design, Continual Service Improvement and the Service Level Management process. These are mainly proactive changes. Corrective changes are reactive and are needed to resolve defects and errors detected in services. These primarily emerge from Service Operations.



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

Services are managed across the lifecycle. The approval authority to proceed with a change - based on

type, size, impact and risk -

resides at different levels

of the Change

Authorization hierarchy.

For the sake of brevity

each level is described in

concise terms. Each level

may have more

granularity and is detailed

in the various documents

describing McGill IT

infrastructure and

procedures. The figure to

the left encapsulates the

current levels of change

authority existing in

McGill IT. This document

will mainly address level 3

to level 6.

The change management

process is an integral part

of all functional layers of

IT governance at McGill.

These layers include the

PMO, Enterprise

Architecture and Portfolio

Management and are

represented in level 1 and

Level 2 of the hierarchy illustrated here. Their activities support and oversee the creation of

opportunity analyses and documents needed to make strategic decisions and inform the design of

current and future services.

Communication flows in both directions. Decisions taken at higher levels are communicated to lower

levels. When levels of impact, cost and risk are detected and deemed more appropriate for a higher

level of decision making, the decision will be escalated to the higher level.

University VPs, planning office

High cost/risk/impact to business- Requires

decision from university executives

to initiate project

CIO, IT directorsSignificant cost and

risk affecting services(internal IT projects)

CAB or ECAB

New or changed services characterized

by high impact and risk – (Major and

Significant changes)

Change manger

Low to medium impact and risk

changes(Minor changes)

Technical Teams(operational and administrative IT

staff)

Pre-approved low impact and low risk

Minor changes(Delegated changes)

Local authorization Standard changes

Change authority

Level of Impact/risk/cost

CommunicationsDecisions

And actions

Communications,Escalations for RFCs,Risks, impact, issues

Change Authorization Hierarchy

Level 1

Level 2

Level 3

Level 4

Level 5

Level 6

University VPs, planning office

High cost/risk/impact to business- Requires

decision from university executives

to initiate project



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 (see Delegated changes).

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

6. For major and significant projects, upon the approval of the project charter, the project managers and sponsors should present an RFC for their project to CAB. Such RFCs serve to alert and inform the CAB of the project and its general areas of activity (changes to services or new services) and establishes the parent RFC for child RFCs that will be submitted to realize the project. Approval in this instance is not the approval of the project but an acknowledgement that the project is in progress and has obtained the required authority to proceed. See the section Change Authority. In addition, the CAB will provide feedback on the project’s plans for changes – methodology, content and scheduling. Project managers may return to the CAB to report on issues affecting the planned changes and scheduling.

7. 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 the task to the status of a Minor change. These should be developed whenever possible in the change management process - reduces red-tape, increases efficiency

8. “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 (ECAB).

9. Inputs to the Change Management process:

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

10. 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 pre-approved Minor changes.

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 CM’s 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 requestor’s or the CM’s initiative, the CM may schedule a CAB or ECAB 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 CAB’s objections. The same rules apply for approval or rejection as stated in item 6.

RFCs

1. RFCs and their content are the responsibility of the line manager. The requestor and his or her manager (the Change Owner is accountable and extends to the Unit Director) are responsible for the accuracy of the facts contained and any provided analysis derived from those facts (e.g., risk). 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 for ensuring communications standards for portions directed at users or other segments of the McGill community. ICS is also responsible for executing such public announcements.

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, plan around the work or respond to incidents caused by the change.

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. However, RFC have priority and will be processed before any other new business.

7. The minutes of the previous meeting are sent out with the new agenda. 8. The agendas and minutes are published on the McGill IT internal file sharing facility (see below). 9. The Change Manager will invite the Change Requester to attend the CAB meeting and present a

summary of the RFC. However, the presentation can be led by any of the roles associated with



the Change Request. These include the Change Owner, Change Implementer, Service Manager,

Solution Architect, Project Manager or any individual well placed to provide an authoritative

brief on the requested change. The RFC presenter, as identified by the technical team, should

ensure that the appropriate subject matter experts are in attendance or otherwise made

available. The Service Manager (SM) – the person responsible for the service, or a suitable

delegate, must also attend to ensure that the SM is committed to and supports the change as

submitted. Missing or Incomplete information, may delay approval or, in the extreme case,

invite rejection of the RFC as presented. The important consideration is that the presentation

provides context and sufficient information to allow the CAB to determine that the risks and

impact have been identified and optimally mitigated, that the testing is satisfactorily completed,

the verification plan is appropriate to the scope of the change, that the stakeholders have been

advised, and that the back out has been planned and tested. The CAB members may ask for

more specific detail about the RFC or pose questions to clarify any ambiguity.

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 CenterStage 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 or changes

to 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

https://agora.mcgill.ca/cio/itsm/cm



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 ® 2011 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 can’t 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 Items or CIs. A CI is (ITILv2011): [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 the Lifecycle of all CIs 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.

http://www.knowledgetransfer.net/dictionary/ITIL/en/Service_Transition.htm

http://www.knowledgetransfer.net/dictionary/ITIL/en/Component.htm

http://www.knowledgetransfer.net/dictionary/ITIL/en/IT_Service.htm

http://www.knowledgetransfer.net/dictionary/ITIL/en/CI.htm

http://www.knowledgetransfer.net/dictionary/ITIL/en/Configuration_Record.htm

http://www.knowledgetransfer.net/dictionary/ITIL/en/Configuration_Management_System.htm

http://www.knowledgetransfer.net/dictionary/ITIL/en/Lifecycle.htm

http://www.knowledgetransfer.net/dictionary/ITIL/en/Configuration_Management.htm


http://www.knowledgetransfer.net/dictionary/ITIL/en/Change_Management.htm


http://www.knowledgetransfer.net/dictionary/ITIL/en/IT_Service.htm

http://www.knowledgetransfer.net/dictionary/ITIL/en/Process.htm

http://www.knowledgetransfer.net/dictionary/ITIL/en/SLA.htm



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 IT units have provided for their respective unit.

The tasks are applied against a service and have been analyzed by the unit’s 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, who is responsible and accountable for the

work),

timelines (time needed to deal with a change at its various stages),

thresholds (e.g. can’t 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.

mailto:[email protected]




Change Management Process Flow

Change Management Process

Se

rvic

e O

wn

er

Ch

an

ge

Ow

ne

rC

AB

/EC

AB

Ch

an

ge

Imp

lem

en

ter

Ch

an

ge

Re

qu

esto

rC

ha

ng

e

Ma

na

ge

r

RFC Build RFC approval process RFC implementation RFC Close

Significant or

Major Change

Needs revision

Normal Change: CM

Intervention required

Approved

Rejected

Apply conditions &

required edits by CAB

Validated

Yes

No

Errors detected by CM

or other stakeholder

Minor

Change

Normal Change

Failed: Withdraw/Cancel

Identify, assess

need; response to

incident or problem

Change

Model?

Accept RFC:

Analysis of RFC

for compliance

Implementer's

Close:

update status &

results

Delegated Change

Submit RFCRFC Build and

testing

Formal

Review?

Delegated Change

Emergency

Change

Maintenance

Change

Model?

Normal

Change Testing,

scheduling,

OK?

Provide support,

consultation and

advice throughout

the lifecycle of the

change

Assess and

evaluate

CM Consults CAB

Process RFC

Post-

Implementation

Review

CM close

Analysis,

Stakeholder

agreement, sign to

staff

Implement and

validate change:




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. Risk of a problem occurring 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 the 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

Scheduled to avoid other Major or Significant changes or activities.

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 (documentation, training, support)

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

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

permanent 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 university’s 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 (discussed in a later section).

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.

does or not include all major components of the service



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

Pre Change Manager,

ECAB*

5. Business Requirement Implement plan per RFC

Pre Change Manager,

ECAB*

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:

Emergency Change Process

Cha

ng

e O

wn

er

Cha

ng

e I

mp

lem

en

ter

Cha

ng

e R

eq

ue

sto

rC

M/E

CA

B

RFC Build RFC approval process RFC implementation RFC Close

No

YES

Rejected

Validated

YesCM Close

No

Make changes as required by CM/ECAB

No

Yes EM5

No

Partially Down EM2 or EM4

Yes

No

Analysis

Completely Down EM1 or EM3

Yes EM6

No

Yes

No

Yes

Analysis, and

determine the Emergency model

Predefined Procedure?

Issue SSA

Business Requirement?

Predefined Procedure?

Service/Node Down?

P1:P2

Working?

RFC Build:Analysis and plan;Stakeholder buy-in

Best effort to provide testing

Submit RFC

Assess and evaluate RFC

Implement and validate change

Provide support, consultation and

advice throughout the lifecycle of the

change

Back out if necessary

Post-Implementation

Review

Create and Submit

RFCRFC

exists?

Requires formal review?

Revision required?

ChangeModel?

Approved? Normal Change

Implementer's

Close:

update status & results


Changes that involve security issues and/or confidentiality:

When changes are contemplated that expose a sensitive issue (security or confidentiality) the

change manager should be consulted on the nature of the exposure. It is understood that such

occasions may necessitate the exclusion of some details from the RFC that would compromise

security. The RFC becomes the official change record and is used to maintain the chain of associated

change activities. This information serves to inform the actions taken during incident and problem

management activities. The RFC record should contain full documentation on what, how and why it

was done. It should also detail the outcome of the change.

Common sense dictates that while it is in our best interests to be as complete as possible, certain information should not be included directly in the RFC itself. There are potential risks associated with such inclusion that could have financial, legal, or security impact. However, the information will be logged and detailed in a secure location maintained by Information Security. This will allow for a complete analysis to resolve incidents and problems.

For example, some items that could be sensitive and therefore omitted from the RFC are:

Passwords

License keys

Special “files” (i.e. Keys, certificates,)

Changes initiated or required by a third party:

McGill University manages the McGill IT infrastructure by established standards and

processes. Vendors, contractors and consultants (referred to as “external agents” for this

discussion) must adhere to these practices. Changes made to the McGill IT production

infrastructure by External Agents may include, but is not limited to; work done as part of a project,

pilot, deployment, proof of concept, contracted regular maintenance, or remediation for a fault or

defect. Work that affects the McGill IT infrastructure baseline directly or by interaction must be in

full conformity with McGill’s Change Management Procedures Guide.

Before work, as listed above, can be undertaken, an RFC (Request for Change) must be submitted to

the McGill IT Change manager. In order to maintain standards, all RFCs must be submitted by proxy

through the McGill IT group with whom the External Agent is engaged. The work cannot begin until

approval is granted by the change authority. Urgent changes, as a response to emergency

prevention of a service disruption or to restore services after an unplanned outage, are

exempt. However, such changes are done in consultation with and with the full permission of the

McGill IT staff responsible for the affected service.



Expedited Changes: For technical or business reasons, IT needs to have the flexibility to implement changes that are time sensitive and cannot respect the normal lead times. Two change models exist for urgent changes:

Emergency: Changes that are required to restore service due to an incident or required to be implemented in order to avoid one that is imminently unfolding.

Expedited: Changes that are required quickly due to a pressing need such as a legal requirement, or business need, but are not related to restoring service.

Normal changes (Major, Significant and Minor) may qualify to be processed as Expedited changes, that

is, processed outside the normal lead times (see Lead times for RFC Processing for more details.) The

ECAB or the CAB (at the discretion of the Change Manger) will be consulted via email or when

scheduling permits at the CAB meeting. Approval or rejection will be decided at the conclusion of the

consultation. Expedited changes should be avoided; changes introduced without the full deliberate

change process risks introducing errors into the production environment.

Reason Codes for Expedited Changes 1. Scheduling constraints.

a. A change is required as part of a project, service request or as an operational

maintenance task that must be introduced within a constrained schedule. This is the

case when the delay of the change:

i. affects future work dependent on this change

ii. would harm the current state of a system or service

2. Service supplier activities or changes affecting the availability of underpinning services (Telco,

Hydro, city utilities).

a. Services provided by utilities (Telco, Hydro power or other suppliers) may require

maintenance that is based on the needs and demands of a larger customer base beyond

McGill. In addition, such changes are constrained by the suppliers’ availability and

perceived urgency in managing their services. For these reasons scheduling may be

incompatible with the CAB approval cycle.

3. Vendor mandated updates or configuration changes.

a. Periodically a vendor alerts us to a security or operational fault in a system or service

that needs a patch or a configuration change. This is also applicable to off-premises

services or services co-managed by a vendor (e.g. D2L or SAN). These changes may be

required urgently and are subject to vendor availability. For these reason the change

may not align with the CAB approval cycle.

4. Contractual obligation.

a. It may arise that under contractual agreement we are to perform a specific task,

reconfiguration or decommissioning of a system or service. For example, a new license

key is to be applied, a system is no longer under license to us, a trial period comes to an

end, or a module must be deactivated as we may not have purchased it, or any other



commitment for which we have a legal, binding contractual obligation to perform. The

execution of legally mandated changes may not fit with the CAB approval cycle.

5. Preventative maintenance (security issues, detected faults or impending failures in

infrastructure).

a. When alerts indicate a fault or issue that has the potential for disrupting services and is

poised to do so, appropriate changes should be made to prevent it. The required

changes may not fit into the CAB approval cycle.

6. Fitting changes into predefined and announced maintenance windows.

a. Various services have regularly scheduled preannounced maintenance windows. These

windows allow for a measure of mitigation against unplanned service disruptions. In

many cases related and supporting services are also part of the maintenance window.

When such a support service needs maintenance, it can be beneficial to schedule the

work during the maintenance window of the service which it supports or has a strong

collaborative affinity. For example, McGill Portal work can be done during the monthly

Banner maintenance window. To meet the scheduled maintenance windows, RFCs may

not be able honor the time delays or the CAB approval schedule.

7. Requests from the business that are urgent and would have significant impact if made to

adhere to the normal delays.

a. The business may request changes to IT services to meet specific urgent needs. These

include the activation, deactivation or modification of a service to address specific

university business requirements.

8. Exception permitted by the change manager or CAB to facilitate timely work that is not

specifically addressed above.

a. Upon the discretion of the Change Manager, and where applicable, the CAB, shorter

lead times than the stated minimums may be approved when there are 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.

b. Criteria:

i. Presumed to be transparent to users

ii. Low risk of service interruption (failovers, redundancies or clustered nodes)

iii. Implementation date and time set to optimal low usage patterns, yet allowing

time for a response in a timely fashion to mitigate implementation issues

iv. Agreement by stakeholders has been obtained, Service Manager, service desk

and any technical staff needed to assist in the change.



Unified view of Change Categories

Major

CAB/ IT Directors

SignificantChange Advisory

Board (CAB)

Minor

Change Manager

Delegated Self-approved

StandardOutside Change

Process

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.

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.

A Minor change is not transparent, but is low in impact and risk. Small changes, may, at the discretion of the CAB, be granted delegated status (see below for more detail).

The CAB may grant delegated status for Minor changes that have been proven to be routine, have a high success rate, and are executed by experienced staff.

A pre-approved Change that is very low Risk and impact, relatively common and follows a Procedure or Work Instruction. For example password reset or provision of standard equipment to a new employee. RFCs are not required to implement a Standard Change.

Standard

Operating

Procedures

Standard

Operating

Procedures

ITIL

Change

Types

McGill Adaptation

Tasks may be

reappraised and

re-categorized.

Active promotion/demotion between these two types.

Upon appraisal by the CAB, Delegated tasks can be categorized as standard (SOP).

Tasks may be reappraised and re-categorized.

Normal

Changes

Normal

Changes

Expedited

CAB/ IT DirectorsFast track processing

Emergency

ECAB/ IT Directors(best effort)

Emergency

or Urgent

Changes

Emergency

or Urgent

Changes

Emergency changes are in response to

incidents or problems requiring immediate

action to restore service or prevent service

disruption.

An Expeditdl change is a normal change that

does not fit into the normal process schedule.

For technical or business reasons, it must be

processed in a faster manner than usual.

DRAWN BY

FRANK PETTINICCHIO



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 McGill’s 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 requestor’s manager. The CO is accountable for the quality and effectiveness of the work done by the CR and the CI.

Service Manager is the de facto sponsor of the change. The SM may have initiated the change or may have approved of the initiative. In all cases the SM’s permission is required to proceed with the submission of the RFC. The SM is consulted on the change plan and the content of the RFC before submission. Post submission the SM is informed as required about the RFC’s 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 (In the loop) 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 (Keep in the picture)



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 (CR’s supervisor) CO Service Manager (Sponsor) SM Change Manager CM

Change Process Owner CPO Change Advisory Board CAB

Procedure CR CI CO SM 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



Legend Process Roles Acronym

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 CIO’s 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 ITSM governance 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 organization’s vision and the process’s 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 and technology (tool)

Ensuring proper Key Performance Indicators are set

Ensuring quality reports are produced, distributed, and utilized

Integrating the Process into design and operational activities.

Taking a ‘helicopter view’, overseeing and ensuring integration between the specific Process and

other Service Management processes.

Staying informed about developments of the business

Staying informed about new 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



ITSM Working Committee Provide leadership for ITIL Process. Ensure that the vision and mission of 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)

Working 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 Manager’s 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.

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

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. 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 university’s IT infrastructure. The CAB makes recommendations for approval, further analysis, deferment, or rejection 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.

Unit Team Notes 1. NCS InfoSec

2. NCS Network

3. NCS Core Server Infrastructure

4. NCS Core Infrastructure Applications

5. ICS Service Desk Manager or Communications

6. ICS Service Desk Team Lead (rotation)

7. ICS Network and Desktop Services

8. CCS CMS/Web/EdTech portfolio

9. ISR Application Services

10. ISR Production Support

11. ISR CAM, RES, STU, FIN portfolio

12. CIO Enterprise Architect

13. ITSM Incident Management

14. ITSM Problem Management

15. ITSM SLA Management

16. PMO PMO



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 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 Manager 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. The manager of the RFC requestor is the Change Owner.

Change Owner’s 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 Manager The Service Manager (SM) is the de facto sponsor of the change. The SM may have initiated the change or may have approved of the initiative. In all cases the SM’s permission is required to proceed with the submission of the RFC. The SM is consulted on the change plan and the content of the RFC before submission. Post submission the SM is informed as required about the RFC’s execution, status and outcome.

The Service Manager’s Responsibilities

The Service Manager:

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

The Change Requestor’s 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 an 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 unit’s director as necessary.

Change tasks are added by Change Manager 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 ITSM Process managers or 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 unit’s 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 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 category’s 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 unit’s

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

StartCreate/edit

Task 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 no later than 5:00 PM

of the Friday 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.

Preapproval lead time serves to:

1. To ensure sufficient time for analysis and dialogue with the Change Manager to identify issues, errors, or deficiencies in the RFC, prior to its presentation at CAB. This is what keeps rejection rates low.

2. To allow sufficient time for familiarization of CAB members with the RFC and consultation with the forward schedule of changes.

3. To allow sufficient time to make adjustments to the implementation plan based on feedback from CAB that do not impact project timelines or business deliverables.

4. Timely planning of the CAB agenda. 5. Grace period for stakeholders to provide addition feedback before approval.

Pre-implementation lead time serves to:

1. Permits CAB members to request / recommend mitigations that would otherwise be difficult if a change is scheduled to be implemented immediately after approval.

2. Ensures adequate time to communicate with the necessary business stakeholders and take action based on their feedback if necessary.

3. Preparation of communications to affected users (so that they can work around potential or planned service interruptions).

4. Notification of the approval and final arrangements with on-calls, sys-admins, service managers, and other stakeholders (usually across multiple units).

5. Preparation of the Service Desk so they can respond to queries or potential incidents. 6. Pre-implementation system verifications and resource availability (software, hardware, vendor,

supplier, technical staff). 7. Time to respond to any feedback from the above before final commitment to proceed (speak

now or forever hold your peace).

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 Change manger, taking the circumstances into account, will decide to do one of the following:

process the RFC as an Expedited change – either at the CAB meeting or via email consultation

delay the RFC to the next CAB if the schedule permits

reject the RFC with explanation or alternately invite the requestor to cancel the RFC



Notes:

“Days” refers to business days. “Hours”, unless specifically stated otherwise, refers to business hours – i.e. 9:00 AM to 5:00 PM.

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 2:00 PM to be considered for same day, that evening or overnight (before 9:00 AM). When submitted after 2:00 PM, these Minor RFCs can only be implemented three business hours after the start of the next business day (no earlier than12:00 PM). Minor changes that do not honour this lead time may be rejected and will be flagged as expedited changes.

Impact Level Minimum Lead Time Required

Approval Authority Before Approval Between Approval and

Implementation

Delegated None None Self

Minor 3 hours or 1 business day1 & 2 None CM

Significant No later than Friday before 5:00 PM before the CAB

2 days4 CAB

Major No later than Friday before 5:00 PM before the CAB

3 days5 CAB

Expedited Significant and Major changes5

At or before 2:00 PM6 2 days7 CAB

Emergency changes8 Best effort9 Best effort9 ECAB



[2] Minor changes that require intervention from ICS, Operations or services from staff not part of the RFC build: The alert or request must be made at least 1 business day before the scheduled implementation time. Minor changes that do not honour this lead time may be rejected and if approved, will be flagged as expedited changes.

[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 as Expedited changes.

[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 Friday at 5:00 PM with

a two business day 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. It gives the Change Manager ample time to for analysis and

negotiating revisions to the RFC before reaching CAB. It also allows for post approval revisions or the

compliance with approval conditions.

Figure 4 illustrates the CAB approval cycle for Significant and Major changes based on an arbitrary

week. The cycle begins on submission deadline of Friday at 5:00 PM. 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 5:00

AM. Either Significant or Major changes can be scheduled well past these minimum milestones as is

indicated by the colour scheme (orange for Significant and red for Major changes).

November 21

Submit Major or Significant RFC on Friday before 5:00 PM

Friday Saturday Sunday Monday Tuesday Wednesday Thursday

22 23 24

Pre-CABRevision Period

25

Pre-CABRevision Period

26

CAB meeting ______________ POST-CAB Revision period

begins

27

Post-CABRevision Period

Note: for Major extends into Friday

28

Significant: Earliest time (10:00

AM)

OK Significant changes

29


30


December 1

Major: Earliesttime (5:00 AM)

OK Significant & Major

2


3


4


RFC Submission and Processing Cycle

Figure 4



Process Metrics Change management metrics provide indicators of the process’s 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 RFC’s 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 RFC’s

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 planned maintenance or incidents that have or will interrupt or degrade service must be announced

to the IT Services community. The SSA (System Status Announcement) application

(https://ncsmotion.campus.mcgill.ca/), should be the primary method for announcing these service

status changes. The SSA also serves as the authoritative source for recording service disruptions. IT

staff that is unfamiliar with the SSA application or has limited time to submit one, can contact the NCS

operator on duty ([email protected] or call 514-398-3699 select option 2) to have the operator

submit the SSA. SSAs have a broad distribution list that includes the ICS alert list.

https://ncsmotion.campus.mcgill.ca/

mailto:[email protected]



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 or incident ticket that corresponds to the item.

The SSA must reference the RFC or incident ticket for which it is issued.

The start/end times must be reconciled when closing the SSA with other sources that may have

recorded these values. These include but are not limited to, the Heat ticket, the operations log,

admin logs and staff memories of events. The reconciled, and thus definitive, start/end values

of a service disruption will be entered in to the respective SSA.



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 (don’t 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 team’s 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 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.

https://itservicemotion.campus.mcgill.ca/



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. ITSM Process managers, 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).



Priority:

Select from the pull-down the appropriate priority for this RFC. The priority can be used by the CM to prioritize the order and speed at which an RFC will be processed. Should the RFC need special consideration from the CM, contact him directly to ensure proper handling.

Risk:

Select from the pull-down the appropriate risk for this RFC. The risk level selected should be the result of an analysis appraising the risk of executing the change (what could go wrong as a direct result) and the risk that follows once the change interacts with other systems and users. See Appendix C for more details.

Impact:

Impact refers to the harm that would result should the change fail. The impact for most categories has been predetermined. You may raise it, but not lower it. The impact takes into account the number of users affected, the duration of interruptions and the potential for data loss or corruption.

Approved by manager:

Every RFC must be approved by the line manager. No RFC will be approved if this field is not set as approved.

Approved by owner:

Every RFC must be approved directly by the owner of the change Item. This is the manager of the team that manages the Service referenced in the RFC. This role is also referred to as the Service Manager. No RFC will be approved if this field is not set as approved.

Implementation duration:

This must be set to the expected duration of the RFC from start to finish. Any special conditions must be clearly described in the Description of Change below. For example, the RFC may be done in two phases of one hour.

Back out duration:

This must be set to the expected duration of the RFC from start to finish. Any special conditions must be clearly described in the Back out plan of this process. The value should represent the time it would take to restore the item changed to its previous state of service, or at a minimum, made functional.

Service Disruption:

This field must be set to the expected duration of service disruption from start to finish of the implementation of the change. Any special conditions must be clearly described in the Description of Change below. For example, the RFC may be done in several steps or phases. This may require multiple service interruptions of various durations.



Description of change:

Provide a brief description of the change that includes what you are trying to achieve and how it will be done. Reference all items (hardware, software, SLAs, documents) by name and when appropriate by version or model numbers. It is appropriate to list the name of any supporting documents and, when applicable, provide a hyperlink. Depending on the complexity of the change you may:

Provide a step-by-step procedure. For multipart, multi-staff changes a detailed schedule for each step is a necessity.

List others involved in the RFC; third party support, other groups or other departments and their roles. For example state clearly that a technician from XYZ will perform the change on ABC.

Refer to any project or initiative for which the change is made.

List any preceding RFCs that are related or prerequisites to this RFC.

Mention future work that this RFC is in anticipation of.

List any agreements with others (colleagues, owners, managers, third party support).



Who will be affected:

The list of who is affected is an important element in appraising the impact. You should list users by category (e.g., students, staff, etc.) or geography (e.g., McLennan library users, etc). It is also helpful to list the affected hardware. For example listing the wireless controllers affected by a change allows us to estimate the number of users affected by the change. Change is made to fix or improve services, but change can also introduce new flaws. Any change can have a negative effect in two ways: 1) any disruptions required to make the change, and 2) problems the actual change once in production may cause. It is not sufficient to state only the effect on usage by the downtime incurred during the change. For example, to say no one is affected by a change because the change is occurring during a scheduled downtime is neglecting to appraise the risk and impact of post implementation failure.



Effect if change will not be implemented:

Changes have a purpose; they are to correct, prevent a fault or enhance service. Describe here the consequences should the change not be made, what conditions (current and future) will prevail and how they negatively impact usage.



Test plan and test results:

Appendix C details the need for testing and provides guidelines for how extensive the testing plan should be. A Delegated change that has a well-established and documented procedure does not need testing. All other impact levels of RFCs must have an adequate test plan. The test plan should be well documented and appropriate to the change at hand. The results of the tests should be clearly stated. Failure to provide this basic information will prevent approval of the RFC. You should report here the equipment used, the test methodology, why this methodology was used, the expected results, the actual results, and finally why the results justify proceeding with the change.



Risk analysis:

Appendix C describes risk and impact and how they interplay. The risk has two components: 1) the actual act of making the change, and 2) the effect of the change post implementation – the full effect of a change or flaws it introduced only become apparent after the change interacts with specific usage, data, or other elements of the ecosystem. Risk analysis is the linchpin for appraising and approving an RFC.



Alternate solutions considered:

List here any other strategy that was considered other than the proposed plan. This will assist the CM, the CAB and, when appropriate, forensics, in understanding the change and making judgments in the future for similar changes. The CAB may feel that an alternate solution is less risky, less costly, or a better long-term solution.



Back out plan:

State here clearly how the state of the item to be changed can be restored to its previous working state. The back out plan requires the same diligence in preparation as the proposed change. A detailed step-by-step plan should be outlined. Any documentation should be referenced and hyperlinked. In the event that an outright back out is not possible or not desired you should state clearly as to why. Provide an alternate plan to remediate the failure in lieu of a clean back out.



Communication plan:

As a general rule, it is better to be liberal, than conservative as to who is notified and consulted on a proposed change. The principles of project management apply to RFCs when it comes to stakeholders. Whenever users are affected the ICS Service Desk must be consulted prior to the submission of the RFC. The help desk should have input in how and when the change will take place – this will help mitigate disruptions and provide for Service Desk preparedness for supporting users. Without proper communication, other departments would not be able to shape the RFC to meet their needs. For example, we would not risk a network failure during registration. The rule of thumb is at least two days’ notice for the Service Desk staff – high impact changes require early and extensive involvement. For further guidance see the “Lead Times for Stakeholder Communication” section. The communication plan should provide for pre-implementation alerts (SSA) to stakeholders (colleagues, service administrators, ICS Service Desk) and post-implementation alerts to signal either a successful completion of the post-implementation checklist or the fallback to the back out plan. Another major consideration is to ensure that any personnel required to monitor, verify or react to the change have been notified and made available at the appropriate time(s) during the change. When the RFC is a multi-step, multi-group effort, special care must be given to precision communication among the individuals and groups performing the change. Each step’s start and completion should be signaled to the other partners so that the work can proceed in the correct order and on the agreed schedule.



Budgetary impact:

In some cases a change may have a known cost. For example, switching from tier 1 to tier 3 storage for a service will save a certain dollar amount for the next 3 years. When these considerations are known and available they must be included in the RFC.



Verification checklist:

The post-implementation verification is an absolute necessity to determine whether the change is to stand or to be backed out. In some instances a back out is not possible or not desired, but the verification will at least allow us to ascertain the new state of the service. This may require pre-implementation baselines and the appropriate metrics to verify a net improvement or degradation of service. The verification list must be an explicit step-by-step recipe for testing the expected result of the change and for discovering flaws – it must state what you will be testing and how you will test it. The “new” state of the service must be exercised as fully as possible to certify it as a successful implementation.



Appendix B: Closing an RFC This Close process allows the change implementer to describe the outcome of the change and its disposition quickly and effectively. This allows the Change Manger to make a decision as to whether a formal Post Implementation Review (PIR) should be conducted to extract lessons learned to make recommendations on:

Improvements to the technical teams’ processes and procedures

changes hardware and software (infrastructure)

changes to the Change Management Process to better serve the enterprise In addition, this information provides metrics to better understand how the process is functioning.

Basic Flow of the RFC Implementer Close

StartRFC was

Implemented?(attempted)

Select all that apply for withdrawing (Cancelling) the RFC. The case for making the change is no longer valid The state of the software /hardware has changed 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 or project The RFC was inadequate or flawed in the assumptions and facts presented Other: ______________________________________________

No

Yes

Caused an incident?

Ticket #: _________ Brief Description:______________

________________________________________________________

Backed out? Why?_______________________

___________________________Yes

Select all that apply: Deviated from plan Did not achieve objectives Partially implemented Exceeded implementation

window

Add implementation Notes

Close

Flow for RFC close by requestor

No

No

Yes

Note:If any is selected then the “Implemented with Exception” = true



The implementer will answer questions in a decision tree to arrive at a determination that the RFC

ended in one of five statuses: Implemented with no Problems, Cancelled, Backed out, Implemented

with Incident, and Implemented with Exception. The distinction is made between with Incident and

with Exception so that hiccups occurring during a change will not be automatically lumped in with a

change that causes an incident.

Implemented with no problems No further information is required from the implementer (may add implementation notes if so desired). This will be the close status of the vast majority of all changes.

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

The RFC was inadequate or flawed in the assumptions and facts presented

Implemented with incident The change caused one or more Priority 1 or Priority 2 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. Implementer may have had to restore data and or software/hardware configurations.

Implemented with Exception The implementer would be required to select (check boxes) any of the following that apply to the exceptions encountered with the RFC. The implementer is expected to provide explanatory notes for any of the selected items above.



Exception Description

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.

Final RFC Closure Status

The RFC will have one of the following as a final status. Other states are transient and must be resolved

to one of these:

1. Cancelled

2. Rejected

3. Implemented OK

4. Caused Incident – may have been backed out and may have had “exceptions” during the

implementation

5. Backed out -- may have had “exceptions” during the implementation

6. Implemented with exception

7. Implemented with problem (old RFCs closed` before January 2013)

Items 4, 5 and 6 are not mutually exclusive, but do have a priority protocol for how the RFC is finally

reported. The priority facilitates the analysis for determining whether a formal Post Implementation

Review is necessary. The metric recorded retains all information and KPIs can be created to report

accurately on all statuses and combinations of statuses.

Final status 4. Incident 5. Backed

out 6. Exception

Caused Incident Occurred possible Possible

Backed out No Occurred Possible

Implemented with Exception No No Occurred





Using IT Service Motion to Close the RFC

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 (don’t click) the mouse over My Stuff tab, as

shown (below) and select either My Open RFCs or My group open RFCs.

Next: click on the (edit RFC) icon as shown below.

Next: click on Close to begin the RFC close process.

Next: Scroll to the bottom of the page and respond to the screen instructions as they are presented.

https://itservicemotion.campus.mcgill.ca/



Appendix C: Risk Assessment

High risk

The likelihood of a negative event is high and/or its occurrence has a large impact on service

disruptions or data integrity. The procedure is of long duration or difficult to back out of the

change.

Make sure management is aware of the change and its implications. Notify the

appropriate stakeholders well in advance of the proposed scheduled change – especially

the ICS Service Desk.

Requires a test environment, where functional and non-functional testing can be

completed. The change should be tested under real load conditions (pilot testing may

be required).

Moderate risk

There is a moderate chance that a negative event will occur, but it has a fairly low impact on a

number of affected users, short disruption and low risk of data loss. The change may only affect

segments of the user base and can be reasonably backed out.

Notify the appropriate stakeholders well in advance of the proposed scheduled change – especially the ICS Service Desk. The change must be well tested and, when possible, it should be verified under real conditions.

Low risk

There is a low probability of a negative event occurring and a low impact on the quality of

services should such an event occur – i.e., very short or minor disruptions and no data loss. The

change is easily backed out.

Notify the appropriate stakeholders if the change is not transparent. In most cases, you

should notify the ICS Service Desk and the owners of the service.

Make sure that the change has been validated by previous implementations of the

change.

No risk

The change is operationally simple to do and has no disruptive effect on service.



Testing and Validation Recommendations Based on Impact and Risk

In order to appraise the methods and extent of testing required for a change, the risk and impact must be determined. All changes pose some risk to the services we manage and maintain. The requestor of the change should assess the risk level. The assigned impact category will dictate the type and level of testing. This table defines how testing and validation should be applied to the five impact levels.

Impact Definition Testing and Validation

Recommendations

Major

High risk level.

There is a potential of disruption to services to a large number of users (1000+). The change may shut down enterprise level services. There is an expected downtime.

Test environment (lab or test server) to validate the solution (functional: did the change work correctly?)

What-if analysis to understand the impact on existing infrastructure (does the change integrate seamlessly?)

Pilot testing is highly recommended

Detailed implementation plan is required at the level of a project plan

Extensive communication plan

Explicit implementation plan

Significant

Moderate to high risk level.

There is a potential impact on services during the procedure, reduced capacity or longer response times for users (1000+). Some short disruption may be required.

Test environment (lab or test server) to validate the solution (functional: did the change work correctly?)

What-if analysis to understand the impact on existing infrastructure

Detailed implementation plan may be required

Minor

Low to moderate risk level.

The potential for disruption is small or limited to a very small number of users. The change may require short service disruptions.

Typically these changes are supported by previous testing on similar changes in the past. If validation has not been done, validate the change in a test environment to ensure that it does not cause problems.

Delegated

Low risk level.

The change is fairly transparent to users and rarely requires service disruptions. When disruptions are necessary they are of very short duration and limited to a small number of users.

Testing will have been done on a test case. Testing is not required for each change. These changes are template quality.

Standard

Risk is negligible or zero.

No user or service impact. Examples include adding individual users to services, and Standard configuration changes such as passwords. No service disruptions are expected.

No testing is required and does not fall under the change management process.



Risk and Impact

The Risk Quotient (RQ) is an expression of the risk of loss or damage and its impact.

RQ = P x I (Risk quotient = probability X impact)

Probability or P is the chance of failure and usually expressed as a percentage or a value from

0.0 to 1.0 – where 1.0 is 100%. There are two components:

P₁ is the probability of an event (error or failure) during the actual execution of the

change.

P₂ is the probability of an event (negative interactions with users, data, hardware

and other systems within the ecosystem) that may occur after the successful execution of the change.

Probability that at least one of the events (errors) will occur for a change: PC = P₁ + P₂

Probability that both types of errors will occur for the same change is: PT = P₁ x P₂

Often, the chance of error while making the actual change is very slim. However the chance of

failure due to some interaction with other systems, databases, or other recent changes is as

high as one out of ten. The only way to understand this risk factor is to do a thorough what-if

analysis. We are often lulled into a sense of security because we have high confidence in the

actual change procedure.

Impact or I is the scope of the failure (see table on previous page). The appraised impact

serves to magnify or reduce the RQ. For example, let us consider a simple task: solve the arithmetic expression 2+2. If the stakes for getting it wrong is that you get laughed at, extra effort – such as could be applied – is wasted. What if the consequence of not answering four is that you will be fined $5,000? You would pause, clear your mind and concentrate on the solution. Now consider the changes we undertake. Some changes affect only a handful of people (e.g., replacing a 24-port router with a 48-port router), while others can affect the entire enterprise for prolonged periods of time (e.g. changes to electrical infrastructures in the datacentre). The test plan must be appropriate to the risk and impact appraised.

The impact can be: 1. Direct (e.g., no email for a day) 2. Indirect (e.g., prospective students unable to get information about McGill)

and can have consequences of varying impact (cost):

1. Cost to remediate the failure 2. Lost opportunities (actions not taken) 3. Loss of productivity (lost time multiplied by thousands of employees and students)



4. Intangibles (e.g., loss of reputation)

The higher the impact of an RFC, the greater the effort required in the analysis, testing and mitigation plan (this includes communication, back out plan and post implementation verification).

Standard

Request Fulfillment

Delegated

Significant

Minor

Major

Major Consequences(open ended)

Degree of

Damage

Number of people affected



Appendix D: Selected ITIL Glossary (source ITIL Foundation)

Change

The addition, modification or removal of approved, supported

or baselined hardware, network, software, application,

environment, system, desktop build or associated

documentation.

Change Advisory

Board (CAB)

A group of people who can give expert advice to on the

implementation of changes. This board is likely to be made

up of representatives from all areas within IT and

representatives from business units.

Change Authority

A group that is given the authority to approve change, e.g.,

by the Project Board. Sometimes referred to as the

Configuration Board.

Change Control

The procedure to ensure that all changes are controlled,

including the submission, analysis, decision-making,

approval, implementation and post-implementation of the

change.

Change Document Request for Change, change control form, change order,

change record.

Change History Auditable information that records, for example, what was

done, when it was done, by whom and why.

change log

A log of Requests For Change raised during the project,

showing information on each change, its evaluation, what

decisions have been made and its current status, e.g.,

Raised, Reviewed, Approved, Implemented, and Closed.

Process of controlling changes to the infrastructure or any

aspect of services, in a controlled manner, enabling approved

changes with minimum disruption.

Change Record A record containing details of which Cls are affected by an

authorised change (planned or implemented) and how.

Configuration

Baseline

Configuration of a product or system established at a specific

point in time, which captures both the structure and details

of the product or system, and enables that product or system

to be rebuilt at a later date.

Configuration

Control

Activities comprising the control of changes to Configuration

Items after formally establishing its configuration documents.

It includes the evaluation, coordination, approval or rejection

of changes. The implementation of changes includes



changes, deviations and waivers that impact on the

configuration.

Configuration

Documentation

Documents that define requirements, system design, build,

production, and verification for a Configuration Item.

Configuration

Identification

Activities that determine the product structure, the selection

of Configuration Items, and the documentation of the

Configuration Item's physical and functional characteristics

including interfaces and subsequent changes. It includes the

allocation of identification characters or numbers to the

Configuration Items and their documents. It also includes the

unique numbering of Configuration control forms associated

with changes and problems.

Configuration Item

(CI)

Component of an infrastructure - or an item, such as a

Request for Change, associated with an infrastructure -

which is (or is to be) under the control of Configuration

Management. Cls may vary widely in complexity, size and

type - from an entire system (including all hardware,

software and documentation) to a single module or a minor

hardware component.

Configuration

Management

The process of identifying and defining the Configuration

Items in a system, recording and reporting the status of

Configuration Items and Requests For Change, and verifying

the completeness and correctness of Configuration Items.

Configuration

Management

Database (CMDB)

A database which contains all relevant details of each CI and

details of the important relationships between Cls.

Configuration

Management Plan

Document setting out the organisation and procedures for

the Configuration Management of a specific product, project,

system, support group or service.

Configuration

Management Tool

(CM Tool)

A software product providing automatic support for change:

Configuration or version control.

Configuration

Structure A hierarchy of all the Cls that comprise a configuration.

Contingency

Planning

Planning to address unwanted occurrences that may happen

at a later time. Traditionally, the term has been used to refer

to planning for the recovery of IT systems rather than entire

business processes.



Continuous Service

Improvement

Programme

An ongoing formal programme undertaken within an

organisation to identify and introduce measurable

improvements within a specified work area or work process.

Customer

Recipient of the service; usually the customer management

has responsibility for the cost of the service, either directly

through charging or indirectly in terms of demonstrable

business need.

Forward Schedule

of Changes (FSC)

Contains details of all the changes approved for

implementation and their proposed implementation dates. It

should be agreed with the customers and the business,

Service Level Management, the Service Desk and Availability

Management. Once agreed, the Service Desk should

communicate to the user community at large any planned

additional downtime arising from implementing the changes,

using the most effective methods available.

Impact

Measure of the business criticality of an incident. Often equal

to the extent to which an incident leads to distortion of

agreed or expected Service Levels.

Impact Analysis

The identification of critical business processes, and the

potential damage or loss that may be caused to the

organisation resulting from a disruption to those processes.



Appendix E: CAB and ECAB Membership by Role

Note: Roles with the “ECAB Member” checked are part of the ECAB.

Name Unit Team ECAB Member

Notes

1. NCS InfoSec

2. NCS Network

3. NCS Core System Infrastructure

4. NCS Core Infrastructure Applications

5. ICS Service Desk Team Lead rotation

6. ICS Network and Desktop Services

7. CCS CMS/Web/EdTech portfolio

8. ISR Portfolio Management Portfolio Managers rotation

9. ISR Systems Management &

Integration

10. ISR Production Support

11. CIO Enterprise Architecture

12. ITSM Incident Manager

13. ITSM Change Manager

14. ITSM Problem Manager

15. ITSM SLA Manager

16. PMO PMO



Appendix F: Document Changes Version 1.1 (July 21, 2009)

Added appendix C: Special Considerations and Required Content by Task (Sept. 5, 2009)

Added logo and front page (Oct. 6,2009)

Added text to Back out Plan in: Appendix A: Creating an RFC (Oct. 6,2009)

Added table of contents (Oct. 8, 2009)

Added section on Changes that involve security issues and/or confidentiality (Oct. 15, 2009)

Added section on commissioning a server (Nov. 17, 2009)

Added section “Communication plans and adequate notices of service disruptions “(Nov. 17, 2009)

Version 2.0 Major rewrite of entire document (April through May 2010)

Version 3.1 Major rewrite of entire document (April through July 2012)

Version 3.2 updates to emergency change models, KPIs, and process mapping diagrams. (January through May 31 2013)

Version 4.0: through to January 7, 2015 o Removed the integrated Change, Incident and problem management flow chart. This

did not reflect accurately the workflows in practice today and the proposed designs

going forward.

o Modified section Change triggers as an intro to new section on Change Authority

Hierarchy

o Add section Change Authority to encapsulate the various change authority levels

o In Basic Concepts, added discussion on introducing project proposals at the CAB

o Clarified in item 9 of Basic Concepts the role the Change manager has in assembling the

CAB an ensuring the proper composition for the agenda items.

o Change the Role Service Owner to Service Manager throughout the document to reflect

the consensus usage of the term

o Rewrite of section Changes that involve security issues and/or confidentiality

o Added section Changes initiated or required by a third party

o Added major section defining expedited change (reasons and causes) and the future

flag for (Reason Codes) to be applied to expedited changes.

o Rewrite on role of the Change management steering committee to reflect the name,

role and mission of the new reference body the ITSM Working Committee.

o New CAB/ECAB composition based on the recent IT reorganization.

o Rewrite of Lead Times for RFC Processing to reflect decision taken by the ITSM Working

Committee. New graph added to illustrate the CAB lead times.

o SSA section improved (added contact info, and general rules of usage)

o New graphic added to illustrate impact (consequences of changes on the business) in

the Risk and Impact section.

o Various minor changes to refine discussion and fix typos and grammar.

Date post:	11-Jul-2016
Category:	Documents
Upload:	diegosq
View:	13 times
Download:	1 times