Shop Direct Group – Team IT Service Management
Issue 2.0
November 2009
Change Management Process
Version 2.0
D:\533577237.doc
Page 1
Shop Direct Group – Team IT Service Management
Issue 2.0
November 2009
DOCUMENT CONTROL
Document Control
Title
Author
Doc Ref
Change Management
John Fee
-
Document Approvers
Name
Role
Jo
Fitzpatrick
IT Service and
Operations Manager
Title
Version
2.0
Date
Version Control Log
Name
Details of Change
Derek Brown
John Fee
Derek Brown
John Fee
Derek Brown
John Fee
First draft for review
John Fee
Bernie Kenny
Bernie Kenny
Bernie Kenny
John Fee
Second draft incorporating feedback from
Kim Richardson & Terry Statham
Integrates Roles & Responsibilities and
Risk & Impact Assessment (both
documents agreed separately). Also,
introduces further input from John Fee
Tidy up, remove tracking etc
Final version for sign off
Updated with comments from Kim
Richardson
Heavily updated to reflect the work
carried out on the FSC and it’s
integration back into the overall process
Overhaul to bring up to date with current
practice, e.g. remove references to
redundant terms such as BOP, Project
Masters etc.
Version
0.1
Date
20/01/05
0.2
23/02/05
0.3
04/03/05
0.4
1.0
1.1
13/04/05
23/05/05
08/06/05
1.2
18/07/05
2.0
11/11/09
Update Frequency
This process will be scheduled for review at least annually. Updates should be made
on an as required basis between reviews.
D:\533577237.doc
Page 2
Shop Direct Group – Team IT Service Management
Issue 2.0
November 2009
Table of Contents
DOCUMENT CONTROL ................................................................................. 2
Document Control ................................................................................................. 2
Title ........................................................................................................................ 2
1 INTRODUCTION .......................................................................................... 4
1.1
1.2
Objectives and Scope ................................................................................ 4
Assumptions, pre-requisites and disclaimers .............................................. 5
2 ROLES AND RESPONSIBILITIES ............................................................. 6
2 FSC PROCESS ........................................................................................ 9
2.1
2.2
2.3
2.4
2.2
Inputs into the Process .............................................................................. 9
Outputs from the Process .......................................................................... 9
Management Information and Reporting & Metrics .................................... 9
Process improvement (Change Feedback Forum) ................................... 10
Process Diagram ..................................................................................... 11
3 PROCESS STEPS ..................................................................................... 12
Process Step 1.1 - Raise Request (0.1)............................................................ 12
Process Step 1.2 - Area Approval Verification and Approval (FSC Event requests
only) (0.2) ............................................................................................................ 12
Process Step 1.3 - Filter Request and Allocate Initial Priority (0.3) ..................... 13
Process Step 1.4 – Emergency Change Process (0.4) ........................................ 13
Process Step 1.5 – Categorise Based on Risk and Impact (0.5) .......................... 13
Process Step 1.6 – Minor Change and Pre-Approved Change (0.6) .................... 14
Process Step 2.0 - Approve Request.................................................................. 15
Process Step 2.1 – Close RFC as Rejected ........................................................ 15
Process Step 2.2 - Build Change ......................................................................... 15
Process Step 2.3 – Test Change ......................................................................... 16
Process Step 2.4 – Testing Successful (Decision) ............................................... 16
Process Step 2.5 – Authorise and Schedule Change .......................................... 16
Process Step 2.6 – Implement Change ............................................................... 16
Process Step 2.7 – Implementation Successful? ................................................. 16
Process Step 2.8 – Review and Close Change ................................................... 16
Process Step 2.9 – Management Information ...................................................... 17
5 Related Documents ................................................................................. 17
6 Glossary.................................................................................................... 17
7 Appendix 1................................................................................................. 18
D:\533577237.doc
Page 3
Shop Direct Group – Team IT Service Management
Issue 2.0
November 2009
1 INTRODUCTION
Change Management – A definition
“The object of Change Management is to ensure that standardised methods and procedures
are used for efficient and prompt handling of all Changes, in order to minimise the impact of
any related Incidents upon service.”
The Change Management process is required to protect the IT Production Service from
change-related incidents. It ensures that installation, modification or decommissioning of
computing, communications, procedural or environmental resources are implemented in an
orderly and controlled fashion. Equally, it assures our business customers are fully supportive
of the changes being implemented and the potential risk and impact it could have upon their
services. Further to this we require that all projects or business activities are logged to ensure
that Service have a comprehensive view of all activity across the business that:
1)
2)
3)
4)
5)
Has the potential to affect the availability of IT resource
Requires a change to the configuration of the current infrastructure
Requires Changes to the IT infrastructure to be made as part of the project delivery
Events that implicate IT in any way i.e. the implementation of a change freeze or chill
Business events that mean IT must take additional care of Service availability i.e.
Peak business times, Business promotions etc
The main principals of the Change Management process are:  Increased emphasis on ownership from change definition through implementation and
review
 Lead times specified on raising changes
 More emphasis on forward planning
 Stringent sign-off for changes which are raised “late”
 Structure and formality to risk and impact assessment/management
 Stronger engagement with the business for change awareness and sign-off
 Clarification of the role of IT Project Managers in gaining business acceptance for their
