McGill IT Services Change Management Process Guide

McGill
IT Services
Change Management Process Guide
Version 4.0
Frank Pettinicchio
January 7, 2015
January 7, 2015
Version 4.0
Page 1
January 7, 2015
Version 4.0
Page 2
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
January 7, 2015
Version 4.0
Page 3

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
January 7, 2015
Version 4.0
Page 4

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 (dont 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
January 7, 2015
Version 4.0
Page 5

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
January 7, 2015
Version 4.0
Page 6
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.
January 7, 2015
Version 4.0
Page 7

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 Change Authorization Hierarchy
resides at different levels
of the Change
Change
Level of
Communications
Communications,
authority
Impact/risk/cost
Decisions
Escalations for RFCs,
Authorization hierarchy.
And actions
Risks, impact, issues
High cost/risk/impact
For the sake of brevity
to business- Requires
University VPs,
Level 1
decision from
each level is described in
planning office
university executives
concise terms. Each level
to initiate project
may have more
granularity and is detailed
Significant cost and
Level 2
CIO, IT directors
risk affecting services
in the various documents
(internal IT projects)
describing McGill IT
infrastructure and
New or changed
services characterized
procedures. The figure to
Level 3
CAB or ECAB
by high impact and
the left encapsulates the
risk (Major and
Significant changes)
current levels of change
authority existing in
Low to medium
McGill IT. This document
impact and risk
Level 4
Change manger
changes
will mainly address level 3
(Minor changes)
to level 6.
Technical Teams
(operational and
administrative IT
staff)
Pre-approved low
impact and low risk
Minor changes
(Delegated changes)
The change management

process is an integral part
of all functional layers of
IT governance at McGill.
These layers include the
Level 6
Local authorization
Standard changes
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.
Level 5
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.
January 7, 2015
Version 4.0
Page 8

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 projects 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)
January 7, 2015
Version 4.0
Page 9

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 CMs notes and placed in the
RFC. Approval may also be conditional in that the requestor may be mandated by the CAB to
make changes to the RFC before it can be finally approved.
7. Should strong disagreement arise that cannot be resolved among the CAB, upon the discretion
of the Change Manager the issue may be escalated to the directors level.
8. In the case of urgent changes or changes that cannot wait for a CAB meeting, upon the
requestors or the CMs initiative, the CM may schedule a CAB 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 CABs 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
January 7, 2015
Version 4.0
Page 10

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
January 7, 2015
Version 4.0
Page 11

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
January 7, 2015
Version 4.0
Page 12

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.
January 7, 2015
Version 4.0
Page 13

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 cant wait until the next scheduled CAB.
Standard Change (aka standard operating procedure - SOP)

A standard change is a preapproved change that is low in risk, common and follows a welldocumented 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.
January 7, 2015
Version 4.0
Page 14

Change Categories and Impact Levels
The creation and submission of RFCs is done via IT Services Motion web application
(itsmotion@campus.mcgill.ca). 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 units senior staff for impact and
risk. The section Change Categories provides detailed guidance on how this is done.
Change Models and Work Flows

Change Models refers to the method used to make a change. Broadly, there are three change models
defined by ITIL (as discussed above) each of these can be refined into more change models as the need
arises and opportunities of streamlining the execution of repetitive changes is identified. In the
discussion below we continue to define and enhance our understanding of the three main ITIL change
models (Standard, Normal and Emergency) and the three subcategories into which Normal changes are
divided: Minor, Significant and Major. The important concept to retain is that the workflow, in broad
terms, differs for Minor changes as opposed to Major changes. For example Minor changes are
approved by the Change Manager, while Major changes are processed by the CAB and require greater
rigor in planning and execution.
We can create our own change models to deal with changes that are repetitive and well understood and
need specific handling and requirements. These models can be developed for either normal (of any
subcategory) or emergency changes. The workflows for these locally defined models are a sequence of
predefined steps to be taken in an agreed way. The model would include:
steps to be taken (activities, actions e.g. testing, assessing a change, approving a change),
the order in which the steps are to be followed
roles and responsibilities (who is going to do what, who is responsible and accountable for the
work),
timelines (time needed to deal with a change at its various stages),
thresholds (e.g. cant approve a change before next CAB then the change becomes an Expedited
change) and
escalation (who to inform, from whom do we get additional authorization)
On the following page is a diagram illustrating the broad flow of RFCs through their lifecycles. For full
detail of each change category please consult the discussion above.
January 7, 2015
Version 4.0
Page 15
January 7, 2015
Version 4.0
Page 16
Change Management Process Flow

