Information Communication Technology (ICT) Service Managementmams.rmit.edu.au/2pj9ct6g0w5l1.pdf · provide an improvement to hardware, ... Information Communication Technology (ICT)

Information and Communications

Technology Service Management

Change Management Process

Final Draft

July 2012

Doc ID <ID>

Version: 0.2

Status: DRAFT / FINAL

Author: Service Management

Information Communication Technology (ICT) Service Management Final Draft

Page 2 of 65 Document: Change_Management_Process_Final_Draft_31July.doc

Author: Candice Walker

Save Date: 02/08/2012

RMIT University

Document Control Printed versions of this document or versions stored elsewhere are subject to change without notice and should be considered ‘uncontrolled’. Please contact the Author to ensure you have the latest version.

Changes to the ‘controlled’ version will not be performed without prior consent from the author and agreed approver. Upon completion of such changes, the revised document will be delivered to all persons listed below.

Document Author

Name Role Contact Details

Candice Walker Senior Manager – Service Improvement

[email protected]

61 3 9925 1002

Revision History

Version Date Comment Editor

0.1 Initial Draft

0.2 31st July 2012 Amend “Expedited” details David Reen

Authorisation

Name Role Area Signature (or email approval to be attached)

Date

Document Distribution

Name Role Area Date

Referenced Documents

Doc ID Doc Title Location Author Version

mailto:[email protected]




Save Date: 02/08/2012

RMIT University

Table of Contents

1 Introduction .................................................................................................................................. 6

1.1 Intent ...................................................................................................................................... 6

1.2 Scope ..................................................................................................................................... 6

1.3 Audience ................................................................................................................................ 6

2 Change management process .................................................................................................... 8

2.1 Process introduction ............................................................................................................... 8

2.2 Process goal .......................................................................................................................... 8

2.3 Process benefits (3P’s X 3C’s) ............................................................................................... 9

2.4 Process scope ...................................................................................................................... 10

3 Process specific definitions ...................................................................................................... 11

3.1 Change types ....................................................................................................................... 11

3.1.1 Normal changes ............................................................................................................ 11

3.1.1.1 Major ......................................................................................................................... 11

3.1.1.2 Significant .................................................................................................................. 11

3.1.1.3 Minor ......................................................................................................................... 12

3.1.2 Standard changes ......................................................................................................... 12

3.1.2.1 Routine ...................................................................................................................... 12

3.1.3 Emergency changes ...................................................................................................... 12

3.1.4 Expedited changes ........................................................................................................ 13

3.2 Risk assessment .................................................................................................................. 13

3.3 Category calculation ............................................................................................................. 15

3.4 Failed change ....................................................................................................................... 15

3.5 Lead-time ............................................................................................................................. 15

3.6 Stakeholder .......................................................................................................................... 16

3.7 Change Advisory Board (CAB) ............................................................................................. 17

ICT Service Management Final Draft

RMIT University

Status: DRAFT

Version 0.1

Document:

Change_Management_Process_Final_Draft_31July.doc Author: Candice Walker Save Date: 02/08/2012

Page 4 of 65

3.7.1 Introduction ................................................................................................................... 17

3.7.2 Purpose ......................................................................................................................... 17

3.7.3 CAB membership .......................................................................................................... 17

3.7.4 ECAB Process and membership ................................................................................... 18

4 High-level process flow ............................................................................................................. 19

4.1 High-level process flow steps ............................................................................................... 20

5 Change management rules........................................................................................................ 22

5.1 Rules for normal changes (major, significant and minor) ...................................................... 22

5.2 Rules for routine changes ..................................................................................................... 24

5.3 Rules for rescheduled changes ............................................................................................ 24

5.4 Rules for emergency changes .............................................................................................. 24

5.5 Rules for closure of changes ................................................................................................ 24

5.6 Rules for unplanned or expedited changes ........................................................................... 25

5.7 Rules for failed changes ....................................................................................................... 25

5.8 Rules for a change to be approved by CAB .......................................................................... 25

6 Continuous process improvement plan ................................................................................... 27

7 Process interface ....................................................................................................................... 28

8 Process measures ..................................................................................................................... 29

8.1 Measures of process effectiveness ....................................................................................... 29

8.2 Measure of process efficiency .............................................................................................. 29

8.3 Contextual measures ............................................................................................................ 30

9 Appendix .................................................................................................................................... 31

9.1 Procedural workflow for Major and Significant changes ........................................................ 31

9.1.1 Major and significant change - procedural workflow steps ............................................. 32

9.2 Minor change process flow ................................................................................................... 38

9.2.1 Minor change procedural workflow steps ....................................................................... 39

9.3 Routine changes procedural workflow .................................................................................. 44


RMIT University

Status: DRAFT

Version 0.1

Document:


Page 5 of 65

9.3.1 Routine changes - procedural workflow steps ............................................................... 45

9.4 Emergency change procedural workflow .............................................................................. 47

9.4.1 Emergency change procedural workflow steps .............................................................. 48

9.5 Glossary of terms ................................................................................................................. 50

9.6 Sample of Change categories and their lead-times .............................................................. 61




Save Date: 02/08/2012

RMIT University

1 Introduction

1.1 Intent

The intent of this document is to communicate the technology based Change Management process at

RMIT University so that all ITS staff may understand and comply with the process as described in this

document.

1.2 Scope

This document provides information on a standardised method of handling changes and modification

to technology systems within RMIT.

It includes:

Process introduction, scope, benefits, definitions

Process flows

Process-based rules

Risk-based category management and lead-time information

Roles and responsibilities of staff involved in the process

A continuous process improvement strategy

Process interface and measures

1.3 Audience

Audience Will read this document to…

Executive Director, ITS Approve the process

Propose and drive amendments to this process

Deputy Directors (or equivalent),

ITS

Endorse the process

Promote compliance to the process and its rules within their

teams

Propose amendments to this process as part of the continual

process improvement strategy

Senior Managers and Team

Leads, ITS

Understand the process-related responsibilities of their staff

Understand the impacts of the process on their local areas


RMIT University

Status: DRAFT

Version 0.1

Document:


Page 7 of 65

Audience Will read this document to…

of work

Empower adherence and compliance with process

Propose amendments and improvements to this process

All Staff in ITS Understand the process and their role within it

Comply with the process and its rules

Understand the impacts of the process on their local areas

of work

Propose amendments and improvements to this process

All University Staff Suggest improvements and amendments to this process as

part of the continual process improvement strategy


RMIT University

Status: DRAFT

Version 0.1

Document:


Page 8 of 65

2 Change management process

2.1 Process introduction

The Change Management process documents the responsibility for providing control over all

technology related changes throughout their lifecycle, while enabling beneficial changes to be made

with minimal disruption to IT services in the production environment.

This process is intended to reduce the number of unscheduled outages and incidents to ITS delivered

and supported services that are related to changes made to the production IT environment. It will also

providea customer focus to the business of managing technology related changes by managing

stakeholder and customer communications.

A change is defined as the addition, removal, or modification of anything that could have an effect on

IT services and includes changes to configuration items and services within the production

environment. A configuration item is identified as, infrastructure e.g. servers, network, applications

databases and so on. A service is made up of a combination of configuration items such as

Enrolment online (EOL), PeopleSoft Campus Solutions and so on.

To be effective, any addition, removal, or modification to infrastructure or business-critical products or

services and its subsequent release must come under the Change Management process. A change

can be reactive to resolve a problem, proactive to remove the possible occurrence of a problem, or

provide an improvement to hardware, software and any underpinning vendor provided services directly

related to the delivery of an ITS managed technology.

2.2 Process goal

The goals of the technology-based Change Management Process are to:

Ensure that standardised methods utilised for efficient and prompt handling of ALL technology-

based changes

Encourage a culture of recording technology changes

Promote detailed and effective impact analysis

Ensure effective stakeholder communication and sign-off

Reduce the number of incidents caused by changes.


RMIT University

Status: DRAFT

Version 0.1

Document:


Page 9 of 65

2.3 Process benefits (3P’s X 3C’s)

The benefit of change management is to prioritise, plan, and protect the IT environment by Checking,

Controlling and Communicating.

Prioritise

Prioritise identified opportunities for business improvements

Validate the priority of proposed changes to proactively provide improved levels of technology

and service to the business.

Plan:

Improved resource management of staff and technology

Cost saving and efficiencies from well-structured and planned changes and releases

Deliver changes promptly to meet business timescales.

Protect:

Reduce the volume and adverse impact of incidents and problems due to quicker and more

successful implementations of corrective changes

Increased productivity through minimised disruptions caused by unplanned or ‘emergency’

changes

By improving assessment of the impact on the business and associated risks

Maximise service availability.

Check:

Ensure the validity of a proposed solution or implementation by conducting, recording and

logging of all checks and balances

Validate the quality, time, and cost of proposed changes before they are incurred.

Control:

Conflict checking empowers the business to release new products, upgrades and

improvements to production in a controlled manner

Controlled workflow empowers proactive planning and prioritisation of work schedules enabling

innovation and growth.


RMIT University

Status: DRAFT

Version 0.1

Document:


Page 10 of 65

Communicate:

Communications to the customer-base, management, staff and the larger University

community ensures a commitment to service improvement while improving the delivery of

service.

2.4 Process scope

This process will encompass all:

Modification and changes to all production databases and applications Delivery or release of

applications and services (server / app based) including mobile applications.

