+

Aroosha OSS
Change Management
Compatible with ITIL v3

+
Change Management Overview

The goal of the Change Management process is to ensure the

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

ITIL V3 Service Transition defines Change Management as

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

Hardware

Communications equipment and software

System software

All documentation and procedures associated with the running,

support and maintenance of IT services.

+
Benefits of Change
Management

Risk Reduction

Service Quality Improvement

Change Management minimizes the risk of introducing

harmful changes into the production environment.

The proper assessment of the impact of changes prevents

unscheduled service outages. This increases service quality.
Change records allow for continuous process improvement
and facilitates the resolution of issues related to change.

Cost Reduction

Effective change management reduces rework and back

outs.

+
Glossary of terms

Change

Change Advisory Board

The addition, modification or removal of approved, supported or

baselined hardware, network, software, application, environment,
system, desktop build or associated documentation.

A group of people who can give expert advice to change

management
on the implementation of changes. This Board is likely to be made up
of representatives from all areas within IT and representatives from
business units.

Change control

The procedure to ensure that all changes are controlled, including the
submission, analysis, decision making, approval, implementation and
post implementation of the change.

+
Glossary of terms

Change history
Auditable information that records, for example, what
was done, when it was done, by whom and why.

Change management

Process of controlling changes to the infrastructure or any

aspect of services, in a controlled manner, enabling
approved changes with minimum disruption.

Request for Change (RFC)

Form or screen used to record details of a request for a

change to any CI within an infrastructure or to procedures
and items associated with the infrastructure.

+
Change Management Process
Principles

An RFC (Request for Change) triggers the process.

The RFC becomes a change record that tracks the change

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

Two key change activities are change prioritization and change

categorization.

Prioritization is used to establish the order in which changes are

considered.

Categorization examines the impact of the change on the organization.

Minor Changes are approved by the Change Manager or the

Change Manager can delegate the

+
Change Management Process
Principles

For Significant and Major Changes, the Change Manager will

consult the Change Advisor Board (CAB) before approving the
change.

In order to streamline the approval process, the concept of a

Standard Change is introduced. Standard changes are changes
that are frequent in nature and low in risk/impact. The CAB can
designate a change task as a Standard Change if

a) precedent setting Minor change has been assessed and successfully

implemented and

b) the technical team requests delegated status for the task.

If granted, the approval of such a change rests with the technical

team. In effect, Standard Changes are pre-approved. The unsuccessful
implementation of Standard changes will result in withdrawal of the
Standard status and a return to Minor. These should be develop
whenever possible in the change management process - reduces redtape, increases efficiency

+
Change Management Process
Principles

Urgent and Emergency changes are dealt through appropriate

change models to expedite their path through the process. This
typically requires a meeting of the Emergency CAB (CAB/EC).

Inputs to the Change Management process:

A request for Change (RFC)

CI data from Configuration Management

Change implementation procedures

Process Outputs:

Detailed change records

Implemented change

Change Advisory Board (CAB) minutes and actions

Change Management reports

Information provided to Configuration Management for updates to

Configuration Items (CIs)

+Change Categories
Change
Categories

Change Model (work flow)

Normal Changes

Emergency
Changes

Standard Changes

Change Authority

Must test
Must have back-out plan
Assessed at regular
intervals (CAB meetings
etc)

Change Manager
Change Advisory
Board

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

Emergency CAB

Repetitive
Low-risk
Well-tested
Defined outcomes

Pre-approved

+Change Categories
Change
Category

Authority

Description

Examples

Standard

Selfapproved

A Standard Change has

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

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

+Change Categories
Change
Category

Minor

Authority

Description

Examples

Change
Manager

A minor change is not

transparent, but is
minimal in risk and
impact.

Oracle Database
Parameters
Change
New virus
signatures
Server additions,
modifications,
removals
SAN storage
additions/deletion
s/modifications to
a client

+Change Categories
Change
Category

Significant

Authority

Description

Examples

CAB

A significant change may

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

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

+Change Categories
Change
Category
Major