Change Management Process
Service Owner
RFC Build
RFC approval process
RFC implementation
RFC Close
Identify, assess
need; response to
incident or problem
Change Owner
Emergency
Change
Change
Model?
Normal Change
Delegated Change
Analysis,
Stakeholder
agreement, sign to
staff
Maintenance
Change Requestor
Needs revision
Normal
Change
Change
Model?
RFC Build and

testing
Testing,
scheduling,
OK?
Validated
Submit RFC
Normal Change: CM
Intervention required
Delegated Change
Change
Manager
Change
Implementer
Failed: Withdraw/Cancel
Approved
Apply conditions &
required edits by CAB
Errors detected by CM
or other stakeholder
Provide support,
consultation and
advice throughout
the lifecycle of the
change
Accept RFC:
Analysis of RFC
for compliance
Implement and
validate change:
Minor
Change
CAB/ECAB
update status &

results
Formal
Review?
Assess and
evaluate
Rejected
January 7, 2015
Implementer's
Close:
Yes
PostImplementation
Review
CM close
No
Significant or
Major Change
CM Consults CAB
Process RFC
Version 4.0
Page 17
January 7, 2015
Version 4.0
Page 18
Basic workflow for Normal, Emergency and Standard changes
Change Categories
Change Model (work flow)
Change Authority
Normal Changes
Change Manager
Change Advisory Board
Emergency Changes
Must test
Must have back-out plan
Assessed at regular intervals
(CAB meetings etc)
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
January 7, 2015
Version 4.0
Page 19

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
Authority
Category
Standard
Selfapproved
Minor
Change
Manager
Description
Examples
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.
A minor change is not
transparent, but is minimal in
risk and impact.
Password reset
Keyboard replacement
Installation of a network Jack
Adding removing a telephone
feature
Oracle Database Parameters Change

New virus signatures
Server additions, modifications,
removals
SAN storage
additions/deletions/modifications to
a client
Network port additions, moves
San storage additions to a client
Backup client additions
Routine database administration
tasks
Data backups and/or restores
Internal database schema changes

Network topology changes
Server role changes
Power shutdown
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
Delegated
Significant
Selfapproved
(approval is
delegated to
the technical
team by the
CAB)
Minor change delegated to the

technical team by the CAB as
self-approved.
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.
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 backout is difficult or impossible.
CAB
Major
Change categories as implemented at McGill
January 7, 2015
Version 4.0
Page 20

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.
Aggravation to risk/impact
Mitigation to risk/impact
Procedure applied to
the CI (Configuration
Item)
Impact on other
systems or
applications
(interdependencies)
Factor
Major upgrade
Major configuration changes
Reboot
Minor configuration change
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
Transparent to users; i.e.

Minimal or no service disruptions
Time scheduled
Service disruptions are expected

and the user experience is
affected
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.
No testing done
Testing not done on comparable
hardware/software
Incomplete testing
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
Business process
change
(effect on usage)
Stakeholder approval
Considerable and complex

change required by IT and/or
customers (documentation,
training, support)
Little or no advanced notice and
Planning did not include
stakeholders
Verification plan
(checklist)
January 7, 2015
Post implementation verification

plan is weak
Version 4.0
Two components on one

platform
Single component
Little or no change required
Stakeholders have agreed to

service disruptions and to the
schedule
Stakeholders have influenced
the RFC content and build
Plan is comprehensive
Staff has been assigned to verify
their areas of responsibility
Page 21
does or not include all major