changes all the way through to implementation, including management of the associated
risks and potential impact. IT Project Managers will always gain full business approval
PRIOR to requesting change authorisation and subsequently on all change resubmissions.
 Recognition of the role of the Client Service Delivery Managers
 Increased membership and clarification of the role of the CAB as an approvals body
 Introduction of a formal Service Acceptance process
This document describes the process that underpins the Management of Change for Shop
Direct. The document should be read in conjunction with the Change Management Policy and
Procedures.
1.1 Objectives and Scope
The objective of this document is to ensure a standard and consistent understanding of the
Change Management process, its inputs and outputs and the interaction with it by Change
Management and the wider Shop Direct population.
Change Management will ensure that a standard process, as detailed in this document, is
employed to ensure the effective management of all changes to the Shop Direct
infrastructure. The scope of this process includes ensuring that changes are effectively
defined, assessed, prioritised, planned, communicated, approved, managed, tested,
scheduled, implemented, reverted (if necessary) and reviewed. Effective Change
Management will deliver a number of benefits to the Shop Direct Group.
D:\533577237.doc
Page 4
Shop Direct Group – Team IT Service Management
Issue 2.0
November 2009
These include:






The ability to deal with high volumes of change in an effective manner
Improved performance as measured by SLAs and KPIs
Reduction in the number of backed out/failed changes
Efficient back out of change where required
Increased productivity for the users of the Services
Reduction of unplanned downtime as a result of change
For the purposes of this document the full process will be explained. This is to give a
comprehensive end-to-end view of the Change Management Process.
The level of detail in this document should be such that would enable the reader to
understand the process without having to seek assistance. The document is relevant to all
resource that hold a stake in the Change Management process. These stakeholders form the
‘extended change team’. Roles and Responsibilities of all stakeholders are detailed in Section
2.
1.2
Assumptions, pre-requisites and disclaimers
It is assumed that the reader has access to the documentation that underpins the delivery of
this process. Further assumptions below have been made:

The responsibility for the raising of RFC’s and FSC Events resides within the scope of
which ever process/area is making the request
Change Management have final authority on the acceptance of requests based on the
verification criteria (detailed in the procedure document).
D:\533577237.doc
Page 5
Shop Direct Group – Team IT Service Management
Issue 2.0
November 2009
2 ROLES AND RESPONSIBILITIES
The following have been identified as stakeholders in the Change Management process. The
roles and responsibilities for each stakeholder are detailed below.
Change Initiator
The change initiator is responsible for the raising of RFCs or FSC Events using the specified
form and CHIMP
 Raise Request for Change (RFC), or Event as far in advance as possible, with line
management approval, and submit to Change Management using the appropriate input
mechanism
 Ensure that mandatory fields are completed with maximum available information
 Ensure that lead times as per policy are met. Seek sign-off for changes that fail to meet
defined lead times
 Provide as much information as possible on the request and ensure that information
