Shop Direct Group – Team IT Service Management
Issue 2.0
November 2009
Change Management Policy
Version 2.0
D:\533577428.doc
Page 1
Shop Direct Group – Team IT Service Management
Issue 2.0
November 2009
DOCUMENT CONTROL
Document Control
Title
Author
Change Management Policy
John Fee
Document Approvers
Name
Role
John Fee
Change Management Manager
Kim Richardson
Vendor Manager and Service Desk
Terry Statham
IT Assurance
Rob Crompton
Client Services Manager
Alan Gellion
Technical Co-ordination
Tom Hunter
Data Centre Manager
Jo Fitzpatrick
IT Service and Operations Manager
Version
2.0
2.0
2.0
2.0
2.0
2.0
2.0
Date
December 2009
December 2009
December 2009
December 2009
December 2009
December 2009
December 2009
Document Signoff and Acceptance
** By providing signoff of this document you are confirming that you and your team have read
and FULLY understand the contents of this document.
You must also send an email confirmation of your acceptance to the IT Change Manager.
Name
Role
Version
Date
Bernard Thorne
IT Development Director
2.0
Neal Preece
eCommerce Development Director
2.0
Joe Galloway
Head of Core Development
2.0
Graham Christensen Head of Customer Development
2.0
Janet Bosworth
Head of Product Development
2.0
Phil Clark
Head of Information Systems Development
2.0
John Sheehan
Software Architecture
2.0
Tim Edwards
IT Infrastructure - Enterprise Services
2.0
Rhoma Bogg
IT Infrastructure – Wintel, Comms and E2.0
Comm
Suzie Williams
Group Change
2.0
Martin Cleator
Group Change
2.0
Version Control Log
Name
Details of Change
Abby Dalton
Sent out to Change Management team for
critique and review
Bernie Kenny
Amendments Made
Bernie Kenny
Amendments Made
Bernie Kenny
Amendments Made
John Fee
Overhaul to bring up to date with current
practice
Version
0.1
Date
06/02/2006
0.2
1.0
1.1
2.0
13/02/2006
31/03/2006
30/04/2006
09/11/2009
Update Frequency
This process will be scheduled for review at least annually. Updates should be made on an as
required basis between reviews.
D:\533577428.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.0
1.1
1.2
1.3
1.4
Purpose ..................................................................................................... 4
Background................................................................................................ 4
Intended Audience ..................................................................................... 4
Assumptions, pre-requisites and disclaimers ............................................. 4
Change Management Authority and Implications of Non Conformance...... 5
2. CHANGE MANAGEMENT POLICY ............................................................ 5
2.1 Policy Overview ............................................................................................... 5
2.2 General Policy ................................................................................................. 5
Generic Information ............................................................................................ 5
Requesting Changes .......................................................................................... 5
Emergency Change ............................................................................................ 7
Change Approval ................................................................................................. 8
Implementation .................................................................................................... 8
Closing Change ................................................................................................... 8
FSC Specific Policies.......................................................................................... 9
2.3 Peak Trading Additional Policy ........................................................................ 9
3 GLOSSARY ............................................................................................. 10
4 RELATED DOCUMENTS AND INTRANET PAGE LINKS ..................... 10
5 APPENDICES........................................................................................... 10
5.1 Scenarios for Emergency Change: ................................................................ 10
D:\533577428.doc
Page 3
Shop Direct Group – Team IT Service Management
Issue 2.0
November 2009
1 INTRODUCTION
1.0 Purpose
This document defines the guiding principles that underpin the delivery of Shop Direct Group
Change Management. This document refers solely to teamIT Services Change Management.
Any other change management processes and procedures used within the Shop Direct Group
(i.e. Group Change) will be subject to their own individual policies and controls.
This policy is part of a framework of documents that support the delivery of Change
Management. It should be read in conjunction with the Change Management Process and
Procedures.
1.1 Background
Rigorously applied Change Management process and procedures are fundamental in the
delivery of a reliable IT Service. Services Change Management is responsible for ensuring
that the stability and integrity of the services under their control and that the SLA’s attached to
these are not compromised as a result of change. Integral to ensuring the process functions
efficiently is that all stakeholders in the process are aware of the rules that are applied when
making changes.
Everyone who has a role to play in Change Management must adhere to the set of rules that
govern the operation of the Change Management process. It is this document, the Change
Management Policy that defines the boundaries in which the process operates and the rules
that must be adhered to by all that engage in it.
1.2 Intended Audience
As above, the policy outlined in this document is applicable to anyone wishing to:
Raise an Infrastructure RFC Change to
 DEVELOPMENT
 PPT
 PRODUCTION
Raise an Application RFC Change to
 PPT
 PRODUCTION