components of the service
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 universitys crisis managers ask that
wireless access in a building be turned off as a response to a security threat. Urgent business needs
not for immediate action will be processed as Expedited changes (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.
January 7, 2015
Version 4.0
Page 22
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
1. Service Down
Correct fault
and/or
reboot
Post
Technical Team
Manager
Implement
plan per RFC
Pre
Change
Manager,
ECAB*
Correct fault
and/or
reboot
Post
Technical Team
Manager
Implement
plan per RFC
Pre
Change
Manager,
ECAB*
5. Business Requirement
Implement
plan per RFC
Pre
Change
Manager,
ECAB*
6. Predefined Emergency Model*
As specified in
the procedure
As specified in
the procedure
As specified in
the procedure
Entire service is down or unusable for all users
2. Service Partially Down

Service is unavailable or unusable for some but
not all users
3. Cluster Node Down

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

Server/node is down or unresponsive, but there
is no perceivable impact on users
Technical teams may be granted by the CAB the

application of a specific set of actions for a
service.
RFC
Approval
Authority
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.
January 7, 2015
Version 4.0
Page 23

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.
January 7, 2015
Version 4.0
Page 24
Emergency Changes Model Sub Processes:

Emergency Change Process
Change Owner
RFC Build
RFC approval process
Analysis, and
determine the
Emergency model
Business
Requirement?
No
Predefined
Procedure?
RFC implementation
RFC Close
Issue SSA
No
Service/
Node Down?
P1:P2
Completely Down EM1 or EM3
Yes EM5
Yes EM6
RFC Build:
Analysis and plan;
Stakeholder buy-in
Best effort to
provide testing
CM/ECAB
Change Implementer
Change Requestor
Partially Down EM2 or EM4
Validated
Submit RFC
Predefined
Procedure?
Change
Model?
Yes
Implement and
validate change
No
YES
Back out if
necessary
No
Provide support,
consultation and
advice throughout
the lifecycle of the
change
January 7, 2015
Assess and
evaluate RFC
Make changes as
required by CM/ECAB
Revision
required?
No
Approved?
Yes
RFC
exists?
No
Create and Submit

RFC
Yes
Analysis
Normal Change
Rejected
Version 4.0
Working?
Implementer's
Close:
update status &
results
Requires
formal
review?
Yes
PostImplementation
Review
CM Close
No
Page 25
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 McGills 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.
January 7, 2015
Version 4.0
Page 26

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
January 7, 2015
Version 4.0
Page 27
5.
6.
7.
8.
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.
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.
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.
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.
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.
January 7, 2015
Version 4.0
Page 28

Unified view of Change Categories
ITIL
Change
Types
Emergency
ECAB/ IT Directors
(best effort)
Emergency changes are in response to

incidents or problems requiring immediate
action to restore service or prevent service
disruption.
McGill Adaptation
Emergency
Emergency
or Urgent
or Urgent
Changes
Changes
Expedited
CAB/ IT Directors
Fast track processing
Major
CAB/ IT Directors
Tasks
Tasksmay
may be
be
reappraised and
reappraised
and
re-categorized.
re-categorized.
Normal
Normal
Changes
Changes
Active promotion/
demotion
between these
two types.
Significant
Change Advisory
Board (CAB)
Minor
Change Manager
Delegated
Upon appraisal by
the CAB, Delegated
tasks can be
categorized as
standard (SOP).
Self-approved
Standard
Standard
Standard
Operating
Operating
Procedures
Procedures
Outside Change
Process
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.
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.
DRAWN BY
FRANK PETTINICCHIO
January 7, 2015
Version 4.0
Page 29

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

Change Requestor creates and submits the RFC for processing. The CR is responsible for content (facts
and analysis) of the RFC. In McGills context the Requestor is usually, but not always, the Change
Implementer.
Change Implementer is responsible for executing the change plan and for recording the results of the
change implementation. In our context the Change Implementer is usually the Change requestor.
Change Owner is the Change requestors manager. The CO is accountable for the quality and
effectiveness of the work done by the CR and the CI.
Service 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 SMs 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 RFCs execution, status and
outcome.
Change Manager is responsible for verifying that the RFC conforms to the process guidelines. The CM
will verify the risk/impact analysis. The CM may reject, require revisions, or approve the RFC.
Change Process Owner is accountable for the overall quality and effectiveness of the Change
Management process. This includes The CPO supervises the work of the Change Manager.
Change Advisory Board assists the Change Manager in his role in appraising the completeness, validity
and the risk/impact analysis for significant changes.
Charting definitions
Responsible (The Doer)
The doer is the individual who actually does the task. The degree of responsibility is determined
by the individual with the A.
Accountable: (The buck stops here)

The individual accountable is the person who is ultimately answerable for the activity or
decision.
Consult (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)
January 7, 2015
Version 4.0
Page 30

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
Responsible,
Accountable
Consult before doing
Inform after decision taken
Process Roles
Acronym
Change Requestor
Change Implementer (may be same as CR)
Change Owner (CRs supervisor)
Service Manager (Sponsor)
Change Manager
Change Process Owner
Change Advisory Board
CR
CI
CO
SM
CM
CPO
CAB
Procedure
1. Identify, assess need; response to incident or
problem
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
CR
CI
CO
SM
A,R
CM
CAB
3. Check the validity and completeness of the RFC
4. review impact and risk
5. Approve/reject/return for revision
6. Execute implementation plan
7. Cancel RFC
8. Post implementation verification and acceptance
C
C
R
R
A,C
A
C
R
I
I
9. Initiate back out
A,C
10. Record implementation results
11. Monitor change
12. Record incidents
13. Update RFC with monitoring status and results
14. Post Implementation Review (PIR)
R,A
January 7, 2015
Version 4.0
I,C
Page 31

Legend
15. Document findings of PIR and set closure code
16. Close RFC (completed)
January 7, 2015
Process Roles
I
I
R
Version 4.0
Acronym
R,A
C
I
Page 32

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

The ITSM Executive Committee oversees the design, development and implementation of IT governance
infrastructure and policy. The committee is composed of the CIO, the IT unit directors and ITIL process
owners.
ITSM executive Responsibilities:
Set and oversee strategies for implementing ITIL at McGill.
Provide the various process owners guidance and input from the respective units.
Review reports from the process owners
Advises the CIO on 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 organizations vision and the processs strategic
goals.
Supervises the Change Manager (CM); sets goals and priorities to be followed by the CM.
Seeks guidance from the Change Manager and various stakeholders on issues relating to the Change
Management Process.
Act as a liaison between the Change Process structure and the directors and CIO.
January 7, 2015
Version 4.0
Page 33

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
January 7, 2015
Version 4.0
Page 34

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 Managers Responsibilities
Is responsible for monitoring compliance with the Change Process and resolving day to day change
issues.
Approves changes.
Ensures that all changes are reviewed and all changes meet basic requirements before approval
Important Changes, he will refer the authorization of Changes to the Change Advisory Board.
Will recommend, in consultation with the CAB, process changes to the Process Owner and the CMPSC.
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.
January 7, 2015
Version 4.0
Page 35

Change Advisory Board (CAB)
The mission of the CAB is to review and prioritize requests for change, keep track of the change
management process, and provide feedback to the Change Manager. The CAB gives the Change
Manager the support necessary to help make the best decisions for proposed changes to the universitys
IT infrastructure. The CAB makes recommendations for approval, further analysis, deferment, or
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.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
Unit
Team
NCS
NCS
NCS
NCS
ICS
ICS
ICS
CCS
ISR
ISR
ISR
CIO
ITSM
ITSM
InfoSec
Network
Core Server Infrastructure
Core Infrastructure Applications
Service Desk
Service Desk
Network and Desktop Services
CMS/Web/EdTech portfolio
Application Services
Production Support
CAM, RES, STU, FIN portfolio
Enterprise Architect
Incident Management
Problem Management
15. ITSM
16. PMO
January 7, 2015
Notes
Manager or Communications
Team Lead (rotation)
SLA Management
PMO
Version 4.0
Page 36

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.
January 7, 2015
Version 4.0
Page 37

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 Owners Responsibilities
The change Owner is:
Accountable to the Change Manager for carry out changes as defined in the McGill IT Change
Management Procedures Guide.
Ensures the Change Management process is followed for building, testing and implementing the
change.
Responsible for all issues and inquiries for the changes under his management.
Accountable for the successful implementation of the change.
Ensures active involvement of appropriate technical groups and other stakeholders during
planning.
Manages the resources used to build, test and implement changes, working with other technical
teams when required.
Provides additional information regarding the change when requested by the Change Manager.
Participates in the Post Implementation Review process.
Performs the initial impact and risk assessment of the change, to assist the applicable change
authority in accepting and classifying the change.
Service 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 SMs 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 RFCs execution, status and
outcome.
The Service Managers 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.
January 7, 2015
Version 4.0
Page 38

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 Requestors Responsibilities
The Change Requester provides:
A clear description and a valid case for implementation.

A well planned method for implementing the change
A suitable blackout plan.
A risk and impact analysis of the change.
A communications plan that provides alerts to all stakeholders of potential impact to services.
Completed documentation required for the change.
Participation in meetings concerning the change. The CR may call and conduct such meetings to
advance the accuracy of the RFC.
Develop a test plan to demonstrate the quality and utility of the change.
With the Change Owner and Change Implementer present the RFC to the CAB
Updates the RFC as required and requested.
Change Implementer
The Change Implementer follows the Change management Process for submitting an RFC under
the supervision of the Change Owner. The Change implementer will follow the plan as outlined
in the RFC that was built by the Change Owner and the Change Requestor.
Change Implementer Responsibilities
The Change Implementer:
Responsible for implementing the approved change as outlined by the approved

implementation, testing and back out plans.
Communicates with stakeholders and colleagues to ensure that the change is on time and any
cross unit support is available as planned.
Participates in planning for the change.
Participates in risk and impact assessment.
Participates in building the RFC and testing the change.
Participates in post-implementation testing, change validation and back out activities
Following Implementation, Updates Change Record and sets Status accordingly
Provides updates on the status of the change to Change Owner, the Change Manager and the
CAB as required.
January 7, 2015
Version 4.0
Page 39
January 7, 2015
Version 4.0
Page 40

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 units 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 units senior staff will do the risk analysis of the change category that is based on the
probability that the change could fail either during implementation or post implementation.
The unit will have done an impact assessment on the effect of the change in both how it
changes service if successfully implemented and the damage it may cause should it fail. The
analysis should include who is affected, how, how many users, the length and complexity of a
back out, and the costs associated. See Risk and Impact section.
Requestors (RFC Submission) Role and Responsibilities:
The requestor must select from NCS Motion a category that best fits his or her change.
Choosing lesser categories to avoid scrutiny or effort is forbidden.
The requestor will have done the analysis for the change in question to ensure that it fits the
general criteria. When necessary, given special circumstances, the requestor will set the impact
at a level higher than the categorys predefined impact. The requestor cannot arbitrarily lower
the impact level. This is to ensure adherence to the standards set by his respective unit.
Exceptions can be made with the approval of the Change Manager, the CAB or the units
director as necessary.
January 7, 2015
Version 4.0
Page 41

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.
January 7, 2015
Version 4.0
Page 42

Change Categories and RFC Processing
Each Unit must create a list of
Change Tasks and tag each with
one of four impact change
categories.
Task list use and maintenance

Create/edit
Task list
Start
Select Task that

best fits the
change
Abbreviated
view of the RFC
submission
process
Found it?
NO
NO
Confer with unit

managers, the
CM and the CAB
as required
The CM or the CAB may challenge
the Task chosen as not matching
the work described.
Yes
Task
matches work
described?
Yes
NO
Task has
correct impact
level?
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.
Yes
Continue with
RFC submission
January 7, 2015
Version 4.0
End
Page 43

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
January 7, 2015
Version 4.0
Page 44
Impact Level
Minimum Lead Time Required

Before Approval
Between Approval and

Implementation
Approval
Authority
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
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 endusers 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.
January 7, 2015
Version 4.0
Page 45

[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.
January 7, 2015
Version 4.0
Page 46

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).
RFC Submission and Processing Cycle
Friday
Saturday
November 21
Sunday
22
Monday
23
Submit Major or
Significant RFC on
Friday before
5:00 PM
Wednesday
25
Pre-CAB
Pre-CAB
Revision Period
Revision Period
Thursday
26
CAB meeting
______________
POST-CAB
29
30
December 1
Significant:
Major: Earliest
Earliest time (10:00

AM)
time (5:00 AM)
OK Significant changes
OK Significant & Major
27
Post-CAB
Revision Period
Note: for Major
extends into Friday
Revision period
begins
28
Tuesday
24
Figure 4
January 7, 2015
Version 4.0
Page 47

Process Metrics
Change management metrics provide indicators of the processs effectiveness and efficiency. These are
divided into three general categories disposition (status), lifecycle (tracking time spent in the process)
and outcome (results and effects of the implementation). These metrics will be automatically collected
by IT Services Motion. There will be a monthly report generated based on these numbers.
KPI Disposition
Disposition Metrics
The disposition refers to the various states and characteristics of the RFC. This set of KPIs describes the
outcome of the implementation of the change plan. It will help to identify areas improvement in how
RFCs are planned as executed.
Metrics for disposition
Description
# Submitted by impact category
Report the number of RFCs submitted for all change types

Delegated, Minor, Significant, Major, Emergency and Expedited.
This basic metric is the foundation for other KPIs.
% Approved
Most RFCs will be approved. The contrasting items to this metric

are the rate of rejection or cancellation.
% Rejected
Though rare, some RFCs will be rejected because they either fail
to meet process guidelines or conflict with other work.
% Canceled
Reason for the cancellation must be provided. Possible reasons

for cancelling are that:
% Implemented with no
Problems
January 7, 2015
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
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.
Version 4.0
Page 48

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.
January 7, 2015
Version 4.0
Page 49

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

to approval
This is the time from the

submission of the RFC till the
time it is approved by the CM
(with or with the CAB).
Identify bottlenecks in the approval process

or lack of due process (too fast). Either
poses risk to IT services.
Avg. time approval to

scheduled time
This is the time from approval

of the RFC to its scheduled
time.
Identifies inadequate delay between the

approval process and the implementation.
This can compromise preparedness and
proper communications among technical
teams and stakeholders. This can be
compared to timelines established via
baseline or policy.
Avg. Time scheduled

to close out
This is the time between the

scheduled time and the RFCs
close out.
Identifies inadequate attention to

monitoring and RFC record updates when
done too quickly. When prolonged it may
cause loss of relevant information events
and conditions can be forgotten.
Avg. Total time

Submission to close
Total lifecycle of the RFC.
This is an indicator of process efficiency.

Delegated changes should have a short
lifecycle in the process while Major changes
should have long cycles in the process.
Aberrations or trends away from the norm
(established McGill IT baseline) can be
discovered via these metrics.
January 7, 2015
Version 4.0
Page 50

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 (sysoper.ncs@mcgill.ca 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.
January 7, 2015
Version 4.0
Page 51

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.
January 7, 2015
Version 4.0
Page 52

Appendix A: Creating an RFC
the instructions provided to create an RFC. By hovering (dont click) the mouse over RFC tab, as shown
in the illustration below, you can select Create RFC from the list.
Once you have selected Create RFC, you will be ready to select the change task appropriate for your
RFC. IT Services Motion will remember the unit and team that you belong to and will display the task
list for your team. Should the list displayed not be your teams list you may change it by using the pull
down list that appears at the right top corner of the task list menu.
Once the correct team name appears in the window the change task menu for your team will be
displayed on the page.
Select the 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.
January 7, 2015
Version 4.0
Page 53

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.
January 7, 2015
Version 4.0
Page 54

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.
January 7, 2015
Version 4.0
Page 55

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).
January 7, 2015
Version 4.0
Page 56

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.
January 7, 2015
Version 4.0
Page 57

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).
January 7, 2015
Version 4.0
Page 58

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.
January 7, 2015
Version 4.0
Page 59

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.
January 7, 2015
Version 4.0
Page 60

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.
January 7, 2015
Version 4.0
Page 61

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.
January 7, 2015
Version 4.0
Page 62

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.
January 7, 2015
Version 4.0
Page 63

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 stepby-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.
January 7, 2015
Version 4.0
Page 64

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 steps 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.
January 7, 2015
Version 4.0
Page 65

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.
January 7, 2015
Version 4.0
Page 66

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 preimplementation 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.
January 7, 2015
Version 4.0
Page 67

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