grows as knowledge of the change increases
 Ensure there is a nominated owner to progress the request through to implementation
 Perform an assessment of risk and impact of proposed change in conjunction with
identified Change owner prior to submittal and include details in the Change
Change Owner/Project Manager
The technical change owner is the authority responsible for implementation and ensuring the
technical objective of the change is achieved within the scope and constraints specified. The
role includes:
 Take full responsibility for all aspects of the change from inception through to successful
implementation and post-implementation review where required
 Perform an assessment of risk and impact using the CHIMP alongside Change Requestor
prior submittal of an RFC to Change Management
 Actively manage/mitigate risk and impact identified to minimise effect on service
 Add information to the change record as the change progresses
 Attend CAB meetings for all Significant or Major Changes where required as the Change
Owner
 Review change detail and verify technical risk and impact assessment
 Ensure change is built effectively
 Ensure comprehensive testing is performed
 Seek approval and authority to proceed with implementation

Project Managers (typically for Application changes) will seek approval and
authorisation direct from the business

Other change owners will seek business approval and authority through
Change Management and the BSM or CSDM
 Manage the implementation of the change
 Advise detailed outcome of implementation in the change record
 Participate in post-implementation reviews as required
 Consider the implications of the change on Disaster Recovery (DR) or contingency
Change Management Team
The Change Management team have the responsibility of overseeing and administering
Changes throughout their entire lifecycle. The role includes:
 Central point of contact and responsibility for capturing change requests for all
infrastructure change (dev, PPT and PRD) and for application change to the PPT and
PRD environments
 Take specific responsibility in the process for:
Maintenance of the Forward Schedule of Change

Filtering all changes and agreeing relative priorities

Satisfying themselves that risk & impact assessment is valid

Approving and authorising minor changes
D:\533577237.doc
Page 6
Shop Direct Group – Team IT Service Management
Issue 2.0
November 2009





Arranging and chairing the weekly CAB, and Emergency CABs, to consider
significant and major changes

Ensuring Major changes are approved by Executive Management

Escalating issues with changes, as required

Referring rejected changes back to change owner

Scheduling changes

Being aware of change status following planned implementation date

Agreeing way forward with “failed” changes

Arranging post-implementation reviews as required and ensuring that lessons
learned are addressed

Producing Management Information on change
Own, and continually seek to improve, the Change Management process, ensuring that it
is fit for purpose, effective and efficient
Facilitate the Change Management process, ensuring that changes follow the various
steps and that all participants conform to the process and perform their respective roles
effectively, including:
Risk and Impact assessment and management

Adequate testing

Ensuring links between incidents/problems and changes
Ensure integration with other key processes, such as Incident, Problem, Release and
Configuration Management
Ensure the process is understood, and adhered to, by all staff responsible for change and
the wider Change team and stakeholders in the process
Change Implementer
The Implementer(s) is the individual(s) responsible for making the change(s) in the controlled
environment on the agreed date and at the agreed time. Implementers will typically be Shop
Direct Group personnel/contractors, but they may be third parties/external contractors. Their
role includes:
 Ensuring the change is fully authorised prior to implementation.
 Ensuring the change is implemented as per the agreed date and time
 Where implemented out of hours contacting the shift prior and post implementation
 In the event of problems invoking the required escalation
 In the event of problems ensuring the regression plan is followed
 Promptly updating the Change Management team of the outcome of the change
 Participating in Post Implementation Reviews or Daily Service Reviews as required
Change Advisory Board Members
 Meet weekly to consider significant and major risk/impact changes for approval and
authorisation
 Prepare for meeting by reviewing submitted changes thoroughly in advance of the
meeting, consulting with colleagues as necessary
 Approve/authorise or reject changes at the meeting considering from a business and
technical viewpoint
 Agree prioritisation and scheduling
 Attend emergency meetings, as required, to consider emergency change
 Review the Forward Schedule of Change for issues, conflicts etc.