Raise an activity on the FSC.
 Log a Significant or Major business or IT event
1.3 Assumptions, pre-requisites and disclaimers
The Change Management team will only be responsible for the management of Change from
the point at which it is
 Logged on the Service management system for TI and Application Requests
It is assumed that the reader has access to the following:
 Change Management Process and Procedures
 Other supporting Information available via the Intranet
Further assumptions have been made:
 It is the responsibility of each and every team leader/manager to ensure that existing
and new team members have the required knowledge of the Change Management
process and the expectations set upon them in this document. Change Management
will assist where possible in this process by making helpful documentation available
and where required and by meeting with new starters individually or in small groups.
As above team leaders/managers are solely responsible for engaging the Change
Management team in this respect.
 It is the responsibility of the individual or their line manger to make Change
Management aware if they need to be part of any communications mail groups.
D:\533577428.doc
Page 4
Shop Direct Group – Team IT Service Management
Issue 2.0
November 2009
Change Management can only manage what they are aware of. Changes to the content of
RFCs and FSC Events must be notified to Change Management immediately.
1.4 Change Management Authority and Implications of Non Conformance
Change Management own the Change Management process and reserve the right to
challenge or reject change in line with the policies outlined in this document. Further to this
where conformance to this policy is questioned by the Change Analysts, escalation to the
Change Manager will occur. For serious or ongoing breaches in conformance to this policy,
Change Manager will make escalations and recommendations to the Senior Management
and Board. In the most serious cases, non-conformance can result in the invocation of the
Shop Direct Group HR disciplinary procedure.
2. CHANGE MANAGEMENT POLICY
2.1 Policy Overview
The Production Service Change Management Policy is based upon best practice as outlined
by ITIL and is further supported by the Change Management Process and Procedures. Any IT
and/or business area wishing to make a change to the Service Managed environments
detailed below MUST adhere to the guidelines laid out in this Policy document.
The General Policy is to be applied at all times and will be subject to a number of measures to
monitor conformance. In addition to this General Policy there are also specific times during
which additional policies will be applicable, e.g. during Peak Trading Period as defined by the
Board. Due to the fact that the implication of Service loss is greatly increased during these
times, additional rigour will be applied as per the details below.
2.2 General Policy
Generic Information
The Change Management Team operate and are contactable between the core hours of
08:30-16:45 Monday to Thursday and 08:30-16:15 on Friday. Critical incidents resulting in a
change outside of these core hours will be dealt with via the Incident Management process.
The following environments fall under the control of Production Change Management:
For Infrastructure Changes:
 Development
 PPT
 Production
For Application Changes:
 PPT
 Production
Exceptions to teamIT Change Management are as follows:
 TI Service Requests