Select all that apply for withdrawing (Cancelling) the RFC.
RFC was
Implemented?
(attempted)
Start
No
Yes
Backed out?
Yes

The state of the software /hardware has changed and the plan is no longer
viable in its current form
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: ______________________________________________
Why?_______________________
___________________________
Ticket #: _________
Brief Description:______________
____________________________
____________________________
No
Caused an
incident?
No
Close
Yes
Select all that apply:
Deviated from plan
Did not achieve objectives
Partially implemented
Exceeded implementation
window
Note:
If any is selected
then the
Implemented with
Exception = true
Add implementation
Notes
Flow for RFC close by requestor
January 7, 2015
Version 4.0
Page 68

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 state of the software /hardware has changed and the plan is no longer viable in its current
form
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.
January 7, 2015
Version 4.0
Page 69

Exception
a) Deviated from plan
b) Did not achieve
objectives
c) Partially
implemented
d) Exceeded
Implementation
Window
Description
The RFC plan was not followed- e.g. steps omitted, added or taken out
of order.
The intended purpose for the change was not met did not have the
expected results.
One or more aspects of the change were not implemented may or
may not have resulted in executing the backout plan.
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.
2.
3.
4.
Cancelled
Rejected
Implemented OK
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.
6. Exception
Occurred
5. Backed
out
possible
Backed out
No
Occurred
Possible
Implemented with Exception
No
No
Occurred
Final status
Caused Incident
January 7, 2015
4. Incident
Version 4.0
Possible
Page 70
January 7, 2015
Version 4.0
Page 71