Authority

Description

Examples

CAB

A major change has

major impact on IT
services (affects
most if not all users). If a
problem occurs during
installation or the
installation is complex
and lengthy, the backout is difficult or
impossible.

Firmware
upgrades on all
switches and/or
routers
New
service/feature
deployments,
terminations
New technology
or type of device
introductions,
decommissioning
Operating
system,
application
software/firmware
releases,
upgrades

+
Roles identified in the change
process

The Change Manager and Deputies

The role of the Change Manager in the change process is to

authorize/approve minor, low risk changes. The Change Manager
will also convene the CAB to discuss the higher risk changes, where
appropriate, and make the decision either to implement or reject
the change. The Change Manager also ensures that all activities to
implement the change are undertaken in an appropriate manner
and are documented and reviewed when completed.

Change Initiators

Anyone can initiate a change within the organisation however,

consideration must be given to whether this should include all
users. If users are to be allowed to raise changes this should be
controlled through the service desk, this will ensure that only
relevant and appropriate changes are raised.

+
Roles identified in the change
process

The Change Advisory Board

The Change Advisory Board is a group called together by the Change Manager
to act in an advisory capacity to the Change Manager to all changes that are
categorized as significant or major. They also authorize changes in these
categories.

The CAB is made up or individuals within or outside IT who are relevant in the
making the decisions on whether a change should be authorized.They are
called together as required in order to ensure that changes are progress in a
prompt and efficient manner.

The CAB/EC

The Emergency Change Advisory Board is a group called together by the

Change Manager to act as decision makers on ALL changes that are
categorised as emergency. This group usually meet virtually as the nature of
emergency change means that it has been be agreed and authorised
immediately. The ECAB is made up or high level individuals who are relevant in
the making the decisions on whether a change should take place immediately
as an emergency or if it should be delayed and given an alternative category.

+
Roles identified in the change
process

The Change Builder(s)

The Change Builder(s) is the appropriate technology subject

matter expert who will ensure that all necessary hardware,
software, licenses etc., are available to complete the
building of the change prior to sending to be tested.

The Change Builder(s) could be any of the staff within IT

but the Change Builder must be identified in the RFC to
ensure that anyone else involved within the change process
knows to which technical expert to direct questions and
issues. The Change Builder will also recommend the types of
testing that are appropriate for each change.

The Change Tester

Wherever possible with all changes the Change Tester

should not be the Change Builder this is to ensure
rigorous and error free testing.

+
Roles identified in the change
process

The Change Implementer

The Change Implementer will usually be the technology

subject matter expert who was the Change Builder. If the
change implementation needs external third party or
supplier involvement this needs to be documented within
the request for change form.

The Change Reviewers

The Change Reviewers are a group called together by the

Change Manager once the change has been implemented
to review and close out the request for change.

+
The change process

+
The change process

+
The change process

+
The change process

+The change process (Initiating a

change )

Only the IT teams have access to the request for change form to
initiate emergency changes. All other requests for changes either
from users and anywhere else in the organisation need to be
considered as to how they can be initiated, i.e. via the service desk,
via the change intranet site etc. It is the responsibility of the Change
Initiator to ensure that a sufficient detail exists in the request for
change to ensure that the Change Manager can make an informed
assessment.

Change information should include the following:

The reason/business justification for the change

Why the change is needed in particular giving detailed

information on implications of not implementing the change i.e.
security risks etc.

Known risks or impact to the business of implementing the change

consideration should also be given to the risk and impact to the
business of not implementing the change

Required resources including people, time and investment/costs

The status of a change at this stage of the change process will be:
NEW and then AWAITING ASSESSMENT.

+The change process (Filtering and

assessing a change )

All changes (except those that can be dealt with via a

standard change or a change model for which
operational procedures exist) are filtered and assessed
by the Change Manager.

Rejection of changes at assessment stage

Where a request for change has been assessed and

considered inappropriate, impractical or unjustified they
should be returned to the Initiator, together with brief
details of the reason for the rejection, and the request for
change should record the rejection information.