Review major incidents as a result of change and ensure actions are in place to address
lessons learned
Area Approvers (FSC Events NOT RFC’s)
This is the party that approves the FSC entry or update prior to its submittal to Change
Management. This will be a member of one of the following groups (The Area Managers
below have nominated deputies who may also approve events):
Financial Services, HR/Publishing, CSC, Trading, Logistics, Maintenance Releases,
Technical Infrastructure and E-Commerce
D:\533577237.doc
Page 7
Shop Direct Group – Team IT Service Management
Issue 2.0
November 2009
Area approvers are solely responsible for the content of the entries and take ownership of the
events upon approval.
 Ensure timely approval of all requests sent by the Assyst Tool including a review of the
current content of the FSC to look for obvious clashes
 Attempt to address clashes prior to submittal to change management
 Ensure the content of the request is accurate and comprehensive
Senior Management (Escalation Point)
Where an agreement on scheduling clash cannot be made at the CAB, Senior Management
will act as escalation and resolve the issue.
D:\533577237.doc
Page 8
Shop Direct Group – Team IT Service Management
Issue 2.0
November 2009
2
2.1
FSC PROCESS
Inputs into the Process
There are 2 inputs into the Change Management process:
1) RFC
Requests for Change – TI Change or Application Change
RFC’s that are significant or major should also appear on the FSC. RFC’s that are of
minor seriousness are not displayed on the FSC unless specifically requested by the
initiator.
Method Used to Raise RFC: Assyst
2) Event Request
An event is something of significance occurring within the business/IT that does not
require an RFC to implement. Examples of this are Sales and Peak Trading periods. An
event should be thought of as an occurrence over one or more days that affects the
availability of resource, the ability for changes to be made or potentially the stability of the
IT Infrastructure.
Method used to raise Event: Intranet Form
All inputs are held and managed in Assyst. Please refer to the associated procedures for
details of how to complete the appropriate forms.
2.2
Outputs from the Process
The outputs from the process are:
1) Approved and Implemented Changes TI Changes and ACN's/Project Master
Changes or Events
This is the end product. The output from the Change Management process is ultimately
implemented RFCs
2) Forward Schedule of Change
The Forward Schedule of Change is an output from the Change Management system that
details all approved events and proposed significant or major RFCs in a calendar format.
It is an Assyst driven HTML Intranet page that:
 Allow requestors to view planned works on given dates to assist in scheduling. Based
on the calendar they are able to see optimum times to request for the work to go
ahead.
 Is used by the CAB members and other approval bodies when considering the risk
and impact of a proposed piece of work.
 Senior management use the FSC as a definitive guide as to what work is planned
3) Management Information and Reporting
See section 2.3 below.
2.3
Management Information and Reporting & Metrics
It is essential that the Change Management team are able to assess the efficiency and
effectiveness of Change Management process on an ongoing basis. Such measures ensure
that the process is fit for purpose. The ability to audit the process and users of the process for
compliance in light of the published policies is also of great importance. This is achieved
through the regular production of Management Information and report.
The reports will be produced at varying frequencies and used to measure the following:
D:\533577237.doc
Page 9
Shop Direct Group – Team IT Service Management
Issue 2.0
November 2009