Using IT Service Motion to Close the RFC
the instructions provided to close an RFC. By hovering (dont click) the mouse over My Stuff tab, as
shown (below) and select either My Open RFCs or My group open RFCs.
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.
January 7, 2015
Version 4.0
Page 72

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.
January 7, 2015
Version 4.0
Page 73

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
Testing and Validation

Recommendations
Definition
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.
Significant
Moderate
to high
risk level.
Minor
Low to
moderate
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.
The potential for disruption is small or

limited to a very small number of users.
The change may require short service
disruptions.
Delegated The change is fairly transparent to users

Low risk
level.
Standard
Risk is
negligible
or zero.
and rarely requires service disruptions.

When disruptions are necessary they are
of very short duration and limited to a
small number of users.
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
Test environment (lab or test server) to
validate the solution (functional: did
the change work correctly?)
What-if analysis to understand the
Explicit
implementation
plan
impact on
existing infrastructure
Detailed implementation plan may be
required
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.
Testing will have been done on a test case.

Testing is not required for each change. These
changes are template quality.
No user or service impact. Examples

include adding individual users to services,
No testing is required and does not fall under
and Standard configuration changes such
the change management process.
as passwords. No service disruptions are
expected.
January 7, 2015
Version 4.0
Page 74

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
Probability that both types of errors will occur for the same change is:
= P + P
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)
January 7, 2015
Version 4.0
Page 75

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).
Major Consequences
(open ended)
Major
Degree
of
Damage
Significant
Number of people affected
Minor
Delegated
Standard
Request
Fulfillment
January 7, 2015
Version 4.0
Page 76

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
January 7, 2015
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
Version 4.0
Page 77

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.
January 7, 2015
Version 4.0
Page 78

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.
January 7, 2015
Version 4.0
Page 79

Appendix E: CAB and ECAB Membership by Role
Name Unit Team

1.
NCS
InfoSec
2.
NCS
Network
3.
NCS
Core System Infrastructure
4.
NCS
Core Infrastructure Applications
5.
ICS
Service Desk
6.
ICS
Network and Desktop Services
7.
CCS
CMS/Web/EdTech portfolio
8.
ISR
Portfolio Management
9.
ISR
10.
ISR
Systems Management &

Integration
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
ECAB
Notes
Member
Team Lead rotation
Portfolio Managers rotation
Note: Roles with the ECAB Member checked are part of the ECAB.
January 7, 2015
Version 4.0
Page 80

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.
January 7, 2015
Version 4.0
Page 81

McGill IT Services Change Management Process Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

McGill IT Services Change Management Process Guide

Uploaded by

Copyright:

Available Formats

McGill