Changes to the underlying infrastructure to support the production environment, including

servers, network (but not test, development, pre-production and sandpit VLANS and so on

Commissioning of test, development, pre-production and sandpit environments. (Note: Once

these environments are live, what occurs within them is not in-scope for change management)

Production-based data centre work

Services or underpinning devices supporting a production service used by students and staff

Modifications and changes to the physical network (but not test, development, pre-production

and sandpit VLANS)

Examples:

o Changes to PeopleSoft Campus Solutions and SAP

o Patch updates

o Implementation of a new server or piece of equipment

o Installation of an additional storage disk

o Deployment of virus definitions as an automated pre-approved change.




Save Date: 02/08/2012

RMIT University

3 Process specific definitions

3.1 Change types

There are three types of changes, Normal, Standard, Emergency

3.1.1 Normal changes

Normal changes are further broken down into risk-based categories as a means of managing and

controlling risk. These categories are,

o Major

o Significant

o Minor

Each of these categories has a specific lead-time and workflow path assigned, and discussed further

in this document.

3.1.1.1 Major

A major change is a change assessed

As a highly complex piece of technological work with or without outages and

that has the potential to cause a major impact to the University in revenue loss or lost

productivity time and

has a high probability of failure to implement successfully

Example: A change raised to conduct maintenance activities on the RMIT network, that includes an

outage to all services on the network, is categorised as a major change. This is due to the severe

impacts that customers will experience, the complexity of the various technologies that are impacted

and the probability of failure, of those services resuming seamlessly.

3.1.1.2 Significant

A significant change is a change assessed

As moderate or mid-level complexity, with or without outages and

has the customer impacts clearly identified and

has a significant to medium probability of failure to implement successfully

Example: An outage to 1 floor of staff or student in a building or outage to staff email at 8 am on

Tuesday morning (since number of staff and students is less at this time of day).


RMIT University

Status: DRAFT

Version 0.1

Document:


Page 12 of 65

3.1.1.3 Minor

A minor change is a change assessed

As low complexity

has a low likelihood of failure and

the consequences of that failure are minimal and

has NO scheduled outage.

Example: A minor configuration change with no service interruption.

3.1.2 Standard changes

These changes are categorised as routine changes, which have the lowest possible risk aspects.

3.1.2.1 Routine

A change assessed

to be of minimal risk and

of the lowest complexity

in addition to being one that has been implemented at least five times in the last six months.

These changes are implemented frequently and have well-documented activity or task lists.

A change can also be categorised as routine on the recommendation of the CAB.

Example: Create DNS entries under RMIT domains and subnets

3.1.3 Emergency changes

These changes are also broken down into the same risk-based categories as a normal change.

However, they are changes implemented urgently to restore a service that has stopped functioning

and is broken. It can also be a preventative change implemented to prevent a service in imminent

danger of disruption due to a recently detected fault or vulnerability.

Risk assessments are still carried out on these changes and they will fall into one of the four

categories above.

Example: The reboot of a server to restart a critical service (on the server) that had stopped working

and was causing file access issues


RMIT University

Status: DRAFT

Version 0.1

Document:


Page 13 of 65

3.1.4 Expedited changes

Any normal change that does not meet its associated category lead-time is an expedited change. The

change is still categorised based on its risk, but due to an urgent need, it cannot wait for the

associated category lead-time prior to implementation. This change is not being implemented to fix a

service interruption (as that would be an emergency change), but is being expedited due to a business

need.

Example: A hardware failure (redundant controller cards in an M9000) that requires an urgent part

replacement to avoid complete loss of service.

3.2 Risk assessment

To determine the category, each change is subjected to a risk assessment and the risk of each

change is assessed against three risk components, which are;

Technical complexity

Likelihood of failure

Consequence of failure

Each of these three components, have seven risk aspects and each aspect is assigned a risk value as

shown in the tables below

1. Technical complexity, which refers to technology-based complexity of a change and factors in

the capability to thoroughly test the change being made to the production environment.

Value Risk Aspect

1. Major complexity without comprehensive test capabilities

2. High technical complexity with comprehensive test capabilities

3. Significant complexity – End-to-end testing not possible

4. Moderate technical complexity – with available testing environment

5. Low complexity – with thorough testing

6. Standard maintenance or operational activity

7. Routine and frequently executed activity of very low complexity.


RMIT University

Status: DRAFT

Version 0.1

Document:


Page 14 of 65

2. Likelihood of failure is indicative of the familiarity of carrying out a particular set of change

related activities.

Value Risk Aspect

1. Solution has not been tried before

2. High possibility of failure

3. Significant possibility of failure

4. Low possibility of failure/has failed previously

5. In case of failure remediation actions are readily available

6. Minimal possibility of failure

7. Repeatable activity (successfully implemented at least five times in six months)

3. Consequence of failure assesses the follow-on impact of a failed change, and adds the

customer focus to the risk assessment criteria.

Value Risk Aspect

1. All of RMIT

2. A Campus

3. Building / Multiple floors

4. Single floor

5. Small groups – up to 40 people

6. Invisible to the customer

7. Not currently utilised by the customer




Save Date: 02/08/2012

RMIT University

3.3 Category calculation

The sum of the risk values will determine the risk category of the proposed change, where the value

ranges between

3 and 7, the category will be major

8 and 12, the category will be Significant

13 and 18, the category will be minor

19 and 21, the category will be Routine

3 4 5 6 7

4 6 8 10 12 14

3 6 9 12 15 18 21

Emergency

Change

Major

Change

Significant

Change

Minor

Change

Routine

Change

3.4 Failed change

A Failed change is one that:

Does not meet its success criteria of the change

Does not achieve its success criteria in the approved change window

Due to unforseen issues was not able to be completed

Causes an incident because of the implementation of the change.

3.5 Lead-time

A lead-time is defined as the latency (or delay) between the initiation and execution of this process.

From the Change Management perspective, this means the minimum amount of time required from

the time a Technical Approver approves the change to its implementation time.

The primary purpose of these lead-times is to enable stakeholders to assess changes and manage

them by mitigating any localised impacts. These lead-times also encompass the communication lead-

time requirements.

The current agreed lead-times are based on business days Monday to Friday.


RMIT University

Status: DRAFT

Version 0.1

Document:


Page 16 of 65

Category Emergency

change

Major change Significant

change

Minor change Routine change

Lead-Time Focus on urgent

service

restoration

15 Business

Days

10 Business

Days

3 Business

days

As soon as Team

Lead/ Technical

approval granted

and in the

designated window

3.6 Stakeholder

A person who needs to be advised about a change that will, or could, have an impact on their area of

responsibility or someone who has a vested interest in the outcome of a change due to an expected

impact or business outcome.

Within the scope of this process, there are two different types of stakeholders, namely;

An Approver: A person who provides documented authorisation of a change to occur

In the stated change window

To the scope identified

At the risk level identified by the Change Category.

A team representative (usually the Team Lead) is required to actively assess and action (approve or

reject with valid reasons) the change.

A Reviewer: A person who has a stake in the outcome of a change or who needs to be kept informed

or notified of a change being implemented. A team representative (usually the Team Lead) is made

aware of the Change, but is not required to action (approve or reject) any task. If however any

concerns are identified with the proposed implementation, the reviewer is required to notify change

management to have the issue addressed




Save Date: 02/08/2012

RMIT University

3.7 Change Advisory Board (CAB)

3.7.1 Introduction

The change advisory board consists of a cross section of representatives from various ITS groups.

It provides multiple perspectives on proposed ITS work to ensure a balance is maintained between

the need for change and the need to minimise inherent risks. The CAB forms an integral part of

the Change Management process.

3.7.2 Purpose

The primary purpose of the CAB is to provide support to the Change Management team and

process. CAB will review, assess and approve or reject changes categorised as Major and

Significant at two different points in the lifecycle of a change.

The first time will be at the planning stage of the lifecycle to seek approval for

Any associated costs

Staff and technology resourcing requirements (for design, build, test and implementation)

Communication and engagement requirements.

The second time will be at the implementation stage of the lifecycle post the stakeholder

management process, where the assessment of the change is based on

Finalised implementation dates and times

Completed testing outcomes

Finalised implementation plans, post verification plans, backout triggers and backout plans

Completed customer communications.

Finalised operational or project-based support arrangements

Complete set of service management support scripts or instruction and documentation

CAB will also retrospectively review Emergency changes.

3.7.3 CAB membership

The CAB quorum consists of 3 members in addition to the chair person, where the membership

consists of

Executive Director – Chair person

Deputy Director – ICT Infrastructure Delivery

Deputy Director – ICT Application Delivery

Deputy Director – ICT Service Management

Deputy Director – Client Computing


RMIT University

Status: DRAFT

Version 0.1

Document:


Page 18 of 65

Deputy Director – Engagement and Planning

3.7.4 ECAB Process and membership

An emergency change requires the approval of the ECAB member prior to implementation. As a

result, the CAB member for the area impacted by the emergency change will need to approve

these changes.

Example: For an emergency change required to clear the logs of a database to ensure its

continued performance levels, the Deputy Director – Application Delivery will sign off the change as

an ECAB member.




Save Date: 02/08/2012

RMIT University

4 High-level process flow

Stake-

holder

Approval

and Review

1 calendar week between final CAB

approval and implementation for Significant

and Major changes

Impleme

ntation

CAB

Major

Change

Minor

Change

(No

scheduled

outages)

Routine

(formerly

known as

Pre-

Approved)

Change

Emergency

Change

Initial

Planning

Planning

CAB

Detailed

Plans

ECAB

Peer/Team/

Technical

Lead Approval

Cha

nge

Man

ager

Nee

d fo

r C

hang

e

Ass

ess

Significant

Change

Minimum Lead-Times

3 Business Days for Minor

10 Business Days for Significant

15 Business Days for Major

Initial

Planning

Implementation

(cannot

commence until

Change has

been fully

approved)

Must have done the change

a minimum of 5 times with

no unexpected impact

Pee

r/T

eam

/Tec

hnic

al L

ead

App

rova

l

Cha

nge

M

anag

er

Rai

se C

hang

e R

ecor

d in

app

rove

d S

ervi

ce M

anag

emen

t app

licat

ion

Was implementation

Successful?

Close Change

YES

Rec

ord

impl

emen

tatio

n ou

tcom

es in

the

appr

oved

Ser

vice

Man

agem

ent a

pplic

atio

n

CAB reviews

Reason for failure

Expedited

Change

NO

4/7/2012

Pee

r/T

eam

/Tec

hnic

al

Le

ad A

ppro

val

DD: to CAB or

Implement

Mus

t inc

lude

DD




Save Date: 02/08/2012

RMIT University

4.1 High-level process flow steps

It is imperative to note that all changes must be logged and authorised prior to implementation in an

RMIT-approved centralised repository or toolset.

The high-level process is as follows:

1. Identify a need for change

2. Raise change in the RMIT approved service management application

3. Assess the change need based on Risk to work out Categorisation of the change

4. Ensure change implementation date is set based on its category lead-time

5. Based on the risk assessed category of the change, take the following category related actions:

o Routine changes will only require the approval of the nominated Technical Team Lead

prior to implementation

o Emergency changes will only require the approval of an ECAB (Emergency Change

Advisory Board) member prior to implementation. If the ECAB member is not available

and a change must be implemented to restore service, then justification to the line-

manager is mandatory. With sufficient justification, the line manager can make the call to

have the change implemented with ECAB approval carried out retrospectively. Post

implementation, this change will be reviewed by CAB to document the root cause of failure

o Expedited changes will generally follow the workflow set out for minor changes as they

still require all approvals as set out in the minor change workflow. At the discretion of the

relevant Deputy Director the change may be implemented prior to a CAB meeting. If this

occurs a CAB Review will be conducted.

o Minor changes will require the detailed plans to be reviewed by

– Technical Approver (Peer or Team Lead)

– Change Manager

– Stakeholder (approvers and reviewers, including the relevant Deputy Director).

o Significant and major changes will require review by:

1. Peer/Team/Technical Lead

2. Change Manager

3. CAB, in the first instance after initial scoping, costing and prioritisation based

on business impact or need, measured against the urgency of the requirement

or need. The CAB will also provisionally approve the scheduled dates.


RMIT University

Status: DRAFT

Version 0.1

Document:


Page 21 of 65

4. On approval by CAB, this change will then be ‘built’ and have its detailed plans

mapped out along with the finalised implementation schedules and dates

5. The detailed plans will then need to be reviewed in sequence by

a. Peer/Team/Technical lead

b. Change Manager

c. Stakeholder (approvers and reviewers)

d. CAB.

6. On approval, the change will be ready for implementation as per the schedule presented to CAB

and stakeholders

7. Once implementation has been completed, the implementer must provide closure by recording

the outcomes of the implementation in the approved service management application

8. If there were any issues because of the implementation, or if the change caused an incident as

result of the failure, or the change was not completed within the approved change window then

the CAB will review the failure reason prior to the closure of the change. If there were no issues

and the change was completed successfully, then the change is closed.


RMIT University

Status: DRAFT

Version 0.1

Document:


Page 22 of 65

5 Change management rules

Set out below are the rules that must be followed for the effective management of technology based

changes in all areas of the ITS production environment.

Environments out of scope for the change management process are excluded specifically, the

development, test, and sandpit environments

5.1 Rules for normal changes (major, significant and minor)

All technology changes must adhere to following business rule requirements, specifically minor,

significant and major changes.

1. A Request For Change (RFC) must be raised in the authorised system or toolset for any technology-

related upgrade, install, un-install, commission, de-commission of products, including software,

hardware, middleware, applications, infrastructure appliances, portals and websites as supported and

maintained by ITS

2. Change requestors must comply with and ensure all changes adhere to the category based lead-

times. These internal lead-times stated in business days are as follows:

a. 15 business days for Major changes

b. 10 business days for Significant changes

c. 3 business days for Minor changes.

3. The category of a change will be determined based on its correlation to the information in the Risk

Assessment section.

4. All changes must be defined by an Impact Statement and this must:

a. Identify the end customer (both staff and student) impacts

b. Identify the service(s) impact(s)

c. Identify both positive and negative impacts during the change window

d. Identify both positive and negative impacts post the change window.

5. All RFC’s must consist of information that is complete and accurate, especially:

a. Impacts

b. Detailed plans

c. Support Information


RMIT University

Status: DRAFT

Version 0.1

Document:


Page 23 of 65

d. Communication information.

All changes are to adhere to the approved Change Implementation Plan and instructions,

including the approved start and end times. These must be in one of three forms:

o Step-by-step instructions

o Run sheets

o Release notes.

6. If a change is liable to go over its designated window, the back-out or contingency options must be

considered and effected. All changes that extend beyond the change window will invoke the Incident

Management Process (by logging an Incident Record). The CAB will review these changes

7. Where a change affects or influences multiple products (including all interfacing applications) or

services, the change is to be implemented during a window that is most mutually agreeable to the

stakeholders and requester.

8. All Stakeholder approvals must be received before a change can be implemented. Any change

implemented without this requisite level of approval will be termed an ‘Unauthorised Change’ and an

explanation will need to be presented before CAB

9. All Implementers, Testers and Support staff must be identified in the change record. The manager of

a resource approving a change is deemed to be allocating that resource to implement the change

10. A Change Approver must approve or reject a Request For Change (RFC) within 12 business hours of

receipt of the Change Request in the Approver’s email

Note: It is the responsibility of the Approver to find a proxy/substitute if they are unavailable – i.e. on

extended leave

11. A Change Reviewer must raise any issues relating to a particular RFC within 12 business hours of

receipt of the Change Request in the Reviewer’s email.

Note: It is the responsibility of the Reviewer to find a proxy/ substitute if they are unavailable – i.e. on

extended leave

12. Changes to process and business rules relating to technology-based Change Management will be

required to be presented to CAB when:

a. The change affects many people

b. It has a business impact

c. It is to be ‘released’ to external parties.

This process will ensure sign-off by all relevant stakeholders, version control, appropriate storage,

and communication to stakeholders.


RMIT University

Status: DRAFT

Version 0.1

Document:


Page 24 of 65

5.2 Rules for routine changes

Certain change activities are categorised as Routine Changes. The frequency and extremely low

complexity, likelihood of failure and consequence of that failure categorises these changes as routine

maintenance activities. To be classified as a Routine Change, they must however meet following

criteria:

1. They must have been done at least five times in a six month period

2. The CAB must approve these activities in advance

3. These routine changes can only be implemented in the agreed and CAB-approved

implementation window

4. They must be linked to the master change that was approved by CAB

5. They must be approved by the nominated Technical Lead (or delegate) prior to

implementation.

5.3 Rules for rescheduled changes

1. The Change Manager must be notified of a change that is to be rescheduled, prior to the

original start time of the change window

2. Rescheduled changes are not required to meet lead-times

3. Rescheduled changes must be re-approved by stakeholders prior to implementation, but do not

require CAB approval, if they have already been to the CAB as part of the original processing of

the change

4. If the rescheduled change is customer impacting, then communications must be sent out to

notify customer of the modified change window.

5.4 Rules for emergency changes

1. All emergency changes must be approved by an ECAB member. In a break/fix situation, the

nominated CAB member will be referred to as an ECAB member.

2. The ECAB member must provide verbal approval for an emergency change to proceed. The

actual change record can be raised retrospectively and the nominated ECAB member must

provide written approval within the approved ITS Service Management application.

5.5 Rules for closure of changes

On the completion of the implementation, the Implementer must update the change record with the actual

outcomes of the change. This must be done within three (3) business days from the implementation end

date and time to accurately reflect the current state of Production. It is the accountability of the Change

Owner to ensure that this action is completed.


RMIT University

Status: DRAFT

Version 0.1

Document:


Page 25 of 65

5.6 Rules for unplanned or expedited changes

A change that is unable to meet its category lead-time must provide a valid business reason or

justification to proceed without meeting its category lead times.

5.7 Rules for failed changes

CAB will review all changes that have failed. This failure must be recorded in the system or toolset as a

Failed Change.

5.8 Rules for a change to be approved by CAB

1. CAB will review all major and significant changes at the planning and implementation phase of

the change lifecycle

2. At the planning phase, the following information must be available in order to receive approval

from CAB to proceed with the (next) planning phase:

The objective, purpose or reason for change

The customer (ARG, SAP, Production Support etc.)

What is the need for this change

What priority does this have to the customer

What are the potential impacts of implementing this change – both positive and negative

during and post the change(if any), including touch points with other apps/ services (e.g.

outage, degraded service while change is in progress)

Proposed change window (planned start date/time and end date/time) and does the change

meet approved category lead-times if implemented on these dates

Is there an outage and if there is to be an outage, potential outage window

A brief description of the actual change including any financial, staff, technology,

communicational and engagement requirements.

3. At the implementation phase the following information must be available to obtain CAB

approval:

The objective, purpose or reason for change

The customer (ARG, SAP, Production Support…)

What is the need for this change

What priority does this have to the customer


RMIT University

Status: DRAFT

Version 0.1

Document:


Page 26 of 65

What are the potential impacts of implementing this change – both positive and negative

during and post the change (if any), including touch points with other apps/ services (e.g.

outage, degraded service while change is in progress)

Firmed and finalised change window (planned start date/time and end date/time) and does

the change meet approved category lead-times if implemented on these dates

Is there an outage and if there is to be an outage, potential outage window

Ensure communication templates that are part of the ICT service status and

communications process are filled in and ready to be sent out

The various teams involved with this implementation

A detailed description of the actual change

A detailed implementation plan

The pre-testing outcomes or plans and list of post verification test plans

Detailed contingency or back-out plans (roll-back, uninstall)

In what situations will they be invoked

What support agreements have been sourced

(e.g. new support agreements with customer, up-skill of current support staff to support

new functionality, helpdesk scripts, existing agreements will continue)

If this information is not available, then CAB has the right to reject this change.

4. CAB will review all failed changes to identify improvement opportunities

5. CAB will review and ratify all proposed routine changes according to the rules stipulated for

Routine changes.


RMIT University

Status: DRAFT

Version 0.1

Document:


Page 27 of 65

6 Continuous process improvement plan

There are two (2) roles in the continuous improvement cycle. These are:

The accountability to ensure process compliance will rest with the Process Owner

The execution of the improvement cycle will be the responsibility of the Process Manager

The Continuous process improvement plan follows a “Plan, Do, Check, Act, Document and Measure”

cycle as identified by ITIL. Non-customer impacting improvements to the process and service

management application are planned, communicated, and implemented at the discretion of the Process

Owner

Plan – Ensure process adherence and documentation are up-to-date

Do – Conduct internal process audits once every six (6) months, followed by an annual external audit

Check –

Internal Audits will check for:

Validity of information in the various fields

Accuracy of implementation windows scheduled vs actual

Accuracy of change implementation – successful vs unsuccessful

External Audit will report on:

Compared results of internal audits

Validate process compliancy

Documentation validity and currency

Make recommendations on identified gaps

Act – Collate the results, publish them and prioritise the feedback suggestions. Design, build and

implement the prioritised improvements

Document – Review and update all relevant documents ensuring prioritised improvements are

captured

Measure – Measure and monitor the process including prioritised improvements.


RMIT University

Status: DRAFT

Version 0.1

Document:


Page 28 of 65

7 Process interface

The diagram below shows how other processes interact with this process via the exchange of

information, and resources in terms of personnel, equipment, and knowledge.

Major incident management: Provides the means of managing and resolving sudden and severe

technology issues, which result in high customer impacts. Resolution might result in temporary work-

arounds or managed known errors.

Configuration management: Provides details on the relationship between components of the IT

infrastructure required to deliver each service, supporting incident resolution and impact analysis.

Knowledge management: Provides the means of ensuring impacts experienced by customers are

handled in a consistent manner through to provision of service-based workarounds to alleviate

customer impacts.

Problem management: Root cause analysis and treatment of the underlying cause of the Major

Incident in order to prevent recurrence or minimise impact in the event of recurrence.

Incident management: The normal Incident Management process is responsible for detecting a

Major Incident and initiating the Major Incident process.

Major Incident Management

Configuration Management

Knowledge Management

Problem Management

Incident Management

Change

Management


RMIT University

Status: DRAFT

Version 0.1

Document:


Page 29 of 65

8 Process measures

8.1 Measures of process effectiveness

The information provided here is used to determine how well this process is achieving its stated goals:

Number of changes approved by CAB – no rework vs. with rework

Number of incidents caused by changes.

Question Measure Trigger/Trend required

How effective are we at raising

changes within lead-times?

An increase in the percentage

(%) of Changes raised within

lead-time

An upward trend of a changes

raised within lead-times

Are we meeting agreed lead-

times?

Number of scheduled vs.

expedited changes per month.

Downward trend of expedited

changes required.

How effective are we at

identifying and logging

repetitive and low risk

changes?

Number of changes by

category.

Upward trend of routine and

minor changes.

8.2 Measure of process efficiency

The information provided here is used to determine how well this process utilises resources to achieve its

goals.

Question Measure Trigger/Trend required

How many Emergency

changes are carried out each

month?

Number of emergency

changes each month by

service type.

Downward trend required.

How efficient are we at

delivering the changes we

have promised customers?

Failed changes vs successful

changes.

Downward trend of failed

changes required.

Number of incidents caused by

changes.

Downward trend required.


RMIT University

Status: DRAFT

Version 0.1

Document:


Page 30 of 65

8.3 Contextual measures

The information provided here is used to measure external factors beyond the scope of this process,

which need to be taken into consideration when monitoring and analysing performance of this process.

Question Measure

How do we rate at logging and

tracking changes?

Total number of changes each

month.

How do we rate at adequately

planning our changes?

Total number of expedited

changes.


RMIT University

Final Draft

Status: DRAFT Version: 0.1

DocRef: TRIM

Document: Change_Management_Process_Final_Draft_31July.doc

Author: Candice Walker Save Date: 02/08/2012

Page 31 of 65

9 Appendix

9.1 Procedural workflow for Major and Significant changes

Major or Significant Change Process Flow

Chan

ge O

wne

rCh

ange

Req

uest

erCh

ange

Bui

lder

Chan

ge T

este

rTe

chni

cal

App

rove

rCh

ange

Man

ager

Stak

ehol

der

App

rove

rs

Chan

ge

Adv

isor

y Bo

ard

Stak

ehol

der

Revi

ewer

sIm

plem

ente

r

Final

1Raise Change

Request

2Conduct Risk Assessment

3Major Or

Significant?

No

12Build Detailed

Implementation and Test (Pre and Post)

Plans

Yes

14Carries out the

documented pre-testing of the

change

8Initial Assessment

of change

9Approved?

10Reviews details of

the change

11Satisfied?

Assist in building the detailed plans

for the change

13Update Detailed plans into record

Yes

15Provide testing

Outcomes/results

17Review details and

lead-time

18Check FSC

19Change Window

Clear for implementation?

30Add Stakeholders

(both approvers and reviewers)Yes

31Approve Task

34Any issues?

No32

Details Ok?Yes

35

Approve Change

33

Mitigate and manage localised

impacts

38Any issues?

36Details Ok?

Yes

37Mitigate and

manage localised impacts

24Assist in resolving stakeholder issues

E

D

D

23Details Ok?

Yes25

Approve at CAB meeting

22Pre-Read changes

on agenda

Yes

41Implement Change in nominated

change window

42Trigger post

verification testing

C

39All approvals

received?

Yes

40Notify Change

owner and change manager

No

47Verify outcomes of

the change

B

48Successful?

49Table for CAB

Review

End ProcessYes

50Record learnings

4Update Description, Impact information

and potential change window information

6Conduct preliminary

conflict check

Description should contain reason for change and a high

level implementation

plan

Impact section should contain information, both

positive and negative relating to impact during

and post the change7

Submit change for initial approval

28Technical

Assessment of all plans

29Approved?

No A

21Table for “Planning”

CAB approval

A

A

B

C

5Ensure appropriate category lead-times

are met

26Initial or final

approval?Planning

Implementation

Assist in building the test plans for

the change

27Authorise change for socialisation,

communication and stakeholder

approval

C

16Update testing

outcomes/results into record

E

20Initial or final

approval?Implementation

Initial/Planning

D

No

46Close change with

appropriate closure code

43

Conduct post verification tests

44

Notify Implementer and Change Owner

of outcomes

45Is back out required?

NoG Yes

G

H

H

No

E

No

E

LegendTasks that can be done in parallel

I

I

On-Page Connector (to avoid cross-over lines)

RMIT University

Final Draft


DocRef: TRIM

Document:


Page 32 of 65

9.1.1 Major and significant change - procedural workflow steps

Step

number

Description – Major and Significant Role

responsible

1. Assess need for change and raise Change Request. ITS support

staff/

Requester

2. Conduct Risk Assessment. Requester

3. Is it major or significant category change?

If yes, go to step 4

If no, exit the process and amend the category as determined by

the risk assessment.

Requester

4. Update description, the impact information and potential change

window.

Description should contain reason for change and a high-level

implementation plan

Impact section should contain information, both positive and

negative relating to impact during and post the change.

Requester

5. Ensure category lead-times are adhered to. Requester

6. Conduct a conflict check to ensure there are no other changes in the

same window that could conflict with the one being planned.

Requester

7. Submit change for initial approval. Requester

8. Conduct initial assessment of change. Technical

approver

9. Is the information provided is accurate and adequate for assessment

and approval?


If no, go to step 4.

Technical

approver

10. Review details of the Change to ensure the information provided is

accurate and adequate.

Change owner

11. If satisfied with the information,

Go to step 12

If not, go to step 4.

Change owner

RMIT University

Final Draft


DocRef: TRIM

Document:


Page 33 of 65

Step

number


responsible

12. Build and provide detailed implementation (including the detailed step-

by-step set of instructions on the work that is to be carried out to

implement this change), pre-test, and post-verification test plans

The Requester can and should assist in building the implementation

and test plans.

Change

builder

13. Update detail plans into the record. To do this, provide required

information as follows:

The success criteria of the change is recorded as part of the title

of the change

Provide information relating to what the change is actually about

in the description section

Record Change Owner information. This is the person who will

own this change from an ITS perspective, such as the Project

Manager, Technical Application owner and so on

Record technical approver information. This can be the Team

Lead or Technical Lead or a peer of the Implementer. The

Technical approver should not be same person as the

Requester

Record implementer information with the name of the person(s)

doing this change. There can be more than one implementer for

a change.

Note: Assist in building the detailed plans for the change.

Requester

14. Conduct documented pre-testing. Tester

15. Provide outcomes of the testing for the requester to update into the

change record.

Tester

16. Update record with the testing outcomes. Requester

17. Review content of change and ensure

At a high level that the content provided is relevant and

appropriate

The support and communicational information provided is

relevant and appropriate

Change

manager

18. Conduct a conflict check by going to the Forward Schedule of Change

and ensuring there’s no other change scheduled for that window.

Change

manager

RMIT University

Final Draft


DocRef: TRIM

Document:


Page 34 of 65

Step

number


responsible

19. Is the change window and initial information sufficient for initial CAB

approval?


If further information is required or a conflict exists, reject the

change and go to step four (4) (get the Requester to amend the

window or negotiate with the other Change Requester if there is

a conflict. This should always be done on a first come, first

served basis, so amending the window for the change that is

second in line is the preferred option – If it’s informational, wait

for the requester to update the relevant information)

Change

manager

20. Is this the initial (or planning) approval or Implementation approval?

Go to step 21 if this is the initial approval

Go to step 29 if this is the implementation approval.

Change

Manager

21. Table for CAB approval. Change

Manager

22. Pre-read changes on CAB agenda. CAB members

23. Are all the details provided ok?


If not, reject change and go to step 24.

CAB

24. Resolve identified issues with the assistance of the Change Manager Requester

25. Approve change at CAB meeting – Change Manager will record and

approve the change on behalf of the CAB meeting in the toolset

CAB

26. Is this the “planning” or “Implementation” approval?

Planning approval provided then go to step 27

Implementation approval provided go to step 38

CAB

27. Ensure change record has all the content updated in it and then

authorise the change to proceed after reviewing the implementation and

test plans

Change Owner

28. Conduct technical assessment of the change, ensuring the technical

validity of the change and that the support and communicational

Technical

Approver

RMIT University

Final Draft


DocRef: TRIM

Document:


Page 35 of 65

Step

number


responsible

information provided is relevant and appropriate

29. Approved?

If yes go to step 17

If no go to step 13

Technical

approver

30. Add stakeholder approvers based on impact and configuration item

being changed

Change

Manager

31. Approve Change Change

Manager

32. If all ok

Got step 21

If not, reject change and go to step 5

Stakeholder

Approver

33. Mitigate and manage localised impacts Stakeholder

Approver

34. Any issues mitigating local impacts?

If yes, contact Change Manager to resolve issues (step 24)

If no issues go to step 35

Stakeholder

approver

35. Approve change

36. If all ok

Got step 25

If not, reject change and go to step 13

Stakeholder

Reviewer


Reviewer


If yes, contact Change Manager to resolve issues (step 27)

If no issues go to step 29

Stakeholder

Reviewer

39. All approval received?

If yes go to step 41

Implementer

RMIT University

Final Draft


DocRef: TRIM

Document:


Page 36 of 65

Step

number


responsible

If not received, go to step 40

40. Notify Change Owner and Change Management that the record is not

yet approved for implementation

Implementer

41. Implement change in the nominated window as per Implementation plan

at the scheduled start date and time

If back-out required, implement the back-out steps documented in the

implementation plan

Implementer

42. Follow key trigger points including post verification testing and back-out

trigger point

Implementer in

collaboration

with the

Change Owner

43. Conduct post verification tests Implementer

44. Notify Change Owner and implementer of post verification outcomes Tester

45. Is back out required?



Note: The actual back-out trigger point will vary from change to

change. A slight variation in the order of the steps from 41 – 45

is acceptable

Change Owner

46. Close change with appropriate code – maximum of 3 business days

from the end of the change window

Implementer

47. Verify outcomes of the change Change

Manger and

Change Owner

48. Verify that the change was successful.

If yes, end process

If no, go to step 49

Change

Manager

49. Table for CAB review Change

Manager

50. Record learning Change

RMIT University

Final Draft


DocRef: TRIM

Document:


Page 37 of 65

Step

number


responsible

Manager

End process

RMIT University

Final Draft


DocRef: TRIM



Page 38 of 65

9.2 Minor change process flow

Minor Change

Cha

nge

Ow

ner

Cha

nge

Req

uest

erC

hang

e B

uild

erC

hang

e T

este

rTe

chni

cal

App

rove

rC

hang

e M

anag

erSt

akeh

olde

rA

ppro

vers

Stak

ehol

der

Rev

iew

ers

Impl

emen

ter

Final

1. Raise Change Request

2. Conduct Risk assessment

3. Minor? No

4.Build And provide detailed implementation and Test (Pre and Post)

Plans

8. Carries out the documented pre-

testing of the change

10. Technical Assessment of all

plans11. Approved?

12. Reviews technical details

of the change14. Satisfied?

Assist in building the detailed plans

for the change

5. Update Detailed plans

into record

No

9. Provide outcomes of

testing

15. Review Details 16. Check FSC

17. Change Window and

details Clear for implementation?

No

18. Add Stakeholders

(both approvers and reviewers)

Yes19. Approve

Change

22. Any issues?

No20. Details Ok? Yes23. Approve

Change

21. Mitigate and manage localised

impacts

26. Any issues?

No

24. Details Ok? Yes25. Mitigate and manage localised

impacts

27. Assist in resolving

stakeholder issues

YesB

B

Yes

30. Implement Change in nominated

change window

35. Close change with appropriate

code

C

C

No

28. All approvals received?

Yes

B

29. Notify Change owner and

change managerNo

36. Verify outcomes of the

change

37. Successful?

38. Table for CAB Review

No

End ProcessYes

39. Record learnings

Yes

31. Trigger post verification

testing

32. Conduct post verification tests

33. Notify Implementer and Change Owner of

outcomes

34. Is backout required? No

D

D

E

Yes

E

F

F

Yes A

A

A

6. Ensure appropriate

category lead-times have been

met

C

13. Validate Lead-times and verify Conflict Check

7. Conduct Conflict check

No

No

RMIT University

Final Draft


DocRef: TRIM

Document:


Page 39 of 65

9.2.1 Minor change procedural workflow steps

Step

number

Description - Minor Role

responsible

1. Assess need for change and raise Change Request ITS support

staff/

Requester

2. Conduct Risk Assessment Requester

3. Is it minor?


If no, exit the process and amend the category as determined by

the risk assessment.

Requester

4. Build and provide detailed implementation (including the detailed step-

by-step set of instructions on the work that is to be carried out to

implement this change), pre-test, and post-verification test plans.

The requester can and should assist in building the implementation and

test plans.

Change

builder

5. Update detail plans into record. To do this, provide the required

information as follows:

The success criteria of the change is recorded as part of the title

of the change

Provide information relating to what the change is about in the

‘description’ section

Record Change Owner information. This is the person who will

own this change from an ITS perspective, like the Project

Manager, Technical Application owner and so on

Record the Technical approver information. This can be the

Team Lead or Technical Lead or a peer of the Implementer.

The Technical approver should not be same person as the

Requester

Record Implementer information with the name of the person(s)

doing this change. There can be more than one implementer for

a change.

Requester

RMIT University

Final Draft


DocRef: TRIM

Document:


Page 40 of 65

Step

number


responsible

Note: Assist in building the detailed plans for the change.

6. Ensure category lead times are adhered to. Requester

7. Conduct a conflict check to ensure there are no other changes in the

same window that could conflict with the one being planned.

8. Conduct documented pre-testing. Tester

9. Provide outcomes of the testing for the Requester to update into the

change record.

Tester

10. Conduct technical assessment of the change, ensuring the technical

validity of the change and that the support and communication

information provided is relevant and appropriate.

Technical

Approver

11. Is it approved?


If no, go to step 5

Technical

Approver

12. Review the Implementation and test plans Change Owner

13. Validate lead-times and verify conflict check by going to the Forward

Schedule of Change and ensuring there’s no other change scheduled

for that window.

Change Owner

14. Is the Change Owner satisfied all the details are correct?

If yes, you do not need to do anything as the change will

progress through its life cycle


Change Owner

15. Review content of change and ensure:

That at a high level the content provided is relevant and

appropriate

The support and communication information provided is relevant

and appropriate

Change

Manager

16. Conduct a conflict check by going to the Forward Schedule of Change

and ensuring there’s no other change scheduled for that window.

Change

Manager

17. Are the change window and detailed plans clear for implementation? Change

RMIT University

Final Draft


DocRef: TRIM

Document:


Page 41 of 65

Step

number


responsible


If further information is required or a conflict exists, reject the

change and go to step 5 (get the Requester to amend the

window or negotiate with the other Change Requester. This

should always be done on a first come, first served basis, so

amending the window for the change that is second in line is the

preferred option).

Manager

18. Based on the change, add relevant stakeholders. Change

Manager

19. Approve the Change. Change

Manager

20. If everything is ok:

Go to step 21

If not, reject the Change and go to step 5.

Stakeholder

Approver


Approver


If yes, contact the Change Manager to resolve issues (step 27)

If no issues, go to step 23.

Stakeholder

approver

23. Approve the change


Go to step 25

If not, reject the Change and go to step 5.

Stakeholder

Reviewer


Reviewer


If yes, contact the Change Manager to resolve issues (step 27).

If no issues, go to step 29.

Stakeholder

Reviewer

27. Assist stakeholders in resolving any mitigation issues. Change

Manager

RMIT University

Final Draft


DocRef: TRIM

Document:


Page 42 of 65

Step

number


responsible

28. Are all the approvals received?


If not received, go to step 29

Implementer

29. Notify Change Owner and Change Management that the record is not

yet approved for implementation

Implementer

30. Implement Change in the nominated window as per Implementation

plan at the scheduled start date and time

If back-out required, implement the back-out steps documented in the

implementation plan

Implementer

31. Follow key trigger points, including post-verification testing and back-out

trigger point.

Implementer in

collaboration

with the

Change Owner

32. Conduct post-verification tests Implementer

33. Notify Change Owner and Implementer of post-verification outcomes Tester

34. Is back-out plan required?



Note: The actual back-out trigger point will vary from change to

change. A slight variation in the order of the steps from 30 – 34

is acceptable

Change Owner

35. Close change with appropriate code. Implementer

36. Verify outcomes of the Change. Change

Manger and

Change Owner

37. Verify that the change was successful.

If yes, end process


Change

Manager

38. Table for CAB review. Change

Manager

RMIT University

Final Draft


DocRef: TRIM

Document:


Page 43 of 65

Step

number


responsible

39. Record learning. Change

Manager

40. End process

RMIT University

Final Draft


DocRef: TRIM

Document:


Page 44 of 65

9.3 Routine changes procedural workflow

Routine Change

Tech

nic

al A

pp

rove

rR

equ

este

rC

AB

Ch

ange

Man

ager

Ch

ange

O

wn

erIm

ple

men

ter

2Provide required

information

(1) Start:Raise change request

8All ok?

Inadequate information,

Rejected

NO

YES

13Check for

Success/Failure

Failure

Success

9Update Change

Request

6Ensure both

Master Change and Proposed Change have same success

criteria

7Validate

implementation time is in agreed change window

10Implement change

as per agreed to implementation

window and standard steps

Change Approved

3Link to Master

Approved Change Request

12Complete Change

recording success or failure

16Close Change

16Record any learnings

or actions for this outcome

15Review Change

5Has this change been

done atleast 5 times in the last 6 months?

YES

NO

Incorrectly categorised, Rejected

11Follow key trigger

points(Implementer in collaboration with the

change owner

4Submit Change

Request

CAB has final authority over which changes become

“Routine”. Current rule is a minimum of five time over a

six month period

Nominated Change Owner always has full accountability for the

change during its lifecycle

14Table for CAB

Review

RMIT University

Final Draft


DocRef: TRIM

Document:


Page 45 of 65

9.3.1 Routine changes - procedural workflow steps

Step

number

Description – Routine change Role

responsible

1. Raise Change Request Requester

2. Provide required information as follows:

The success criteria of the Change is recorded as part of the title of

the Change

Provide information relating to what the Change is actually about in

the description section

Record Change Owner information; this is the person who will own

this Change from an ITS perspective, such as the Project Manager,

Technical Application owner and so on

Record the Technical Approver information. This can be the Team


Technical Approver should not be same person as the Requester

Record the Implementer information with the name of the person(s)

doing this change. There can be more than one implementer for a

change.

Requester

3. Relationally link the master-approved Change that contains all of the

documented process and implementation plans to this routine change.

Requester

4. Submit the Change. Requester

5. Ensure the Change has been implemented at least five times in the last six

months.

Technical

Approver

6. Ensure the linked Change and the proposed Change have the same

success criteria.

Technical

Approver

7. Validate the implementation time is in the agreed change window.

If the Change is not in the agreed window, ensure justification is

appropriate and relevant.

Technical

Approver


Approve the change and go to step 10.

If further information is required, reject the change and go to step 9.

Technical

Approver

RMIT University

Final Draft


DocRef: TRIM

Document:


Page 46 of 65

Step

number

Description – Routine change Role

responsible

9. Based on rejection reasons, update the change record and go to step 8.

10. Implement Change in the agreed implementation window and standard

implementation steps.

Implementer

11. Follow key trigger points including back-out trigger point. Implementer

in

collaboration

with the

Change

Owner

12. Complete Change recording success or failure. Implementer

13. Check for success or failure:

If successful, close the Change

If unsuccessful, go to step 14.

Change

Manger

14. Table for CAB Review. Change

Manager

15. Review failed routine change. CAB

16. Record any learning or actions for this outcome. Change

Manger

17. Close the Change and stop recording, logging and tracking. Change

Manger

RMIT University

Final Draft


DocRef: TRIM

Document:


Page 47 of 65

9.4 Emergency change procedural workflow

Emergency Change

E-CA

B(D

eput

y D

irec

tor)

Req

uest

erCA

BB

uild

erIm

plem

ente

rCh

ange

M

anag

erTe

ster

1Emergency need for

change identified

2Seek Approval to

implement

3Provide approval to

implement

5Implement Change

6Verify Emergency

Fix

7Raise Change

Request

8Provide Required

information

9Provide information

forpre-testing

ImplementationPost Verification

Backout

10Record information on

Pre-testingImplementation Steps

Post VerificationBack-out trigger points

(if applicable)

12Review content and

scope change

13All ok?

Further information required

NO

Approve Change

YES

14Update Change

record

15Review Actions

taken and justification

16All ok?

NO

Approve ChangeYES

17Record any learning

or action of outcome

End Process

Further information required

4Build

Emergency Fix

11Submit Change

record 18Close change record

RMIT University

Final Draft


DocRef: TRIM

Document:


Page 48 of 65

9.4.1 Emergency change procedural workflow steps

Step

number

Description – Emergency change Role

responsible

1. Emergency need for Change identified. Requester

2. Seek approval from an E-CAB member (relevant Deputy Director) to

implement.

Requester

3. Provide approval to implement Emergency Change. ECAB

Member

4. Build emergency fix. Change

builder in

collaboration

with Tester

and

Implementer

5. Implement change. Implementer

6. Verify emergency fix. Tester

7. Raise Change Request. Requester

8. Record the required information as follows

The success criteria of the change is recorded as part of the title of

the change

Provide information relating to what was actually done

Record Change Owner information, this is the person who owned

this change from an ITS perspective

Record the Technical Approver information. This can be the Team


Technical Approver should not be same person as the Requester

Record the Implementer information with the name of the person(s)

doing this Change. There can be more than one implementer for a

change.

Requester

9. Provide information on:

Any pre-testing activities; this should include any testing that was

conducted

The implementation steps that were carried out

The post-verification testing, along with information on who carried

Implementer

RMIT University

Final Draft


DocRef: TRIM

Document:


Page 49 of 65

Step

number

Description – Emergency change Role

responsible

out this verification testing

The back-out trigger point and the back-out plans if any were

recognised as needing to be recorded.

10. Update record with the information provided by the Implementer on the

technical activities undertaken, including all testing and implementation

plans.

Requester

11. Submit the change. Requester

12. Review content and scope of change. ECAB

member


Approve the Change and go to step 15

If further information is required, reject the Change and go to step

14 (the Request goes back to the Requester to be updated).

ECAB

member

14. Update change record and go to step 11. Requester

15. Review actions taken to effect this Change and review justification of

‘Emergency’ situation

CAB


Approve the Change and go to step 17

If further information is required, reject the Change and go to step

14 (the Request goes back to the Requester to be updated).

CAB – review

recorded on

behalf of the

CAB by

Change

Manager

17. Record any learning or actions for this outcome.in the CAB minutes Change

Manger

18. Close change. Requester

End process.


RMIT University

Final Draft


DocRef: TRIM

Document:


Page 50 of 65

9.5 Glossary of terms

The following terms and abbreviations used in this document are detailed below. Some of this

nomenclature are industry and framework based.

Terminology Definition

Change

builder(s)

Responsible for building the change

Responsible for detailing the Implementation, Back-out and Post-

verification Testing plans into the change record.

This/these could be IT Architects, and other technical team personnel

CAB

Change Advisory Board

CAB

Membership

The CAB membership is made up of the following:

Executive Director – CAB Chair

Core CAB members (are also Emergency Change Advisory Board (ECAB)

members)

Deputy Director - Infrastructure Delivery

Deputy Director - Application Delivery

Deputy Director - ICT Service Management

Deputy Director - Engagement and Planning

Deputy Director – Client Computing

Other members of staff will be requested to be part of CAB based on the

changes being presented for assessment, approval and review.

CAB Scope The scope of this CAB includes the review of:

Any amendments to the overall working of the Change Management

process

Any assessment, review and approval of all technology changes,

including changes initiated by partners/suppliers/vendors

Approve the scope, cost and initial plans of a Major or Significant Change


RMIT University

Final Draft


DocRef: TRIM

Document:


Page 51 of 65


Assess and authorise the priority of the RFC

Assess the impact of a change from a strategic and technological

perspective

Balance the need for change with the need to minimise inherent risks.

Category A specific classification assigned to a change based on its risk assessment.

The risk components assessed are:

Complexity (both technical and organisational)

Likelihood (of failure); and

Consequence (or impact of that failure)

Category lead-

times

Routine (formerly known as Pre-approved) changes have no lead-time and

can be implemented in their specific pre-designated window as soon as

they are approved.

3 business days for a Minor Category change

10 business days for a Significant Category change

15 business days for a Major Category change

Change Any change to the Production environment that:

Impacts a service or its component parts

Adds, modifies/changes or removes a service or its component parts.

Example: A change

Server not available due to network maintenance activity.

Not a change

When a development box is rebooted and only affects the

service in the development environment.

Change

Manager Manages the Change Process

• Ensures that Change Management processes have high visibility and

open channels of communication in order to promote smooth transitions

when changes take place

• Ensures that the Change Management procedures work effectively with


RMIT University

Final Draft


DocRef: TRIM

Document:


Page 52 of 65


the Incident Management, Request Management, Problem

Management, Configuration Management, and Release Management

processes, as well as Service Centre policies

• Ensures appropriate stakeholder management principles are applied

based on category and types of changes

• Ensures content and visibility of the Forward Schedule of Change

(Change Awareness Calendar) was appropriate and available for

planning activities

• Runs Continual Service Improvement (CSI) programs to provide input

into the service improvement strategy for Technical Change

Management processes and its associated business rules

• Periodic audits to confirm that the Change Management and support

teams are adhering to defined procedures.

CAB preparation

• Reviews all changes prior to the CAB meeting (e.g. initially a pre-CAB

meeting is recommended prior to each CAB)

• Issues a CAB agenda that includes all changes that were approved at

the pre-CAB and circulates it to CAB members in advance of meetings to

allow prior consideration.

All changes

• Monitors, tracks and manages change records throughout their lifecycle

from request through to approval and closure

• Tables (Requests for Change) RFCs for CAB meetings

• Rejects any RFCs that do not meet content, notification and technical

quality requirements.

• Checks start date against lead-time

• Ensures no conflict with another change in the same window

• Ensures communications plan in place

• Identifies stakeholders and approvers based on impact and customers at

risk of impact

• Verifies Change Owner has engaged customer to validate solution

• Ensures the various plans have enough detail


RMIT University

Final Draft


DocRef: TRIM

Document:


Page 53 of 65


• Ensures resources allocated to the record are appropriate (for example:

if implementation plans include database-related changes, then ensure

there is a DBA task included

• Documents CAB or ECAB, comments and approvals for their change

• Reviews all outstanding RFCs awaiting consideration or awaiting action

• Updates the Change log with all progress that occurs. This includes any

actions to correct problems and/or to take opportunities to improve

service quality.

• Analyses change records to determine any trends or apparent problems

that occur. Seek rectification with relevant Change Owners

• Ensures cause of a failed Change is accurately documented by assisting

in finding the Root Cause of Change Failure (Change Review process)

Table for CAB to discuss any failed or problematic change.

• Produces a comprehensive management report that outlines details of all

high impact changes, minimising impact to the delivery of Service Level

Agreements (SLA) to the Service Centre

• Ensures all problems or emergency fixes work adheres to Emergency

Change procedures and sign-offs, including risk management of

customer impact.

Change Owner The person with ultimate accountability for the delivery of the Change (an

example might be a Project Manager).

ECAB member

A CAB member who provides approval for an emergency change to be

implemented in a break-fix situation. This is usually the Deputy Director for a

specific area implementing the change.

Emergency

Change

Regardless of the category, these changes are executed in ‘break-fix’

situations (something is broken and needs to be fixed now; something will

break shortly and needs to be pro-actively fixed now; something is not

working as it should and needs to be fixed now).

The Request for Change (RFC) can be raised retrospectively and it will

trigger the following list of tasks on initial submission:

Technical approval

ECAB approval (assigned to the designated ECAB member)

CAB review.


RMIT University

Final Draft


DocRef: TRIM

Document:


Page 54 of 65


Expedited

Change

Any normal change that does not meet its associated category lead-time is

an expedited change. The change is still categorised based on its risk, but

due to an urgent need, it cannot wait for the associated category lead-time

prior to implementation. On Deputy Director discretion an expedited change

may be implemented prior to the next CAB meeting. In such cases the

change will be retrospectively reviewed by CAB.

Impact An affected group of customers. The effect could be positive or negative. In

the case of an incident, the impacted customer group will have a negative

experience.

Implementer Responsible for implementing the change as per the detailed plans and within

the change window.

If unable to meet the requirement of the Change Window, the Implementer

must notify the Change Administrator

Close implementation tasks at the end of the implementation, recording

success or otherwise of the implementation.

Incident An Incident is an unplanned interruption to an IT service or a reduction in the

quality of an IT service.

The failure of a configuration item that has not yet affected service but that

increases the risk of service interruption (or risk of a reduction in service

quality), e.g. the failure of a single server in a clustered environment, is also

considered an Incident.

(Incident)

Detector

The person (ITS staff member or customer) who logs an Incident or reports it

to the IT Service Desk.

(Incident)

Resolver

The ITS staff member who resolves an Incident.

Incident

Trigger

The trigger for an Incident may be the total or partial loss of a service, or

potential loss of service, including a service running slowly

ISO 20000 The International Standards Organisation (ISO) provides a set of clearly

defined activities to be carried out in a consistent manner to achieve an

industry-based accreditation (ISO 20000 certification) in Information

Technology Service Management (ITSM).

ITIL IT Infrastructure Library. A collection of five books that provides an industry

best practice framework and guidance structure for IT organisations to

provide managed services enabling customers to meet business needs.

ITS Service

Management

The software used by ITS to record and manage Incidents – VMWare

Service Manager 9.


RMIT University

Final Draft


DocRef: TRIM

Document:


Page 55 of 65


Tool

KBC Known Business Contacts – a collated list of contacts within the business

that have been identified as the key people with whom to communicate in

relation to Major Incidents.

Lead-time Time from when the Change Request receives its first approval (Technical

Approver approval) to the implementation start date. This allows stakeholders

to assess changes, mitigate and manage any localised impacts

• CAB Agenda submission cutoff times

– Noon the day prior to CAB (so, Wednesday and Friday at

noon, since CAB runs on Thursday and Monday every week).

Likelihood An aspect of risk assessment that evaluates the likelihood of a change failing,

such as not having a test environment contributes to the likelihood of failure

of an implementation.

Major Category

Change

A change of high or major complexity with outages to multiple locations and

multiple customer groups.

Example: outage caused by a network change at year-end which affected all

of RMIT

This will trigger the following list of tasks on initial submission:

Technical approval

Change Admin approval

CAB design approval

Planning

Technical approval


Stakeholder approval(s)

CAB approval

Implementation


RMIT University

Final Draft


DocRef: TRIM

Document:


Page 56 of 65


Major Incident Priority 1 and Priority 2 Major Incidents. Major Incidents are managed by the

Major Incident Management process. Some Priority 2 incidents are excluded

from invoking the Major Incident process; these are

- Teaching Spaces

- Classrooms

- IT Laboratories

- Audio Visual support

Minor

Category

Change

A change that is of low complexity, has a low likelihood of failure and the

consequences of that failure are minimal. Has no scheduled outage.

– Example: minor configuration change with no service

interruption


Technical approval



Implementation

Non-Standard

Request

A Request which is not pre-defined as a Standard Request and therefore

which requires a decision to be made, on a case-by-case basis, as to

whether ITS should fulfil the Request.

Outage Anything that disrupts the delivery of a ‘Service’.

On-call Analyst The person or persons appointed by each Support Team to provide support

outside of Core Hours.

Positive

Handover or

Contact

When an IT Service Desk or On-call Analyst hands over a major incident to a

Major Incident Manager by speaking to them either in person or on the

phone. It is not a ‘positive handover’, if a voicemail message is left when

reporting a Major Incident.

Priority An attribute of an Incident that represents the relative importance of an

Incident. Priority is based on Impact and Service Category and determines

the Response and Resolution Time Targets for the Incident.


RMIT University

Final Draft


DocRef: TRIM

Document:


Page 57 of 65


Problem The cause of one or more incidents, where the cause is usually not known at

the time that it is recorded. Problem management is the process responsible

for further investigation and identifying the underlying root cause of the

problem.

Request A Request (also known as a Service Request) is a type of frequent, low-risk

demand placed on ITS by customers (or other ITS staff members) in order to

obtain a pre-defined IT service.

Requests typically include password resets, setting up new starters,

equipment moves, system access requests, software installs, application

enhancement requests and requests for information.

RFC A request for change is a record raised requesting approval for a system, or

service be modified, changed, amended, enhanced or newly introduced into

the production environment

Request

Fulfilment

The process responsible for providing effective management of Requests

throughout their lifecycle, ensuring that fulfilment of Requests occurs in a

timely fashion and customer expectations are managed accordingly.

Requestor or

Creator

Person who raises the change in the Change Management system (VSM).

They are responsible for recording all required content relating to the change

in the Change Management system

Response

Time

The time it takes from an Incident being detected or Service Request being

raised, to the Incident Detector/Requester being contacted by the IT Service

Desk or Analyst (an automated response by the ITS Service Management

Tool is not considered a response).

Response

Time Target

The time within which RMIT aims to respond to an Incident or Request of a

given Priority

Response

Percentage (%)

Target

The percentage of Incidents or Requests of a given Priority that RMIT aims to

respond to within the Response Time Target for that Priority. For example,

RMIT aims to respond to 90% of Priority 2 Incidents within one (1) business

hour.

Resolution

Time

(Fulfilment

Time

The time it takes from an Incident being detected to the Incident being

resolved;

Or

The time it takes from a Request being logged to the Request being fulfilled

Resolution

Time Target

(Fulfilment

The time within which RMIT aims to resolve an Incident or fulfil a Request of

a given Priority. For example, the Resolution Time Target for a Priority 3


RMIT University

Final Draft


DocRef: TRIM

Document:


Page 58 of 65


Time Target) Incident is two (2) business days.

Resolution

Percentage (%)

Target

(Fulfilment

Percentage [%]

Target)

The percentage of Incidents or Requests of a given Priority that RMIT aims to

resolve within the Resolution Time Target for that Priority. For example, RMIT

aims to resolve 80% of Priority 2 Incidents within four (4) business hours.

RFC Request for Change record, (also known as a Change Request) and should

not be referred to as a ‘CAB’.

Routine or Pre-

Approved

Category

Change

A change of minimal risk and of the lowest complexity that has been

implemented at least five (5) times in the last six (6) months.

Example: Create DNS entries under RMIT domains and subnets

This will trigger the following list of tasks on initial submission

Technical approval

Implementation.

Service Anything that provides or facilitates the customer achieving a business

solution or outcome.

It is a:

Platform

o Production

o Setting up of Dev, Test and Sandpit environments

o Network – LAN, WAN, Wireless…

o Environment – Unix, Mac, Windows, Novell…

Application – SAP, Peoplesoft…

Resource – servers, VM’s, storage, database…

Service

Catalogue

A catalogue of services provided by the Information Technology Services

area to the rest of the RMIT community and customer-base.

Service

Category

Each service provided by ITS to its customers is categorised in the Service

Catalogue as either a Bronze, Silver or Gold service, based on how

dependent customers are on the normal operation of the service – a Gold


RMIT University

Final Draft


DocRef: TRIM

Document:


Page 59 of 65


service is deemed most critical and a Bronze, the least. Service Category is

used together with Impact to determine the Priority of an Incident.

Significant

Category

Change

A change of moderate to significant complexity, with or without outages and

any additional customer impacts are clearly identified and known.

Example: Outage to a floor or an outage to GroupWise at 8 am on Tuesday

morning.


Technical approval


CAB design approval

Planning

Technical approval



CAB approval

Implementation.

SLA Service Level Agreements (SLA’s) are ITS’ commitment to respond to,

resolve or fulfill incidents and requests within set timeframes.

Stakeholder A person who needs to be advised about a change that will, or could, have an

impact on their area of responsibility.

A stakeholder may be also be a person who has a vested interest in the

outcome of a change due to an expected impact or business outcome

Stakeholder

Approver

A person who provides documented authorisation of a change to occur

In the stated change window

To the scope identified

At the risk level identified by the Change Category.

A team representative (usually the Team Lead) is required to actively assess

and action (approve or reject with valid reasons) the task assigned to the

group.


RMIT University

Final Draft


DocRef: TRIM

Document:


Page 60 of 65


Stakeholder

Reviewer

A person who has a vested interest in the outcome of a change or who needs

to be kept informed or notified of a change being implemented. A team

representative (usually the Team Lead) is made aware of the Change, but is

not required to action any task.

If however any concerns are identified with the proposed implementation, the

reviewer is required to notify change management to have the issue

addressed

Standard

Requests

A Request which is pre-agreed as supported by ITS and that has a certain

amount of documented knowledge associated with it that helps ITS to fulfil

the Request consistently whenever it occurs.

Support /

Fulfilment

Team

The 2nd or 3rd level ITS team who are assigned to resolve an Incident or fulfil

a Request that is out-of-scope for the IT Service Desk.

Technical

Approver

Usually a team lead/manager who reviews the content and technical validity

of the Change. The Change cannot be socialised for approval until it has

passed through this review phase.

Tester(s) Responsible for the testing of the Change before and after implementation.

This is not necessarily done by the same person. This could be the Testing

Team, a peer of the implementer or a customer representative.

VSM VmWare Service Manager 9 – the current service management toolset used

by RMIT ITS to log Incidents, Requests for fulfilment, Changes, and

Configuration information.


RMIT University

Final Draft

Status: Discussion Version: 0.1

DocRef: TRIM



Page 61 of 65

9.6 Sample of Change categories and their lead-times

Change

category

Change criteria Examples Change Approver Lead-time to

implementation

(following

technical lead

approval)

Submission

before CAB

convenes

Scheduled

outage

notification

lead-time

Routine

(formerly

known as

Pre-

approved or

Standard)

Day to day changes

and scheduled

maintenance that

require no outages.

Also usually known

as BAU (Business

As Usual) activities

and are managed

within a team and

further approvals are

not required.

Routine,

documented, low

complexity, low risk,

low impact, well-

known and proven

tasks (routine tasks).

Password resets,

GroupWise Index

rebuilds

PC/Notebook

deployments/impl

ementations/rollou

ts

Mobile device

configurations

User accounts

AV changes.

Approval not

required but the

change must be on

Manager’s Pre-

approved Change

list.

N/A Only once, to

be ratified as a

routine

No scheduled

outage. These

changes should

need no

notification to

the customer

due to the

nature of the

change

Emergency Critical system

outages where a

system is deemed

SAP intermittently

unavailable

Deputy Director or

Emergency

Change Advisory

Verbal approval

to be given by DD

Retrospectively

submitted to the

following CAB

No lead time is

possible as they

are usually to fix


RMIT University

Final Draft


DocRef: TRIM



Page 62 of 65

Change

category


implementation

(following

technical lead

approval)

Submission

before CAB

convenes

Scheduled

outage

notification

lead-time

unavailable or

unusable.

An immediate or

unscheduled outage

would be required to

rectify the problem.

No access to

Peoplesoft.

Board (ECAB). or ECAB. for review. unforseen

technology

issues

Expedited Changes that, for

unforseen reasons

do not meet

category lead times.

Redundant

controller cards in

an M9000 device

Technical Leader,

Change

Administrator, and

stakeholders

As soon as the

need for change

has been

identified. It is

the change

owner’s

responsibility to

ensure all

approvals are

received prior to

the

implementation

start date and

time

Approved by

Change

Administrator ,

and

stakeholders

which must

include relevant

Deputy Director.

No lead time is

possible as they

are usually to fix

unforseen

technology

issues however,

at least 1 day

should be

provided


RMIT University

Final Draft


DocRef: TRIM



Page 63 of 65

Change

category


implementation

(following

technical lead

approval)

Submission

before CAB

convenes

Scheduled

outage

notification

lead-time

Minor Operational

upgrades to

infrastructure and

applications that

affect only a small

number of users

risk is less due to

the ITS experience

level with the

proposed change

Low business impact

Will cause no

outage.

Staff moves,

updates of virus

protection files,

batch jobs within a

certain class.

Technical Leader,

Change

Administrator, and

stakeholders

Three (3)

business days

prior to

implementation

date.

Approved by

Change

Administrator by

noon the day

before CAB is

to convene.

1 day prior to

implementation

and triggered as

part of the

Change

Request

process,

however these

changes should

have no outage

Significant Operational

upgrades to

infrastructure and

applications that

affect a significant

number of

customers or users

The purchase and

installation of a

new server within

the organization

Technical Leader,

Change

Administrator,

stakeholders and

CAB.

10 business days

prior to

implementation.

Approved by

Change

Administrator by

noon the day

before CAB is

to convene.

5 days prior to

implementation

and triggered as

part of the

Change

Request


RMIT University

Final Draft


DocRef: TRIM



Page 64 of 65

Change

category


implementation

(following

technical lead

approval)

Submission

before CAB

convenes

Scheduled

outage

notification

lead-time

and are usually

accompanied by an

outage

risk is moderate

since some impacts

are known and

others would need

evaluation

Moderate business

impact

Service

unavailability or the

risk of a service

being only partially

usable if change is

not done.

Re-segmenting

part of the

network

Introduction of a

new application to

a moderate group

of customers (e.g.

50 – 150

customers.

process.

Major Core application or

infrastructure

operational changes

Datacentre move,

Core network

outage e.g.

Technical Leader,

Change

Administrator,

stakeholders and

15 business days

prior to

implementation.

Approved by

Change

Manager by 9

am the day

10 days prior to

implementation

and triggered as

part of the


RMIT University

Final Draft


DocRef: TRIM



Page 65 of 65

Change

category


implementation

(following

technical lead

approval)

Submission

before CAB

convenes

Scheduled

outage

notification

lead-time

Require a major

outage and are

classified as a high

risk

New technology

implementation or a

configuration change

that would likely

involve downtime of

the network or a

whole service

Potential for

significant business

impact.

installing/changing

/upgrading RMIT-

wide software e.g.

PeopleSoft, SAP

and Blackboard

Introduction of

new software to a

group of people,

re-working part of

the network,

installation of a

server.

CAB.

before CAB is

to convene.

Change

Request

process.