Daily Changes (can be parameterised)
Seriousness of Changes
Change Failures
Change Authorisations
Open and Unscheduled Changes
Open and Schedulde Changes
Emergency Changes
SVD Failures
Monthly Changes
Test Pipe Changes
Various different analyses
Reports will also be produced to monitor conformance to the Process.
2.4
Process improvement (Change Feedback Forum)
In the interests of ensuring all aspects of the end to end Change Management Process are
robust, effective and efficient on an ongoing basis, regular reviews and audits are carried out
by the Change Management Team. The Management Information and reports play a key role
in the measurement of its success but a number of other techniques, as determined by the
Change Manager, will be deployed to gather the required information. Should the process fail
to meet the required level of performance, the Change Manager will be responsible for
investigating the reason for the failure and initiating a Process Improvement Plan to resolve it.
This activity ensures that Change Management are able to fulfil the needs of the overall
organisation by managing change effectively on an ongoing basis.
All stakeholders in the process are able to make a contribution to how the process can be
improved, or to raise any issues of inefficiencies that may be experienced, via the Change
Feedback Forum. This is an Area on the Intranet site where questions, comments feedback
etc can be posted.
The maturity of the Change Management process will inevitably evolve over time. Any
changes to working practice or to the Process will be thoroughly communicated.
D:\533577237.doc
Page 10
Shop Direct Group – Team IT Service Management
Issue 2.0
November 2009
Area Approver /
Team Leader
Requestor
2.2
Process Diagram
0.1
Raise Request
No
0.3
Verification and
Approval
Approved
Yes
Change Management
0.3
Filter Request
and Allocate
Initial Priority
No
0.6 Standard/
Minor
Change
Management
authorise and
schedule
1.1Close RFC
as Rejected
2.1
Management
Information
No
Is it Urgent?
No
0.5
VerifySeriousn
ess based on
Impact/Risk
0.7 Significant
Authorised and
Sched by CAB
0.8 Major
Auth and Sched
by CAB/Senior
Management
1.0
Approve
Request
1.7
Authorise and
Schedule Change
Implementation
Approve?
Authorised?
No
Yes
y
0.9 FSC Event
Backed out/
Failed?
CAB Approval
1.0
Update
Change
y
yes
CAB
Yes
Change Build
and Test
Approve?
Implementor
Build Change
Test Change
n
D:\533577237.doc
Page 11
2.0
Close Change
Yes
no
Yes
0.4
Emergency
Change
Process
1.9
Implementatio
n successful?
1.6
Testing
Successful?
1.8
Implement
Change
2.2
PIR as
Appropraite
Shop Direct Group – Team IT Service Management
Issue 2.0
November 2009
3 PROCESS STEPS
This section provides a breakdown of the Change Management process.
Process Step 1.1 - Raise Request (0.1)
A Request for Change be it TI or Application can be raised by anyone (typically within
Systems or TSG) who requires a change to the IT infrastructure, systems and/or applications.
Before the change is submitted to Change Management it requires authorisation by the
Change Initiator’s line manager. The Change Initiator is normally the “owner” of the change
and is responsible for its success. If it is not appropriate for the Change Initiator to own the
change, an alternative owner must be identified on the RFC. A request can be made on
raising to display an RFC on the FSC.
The Implementer can be any party wishing to make a change to the IT infrastructure or log an
FSC event within the scope identified earlier in the document. All requests MUST be
accompanied by a CHIMP (appendix *). Changes submitted without the CHIMP will be
rejected.
For each type of input there is a minimum level of detail required to process the request. For
details of mandatory fields please refer to the appropriate forms.
Requests that do not have the required information will be rejected.
The RFC will be raised on the Change Management system (Assyst), and a unique
identification number is allocated. Any RFCs, which are being raised as a result of an
incident or a problem, should have a reference to the requisite incident/problem record.
Requests for Change should be raised as early as is practical - to enable prompt identification
of risk and potential scheduling conflicts. Early and clear notification of changes that are
business/date critical is important. For projects, this would typically be when the PRD has
been signed off.
Since Project Managers will typically already be engaged with the business, they will be
seeking business support as the project evolves into change(s).
Following the signoff of a PRD, an FSC Event should be raised via the FSC Intranet forms.
This is a high level record that details the project details, scope etc and the anticipated go live
date. All related RFCs required to implement the project should be raised separately via
Assyst. This relationship must be identified by the Initiator and the correct Project Reference
number supplied.
Service Acceptance will check as part of their assurance role that an FSC Event has been
raised. It is recognised that detail at an early stage is likely to be limited. However, the
following minimum mandatory fields will provide early warning of the request – additional
information should be provided as the change develops.
o Project Name
o Project Ref. No.
o Project Owner/Prime Contact
o Brief Description
o Indicative Dates for Implementation
Process Step 1.2 - Area Approval Verification and Approval (FSC Event requests only)
(0.2)
Area approvers and associated deputies have been agreed and are identified by role in
section 1.3.
All requests to raise a new entry or update an existing entry on the FSC must be approved by
an Area Approver prior to their submittal to Change Management for inclusion on the FSC.
D:\533577237.doc
Page 12
Shop Direct Group – Team IT Service Management
Issue 2.0
November 2009
Each request, be it a new entry or an update must be completed according to requirements
and all fields populated with valid information (refer to the Area Approver CRIB sheet for
further details). The request must then be either ‘Approved’ or ‘Rejected’. For further details
on the procedure for Area Approval follow the link to Area Approver CRIB sheet
Process Step 1.3 - Filter Request and Allocate Initial Priority (0.3)
Upon receipt of a request, Change Management perform verification steps to ensure the
minimum information requirements have been met. Requests submitted to Change
Management with incorrect information or with key information omitted will be rejected. If the
Change is accepted the initial priority is agreed with the initiator.
Priority is the order in which changes will be progressed and relates to the impact of the issue
that the change is being raised to resolve. Whilst all changes should arrive with a date
attached, prioritisation is mainly used to help address conflict situations.
Priorities are:Immediate – causing loss of service or severe usability problems to a large number
of customers (would typically be a high impact incident). Emergency requirement for
change due to unforeseen business requirement. If the request is an Emergency it
follows the Emergency process as per step below. If the request is non emergency it
progresses through the normal process.
High – severely affecting some users. Important change to address urgent business
requirement.
Medium – no severe impact, but rectification cannot be deferred until the next
scheduled release or upgrade.
Low – no business impact. Change can wait until next scheduled release or upgrade.
Process Step 1.4 – Emergency Change Process (0.4)
Should the change be designated as “immediate”, it would be raised as an emergency
change and follow a fast track approach. An Emergency Change is defined as a change that
is required urgently to resolve issues with critical business processing/online system
availability that is either halted/not available, inaccurate or incomplete.
Emergency changes are handled in a very similar way as normal changes except, depending
on the urgency of the requirement, the change may be undertaken prior to the normal
procedures being followed. In such cases, written (via email) or even verbal authorisation in
extreme cases will be given by an appropriate senior level for the change to proceed, and the
process will then be followed retrospectively. In some cases, if the potential impact/risk of the
problem and/or fix is great, an ad hoc CAB will be convened to consider the change and
approve the course of action. The subsequent change record will be flagged on Assyst as an
emergency change for reporting purposes.
Out of hours, changes are considered and authorised by the Shift Controller, consulting as
necessary with duty service managers, senior management and/or BSM(s). A retrospective
change record must be raised.
Process Step 1.5 – Categorise Based on Risk and Impact (0.5)
Based on the risk and impact of a change, the change is categorised into Minor, Significant or
Major.
Risk is defined as the likelihood of a change failing.
Impact is the business implications should the risk materialise.
Assessment of risk and impact will be performed by the change owner based on the set of
questions in Appendix 1.
D:\533577237.doc
Page 13
Shop Direct Group – Team IT Service Management
Issue 2.0
November 2009
Risk
High
Medium
Low
Impact
High
Major
Major Significant
Medium
Major Significant Minor
Low Significant Minor
Minor
Authorisation levels are based upon the assigned category and would result in the following
authorities being required:Major – Executive Management (via Change Advisory Board)
Significant – Change Advisory Board (via Change Management)
Minor – Change Management
There are two stages to change authorisation. The first stage is “approval” and the second
stage is “authorisation”. In the “approval” phase, agreement (or otherwise) is being granted at
an early stage in principal based upon the information provided on the RFC and considering
whether there are any conflicts with other changes in the FSC. As well as agreement within
IT, agreement with the business should be sought.
The “authorisation” stage is much closer to implementation and is described more fully in step
008.
Project driven (typically application) change will already carry pre-authorisation by the
business (secured by the Project Manager). All other changes will seek business agreement
via Change Management in conjunction with the BSM(s)/CSDM(s).
The authorisation process considers technical and business matters. Change Management
will involve all parties who can contribute to this authorisation process, whether by requesting
their input through the Change Management tool or talking to them. Contributors will vary
from change to change, but examples are business representatives, technical services teams
and operations to name but three.
The CAB is the IT approvals body and meets weekly to consider major and significant
changes for approval. At this stage in the change life cycle, it is considering change approval
in principal, since the build and test phase has not been completed. The CAB will review the
Forward Schedule of Change as well as specific changes of a relevant category.
The CAB should comprise the following representatives: Change Manager
 Data Centre Manager
 Problem Manager
 Help Desk Manager
 Client Facing Manager/relevant CSDM(s)
