Get documents about "Change Management Process Itil
W
Description
Change Management Process Itil document sample
Document Sample
Process, Policy and Procedure
Documentation
Change Management
Version 1.3
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 1 of 65
Preamble
This document outlines examples of the policies, processes and procedures you need to have in
place to implement Change Management in your organisation. It not only covers the process as
recommended by ITIL but information your support system provider will need and information
your people will need.
It is the combination of people, processes and technology that will get you over the line in the
end not just processes alone!
To make this document complete in terms of how work would flow into and out of Change
Management we have covered some areas of other ITIL processes. Mainly:
Problem
Release & Deployment
Service Level Management
The idea behind the document is that you take the work commenced here and amend it to suit the
unique requirements of your organisation. ITIL is a framework and open to interpretation so if it
makes sense for you to do something differently to what we have outlined here then feel free to
do so.
Once you have updated the document, your support system provider can use it to configure the
system to underpin your processes. Your staff can also use it to understand how the process will
work in your environment and how it will be monitored and reported against - it defines the
goalposts. Why not involve staff in the job of amending this document to suit your environment -
after all, involvement breeds acceptance.
Good luck on the journey and don‟t forget that if you want buy in from your people you need to
communicate, communicate, communicate, every step of the way!
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 2 of 65
Implementing Change Management
Steps to Implementation
Step 1
Gain Senior Management approval/buy in for the implementation. If this is not forthcoming, it is
going to be extremely hard (almost to the point of not worth trying) to implement.
Step 2
Appoint a Process Owner, Process Manager & CAB Members. These may or may not be full
time positions depending on the size of the organisation. Sample role statements for these
positions may be found in the documentation.
Step 3
Commence a staff awareness campaign (remember – communicate, communicate,
communicate). Ensure all IT staff are ITIL trained and knowledgeable. A big enabler in
implementing ITIL processes is having a common understanding amongst staff of the
terminology used and the relationships between processes.
ITIL Foundation certification has advantages but is not mandatory – there are many ITIL
awareness programmes available that would suffice.
Step 4
Document your policies, processes & procedures – use this document as a template.
Step 5
Define the roles and responsibilities for all parties involved so they are clear on what it is they
need to do. Sample Role Statements are included in this document.
Step 6
Workshop the documentation with the Change Management Team and the CAB until consensus
is reached.
Step 7
Configure your support system to underpin the processes as outlined in your documentation and
define your reports.
Step 8
Decide on a launch strategy – should it be overt or covert
Step 9
If overt, communicate to the stakeholders
awareness campaigns
email
newsletters
through team meetings
focus on individual teams needs
Step 10
Go live!
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 3 of 65
Document Control
Document Versions
Date Version Person Brief Summary of Change
Changing
26/05/08 1.0 Iain Maitland Document Commenced
29/11/08 1.1 Iain Maitland Update to ITIL v3
02/02/09 1.2 Iain Maitland CAB Agenda & Steps to
Implementation Added
13/02/09 1.3 Iain Maitland Final read - slight adjustments and
amendments throughout
Document Location
The document is located at: H:\ITIL Process Docs
Document Approval
Authorising Officer Name Signature/s Date
Process Owner Iain Maitland
Change Manager Dave Tice
Document Owner Adam McMahon
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 4 of 65
Table of Contents
Document Control ............................................................................................................... 4
Table of Contents ................................................................................................................. 5
Change Management Scope ................................................................................................ 6
Basic Change Management Process as Defined by ITIL ................................................... 8
Change Management at HDAA ......................................................................................... 9
Change Management Process Description (HDAA) .......................................................... 10
Inputs & Outputs of Change Management ....................................................................... 11
Change Management Policies ............................................................................................. 12
Policy Statements ............................................................................................................... 13
Change Risk Assessment ..................................................................................................... 20
Change Categorisation Matrix ........................................................................................... 22
Pre-approved Standard Changes ....................................................................................... 23
Minor Changes – Authorised by Change Manager .......................................................... 24
CAB Membership ................................................................................................................ 25
Emergency CAB Membership ............................................................................................ 26
CAB Approvals .................................................................................................................... 27
Change Status....................................................................................................................... 28
Change Resolution Codes.................................................................................................... 29
Change Procedural Documentation ................................................................................... 30
Change Procedures Flowchart ............................................................................................ 31
Change Procedures Flowchart Description ........................................................................ 32
1.0 Raise and Record an RFC ............................................................................................ 33
2.0 Change Assessment Procedure ..................................................................................... 36
3.0 Standard Change Procedure ......................................................................................... 37
4.0 Urgent Change Procedure ............................................................................................ 38
5.0 Change Approval .......................................................................................................... 41
6.0 Change Development ................................................................................................... 43
7.0 Change Review............................................................................................................. 45
8.0 Change Closure ............................................................................................................ 47
Change Management Responsibilities - RACI Matrix....................................................... 48
Change Management: Critical Success Factors & Key Performance Indicators .......... 49
Change Management - Critical Success Factors (CSF‟s) .................................................. 50
Change Management - Key Performance Indicators (KPI‟s) ............................................ 51
Change Management Reporting ........................................................................................ 54
Change Management Roles ................................................................................................ 56
Process Owner (IT Director) .............................................................................................. 57
Change Advisory Board (CAB) Member ........................................................................... 59
Change Manager (IT Manager) .......................................................................................... 60
Change Initiator .................................................................................................................. 62
Change Implementer .......................................................................................................... 63
Change Management - Customer Satisfaction Measurement ......................................... 64
Change Advisory Board Agenda ........................................................................................ 64
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 5 of 65
Change Management Scope
This document seeks to provide standardised methods and procedures to meet the change
management requirements supporting HDAA‟s operations. The business processes outlined in
this document meet industry best practice as defined by the IT Infrastructure Library (ITIL) as
customised to comply with HDAA‟s unique circumstances.
‘Change’ can be broadly defined as the process of requesting, analysing, approving, developing,
implementing and reviewing a planned or unplanned change within the IT infrastructure. The
process begins with the completion of a Request for Change (RFC) either manually or through
the Support System. It ends with the satisfactory implementation of the change and the
communication of that change to all interested parties.
Some Changes arise as a result of Problems, but many Changes can come from proactively
seeking business benefits such as reducing costs or improving services. The goal of the Change
Management process is to ensure that standardised methods and procedures are used for efficient
and prompt handling of all Changes, in order to minimise the impact of Change-related Incidents
upon service quality, and consequently to improve the day-to-day operations of the organisation.
The purpose of Change Management is to ensure that all changes are controlled, including the
submission, analysis, decision-making, approval, implementation and post implementation of the
change.
At HDAA, Changes that arise as a result of a problem will primarily be initiated by a support
specialist while Changes that are requested by the HDAA business units will be reported to the
Service Desk for an RFC to be raised through the support system. Alternatively, business driven
change can be requested through the support system web portal.
This document covers the daily operational aspects of Change Management. It defines process
flow, policy, KPI‟s and work procedures. It also identifies reporting requirements and the HDAA
roles and responsibilities for the process.
Related Processes
Problem Management
Configuration Management
Release Management
Ownership
The IT Director is the Process Owner
The IT Operations Manager is the Change Manager
All IT Team Leaders are responsible for ensuring the Change Management
Process is followed in their respective areas of responsibility.
Distribution
All IT staff members
Business System Owners
CAB Members
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 6 of 65
In this document we have used the term “Service Desk Analyst” to represent the first level
support staff and the term “Support Specialist” to represent staff providing higher levels of
support outside of the Service Desk (2nd level, 3rd level etc.)
Value to the Business of Change Management
Reliability and business continuity are essential for the success and survival of any organisation.
Service and infrastructure changes can have a negative impact on the business through service
disruption and delay in identifying business requirements, but Change Management enables the
service provider to add value to the business by:
Prioritising and responding to business and customer change proposals
Implementing changes that meet the customers‟ agreed service requirements while
optimising costs
Contributing to meet governance, legal, contractual and regulatory requirements
Reducing failed changes and therefore service disruption, defects and re-work
Delivering change promptly to meet business timescales
Tracking changes through the service lifecycle and to the assets of its customers
Contributing to better estimations of the quality, time and cost of change
Assessing the risks associated with the transition of services (introduction or disposal)
Aiding productivity of staff through minimising disruptions due to high levels of
unplanned or „emergency‟ change and hence maximising service availability
Reducing the Mean Time to Restore Service (MTRS), via quicker and more successful
implementation of corrective changes
Liaising with the business change process to identify opportunities for business
improvement.
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 7 of 65
Basic Change Management Process as Defined by ITIL
Change
Required
Raise & Record
Change Request
Assess Change
Approve/Reject
Change
Coordinate Change
Implementation
Review Change
Close Change
End
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 8 of 65
Change Management at HDAA
A Change is
Required
1.0 Raise & Record RFC
A change is initiated when a
Request For Change (RFC) is
logged in the Support System
2.0 Change Assessment
The RFC is filtered and if
approved then prioritised and
categorised
3.0 Standard Change
Is it a Standard
Yes These changes have prior
Change?
approval and can be
implemented without invoking
the full Change process
No
4.0 Urgent Change
The ECAB will approve an
Urgent Change in most
Is it an Urgent
instances. Where this is Yes
impractical, the IT Director Change?
(or Change Manager in his
absence) can authorise the
change
No
5.0 Change Approval
The appropriate CAB
members will review and
approve the change. However,
minor changes can be
approved by the relevant
Change Manager.
6.0 Change Implementation
The change is built and then
implemented through release
and deployment according to
the RFC
7.0 Post Implementation
Review
All Changes will undergo a Post
Implementation Review by the
relevant authority
8.0 Change Closure
Update the Change Record
within the support system, file
supporting documentation and
close
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 9 of 65
Change Management Process Description (HDAA)
Activity Description
1.0 Raise and Change Management is initiated when a Request For Change (RFC) is
Record RFC logged in the Support system. The RFC may be logged by the customer
through the web portal or may be raised by an IT staff member.
2.0 Change The RFC is filtered (accepted yes/no), assessed for risk, prioritised
Assessment (Emergency, High, Medium, Low) and categorised (Standard, Minor,
Significant, Major or Urgent) by the applicable Change Facilitator. The
RFC may need to be referred to the Business representative or an IT staff
member for more information before progressing.
3.0 Standard Change Standard Change Procedures are procedures that have the official, prior
approval of the Change Advisory Board (CAB). They may therefore be
implemented immediately, without the need for any further assessment or
approval. See Standard Change Table
4.0 Urgent Change Follow the Urgent Change Procedure. The Emergency Change Advisory
Board (ECAB) will approve urgent Changes.
5.0 Change All changes require the appropriate level of approval (based on the
Approval priority and category) before they are entered into the Forward Schedule
Of Change (FSC). The CAB is the primary body charged with
responsibility for change control, however the Change Manager is
authorised to approve Minor Changes without reference to the CAB.
Standard changes are changes that have prior approval from the CAB and
can be implemented without further approval.
The relevant CAB members will approve all changes categorised as
significant or major:
Change approval will be automated through the Support System.
6.0 Change The change is built and then moves for implementation to the Release and
Implementation Deployment process in accordance with the RFC and any special
instructions applicable to the change.
7.0 Change Review Prior to closure, the relevant authorised officers will review all Changes.
8.0 Change Closure Update the Change Record within the Support System, file all supporting
documentation and close the RFC.
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 10 of 65
Inputs & Outputs of Change Management
Scope
This section lists all the relevant inputs and outputs to the process.
Inputs
Process Inputs
Requests for Change (RFC‟s)
CMDB Information (Change impact analysis on CI‟s)
Outputs
Output Objective Description
Closed Changes These are the Changes that have been formally closed
following implementation & review.
Forward Schedule of Information on when changes are to be implemented
Changes (FSC) will be held in the FSC
CAB minutes and Documented outcomes from CAB meetings
actions
Change Management Regular reports outlining performance for Change
Reports Management
Failed Changes Should a failed change require further analysis and
investigation; a new Request For Change will be raised
in the Support System so the work can be recorded and
allocated
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 11 of 65
Change Management Policies
Scope
This section contains all the policy statements that form the foundation of the Change
Management Process.
Each policy is described in terms of:
Policy statement
Reason for policy
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 12 of 65
Policy Statements
Change Management Process Policy
Title Policy
Policy Statement One IT Change Management Process will be utilised
throughout HDAA.
The IT Change Management Process will seek to
implement best practice as defined by the IT
Infrastructure Library (ITIL) as customised to
HDAA‟s circumstances.
Reason for Policy To ensure consistency and quality of IT services
delivered to customers, while minimising change-
related incidents/problems and change related service
unavailability.
Process Owner Authority Policy
Title Policy
Policy Statement The Change Management Process Owner (IT
Director) will be accountable for the entire IT Change
Management Process within HDAA and has the
authority to:
Develop policies and procedures pertaining to the
process
Appoint staff to any position within the process
In conjunction with the CAB members, hold the
right to veto any decisions made by other
participants in the process
Enforce compliance with the process
Reason for Policy Provides a single point of accountability for the IT
Change Management Process across HDAA.
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 13 of 65
Change Compliance Policy
Title Policy
Policy Statement All employees will comply with the policies and
procedures developed by the Change Management
Process as contained in this document.
Any exceptions require approval by the Change
Advisory Board.
Reason for Policy Provides a consistent set of processes and procedures
required to minimise the impact of change-related
incidents and improve day-to-day operations.
Urgent Change Policy
Title Policy
Policy Statement A change is categorised as „Urgent‟ if:
It is prioritised as an emergency
Is unplanned and unforseen
Is necessary to resolve or prevent a Priority 1 or
2 incident/problem; or
Is necessary to prevent disruption (or further
disruption) to the production environment; or
Has been previously deemed as „Urgent‟ by the
Change Advisory Board (CAB)
Reason for Policy To enable Change Management to deal with Urgent
Changes quickly without having to sacrifice normal
management controls.
Standard Pre-approved Change Policy
Title Policy
Policy Statement Standard Changes are:
documented, common changes that follow an
established path; and
have prior approval from the CAB
RFC‟s are required to be logged and assigned, and
can then be carried out in accordance with the
approved Standard Change Procedure (see Approved
Standard Changes)
Reason for Policy To prevent the Change Management Process from
being bogged down in common or reoccurring
changes, without having to sacrifice change controls.
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 14 of 65
Change Advisory Board Policy
Title Policy
Policy Statement The ‘Change Advisory Board (CAB)’ members are
charged with the primary responsibility to approve
changes.
Change approval can be granted electronically via the
Support System thus allowing formal face-to-face CAB
meetings to be kept to a minimum. CAB meetings will
be scheduled monthly.
CAB members will be appointed by the various
Business Owners and the Process Owner (IT
Director). Core members will consist of:
Business System Representatives
IT Director (process owner)
IT Manager (process manager)
Business Unit Representatives
IT Team Leader as required (normally the
Technical System Owner)
The CAB‟s core responsibilities are to:
Assess RFC‟s referred to the CAB for approval
Review and document Standard Change types for
pre-approval
Periodically review the effectiveness of the Change
Management Process and identify opportunities for
improvement
All CAB meetings are to be minuted and records
maintained for a minimum period of 3 years
Reason for Policy Provides the standards required for the Change
Advisory Board (CAB) function.
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 15 of 65
Change Prioritisation Policy
Title Policy
Policy Statement Every RFC will be allocated a priority that will
determine the speed at which it is approved and
deployed. The criteria used will be the urgency of
the need for a solution along with the business
impact of not implementing the change.
The Change Requestor may choose an initial priority
but Change Management is ultimately responsible for
assigning this priority. The priority of the RFC ideally
should be decided in collaboration with the initiator
and, if necessary, with the Change Advisory Board
(CAB); but it should not be left to the initiator alone,
as a higher priority than is really justified may result.
All RFC‟s submitted at HDAA will have a priority
assigned in accordance with the Change Priority
Matrix.
Reason for Policy To establish common guidelines and standards for the
prioritisation of any Request for Change (RFC).
Change Categorisation Policy
Title Policy
Policy Statement Every RFC will be categorised according to the
change complexity and resources required, including
people, money and time to complete the change.
The change category will determine the level of
authorisation required for a change.
All RFC‟s submitted at HDAA will have a category
assigned in accordance with the Change
Categorisation Matrix.
Reason for Policy To establish common guidelines and standards for the
categorisation of any Request for Change (RFC).
Change Approval Policy
Title Policy
Policy Statement All Changes will be approved by the relevant
approval officer/s electronically through the Support
System. Change approval is based on the change
category as follows:
Standard Changes – are documented changes that
are pre-approved by the CAB.
Minor Changes - may be approved by the Change
Manager.
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 16 of 65
Title Policy
Significant and Major Changes - under normal
circumstances, these will be approved electronically
by the relevant Change Advisory Board (CAB)
member/s.
Urgent Changes – authorised by the ECAB
members
Reason for Policy Ensures that the authority required to perform a
change is understood by the relevant parties.
Change Communication Policy
Title Policy
Policy Statement Changes that are under the control of Change
Management will be communicated to the necessary
customers as appropriate.
Reason for Policy To ensure that all planned changes have been
communicated to the customers that may be impacted
by the change
Failed Change Policy
Title Policy
Policy Statement Failure of a Change is deemed as such if the results of
the change are not successful and the Change Manager
determines it has failed after consulting with the
Change Initiator and the Change Implementer.
A failed change may result from any of the following:
One or more incidents reported subsequent to the
change
The change must be backed out for any reason
The change was not implemented according to
schedule
Reason for Policy To minimise failed changes and any related impacts to
the business
Change Testing Policy
Title Policy
Policy Statement Any Request For Change (RFC) requires successful
completion of testing before being released to the
production environment.
Reason for Policy Ensures that any changes are tested prior to being
released.
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 17 of 65
Testing Exceptions in Urgent Change Process Policy
Title Policy
Policy Statement Any Request For Change (RFC) requires successful
completion of testing before being released to the
production environment. The exception to this is an
Urgent change, where the nature of the change is so
critical that testing will delay the process. In this
instance the ECAB can approve an exception to
normal testing
Reason for Policy Ensures that any Urgent change not tested has the
required approval.
Forward Schedule of Changes Policy
Title Policy
Policy Statement A Forward Schedule of Changes (FSC) will be
maintained within the Support System at HDAA.
The FSC contains details of all the Changes approved
for implementation and their proposed
implementation dates.
The implementation date will be agreed with the
customer and their business unit. Once agreed, the IT
Service Desk will communicate to the user
community at large any planned additional downtime
arising from implementing the Changes, using the
most effective methods available.
Reason for Policy Communicate planned changes, identify potential
change conflicts, impact and risk analysis.
Reporting Policy
Title Policy
Policy Statement Change Management metrics and management
reports will be regularly reviewed and provided to
the CAB, Management and Customers in accordance
with outlined procedures and agreements.
Reason for Policy Assessing the efficiency and effectiveness of the
Change Management process
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 18 of 65
Post Implementation Review (PIR) Policy
Title Policy
Policy Statement A Post Implementation Review (PIR) will be
conducted for each change undertaken at HDAA.
The PIR process is designed to collect and utilise the
knowledge learned throughout the change to
optimise the delivery and outputs of future changes.
The review will be conducted at the weekly IT Team
Leaders meeting and the content will vary depending
on the success factor for the change, any
incidents/problems that may have been encountered
because of the change, and the category of the
change.
Reason for Policy To gain information and understanding with which
to improve based on reviewing changes. A
successfully completed Post Implementation Review
(PIR) will be used in process evaluation and
continuous process improvement.
Change Management Policy – Process Review Policy
Title Policy
Policy Statement At the Process Owner‟s discretion, regular reviews
will be conducted. The reviews will focus on the
process consistency and repeatability as well as Key
Performance Indicators (KPI‟s).
Results are communicated with the Change
Managers, Change Coordinators, Change Advisory
Board (CAB) members, and management as
appropriate
Reason for Policy Maximise process benefits and reduce costs.
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 19 of 65
Change Risk Assessment
All change requests should undergo a risk assessment before being submitted. The focus should
be on identifying the factors that may disrupt the business, impede the delivery of service
warranties or impact corporate objectives and policies. The relevant risk is the risk to the
business service. Changes require thorough assessment, wide communication and appropriate
authorisation by the person accountable for that business service.
Each change should be assessed in terms of:
the likelihood that the risk(s) will occur (probability)
the consequence to HDAA should the risk(s) occur (impact)
The following matrix will be used to enable requesters to determine a risk category when raising
a Request for Change (RFC).
Change Impact/Risk Categorisation Matrix
High Impact High Impact
Low Probability High Probability
Risk Category: 2 Risk Category: 1
Change Impact Low Impact Low Impact
Low Probability High Probability
Risk Category: 4 Risk Category: 3
Probability
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 20 of 65
Change Priority Matrix
In the change management process, the priority (or urgency) is determined by how quickly a
change is required.
One of the following priority codes will be allocated within the support system to every RFC -
the priority field will be a mandatory field within the system:
Change Priorities
Priority Priority Definition
Emergency A change that, if not implemented immediately, may
put life at risk or may leave HDAA open to an
unacceptable risk - for example, applying a security
patch or urgent virus definition upgrade.
High A change that is important and must be implemented
asap - for example, an upgrade in line with new
legislation requirements.
Medium A change that should be implemented soon to gain
benefit from a changed service - for example,
between version upgrades to a service.
Low A change that is not pressing but would be
advantageous - for example, a “nice to have” addition
to a system or service.
Change Service Levels
The following table sets out the service level targets applicable for each change priority type:
Service Level
Priority Target Target
Implementation Implementation
Time (Hours) Success Rate (%)
Emergency 8 90
High 16 90
Medium 80 80
Low 120 80
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 21 of 65
Change Categorisation Matrix
Scope
The change priority (see priority matrix) indicates how quickly a change should be implemented.
The change category is a measure of the size of the change‟s impact on users, the business, or the
IT infrastructure. For example, does the change affect one user, a department, or every user
within the organisation? Does the change involve updating a single switch, or is it a complete
overhaul of the network? The answers to such questions determine the category of the change.
Categorisation will be used to determine the level of authorisation required for a change.
The Change category field within the Support System will be mandatory and all Changes will be
categorised as one of the following:
Change Categories
Category Category Definition Approval
Urgent To be used in conjunction with a change that has Emergency Change
an Emergency priority only and will follow the Advisory Board (ECAB).
urgent change procedure.
Major Will have impact on a very high percentage of Change Advisory Board or
HDAA users or a business-critical system. The HDAA Board of Directors
change may be new technology or a
configuration change and would likely involve
downtime of the network or a service.
Significant Affects a relatively high percentage of users. The Change Advisory Board
change is a non-standard change, such as a new
product or network changes, and may involve
downtime of the network or a service.
Minor Affects a small percentage of users and risk is Change Manager
less because of IT‟s experience level with the
proposed change.
Standard Affects the smallest percentage of users and has Pre Approved by CAB
a set release process.
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 22 of 65
Pre-approved Standard Changes
Scope
Changes that are categorised as „Standard‟ are pre approved by the Change Advisory Board.
The following table outlines those changes that have been pre-approved for inclusion as a
standard change:
Standard Change Category (Changes Pre-Approved)
Service Area Device Type of Change
LAN Patch Panel Port patching for configuring devices
to relevant LAN outlets.
LAN Hub / Switch Port Changes
Hardware PC Replace monitor, mouse, keyboard,
cd, dvd.
Server Support Server Replace hot swappable drive
Applications Support Software Reinstall on PC
Telephony Telephone System Voice Mail Messages
On-line Services Internet Reboot modem
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 23 of 65
Minor Changes – Authorised by Change Manager
Scope
The Change Manager within IT Services can approve changes that are categorised as „Minor‟.
The following table outlines those changes that are included in this category.
Minor Change Category (Change Manager Approved)
Service Area Device Type of Change
LAN Patch Panel Replace Patch Panel
LAN Hub / Switch Replace Hub or Switch
Server Support Server Increase memory, Increase disk
capacity
Applications Support Software Update Virus Definitions
Telephony Telephone System Move extension
On-line Services Internet Replace modem
Hardware PC Upgrade Memory
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 24 of 65
CAB Membership
Scope
The Change Advisory Board (CAB) is a body that exists to approve Changes. CAB members
should be chosen who are capable of ensuring that all Changes affecting their area of
responsibility are adequately assessed from both a business and a technical viewpoint. To
achieve this mix, the CAB needs to include people with a clear understanding of the business
needs, as well as the technical development and support functions.
At HDAA it is not necessary to hold face-to-face CAB meetings for each change request. Most
of the assessment referral process will be handled electronically via the Support System. Only in
very complex, high-risk or high-impact cases will a formal CAB meeting be necessary.
Otherwise, meetings will be held once per month. These meetings will be used to provide a
formal review and sign-off for pre-approved Standard Changes, a review of any outstanding
Changes, and to discuss any impending major Changes. A standard agenda will be used for these
meetings (see standard CAB agenda).
The following table outlines the CAB members at HDAA:
CAB Members
Business Unit Member Contact Email Address
Number
Executive Alan Hull 9986 1988 alanh@hdaa.com.au
davidb@hdaa.com.au
Finance David Byron 9986 1987
christ@hdaa.com.au
HR Chris Thompson 9986 1983
davidg@hdaa.com.au
Enquiries David Gilmour 9986 1982
annew@hdaa.com.au
Sales Anne Wilson 9986 1976
rond@hdaa.com.au
Business Unit 1 Ronald Dio 9986 1943
stevien@hdaa.com.au
Business Unit 2 Stephanie Nicks 9986 1966
janderson@hdaa.com.au
Business Unit 3 Jon Anderson 9986 1944
iainm@hdaa.com.au
Information Iain Maitland 9986 1932
Technology Services
davet@hdaa.com.au
Information Dave Tice 9986 1933
Technology Services
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 25 of 65
Emergency CAB Membership
Scope
When major Problems arise that require an urgent change, there may not be time to gain full
CAB approval. It is therefore necessary to identify a smaller group with authority to make
emergency decisions. Such a body is known as the Emergency Change Advisory Board (ECAB).
This is intended to ensure that the composition of the CAB will be flexible; in order to act
quickly when urgent changes are proposed. It will also ensure that the composition of the ECAB
will provide the ability to make appropriate decisions in any conceivable eventuality.
ECAB Members
Business Unit Member Contact Number Email Address
alanh@hdaa.com.au
Executive Alan Hull W: 9986 1988
M: 0415 666 037
davidb@hdaa.com.au
Finance David Byron W: 9986 1987
M: 0415 666 034
annew@hdaa.com.au
Sales Anne Wilson W: 9986 1976
M: 0415 666 036
iainm@hdaa.com.au
Information Iain Maitland W: 9986 1932
Technology Services M: 0415 666 038
davet@hdaa.com.au
Information Dave Tice W: 9986 1933
Technology Services M: 0415 666 039
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 26 of 65
CAB Approvals
Scope
All changes categorised as „Significant‟ or „Major‟ require approval from the relevant CAB
authorised officer/s.
If more than one Business Unit is affected by a change then approval is required from the
authorised officer (or the nominated secondary officer) from each Business Unit. The IT
Manager is also required to authorise „significant‟ and „major‟ changes. Change approval will be
undertaken electronically through the support system.
The following officers are authorised to approve changes for their respective Business Areas:
Significant & Major Change Approval – Authorised Officers
Business Unit Authorised Officer Secondary Officer
Executive Alan Hull Richard Davies
Finance David Byron Justin Hayward
HR Chris Thompson Paul Rodgers
Enquiries David Gilmour Ian Gillan
Sales Anne Wilson Don Henley
Business Unit 1 Ronald Dio Cass Elliott
Business Unit 2 Stephanie Nicks Denny Doherty
Business Unit 3 Jon Anderson Nancy Wilson
Information Technology Dave Tice Christine McVie
Services
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 27 of 65
Change Status
Scope
The status of a change reflects the current position in its lifecycle.
All Change Requests logged in the Support System will have the relevant status applied at each
stage of its progression toward closure. The „Status‟ field in the Support System will be a
mandatory field.
Status Codes
The following status codes will be used for changes logged at HDAA:
Status Codes
Change Status Category Explanation
Open This is the system default when a RFC has been
logged but no action has yet been taken.
With Customer This status is applied when awaiting some further
information from the customer to complete the RFC
Awaiting Authorisation Set when the RFC is fully completed, prioritised and
categorised and is awaiting approval from relevant
authorised officer/s.
Authorised Where RFC is approved and build or preparation
action is underway. The proposed implementation date
will appear in the FSC
Backed Out Where the change has been unsuccessful at release and
has been backed out.
Resolved Where the change has been implemented through
release and is awaiting review. A resolution code will
be applied at this stage.
Closed Indicates that the change has been implemented and
reviewed. Where applicable the appended problem and
any related incident/s would also be closed. The
resolution code will flow through to the closure code.
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 28 of 65
Change Resolution Codes
Scope
To facilitate reporting against completed changes, a change resolution code will be applied in the
support system when the change record is resolved.
Resolution Codes
The following change resolution codes will be used at HDAA:
Resolution
Resolution Code Explanation
Cancelled Implementation not completed for policy/initial
approval reasons or where the requestor cancels the
change.
Rejected Where a significant or major change was not approved
by the relevant CAB member/s and a decision was
made not to proceed with the change.
Failed Implementation not completed, or backed out, due to
technical failure.
Implemented with A change related „problem‟ has been formally
problems identified and is currently unresolved.
Implemented No outstanding change related „problems‟ have been
formally identified.
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 29 of 65
Change Procedural Documentation
Scope
This section documents the relevant procedures to be followed in managing changes to the
HDAA computing infrastructure.
The workflow involved is graphically presented in the following flow chart which identifies the
activities required in order to ensure that changes are being handled in the correct manner and
within the timescales relevant to the business:
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 30 of 65
Change Procedures Flowchart
Change
Required
1.0 Raise & Record RFC
2.0 Change
Assessment
Standard
Yes 3.0 Standard Change
Change?
No
4.0 Urgent Change Urgent
Yes
Change?
No
5.0 Change
Approval
6.0 Change
Implementation
7.0 Post
Implementation
Review (PIR)
8.0 Change
Closure
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 31 of 65
Change Procedures Flowchart Description
Activity Description
1.0 Raise & Record Change Management is initiated when a Request For Change (RFC) is
RFC logged in the Support system.
2.0 Change The RFC is filtered (accepted yes/no), prioritised (Emergency, High,
Assessment Medium, Low), risk assessed and categorised (Standard, Minor,
Significant, Major or Urgent) by the applicable Change Facilitator. The
RFC may need to be referred to the Business Unit representative or an IT
staff member for more information before progressing.
3.0 Standard Change Standard Change Procedures are for Changes that have the official, prior
Procedure approval of the Change Advisory Board (CAB). They may therefore be
implemented immediately, without the need for any further assessment or
approval. See Standard Change Table
4.0 Urgent Change Urgent changes are those that have a priority classification of
Procedure „Emergency‟ and will be authorised by the ECAB. Urgent changes will be
fast-tracked through the Change Management process.
5.0 Change All changes require the appropriate level of approval, which is based on
Approval the priority and categorisation, before they are entered into the Forward
Schedule Of Change (FSC). The CAB is the primary body charged with
responsibility for change control, however the Change Manager is
authorised to approve Minor Changes without reference to the CAB.
CAB approval is determined by the specific change under consideration.
It is composed of:
Business System Owner/s applicable to the change
IT Change Manager
IT Team Leaders (the Technical System Owners)
Change approval will be automated through the Support System.
6.0 Change The change is built and then implemented through the release &
Development deployment process in accordance with the RFC and any special
instructions applicable to the change.
7.0 Change Review Prior to closure, the relevant authorised officers will review all Changes.
8.0 Change Closure Update the Change Record within the Support System, file all
documentation and close the RFC
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 32 of 65
1.0 Raise and Record an RFC
Scope
The procedure begins by raising a RFC within the Support System. This can be done either by an
IT officer directly within the Support System or by a Business Unit representative through the
Support System‟s Web Portal.
All RFC‟s requested through the web portal will be forwarded to the Service Desk in the first
instance, the Service Desk will perform an advisory function for business driven change,
assisting requestors to adequately plan, document and support the change request.
Procedures
Activity Sub Description
Activity
1.1 1.1.1 The need for a change may be initiated as a result of a problem or
Raise RFC Business or to satisfy a business need which would be initiated by a Business
Problem Unit representative or by the Board of Directors.
related
Change? If related to a problem go to 1.1.2
If related to a business need go to 1.1.3
1.1.2 Where identified as the result of a problem the relevant support
Problem specialist will log the RFC in the Support System.
Related
Change The status field will default to „open‟ and a unique change request
number will be allocated to enable future tracking.
Append the problem ticket to the RFC along with any electronic
documentation relating to the change and go to 2.0 Change
Assessment
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 33 of 65
Activity Sub Description
Activity
1.1.3 Where a business unit representative initiates the change, the
Business initial request will be communicated to the Service Desk via the
Related Support System web portal utilising an on line RFC form.
Change
The status field will default to „open‟ and a unique change request
number will be allocated to enable future tracking. The change
request number will be automatically sent via email to the change
requestor through the Support System.
Once received at the Service Desk, the Service Desk Analyst will
filter the request and decide whether there is enough information
to proceed or not. This screening process is not concerned with the
validity or approval of the change request, but determines whether
a decision to authorise or deny the change can be made based on
the information at hand and any references made by the initiator.
This screening process should include:
A reality check to ensure that the RFC is appropriate. Because any
user can request a change, it means that requests might be
generated that are:
Not relevant to the IT change management process.
Not detailed enough.
Not fully understood as to their implications.
Not completed correctly due to the change initiator‟s lack of
knowledge of the change management process.
In summary, the process for requesting a business related change
consists of the following steps:
The change initiator creates and submits an account of the
change needed.
A screener (Service Desk Analyst) determines whether there is
sufficient information present in the RFC for it to proceed.
If sufficient information is not present, the screener calls or
returns the request to the initiator with an explanation or
request for further information
This cyclical process results in an authorised, screened request
ready for entry into the change assessment procedure or a
request that is deemed inappropriate and is unauthorised.
If authorised to proceed, go to 1.1.4
If not authorised, confirm decision with the Change Manager and
go to 1.1.5
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 34 of 65
Activity Sub Description
Activity
1.1.4 The Service Desk Analyst will append any electronic data
Ensure all supporting the RFC within the Support System.
required
information is If a “standard change” which is pre-approved go to 3.0 Standard
present Change
If other than a “standard change” The Service Desk analyst will
then escalate the RFC to the Change Manager for further
processing. Go to 2.0 Change Assessment.
1.1.5 If the Change is not accepted, the reasons will be explained to the
Communicate change initiator. If the representative accepts these reasons then
with initiator this will be documented within the support system and no further
action will be taken. Resolve the change - set the status to
„Resolved‟ and set the resolution code to „Cancelled‟ - go to 7.0
Review Change
If the business unit representative does not accept the reason for
rejection, then the request will be escalated to the Change
Manager for a decision. The Change Manager may discuss the
request with CAB members or convene a CAB meeting for final
determination.
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 35 of 65
2.0 Change Assessment Procedure
Scope
This procedure covers the initial assessment including setting the risk, priority and category of
the Request for Change.
Procedures
Activity Sub Activity Description
2.1 2.1.1 The RFC should arrive with the risk assessment determined by
Risk/Priority Set Risk & the business unit representative (see Impact/Risk matrix).
Priority
The Change Manager then determines the initial priority of the
RFC in regards to its urgency.
With the organisation‟s best interest in mind and taking into
consideration any policies and/or service level agreements the
Change Manager will assess the RFC and apply the most
appropriate priority code (see change priority matrix).
Go to 2.2
2.2 2.2.1 The Change Manager determines the category of the RFC in
Category Set Category regards to its impact on IT or the business (see change category
matrix). The category that is applied will determine the
appropriate approval process to be taken.
If any further information is required at this stage, contact the
change initiator. If information is not forthcoming immediately,
set the status code to „With Customer‟ until the information is
received. If documented in an electronic format append the
information to the RFC within the Support System.
Once all information is present, set the status code in the
Support System to „Awaiting Authorisation‟
Go to 2.2.2
2.2.2 If it is determined to be a Standard Change that has been
Determine miscategorised at the Service Desk go to 3.0 Standard Change
relevant Procedure
approval
procedure If an Urgent Change go to 4.0 Urgent Change Approval
Otherwise go to 5.0 Change Approval
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 36 of 65
3.0 Standard Change Procedure
Scope
A standard change is a change to the infrastructure that follows an established path, is relatively
common, and is the accepted solution to a specific requirement or set of requirements. The
crucial elements of a standard change are:
The tasks are well known and proven.
Authority is given in advance by the CAB.
The change process can usually be initiated by the Service Desk.
Budgetary approval is typically preordained or within the control of the
initiator.
Standard changes are automatically approved and move straight to the change implementation
phase of the change management process. Because the types of changes that have been pre
approved as standard changes are known to have a low impact on the environment and are a low
risk to it, they do not need to be reviewed again by the CAB or even the Change Manager. This,
however, means that care must be taken during the initial screening to ensure that a change
request that has been categorised as standard is, indeed, one of the pre approved change types.
See “Pre-approved Standard Changes” for a list of standard changes in use at HDAA.
Procedures
Activity Sub Activity Description
3.1 3.1.1 Once the initial category is determined to be standard then verify
Check and Is change that the change is included on the Pre-approved Standard
Authorise listed as Changes list.
standard?
If included select “standard” for the category from the drop down
list in the Support System and go to 3.1.2
If not included go to 2.2.1 and reassess the change category or
request that this change type be added to the standard change list
through the Change Manager and CAB.
3.1.2 The change is approved within the Support System and the status
Authorise is changed to „Authorised”.
Go to 6.0 Change Development
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 37 of 65
4.0 Urgent Change Procedure
Scope
Urgent changes are those that have a priority classification of “Emergency”. The urgent change
procedure is an accelerated process that follows normal Change Management to the extent that
time constraints permit. Urgent changes need to be implemented quickly - for example, to
prevent a potential security breach or fix a business-critical application.
Time constraints allow only limited testing and require that normal processes, controls and
approval be bypassed. Urgent changes must be approved through the Emergency Change
Advisory Board (ECAB).
The ECAB is smaller than the regular CAB, and is able to meet or be available at short notice.
The ECAB must be empowered to make quick decisions and must have the full authority to
approve or deny urgent changes.
See „Emergency CAB Membership‟ table for ECAB members.
Procedures
Activity Sub Activity Description
4.1 4.1.1 When a change is given a priority of “Emergency‟ it is
Approval Convene immediately categorised as an Urgent Change.
ECAB
In this instance, a meeting of the ECAB will be convened
with the purpose of reviewing the change to ensure that an
emergency situation exists.
If a meeting is unrealistic at short notice then approval
through phone hook-up or through other electronic means
may be sought.
Go to 4.1.2
4.1.2 If Urgent category is endorsed go to 4.1.3
Category If Urgent category is not endorsed go to 2.2.1
endorsed?
4.1.3 When an Urgent Change is endorsed, the ECAB will
Planning & authorise the change in the Support System and determine the
Communication best implementation plan. Status code is changed to
“Authorised”
All IT staff will be notified of the Urgent Change.
The Service Desk team leader (in conjunction with the IT
Manager) will be responsible for regular communication (both
within IT and with the affected business unit/s) regarding the
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 38 of 65
Activity Sub Activity Description
on-going status of the change. Communication is very
important in an emergency situation.
Go to 4.2
4.2 4.2.1 The change is added to the Forward Schedule of Change
Develop Build change (FSC).
Development work will commence immediately with the
urgent change given priority over all other change requests in
the system.
The Change Manager will be responsible for coordinating the
build and applying the relevant level of resources to ensure
the change is ready for release asap.
A suitable back-out plan will be developed and agreed with
the ECAB.
Go to 4.3
4.3 4.3.1 Best practice suggests that all changes be tested unless there is
Test Is there time for no time to do so. The level of testing to be undertaken for the
testing? urgent change (if any) will be determined by the ECAB.
If testing is approved go to 4.3.2
If it is decided to proceed without testing go to 4.4
4.3.2 If testing successful go to 4.4
Undertake If testing unsuccessful go to 4.3.3
Testing
4.3.3 Inform ECAB and, if approved, rebuild the change.
Go to 4.3.1
4.4 4.4.1 Once built the urgent change will be scheduled for release at
Release Implement the most suitable time. The ECAB will have final approval for
Urgent Change the implementation timing.
Go to 4.4.2
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 39 of 65
Activity Sub Activity Description
4.4.2 If the change worked, change the status to „Resolved‟ and
Did change apply resolution code - go to 7.0 Change Review
work?
If the change did not work, go to 4.4.3
4.4.3 Back-out ECAB is notified and back-out plans are implemented – status
change is changed to „Backed Out”. If ECAB agrees a more thorough
approach is taken with the change build.
Rebuild change and go to 4.3.1
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 40 of 65
5.0 Change Approval
Scope
The change approval procedure is determined by the change category. Minor changes are
approved by the relevant IT Change Manager and are listed in the “Minor Changes – Authorised
by Change Manager” section of this document.
Significant and Major changes will require approval from the relevant approval officers listed in
the “CAB Approvals” section of this document.
Procedures
Activity Sub Activity Description
5.1 5.1.1 If categorised as minor go to 5.1.2
Change Is the change
Category categorised as If categorised as significant or major go to 5.1.3
minor,
significant or
major?
5.1.2 The Change Manager will approve and change status in the
Minor Change Support System to “Authorised”
Go to 5.2
5.1.3 Escalate the fully completed RFC to CAB members according to
Significant the “CAB Approval matrix”. The RFC will be sent to the relevant
and Major approval officers through the Support System which will
Change determine the required approvers by a combination of the
„category field‟ and „business units affected‟ field. The Change
Manager and the IT Director will be included in the approval
process.
The RFC will be monitored for approval/rejection on a regular
basis. If a response is not forthcoming in a timely manner or it is
known that the CAB member is not in the office, the RFC will be
sent to the secondary approval officer as listed in the „CAB
Approvals‟ section of this document.
Go to 5.2
5.2 5.2.1 If no go to 5.2.2
Approval Is the RFC
Authorised? If yes go to 5.2.3
5.2.2 The requestor will be notified that the Change has been rejected
RFC Rejected by the CAB. Update the status code in the Support System to
„Resolved‟ and the resolution code to „Rejected‟.
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 41 of 65
Activity Sub Activity Description
Go to 7.0 Change Review
5.2.3 Once the RFC is authorised by the relevant CAB members,
RFC change the status code within the Support System to
Authorised „Authorised‟.
Go to 6.0 Change Development
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 42 of 65
6.0 Change Development
Scope
After an RFC has been approved (using the appropriate approval body based on its priority and
category), it moves into the change development phase. This phase is concerned with the steps
necessary to plan the change, develop the deliverables of the change (for example, developing
new code or configuring new hardware), and the handover to the Release & Deployment
Management process for the deployment of the change into the production environment.
The speed with which the steps in this process are executed can vary greatly. A small, emergency
change may be planned, developed, and implemented in minutes. A change involving
deployment of a new software package to all of HDAA may take months in the development and
deployment phases.
Activity Sub Activity Description
6.1 6.1.1 The forward schedule of change within the Support System will
Schedule Enter in FSC contain only minor, significant, major, and emergency changes.
Standard changes are not considered to have an impact on other
types of change and therefore will not be included.
The Change Manager enters the proposed date and time for the
change implementation into the FSC once the RFC is approved.
In some cases, it may only be possible to enter a tentative date
for the change. This is the case for large changes that require a
long development phase. As the development project progresses
and the development project plan is drawn up and tracked, the
date when the change will be implemented in the production
environment becomes more definite and the FSC can be updated
at this stage.
Go to 6.2
6.2 6.2.1 After the change has been scheduled, the change manager needs
Ownership Appoint to identify and appoint a change owner to manage the change
Change Owner through the development and release process and into the
production environment. The change owner may in some cases
be the change initiator.
The RFC will be assigned within the Support System to the
appointed IT Group who will take ownership of the change
request.
Go to 6.3
6.3 6.3.1 Development work will commence on the requested change.
Develop Build change
The change owner will be responsible for coordinating the build
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 43 of 65
Activity Sub Activity Description
in line with the timeframe set out in the FSC. Should delays
occur these will be discussed with the Change Manager and the
FSC updated if required.
Commence building change.
Prior to testing, a suitable back-out plan will be developed and
agreed with the Change Manager.
Go to 6.4
6.4 6.4.1 All changes will be tested unless there is no time to do so
Test Undertake (Urgent Changes only). The level of testing to be undertaken will
Testing depend on the type of change.
Test Change.
Go to 6.4.2
6.4.2 If testing successful go to 6.5
Was testing If testing unsuccessful go to 6.4.3
successful?
6.4.3 Inform Change Manager and, if approved, rebuild the change.
Testing
Unsuccessful Go to 6.3.1
6.5 6.5.1 Once built, the change will be released through the Release &
Release Implement Deployment Management process. Check FSC date is still
Change applicable, set status code to „Scheduled‟.
Go to 6.5.2
6.5.2 If yes, change status to „Resolved‟ and apply resolution code
Was release within the Support System. - go to 7.0 Change Review
successful
If no go to 6.5.3
6.5.3 Back-out The Change Manager is notified and the back-out plan is
change implemented – status is changed to „Backed Out”. If Change
Manager agrees the change will be rebuilt.
Amend FSC, rebuild change and go to 6.3.1
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 44 of 65
7.0 Change Review
Scope
Following release and deployment into the production environment or, as in the case of a
standard change, just a deployment into production, a review should be conducted to establish
whether the change has had the desired effect and has met the requirements of the original
Request for Change (RFC).
In most cases, this review process will be brief. For a standard change, e.g. where the effect has
been small and the results relatively predictable, the review process may be limited to checking
that the user has the desired functionality from the change.
All changes within the system will be reviewed at the weekly IT Team Leader meeting.
Activity Sub Description
Activity
7.1 7.1.1 In order to determine whether the deployed change has been
Monitor Monitor effective and has achieved the desired results, it is necessary
Change in to monitor the change in the production environment. For a
Production small change, this may consist of checking on the desired
functionality (e.g. for a change in Group Policy allowing a
desktop setting to be changed). For larger changes, it might
require the monitoring of network and server information,
performance data, event logs, or response times.
Go to 7.2
7.2 7.2.1 A Post Implementation Review for all changes with a status
Post PIR Meetings of „Resolved‟ will be conducted at the weekly IT Team
Implementation Leader meeting.
Review
Where sufficient monitoring has been completed and the
change meets objectives then it will be approved for closure
at the meeting. Following the meeting, the Service Desk
will set the resolution code to „Implemented‟ and then close
all changes that are approved (see 8.0 Change Closure).
Some changes may have an immediate adverse effect on
users or the network, as evidenced by a large increase in
incidents reported to the Service Desk. In these cases, an IT
Team Leader meeting will be called immediately in order to
decide whether to back out the change or to make other
changes to resolve the situation.
If a decision is made to back out go to 7.2.2 Back Out
If an implemented change has not fully met the objectives
desired for the change, the PIR may determine that backing
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 45 of 65
Activity Sub Description
Activity
out the change is too costly or too risky, or the desired effect
can be achieved (with less expense) by making additional
changes. For example, a service pack or hot fix may be
required to fully implement the functionality of the original
change to the level desired.
In this case, a new RFC should be raised to keep the
production environment running and to achieve the results
originally desired.
The priority of such an RFC needs to be set appropriately:
an emergency change might be required to minimise the
time during which the adverse effects of the original change
are experienced.
If decided to raise additional change/s - go to 7.2.3
“Additional Change Required”
7.2.2 The back-out plan associated with the change is
Back Out implemented – set resolution code to „Fail‟. Go to 8.0
Change Closure
If it is determined that the change is still required a new
RFC will be raised and the failed change will be appended
within the Support System.
7.2.3 Set resolution code to „Implemented With Problems‟ and
Additional close RFC (see 8.0 Change Closure).
Change
Required Raise new RFC and append existing RFC within the
Support System.
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 46 of 65
8.0 Change Closure
Scope
The Service Desk will close all RFC‟s.
This procedure checks that the change record is fully updated and a resolution/closure code is
assigned.
Activity Sub Description
Activity
8.1 Set the status of the RFC to „Closed‟ within the Support System.
Close the
Change The Support System captures the time and date of closure and the
resolution code automatically populates into the Closure Code
field.
When a change is closed there will be an email notification sent to
the initiator informing them that their change has been closed and
the closure code applied. Any appended problems/incidents will
also be closed at this time. For significant, major and urgent
change categories the relevant CAB members will be advised
automatically through email that the change is now closed. Closed
changes will be discussed at the monthly CAB meetings.
All relevant electronically held documentation will be appended to
the RFC within the Support System (if not already appended).
Any hard copy documentation will be filed using the unique RFC
record number from the Support System as the reference guide.
Note: As part of the quality assurance function, the Support
system will auto email 20% of business driven change
requestors with a quick satisfaction survey. See Customer
Satisfaction for details of questions and rating system.
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 47 of 65
Change Management Responsibilities - RACI Matrix
Scope
RACI is an accountability and communication matrix that is designed to help eliminate
confusion over roles and responsibilities.
The acronym „RACI‟ stands for Responsible, Accountable, Consulted and Informed.
This section contains the RACI matrix for the HDAA Change Management Process.
Change Management RACI Matrix
Process Service Service Support IT Team Change Initiator CAB ECAB
Procedure Owner Desk Team Desk Specialist Leaders
Leader Analyst Manager
CM Process i.e. A R I I R R I C C
planning, design,
roles,
communication,
training, adoption,
compliance,
reporting,
continuous
improvement
1.0 Change C/R C/R C/R R/C A R
Initiation
2.0 Change I I R R/C A C
Assessment
3.0 Standard A/C/I R/I R/I R/C
Change Procedure
4.0 Urgent I C I R R/C A/C I I C
Change Procedure
5.0 Change I I C R/C A I
Approval (Minor)
5.0 Change I I C C A/I R
Approval
(Significant &
Major)
6.0 Change I I R/C R/C A/I
Development
7.0 Change C I I R/C A/C
Review
8.0 Change A/R R I I I I I
Closure
Legend
R = Responsible: executes the task
A = Accountable: accountable for final result
C = Consulted: consulted about the task to provide additional information
I = Informed: needs to be kept up-to-date on activities/tasks
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 48 of 65
Change Management: Critical Success Factors & Key
Performance Indicators
Scope
Critical Success Factors (CSF‟s) are the small number of things that need to be done right within
each ITIL process. Key Performance Indicators (KPI‟s) are a set of clearly defined objectives
that have measurable targets and are used to judge the performance against the critical success
factors of an area or a process. Reports against Change Management KPI‟s will be produced for
discussion at IT Team Leader weekly meetings but will be measured monthly.
KPI targets (or a sub-set) will be made available to customers via Service Level Agreements
(SLA‟s) and performance against KPI‟s included in regular customer reports.
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 49 of 65
Change Management - Critical Success Factors (CSF’s)
The critical success factors for Change Management within HDAA will be:
HDAA has a repeatable process for making changes
Changes are made quickly and accurately
Existing services are protected when Changes are being made
Process efficiency and effectiveness benefits are delivered
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 50 of 65
Change Management - Key Performance Indicators (KPI’s)
1. Repeatable Process for Making Changes
KPI Name Definition Data Source Target
Percentage reduction As process matures and Support Gradual reduction
in rejected RFC‟s historical data is collected, System over time as
fewer changes should be process matures.
rejected – especially for Measured
insufficient detail or monthly.
information supplied.
Percentage increase in Changes implemented within Support Gradual
Business Change timeframe documented in the System percentage
Requests implemented Forward Schedule of Changes. increase over time
on time as process
matures.
No unauthorised If the approval process is well Support No unauthorised
changes detected in defined and repeatable, there System changes within
system should be no unauthorised Support
changes entering or within the
system
Reduction in time to As process matures and staff Support Percentage
make Standard become familiar with pre System decrease in
Changes approved standard changes average time taken
average implementation time to process a
will reduce Standard Change
Reports produced on Reports will be produced for Support Reports available
schedule weekly team leader meetings System for meetings 99%
and monthly CAB meetings of time.
2. Make Changes Quickly & Accurately
KPI Name Definition Data Source Target
Percentage reduction If overall process is working Support Gradual reduction
in changes resulting in quickly and accurately System over time as
incidents (including sufficient testing) process matures.
then approved changes should Measured monthly
not cause change related
incidents.
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 51 of 65
2. Make Changes Quickly & Accurately
KPI Name Definition Data Source Target
Percentage reduction Accurate, sufficiently tested Support Gradual reduction
in Changes requiring changes should not lead to a System over time as
back-out back-out being required process matures.
Measured monthly
Reduction in the If process is running smoothly Support Number of
number of urgent with changes implemented System reported urgent
changes within agreed timeframes then changes reducing
requests for urgent changes
should reduce
3. Protect Services When Making Changes
KPI Name Definition Data Source Target
Percentage reduction Successful change should not Support Gradual reduction
in changes resulting in lead to associated incidents or System over time as
incidents to existing problems. process matures.
services Measured monthly
Reduction in both the If changes are implemented to Support Service
scheduled and schedule then there should be System availability
unscheduled service a reduction in service measures
unavailability caused unavailability gradually improve
by changes
Percentage increase in Day to day services will be Support Gradual increase
Changes activated protected the more changes System in changes
(released) outside core are released outside of core released outside
service hours business hours core business
hours
4. Deliver Process Efficiency & Effectiveness Benefits
KPI Name Definition Data Source Target
Improvement in This is the overall rating from Survey Gradual increase
Customer Satisfaction customer surveys conducted Database on overall
Survey feedback on on change closure. customer
change satisfaction each
year as process
matures
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 52 of 65
4. Deliver Process Efficiency & Effectiveness Benefits
KPI Name Definition Data Source Target
Reduction in The more efficient and Support Gradual reduction
percentage of failed effective the process the less System over time as
changes failures process matures.
Measured monthly
Increased percentage Performance against Service Support Performance
of Changes Levels as documented should System targets are met on
implemented on time improve as process becomes an increasing basis
more efficient
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 53 of 65
Change Management Reporting
Scope
This section describes the main reporting requirements of Change Management. These reports
will be used as the basis for management of the process.
By maintaining historical information on infrastructure changes, it is possible to derive measures
that are indicative of the quality of service and the performance of the process.
Reports will be produced for each of the Key Performance Indicators listed above. Other more
detailed reports will be required by team leaders and managers – these reports are listed below.
Summary Of Changes
These reports provide a convenient „snapshot‟ of the performance of a Support Group or overall
performance of the Process.
Reports
Summary of Urgent Changes – provides a list of all changes categorised as
„Urgent‟ for review at weekly team leaders meeting.
Summary of Changes by category: Provides a list of all changes by
category i.e. urgent, major, significant, minor and standard.
Summary of Changes by status for all Support Groups: Provides a list of
all changes and their current status for each Support Group.
Summary of Changes by Support Group: Provides a list of changes
allocated to the change owners in each Support Group.
Summary of Changes by Configuration Item: Provides a list of changes
applied to individual Configuration Item (CI) for month.
Summary of Changes by Priority: Provides a list of changes for each of the
four possible priorities in use (Emergency, High, Medium and Low).
Summary of Changes by Business Unit: Provides a list of changes for each
Business Unit within HDAA.
Measurements in the Reports
Against each item listed in the selected report will be the following metrics:
Number of new changes
Number of changes resolved
Number of changes in breach of SLA (by business unit)
Total time and Average time spent until change is implanted and RFC is
resolved
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 54 of 65
Summary of Effectiveness
These reports are intended to provide an overall view of the effectiveness of Change
Management in a specified period (monthly) by providing aggregates of key metrics against four
perspectives (performance, efficiency, quality & customer satisfaction).
Reports
Summary of Effectiveness of Change Management
Summary of Effectiveness by Support Group
Summary of Effectiveness by Change Owner
Measurement
Performance:
Total number of changes unresolved by status
Total number of new changes logged
Total number of changes resolved
Total number of changes closed
Efficiency:
Total hours spent on change from approval to resolution
Average hours per change from approval to resolution
Quality:
Total changes resolved within SLA by Business Unit
Total changes in breach of SLA
Customer satisfaction:
Percentage satisfaction rating from customer survey on 20% of changes
closed
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 55 of 65
Change Management Roles
Scope
Roles associated with the Change Management Process are defined in the context of the function
and are not intended to correspond with organisational job titles. Specific roles have been defined
according to industry best practice. In some cases, many persons might share a single role; and in
other cases, a single person may assume many roles, or at least more than one role. It is
especially likely that a person will assume different roles with respect to different processes. For
example, the change owner for change management may be the release manager for release
management.
This document provides detailed descriptions of the key roles in the Change Management
Process as implemented at HDAA.
The key roles are:
Process Owner (IT Director)
Change Manager (IT Manager)
Change Initiator (Business Unit staff member or any IT staff member)
Change Implementers (Potentially any IT staff member or 3rd Party)
This document describes each role referred in terms of:
Role profile
Objectives
Responsibilities & Activities
Authority
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 56 of 65
Process Owner (IT Director)
Profile
The person fulfilling this role has the overall responsibility for the integrity of the end-to-end
Change Management Process, for the way in which it functions and develops, and is the Support
System owner. The main role of the Process Owner is to ensure that the design of the change
management process and the underpinning support systems are efficient, effective, and fit-for-
purpose.
The Process Owner will work to ensure integration between the ITIL disciplines and their
process-flows.
In general, the Change Management Process Owner:
Operates with a bird‟s eye view
Has strong process competencies
Can coach and mentor the other participants (Particular the Change Manager
and CAB Members) in the Change Management Process
Understands the business priorities
Possesses at least an ITIL Foundation certificate and preferably an ITIL
Practioners certificate in Release and Control or the ITIL Service
Management certificate
Objectives
Take ownership of the Process to establish process flow, accountabilities &
responsibilities
Quality manage the Process ensuring compliance and continuous
improvement
Ensure there is a balance between the key components of a good Service
Management environment: People, Process, Product & Partners
Responsibilities
Ensuring the Change Management process is fit-for-purpose
Ensuring the Process is followed (eg ensuring CAB meetings are held
regularly and all change activities are reviewed)
Defining the Business Case for the Change Management Process
Ensuring there is optimal fit between people, process, product & partners
Ensure Key Performance Indicators are met
Reporting to upper management
Integration/communication of the process with the HDAA Business Units
Any changes to the Change Management Process
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 57 of 65
Authority
The Process Owner has authority to:
Recruit/appoint staff to positions in the Process
Approve training requests for participants in the Process
Approve changes to the Process or Technology, in particular to integrate ITIL
processes and to resolve conflicts in processes
Enforce compliance with the Process by all participants.
In conjunction with the CAB overrule any change that does not have business
approval, is an incorrect application of the Process or that will have negative
consequences for HDAA‟s services
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 58 of 65
Change Advisory Board (CAB) Member
Profile
The Change Advisory Board (CAB) is the group of people who have the primary accountability
and responsibility for the approval and review of change related activities.
Activities delegated to other participants, such as Standard Change Procedures and approval of
minor RFC‟s by the Change Manager, will be initially approved and regularly reviewed by the
CAB.
Membership
The core members of the CAB are in general:
IT Director (Process Owner)
IT Manager (Change Manager)
Business Unit representatives (one per Business Unit)
Objectives
Assess, control, approve and review all change related activities so as to
minimise the occurrence of incidents and failures and maximise service
availability
Quality assurance and continuous improvement of the change process
Responsibilities & Activities
Assess and approve/reject all significant and major RFC‟s referred by the
Change Manager
Ensure a Forward Schedule (FSC) of Change is maintained.
Advise on project plans and implementations
Periodically meet to review change reports, update Standard and Minor
Change tables and to ratify urgent change procedures
Review the effectiveness of the Change Process in general, identifying and
recommending opportunities for improvement to the Process Owner.
Authority
The CAB has the authority to:
Approve or reject all urgent (ECAB), major and significant change requests
Be informed of any urgent change requests raised
Enforce the Change Management Process
Recommend changes to improve the Process
Review any change related activity
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 59 of 65
Change Manager (IT Manager)
Profile of the Role
The Change Manager reports to the Change Advisory Board (CAB) in regards to the change
management process but ultimately reports to the Process Owner.
The Change Manager is the key coordinator of the change management process. This role
provides input to the filtering of the initial RFC‟s and to the classification of RFC‟s. Minor
requests may be approved and scheduled by the Change Manager, while significant or major
RFC‟s must be referred to the CAB. The Change Manager ensures that an ECAB meeting is
called when a change is categorised as urgent.
Following approval of a change, the Change Manager is responsible for monitoring progress and
ensuring compliance with the change process. The Change Manager also responsible for
identifying post-implementation issues, such as change related incidents, and ensuring changes
are reviewed.
In general, the Change Manager:
Is the key coordinator of the change management process
Has strong process and management skills
Understands both the business side and the technical side of proposed
changes and is able to clearly present this information to the CAB
Ideally, Possesses an ITIL Foundation Certificate and is moving forward to
achieve the Practitioners Certificate for the Change Management process.
Objectives of the Role
Responsible for ensuring the day to day filtering & classification of RFC‟s is
undertaken
Responsible for day-to-day monitoring and management of the change
process
Establish an environment of quality assurance and continuous process
improvement
Responsibilities & Activities
Responsible for ensuring that the Change Management process is being
followed correctly
Filters and classifies all RFC‟s in collaboration with IT staff and returns
incomplete or incorrect RFC‟s to initiator.
Approves/rejects “minor” RFC‟s.
Ensures “significant” and “major” changes are referred to the CAB for
assessment and approval and “urgent” changes are referred to the ECAB.
Ensures that sufficient technical guidance is provided to the CAB to enable its
decision-making.
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 60 of 65
Participates fully in the CAB meetings and carries out delegated tasks.
Liaises with all necessary individuals to coordinate the building, testing and
implementation of changes as per the Forward Schedule of Changes (FSC)·
Assigns change related tasks to appropriate individuals
Is vigilant in the monitoring of all changes from build to testing.
Ensures an adequate Post Implementation Review (PIR) takes place.
Provides any reporting as requested by the CAB or Process Owner
Authority
The Change Manager has authority to:
Enforce compliance with the change process by all initiators, builders, testers
& implementers
Assign approved, change related tasks to appropriate individuals
Report on Key Performance Indicators that have been established.
Escalate any breaches in the process to the CAB and the Process Owner
Recommend improvements to the process and the related technology
Communicate/educate customers and users
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 61 of 65
Change Initiator
Profile
Can be any staff member either in an HDAA business unit or in the IT
Department.
Must possess the technical or business competence to identify the need for
change and to satisfactorily complete an RFC – otherwise should seek
assistance from an IT staff member (the Service Desk can help).
Responsibilities & Activities
Initiating change requests
Satisfactorily completing an RFC, and
Providing all necessary supporting documentation
Provides Input To
Project plan
Assessment and planning of the change
Building, testing and implementing the change
Assessing and reviewing the change
Identifying and resolving change related incidents
Authority
Log and implement Standard Change Procedures
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 62 of 65
Change Implementer
Role Profile
“Change Implementer” is a generic term that refers to anyone assigned by the Change Manager
(with approval of the CAB if required) to carry out a change related activity.
A Change Implementer may be assigned responsibility for one or more aspects of a project plan
such as:
Designing
Building
Testing
Transferring to Production
In general, the Change Implementer:
Must possess the necessary technical skills to carry out the assigned task
Must understand the Change Management Process
Responsibilities and Activities
Complies with the Change Management Process and required authorisations
Carries out the approved and assigned task, in accordance with the project
plan, procedures or specifications
Keeps the Change Manager informed of progress
Updates the Change Record as required
Provides feedback on the implementation in the Post Implementation Review
(PIR) when required
Provides Input To
Project plan
Assessment and planning of the change
Building, testing and implementing the change
Assessing and reviewing the change
Identifying and resolving change related incidents
Authority
Log and implement Standard Change Procedures
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 63 of 65
Change Management - Customer Satisfaction
Measurement
Scope
Since customer satisfaction on changes arising from problem tickets will be measured within the
problem management process, customer satisfaction within the change process will be
undertaken by sampling 20% of customers who have requested a business change.
This will be automated through the Support system.
Questions
When surveying customers, the five questions to be asked are:
How satisfied were you with:
The courtesy of the IT staff?
The technical skills/knowledge of the change builder/s?
The timeliness of the service provided?
The change release?
The overall service experience?
Rating Scale
The rating scale will be based on a 5 point scale:
Very Dissatisfied
Satisfied
Indifferent
Satisfied
Very Satisfied
Reporting
The KPI for customer satisfaction against Change Management will be „90% of staff surveyed
are satisfied or above with the services provided‟. Reports will be produced on a monthly basis
showing the percentage of staff responding „satisfied‟ or „very satisfied‟ to the questions listed
above. Individual reports will be produced for each question and a cumulative report against all
questions will also be produced for KPI reporting.
End Process
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 64 of 65
Change Advisory Board Agenda
Date: xx/xx/xx
The most viable approach for CAB meetings is a combination of regular meetings combined with
electronic automation. If this format is viable then monthly meetings held on a regular basis (e.g.
first Tuesday of each month) would be appropriate. A standard agenda should be used – for
example:
1) Opening of the meeting
2) Apologies
3) Minutes from previous meetings
4) Actions points from last meeting
5) Urgent Changes that may have arisen between this and the previous meeting
6) Failed Changes i.e. where the back-out plan needed to be invoked
7) Status of current Changes (does the status, priority or category need to change?)
8) Status of testing for current changes (verification and validation)
9) Status of release planning activities for current changes, such as training, documentation
readiness and rollback procedures
10) New Requests For Change to be assessed in structured and priority order
11) Changes being implemented without approval from Change Management
12) Any changes to pre-approved schedules i.e. standard or minor changes
13) Post Implementation Review of closed Changes
14) Action points (assign to members)
15) Wins/accomplishments for this period
16) Comments and questions (also on the process for possible process improvement)
17) Closure of the meeting
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 65 of 65
tion Review of closed Changes
14) Action points (assign to members)
15) Wins/accomplishments for this period
16) Comments and questions (also on the process for possible process improvement)
17) Closure of the meeting
668eadd3-a7e9-4ac8-a0b4-504cd82e5888.doc Page 65 of 65
Related docs