All communications pertaining to Change Management and the process will be sent out by
the Change Management team or Senior Management.
Requesting Changes
Change Management are not responsible for the raising of RFCs.
Parties able to request change from Production Change Management:
Infrastructure Change – Infrastructure Teams, TSG, Networks, Cable & Wireless etc
D:\533577428.doc
Page 5
Shop Direct Group – Team IT Service Management
Issue 2.0
November 2009
Application Change – Systems Teams
FSC Events – Any party wishing to log a significant or major business event on the Change
Calendar
Shaw Changes to register mechanical handling changes or internal fail over tests are raised
by Shaw Admin
If you wish to request a change and are not one of the above detailed parties you must speak
to the department detailed above who will advise the process.
Third Parties are required to inform Change Management of planned change in line with the
Service Agreements documented. The LSDG second line support group that manages the
area to which the change is to be applied should manage requests for changes by third
parties. This includes the raising of the change.
All changes should be raised on the appropriate form (detailed below). Changes submitted
using any other media would be rejected:
Application Changes – Assyst
Infrastructure Changes – Assyst
FSC Event – Intranet Form
Every Infrastructure or Application change must be submitted with a completed CHIMP
(Change Impact form). RFCs submitted without the required CHIMP will be rejected. The
CHIMP determines the Risk and Impact of an RFC. A combination of Risk and Impact scores
determine the Seriousness (ITIL Category) of the RFC that in turn defines the approval route
the change will follow. All CHIMPS are validated by the Change Management Team and will
be challenged where not completed correctly or inaccurately.
Risk 1
(The likelihood of a change failing)
Change Seriousness
1
Impact
(The business
implication
should the risk
materialise)
High
Medium
Low
High
Major
Major
Significant
Medium
Major
Significant
Minor
Low
Significant
Minor
Minor
Required lead-times are determined by the Seriousness (ITIL Category) of the change.
Associated approval levels are also detailed in the table below:
Change
Seriousness
Lead Time Policy – Submission Dates
Authorisation Level Required
Earliest
Latest
Major
As soon as possible
> 4 calendar weeks
before proposed
implementation
Executive Management
(Via Change Management)
Significant
As soon as possible
> 3 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:\533577428.doc
Page 6
Shop Direct Group – Team IT Service Management
Issue 2.0
November 2009
When requesting an RFC it is important to ensure a sensible implementation time is detailed.
Optimum windows for the implementation of change vary by Service. Details of the operating
hours for each service are available in the Service Catalogue section on the Intranet and also
on the Box/Domains List also on the Intranet. http://isdev/Depts/CompOps/Services/index.htm
(this doesn’t seem to be valid?)
The appropriate level of information must be included in the change to allow the Change
Team to make an informed decision on whether to approve or not. This includes ALL
mandatory fields. For example, in the backout/reversion plan or impact field it is not sufficient
to put ‘Yes’. Detail should be written in a non-technical language. Changes deemed lacking in
detail would be rejected. Where a rejection happens the change is closed and must be reraised.
It is the responsibility of the request owner to ensure the content of the request is accurate
and up to date. Should the content change, it is the responsibility of the owner to inform
Change Management via the correct channels detailed in the procedure.
Changes that form part of a project must contain the Project reference number.
Changes that form part of a release must contain the release name.
Emergency Change
In the main all changes should be planned. It is inevitable however that situations will arise
where changes have to be implemented quicker than the prescribed lead times or to
circumvent or prevent an incident. Such Emergency changes should be kept to a necessary
minimum. These changes are planned, built and tested in a shorter space of time therefore
pose significantly higher risk during and following implementation.
All changes that do not fulfil the required lead-times (i.e. less that one calendar week or 7
days) will be channelled through the emergency route. All unjustified Emergency change
requests (i.e. bad planning etc) will be monitored and reported upon.
Any change that requires emergency implementation as a result of bad planning will be
recorded and reported against
In the event of a total Service outage, where restoration can be achieved through
Stop/Restart, Boot, Reload and there is no requirement for a change to the production
environment, we do not require a CHIMP or Change. Recovery/Restoration method should
always be recorded against the corresponding incident
In all other Emergency circumstances, approval must be sought from the IT Change Manager
prior to commencing the change unless it is a Major Incident whereby the Duty Service
Manager, acting as Major Incident Manager (MIM) has delegated authority from Change
Management to implement a change to circumvent the incident and raise retrospective
Change and CHIMP
Where an Emergency change is required to resolve an incident (production fix) the associated
Incident Reference must be included in the change detail
During prime shift a Change Request and accompanying CHIMP must be raised for
emergencies. Depending on the urgency of the requirement the IT Change Manager may
verbally authorise the work and agree to the retrospective raising of the appropriate Change
and CHIMP
Out of Hours the Duty Service Manager or Shift Manager has delegated authority from
Change Management to approve emergency changes that are to be implemented out of
D:\533577428.doc
Page 7
Shop Direct Group – Team IT Service Management
Issue 2.0
November 2009
hours to recover service or prevent service loss. Again a retrospective Change and CHIMP
must be raised.
Change Approval
For Minor change, Change Management is responsible for Approval. For Significant/Major
change or FSC Events it is the CAB that form the approval body.
The CAB convenes weekly on a Wednesday from 10:00 – 11:30. The CAB has a number of
mandatory attendees and optional attendees who vary depending on the agenda. Where a
mandatory attendee is unable to attend the CAB a deputy must be nominated and attend. The
deputy must be someone who has the appropriate level of authority and is empowered to,
and will make decisions in the absence of the mandatory attendee.
Pre-Approved Changes
For routine, low risk and low impact changes, a pre-approved process can be agreed and
used, to cut down on unnecessary administration. Change Management will monitor the
usage of pre-approved changes to ensure they are not being used for anything outside of the
agreed scope.
Implementation
The only means of getting authorisation to make a change to the environments controlled by
Change Management is via a fully approved RFC.
Changes must not be implemented without full approval. Change Management make best
endeavours to send approval notifications to implementers but it is the responsibility of the
change owner and implementer to ensure this request is fully approved prior to
implementation.
Out of Hours - Prior to beginning the implementation, the implementer must contact Shift
Operations 0151 432 3133 to notify them they are about to begin work. The implementer must
also contact Shift when they complete the change to notify the outcome and advise if there
were any issues during implementation.
The change must be implemented as per the approved details on the request. Most
specifically the date and time of the change is an important part of the considerations during
approval and should not be deviated from without notifying the Change Management team to
seek re-approval.
For all Change, an implementation task is assigned to the Implementer upon approval.
Immediately following the implementation, the Implementer must update the implementation
task that was assigned with the outcome of the change and deviations made from the record
and any issues that were experienced during implementation. Carrying out the update is part
of the implementation tasks and the implementation is not deemed complete until this has
occurred.
Closing Change
Changes will not be closed until the Implementer has provided the post implementation
update. The task owner is responsible for ensuring that their task is closed down in a timely
manner.
Any relevant information regarding the implementation should be noted in the task.
Change Management are solely responsible for the final closure of completed RFCs.
D:\533577428.doc
Page 8
Shop Direct Group – Team IT Service Management
Issue 2.0
November 2009
FSC Specific Policies
All business and IT events, that are major or significant in nature (e.g. end of season sale,
scheduled releases, planned power outages etc), should be logged on the Forward Schedule
of Change.
The relevant event owner, project or release manager is responsible for logging the event on
the FSC via an Intranet link.
This will automatically route an approval process to the appropriate area approver, and then
to Change Management for CAB approval.
CAB will assess the event, taking into account other events already logged for potential
clashes. The outcome of this will be acceptance, rejection, or referral to another event owner
for their sign off of any potential clash.
Changes to the details of FSC events must be notified to the Change Management Team
immediately by completing the Update form available on the Intranet page.
2.3 Peak Trading Additional Policy
Peak Trading Period occurs during early November through to Early January. The exact
dates are defined by the Board and published by Change Management several weeks prior to
its start.
During this period, the following guidelines are asked to be observed:






Please refrain from submitting changes, and for change approvers, from authorising
them, unless absolutely essential, and be prepared to justify that.
This applies to ALL production infrastructure and application changes.
The Change Impact (or Chimp) document submitted with all changes will have an
increased weighting applied for Impact, meaning more changes will be assessed as
Significant or Major. This will lead to more scrutiny being applied to them by Change
Management and the Change Advisory Board (CAB). Details of the Chimp to be used
during peak trading will be supplied.
Any changes which are assessed as potentially high risk and/or impact will be expected
to have had senior business support obtained before submission, by the relevant BEM,
Project Manager or PAM as appropriate. This should be clearly referenced within the
Change Record.
Change Management and the CAB will be assessing every change with the need to
protect stability of service during peak trading in mind, and reserve the right to challenge
or reject any change.
In any such cases, appeals should be taken by the relevant BEM, Project Manager or
PAM to the IT Services Manager for specific authorisation/arbitration.
D:\533577428.doc
Page 9
Shop Direct Group – Team IT Service Management
Issue 2.0
November 2009
3
GLOSSARY
FSC
-
Forward Schedule of Change
RFC
-
Request for Change
CAB
-
Change Advisory Board
ITIL
-
Information Technology Infrastructure Library (Best Practice)
CHIMP -
Change Impact Form
TSG
-
Technical Services Group
TI
-
Technical Infrastructure
PPT
-
Pre Production Test
HR
-
Human Resources
SLA
-
Service Level Agreement
OLA
-
Operational Level Agreement
4
RELATED DOCUMENTS AND INTRANET PAGE LINKS
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
5 APPENDICES
5.1 Scenarios for Emergency Change:
Scenario 1:
There is an Incident registered with the Helpdesk, the Production Service is down and
the need to Stop/Restart, Boot, Reload is the requirement to get the service back up
and running, but no change to the production environment is required.
Prime Shift/Out of Hours: NO Change Request / CHIMP is required to restore the Service
Scenario 2:
There is an Incident registered with the Helpdesk, the Production Service is down, but
there is a need to change settings etc to restore the service.
Prime Shift: Raise a CR/CHIMP via the normal CR process to register these actions and gain
Change authorisation to proceed. Depending on the urgency to restore the Service, Change
Management may verbally authorise and agree for the documentation to be raised as a
Retrospective Change Request / CHIMP.
D:\533577428.doc
Page 10
Shop Direct Group – Team IT Service Management
Issue 2.0
November 2009
Out of Hours: Contact Shift Operations who will seek approval for the Change to proceed
from the Duty Service Manager. The appropriate CR/CHIMP should then be raised for
Change Management to give retrospective Authorisation during prime shift.
Scenario 3:
There is an Incident registered with the Helpdesk and the Service is up for some but
not all users/applications.
Prime Shift: Duty Service Manager will co-ordinate an outage time that is favourable to the
business for a restoration of full service. Support Team raise a CR/CHIMP via the normal CR
process to gain Change authorisation to proceed. Depending on the urgency to restore the
Service, Change Management may verbally authorise and agree for the documentation to be
raised as a Retrospective Change Request/CHIMP.
Out of Hours: Contact Shift Operations who will seek approval for the Change to proceed
from the on call Duty Service Manager. The appropriate CR/CHIMP should then be raised for
Change Management to give retrospective Authorisation during prime shift.
D:\533577428.doc
Page 11