Relevant change owners by invitation (for major changes and as required by Change
Management)
If the change is categorised as Minor Impact, go to process step 1.6
If the change is Significant, go to process step 1.7
If the change is Major, go to process step 1.8
Process Step 1.6 – Minor Change and Pre-Approved Change (0.6)
Minor changes must be submitted at least one week ahead of the proposed implementation
date. Changes that fail to be raised with this lead-time require agreement from Change
Management before they may proceed.
The changes are authorised by Change Management in conjunction with technical and
business contacts relevant to the nature of the change. The cumulative risk of changes
scheduled for the same period must be considered at this stage.
D:\533577237.doc
Page 14
Shop Direct Group – Team IT Service Management
Issue 2.0
November 2009
Minor changes that are regular and routine, such as data fixes, can go via a pre-approved
route. This means that the type of change to be undertaken has pre-approval from an
authorising manager, and therefore does not have to follow an approval process each time
one is raised, cutting down on admin overheads. By definition, these are low risk and low
impact, and therefore do not require a Chimp. They will be monitored for abuse, so that they
are not used for changes which should follow a normal change approval/assessment process.
Process Step 1.7 – Significant Change (0.7)
Significant changes must be submitted at least four weeks ahead of the proposed
implementation date. Changes that fail to be raised with this lead-time require agreement
from the Production Services Director before they may proceed.
The changes are considered as above and submitted to the CAB for consideration. The CAB
brings a wider and more senior focus to changes and sits once per week as the formal IT
Change Approvals body. All significant Changes should be displayed on the FSC.
Changes being considered by the CAB are circulated three days in advance of the meeting,
to provide members with the opportunity of consulting with colleagues prior to the meeting.
Process Step 1.8 – Major Change (0.8)
Major changes must be submitted at least three months ahead of the proposed
implementation date. Changes that fail to be raised with this lead-time require agreement
from the IT Services Director before they may proceed.
These changes are also considered by the CAB but are then referred to executive
management for sign-off. Typically, this would involve the IT Services Director who would
decide whether the change warranted agreement by the CIO. Similarly, in the business, a
senior level of sign-off will be sought.
Project (business) driven changes will already carry this authority.
For all other changes, business agreement will be sought in advance of the CAB by Change
Management in consultation with the BSM(s) or CSDM(s). All Major Changes are displayed
on the FSC.
Process Step 1.9 – FSC Event (0.9)
All FSC events as defined in this process require CAB discussion and approval prior to their
inclusion on the FSC.
Process Step 2.0 - Approve Request
Change receives either “Approval” or ”Authorisation” dependant upon level of detail provided.
The FSC should carry this identifier. If the change is approved, it continues to be built and
tested (the likelihood is that this has proceeded in parallel with the authorisation process).
Should the change not be approved, Change Management provides the Change Owner with
the reasons. The Change Owner is responsible for addressing concerns raised and resubmitting the change with appropriate support for date etc
Process Step 2.1 – Close RFC as Rejected
If the request is rejected in the CAB the requestor (and Area Approver for FSC Events) should
be notified. Following their notification the record should be closed.
Process Step 2.2 - Build Change
The change is built and tested. Accountability rests with the Change Owner to deliver the
change exactly as per their RFC. Deviations demand re-submissions.
D:\533577237.doc
Page 15
Shop Direct Group – Team IT Service Management
Issue 2.0
November 2009
It is recognised that changes can be built and tested by different parties, including suppliers.
Through interface with the separately defined Service Acceptance process, progress should
proceed through Service Acceptance gateways, various stages of testing, including “PreProduction” and “go/no-go” meetings.
Process Step 2.3 – Test Change
If testing has been successful and the above gateways have been passed, the change
proceeds for Final Change Authorisation to the relevant authority (see 004 above).
Backout testing is a key element of the testing phase. Should this testing not be possible, the
minimum requirement is a robust reversion plan.
Where there are issues, the change is taken back through the build and test phase.
Process Step 2.4 – Testing Successful (Decision)
Confirmation of Successful testing should be received prior to the change progressing. The
change may need to go through several iterations at this point, ie require a rebuild if the
testing is not successful.
Process Step 2.5 – Authorise and Schedule Change
At this stage the change is being considered for final authorisation. The difference this time is
that all the detail on the change, and other changes scheduled for the same time will have
been made available. This occurs typically, in the week(s) leading up to implementation.
Process Step 2.6 – Implement Change
The change is implemented according to the details specified on the request. The change
implementer should notify Operations Shift Management immediately prior to and following
implementation.
Process Step 2.7 – Implementation Successful?
Positive confirmation is given to Change Management by the Change Owner that the change
has been successfully implemented and adequately proven in the live environment. The
change implementer’s responsibilities include informing Operations Shift Management of the
success or failure of a change and raising an incident log for failed changes. Operations
advise the status of overnight changes in their morning service report.
Should there be issues, the implementation will either not have gone ahead, will have been
backed out and/or have incidents raised against it. As soon as practical, the preferred course
of action will be proposed by the Change Owner. Change Management will consider it in light
of the risks it presents to service delivery (as a whole) and prevailing business needs,
involving other parties as necessary. IT Project Managers will retain responsibility for
business liaison of their change with Change Management and the BSM(s) or CSDM(s) for all
other changes.
Process Step 2.8 – Review and Close Change
All changes will be reviewed prior to closure however post-implementation reviews will be
held in every case where a major incident has arisen as a result of a change. In addition,
consideration should be given to holding a PIR for complex changes, which have been
successful. Change Management have the authority to request active participation in a Postimplementation review on changes of their choosing.
D:\533577237.doc
Page 16
Shop Direct Group – Team IT Service Management
Issue 2.0
November 2009
The objective in every case will be to identify lessons learned which could be applied to the
process in future. Appropriate lessons learned will be published for inclusion in ongoing/future
changes.
The change is closed when the Change Owner can satisfy Change Management that the
change has been implemented successfully and has met the needs of the business. In
extreme situations IT Services may request that Service Levels be suspended, should the
change have been implemented against their express recommendation.
Process Step 2.9 – Management Information
Management information is produced by Change Management on a weekly and monthly
basis. The reports produced can be seen in section 2.3. The reports have a variety of
purposes but ultimately monitor the performance of and the conformance to the Change
Management process.
5 Related Documents
Up to date links to various items of change documentation, reports, crib sheets and the
Forward Schedule of Change can be found on the Change Management Intranet page.
CHANGE Management Intranet Page
http://isdev/depts/CompOps/Services/Changemanagement/index.htm
6 Glossary
BAU
Business As Usual
FSC
Forward Schedule of Change
HR
Human Resources
ITIL
Information Technology Infrastructure Library
RFC
Request For Change
R&R’s
Roles and Responsibilities
TI
Technical Infrastructure
BSM
Business Systems Manager
CAB
Change Advisory Board
CIO
Chief Information Officer
ITPO
IT Programme Office
PRD
Project Registry Document
RFC
Request for Change
CSDM
Client Service Delivery Manager
TSG
Technical Services Group
D:\533577237.doc
Page 17
Shop Direct Group – Team IT Service Management
Issue 2.0
November 2009
7 Appendix 1
Risk 1
(the likelihood of a change failing)
Change Seriousness
Impact 1
(the business
implication
should the risk
materialise)
Change
Seriousness
High
Medium
Low
High
Major
Major
Significant
Medium
Major
Significant
Minor
Low
Significant
Minor
Minor
Lead Time Policy – Submission Dates
Authorisation Level Required
Earliest
Latest
Major
As soon as possible
> 3 calendar months
before proposed
implementation
Executive Management
(via Change Management)
Significant
As soon as possible
> 4 calendar weeks
before proposed
implementation
Change Advisory Board
(via Change Management)
Minor
As soon as possible
> 1 calendar week before
proposed implementation
Change Management
D:\533577237.doc
Page 18