A right of appeal against rejection should exist, via

normal management channels.
The status of a change rejected at this stage of the
change process will be: REJECTED BY THE CHANGE
MANAGER.

+The change process (Filtering and

assessing a change )

Progression of changes at assessment stage

If the Change Manager completed the change

assessment and considers it request viable the request
for change is progress to prioritization.

The status of a change at this stage of the change

process will be: ASSESSED.

+The change process (Assigning a priority

to a change)

The Change Manager assigns the change a priority based

on the following information: (Priority information (priority
is based on how quickly the change needs to be
implemented)

Emergency needs doing immediately (emergency

change process). Causing loss of service or severe
usability problems to a larger number of Users, a
mission-critical system, or some equally serious
problem. Immediate action required. Urgent CAB/EC
meeting may need to be convened. Resources may
need to be allocated immediately to build such
authorised changes.

High needs doing within 48 hours. Severely affecting

some users, or impacting upon a large number of users.
To be given highest priority for change building, testing
and implementation resources. (other than emergency).

+The change process (Assigning a priority

to a change)

Medium needs doing within five days. No severe

impact, but rectification cannot be deferred until
the next scheduled release or upgrade. To be
allocated medium priority for resources.

Low needs doing by the indicated date. A

change is justified and necessary, but can wait
until the next scheduled release or upgrade. To be
allocated resources accordingly.

+The change process (Assigning a

category to a change)

The Change Manager assigns the change category

based on the following information: (Category
information (category is based on the required level
of authorization)

Standard change using a procedure preauthorized

IT change model using a procedure may need

some level of authorization

Minor change authorized by Change Manager

alone (low risk and low impact to the business)

Significant change authorized by a CAB (medium

risk and/or medium impact to the business)

Major change authorized by a CAB (senior level)

(high risk and/or high impact to the business)

+The change process (Authorization of a

change by the Change Manager )

If the request for change has a priority of any other

than emergency and category of any other than
significant or major the Change Manager has the
authority to authorize these changes alone. It is
probable that in most cases the Change Manager will
take advice but these changes do not have to be
presented to Change Advisory Board.

The status of a change at this stage of the change

process will be: AUTHORISED.

+The change process (Authorization of a

change by the Change Advisory Board )

CAB meetings

The Change Manager will always act as the Chair of any CAB
meetings either virtual or face to face.

CAB meetings should be called by the Change Manager at

appropriate times to ensure the prompt and efficient handling of
all changes. During high levels of change this could potentially
be daily.

For complex, high risk or high impact changes, or when major

projects are due to deliver products a formal CAB meeting be
would be necessary.

The meetings can then be used to provide a formal review and

authorisation of changes, a review of outstanding changes, and,
to discuss any impending major changes. Where face to face
meetings are appropriate, they should have a standard agenda.

Relevant change information should be circulated in advance to

allow CAB members to conduct impact and resource
assessments prior to the CAB meeting.

+The change process (Authorization of a

change by the Change Advisory Board )

CAB meetings

The CAB called by the Change Manager should consist of

attendees who are relevant to RFCs being considered. This also
includes attendees for other groups and parts of the business.
Authorization at the CAB for each change must be given by
appropriate representatives from all areas the change will affect.

The CAB representatives for a significant or major change are at

a different level. All major changes must have CAB
representation from the senior IT and business management.

A standard CAB

Failed changes

Backed out changes

RFCs to be assessed by CAB members

RFCs that have been assessed by CAB members

Implemented change are reviewed

+The change process (Authorization of a

change by the Change Advisory Board )

A standard CAB

The change management process including any amendments made to

the process, as well as proposed changes to the process (as appropriate)

Change management successes for the period under discussion, i.e. a

review of the business benefits seen as a result of the change
management process (as appropriate)

CAB considerations for each change (prior to authorization)

Impact assessment (on the business) Risk assessment (on the business)

Effect upon the infrastructure and customer service, as defined in the

SLA, and upon the capacity and performance, reliability and resilience,
contingency plans, and security

Impact on other services that run on the same infrastructure (or on

software development projects)

Resource assessment the IT, business and other resources required to

implement the change, covering the likely costs, the number and
availability of people required, the elapsed time, and any new
infrastructure elements required

+The change process (Authorization of a

change by the Change Advisory Board )

CAB considerations for each change (prior to authorization)

Effect/risk/impact of not implementing the change

Other changes being implemented on the Forward Schedule of
Change
Technical capability and technical approval

Financial approval (if required)

Third party/supplier involvement in the implementation of the

change

The impact on non-IT infrastructures within the organization

Business approval (if required)

Review/assessment of the change priority

CAB comments/issues

All CAB Manager within the CAB meeting information section of

the request for change form. comments on each change and any
issues that have been discussed must be documented by the
Change

+The change process (Authorization of a

change by the Change Advisory Board )

CAB recommendations/decisions

All CAB recommendations and decision that have been discussed

must be documented by the Change Manager within the CAB
meeting information section of the request for change form.

CAB authorisation/approval

Once all aspect of the change have been considered (as per the
CAB considerations for each change information above) the CAB
will then give authorisation for the change to be progress for
scheduling and into the change build stage of the process.

Note that the CAB is an advisory body only. If the CAB cannot
make a final decision on the authorisation of a change then the
change escalation needs to be initiated by the Change Manager
to ensure that authorisation is given (via escalation) at a higher
level. The escalation of change authorisation is documented in
the request for change the Change Manager will detail to
whom the change was escalated and the final decision that was
made either authorised or rejected.

+The change process (Authorization of a

change by the Change Advisory Board )

CAB authorisation/approval

Once a change has been authorised, the status of the

change at this stage of the change process will be:
AUTHORISED.

The Change Manager will update the change authorised by

section of the request for change form with the names of all
the change authorisers. Formal authorisation can be added
with electronic signatures, if required.

+The change process (Rejection of a

change by the Change Advisory Board )

If the CAB rejects the change, the Change Manager

must document, in full, the reasons for the rejection
and ensure that the decision is communicated to the
Change Initiator.

The status of the change at this stage of the change

process will be: REJECTED BY THE CAB.

+The change process (Scheduling of a

change)

Only when a change has been authorised can the Change

Manager progress the change for scheduling. The Change
Manager will complete the following information in the
request for change form with input from other IT
managers/team leaders to ensure that the appropriate
resources are allocated to the change.

Additional change information (scheduling information)

Change(s) Builder identified Full name and department.

Type of testing identified What type of testing (if any) needs to
be completed prior to the change being implemented. If not
testing is to be carried out NO testing needs to be documented in
the request for change and any potential risks identified.
Change Tester identified Full name and department.

The Change Manager has responsibility for ensuring that changes are
implemented as scheduled, though this will be largely a coordination role as
the actual implementation will be the responsibility of others within IT.

+The change process (Building of a

change )

Once a Change Builder(s) has been identified the change

is passed to the appropriate technology expert for
building. The Change Builder(s) will change the status of
the RFC to IN BUILD.

Activities

of change building

building a new production module

creating a new version of one or more software modules

purchasing equipment or services externally

preparing a hardware modification

producing new or amended documentation showing the

components of the change build

devising a backout plan

devising testing requirements, as appropriate

documenting required resources for the change implementation

+The change process (Building of a

change )

Change dependencies identified

The Change Builder(s) needs to consider any change

dependencies that may have an impact on this
change being built and implemented. This may
include the consideration of order in which any
dependent changes need to take place
and potential risk and resource implications. The
Change Builder(s) will need to check all changes that
have been authorised and are potentially being built
by other teams and also any changes that are
currently being assessed to ensure that no
dependencies exist.

If there are dependencies the Change Builder(s) need

to document these in the change dependencies
identified section of the request for change.

+The change process (Building of a

change )

Details of the change backout plan

The Change Builder(s) needs to document a change

backout plan in detail, which can be used in the event that
the implementation of the change is not successful. This
plan needs to document the timing at which the backout
plan should be invoked i.e. at what stage is the change
implementation considered unsuccessful.

High level information on the details of the change backout

plan need to be documented in the request for change form
in the section details of the change backout plan.

At this stage the name of the person who can authorise the
backout plan with any relevant contact information also
needs to be documented.

Date change building completed

Once all change build activities have been completed The

Change Builder(s) will complete date change building

+The change process (Building of a

change )

The Change Manager role during change building

The Change Manager has a coordination role during change

building alongside the normal line management controls, to
ensure that the change building activities are both
resourced and also completed to schedule.

The Change Manager also ensure that backout procedures

are prepared and documented in advance, for each
authorised change, so that if errors occur after
implementation, these procedures can be quickly activated
with minimum impact on service quality.

+The change process (Testing of a

change)

Once the Change Builder(s) has completed all build activities

the change is passed to a Change Tester for independent
testing. The Change Tester will change the status of the RFC
to IN TEST.

Activities of Change Tester

To prevent changes from adversely impacting on service

quality, it is strongly recommended that the Change Tester
will carry out the following activities to ensure that the
change is thoroughly tested in advance (including backout
procedures) where possible.

Testing should include aspects of the change such as:

performance

security

functionality

testing of the backout plan

documenting testing carried out and results

+The change process (Testing of a

change)

Activities of Change Tester

Usually most of this testing will require a separate test

environment. Potentially it is not possible for every type of
change to the tested and, in these instances, a more
detailed impact and risk of implementing these types of
changes must be undertaken to reduce issues during the
Implementation of the change.

Change dependencies identified

The Change Tester needs to consider any change

dependencies that may have an impact on this change
being built as a result of the testing. This may include the
consideration of order in which any dependent changes
need to take place and potential risk and resource
implications. The Change Tester will need to check all
changes that have been authorised and are potentially
being built by other teams and also any changes that are
currently being assessed

+The change process (Testing of a

change)

Change dependencies identified

Details of the testing carried out

The Change Tester needs to document all testing carried

out.

Backout plan tested

to ensure that no dependencies exist. If there are

dependencies they need to be document in change
dependencies Identified section of the request for change.

The Change Tester needs to ensure that the backout plan is

tested and that this is documented in the request for
change form.

Date change testing completed

Once all testing activities have been completed the Change

Tester will complete date change testing completed

+The change process (Testing of a

change)

If change failed testing reason for test failure

Date returned to Change Builder for rebuilding

The Change Tester needs to document if the change failed

testing and the reasons for this failure. The Change Tester
may also make any observations or recommendations that
they feel would be useful for the Change Builder as part of
the rebuild of the change.

The Change Tester need to complete the date the request

for change was returned to the Change Builder section in
the request for change form for rebuilding following a
change test failure.

The Change Manager role during change testing

The Change Manager has an overseeing role to ensure that

all changes that can be, are thoroughly tested.

+The change process (Testing of a

change)

The Change Manager role during change testing

In all cases involving changes that have not been fully

tested, special care needs to be taken during
implementation. The Change Manager should assess the
risk to the business of any change that is to be installed
without complete testing having taken place.

The Change Manager also has the responsibility of ensure

that testing should also include adequate backout testing to
ensure that other areas of the business and infrastructure
are not adversely affected by the change.

+The change process (Implementation of

a change )

RFC status

Change communicated to

The Change Implementer will change the status of the

request for change to AWAITING IMPLEMENTATION.

To ensure that the appropriate parts of the business, other

IT groups and the user are aware of changes that will
impact them the Change Implementer needs to ensure that
change is communicated at an appropriate time BEFORE
the change is implemented.

Date of change communication

The Change Implementer will update the request for

change form with the date the change communication was
sent.

+The change process (Implementation of

a change )

Scheduled implementation date

Date change actually implemented

The Change Implementer will update the request for change form
with the date the change implemented has been scheduled to take
place.

The Change Implementer needs to document in the request for

change form the date the change was actually implemented if
this is differently from the implementation date that was agreed
reasons for this change need to be documented here in the request
for change form. Details of who authorised the bringing forward or
delay of a change also need to be documented.

Issues encountered

Issues encountered during the change implementation need to be

documented. Even if issues are encountered that do not lead to the
use of the backout plan they must be documented to ensure that
they are known and discussed at the change review. These issues
need to be documented by the Change Implementer in the request
for change form.

+The change process (Implementation of

a change )

Backout plan implemented Y/N

If the backout plan was implemented this need to be documented

by the Change Implementer in the request for change form.

If the change was backed out the Change Implementer will change
the status of the RFC to CHANGE BACKED OUT.

Backout authorised by

If the change was backed out, The Change Implementer needs to

update the request for change form with the name of who
authorised the backout.

Change successfully implemented

The Change Implementer will change the status of the RFC to

IMPLEMENTED.

Once the Change Implementer has confirmed that the change

implementation is stable and all documentation is completed the
status of the request for change needs to be changed to AWAITING
REVIEW.

+The change process (Implementation of

a change )

The Change Manager role during change

implementation

The Change Manager has an overseeing role to ensure that

all changes are implemented according to the agreed
implementation dates prior to the agreed dates the
Change Manager needs to ensure that adequate resource is
provided to ensure implementation takes place.

The Change Manager also has the responsibility to check

daily the implemented changes and prepare both
Implemented and backout changes for review.

+The change process (Reviewing a

change)

After the change implementation has passed, the

Change Manager needs to review all changes that have
been set to a status of AWAITING REVIEW or CHANGED
BACKED OUT but the Change Implementer.

Date change reviewed

The Change Manager will update the request for change

form with the date the request for change was reviewed
prior to closure.

Review information

The Change Manager must review all implemented changes

after a predefined period has elapsed. This process may

still involve CAB members; change management may look

to them for assistance in the review process.

+The change process (Reviewing a

change)

Change reviews may be tabled at CAB meetings, for

CAB members information and to agree any follow up
action that may be needed. The purpose of such
reviews is to establish that:

The change has had the desired effect and met its
objectives

Users and customers are content with the results, or to

identify any shortcomings

There have been no unexpected or undesirable side effects

to functionality, availability, capacity/performance, security,
maintainability etc.

The resources used to implement the change were as

planned

The implementation plan worked correctly (so include

comments from the implementers)

The change was implemented on time and to cost

+The change process (Reviewing a

change)

Where a change has not achieved its objectives, the

Change Manager (or the CAB) should decide what
follow up action is required, which could involve raising
a revised RFC. If the review is satisfactory or the
original change is abandoned, the RFC should be
formally closed in the logging system.

Change successful

The change review team needs to decide the criteria on

which they base a successful change this will vary
according to the change being reviewed. The Change
Manager needs to be documented the final decision made
in the request for change form.

Change reviewed by

The Change Manager needs to document all those who

attended the change review.

+The change process (Reviewing a

change)

Backout plan deployed (if appropriate)

Changes that have been backout during implementation

need to be reviewed. If the backout plan was deployed
the success of the backout deployed needs to be
documented.

If for any reason the backout plan was deployed and it was
not successful this also needs to be documented with
details as to why it failed.

The Change Manager needs to inform the Change Initiator

that the change was unsuccessful. At this stage the Change
Manager will return the request for change back to the start
of the process and change the status to AWAITING REASSESSMENT.

Additional review details

The Change Manager needs to document any other

discussion points that were part of the change review as a

+The change process (Reviewing a

change)

Change to become a procedure

If the change is one that has been repeated on a number of

occasions the change review team need to assess it in line
with the option to make it a standard change (implemented
through a standard change or change model). If it is to
become a procedure it needs to be allocated to a team
member for writing and a review and implementation
timescale agreed.

Closing a change

The Change Manager need to ensure that the status of the

request for change needs to be changed to CLOSED to
completed the process.

Questions.???