03 - ITIL V3 2011 Service Transition ST-1-109

Service providers must implement changes to support the
changing needs of the business. They must ensure that these

changes deliver the value that the business expects, while
protecting existing services from negative impacts. To do
this successfully requires efficient planning, so that new or
changed services can be delivered with the appropriate
balance of speed, cost and safety and with minimal disruption
to operations.
ITIL Service Transition provides guidance on managing

the many aspects of service change, preventing undesired
consequences while allowing for innovation. It is essential
reading for anyone seeking to deliver IT change with the best
possible outcomes for the business.
ITIL® Service Transition

ISBN 978-0-11-331306-8
ANAGE
TM
ME
BES
2011 edition
NT PRAC
T
9 780113 313068 www.best-management-practice.com
UC
TIC
E PROD
7188 ITIL ST AN Cover V0_3.indd 1-3 11/07/2011 11:05

London: TSO
7267 ITIL-ServiceTranslation v0_1.indd 1 11/07/2011 15:41

Published by TSO (The Stationery Office) and available from:
Online
www.tsoshop.co.uk
Mail, Telephone, Fax & E-mail

TSO
PO Box 29, Norwich, NR3 1GN
Telephone orders/General enquiries: 0870 600 5522
Fax orders: 0870 600 5533
E-mail: [email protected]
Textphone 0870 240 3701
TSO@Blackwell and other Accredited Agents
Customers can also order publications from:

TSO Ireland
16 Arthur Street, Belfast BT1 4GD
Tel 028 9023 8451 Fax 028 9023 5401
© Crown Copyright 2011
This is a Crown copyright value added product, reuse of which requires a Licence from the
Cabinet Office
Applications to reuse, reproduce or republish material in this publication should be sent to

The Efficiency & Reform Group Service Desk, Cabinet Office, Rosebery Court, St Andrews Business
Park, Norwich, Norfolk NR7 0HS Tel No: (+44) (0)845 000 4999,
E-mail: [email protected] or complete the application form on the Cabinet Office
website, Licensing section.
Copyright in the typographical arrangement and design is vested in The Stationery Office Limited.
Applications for reproduction should be made in writing to The Stationery Office Limited, St
Crispins, Duke Street, Norwich, NR3 1PD.
The Swirl logo™ is a trade mark of the Cabinet Office

ITIL® is a registered trade mark of the Cabinet Office
PRINCE2® is a registered trade mark of the Cabinet Office
M_o_R® is a registered trade mark of the Cabinet Office
P3O® is a registered trade mark of the Cabinet Office
MSP® is a registered trade mark of the Cabinet Office
MoV™ is a trade mark of the Cabinet Office
MoP™ is a trade mark of the Cabinet Office
The OGC Official Product endorsement logo™ is a trade mark of the Cabinet Office
OGC (former owner of Best Management Practice) and its functions have moved into the
Cabinet Office part of HM Government - www.cabinetoffice.gov.uk
First edition Crown Copyright 2007

Second edition Crown Copyright 2011
First published 2011
ISBN 9780113313068
Printed in the United Kingdom for The Stationery Office.

Material is FSC certified and produced using ECF pulp.
Sourced from fully sustainable forests.
P002425500 c70 07/11

Contents
List of figures v 4.6 Change evaluation 175

4.7 Knowledge management 181
List of tables vii
5 Managing people through service
Forewordviii
transitions197
Prefaceix 5.1 Managing communications and
commitment199
Acknowledgementsxi
5.2 Managing organization and
1 Introduction 1 stakeholder change203
1.1 Overview 3 5.3 Stakeholder management 215
1.2 Context 6 6 Organizing for service transition 219

1.3 ITIL in relation to other publications 6.1 Organizational development 221
in the Best Management Practice
portfolio8 6.2 Functions 221
1.4 Why is ITIL so successful? 10 6.3 Organizational context for

transitioning a service222
1.5 Chapter summary 10
6.4 Roles 223
2 Service management as a practice 13 6.5 Responsibility model – RACI 234
2.1 Services and service management 15 6.6 Competence and training 234
2.2 Basic concepts 22 6.7 Service transition relationship with
2.3 Governance and management other lifecycle stages 236
systems27
7 Technology considerations 239
2.4 The service lifecycle 30
7.1 Knowledge management tools 242
3 Service transition principles 35 7.2 Collaboration 242
3.1 Policies for service transition 37 7.3 Configuration management system 243
3.2 Optimizing service transition
performance45 8 Implementing service transition 245
3.3 Service transition inputs and outputs 46 8.1 Key activities in the introduction of
service transition 247
4 Service transition processes 49 8.2 An integrated approach to service
4.1 Transition planning and support 51 transition processes 250
4.2 Change management 60 8.3 Implementing service transition in

a virtual or cloud environment 250
4.3 Service asset and configuration
management 89 9 Challenges, critical success factors
4.4 Release and deployment
and risks253
management114 9.1 Challenges 255
4.5 Service validation and testing 150 9.2 Critical success factors 255

iv | Contents
9.3 Risks 256 C.12 Skills Framework for the

Information Age 286
9.4 Service transition under difficult
conditions256 C.13 Carnegie Mellon: CMMI and
eSCM framework286
Afterword261
C.14 Balanced scorecard 286
Appendix A: Description of asset types 265 C.15 Six Sigma 287
A.1 Management 267
Appendix D: Examples of inputs and
A.2 Organization 267 outputs across the service lifecycle 289
A.3 Process 267
References and further reading 293
A.4 Knowledge 267
Abbreviations and glossary 297
A.5 People 268
A.6 Information 268 Index339
A.7 Applications 268
A.8 Infrastructure 268
A.9 Financial capital 269
Appendix B: Risk assessment

and management271
B.1 Definition of risk and risk
management273
B.2 Management of Risk (M_o_R) 273
B.3 ISO 31000 274
B.4 ISO/IEC 27001 275
B.5 Risk IT 276
Appendix C: Related guidance 279

C.1 ITIL guidance and web services 281
C2 Quality management system 281
C.3 Risk management 282
C.4 Governance of IT 282
C.5 COBIT 282
C.6 ISO/IEC 20000 service management
series283
C.7 Environmental management and
green/sustainable IT 283
C.8 ISO standards and publications for IT 284
C.9 ITIL and the OSI framework 284
C.10 Programme and project
management285
C.11 Organizational change 285

List of figures
Figure 1.1 The ITIL service lifecycle 3 Figure 4.8 Example of relationships
between the CMS and SKMS 94
Figure 1.2 The scope of service transition 5
Figure 4.9 Example of the application of the
Figure 1.3 ITIL’s relationship with other
architectural layers of the CMS 96
Best Management Practice guides 9
Figure 4.10 The relationship between the
Figure 2.1 Conversation about the definition
definitive media library and the
and meaning of services 16
configuration management
Figure 2.2 Logic of value creation through system99
services20
Figure 4.11 Typical service asset and
Figure 2.3 Sources of service management configuration management
practice21 activity model101
Figure 2.4 Examples of capabilities and Figure 4.12 Example of a configuration
resources23 breakdown for an end-user
Figure 2.5 Process model 23 computing service 103
Figure 2.6 The service portfolio and its Figure 4.13 Example of a configuration
contents27 breakdown for a managed
virtual system103
Figure 2.7 Architectural layers of an SKMS 28
Figure 4.14 Example of service lifecycle
Figure 2.8 Plan-Do-Check-Act cycle 29 configuration levels and
Figure 2.9 Integration across the service baseline points108
lifecycle32 Figure 4.15 Simplified example of an IT
Figure 2.10 Continual service improvement infrastructure108
and the service lifecycle 33 Figure 4.16 Example of a configuration
Figure 4.1 Scope of change management item lifecycle110
and release and deployment Figure 4.17 Simplified example of release
management for services 62 units for an IT service 116
Figure 4.2 Example of a process flow for a Figure 4.18 Architecture elements to be built
normal change70 and tested117
Figure 4.3 Example of a process flow for Figure 4.19 Example of a release package 118
standard deployment request 71
Figure 4.20 Coordinating the deployment
Figure 4.4 Example of a process flow for a of service components 119
standard operational change
request71 Figure 4.21 Options for ‘big bang’ and
phased deployment120
Figure 4.5 Example of a change
authorization model78 Figure 4.22 Phased deployment across
geographical locations 121
Figure 4.6 Interfaces between change
management and service asset Figure 4.23 Phases of release and
and configuration management 87 deployment management123
Figure 4.7 Example of a logical Figure 4.24 Example of service testing

configuration model93 through service transition 134

vi | List of figures
Figure 4.25 Example of a set of Figure 6.2 Example of service transition

deployment activities138 organizational structure for a
larger organization222
Figure 4.26 Example of early life support
activities144 Figure 6.3 Example of service transition
organization and its interfaces 223
Figure 4.27 Illustration of the benefits of
targeted early life support 145 Figure 6.4 Organizational interfaces for a
service transition224
Figure 4.28 Dynamics of a service model 153
Figure 6.5 Flow of experience 236
Figure 4.29 Design constraints driven by
strategy154 Figure 8.1 Steps to improving the service
transition processes 247
Figure 4.30 Designing tests to cover a range
of service assets, utilities and Figure 8.2 An example of a path through the
warranties162 processes that might be required
for a single service transition 251
Figure 4.31 Example of a validation and
testing process169 Figure B.1 The M_o_R framework 274
Figure 4.32 Performing test activities – an Figure B.2 ISO 31000 risk management
example171 process flow275
Figure 4.33 Change evaluation process flow 177 Figure B.3 ISACA Risk IT process framework 277
Figure 4.34 Context for qualification and
validation activities 179
Figure 4.35 The flow from data to wisdom 184
Figure 4.36 Relationship of the CMDB, the
CMS and the SKMS 185
Figure 4.37 Examples of data and information
in the service knowledge
management system 186
Figure 4.38 Contribution of knowledge to
effectiveness of support staff 195
Figure 5.1 Example of a communication
strategy and plan contents 201
Figure 5.2 Example of a communication
path202
Figure 5.3 Example of service transition
steps for outsourcing203
Figure 5.4 The emotional cycle of change 204
Figure 5.5 Potential stakeholders 216
Figure 5.6 Example of a stakeholder map 217
Figure 5.7 Power impact matrix 217
Figure 5.8 Example of a commitment
planning chart218
Figure 6.1 Example of service transition
organizational structure for a
small organization222

List of tables
Table 2.1 The processes described in each Table 5.4 Organizational role and skills
core ITIL publication 31 assessment checklist 210
Table 3.1 Service transition inputs and Table 5.5 Example of a feedback survey 211
outputs by lifecycle stage 46
Table 5.6 Tips for managing change 212
Table 4.1 Example of a responsibility matrix
Table 5.7 J. P. Kotter’s ‘eight steps to
for release points during service
transform your organization’ 213
transition53
Table 6.1 An example of a simple RACI
Table 4.2 Extract from a service release
matrix234
policy for a retail organization 55
Table 4.3 Example of types of request by
service lifecycle stage 66
Table 4.4 Example of contents of change
documentation72
Table 4.5 Example of a change impact and
risk categorization matrix 75
Table 4.6 Change priority examples 76
Table 4.7 Configuration documentation
for assets and responsibilities
through the service lifecycle 106
Table 4.8 Levels of configuration for build
and testing125
Table 4.9 Questions to be answered when
planning deployment 128
Table 4.10 Examples of service test models 157
Table 4.11 Service requirements, 1: improve
user accessibility and usability 158
Table 4.12 Examples of service management
manageability tests 165
Table 4.13 Key terms that apply to the
change evaluation process 176
Table 4.14 Factors to consider when assessing
the effect of a service change 178
Table 5.1 Job characteristics that motivate
people203
Table 5.2 Understanding the culture of
the parties involved 207
Table 5.3 Example of a RACI matrix for
managing change 209

Foreword
Back in the 1980s no one truly understood IT ITIL is not a panacea to all problems. It is, however,
service management (ITSM), although it was a tried and tested approach that has been proven
clear that it was a concept that needed to be to work.
explored. Hence a UK government initiative was
I wish you every success in your service
instigated and ITIL® was born. Over the years,
management journey.
ITIL has evolved and, arguably, is now the most
widely adopted approach in ITSM. It is globally
recognized as the best-practice framework. ITIL’s Frances Scarff
universal appeal is that it continues to provide a
set of processes and procedures that are efficient, Head of Best Management Practice
reliable and adaptable to organizations of all Cabinet Office
sizes, enabling them to improve their own service
provision.
In the modern world the concept of having
a strategy to drive the business forward with
adequate planning and design transitioning into
day-to-day operation is compelling. The aim of
service transition is to make the move into the
live business environment as smooth as possible.
This vital step in the service lifecycle ensures that
processes and procedures are in place to protect
the live operational environment, ensuring that
only tested and planned services are enabled
for the business, in accordance with an agreed
and communicated business timescale and with
adequate fallback provision.
The principles contained within ITIL Service
Transition have been proven countless times in the
real world. We encourage feedback from business
and the ITSM community, as well as other experts
in the field, to ensure that ITIL remains relevant.
This practice of continual service improvement is
one of the cornerstones of the ITIL framework and
the fruits of this labour are here before you in this
updated edition.
There is an associated qualification scheme so that
individuals can demonstrate their understanding
and application of the ITIL practices. So whether
you are starting out or continuing along the ITIL
path, you are joining a legion of individuals and
organizations who have recognized the benefits of
good quality service and have a genuine resolve to
improve their service level provision.

Preface
‘They always say that time changes things, but that meet business demands for functionality,
you actually have to change them yourself.’ security, performance, reliability and flexibility.
Andy Warhol The service design package facilitates the build,
test, and release and deployment activities of
This is the third book in the series of five ITIL
service transition, and the operation, support and
core publications containing advice and guidance
improvement activities within the service operation
around the activities and processes associated with
and continual service improvement stages of the
the five stages of the service lifecycle. The primary
service lifecycle.
purpose of the service transition stage of the
service lifecycle is to ensure that any modifications ITIL Service Transition is the IT service management
or transitions to the live operational environment (ITSM) professional’s guide to delivering those
– affecting either new, modified, retiring or retired changes through transition lifecycle steps, which
services – meet the agreed expectations of the help them to manage change in a broader
business, customers and users. This means that all context. Large-scale IT change is often driven
modifications to operational environments should through project or programme initiatives. These
be managed, planned and coordinated through are mistakenly seen to be outside ‘change
service transition processes and activities to management’ and too often not considered to be
facilitate a smooth transition to live operation. This a service management concern until it is time to
will ensure that a new, modified, retiring or retired implement them. Experience teaches us that this
service fulfils its operational expectation and has approach rarely yields the best possible benefit to
no or minimal adverse impact on customers, users the business.
and the business.
Service transition also requires the effective
Successful service transition does not happen until management of knowledge, organizational culture
an organization recognizes the need for it and the and transition in difficult or unusual circumstances.
benefits it will bring. Effective service transition Every IT professional knows that the major part of
is necessary because business operations and any change – that can make or break its success –
processes are in a constant state of transition. The is related to the human factor, especially cultural
quest for competitive advantage, best-of-breed aversion to change.
innovation, agility and self-preservation are eternal
ITIL Service Transition supplies guidance on
catalysts for changes that must ultimately be
managing service transition from designed
delivered.
specifications, dealing with change, configuration,
Service transition ensures that the requirements test, release and deployment and every step in
of service strategy encoded in service design are between. Effective service transition ensures that
effectively realized through to the delivery of meeting business need, cost and efficiency are
live services within the service operation stage of achieved with minimal risk, maximum optimization
the service lifecycle. Service transition takes the and the highest degree of confidence possible.
outputs from service design, the preceding stage
of the lifecycle, and uses them to ensure that Contact information
service solutions are smoothly migrated to live Full details of the range of material published
operation, fulfilling agreed customer and business under the ITIL banner can be found at:
requirements. The trigger for this transition activity
is the production of a service design package www.best-management-practice.com/IT-Service-
produced by the processes and activities of service Management-ITIL/
design. Service transition takes this new business If you would like to inform us of any changes that
requirement contained within the service design may be required to this publication, please log
package and, using the five aspects of design, them at:
creates services and their supporting practices

x | Preface
www.best-management-practice.com/changelog/
For further information on qualifications and
training accreditation, please visit
www.itil-officialsite.com
Alternatively, please contact:
APM Group – The Accreditor Service Desk
Sword House
Totteridge Road
High Wycombe
Buckinghamshire
HP13 6DG
UK
Tel: +44 (0) 1494 458948
Email: [email protected]

Acknowledgements
2011 edition Wider team
Authors and mentors Change advisory board

Stuart Rance (HP) Author The change advisory board (CAB) spent
Colin Rudd (IT Enterprise Management Service Ltd considerable time and effort reviewing all the
(ITEMS)) Mentor comments submitted through the change control
Shirley Lacy (ConnectSphere) Project mentor log and their hard work was essential to this
Ashley Hanna (HP) Technical continuity editor project. Members of the CAB involved in this
review included:
Other members of the ITIL authoring David Cannon, Emily Egle, David Favelle, Ashley
team Hanna, Kevin Holland, Stuart Rance, Frances Scarff
Thanks are due to the authors and mentors who and Sharon Taylor.
have worked on all the publications in the lifecycle Once authors and mentors were selected for the
suite and contributed to the content in this 2011 update, a revised CAB was appointed and
publication and consistency across the suite. They now includes:
are:
Emily Egle, David Favelle, Phil Hearsum, Kevin
David Cannon (HP), Lou Hunnebeck (Third Holland and Frances Scarff.
Sky), Vernon Lloyd (Fox IT), Anthony T. Orr
(BMC Software), Randy Steinberg (Migration Reviewers
Technologies Inc.) and David Wheeldon (David
Claire Agutter, IT Training Zone; Niels Backx,
Wheeldon IT Service Management).
Quint Wellington Redwood; Ernest R. Brewster,
Independent; David M. Brink, Solutions3; Jeroen
Project governance
Bronkhorst, HP; Tony Brough, DHL Supply Chain;
Members of the project governance team included: Erin Casteel, Veridity Pty Ltd; Janaki Chakravarthy,
Jessica Barry, APM Group, project assurance Independent; Christiane Chung Ah Pong, NCS
(examinations); Marianna Billington, itSMFI, senior Pte Ltd, Singapore; Patrick Connelly, Gartner
user; Emily Egle, TSO, team manager; Janine Consulting; Barry Corless, Global Knowledge;
Eves, TSO, senior supplier; Phil Hearsum, Cabinet Federico Corradi, Cogitek; Jenny Dugmore, Service
Office, project assurance (quality); Tony Jackson, Matters; Frank Eggert, MATERNA GmbH; Robert
TSO, project manager; Paul Martini, itSMFI, senior Falkowitz, Concentric Circle Consulting; David
user; Richard Pharro, APM Group, senior supplier; Favelle, UXC Consulting/Lucid IT; Ryan Fraser, HP;
Frances Scarff, Cabinet Office, project executive; Anne Goddard, Goddard Service Management
Rob Stroud, itSMFI, senior user; Sharon Taylor, Consulting; Vawns Guest, Pink Elephant; Kevin
Aspect Group Inc., adviser to the project board Holland, NHS Connecting for Health; Steve
(technical) and the ATO sub-group, and adviser to Ingall, iCore-ltd; Randy Johnson, IBM; George
the project board (training). Kinnear, The Grey Matters Education Ltd; Brad
Laatsch, HP; Chandrika Labru, Tata Consultancy
For more information on the ATO sub-group see: Services; Zoe Lambert, HP; Reginald Lo, Third
www.itil-officialsite.com/News/ Sky; Jane McNamara, Lilliard Associates Ltd;
ATOSubGroupAppointed.aspx Jeroen Moolhuijsen, Getronics Consulting; Judit
Pongracz, ITeal Consulting; Arvind Raman, Infosys
For a full list of acknowledgements of the ATO
Technologies Ltd.; Peter Ravnholt, UXC Consulting/
sub-group at the time of publication, please
Lucid IT; Claudio Schicht, Independent; Noel Scott,
visit: www.itil-officialsite.com/Publications/
Symantec; Arun Simha, L-3 Communications
PublicationAcknowledgements.aspx
STRATIS; Hon P Suen, The Hong Kong Jockey

xii | Acknowledgements
Club; Helen Sussex, Logica; J.R. Tietsort,

Micron Technology; Claudia Tropp, Technology
Partners International, Inc.; Ken Turbitt, Service
Management Consultancy (SMCG) Ltd; Deborah
Wagner, Booz Allen Hamilton; Chuck Wysocki,
McKesson Corporation
2007 edition
Chief architect and authors

Thanks are still due to those who contributed to
the 2007 edition of Service Transition, upon which
this updated edition is based.
Sharon Taylor (Aspect Group Inc) Chief architect
Shirley Lacy (ConnectSphere) Author
Ivor Macfarlane (Guillemot Rock) Author
All names and organizations were correct at
publication in 2007.
For a full list of all those who contributed to the
2007 and 2011 editions of Service Strategy, Service
Design, Service Transition, Service Operation and
Continual Service Improvement, please go to
www.itil-officialsite.com/Publications/
PublicationAcknowledgements.aspx

7267 ITIL-ServiceTranslation v0_1.indd 13
Introduction 1
11/07/2011 15:41
|
3
1 Introduction
ITIL is part of a suite of best-practice publications key principles, required processes and activities,
for IT service management (ITSM).1 ITIL provides organization and roles, technology, associated
guidance to service providers on the provision of challenges, critical success factors and risks. The
quality IT services, and on the processes, functions service lifecycle uses a hub-and-spoke design, with
and other capabilities needed to support them. service strategy at the hub, and service design,
ITIL is used by many hundreds of organizations transition and operation as the revolving lifecycle
around the world and offers best-practice guidance stages or ‘spokes’. Continual service improvement
applicable to all types of organization that surrounds and supports all stages of the service
provide services. ITIL is not a standard that has to lifecycle. Each stage of the lifecycle exerts influence
be followed; it is guidance that should be read on the others and relies on them for inputs and
and understood, and used to create value for the feedback. In this way, a constant set of checks
service provider and its customers. Organizations and balances throughout the service lifecycle
are encouraged to adopt ITIL best practices and to ensures that as business demand changes with
adapt them to work in their specific environments business need, the services can adapt and respond
in ways that meet their needs. effectively.
ITIL is the most widely recognized framework for In addition to the core publications, there is also a
ITSM in the world. In the 20 years since it was complementary set of ITIL publications providing
created, ITIL has evolved and changed its breadth guidance specific to industry sectors, organization
and depth as technologies and business practices types, operating models and technology
have developed. ISO/IEC 20000 provides a formal architectures.
and universal standard for organizations seeking to
have their service management capabilities audited
1.1 Overview
and certified. While ISO/IEC 20000 is a standard to
be achieved and maintained, ITIL offers a body of ITIL Service Transition provides best-practice
knowledge useful for achieving the standard. guidance for the service transition stage of the ITIL
service lifecycle. Although this publication can be
In 2007, the second major refresh of ITIL was
published in response to significant advancements
in technology and emerging challenges for IT
service providers. New models and architectures
such as outsourcing, shared services, utility Continual
service
computing, cloud computing, virtualization, web improvement
services and mobile commerce have become Service
transition
widespread within IT. The process-based approach
of ITIL was augmented with the service lifecycle
to address these additional service management
challenges. In 2011, as part of its commitment
Service
to continual improvement, the Cabinet Office strategy
published this update to improve consistency across
the core publications. Service
Service
design
operation
The ITIL framework is based on the five stages
of the service lifecycle as shown in Figure 1.1,
with a core publication providing best-practice
guidance for each stage. This guidance includes
1 ITSM and other concepts from this chapter are described in more detail
in Chapter 2. Figure 1.1 The ITIL service lifecycle

4 | Introduction
read in isolation, it is recommended that it is used planning, building, testing, evaluation and
in conjunction with the other core ITIL publications. deployment. The publication also considers service
retirement and transfer of services between service
1.1.1 Purpose and objectives of service providers. The guidance focuses on how to ensure
transition that the requirements from service strategy,
developed in service design, are effectively realized
The purpose of the service transition stage of the
in service operation while controlling the risks of
service lifecycle is to ensure that new, modified
failure and subsequent disruption.
or retired services meet the expectations of the
business as documented in the service strategy and Consideration is given to:
service design stages of the lifecycle.
■■ Managing the complexity associated with
The objectives of service transition are to: changes to services and service management
■■ Plan and manage service changes efficiently and
processes
effectively ■■ Allowing for innovation while minimizing the
unintended consequences of change
■■ Manage risks relating to new, changed or
retired services ■■ Introducing new services
■■ Successfully deploy service releases into ■■ Changes to existing services, e.g. expansion,
supported environments reduction, change of supplier, acquisition or
disposal of sections of user base or suppliers,
■■ Set correct expectations on the performance
change of requirements or skills availability
and use of new or changed services
■■ Decommissioning and discontinuation
■■ Ensure that service changes create the expected
of services, applications or other service
business value
components
■■ Provide good-quality knowledge and
■■ Transferring services to and from other service
information about services and service assets.
providers.
In order to achieve these objectives, there are many
Guidance on transferring the control of services
things that need to happen during the service
includes transfer in the following circumstances:
transition lifecycle stage. These include:
■■ Out to a new supplier, e.g. outsourcing
■■ Planning and managing the capacity and
resources required to manage service transitions ■■ From one supplier to another
■■ Implementing a rigorous framework for ■■ Back in from a supplier, e.g. insourcing

evaluating service capabilities and risk profiles ■■ Moving to a partnership or co-sourcing
before new or changed services are deployed arrangement (e.g. partial outsourcing of some
■■ Establishing and maintaining the integrity of processes)
service assets ■■ Multiple suppliers, e.g. co-sourcing or multi-
■■ Providing efficient repeatable mechanisms for sourcing
building, testing and deploying services and ■■ Joint venture
releases ■■ Down-sizing, up-sizing (right-sizing) and off-
■■ Ensuring that services can be managed, shoring
operated and supported in accordance with ■■ Merger and acquisition.
constraints specified during the service design In reality, circumstances generate a combination of
stage of the service lifecycle. several of the above options at any one time and in
any one situation.
1.1.2 Scope
The scope also includes the transition of changes
ITIL Service Transition provides guidance for the
in the service provider’s service management
development and improvement of capabilities
capabilities that will impact on the ways of
for transitioning new and changed services
working, the organization, people, projects and
into supported environments, including release
third parties involved in service management.

|
Introduction 5
1.1.2.1 Processes within service transition ■■ Service testing and validation

The processes described in ITIL Service Transition ■■ Change evaluation.
can be categorized into two groups, based on the Some activities of all service transition processes
extent to which process activities take place within may be carried out during the service design stage
the service transition stage of the service lifecycle. of the service lifecycle – for example, design of a
Processes with significant activities throughout release package or planning of a service transition.
the service lifecycle Figure 1.2 shows all of the processes described in
The first group are processes that are critical during ITIL Service Transition. Processes that are largely
the service transition stage but influence and within the service transition stage of the service
support all stages of the service lifecycle. These lifecycle are shown within the central rectangle;
comprise: the other stages of the service lifecycle that come
before and after these processes are shown in the
■■ Change management smaller darker rectangles.
■■ Service asset and configuration management
Figure 8.2 in Chapter 8 gives an example of how
■■ Knowledge management.
the many processes involved in service transition
Processes which have most of their activities in might interact.
the service transition stage of the service lifecycle
The second group are processes that are strongly
focused within the service transition stage:
■■ Transition planning and support
■■ Release and deployment management
Continual service improvement
Change management (4.2)
Auth Auth Auth Auth Auth Auth Auth Auth
Service asset and configuration management (4.3)
BL BL BL BL BL BL BL BL
Transition planning and support (4.1)
Managing people through service transitions (5)
Change evaluation (4.6)
Service Service Release Release build Release Review and Service

strategy design planning and test deployment close operation
Release
deployment
Release
deployment
Release and deployment management (4.4)
Service validation and testing (4.5)
Knowledge management (4.7)
Focus of activity ITIL process in service Change authorization

Auth
related to Other ITIL core transition that supports
service publications the whole service lifecycle
transition
Point to capture baseline
BL
Figure 1.2 The scope of service transition

6 | Introduction
1.1.3 Usage 1.1.5 Target audience

ITIL Service Transition provides access to proven ITIL Service Transition is relevant to organizations
best practice based on the skill and knowledge of involved in the development, delivery or support of
experienced industry practitioners in adopting a services, including:
standardized and controlled approach to service
■■ Service providers, both internal and external
management. Although this publication can be
■■ Organizations that aim to improve services
used and applied in isolation, it is recommended
through the effective application of service
that it is used in conjunction with the other core
management and service lifecycle processes to
ITIL publications. All of the core publications need
improve their service quality
to be read to fully appreciate and understand
■■ Organizations that require a consistent
the overall lifecycle of services and IT service
management. managed approach across all service providers in
a supply chain or value network
1.1.4 Value to business ■■ Organizations that are going out to tender for
their services.
Selecting and adopting the best practice as
recommended in this publication will assist The publication is also relevant to IT service
organizations in delivering significant benefits. It managers and to all those working in service
will help readers to set up service transition and transition or areas supporting the objectives of
the processes that support it, and to make effective service transition, including:
use of those processes to facilitate the effective ■■ Staff working in programmes and projects who
transitioning of new, changed or decommissioned
are responsible for delivering new or changed
services.
services and the service environment
Adopting and implementing standard and ■■ Transition managers and staff
consistent approaches for service transition will: ■■ Testing managers and testing practitioners,
■■ Enable projects to estimate the cost, timing, including test environment and test data
resource requirement and risks associated with managers and librarians
the service transition stage more accurately ■■ Quality assurance managers
■■ Result in higher volumes of successful change ■■ Service asset and configuration management
■■ Be easier for people to adopt and follow staff
■■ Enable service transition assets to be shared and ■■ Change management staff
re-used across projects and services ■■ Release and deployment management staff
■■ Reduce delays from unexpected clashes and ■■ Procurement staff
dependencies – for example, if multiple projects ■■ Relationship managers and supplier managers
need to use the same test environment at the ■■ Suppliers delivering services, support, training
same time etc.
■■ Reduce the effort spent on managing the
service transition test and pilot environments
1.2 Context
■■ Improve expectation setting for all stakeholders
involved in service transition including The context of this publication is the ITIL service
customers, users, suppliers, partners and projects lifecycle as shown in Figure 1.1.
■■ Increase confidence that the new or changed The ITIL core consists of five lifecycle publications.
service can be delivered to specification without Each provides part of the guidance necessary for
unexpectedly affecting other services or an integrated approach as required by the ISO/IEC
stakeholders 20000 standard specification. The five publications
■■ Ensure that new or changed services will be are:
maintainable and cost-effective ■■ ITIL Service Strategy
■■ Improve control of service assets and ■■ ITIL Service Design
configurations.
■■ ITIL Service Transition

|
Introduction 7
■■ ITIL Service Operation development and strategic risks are among the
■■ ITIL Continual Service Improvement other major topics.
Each one addresses capabilities having direct Organizations should use ITIL Service Strategy to
impact on a service provider’s performance. The set objectives and expectations of performance
core is expected to provide structure, stability and towards serving customers and market
strength to service management capabilities, with spaces, and to identify, select and prioritize
durable principles, methods and tools. This serves opportunities. Service strategy is about ensuring
to protect investments and provide the necessary that organizations are in a position to handle
basis for measurement, learning and improvement. the costs and risks associated with their service
The introductory guide, Introduction to the ITIL portfolios, and are set up not just for operational
Service Lifecycle, provides an overview of the effectiveness but for distinctive performance.
lifecycle stages described in the ITIL core. Organizations already practising ITIL can use ITIL
ITIL guidance can be adapted to support various Service Strategy to guide a strategic review of their
business environments and organizational ITIL-based service management capabilities and to
strategies. Complementary ITIL publications improve the alignment between those capabilities
provide flexibility to implement the core in a and their business strategies. ITIL Service Strategy
diverse range of environments. Practitioners can will encourage readers to stop and think about why
select complementary publications as needed something is to be done before thinking of how.
to provide traction for the ITIL core in a given
context, in much the same way as tyres are selected 1.2.2 Service design
based on the type of vehicle, purpose and road For services to provide true value to the business,
conditions. This is to increase the durability and they must be designed with the business objectives
portability of knowledge assets and to protect in mind. Design encompasses the whole IT
investments in service management capabilities. organization, for it is the organization as a whole
that delivers and supports the services. Service
1.2.1 Service strategy design is the stage in the lifecycle that turns a
At the centre of the service lifecycle is service service strategy into a plan for delivering the
strategy. Value creation begins here with business objectives.
understanding organizational objectives and ITIL Service Design provides guidance for the
customer needs. Every organizational asset design and development of services and service
including people, processes and products should management practices. It covers design principles
support the strategy. and methods for converting strategic objectives
ITIL Service Strategy provides guidance on how into portfolios of services and service assets.
to view service management not only as an The scope of ITIL Service Design is not limited
organizational capability but as a strategic asset. to new services. It includes the changes and
It describes the principles underpinning the improvements necessary to increase or maintain
practice of service management which are useful value to customers over the lifecycle of services, the
for developing service management policies, continuity of services, achievement of service levels,
guidelines and processes across the ITIL service and conformance to standards and regulations. It
lifecycle. guides organizations on how to develop design
capabilities for service management.
Topics covered in ITIL Service Strategy include the
development of market spaces, characteristics Other topics in ITIL Service Design include design
of internal and external provider types, service coordination, service catalogue management,
assets, the service portfolio and implementation service level management, availability
of strategy through the service lifecycle. Business management, capacity management, IT service
relationship management, demand management, continuity management, information security
financial management, organizational management and supplier management.

8 | Introduction
1.2.3 Service transition capacity utilization, scheduling of operations,

ITIL Service Transition (this publication) provides and avoiding or resolving service incidents and
guidance for the development and improvement managing problems. New models and architectures
of capabilities for introducing new and changed such as shared services, utility computing, web
services into supported environments. It describes services and mobile commerce to support service
how to transition an organization from one state operation are described.
to another while controlling risk and supporting Other topics in ITIL Service Operation include event
organizational knowledge for decision support. It management, incident management, request
ensures that the value(s) identified in the service fulfilment, problem management and access
strategy, and encoded in service design, are management processes; as well as the service desk,
effectively transitioned so that they can be realized technical management, IT operations management
in service operation. and application management functions.
ITIL Service Transition describes best practice
in transition planning and support, change 1.2.5 Continual service improvement
management, service asset and configuration ITIL Continual Service Improvement provides
management, release and deployment guidance on creating and maintaining value
management, service validation and testing, for customers through better strategy, design,
change evaluation and knowledge management. transition and operation of services. It combines
It provides guidance on managing the complexity principles, practices and methods from quality
related to changes to services and service management, change management and capability
management processes, preventing undesired improvement.
consequences while allowing for innovation. ITIL Continual Service Improvement describes
ITIL Service Transition also introduces the service best practice for achieving incremental and large-
knowledge management system, which can scale improvements in service quality, operational
support organizational learning and help to efficiency and business continuity, and for ensuring
improve the overall efficiency and effectiveness that the service portfolio continues to be aligned
of all stages of the service lifecycle. This will to business needs. Guidance is provided for linking
enable people to benefit from the knowledge and improvement efforts and outcomes with service
experience of others, support informed decision- strategy, design, transition and operation. A closed
making, and improve the management of services. loop feedback system, based on the Plan-Do-Check-
Act (PDCA) cycle, is established. Feedback from any
1.2.4 Service operation stage of the service lifecycle can be used to identify
ITIL Service Operation describes best practice for improvement opportunities for any other stage of
managing services in supported environments. It the lifecycle.
includes guidance on achieving effectiveness and Other topics in ITIL Continual Service Improvement
efficiency in the delivery and support of services to include service measurement, demonstrating value
ensure value for the customer, the users and the with metrics, developing baselines and maturity
service provider. assessments.
Strategic objectives are ultimately realized through
service operation, therefore making it a critical 1.3 ITIL in relation to other
capability. ITIL Service Operation provides guidance publications in the Best
on how to maintain stability in service operation,
Management Practice portfolio
allowing for changes in design, scale, scope and
service levels. Organizations are provided with ITIL is part of a portfolio of best-practice
detailed process guidelines, methods and tools for publications (known collectively as Best
use in two major control perspectives: reactive and Management Practice or BMP) aimed at helping
proactive. Managers and practitioners are provided organizations and individuals manage projects,
with knowledge allowing them to make better programmes and services consistently and
decisions in areas such as managing the availability effectively (see Figure 1.3). ITIL can be used
of services, controlling demand, optimizing in harmony with other BMP products, and

|
Introduction 9
international or internal organization standards. allows organizations to assess risk accurately

Where appropriate, BMP guidance is supported by (selecting the correct responses to threats and
a qualification scheme and accredited training and opportunities created by uncertainty) and
consultancy services. All BMP guidance is intended thereby improve their service delivery.
to be tailored for use by individual organizations. Office of Government Commerce (2010).
BMP publications include: Management of Risk: Guidance for Practitioners.
TSO, London.
■■ Management of Portfolios (MoP™) Portfolio
■■ Management of Value (MoV™) MoV provides
management concerns the twin issues of how
to do the ‘right’ projects and programmes in a cross-sector and universally applicable guide
the context of the organization’s strategic on how to maximize value in a way that takes
objectives, and how to do them ‘correctly’ in account of organizations’ priorities, differing
terms of achieving delivery and benefits at a stakeholders’ needs and, at the same time,
collective level. MoP encompasses consideration uses resources as efficiently and effectively as
of the principles upon which effective portfolio possible. It will help organizations to put in
management is based; the key practices in place effective methods to deliver enhanced
the portfolio definition and delivery cycles, value across their portfolio, programmes,
including examples of how they have been projects and operational activities to meet
applied in real life; and guidance on how to the challenges of ever-more competitive and
implement portfolio management and sustain resource-constrained environments.
progress in a wide variety of organizations. Office of Government Commerce (2010).
Office of Government Commerce (2011). Management of Value. TSO, London.
Management of Portfolios. TSO, London. ■■ Managing Successful Programmes (MSP®)
■■ Management of Risk (M_o_R®) M_o_R MSP provides a framework to enable the
offers an effective framework for taking achievement of high-quality change outcomes
informed decisions about the risks that affect and benefits that fundamentally affect the way
performance objectives. The framework in which organizations work. One of the core
Glossary
Guidance
Models
Management Management Portfolio,

Portfolio, of Risk of Value Programme ITIL®
Programme (M_o_R®) (MoV™) and Project
and Project Offices
Management (P3O®)
Maturity
Model
(P3M3®)
Portfolio management (MoP™)
PRINCE2®
Maturity Programme management (MSP®)
Model
(P2MM)
Project management (PRINCE2®)
Figure 1.3 ITIL’s relationship with other Best Management Practice guides

10 | Introduction
themes in MSP is that a programme must add ■■ Non-prescriptive ITIL offers robust, mature and
more value than that provided by the sum of its time-tested practices that have applicability to
constituent project and major activities. all types of service organization. It continues
Cabinet Office (2011). Managing Successful to be useful and relevant in public and private
Programmes. TSO, London. sectors, internal and external service providers,
small, medium and large enterprises, and within
■■ Managing Successful Projects with PRINCE2®
any technical environment. Organizations
PRINCE2 (PRojects IN Controlled Environments,
should adopt ITIL and adapt it to meet
V2) is a structured method to help effective
the needs of the IT organization and their
project management via clearly defined
customers.
products. Key themes that feature throughout
■■ Best practice ITIL represents the learning
PRINCE2 are the dependence on a viable
experiences and thought leadership of the
business case confirming the delivery of
world’s best-in-class service providers.
measurable benefits that are aligned to an
organization’s objectives and strategy, while ITIL is successful because it describes practices that
ensuring the management of risks, costs and enable organizations to deliver benefits, return on
quality. investment and sustained success. ITIL is adopted
Office of Government Commerce (2009). by organizations to enable them to:
Managing Successful Projects with PRINCE2. ■■ Deliver value for customers through services
TSO, London.
■■ Integrate the strategy for services with the
■■ Portfolio, Programme and Project Offices business strategy and customer needs
(P3O®) P3O provides universally applicable ■■ Measure, monitor and optimize IT services and
guidance, including principles, processes and service provider performance
techniques, to successfully establish, develop ■■ Manage the IT investment and budget
and maintain appropriate support structures. ■■ Manage risk
These structures will facilitate delivery of
■■ Manage knowledge
business objectives (portfolios), programmes
■■ Manage capabilities and resources to deliver
and projects within time, cost, quality and other
services effectively and efficiently
organizational constraints.
■■ Enable adoption of a standard approach to
Office of Government Commerce (2008).
service management across the enterprise
Portfolio, Programme and Project Offices. TSO,
London. ■■ Change the organizational culture to support
the achievement of sustained success
■■ Improve the interaction and relationship with
1.4 Why is ITIL so successful? customers
ITIL embraces a practical approach to service ■■ Coordinate the delivery of goods and services
management – do what works. And what works across the value network
is adapting a common framework of practices ■■ Optimize and reduce costs.
that unite all areas of IT service provision towards
a single aim – that of delivering value to the
business. The following list defines the key
1.5 Chapter summary
characteristics of ITIL that contribute to its global ITIL Service Transition comprises:
success:
■■ Chapter 2 Service management as a practice
■■ Vendor-neutral ITIL service management This chapter explains the concepts of service
practices are applicable in any IT organization management and services, and describes
because they are not based on any particular how these can be used to create value. It also
technology platform or industry type. ITIL is summarizes a number of generic ITIL concepts
owned by the UK government and is not tied to that the rest of the publication depends on.
any commercial proprietary practice or solution.

| 11
Introduction
■■ Chapter 3 Service transition principles ■■ Chapter 9 Challenges, risks and critical success
This chapter describes some of the key factors
principles of service transition that will enable It is important for any organization to
service providers to plan and implement best understand the challenges, risks and critical
practice in service transition. These principles success factors that could influence their success.
are the same irrespective of the organization; This chapter discusses typical examples of these
however, the approach may need to be tailored for the service transition lifecycle stage.
to circumstances, including the size of the
■■ Appendix A Description of asset types
organization, geographic distribution, culture
This appendix describes the key asset types
and available resources. It concludes with a
of management, organization, process,
table showing the major inputs and outputs for
knowledge, people, information, applications,
the service transition lifecycle stage.
infrastructure and financial capital.
■■ Chapter 4 Service transition processes
■■ Appendix B Risk assessment and management
Chapter 4 sets out the processes and activities
This appendix contains basic information about
on which effective service transition depends
several commonly used approaches to the
and how they integrate with the other stages of
assessment and management of risk.
the lifecycle.
■■ Appendix C Related guidance
■■ Chapter 5 Managing people through service
transitions This contains a list of some of the many external
methods, practices and frameworks that align
Chapter 5 deals with the management of
well with ITIL best practice. Notes are provided
organizational and stakeholder change, and
on how they integrate into the ITIL service
communications. These critical aspects of
lifecycle, and when and how they are useful.
service transition are key to the success of any
transition, and must be carefully managed. ■■ Appendix D Examples of inputs and outputs
across the service lifecycle
■■ Chapter 6 Organizing for service transition
This appendix identifies some of the major
This chapter identifies the organizational roles
inputs and outputs between each stage of the
and responsibilities that should be considered
service lifecycle.
to manage the service transition lifecycle stage
and processes. These roles are provided as ■■ References and further reading
guidelines and can be combined to fit into a This provides a list of other sources of
variety of organizational structures. Examples of information that both informed the writing
organizational structures are also provided. of this publication and can be used for further
■■ Chapter 7 Technology considerations study and exploration by readers.
ITIL service management practices gain ■■ Abbreviations and glossary
momentum when the right type of technical This contains a list of abbreviations and a
automation is applied. This chapter provides selected glossary of terms.
recommendations for the use of technology in
service transition and the basic requirements
a service provider will need to consider when
choosing service management tools.
■■ Chapter 8 Implementing service transition
For organizations new to ITIL, or those
wishing to improve their maturity and service
capability, this chapter outlines effective ways to
implement the service transition lifecycle stage.

Service management

as a practice 2
11/07/2011 15:41
| 15

2 Service management as a practice
2.1 Services and service Customers seek outcomes but do not wish to have
management accountability or ownership of all the associated
costs and risks. All services must have a budget
2.1.1 Services when they go live and this must be managed.
The service cost is reflected in financial terms
Services are a means of delivering value to
such as return on investment (ROI) and total cost
customers by facilitating the outcomes customers
of ownership (TCO). The customer will only be
want to achieve without the ownership of specific
exposed to the overall cost or price of a service,
costs and risks. Services facilitate outcomes by
which will include all the provider’s costs and risk
enhancing the performance of associated tasks and
mitigation measures (and any profit margin if
reducing the effect of constraints. These constraints
appropriate). The customer can then judge the
may include regulation, lack of funding or capacity,
value of a service based on a comparison of cost or
or technology limitations. The end result is an
price and reliability with the desired outcome.
increase in the probability of desired outcomes.
While some services enhance performance of tasks, Definitions
others have a more direct impact – they perform
the task itself. Service: A means of delivering value to
customers by facilitating outcomes customers
The preceding paragraph is not just a definition, want to achieve without the ownership of
as it is a recurring pattern found in a wide range specific costs and risks.
of services. Patterns are useful for managing
complexity, costs, flexibility and variety. They IT service: A service provided by an IT service
are generic structures useful to make an idea provider. An IT service is made up of a
applicable in a wide range of environments and combination of information technology, people
situations. In each instance the pattern is applied and processes. A customer-facing IT service
with variations that make the idea effective, directly supports the business processes of one
economical or simply useful in that particular case. or more customers and its service level targets
should be defined in a service level agreement.
Definition: outcome Other IT services, called supporting services,
are not directly used by the business but are
The result of carrying out an activity, following a
required by the service provider to deliver
process, or delivering an IT service etc. The term
customer-facing services.
is used to refer to intended results, as well as to
actual results.
Customer satisfaction is also important. Customers
need to be satisfied with the level of service and
An outcome-based definition of service moves
feel confident in the ability of the service provider
IT organizations beyond business–IT alignment
to continue providing that level of service – or
towards business–IT integration. Internal dialogue
even improving it over time. The difficulty is that
and discussion on the meaning of services is
customer expectations keep shifting, and a service
an elementary step towards alignment and
provider that does not track this will soon find
integration with a customer’s business (Figure 2.1).
itself losing business. ITIL Service Strategy is helpful
Customer outcomes become the ultimate concern
in understanding how this happens, and how a
of business relationship managers instead of the
service provider can adapt its services to meet the
gathering of requirements, which is necessary
changing customer environment.
but not sufficient. Requirements are generated
for internal coordination and control only after Services can be discussed in terms of how they
customer outcomes are well understood. relate to one another and their customers, and can
be classified as core, enabling or enhancing.

16 | Service management as a practice
I must ask, do you I believe services are a means of delivering value by

have a definition facilitating outcomes customers want to achieve
for services? without the ownership of specific costs and risks.
What would that mean

in operational terms? Well, services facilitate outcomes by
Give me a few handles. having a positive effect on activities,
objects and tasks, to create conditions for
better performance. As a result, the
probability of desired outcomes is higher.
But without the ownership of
costs and risks? Customers
cannot wish them away.
No, they cannot, but what they can do is
Manager Manager let the provider take ownership. That’s
Aha! Because the provider is (Operations) (Strategy) really why it is a service. If customers
specialized with capabilities for manage it all by themselves, they
dealing with those costs and risks. wouldn’t need a service, would they?
Yes, and also because the customer

(A casual conversation would rather specialize in those outcomes.
at the water cooler)
And also because the provider can

Let’s write a book on
potentially spread those costs and
service management!
risks across more than one customer.
Figure 2.1 Conversation about the definition and meaning of services
Core services deliver the basic outcomes desired and functionality. If each individual aspect of these
by one or more customers. They represent the complex services were defined independently, the
value that the customer wants and for which they service provider would soon find it impossible to
are willing to pay. Core services anchor the value track and record all services.
proposition for the customer and provide the basis
Most service providers will follow a strategy where
for their continued utilization and satisfaction.
they can deliver a set of more generic services
Enabling services are services that are needed in to a broad range of customers, thus achieving
order for a core service to be delivered. Enabling economies of scale and competing on the basis
services may or may not be visible to the customer, of price and a certain amount of flexibility. One
but the customer does not perceive them as way of achieving this is by using service packages.
services in their own right. They are ‘basic factors’ A service package is a collection of two or more
which enable the customer to receive the ‘real’ services that have been combined to offer a
(core) service. solution to a specific type of customer need or
to underpin specific business outcomes. A service
Enhancing services are services that are added to a
package can consist of a combination of core
core service to make it more exciting or enticing to
services, enabling services and enhancing services.
the customer. Enhancing services are not essential
to the delivery of a core service, and are added to Where a service or service package needs to be
a core service as ‘excitement’ factors, which will differentiated for different types of customer,
encourage customers to use the core service more one or more components of the package can be
(or to choose the core service provided by one changed, or offered at different levels of utility
company over those of its competitors). and warranty, to create service options. These
different service options can then be offered to
Services may be as simple as allowing a user to
customers and are sometimes called service level
complete a single transaction, but most services are
packages.
complex. They consist of a range of deliverables

Service management as a practice | 17
2.1.2 Service management inventories, make components, produce raw

When we turn on a water tap, we expect to see materials or own the companies that produced
water flow from it. When we turn on a light them (Magretta, 2002).
switch, we expect to see light fill the room. Not so Service management capabilities are similarly
many years ago, these very basic things were not influenced by the following challenges that
as reliable as they are today. We know instinctively distinguish services from other systems of value
that the advances in technology have made them creation, such as manufacturing, mining and
reliable enough to be considered a utility. But it agriculture:
isn’t just the technology that makes the services
■■ Intangible nature of the output and
reliable. It is how they are managed.
intermediate products of service processes: they
The use of IT today has become the utility of are difficult to measure, control and validate (or
business. Business today wants IT services that prove)
behave like other utilities such as water, electricity ■■ Demand is tightly coupled with the customer’s
or the telephone. Simply having the best assets: users and other customer assets such
technology will not ensure that IT provides utility- as processes, applications, documents and
like reliability. Professional, responsive, value- transactions arrive with demand and stimulate
driven service management is what brings this service production
quality of service to the business. ■■ High level of contact for producers and
Service management is a set of specialized consumers of services: there is little or no buffer
organizational capabilities for providing value to between the service provider’s creation of the
customers in the form of services. The more mature service and the customer’s consumption of that
a service provider’s capabilities are, the greater is service
their ability to consistently produce quality services ■■ The perishable nature of service output and
that meet the needs of the customer in a timely service capacity: there is value for the customer
and cost-effective manner. The act of transforming from assurance on the continued supply of
capabilities and resources into valuable services is consistent quality. Providers need to secure a
at the core of service management. Without these steady supply of demand from customers.
capabilities, a service organization is merely a
Service management is more than just a set
bundle of resources that by itself has relatively low
of capabilities. It is also a professional practice
intrinsic value for customers.
supported by an extensive body of knowledge,
experience and skills. A global community of
Definitions
individuals and organizations in the public and
Service management: A set of specialized private sectors fosters its growth and maturity.
organizational capabilities for providing value to Formal schemes exist for the education, training
customers in the form of services. and certification of practising organizations, and
Service provider: An organization supplying individuals influence its quality. Industry best
services to one or more internal or external practices, academic research and formal standards
customers. contribute to and draw from its intellectual capital.
The origins of service management are in
Organizational capabilities are shaped by the traditional service businesses such as airlines, banks,
challenges they are expected to overcome. An hotels and phone companies. Its practice has grown
example of this is provided by Toyota in the 1950s with the adoption by IT organizations of a service-
when it developed unique capabilities to overcome oriented approach to managing IT applications,
the challenge of smaller scale and financial capital infrastructure and processes. Solutions to business
compared to its American rivals. Toyota developed problems and support for business models,
new capabilities in production engineering, strategies and operations are increasingly in the
operations management and managing suppliers form of services. The popularity of shared services
to compensate for its inability to afford large and outsourcing has contributed to the increase in
the number of organizations that behave as service
providers, including internal IT organizations. This

in turn has strengthened the practice of service ITSM must be carried out effectively and efficiently.
management while at the same time imposed Managing IT from the business perspective enables
greater challenges. organizational high performance and value
creation.
2.1.3 IT service management A good relationship between an IT service provider
Information technology (IT) is a commonly used and its customers relies on the customer receiving
term that changes meaning depending on the an IT service that meets its needs, at an acceptable
different perspectives that a business organization level of performance and at a cost that the
or people may have of it. A key challenge is to customer can afford. The IT service provider needs
recognize and balance these perspectives when to work out how to achieve a balance between
communicating the value of IT service management these three areas, and communicate with the
(ITSM) and understanding the context for how the customer if there is anything which prevents it
business sees the IT organization. Some of these from being able to deliver the required IT service at
meanings are: the agreed level of performance or price.
■■ IT is a collection of systems, applications and A service level agreement (SLA) is used to
infrastructures which are components or sub- document agreements between an IT service
assemblies of a larger product. They enable or provider and a customer. An SLA describes the
are embedded in processes and services. IT service, documents service level targets, and
■■ IT is an organization with its own set of specifies the responsibilities of the IT service
capabilities and resources. IT organizations can provider and the customer. A single agreement
be of various types such as business functions, may cover multiple IT services or multiple
shared services units and enterprise-level core customers.
units.
■■ IT is a category of services utilized by business. 2.1.4 Service providers
The services are typically IT applications and There are three main types of service provider.
infrastructure that are packaged and offered While most aspects of service management apply
by internal IT organizations or external service equally to all types of service provider, other
providers. IT costs are treated as business aspects such as customers, contracts, competition,
expenses. market spaces, revenue and strategy take on
■■ IT is a category of business assets that provide a different meanings depending on the specific type.
stream of benefits for their owners, including, The three types are:
but not limited to, revenue, income and profit.
■■ Type I – internal service provider An internal
IT costs are treated as investments.
service provider that is embedded within a
Every IT organization should act as a service business unit. There may be several Type I
provider, using the principles of service service providers within an organization.
management to ensure that they deliver the ■■ Type II – shared services unit An internal service
outcomes required by their customers. provider that provides shared IT services to more
than one business unit.
Definitions
■■ Type III – external service provider A service
IT service management (ITSM): The provider that provides IT services to external
implementation and management of quality IT customers.
services that meet the needs of the business. IT
ITSM concepts are often described in the context
service management is performed by IT service
of only one of these types and as if only one type
providers through an appropriate mix of people,
of IT service provider exists or is used by a given
process and information technology.
organization. In reality most organizations have
IT service provider: A service provider that a combination of IT service providers. In a single
provides IT services to internal or external organization it is possible that some IT units
customers. are dedicated to a single business unit, others

provide shared services, and yet others have ■■ Internal customers These are customers
been outsourced or depend on external service who work for the same business as the IT
providers. service provider. For example, the marketing
department is an internal customer of the IT
Many IT organizations who traditionally provide
organization because it uses IT services. The
services to internal customers find that they
head of marketing and the chief information
are dealing directly with external users because
officer both report to the chief executive officer.
of the online services that they provide. ITIL
If IT charges for its services, the money paid is
Service Strategy provides guidance on how the IT
an internal transaction in the organization’s
organization interacts with these users, and who
accounting system, not real revenue.
owns and manages the relationship with them.
■■ External customers These are customers who
2.1.5 Stakeholders in service management work for a different business from the IT service
provider. External customers typically purchase
Stakeholders have an interest in an organization,
services from the service provider by means of a
project or service etc. and may be interested in
legally binding contract or agreement.
the activities, targets, resources or deliverables
from service management. Examples include
2.1.6 Utility and warranty
organizations, service providers, customers,
consumers, users, partners, employees, The value of a service can be considered to be
shareholders, owners and suppliers. The term the level to which that service meets a customer’s
‘organization’ is used to define a company, legal expectations. It is often measured by how much
entity or other institution. It is also used to refer to the customer is willing to pay for the service, rather
any entity that has people, resources and budgets – than the cost to the service provider of providing
for example, a project or business. the service or any other intrinsic attribute of the
service itself.
Within the service provider organization there
are many different stakeholders including the Unlike products, services do not have much intrinsic
functions, groups and teams that deliver the value. The value of a service comes from what it
services. There are also many stakeholders external enables someone to do. The value of a service is
to the service provider organization, for example: not determined by the provider, but by the person
who receives it – because they decide what they
■■ Customers Those who buy goods or services. will do with the service, and what type of return
The customer of an IT service provider is the they will achieve by using the service. Services
person or group who defines and agrees the contribute value to an organization only when
service level targets. This term is also sometimes their value is perceived to be higher than the cost
used informally to mean user – for example, of obtaining the service.
‘This is a customer-focused organization.’
From the customer’s perspective, value consists of
■■ Users Those who use the service on a day-to-
achieving business objectives. The value of a service
day basis. Users are distinct from customers,
is created by combining two primary elements:
as some customers do not use the IT service
utility (fitness for purpose) and warranty (fitness
directly.
for use). These two elements work together to
■■ Suppliers Third parties responsible for
achieve the desired outcomes upon which the
supplying goods or services that are required
customer and the business base their perceptions
to deliver IT services. Examples of suppliers
of a service.
include commodity hardware and software
vendors, network and telecom providers, and Utility is the functionality offered by a product
outsourcing organizations. or service to meet a particular need. Utility can
be summarized as ‘what the service does’, and
There is a difference between customers who work
can be used to determine whether a service is
in the same organization as the IT service provider,
able to meet its required outcomes, or is ‘fit for
and customers who work for other organizations.
purpose’. Utility refers to those aspects of a service
They are distinguished as follows:
that contribute to tasks associated with achieving
outcomes. For example, a service that enables a

business unit to process orders should allow sales performance of the tasks required to achieve an
people to access customer details, stock availability, outcome, or to remove constraints that prevent the
shipping information etc. Any aspect of the service task from being performed adequately (or both).
that improves the ability of sales people to improve Warranty requires the service to be available,
the performance of the task of processing sales continuous and secure and to have sufficient
orders would be considered utility. Utility can capacity for the service to perform at the required
therefore represent any attribute of a service that level. If the service is both fit for purpose and fit
removes, or reduces the effect of, constraints on for use, it will create value.
the performance of a task.
It should be noted that the elements of warranty in
Warranty is an assurance that a product or service Figure 2.2 are not exclusive. It is possible to define
will meet its agreed requirements. This may be a other components of warranty, such as usability,
formal agreement such as a service level agreement which refers to how easy it is for the user to access
or contract, or a marketing message or brand and use the features of the service to achieve the
image. Warranty refers to the ability of a service to desired outcomes.
be available when needed, to provide the required
The warranty aspect of the service needs to be
capacity, and to provide the required reliability in
designed at the same time as the utility aspect in
terms of continuity and security. Warranty can be
order to deliver the required value to the business.
summarized as ‘how the service is delivered’, and
Attempts to design warranty aspects after a
can be used to determine whether a service is ‘fit
service has been deployed can be expensive and
for use’. For example, any aspect of the service that
disruptive.
increases the availability or speed of the service
would be considered warranty. Warranty can Information about the desired business outcomes,
therefore represent any attribute of a service that opportunities, customers, utility and warranty of
increases the potential of the business to be able the service is used to develop the definition of a
to perform a task. Warranty refers to any means by service. Using an outcome-based definition helps to
which utility is made available to the users. ensure that managers plan and execute all aspects
of service management from the perspective of
Utility is what the service does, and warranty is
what is valuable to the customer.
how it is delivered.
Customers cannot benefit from something that is 2.1.7 Best practices in the public domain
fit for purpose but not fit for use, and vice versa. Organizations benchmark themselves against peers
The value of a service is therefore only delivered and seek to close gaps in capabilities. This enables
when both utility and warranty are designed them to become more competitive by improving
and delivered. Figure 2.2 illustrates the logic that their ability to deliver quality services that meet
a service has to have both utility and warranty the needs of their customers at a price their
to create value. Utility is used to improve the customers can afford. One way to close such gaps is
UTILITY
Performance supported? T/F

OR
Constraints removed? Fit for
purpose?
AND Value created

Available enough? T/F
Fit for use?
Capacity enough?
AND
Continuous enough? T/F
T: True
Secure enough? F: False
WARRANTY
Figure 2.2 Logic of value creation through services

the adoption of best practices in wide industry use. ■■ Owners of proprietary knowledge expect to
There are several sources for best practice including be rewarded for their investments. They may
public frameworks, standards and the proprietary make such knowledge available only under
knowledge of organizations and individuals (Figure commercial terms through purchases and
2.3). ITIL is the most widely recognized and trusted licensing agreements.
source of best-practice guidance in the area of ■■ Publicly available frameworks and standards
ITSM. such as ITIL, LEAN, Six Sigma, COBIT, CMMI,
Public frameworks and standards are attractive PRINCE2, PMBOK®, ISO 9000, ISO/IEC 20000
when compared with proprietary knowledge for and ISO/IEC 27001 are validated across a diverse
the following reasons: set of environments and situations rather than
the limited experience of a single organization.
■■ Proprietary knowledge is deeply embedded in They are subject to broad review across
organizations and therefore difficult to adopt, multiple organizations and disciplines, and
replicate or even transfer with the cooperation vetted by diverse sets of partners, suppliers and
of the owners. Such knowledge is often in the competitors.
form of tacit knowledge which is inextricable ■■ The knowledge of public frameworks is more
and poorly documented. likely to be widely distributed among a large
■■ Proprietary knowledge is customized for the community of professionals through publicly
local context and the specific needs of the available training and certification. It is easier
business to the point of being idiosyncratic. for organizations to acquire such knowledge
Unless the recipients of such knowledge have through the labour market.
matching circumstances, the knowledge may
not be as effective in use.
Standards Employees
Industry practices Customers
Sources Enablers
Academic research Suppliers
(generate) (aggregate)
Training and education Advisers
Internal experience Technologies
Substitutes Competition
Drivers Regulators Compliance Scenarios

(filter) (filter)
Customers Commitments
Knowledge fit for business

Objectives, context and purpose
Figure 2.3 Sources of service management best practice

Ignoring public frameworks and standards and technologies. It is relatively easy to acquire
can needlessly place an organization at a resources compared to capabilities (see Figure 2.4
disadvantage. Organizations should cultivate their for examples of capabilities and resources).
own proprietary knowledge on top of a body
Service providers need to develop distinctive
of knowledge based on public frameworks and
capabilities to retain customers with value
standards. Collaboration and coordination across
propositions that are hard for competitors to
organizations become easier on the basis of shared
duplicate. For example, two service providers
practices and standards. Further information on
may have similar resources such as applications,
best practice in the public domain is provided in
infrastructure and access to finance. Their
Appendix C.
capabilities, however, differ in terms of
management systems, organization structure,
2.2 Basic concepts processes and knowledge assets. This difference is
reflected in actual performance.
2.2.1 Assets, resources and capabilities Capabilities by themselves cannot produce value
The service relationship between service providers without adequate and appropriate resources.
and their customers revolves around the use of The productive capacity of a service provider is
assets – both those of the service provider and dependent on the resources under its control.
those of the customer. Each relationship involves Capabilities are used to develop, deploy and
an interaction between the assets of each party. coordinate this productive capacity. For example,
Many customers use the service they receive from capabilities such as capacity management and
a service provider to build and deliver services or availability management are used to manage
products of their own and then deliver them on the performance and utilization of processes,
to their own customers. In these cases, what the applications and infrastructure, ensuring service
service provider considers to be the customer asset levels are effectively delivered.
would be considered to be a service asset by their
customer. 2.2.2 Processes
Without customer assets, there is no basis for Definition: process
defining the value of a service. The performance of
A process is a structured set of activities
customer assets is therefore a primary concern for
designed to accomplish a specific objective. A
service management.
process takes one or more defined inputs and
turns them into defined outputs.
Definitions
Asset: Any resource or capability.
Processes define actions, dependencies and
Customer asset: Any resource or capability used sequence. Well-defined processes can improve
by a customer to achieve a business outcome. productivity within and across organizations and
functions. Process characteristics include:
Service asset: Any resource or capability used
by a service provider to deliver services to a ■■ Measurability We are able to measure the
customer. process in a relevant manner. It is performance-
driven. Managers want to measure cost, quality
There are two types of asset used by both and other variables while practitioners are
service providers and customers – resources and concerned with duration and productivity.
capabilities. Organizations use them to create value ■■ Specific results The reason a process exists is
in the form of goods and services. Resources are to deliver a specific result. This result must be
direct inputs for production. Capabilities represent individually identifiable and countable.
an organization’s ability to coordinate, control and ■■ Customers Every process delivers its primary
deploy resources to produce value. Capabilities are results to a customer or stakeholder. Customers
typically experience-driven, knowledge-intensive, may be internal or external to the organization,
information-based and firmly embedded within but the process must meet their expectations.
an organization’s people, systems, processes

The output produced by a process has to conform

Capabilities Resources
to operational norms that are derived from
business objectives. If products conform to the
Management Financial capital
set norm, the process can be considered effective
(because it can be repeated, measured and
Organization Infrastructure managed, and achieves the required outcome). If
the activities of the process are carried out with a
Applications
minimum use of resources, the process can also be
Processes
considered efficient.
Knowledge Information
Inputs are data or information used by the process
and may be the output from another process.
People (experience, skills People (number A process, or an activity within a process, is
and relationships) of employees)
initiated by a trigger. A trigger may be the arrival
of an input or other event. For example, the failure
Figure 2.4 Examples of capabilities and resources of a server may trigger the event management and
incident management processes.
■■ Responsiveness to specific triggers While a
A process may include any of the roles,
process may be ongoing or iterative, it should responsibilities, tools and management controls
be traceable to a specific trigger. required to deliver the outputs reliably. A process
A process is organized around a set of objectives. may define policies, standards, guidelines, activities
The main outputs from the process should be and work instructions if they are needed.
driven by the objectives and should include process
measurements (metrics), reports and process
improvement.
Process control
Process policy
Process owner Process objectives
Triggers Process
documentation Process feedback
Process
Process metrics
Process activities Process roles
Process Process Process Process

inputs procedures improvements outputs
Process Including process

work instructions reports and reviews
Process enablers
Process
Process resources capabilities
Figure 2.5 Process model

Processes, once defined, should be documented organization – for example, ensuring that all
and controlled. Once under control, they can be people who resolve incidents complete the
repeated and managed. Process measurement and incident record in the same way.
metrics can be built into the process to control ■■ Team A team is a more formal type of group.
and improve the process as illustrated in Figure These are people who work together to achieve
2.5. Process analysis, results and metrics should be a common objective, but not necessarily in the
incorporated in regular management reports and same organizational structure. Team members
process improvements. can be co-located, or work in multiple locations
and operate virtually. Teams are useful for
2.2.3 Organizing for service management collaboration, or for dealing with a situation of
There is no single best way to organize, and a temporary or transitional nature. Examples
best practices described in ITIL need to be of teams include project teams, application
tailored to suit individual organizations and development teams (often consisting of people
situations. Any changes made will need to take from several different business units) and
into account resource constraints and the size, incident or problem resolution teams.
nature and needs of the business and customers. ■■ Department Departments are formal
The starting point for organizational design is organizational structures which exist to perform
strategy. Organizational development for service a specific set of defined activities on an ongoing
management is described in more detail in ITIL basis. Departments have a hierarchical reporting
Service Strategy Chapter 6. structure with managers who are usually
responsible for the execution of the activities
2.2.3.1 Functions and also for day-to-day management of the
A function is a team or group of people and staff in the department.
the tools or other resources they use to carry ■■ Division A division refers to a number of
out one or more processes or activities. In larger departments that have been grouped together,
organizations, a function may be broken out often by geography or product line. A division is
and performed by several departments, teams normally self-contained.
and groups, or it may be embodied within a ITIL Service Operation describes the following
single organizational unit (e.g. the service desk). functions in detail:
In smaller organizations, one person or group
can perform multiple functions – for example, ■■ Service desk The single point of contact for
a technical management department could also users when there is a service disruption, for
incorporate the service desk function. service requests, or even for some categories of
request for change. The service desk provides
For the service lifecycle to be successful, an a point of communication to users and a point
organization will need to clearly define the roles of coordination for several IT groups and
and responsibilities required to undertake the processes.
processes and activities involved in each lifecycle ■■ Technical management Provides detailed
stage. These roles will need to be assigned to technical skills and resources needed to support
individuals, and an appropriate organization the ongoing operation of IT services and the
structure of teams, groups or functions will need to management of the IT infrastructure. Technical
be established and managed. These are defined as management also plays an important role in the
follows: design, testing, release and improvement of IT
■■ Group A group is a number of people who services.
are similar in some way. In ITIL, groups refer ■■ IT operations management Executes the daily
to people who perform similar activities – operational activities needed to manage IT
even though they may work on different services and the supporting IT infrastructure.
technologies or report into different This is done according to the performance
organizational structures or even different standards defined during service design. IT
companies. Groups are usually not formal operations management has two sub-functions
organizational structures, but are very useful
in defining common processes across the

that are generally organizationally distinct. management process at the same time as taking
These are IT operations control and facilities part in activities of the capacity management and
management. problem management processes.
■■ Application management Is responsible for
See Chapter 6 for more details about the roles and
managing applications throughout their responsibilities described in ITIL Service Transition.
lifecycle. The application management function
supports and maintains operational applications 2.2.3.3 Organizational culture and behaviour
and also plays an important role in the design,
Organizational culture is the set of shared values
testing and improvement of applications that
and norms that control the service provider’s
form part of IT services.
interactions with all stakeholders, including
The other core ITIL publications do not define
customers, users, suppliers, internal staff etc.
any functions in detail, but they do rely on the
An organization’s values are desired modes of
technical and application management functions
behaviour that affect its culture. Examples of
described in ITIL Service Operation. Technical and
organizational values include high standards,
application management provide the technical
customer care, respecting tradition and authority,
resources and expertise to manage the whole
acting cautiously and conservatively, and being
service lifecycle, and practitioner roles within a
frugal.
particular lifecycle stage may be performed by
members of these functions. High-performing service providers continually
align the value network for efficiency and
2.2.3.2 Roles effectiveness. Culture through the value network is
A number of roles need to be performed transmitted to staff through socialization, training
during the service lifecycle. The core ITIL programmes, stories, ceremonies and language.
publications provide guidelines and examples Constraints such as governance, capabilities,
of role descriptions. These are not exhaustive or standards, resources, values and ethics play a
prescriptive, and in many cases roles will need to significant role in organizational culture and
be combined or separated. Organizations should behaviour. Organizational culture can also be
take care to apply this guidance in a way that suits affected by structure or management styles
their own structure and objectives. resulting in a positive or negative impact on
performance. Organizational structures and
Definition: role management styles contribute to the behaviour
A role is a set of responsibilities, activities and of people, process, technology and partners.
authorities granted to a person or team. A role These are important aspects in adopting service
is defined in a process or function. One person management practices and ITIL.
or team may have multiple roles – for example, Change related to service management
the roles of configuration manager and change programmes will affect organizational culture and
manager may be carried out by a single person. it is important to prepare people with effective
communication plans, training, policies and
Roles are often confused with job titles but it is procedures to achieve the desired performance
important to realize that they are not the same. outcomes. Establishing cultural change is also
Each organization will define appropriate job titles an important factor for collaborative working
and job descriptions which suit their needs, and between the many different people involved in
individuals holding these job titles can perform one service management. Managing people through
or more of the required roles. service transitions is discussed at more length in
Chapter 5 of this publication.
It should also be recognized that a person may,
as part of their job assignment, perform a single
2.2.4 The service portfolio
task that represents participation in more than
one process. For example, a technical analyst The service portfolio is the complete set of services
who submits a request for change (RFC) to add that is managed by a service provider and it
memory to a server to resolve a performance represents the service provider’s commitments and
problem is participating in activities of the change investments across all customers and market spaces.

It also represents present contractual commitments, ■■ Supporting services IT services that support or
new service development, and ongoing service ‘underpin’ the customer-facing services. These
improvement plans initiated by continual service are typically invisible to the customer, but are
improvement. The portfolio may include third- essential to the delivery of customer-facing IT
party services, which are an integral part of service services.
offerings to customers.
Figure 2.6 illustrates the components of the service
The service portfolio represents all the resources portfolio, which are discussed in detail in ITIL
presently engaged or being released in various Service Strategy. These are important components
stages of the service lifecycle. It is a database or of the service knowledge management system
structured document in three parts: (SKMS) described in section 2.2.5.
■■ Service pipeline All services that are under
consideration or development, but are not
2.2.5 Knowledge management and the
yet available to customers. It includes major SKMS
investment opportunities that have to be traced Quality knowledge and information enable people
to the delivery of services, and the value that to perform process activities and support the flow
will be realized. The service pipeline provides a of information between service lifecycle stages and
business view of possible future services and is processes. Understanding, defining, establishing
part of the service portfolio that is not normally and maintaining information is a responsibility of
published to customers. the knowledge management process.
■■ Service catalogue All live IT services, including Implementing an SKMS enables effective decision
those available for deployment. It is the only support and reduces the risks that arise from a lack
part of the service portfolio published to of proper mechanisms. However, implementing
customers, and is used to support the sale and an SKMS can involve a large investment in tools
delivery of IT services. It includes a customer- to store and manage data, information and
facing view (or views) of the IT services in use, knowledge. Every organization will start this work
how they are intended to be used, the business in a different place, and have their own vision
processes they enable, and the levels and quality of where they want to be, so there is no simple
of service the customer can expect for each answer to the question ‘What tools and systems
service. The service catalogue also includes are needed to support knowledge management?’
information about supporting services required Data, information and knowledge need to be
by the service provider to deliver customer- interrelated across the organization. A document
facing services. Information about services management system and/or a configuration
can only enter the service catalogue after due management system (CMS) can be used as a
diligence has been performed on related costs foundation for implementation of the SKMS.
and risks.
■■ Retired services All services that have been
Figure 2.7 illustrates an architecture for service
phased out or retired. Retired services are not knowledge management that has four layers
available to new customers or contracts unless a including examples of possible content at each
special business case is made. layer. These are:
■■ Presentation layer Enables searching,
Service providers often find it useful to distinguish
customer-facing services from supporting services: browsing, retrieving, updating, subscribing and
collaboration. The different views onto the
■■ Customer-facing services IT services that are other layers are suitable for different audiences.
visible to the customer. These are normally Each view should be protected to ensure that
services that support the customer’s business only authorized people can see or modify the
processes and facilitate one or more outcomes underlying knowledge, information and data.
desired by the customer. ■■ Knowledge processing layer Is where the
information is converted into useful knowledge
which enables decision-making.

2.3 Governance and management

Service knowledge management system systems
Service portfolio
2.3.1 Governance
Service status
Governance is the single overarching area that
Requirements
ties IT and the business together, and services
Definition Service
are one way of ensuring that the organization is
Analysis
pipeline able to execute that governance. Governance is
Approved what defines the common directions, policies and
Service lifecycle
Chartered rules that both the business and IT use to conduct

Design business.
Customer/support
Development team viewable
section of the
Many ITSM strategies fail because they try to build
Build
service portfolio a structure or processes according to how they
Test Service (the service
catalogue catalogue, with would like the organization to work instead of
Release selected fields
viewable)
working within the existing governance structures.
Operational/live
Retiring
Definition: governance
Retired Retired services
Ensures that policies and strategy are actually
implemented, and that required processes
Figure 2.6 The service portfolio and its contents are correctly followed. Governance includes
defining roles and responsibilities, measuring
and reporting, and taking actions to resolve any
■■ Information integration layer Provides
issues identified.
integrated information that may be gathered
from data in multiple sources in the data layer.
■■ Data layer Includes tools for data discovery and Governance works to apply a consistently managed
data collection, and data items in unstructured approach at all levels of the organization – first by
and structured forms. ensuring a clear strategy is set, then by defining
the policies whereby the strategy will be achieved.
In practice, an SKMS is likely to consist of multiple The policies also define boundaries, or what the
tools and repositories. For example, there may be organization may not do as part of its operations.
a tool that provides all four layers for the support
of different processes or combinations of processes. Governance needs to be able to evaluate, direct
Various tools providing a range of perspectives and monitor the strategy, policies and plans.
will be used by different stakeholders to access Further information on governance and service
this common repository for collaborative decision management is provided in Chapter 5 of ITIL
support. Service Strategy. The international standard for
corporate governance of IT is ISO/IEC 38500,
This architecture is applicable for many of the described in Appendix C.
management information systems in ITIL. A primary
component of the SKMS is the service portfolio, 2.3.2 Management systems
covered in section 2.2.4. Other examples include
A system is a number of related things that work
the CMS, the availability management information
together to achieve an overall objective. Systems
system (AMIS) and the capacity management
should be self-regulating for agility and timeliness.
information system (CMIS).
In order to accomplish this, the relationships within
the system must influence one another for the sake
of the whole. Key components of the system are
the structure and processes that work together.

Presentation Portals IT governance Quality Services view Asset and Service desk Self-service
layer scorecards view management configuration and support view
dashboards view view view
reports
Search, browse, retrieve, update, publish, subscribe, collaborate
Knowledge Query and Monitoring

processing analysis Reporting Performance management Modelling and alerting
layer
Service knowledge management base

Information
integration
layer
Integrated CMDB Other integrated data and information
Schema mapping, metadata management, reconciliation, extract, transform, mining
DML Unstructured data

CMDB Service Other External
Data layer CMDB
portfolio structured database
data links
CMDB
CMDB
Discovery, collection, audit
Figure 2.7 Architectural layers of an SKMS
A systems approach to service management Many businesses have adopted management

ensures learning and improvement through a big- system standards for competitive advantage and
picture view of services and service management. to ensure a consistent approach in implementing
It extends the management horizon and provides a service management across their value network.
sustainable long-term approach. Implementation of a management system also
provides support for governance (see section 2.3.1).
By understanding the system structure, the
interconnections between all the assets and service
Definition: management system (ISO 9001)
components, and how changes in any area will
affect the whole system and its constituent parts The framework of policy, processes, functions,
over time, a service provider can deliver benefits standards, guidelines and tools that ensures
such as: an organization or part of an organization can
achieve its objectives.
■■ Ability to adapt to the changing needs of
customers and markets
■■ Sustainable performance A management system of an organization can
adopt multiple management system standards,
■■ Better approach to managing services, risks,
such as:
costs and value delivery
■■ Effective and efficient service management ■■ A quality management system (ISO 9001)
■■ Simplified approach that is easier for people to ■■ An environmental management system (ISO
use 14000)
■■ Less conflict between processes ■■ A service management system (ISO/IEC 20000)
■■ Reduced duplication and bureaucracy. ■■ An information security management system
(ISO/IEC 27001)
■■ A management system for software asset
management (ISO/IEC 19770).

Service providers are increasingly adopting these ISO/IEC 20000 is an internationally recognized
standards to be able to demonstrate their service standard that allows organizations to demonstrate
management capability. As there are common excellence and prove best practice in ITSM.
elements between such management systems, they Part 1 specifies requirements for the service
should be managed in an integrated way rather provider to plan, establish, implement, operate,
than having separate management systems. To monitor, review, maintain and improve a
meet the requirements of a specific management service management system (SMS). Coordinated
system standard, an organization needs to analyse integration and implementation of an SMS, to
the requirements of the relevant standard in detail meet the Part 1 requirements, provides ongoing
and compare them with those that have already control, greater effectiveness, efficiency and
been incorporated in the existing integrated opportunities for continual improvement. It
management system. Appendix C provides further ensures that the service provider:
information on these standards.
■■ Understands and fulfils the service requirements
ISO management system standards use the Plan- to achieve customer satisfaction
Do-Check-Act (PDCA) cycle shown in Figure 2.8. ■■ Establishes the policy and objectives for service
The ITIL service lifecycle approach embraces and management
enhances the interpretation of the PDCA cycle. ■■ Designs and delivers changes and services that
You will see the PDCA cycle used in the structure add value for the customer
of the guidance provided in each of the core ITIL ■■ Monitors, measures and reviews performance of
publications. This guidance recognizes the need the SMS and the services
to drive governance, organizational design and
■■ Continually improves the SMS and the services
management systems from the business strategy,
based on objective measurements.
service strategy and service requirements.
Service providers across the world have successfully
Definition: ISO/IEC 20000 established an SMS to direct and control their
service management activities. The adoption
An international standard for IT service
of an SMS should be a strategic decision for an
management.
organization.
Continual quality control and consolidation
Plan Project plan

Do Project
Check Audit
Act New actions
Maturity level
ACT PLAN
Business
IT
alignment
CHECK DO
Effective quality
improvement
Consolidation of the level reached

i.e. baseline
Timescale
Figure 2.8 Plan-Do-Check-Act cycle

One of the most common routes for an Organizations should function in the same manner
organization to achieve the requirements of ISO/ as a high-performing sports team. Each player in a
IEC 20000 is by adopting ITIL service management team and each member of the team’s organization
best practices and using the ITIL qualification who are not players position themselves to
scheme for professional development. support the goal of the team. Each player and
team member has a different specialization that
Certification to ISO/IEC 20000-1 by an accredited
contributes to the whole. The team matures
certification body shows that a service provider is
over time taking into account feedback from
committed to delivering value to its customers and
experience, best practice, current process and
continual service improvement. It demonstrates
procedures to become an agile high-performing
the existence of an effective SMS that satisfies the
team.
requirements of an independent external audit.
Certification gives a service provider a competitive Specialization and coordination are necessary in
edge in marketing. Many organizations specify a the lifecycle approach. Specialization allows for
requirement to comply with ISO/IEC 20000 in their expert focus on components of the service but
contracts and agreements. components of the service also need to work
together for value. Specialization combined with
coordination helps to manage expertise, improve
2.4 The service lifecycle
focus and reduce overlaps and gaps in processes.
Services and processes describe how things Specialization and coordination together help to
change, whereas structure describes how they are create a collaborative and agile organizational
connected. Structure helps to determine the correct architecture that maximizes utilization of assets.
behaviours required for service management. Coordination across the lifecycle creates an
Structure describes how process, people, environment focused on business and customer
technology and partners are connected. Structure outcomes instead of just IT objectives and projects.
is essential for organizing information. Without Coordination is also essential between functional
structure, our service management knowledge groups, across the value network, and between
is merely a collection of observations, practices processes and technology.
and conflicting goals. The structure of the service Feedback and control between organizational
lifecycle is an organizing framework, supported by assets helps to enable operational efficiency,
the organizational structure, service portfolio and organizational effectiveness and economies of
service models within an organization. Structure scale.
can influence or determine the behaviour of the
organization and people. Altering the structure of 2.4.2 Processes through the service
service management can be more effective than lifecycle
simply controlling discrete events.
Each core ITIL lifecycle publication includes
Without structure, it is difficult to learn from guidance on service management processes as
experience. It is difficult to use the past to educate shown in Table 2.1.
for the future. We can learn from experience but
Service management is more effective if people
we also need to confront directly many of the most
have a clear understanding of how processes
important consequences of our actions.
interact throughout the service lifecycle, within
See Chapter 1 for an introduction to each ITIL the organization and with other parties (users,
service lifecycle stage. customers, suppliers).
Process integration across the service lifecycle
2.4.1 Specialization and coordination
depends on the service owner, process owners,
across the lifecycle process practitioners and other stakeholders
Organizations need a collaborative approach understanding:
for the management of assets which are used to
■■ The context of use, scope, purpose and limits of
deliver and support services for their customers.
each process

Table 2.1 The processes described in each core ITIL publication

Core ITIL lifecycle publication Processes described in the publication
ITIL Service Strategy Strategy management for IT services
Service portfolio management
Financial management for IT services
Demand management
Business relationship management
ITIL Service Design Design coordination
Service catalogue management
Service level management
Availability management
Capacity management
IT service continuity management
Information security management
Supplier management
ITIL Service Transition Transition planning and support
Change management
Service asset and configuration management
Release and deployment management
Service validation and testing
Change evaluation
Knowledge management
ITIL Service Operation Event management
Incident management
Request fulfilment
Problem management
Access management
ITIL Continual Service Improvement Seven-step improvement process
■■ The strategies, policies and standards that apply As discussed in section 2.2.2, each process has a
to the processes and to the management of clear scope with a structured set of activities that
interfaces between processes transform inputs to deliver the outputs reliably. A
■■ Authorities and responsibilities of those process interface is the boundary of the process.
involved in each process Process integration is the linking of processes by
■■ The information provided by each process ensuring that information flows from one process
that flows from one process to another; who to another effectively and efficiently. If there is
produces it; and how it is used by integrated management commitment to process integration,
processes. processes are generally easier to implement and
there will be fewer conflicts between processes.
Integrating service management processes
depends on the flow of information across process Stages of the lifecycle work together as an
and organizational boundaries. This in turn integrated system to support the ultimate
depends on implementing supporting technology objective of service management for business value
and management information systems across realization. Every stage is interdependent as shown
organizational boundaries, rather than in silos. If in Figure 2.9. See Appendix D for examples of
service management processes are implemented, inputs and outputs across the service lifecycle.
followed or changed in isolation, they can become The SKMS, described in section 2.2.5 enables
a bureaucratic overhead that does not deliver value integration across the service lifecycle stages.
for money. They could also damage or negate the It provides secure and controlled access to the
operation or value of other processes and services. knowledge, information and data that are
needed to manage and deliver services. The

Requirements The business/customers
Service Change proposals

strategy and service
management system
Resources and
Service knowledge
constraints charters
Policies
Strategies
Service Service design

design packages
Standards
Solution Architectures
designs
Service Implementation
transition of transition plans
Tested SKMS updates
New/changed/ solutions
retired services
Business
Service Operational/live value
portfolio Service Achievements services
operation against targets
Service
catalogue
Continual
service
improvement CSI register, improvement
actions and plans
Figure 2.9 Integration across the service lifecycle
service portfolio represents all the assets presently service design, are effectively realized in service
engaged or being released in various stages of the operation while controlling the risks of failure and
lifecycle. disruption.
Chapter 1 provides a summary of each stage in The service operation stage of the service lifecycle
the service lifecycle but it is also important to carries out the activities and processes required to
understand how the lifecycle stages work together. deliver the agreed services. During this stage of the
lifecycle, the value defined in the service strategy is
Service strategy establishes policies and principles
realized.
that provide guidance for the whole service
lifecycle. The service portfolio is defined in this Continual service improvement acts in tandem
lifecycle stage, and new or changed services are with all the other lifecycle stages. All processes,
chartered. activities, roles, services and technology should be
measured and subjected to continual improvement.
During the service design stage of the lifecycle,
everything needed to transition and operate Most ITIL processes and functions have activities
the new or changed service is documented in a that take place across multiple stages of the service
service design package. This lifecycle stage also lifecycle. For example:
designs everything needed to create, transition
■■ The service validation and testing process may
and operate the services, including management
design tests during the service design stage and
information systems and tools, architectures,
perform these tests during service transition.
processes, measurement methods and metrics.
■■ The technical management function may
The activities of the service transition and service provide input to strategic decisions about
operation stages of the lifecycle are defined during technology, as well as assisting in the design and
service design. Service transition ensures that the transition of infrastructure components.
requirements of the service strategy, developed in

Service strategy
Strategies, policies,
standards Feedback
Lessons learned Feedback
for improvement Lessons learned
for improvement
Service design
Plans to create and modify

Output
services and service
management processes Feedback
Lessons learned Feedback
for improvement Lessons learned
for improvement
Service transition
Manage the transition of a

Output new or changed service
and/or service management Feedback
process into production Lessons learned
for improvement
Service operation
Day-to-day operation of
Output services and service
management processes
Continual service improvement

Activities are embedded in the service lifecycle
Figure 2.10 Continual service improvement and the service lifecycle
■■ Business relationship managers may assist in between each stage drives decisions about the need for
gathering detailed requirements during the service minor course corrections or major service improvement
design stage of the lifecycle, or take part in the initiatives.
management of major incidents during the service
Figure 2.10 illustrates some examples of the continual
operation stage.
feedback system built into the service lifecycle.
■■ All service lifecycle stages contribute to the seven-
step improvement process. Adopting appropriate technology to automate
the processes and provide management with
Appendix D identifies some of the major inputs and the information that supports the processes is
outputs between each stage of the service lifecycle. also important for effective and efficient service
Chapter 3 of each core ITIL publication provides more management.
detail on the inputs and outputs of the specific lifecycle
stage it describes.
The strength of the service lifecycle rests upon
continual feedback throughout each stage of
the lifecycle. This feedback ensures that service
optimization is managed from a business perspective
and is measured in terms of the value the business
derives from services at any point in time during the
service lifecycle. The service lifecycle is non-linear
in design. At every point in the service lifecycle, the
process of monitoring, assessment and feedback

Service transition
principles 3
11/07/2011 15:41
| 37

3 Service transition principles
This chapter describes the key policies and 3.1.1 Define and implement a formal
principles that will enable service providers to plan policy for service transition
and implement service transition best practice.
These principles are the same irrespective of the 3.1.1.1 Policy
organization; however, the approach may need ■■ A formal policy for service transition should
to be tailored to circumstances, including size, be defined, documented and approved by
distribution, culture and resources. the management team, who ensure that it is
communicated throughout the organization
3.1 Policies for service transition and to all relevant suppliers and partners.
The following are examples of policies for service

3.1.1.2 Principles
transition. Every service provider should agree and
■■ Policies should clearly state the objectives, and
document policies that are appropriate for their
circumstances. Endorsement and visible support any non-compliance with the policy must be
from senior management contribute to the overall remedied.
effectiveness. Each policy is explicitly stated and its ■■ Policies should be aligned with the overall
suggested application and approach are illustrated governance framework, organization and
by applicable principles and best practices that help service management policies, with appropriate
an organization to deliver that principle. Examples auditing and enforcement. This should include
of these policies include: alignment with ISO/IEC 20000, ISO/IEC 38500
and COBIT where these have been adopted.
■■ Define and implement a formal policy for
■■ Sponsors and decision makers involved in
service transition
developing the policy must demonstrate their
■■ Implement all changes to services through commitment to adapting and implementing the
service transition policy. This includes the commitment to deliver
■■ Adopt a common framework and standards predicted outcomes from any change in the
■■ Maximize re-use of established processes and services.
systems ■■ Processes should integrate teams, blending
■■ Align service transition plans with the business competencies while maintaining clear lines of
needs accountability and responsibility.
■■ Establish and maintain relationships with ■■ Changes should be delivered in releases, except
stakeholders for standard changes and some emergency
■■ Establish effective controls and disciplines changes.
■■ Provide systems for knowledge transfer and ■■ Deployment must be addressed early in the
decision support release design and release planning stages.
■■ Plan release packages
■■ Anticipate and manage course corrections 3.1.1.3 Best practice
■■ Proactively manage resources across service ■■ Obtain formal sign-off from the management
transitions team, sponsors and decision makers involved in
■■ Ensure early involvement in the service lifecycle developing the policy.
■■ Provide assurance of the quality of the new or
changed service
■■ Proactively improve quality during service
transition.

38 | Service transition principles
3.1.2 Implement all changes to services or in the case of a standard change it may be

through service transition predefined.
■■ Changes to services are defined in a service
3.1.2.1 Policy design package, which can be used by service
■■ All service changes must be managed by the transition to measure the actual versus
service transition lifecycle stage, except for predicted progress and performance.
standard changes that follow a procedure ■■ The change management process should be
defined during the service transition lifecycle standardized and enforced.
stage. ■■ Management commitment to enforcing the
■■ The scope of service change must be process is essential, and it must be clearly visible
documented. This scope should include all to all stakeholders.
changes to the service portfolio or service ■■ Configuration auditing aims to identify
catalogue and should normally exclude business unauthorized changes.
process changes and some minor operational ■■ Late requests for changes that cannot be
changes. properly managed should not be accepted.
3.1.2.1 Principles 3.1.3 Adopt a common framework and

■■ There should be a single focal point for standards
changes to supported services, to minimize the
probability of conflicting changes and potential 3.1.3.1 Policy
disruption. ■■ Base service transition on a common framework
■■ People who do not have the authority to of standard re-usable processes and systems to
make a change or release into the supported improve integration of the parties involved in
environment should be prevented from having service transition and reduce variations in the
access. processes.
■■ Each release will be designed and governed
by a request for change raised via the change
3.1.3.2 Principles
management process to ensure effective control ■■ Implement industry best practice as the basis of
and traceability. standardization to enable integration across the
■■ All standard changes, normal changes and supply chain.
emergency changes must follow policy, ■■ Control the service transition framework
principles and processes defined by service and standards under the direction of
transition. change management and service asset and
■■ Standardized methods and procedures are used configuration management.
for efficient and prompt handling of all changes ■■ Ensure that processes are adopted consistently
in order to minimize the impact of change- by scheduling regular reviews and audits of the
related incidents on business continuity, service service management processes.
quality and re-work.
■■ All updates to changes and releases are 3.1.3.3 Best practice
recorded against service assets and/or ■■ Publish standards and best practices for service
configuration items (CIs) in the configuration transition.
management system. ■■ Provide a framework for establishing consistent
processes for assuring and evaluating the
3.1.2.2 Best practice service capability and risk profile before and
■■ The definition of a change is clearly explained. after a release is deployed. A flowchart such
■■ Internal and external changes are as that shown in Figure 8.2 can be helpful for
differentiated. identifying how the various service transition
■■ Changes are justified through the development processes work together to achieve this.
of a clear business case. This may be provided ■■ Provide supporting systems to automate
as part of the documentation for the change, standard processes in order to reduce resistance
to adoption.

Service transition principles | 39
■■ Ensure that there is management understanding 3.1.5 Align service transition plans with
of the need for standard ways of working by the business needs
developing and delivering improvements based
on a sound business case. 3.1.5.1 Policy
■■ Establish the level of management and ■■ Align service transition plans and new or
stakeholder commitment and take action to changed service with the customer’s and
close any gaps. business organization’s requirements in order to
■■ Continually plan how to improve the buy-in to maximize the value delivered by a change.
adopting a common framework and standards.
3.1.5.2 Principles
3.1.4 Maximize re-use of established ■■ Set customer and user expectations during
processes and systems transition as to how the new or changed service
can be used effectively to enable business
3.1.4.1 Policy change.
■■ Service transition processes are aligned with the ■■ Provide information and establish processes to
organization’s processes and related systems to enable business change projects and customers
improve efficiency and effectiveness, and where to integrate a release into their business
new processes are required they are developed processes and services.
with re-use in mind. ■■ Ensure that the service can be used in
accordance with the requirements and
3.1.4.2 Principles constraints specified within the service
■■ Re-use established processes and systems requirements in order to improve customer and
wherever possible. stakeholder satisfaction.
■■ Capture data and information from the original ■■ Communicate and transfer knowledge to the
source to reduce errors and aid efficiency. customers, users and stakeholders in order to
■■ Develop re-usable standard service transition increase their capability to maximize use of the
models to build up experience and confidence new or changed service.
in the service transition activities. ■■ Monitor and measure the use of the services
■■ Implement industry standards and best practice and underlying applications and technology
as the basis of standardization to enable solutions during deployment and early life
integration of deliverables from many suppliers. support in order to ensure that they are well
established before transition closure.
3.1.4.3 Best practice ■■ Compare the actual performance of services
■■ Integrate the service transition processes into after a transition against the predicted
the overall service management system. performance defined in service design with the
■■ Use the organization’s programme and project aim of reducing variations in service capability
management practices (typically based on and performance.
PRINCE2 or PMBOK).
■■ Use existing communications channels for 3.1.5.3 Best practice
service transition communication. ■■ Adopt programme and project management
■■ Follow human resources, training, finance and best practices to plan and manage the resources
facilities management processes and common required to package, build, test and deploy a
practices. release successfully within the predicted cost,
■■ Design service transition models that enable quality and time estimates. These practices will
easy customization to suit specific circumstances. typically be based on PRINCE2 or PMBOK.
■■ Provide clear and comprehensive plans that
■■ Structure models such that a consistent
approach is repeated for each target service unit enable the customer and business change
or environment with local variation as required. projects to align their activities with the service
transition plans.
■■ Manage stakeholder commitment and
communications.

3.1.6 Establish and maintain relationships 3.1.7.2 Principles

with stakeholders ■■ Establish and maintain the integrity of all
identified service assets and configurations as
3.1.6.1 Policy they evolve through the service transition stage.
■■ Establish and maintain relationships with ■■ Automate audit activities, where beneficial, in
customers, customer representatives, users and order to increase the detection of unauthorized
suppliers throughout service transition in order changes and discrepancies in the configurations.
to set their expectations about the new or ■■ Clearly define ‘who is doing what, when and
changed service. where’ at all handover points to increase
accountability for delivery against the plans and
3.1.6.2 Principles processes.
■■ Set stakeholder expectations on how the ■■ Define and communicate roles and
performance and use of the new or changed responsibilities for handover and acceptance
service can be used to enable business change. through the service transition activities (e.g.
■■ Communicate changes to all stakeholders in build, test, deployment) to reduce errors
order to improve their understanding and resulting from misunderstandings and lack of
knowledge of the new or changed service. ownership.
■■ Provide good-quality knowledge and ■■ Establish transaction-based processes
information so that stakeholders can find for configuration, change and problem
information about the service transition easily, management to provide an audit trail and the
e.g. release and deployment plans, and release management information necessary to improve
documentation. the controls.
■■ Ensure that benefits realization for the business
3.1.6.3 Best practice is measured and reported for every service
■■ Stakeholders should verify that the new or transition.
changed service can be used in accordance with
the requirements and constraints specified 3.1.7.3 Best practice
within the service requirements. ■■ Ensure that roles and responsibilities are
■■ Share service transition and release plans and well defined, maintained and understood
any changes with stakeholders. by those involved and are mapped to any
■■ Work with business relationship management relevant processes for current and foreseen
and service level management to build customer circumstances.
and stakeholder relationships during service ■■ Assign people to each role and maintain
transition. the assignment in the service knowledge
■■ Work with supplier management to ensure management system (SKMS) or configuration
commitment and support from key suppliers management system (CMS) to provide visibility
during and following transition. of the person responsible for particular
activities.
3.1.7 Establish effective controls and ■■ Implement integrated incident, problem,
disciplines change, service asset and configuration
management processes with service level
3.1.7.1 Policy management to measure the quality of
■■ Establish suitable controls and disciplines configuration items throughout the service
throughout the service lifecycle to enable lifecycle.
the smooth transition of service changes and ■■ Ensure that the service can be managed,
releases. operated and supported in accordance with
the requirements and constraints specified
within the service design by the service provider
organization.

■■ Ensure that only competent staff can implement about promoting a release through the
changes to controlled test environments and test environments and into a supported
supported services. environment.
■■ Perform configuration audits and process
audits to identify configuration discrepancies 3.1.8.3 Best practice
and non-conformance that may impact service ■■ Provide easy access, presentation and reporting
transitions. tools for the SKMS and CMS.
■■ Provide quality user interfaces to the SKMS and
3.1.8 Provide systems for knowledge CMS for different people and roles to make
transfer and decision support decisions at appropriate times.
■■ After each transition is complete, publish a
3.1.8.1 Policy summary of the predicted and unpredicted
■■ Service transition develops systems and effects of the change and deviations of actual
processes to transfer knowledge for effective from predicted capability and performance
operation of the service and enable decisions together with the risk profile.
to be made at the right time by competent ■■ Ensure that service asset and configuration
decision makers. management information is accurate to
trigger approval and notification transactions
3.1.8.2 Principles for decision-making via workflow tools, e.g.
■■ Provide quality data, information and changes and acceptance of deliverables.
knowledge at the right time to the right people ■■ Provide knowledge, information and data
to reduce effort spent waiting for decisions and for deployment, service desk, operations and
consequent delays. support teams to resolve incidents and errors.
■■ Ensure that there is adequate training and
knowledge transfer to users to maximize the 3.1.9 Plan release packages
business value created by the new or changed
service and to reduce the number of training 3.1.9.1 Policy
calls that the service desk handles. ■■ Releases are planned and designed to be built,
■■ Improve the quality of information and data tested, delivered, distributed and deployed into
to enhance user and stakeholder satisfaction the live environment in a manner that provides
while optimizing the cost of production and the agreed levels of traceability, in a cost-
maintenance. effective and efficient way.
■■ Improve the quality of release and deployment
documentation to reduce the number of 3.1.9.2 Principles
incidents and problems caused by poor-quality ■■ A release policy is agreed with the business and
user documentation, support or operational all relevant parties.
documentation time between changes being ■■ Releases are planned well in advance.
implemented and the documentation being ■■ Resource utilization is optimized across service
updated. transition activities to reduce costs.
■■ Provide easy access to quality information ■■ Resources are coordinated during release and
to reduce the time spent searching for deployment management.
information, particularly during critical activities
■■ Release and distribution mechanisms are
such as handling a major incident.
planned to ensure that the integrity of
■■ Establish the definitive source of knowledge components during installation, handling,
and share information across the service packaging and delivery is maintained.
lifecycle and with stakeholders in order to
■■ Emergency releases are managed in line with
maximize the quality of information and reduce
the emergency change procedure and are
the overhead in maintaining it.
reported to management as appropriate.
■■ Provide consolidated information to enable
■■ The risks of remediating a failed release are
change and release and deployment
assessed and managed.
management to expedite effective decisions

■■ The success and failure of the release package 3.1.10.1 Policy

is measured with the aim of improving ■■ Use risk assessment and management to identify
effectiveness and efficiency while optimizing and document the range of course corrections
costs. that staff are allowed to implement.
■■ Train staff to recognize the need for course
3.1.9.3 Best practice corrections and empower them to apply
■■ All updates to releases are recorded in the necessary variations within prescribed and
configuration management system. understood limits.
■■ Definitive versions of electronic media,
including software, are captured in a definitive 3.1.10.2 Principles
media library prior to release into the service ■■ Encourage stakeholders to expect changes to
operation readiness test environment. plans and understand that these are necessary
■■ Records are kept of planned release and and beneficial.
deployment dates and deliverables with ■■ Learn from previous course corrections to
references to related change requests and predict future ones and re-use successful
problems. approaches.
■■ Proven procedures are followed for handling, ■■ Debrief and propagate knowledge through
distribution and delivery of release packages, end-of-transition debriefing sessions, and
including verification. make conclusions available through the service
■■ Prerequisites and corequisites for a release are knowledge management system.
documented and communicated to the relevant ■■ Manage course corrections through appropriate
parties, e.g. technical requirements for a test change management, project management and
environment. baseline procedures.
3.1.10 Anticipate and manage course 3.1.10.3 Best practice

corrections ■■ Use project management practices and the
Course corrections change management process to manage course
corrections.
When plotting a long route for a ship or aircraft, ■■ Document and control changes but without
assumptions will be made about prevailing making the process bureaucratic. (It should be
winds, weather and other factors, and plans for easier to do it correctly than to cope with the
the journey prepared. Checks along the way consequences of doing it wrong.)
– observations based on the actual conditions
■■ Provide information on changes that were
experienced – will require (usually minor)
applied after the configuration baseline was
alterations to ensure the destination is reached.
established.
Successful transition is also a journey – from the ■■ Involve stakeholders with changes when
‘as is’ state within an organization towards the appropriate, but manage issues and risks within
‘as-required’ state. In the dynamic world within service transition when appropriate.
which IT service management functions, it is very
often the case that factors arise between initial 3.1.11 Proactively manage resources
design of a changed or new service and its actual across service transitions
transition. This means that ‘course corrections’ to
that service transition journey will be required, 3.1.11.1 Policy
altering the original course of action planned by ■■ Provide and manage shared and specialist
service design in order to reach the destination resources across service transition activities to
agreed with the customer. eliminate delays and optimize utilization of
resources.

3.1.11.2 Principles lifecycle that an error is detected, the higher the

■■ Recognize the resources, skills and knowledge cost of rectification.)
required to deliver service transition within the ■■ Identify changes that will not deliver the
organization. expected benefits, and either change the
■■ Develop a team (including externally sourced service requirements or stop the change before
resources if required) capable of successful resources are wasted.
implementation of the service transition
strategy, service design package and release. 3.1.12.3 Best practice
This team should have the ability to manage all ■■ Involve customers or customer representatives
required organizational change management in service acceptance test planning and test
before, during and after the service transition. design to understand how to validate that the
■■ Establish dedicated resources to perform critical service will add value to the customer’s business
activities to reduce delays. processes and services.
■■ Establish and manage shared resources to ■■ Involve users in test planning and design
improve the effectiveness and efficiency of whenever possible. Base testing on how the
service transition. users actually work with a service – not just on
■■ Automate repetitive and error-prone processes how the designers intended it to be used.
to improve the effectiveness and efficiency ■■ Use previous experience to identify errors in the
of key activities, e.g. distribution, build and service design.
installation. ■■ Build in – at the earliest possible stage – the
ability to check for and to demonstrate that
3.1.11.3 Best practice a new or changed service will be capable of
■■ Work with human resources (HR), supplier delivering the value required of it.
management etc. to identify, manage and make ■■ Use a formal evaluation of the service design
use of competent and available resources. and internal audits to establish whether the
■■ Recognize and use competent and specialist risks of progressing are acceptable.
resources outside the core ITSM team to deliver
service transition. 3.1.13 Provide assurance of the quality of
■■ Proactively manage shared resources to the new or changed service
minimize the impact that delays in one
transition have on another transition.
3.1.13.1 Policy
■■ Measure the impact of using dedicated versus ■■ Verify and validate that the proposed changes
non-dedicated resources on delays, e.g. the to the operational services defined in the service
impact on service transition of using operations and release definitions, service model and
staff who get diverted to fix major incidents. service design package can deliver the required
service requirements and business benefits.
3.1.12 Ensure early involvement in the
3.1.13.2 Principles
service lifecycle
■■ Service transition is responsible for assuring
3.1.12.1 Policy that the proposed changes to the operational
■■ Establish suitable controls and disciplines to services can be delivered according to the
check at the earliest possible stage in the service agreements, specifications and plans within
lifecycle that a new or changed service will be agreed confidence levels.
capable of delivering the value required. ■■ Service transition teams should understand
what the customers and business actually
3.1.12.2 Principles require from a service to improve customers’
■■ Use a range of techniques to maximize fault
and users’ satisfaction.
detection early in the service lifecycle in order to ■■ Quality assurance and testing practices provide
reduce the cost of rectification. (The later in the a comprehensive method for assuring the
quality and risks of new or changed services.

■■ Test environments need to reflect the live ■■ Evaluate the predicted capability, quality
environment to the greatest degree possible and costs of the service design taking into
in order to optimize the testing efforts. A account the results of previous experience and
cost benefit analysis should be performed to stakeholder feedback prior to deployment.
prioritize investments in the test environments. ■■ Consider the circumstances that will actually be
Change management should consider the in place when service transition is complete, not
potential impact of changes on the effectiveness just what was expected at the design stage.
of test environments.
■■ Test design and execution should be managed 3.1.14 Proactively improve quality during
and delivered independently from the service service transition
designer and developer in order to increase
the effectiveness of testing and meet any 3.1.14.1 Policy
‘segregation of duty’ requirements. ■■ Proactively plan and improve the quality of the
■■ Formal evaluations of the service design and the new or changed service during transition.
new or changed service should be performed to
identify the risks that need to be managed and 3.1.14.2 Principles
mitigated during build, test, deployment and ■■ Detect and resolve incidents and problems
use of the service – see section 4.6. during transition to reduce the likelihood of
■■ Problem management and service asset and errors occurring during the operational stage
configuration management processes should of the service lifecycle and adversely affecting
be carried out across the service lifecycle in business operations.
order to measure and reduce the known errors ■■ Proactively manage and reduce incidents,
caused by implementing releases into supported problems and errors detected during service
environments. transition to reduce costs, re-work and the
impact on the user’s business activities.
3.1.13.3 Best practice ■■ Align the management of incidents, problems
■■ Understand the business value that the service and errors during transition with the processes
helps to create and the quality criteria for the used during the service operation stage of
business processes and products that may be the service lifecycle, in order to facilitate
affected by the new or changed service. measurement and management of the impact
■■ Understand the business’s process and priorities and cost of errors across the service lifecycle.
– this often requires an understanding of its
culture, language, customs and customers. 3.1.14.3 Best practice
■■ Comprehensive stakeholder involvement is ■■ Compare actual versus predicted service
important both for effective testing and for capability, performance and costs during pilots
building stakeholder confidence, and so should and early life support in order to identify any
be visible across the stakeholder community. deviations and risks that can be removed prior
■■ Understand the differences between the build, to service transition closure.
test and live environments in order to manage ■■ Perform a formal evaluation of the new or
any differences and improve the ability to changed service to identify the risk profile and
predict a service’s behaviour. prioritize the risks that need to be mitigated
■■ Test environments are maintained under the before transition closure, e.g. security risks that
control of change management and service may impact the warranties.
asset and configuration management, and their ■■ Use the risk profile from the evaluation of the
continued relevance is considered directly as service design to develop risk-based tests.
part of any change. ■■ Provide and test the diagnostic tools and aids
■■ Establish the current service baseline and with the service desk, operations and support
the service design baseline prior to change staff to ensure that if something goes wrong
evaluation. in testing or live use, it is relatively simple to

obtain key information that helps to diagnose ■■ Percentage of customer and stakeholder
the problem without impacting too much on organizations or units that have a clear
the user. understanding of the service transition practice
■■ Encourage cross-fertilization of knowledge and its capabilities
between service transition and service operation ■■ Percentage of service lifecycle budget allocated
stages to improve problem diagnoses and to service transition activities
resolution time, e.g. workarounds and fixes. ■■ Quality rating of the plans including adherence
■■ Establish transition incident, problem, error and to a structured approach, compliance with the
resolution procedures and measures that reflect plan templates and completeness of the plans
those in use in the live environment. ■■ Percentage of planning meetings where
■■ Fix known errors and resolve incidents in stakeholders have participated
accordance with their priority for resolution. ■■ Percentage of service transition plans that are
■■ Document any resolution, e.g. workarounds so aligned with the service transition policies
that the information can be analysed. ■■ Percentage of strategic and tactical projects that
■■ Proactively analyse the root cause of high- adopt the service transition service practices
priority and repeat incidents. ■■ Percentage of release planning documents that
■■ Record, classify and measure the number and are quality assured by staff working in service
impact of incidents and problems against each transition roles.
release in the test, deployment and live service
operation stages in order to identify early 3.2.2 Metrics for service transition
opportunities to fix errors. Measuring and monitoring the performance of the
■■ Compare the number and impact of incidents service transition lifecycle stage should focus on the
and problems between deployments in order to delivery of the new or changed service against the
identify improvements and fix any underlying predicted levels of warranty, service level, resources
problems that will improve the user experience and constraints within the service design or release
for subsequent deployments. package. Metrics should therefore be aligned with
■■ Update incident and problem management with the metrics for service design, and may include the
workarounds and fixes identified in transition. variation in predicted versus actual measures for:
■■ Resource utilization against capacity
3.2 Optimizing service transition ■■ Capabilities (where these can be measured)
performance ■■ Warranties
In order to be effective and efficient, service ■■ Service levels

transition must focus on delivering what the ■■ Cost against approved budget
business requires as a priority and doing so within ■■ Time
financial and other resource constraints. ■■ Quality of service, e.g. satisfaction rating or
service levels met, breached and near misses
3.2.1 Metrics for alignment with the ■■ Value
business and IT plans ■■ Errors and incidents
The service transition lifecycle stage and release ■■ Risks.
plans need to be aligned with the business, service
Examples of other metrics for optimizing the
management and IT strategies and plans.
performance of service transition are:
Typical metrics that can be used in measuring this
■■ Cost of testing and evaluation versus cost of live
alignment are:
incidents
■■ Increased percentage of service transition plans ■■ Delays caused by service transition, e.g. due to a
that are aligned with the business, IT, service lack of service transition resources
management strategies and plans ■■ Operational problems that could have been
identified by the service transition processes

Table 3.1 Service transition inputs and outputs by lifecycle stage

Lifecycle stage Service transition inputs (from the lifecycle stages in the Service transition outputs (to the lifecycle stages
first column) in the first column)
Service strategy Vision and mission Transitioned services
Service portfolio Information and feedback for business cases
Policies and service portfolio
Strategies and strategic plans Response to change proposals
Priorities Service portfolio updates
Change proposals, including utility and warranty Change schedule
requirements and expected timescales Feedback on strategies and policies
Financial information and budgets Financial information for input to budgets
Input to change evaluation and change advisory board Financial reports
(CAB) meetings Knowledge and information in the SKMS
Service design Service catalogue Service catalogue updates
Service design packages, including: Feedback on all aspects of service design and
■■ Details of utility and warranty service design packages
■■ Acceptance criteria Input and feedback on transition plans
■■ Service models Response to RFCs
■■ Designs and interface specifications Knowledge and information in the SKMS
■■ Transition plans (including the CMS)
■■ Operation plans and procedures Design errors identified in transition for re-
Requests for change (RFCs) to transition or deploy new design
or changed services Evaluation reports
Input to change evaluation and CAB meetings
Designs for service transition processes and procedures
Service level agreements, operational level agreements
and underpinning contracts
Service RFCs to resolve operational issues New or changed services
operation Feedback on quality of transition activities Known errors
Input to operational testing Standard changes for use in request fulfilment
Actual performance information Knowledge and information in the SKMS
Input to change evaluation and CAB meetings (including the CMS)
Change schedule
Continual Results of customer and user satisfaction surveys Test reports
service Input to testing requirements Change evaluation reports
improvement Data required for metrics, key performance indicators Knowledge and information in the SKMS
(KPIs) and critical success factors (CSFs) Achievements against metrics, KPIs and CSFs
Input to change evaluation and CAB meetings Improvement opportunities logged in the
Service reports continual service improvement register
RFCs for implementing improvements
■■ Stakeholder satisfaction with the transition ■■ Increased productivity of staff

stage ■■ Increased re-use and sharing of service assets
■■ Cost savings by targeted testing of changes to and service transition process assets
the service design ■■ More motivated staff and improved job
■■ Reduction in emergency, urgent or late changes satisfaction, where this can be measured
and releases – reducing unplanned work ■■ Improved communications and inter-team
■■ Reduced cost of transitioning services and working (IT, customer, users and suppliers),
releases – by type. For example, the cost of where this can be measured
implementing minor infrastructure changes, or ■■ Enhanced performance of service transition
the cost of retiring customer-facing services processes.

3.3 Service transition inputs and

outputs
The main input to service transition is a service
design package, which includes all of the
information needed to manage the entire lifecycle
of a new or changed service. The main output is
the deployment into live use of a new or changed
service, with all the supporting knowledge and
information, tools and processes required to
support the service. Table 3.1 shows the major
service transition inputs and outputs, by lifecycle
stage. Appendix D provides a summary of the
major inputs and outputs between each stage of
the service lifecycle.

Service transition
processes 4
11/07/2011 15:41
| 51

4 Service transition processes
This chapter sets out the processes and activities on 4.1 Transition planning and
which effective service transition depends. These support
comprise both lifecycle processes and those almost
wholly contained within service transition. Each is 4.1.1 Purpose and objectives
described in detail, setting out the key elements of
The purpose of the transition planning and support
that process or activity.
process is to provide overall planning for service
The processes and activities and their relationships transitions and to coordinate the resources that
are set out in Figure 1.2 and the topics specifically they require.
addressed in this chapter are:
The objectives of transition planning and support
■■ Transition planning and support are to:
■■ Change management
■■ Plan and coordinate the resources to ensure that
■■ Service asset and configuration management the requirements of service strategy encoded in
■■ Release and deployment management service design are effectively realized in service
■■ Service validation and testing operation.
■■ Change evaluation ■■ Coordinate activities across projects, suppliers
■■ Knowledge management. and service teams where required.
Some of these processes are used throughout ■■ Establish new or changed services into
the service lifecycle, but they are addressed in supported environments within the predicted
this publication since they are central to effective cost, quality and time estimates.
service transition. ■■ Establish new or modified management
information systems and tools, technology and
The other processes and activities are mostly management architectures, service management
contained within the service transition stage of the processes, and measurement methods and
lifecycle, but are also made use of in other stages; metrics to meet requirements established during
for example, change evaluation of the service the service design stage of the lifecycle.
design, and performance testing within service
■■ Ensure that all parties adopt the common
operation.
framework of standard re-usable processes and
The purpose and scope of service transition as a supporting systems in order to improve the
whole are set out in section 1.1. effectiveness and efficiency of the integrated
planning and coordination activities.
Figure 8.2 gives an example of how the many
processes involved in service transition might ■■ Provide clear and comprehensive plans that
interact. enable customer and business change projects
to align their activities with the service
Note that this chapter does not cover strategic transition plans.
planning for business transformation or ■■ Identify, manage and control risks, to minimize
organizational change, although the interfaces to the chance of failure and disruption across
these processes do need to be managed. Guidance transition activities; and ensure that service
on organizational change is addressed in Chapter transition issues, risks and deviations are
5. Business transformation is the subject of reported to the appropriate stakeholders and
many publications aimed at the general business decision makers.
manager.
■■ Monitor and improve the performance of the
service transition lifecycle stage.

52 | Service transition processes
4.1.2 Scope ■■ The service specifications

The scope of transition planning and support ■■ The service models
includes: ■■ The architectural design required to deliver the
new or changed service, including constraints
■■ Maintaining policies, standards and models for
■■ The definition and design of each release
service transition activities and processes
■■ The detailed design of how the service
■■ Guiding each major change or new service
components will be assembled and integrated
through all the service transition processes
into a release package
■■ Coordinating the efforts needed to enable
■■ Release and deployment management plans
multiple transitions to be managed at the same
■■ The service acceptance criteria.
time
■■ Prioritizing conflicting requirements for service Service design packages will be created (or
transition resources updated) for all major changes. This could include
■■ Planning the budget and resources needed to implementation of new service management
fulfil future requirements for service transition processes or tools, or replacement of old
■■ Reviewing and improving the performance of infrastructure components, as well as release of
transition planning and support activities new or changed services and decommissioning or
■■ Ensuring that service transition is coordinated retiring assets or services.
with programme and project management,
service design and service development 4.1.4.1 Service transition policy
activities. Policies that support service transition are provided
in Chapter 3.
Transition planning and support is not responsible
for detailed planning of the build, test and Policies for change management, service asset
deployment of individual changes or releases; and configuration management, release and
these activities are carried out as part of change deployment management, service validation
management and release and deployment and testing, change evaluation and knowledge
management. management also support service transition and
examples of these are provided in sections 4.2, 4.3,
4.1.3 Value to business 4.4, 4.5, 4.6 and 4.7.
Effective transition planning and support can
significantly improve a service provider’s ability 4.1.4.2 Release policy
to handle high volumes of change and releases The release policy should be defined for one or
across its customer base. An integrated approach more services and include:
to planning improves the alignment of the service ■■ The unique identification, numbering and
transition plans with the customer, supplier and naming conventions for different types of
business change project plans. release together with a description
■■ The roles and responsibilities at each stage
4.1.4 Policies, principles and basic in the release and deployment management
concepts process
This section sets out basic concepts for effective ■■ The requirement to only use software assets
transition planning and support. from the definitive media library
Service design coordination will – in collaboration ■■ The expected frequency for each type of release
with customers, external and internal suppliers and ■■ The approach for accepting and grouping
other relevant stakeholders – develop the service changes into a release, e.g. how enhancements
design and document it in a service design package are prioritized for inclusion
(SDP). The SDP includes the following information ■■ The mechanism to automate the build,
that is required by the service transition teams: installation and release distribution processes to
■■ The service charter, which includes a description
improve re-use, repeatability and efficiency
of the expected utility and warranty, as well as
outline budgets and timescales

Service transition processes | 53
■■ How the configuration baseline for the release their role and level of authority and those of
is captured and verified against the actual others involved in the release and deployment
release contents, e.g. hardware, software, management process.
documentation and knowledge
An example of a responsibility matrix for
■■ Exit and entry criteria and authority for
an organization that supports client–server
acceptance of the release into each service applications is shown in Table 4.1. Such a matrix
transition stage and into the controlled test, will help to identify gaps and overlaps, and typical
training, disaster recovery and other supported roles can be planned for the future.
environments
■■ Criteria and authorization to exit early life All releases should have a unique identifier that
support and handover to the service operation can be used by service asset and configuration
functions. management and the documentation standards.
The types of release should be defined, as this
A release that consists of many different types of helps to set customer and stakeholder expectations
service assets may involve many people, often from about the planned releases. A typical example is:
different organizations. The typical responsibilities
■■ Major releases Normally contain large areas of
for handover and acceptance of a release should
be defined and then they can be modified as new functionality, some of which may eliminate
required for specific transitions. The main roles temporary fixes to problems. A major upgrade
and responsibilities at points of handover should or release usually supersedes all preceding
be defined to ensure that everyone understands minor upgrades, releases and emergency fixes.
Table 4.1 Example of a responsibility matrix for release points during service transition
Development Controlled test Release to production Live
Class of object Released from Accepted by Authority to release to live Accepted and
supported by
Purchased package Application Test manager Change manager/change authority Operations
development manager manager
Customized Application Test manager Change manager/change authority Operations
modules development manager manager
Physical database Application Database Change manager/change authority Database
changes development manager administrator administrator
Server Server builder Server manager Change manager/change authority Server manager
Desktop build (e.g. Desktop development Test manager Change manager/change authority Desktop support
a new application) manager manager
Desktop application Desktop development Desktop support Desktop support manager, change Desktop support
(already built and manager manager manager/change authority manager
within operational
constraints)
Desktop computers Logistics Desktop support Desktop support manager, change Desktop support
manager/change authority manager
Desktop service Service development Desktop support Service level management, desktop Service level
support manager, change manager/ management,
change authority desktop support
manager
Release/change Development Test manager, Release manager, test manager, Service desk
authorization manager, change change manager/ operations manager, desktop users
manager/change change authority support service, desk user at each
authority site, customer stakeholder, change
manager/change authority

■■ Minor releases Normally contain small ●● Agreements and contracts that apply to
enhancements and fixes, some of which may service transition
already have been issued as emergency fixes. A ■■ Organizations and stakeholders involved in
minor upgrade or release usually supersedes all transition:
preceding emergency fixes. ●● Third parties, strategic partners, suppliers
■■ Emergency releases Normally contain and service providers
corrections to a small number of known errors, ●● Customers and users
or sometimes an enhancement to meet a high- ●● Service management
priority business requirement.
●● Service provider
A release policy may specify, for example, that ●● Transition organization (see section 6.2)
only strict ‘emergency fixes’ will be issued between ■■ Framework for service transition:
formally planned releases of enhancements and ●● Policies, processes and practices applicable
non-urgent corrections. to service transition including process service
An extract from a release policy is shown in Table provider interfaces (SPIs)
4.2, which shows how different types of release ●● Integration with policies and methods used
can be defined. In this table the following naming/ for programme and project management
numbering conventions have been used: ●● Roles and responsibilities
■■ Characters before the underscore (for example ●● Transition resource planning and estimation
SS, ESWnnn, ESDnnn) identify the service. ●● Transition preparation and training
■■ Characters after the underscore (for example requirements
x, 1.x, 1.1.x) identify the specific release. ●● The release and change authorization
Characters to the right of decimal points ●● Re-using the organization’s experience,
represent successively minor releases. expertise, tools, knowledge and relevant
historical data
4.1.5 Process activities, methods and ■■ Criteria:
techniques ●● Entry and exit criteria for each release stage
●● Criteria for stopping or re-starting transition
4.1.5.1 Transition strategy activities
The organization should decide the most ●● Success and failure criteria
appropriate approach to service transition based ■■ Identification of requirements and content of
on the size and nature of the services, the number the new or changed service:
and frequency of releases required, and any special
●● Services to be transitioned with target
needs of the users – for example, if a phased
locations, customers and organizational units
deployment is usually required over an extended
●● Release definitions
period of time.
●● Applicable SDP including architectural design
The service transition strategy defines the overall ●● Requirements for environments to be used,
approach to organizing service transition and locations, organizational and technical
allocating resources. The aspects to consider are:
●● Planning and management of environments,
■■ Purpose and objectives of service transition e.g. commissioning and decommissioning
■■ Context, e.g. service customer, contract ■■ People:
agreement portfolio ●● Assigning roles and responsibilities for all
■■ Scope – inclusions and exclusions activities, including authorization
■■ Applicable standards, agreements, legal, ●● Assigning and scheduling training and
regulatory and contractual requirements: knowledge transfer
●● Internal standards ■■ Approach:
●● Interpretation of legislation, industry ●● Transition model including service transition
guidelines and other externally imposed lifecycle stages
requirements and standards ●● Plans for managing changes, assets,
configurations and knowledge

Table 4.2 Extract from a service release policy for a retail organization
Service Release definition* Naming/numbering Frequency/occurrence Release window
Store service Type A SS_x Annual (Feb) Wednesday 01.00–04.00 hours
Type B or C SS_1.x or SS_1.1.x Quarterly Not holiday weekends
Emergency SS_1.1.1.x As required Not 1 September to 31 January
E-store web Type A ESWnnn_x 6 months 01.00–02.00 hours
service Type B or C ESWnnn_1.x Monthly Not holiday weekends
Emergency ESWnnn_1.1.x As required Not 1 October to 10 January
E-store delivery Type A ESDnnn_x 6 months 01.00–02.00 hours
service Type B ESDSnnn_1.x Quarterly Highest level of authorization
Type C ESDnnn_1.1.x Monthly required during holiday
Emergency ESDnnn_1.1.1.x As required weekends
*Release definitions
Type A Something that impacts the whole system/service.
Type B A release that will impact part of the system, e.g. single sub-system or sub-service.
Type C Correction to a single function.
Emergency A change required to restore or continue service to ensure that the service level agreement (SLA) is
maintained.
Baseline and evaluation points

●● ■■ Schedule of milestones
●● Configuration audit and verification points ■■ Financial requirements – budgets and funding.
●● Points where change authorization is needed
●● Use of change windows 4.1.5.2 Service transition lifecycle stages
●● Transition estimation, resource and cost The SDP should define the lifecycle stages for the
planning service transition, and the move from one stage to
●● Preparation for service transition the next should be subject to formal checks. Typical
●● Change evaluation and change authorization stages in the life of a transition might include:
●● Release planning, build, test, deployment ■■ Acquire and test new configuration items (CIs)
and early life support and components
●● Error handling, correction and control ■■ Build and test
●● Management and control – recording, ■■ Service release test
progress monitoring and reporting ■■ Service operational readiness test
●● Service performance and measurement ■■ Deployment
system ■■ Early life support
●● Key performance indicators (KPIs) and ■■ Review and close service transition.
improvement targets
For each stage there will be exit and entry criteria
■■ Deliverables from transition activities, including
and a list of mandatory deliverables from the
mandatory and optional documentation for
stage. These criteria are often implemented as
each stage:
‘quality gates’ at specific stages in the design and
●● Transition plans
transition of a new or changed service. Each quality
●● Change management and service asset and
gate will define a standard set of criteria which
configuration management (SACM) plans must be met before the service can move to the
●● Release policy, plans and documentation next stage.
●● Test plans and reports
●● Build plans and documentation 4.1.5.3 Prepare for service transition
●● Evaluation plan and report The service transition preparation activities include:
●● Deployment plans and reports
■■ Review and acceptance of inputs from the other
●● Transition closure report
service lifecycle stages

■■ Review and check the input deliverables, e.g. ■■ Schedule of milestones, handover and delivery
change proposal, SDP, service acceptance criteria dates
and evaluation report (see section 4.6.6) ■■ Activities and tasks to be performed
■■ Identifying, raising and scheduling requests for ■■ Staffing, resource requirements, budgets and
change (RFCs) time-scales at each stage
■■ Checking that the configuration baselines are ■■ Issues and risks to be managed
recorded in the configuration management ■■ Lead times and contingency.
system (CMS) before the start of service
transition (see section 4.3.4.2) Allocating resources to each activity and factoring
in resource availability will enable the service
■■ Checking transition readiness.
transition planner to work out whether the
The configuration baselines help to fix a point transition can be deployed by the required date.
in history that people can reference and apply If resources are not available, it may be necessary
changes to in a manner that is understandable. to review other transition commitments and
Any variance in the proposed service scope, service consider changing priorities. Such changes need
strategy requirements and service design baseline to be discussed with people responsible for
must be requested and managed through change change management and release and deployment
management. management as this may affect other changes that
At a minimum, it should be accepted (by people could be dependent on or prerequisites for the
responsible for service design and service release.
transition, and other stakeholders) that the service Integrated planning
design and all the release units can be operated
Good planning and management are essential for
and supported within the predicted constraints
successful deployment of a release into production
and environment. The change evaluation activity
across distributed environments and locations.
described in section 4.6 performs the evaluation
It is important to maintain an integrated set of
of the SDP and service acceptance criteria and
transition plans that are linked to lower-level plans
provides a report to change management with
such as release build and test plans. These plans
recommendations on whether the change should
should be integrated with the change schedule
be authorized.
and release and deployment management
plans. Establishing good-quality plans at the
4.1.5.4 Planning and coordinating service
outset enables service transition to manage and
transition coordinate the service transition resources, e.g.
Planning an individual service transition resource allocation, utilization, budgeting and
The release and deployment management activities accounting.
should be planned in stages as details of the An overarching service transition plan should
deployment might not be known in detail initially. include the milestone activities to acquire the
Each service transition plan should be developed release components, package the release, build,
from a proven service transition model wherever test, deploy, evaluate and proactively improve
possible. Although service design provides the the service through early life support. It will
initial plan, the planner will allocate specific also include the activities to build and maintain
resources to the activities and modify the plan the services and IT infrastructure, systems and
to fit in with any new circumstances (e.g. a test environments and the measurement system to
specialist may have left the organization). support the transition activities.
A service transition plan describes the tasks and Adopting programme and project management
activities required to release and deploy a release
best practice
into the test environments and into production,
including: It is best practice to manage several releases
and deployments as a programme, with each
■■ Work environment and infrastructure for the significant deployment run as a project. This will
service transition typically be based on PRINCE2 or PMBOK. The
actual deployment may be carried out by dedicated

staff as part of broader responsibilities such as ■■ Have circumstances changed such that the
operations or through a team brought together for approach needs amending?
the purpose. Elements of the deployment may be ■■ Were the rules and guidance on how to apply it
delivered through external suppliers, and suppliers relevant for current service and release?
may deliver the bulk of the deployment effort, for ■■ Do the people who need to use the plans
example in the implementation of a commercial understand and have the requisite skills to use
off-the-shelf system such as an ITSM support tool. them?
Significant deployments will be complex projects in ■■ Is the service release within the SDP and the
their own right. The steps to consider in planning scope of the issues addressed by the transition
include the range of elements comprising that model?
service, e.g. people, application, hardware,
software, documentation and knowledge. This Example: Anticipating changed business
means that the deployment will contain sub- circumstances
deployments for each type of element comprising A new version of a retail organization’s point-
the service. of-sale system was designed and ready for
Reviewing the plans transition to the live environment. Although
the new version offered added features, most
All service transition and release and deployment
improvements related to ease of use, ease of
plans should be reviewed. Wherever possible, lead
support and maintainability of the software.
times should include an element of contingency
and be based on experience rather than merely The transition was originally scheduled for
supplier assertion. This applies even more for installation in September, but due to delays in
internal suppliers where there is no formal third-party suppliers the service was not ready
contract. Lead times will typically vary seasonally, for test and subsequent deployment until late
and they should be factored into planning, November. The initially planned approach of
especially for long time-frame transitions, where involving 20% of user staff in acceptance trials
the lead times may vary between stages of a and store disruption across the user base was
transition, or between different user locations. no longer appropriate. With the Christmas sales
boom imminent, such disruption would have
Before starting the release, the service transition
been prevented by the annual change freeze.
planning role should verify the plans and ask
Instead, a longer, slower but less resource-
appropriate questions such as:
intensive acceptance-testing approach was
■■ Are these service transition and release plans up selected with deployment to stores rescheduled
to date? for late January.
■■ Have the plans been agreed and authorized Where the transition approach does require
by all relevant parties, e.g. customers, users, rethinking and probable alteration, this
operations and support staff? should be delivered through the formal
■■ Do the plans include the release dates and change management process, since the
deliverables and refer to related change consideration of alternatives and agreement
requests, known errors and problems? of the revised transition approach must
■■ Have the impacts on costs, organizational, be properly documented. However, for
technical and commercial aspects been foreseeable scenarios, where the path of action
considered? is documented as an accepted reaction to the
■■ Have the risks to the overall services and circumstances, authority to record and proceed
operations capability been assessed? with a change may be delegated to service
■■ Has there been a compatibility check to transition or another appropriate party for
ensure that the configuration items that are authorization, e.g. customer or project. For
to be released are compatible with each other example, where the service transition milestone
and with configuration items in the target dates and release dates can be achieved with the
environments? same cost and resources and with no impact on
the service definition.

■■ Has the service design altered significantly such Communication

that it is no longer appropriate? Managing communication throughout a service
■■ Have potential changes in business transition is absolutely critical to success. A
circumstances been identified? (An example of communication plan should include:
anticipating changed business circumstances is
■■ Objectives of the communication
shown.)
■■ Defined stakeholders, including users,
4.1.5.5 Provide transition process support customers, IT staff, suppliers and customers of
the business (if appropriate)
Advice ■■ Communication content for each type of
Service transition should provide support for stakeholder
all stakeholders to enable them to understand ■■ Communication frequency (daily, weekly etc.),
and follow the service transition framework which may vary for each stakeholder group at
of processes and supporting systems and tools. different stages of the transition
Although the transition planning and support team
■■ Channel and format (newsletters, posters,
may not have the specialist resources to handle
emails, reports, presentations etc.)
some issues, it is important that they are able to
■■ How the success of the communication will be
identify relevant resources that can help projects
measured.
– e.g. experts who can set up the configuration
management system or testing tools. Plans and progress should be communicated and
made available to relevant stakeholders. The
Projects should implement service transition
stakeholder list is defined in the service design
activities and tasks in accordance with applicable
package received from the service design stage
service transition standards, policies and
of the lifecycle, and people working in the service
procedures, which should be documented by each
transition stage should establish the continued
organization based on best practice as described
relevance of that list and update it as necessary.
in this publication. However, project managers
are not always aware of the need to adopt Progress monitoring and reporting
these standards, policies and procedures. When Service transition activities should be monitored
new projects start up, transition planning and against the intentions set out in the transition
support should proactively seek opportunities for model and plan. Measuring and monitoring the
establishing the service transition processes into release and deployment will establish whether the
the project quickly – before alternative methods transition is proceeding according to plan.
are adopted. Another approach is to work closely
with the programme or project support and offer Maintaining an oversight of the actual transitions
support to projects via this route. against the integrated service transition plans,
release and change schedules is essential. This
Administration includes monitoring the progress of each transition
Transition planning and support should provide periodically and at milestone or baseline points as
administration for: well as receiving and chasing updates.
■■ Managing service transition changes and work Management reports on the status of each
orders transition will help to identify when there are
■■ Managing issues, risks, deviations and waivers significant variances from plan so that, for
■■ Managing support for tools and service example, project management and the service
transition processes management organization can make decisions and
■■ Monitoring the service transition performance take action.
to provide input into continual service In many cases the transition plans will require
improvement. amendment to bring them into line with a
Changes that affect the agreed baseline reality that has changed since design. This is not
configuration items are controlled through change synonymous with bad design or error in selecting
management. transition models, but merely a reflection of a
dynamic environment.

4.1.6 Triggers, inputs, outputs and service transition teams – especially in the

interfaces areas of release build and test and release
deployment. Key inputs to this SDP will come
4.1.6.1 Trigger from service level management, information
The trigger for planning a single transition is an security management, IT service continuity
authorized change. Longer-term planning may be management, availability management and
triggered by receipt of a change proposal from capacity management.
service portfolio management. Budgeting for ■■ Supplier management will work during the
future transition requirements will be triggered by service transition to ensure that appropriate
the organization’s budgetary planning cycle. contracts are in place.
■■ All service transition processes are coordinated
4.1.6.2 Inputs by transition planning and support, so service
The inputs to transition planning and support are: transition planning and support must have
interfaces to change management, SACM,
■■ Change proposal release and deployment management, service
■■ Authorized change validation and testing, change evaluation and
■■ Service design package, which includes: knowledge management.
●● Release package definition and design ■■ Pilots, handover and early life support must
specification be coordinated with the service operation
●● Test plans functions.
●● Deployment plans ■■ Technical management and application
●● Service acceptance criteria (SAC). management will provide the personnel needed
to carry out many aspects of service transition,
4.1.6.3 Outputs for example to review changes or plan
deployments.
The outputs from transition planning and support
are: There are also interfaces with project and
programme management teams, which have to
■■ Transition strategy and budget
work very closely with transition planning and
■■ Integrated set of service transition plans.
support, and with customers who must be involved
in many aspects of service transition.
4.1.6.4 Interfaces
Transition planning and support has interfaces to 4.1.7 Information management
almost every other area of service management:
The transition planning and support process makes
■■ Demand management should provide long-term heavy use of the service knowledge management
information about likely resource requirements. system, to provide access to the full range of
■■ The service portfolio management process information needed for short-, medium- and long-
should engage transition planning and support range planning.
to provide input to their planning and decision- Transition planning and support needs access to
making. information about new or changed services to
■■ Service portfolio management will submit create and manage plans. This information may
a change proposal to trigger longer-term be found in many structured and unstructured
planning within transition planning and documents, such as guidelines, standards, models
support. and plans, as well as in documents created and
■■ Business relationship management will help to maintained by other processes such as service
manage appropriate two-way communication design packages, contracts and operational level
with customers. agreements (OLAs) and process documentation.
■■ Key inputs to transition planning and support Timely access to up-to-date versions of these
come from the service design stage of the documents is essential so that transition plans can
lifecycle in the form of a service design package. be created and managed. All of these documents
It is common for some design work to actually
be carried out by personnel who work within

should be stored in the service knowledge ●● KPI Reduction in time and resource to
management system (SKMS) and managed via develop and maintain integrated plans and
change management and the CMS. coordination activities
■■ CSF Managing conflicting demands for shared
4.1.8 Critical success factors and key resources
performance indicators ●● KPI Increased project and service team
The following list includes some sample critical satisfaction with the service transition
success factors (CSFs) for transition planning practices
and support. Each organization should identify ●● KPI Reduced number of issues caused by
appropriate CSFs based on its objectives for conflicting demands for shared resources.
the process. Each sample CSF is followed by a
small number of typical KPIs that support the 4.1.9 Challenges and risks
CSF. These KPIs should not be adopted without
careful consideration. Each organization should 4.1.9.1 Challenges
develop KPIs that are appropriate for its level of The biggest challenge for transition planning and
maturity, its CSFs and its particular circumstances. support is building up the relationships needed
Achievement against KPIs should be monitored and to manage and coordinate the many stakeholders
used to identify opportunities for improvement, who may be involved in service transition. Often
which should be logged in the continual service the relationships are not hierarchical and require
improvement (CSI) register for evaluation and careful negotiation.
possible implementation.
Coordinating and prioritizing many new or
■■ CSF Understanding and managing the trade- changed services can be a big challenge, especially
offs between cost, quality and time if there are delays or test failures that cause
●● KPI Increase in the number of releases projects to slip. Transition planning and support
implemented that meet the customer’s needs to understand the risks and issues for each
agreed requirements in terms of cost, quality, project in order to proactively manage resource
scope and release schedule (expressed as a planning.
percentage of all releases)
●● KPI Reduced variation of actual versus 4.1.9.2 Risks
predicted scope, quality, cost and time Risks to transition planning and support include:
■■ CSF Effective communication with stakeholders ■■ Lack of information from demand management
●● KPI Increased customer and user satisfaction and service portfolio management resulting in a
with plans and communications reactive transition planning and support process
●● KPI Reduced business disruption due to with insufficient long-term planning
better alignment between service transition ■■ Poor relationships with project and programme
plans and business activities teams resulting in sudden and unexpected
■■ CSF Identifying and managing risks of failure service transition requirements
and disruption ■■ Delays to one transition having a subsequent
●● KPI Reduction in number of issues, risks and effect on future transitions, due to resource
delays constraints
●● KPI Improved service transition success rates ■■ Insufficient information to prioritize conflicting
■■ CSF Coordinating activities of multiple requirements.
processes involved in each transition
●● KPI Improved efficiency and effectiveness of
4.2 Change management
the processes and supporting systems, tools,
knowledge, information and data to enable Changes are made for a variety of reasons and in
the transition of new and changed services, different ways – for example:
e.g. sharing tool licences

■■ Proactively, e.g. when organizations are ■■ Respond to the customer’s changing business
seeking business benefits such as reduction in requirements while maximizing value and
costs, improved services or increased ease and reducing incidents, disruption and re-work.
effectiveness of support ■■ Respond to the business and IT requests for
■■ Reactively as a means of resolving errors and change that will align the services with the
adapting to changing circumstances. business needs.
Changes should be managed in order to: ■■ Ensure that changes are recorded and
evaluated, and that authorized changes are
■■ Optimize risk exposure (supporting the risk prioritized, planned, tested, implemented,
profile required by the business) documented and reviewed in a controlled
■■ Minimize the severity of any impact and manner.
disruption ■■ Ensure that all changes to configuration items
■■ Achieve success at the first attempt are recorded in the configuration management
■■ Ensure that all stakeholders receive appropriate system.
and timely communication about the change ■■ Optimize overall business risk – it is often
so that they are aware and ready to adopt and correct to minimize business risk, but sometimes
support the change. it is appropriate to knowingly accept a risk
Such an approach will improve the bottom line because of the potential benefit.
for the business by delivering early realization of
benefits (or removal of risk) while saving money 4.2.2 Scope
and time. Change can be defined in many ways. The ITIL
definition of a change is ‘the addition, modification
An appropriate response to all requests for change
or removal of anything that could have an effect
entails a considered approach to assessment of risk
on IT services’. The scope should include changes
and business continuity, change impact, resource
to all architectures, processes, tools, metrics and
requirements, change authorization and especially
documentation, as well as changes to IT services
to the realizable business benefit. Risk assessment
and other configuration items.
should consider the risk of not implementing the
change as well as any risks that the change might All changes must be recorded and managed in a
introduce. This considered approach is essential to controlled way. The scope of change management
maintain the required balance between the need covers changes to all configuration items across
for change and the impact of that change. the whole service lifecycle, whether these CIs are
physical assets such as servers or networks, virtual
This section provides information on the change
assets such as virtual servers or virtual storage,
management process and provides guidance that is
or other types of asset such as agreements or
scalable for:
contracts. It also covers all changes to any of the
■■ Different kinds and sizes of organization five aspects of service design:
■■ Small and large changes required at each
■■ Service solutions for new or changed services,
lifecycle stage
including all of the functional requirements,
■■ Changes with major or minor impact resources and capabilities needed and agreed
■■ Changes in a required time frame ■■ Management information systems and
■■ Different levels of budget or funding available tools, especially the service portfolio, for the
to deliver change. management and control of services through
their lifecycle
4.2.1 Purpose and objectives ■■ Technology architectures and management
The purpose of the change management process architectures required to provide the services
is to control the lifecycle of all changes, enabling ■■ Processes needed to design, transition, operate
beneficial changes to be made with minimum and improve the services
disruption to IT services. ■■ Measurement systems, methods and metrics for
The objectives of change management are to: the services, the architectures, their constituent
components and the processes.

Each organization should define the changes that Strategic changes are brought in via service
lie outside the scope of its change management strategy and the service portfolio management
process. Typically these might include: process in the form of change proposals. Changes
to a service will be brought in via service design,
■■ Changes with significantly wider impacts than
continual service improvement, service level
service changes, e.g. departmental organization,
management and service catalogue management.
policies and business operations – these changes
Corrective change, resolving errors detected in
would produce RFCs to generate consequential
services, will be initiated from service operation
service changes.
and may route via support or external suppliers
■■ Changes at an operational level such as repair to
into a formal RFC.
printers or other routine service components.
Change management is not responsible for
Figure 4.1 shows the typical scope of a change
coordinating all of the service management
management process for an IT organization and
processes to ensure the smooth implementation
how it interfaces with the business and suppliers at
of projects. This activity is carried out by transition
strategic, tactical and operational levels. It covers
planning and support.
interfaces to internal and external service providers
where there are shared assets and configuration
4.2.3 Value to business
items that need to be under change management.
Change management must interface with business Reliability and business continuity are essential
change management (to the left in Figure 4.1) for the success and survival of any organization.
and with the supplier’s change management (to Service and infrastructure changes can have a
the right in the figure). This may be an external negative impact on the business through service
supplier within a formal change management disruption and delay in identifying business
system, or the project change mechanisms within requirements, but change management enables
an internal development project. the service provider to add value to the business
by:
The service portfolio provides a clear definition
of all current, planned and retired services. ■■ Protecting the business, and other services,
Understanding the service portfolio helps all while making required changes
parties involved in the service transition to ■■ Implementing changes that meet the customers’
understand the potential impact of the new or agreed service requirements while optimizing
changed service on current services and other new costs
or changed services.
Business Service provider Supplier
Manage the
Strategic Manage the
Manage IT services supplier’s
change business business
Manage the Manage

Tactical Service
business external
change portfolio
processes services
Service
change
Manage
Operational Service External
business
change operations operations
operations
Figure 4.1 Scope of change management and release and deployment management for services

■■ Contributing to meet governance, legal, ■■ Notifying affected parties (of what is proposed,
contractual and regulatory requirements planned and implemented)
by providing auditable evidence of change ■■ Recording and maintaining accurate change,
management activity. This includes better configuration, and release and deployment
alignment with ISO/IEC 20000, ISO/IEC 38500 records
and COBIT where these have been adopted ■■ Managing and resolving incidents caused by
■■ Reducing failed changes and therefore service change
disruption, defects and re-work ■■ Identifying the problems that continually arise
■■ Reducing the number of unauthorized which require more change
changes, leading to reduced service disruption ■■ Introducing new ideas and technology that
and reduced time to resolve change-related cause even more change.
incidents
There are therefore considerable cost savings and
■■ Delivering change promptly to meet business
efficiencies to be gained from well-structured and
timescales
planned changes and releases.
■■ Tracking changes through the service lifecycle
and to the assets of its customers As there is so much focus today on enterprise risk
■■ Contributing to better estimates of the quality, management, change management is a key process
time and cost of change that comes under the scrutiny of auditors.
■■ Assessing the risks associated with the transition
of services (introduction or disposal) 4.2.4 Policies, principles and basic
■■ Improving productivity of staff by minimizing concepts
disruptions caused by high levels of unplanned This section sets out basic concepts within change
or ‘emergency’ change and hence maximizing management that support its effective execution.
service availability
■■ Reducing the mean time to restore service 4.2.4.1 Policies
(MTRS), via quicker and more successful Increasing the success rate of changes and releases
implementations of corrective changes requires executive support for implementing a
■■ Liaising with the business change process culture that sets stakeholder expectations about
to identify opportunities for business changes and releases and reduces unplanned work.
improvement.
Pressure will be applied to reduce timescales and
meet deadlines; to cut budgets and operating
Example of IT service-initiated business change
costs; and to compromise testing. This must not
In the retail industry, bar-coding of goods be done without due diligence to governance and
coupled with bar-code readers at the checkout risk. The service transition management team will
was initially introduced to deliver savings be called on from time to time to make a ‘no go’
by removing the need to label every item, decision and not implement a required change.
automating stock control, speeding customer There must be policies and standards defined
throughput and reducing checkout staff. which make it clear to the internal and external
Suggestions from IT to the business resulted in providers what must be done and what the
making use of this facility to power innovative consequences of non-adherence to policy will be.
concepts such as ‘buy one get one free’ and
Policies that support change management include:
capturing data on each individual’s purchasing
habits. ■■ Creating a culture of change management
across the organization where there is zero
The reliance on IT services and underlying tolerance for unauthorized change
information technology is now so complex that ■■ Aligning the change management process
considerable time can be spent on: with business, project and stakeholder change
management processes
■■ Assessing the impact of business change on IT
■■ Ensuring that changes create business value and
■■ Analysing the impact of a service or IT change that the benefits for the business created by
on the business each change are measured and reported

■■ Prioritization of change, e.g. innovation versus ●● Change authorization – levels of

preventive versus detective versus corrective authorization and rules that govern decision-
change making and actions, e.g. escalation
■■ Establishing accountability and responsibilities ●● Composition of advisory boards, e.g. the
for changes through the service lifecycle change advisory board (CAB) and the
■■ Segregation of duty controls emergency CAB (ECAB)
■■ Establishing a single focal point for changes in ■■ Stakeholders:
order to minimize the likelihood of conflicting ●● Planning of changes and releases to enable
changes and potential disruption to supported stakeholders to make their own preparations
environments and plan their activities
■■ Preventing people who are not authorized to ●● Communicating changes, change schedule
make a change from having access to supported and release plans
environments ■■ Grouping and relating changes:
■■ Integration with other service management ●● Into a planned change window
processes to establish traceability of change, ●● Into a release, build or baseline
detect unauthorized change and identify ●● By linking several RFCs to a change proposal
change-related incidents
●● By linking several child RFCs to a master RFC
■■ Change windows – enforcement and
■■ Procedures:
authorization for exceptions
●● Change authorization policies, rules and
■■ Performance and risk evaluation of all changes
procedures
that impact service capability
●● Methods of raising an RFC
■■ Performance measures for the process, e.g.
●● Tracking and management of change
efficiency and effectiveness.
requests, i.e. change records
●● Prompt impact assessment and evaluation of
4.2.4.2 Design and planning considerations
change requests
The change management process should
●● Identification of dependencies and
be planned in conjunction with release and
incompatibilities between changes
deployment management and service asset and
●● Verification of the implementation of a
configuration management. This helps the service
provider to evaluate the impact of the change on change
the current and planned services and releases. ●● Oversight and evaluation of deliverables
from change and release implementation
The requirements and design for the change
●● Measurement and reporting of change
management processes include:
success and business value created
■■ Requirements, e.g. to comply with relevant ●● Regular review of changes to identify trends
legislation, industry codes of practice, standards and improvements, e.g. in the success or
and organizational practices failure of changes and releases
■■ Approach to eliminating unauthorized change ■■ Interfaces to other service management
■■ Identification and classification: processes, for example service level
●● Change document identifiers management, IT service continuity
●● Change document types, change management, information security
documentation templates and expected management, availability management and
content capacity management for impact assessment
●● Impact, urgency, priorities
and review
■■ Organization, roles and responsibilities:
■■ Approach to interfacing change, release and
deployment, and service asset and configuration
●● Accountabilities and responsibilities of all
management with problem and incident
stakeholders
management processes to measure and reduce
●● Approach to independent testing and formal
change-related incidents
evaluation of change
■■ Service asset and configuration management
interfaces:

●● Providing quality information for impact As much use as possible should be made of
assessment and reporting, e.g. comparison devolved authorization, both through the standard
of current configuration to planned change procedure and through the authorization
configuration of minor changes by change management staff.
●● Identifying high-risk, high-impact CIs During the planning of different types of change
●● Capturing CIs, configuration baselines and requests, each must be defined with a unique
releases naming convention (see section 4.3.5.3). Table 4.3
●● Capturing related deliverables, e.g. provides examples of different types of change
acceptance criteria, test and evaluation request across the service lifecycle.
reports.
For different change types there are often specific
procedures, e.g. for impact assessment and change
4.2.4.3 Types of change request
authorization.
A change request is a formal communication
seeking an alteration to one or more configuration 4.2.4.4 Changes, RFCs and change records
items. This could take several forms, e.g. a ‘request
The terms ‘change’, ‘change record’ and ‘RFC’ are
for change’ document, service desk call or project
often used inconsistently, leading to confusion. The
initiation document. Different types of change
usage in this publication is as follows:
may require different types of change request. For
example, a major change may require a change ■■ Change The addition, modification or removal
proposal, which is usually created by the service of anything that could have an effect on IT
portfolio management process. An organization services. The scope should include changes to
needs to ensure that appropriate procedures all architectures, processes, tools, metrics and
and forms are available to cover the anticipated documentation, as well as changes to IT services
requests. Avoiding a bureaucratic approach to and other configuration items.
documenting a minor change removes some ■■ RFC A request for change – a formal proposal
of the cultural barriers to adopting the change for a change to be made. It includes details of
management process. the proposed change, and may be recorded
There are three different types of service change: on paper or electronically. The term RFC is
often misused to mean a change record, or the
■■ Standard change A pre-authorized change that change itself.
is low risk, relatively common and follows a ■■ Change record A record containing the details
procedure or work instruction. of a change. Each change record documents the
■■ Emergency change A change that must be lifecycle of a single change. A change record
implemented as soon as possible, for example to is created for every request for change that
resolve a major incident or implement a security is received, even those that are subsequently
patch. rejected. Change records should reference the
■■ Normal change Any service change that is not a configuration items that are affected by the
standard change or an emergency change. change. Change records may be stored in the
Changes are often categorized as major, significant configuration management system or elsewhere
or minor, depending on the level of cost and risk in the service knowledge management system.
involved, and on the scope and relationship to RFCs are only used to submit requests; they are
other changes. This categorization may be used not used to communicate the decisions of change
to identify an appropriate change authority. See management or to document the details of the
section 4.2.5.5 for more information about change change. A change record contains all the required
authorities. information about a change, including information
Management of standard changes is described in from the RFC, and is used to manage the lifecycle
section 4.2.4.7. Management of normal changes of that change.
is described in sections 4.2.5.1 to 4.2.5.10, and
differences for managing emergency changes are
described in section 4.2.5.11.

Table 4.3 Example of types of request by service lifecycle stage

Type of change with Documented work Service Service Service Service Continual
examples procedures strategy design transition operation service
improvement
Request for change to service Service change
portfolios management
New portfolio line item ü
To predicted scope, business
case, baseline
Service pipeline
Request for change to service Service change
or service definition management
To existing or planned service ü ü ü ü ü
attributes
Project change that
impacts service design, e.g.
forecasted warranties
Service improvement
Project change proposal Project change
management procedure
Business change ü ü ü
No impact on service or
design baseline
User access request User access procedure ü
User service request Request fulfilment
process
Standard change ü
Operational activity Local procedure (often
Tuning (within specification/ pre-authorized – see
constraints) section 4.2.4.7)
Restart application on failure ü

if no impact on other services
Planned maintenance
Operational repair Service change
management
Emergency change ü
4.2.4.5 Change models and workflows Changes that require specialized handling could be
Organizations will find it helpful to predefine treated in this way, such as:
change models – and apply them to appropriate ■■ Emergency changes that may have different
changes when they occur. A change model is a way authorization and may be documented
of predefining the steps that should be taken to retrospectively
handle a particular type of change in an agreed ■■ Changes to mainframe software that may
way. Support tools can then be used to manage require specific sequences of testing and
the required process. This will ensure that such implementation
changes are handled in a predefined path and to
predefined timescales.

■■ Implementation of security patches for desktop organizations, change proposals may be created by
operating systems that require specific testing a programme management office or by individual
and guaranteed deployment to large numbers projects. The change proposal should include:
of targets, some of which may not be online
■■ A high-level description of the new, changed
■■ Service requests that may be authorized and
or retired service, including business outcomes
implemented with no further involvement from to be supported, and utility and warranty to be
change management. provided
The change model includes: ■■ A full business case including risks, issues and
alternatives, as well as budget and financial
■■ Steps that should be taken to handle the
expectations
change, including handling issues and
■■ An outline schedule for design and
unexpected events
implementation of the change.
■■ The chronological order in which these steps
should be taken, with any dependences or Change management reviews the change proposal
co-processing defined and the current change schedule, identifies any
■■ Responsibilities – who should do what (including potential conflicts or issues and responds to
identification of those change authorities who the change proposal by either authorizing it or
will authorize the change and who will decide documenting the issues that need to be resolved.
whether formal change evaluation is needed) When the change proposal is authorized, the
■■ Timescales and thresholds for completion of the change schedule is updated to include outline
actions implementation dates for the proposed change.
■■ Escalation procedures – who should be After the new or changed service is chartered,
contacted and when. RFCs will be used in the normal way to request
These models are usually input to the change authorization for specific changes. These RFCs will
management support tools; the tools then be associated with the change proposal so that
automate the handling, management, reporting change management has a view of the overall
and escalation of the process. strategic intent and can prioritize and review these
RFCs appropriately.
4.2.4.6 Change proposals More detail about the content of a change
Major changes that involve significant cost, risk proposal can be found in section 4.2.5.2.
or organizational impact will usually be initiated
through the service portfolio management process. 4.2.4.7 Standard changes (pre-authorized)
Before the new or changed service is chartered A standard change is a change to a service or
it is important that the change is reviewed for other configuration item for which the approach
its potential impact on other services, on shared is pre-authorized by change management,
resources, and on the change schedule. and this approach follows an accepted and
Change proposals are submitted to change established procedure to provide a specific change
management before chartering new or changed requirement. Every standard change should have
services in order to ensure that potential conflicts a change model that defines the steps to follow,
for resources or other issues are identified. including how the change should be logged and
Authorization of the change proposal does not managed as well as how it should be implemented.
authorize implementation of the change but Examples might include an upgrade of a PC
simply allows the service to be chartered so that in order to make use of specific standard and
service design activity can commence. prebudgeted software, provision of standard
A change proposal is used to communicate a equipment and services to a new employee, or a
high-level description of the change. This change desktop move for a single user. Other examples
proposal is normally created by the service include low-impact, routine application change to
portfolio management process and is passed to handle seasonal variation.
change management for authorization. In some

Authorization of each occurrence of a standard Some standard changes will be triggered by the
change will be granted by the delegated authority request fulfilment process and be directly recorded
for that standard change (e.g. by the budget- and passed for action by the service desk.
holding customer for installation of software
from an approved list on a PC registered to their 4.2.4.8 Remediation planning
organizational unit, or by the third-party engineer
for replacement of a faulty desktop printer). Definition: remediation
The crucial elements of a standard change are as Actions taken to recover after a failed change
follows: or release. Remediation may include back-out,
invocation of service continuity plans, or other
■■ There is a defined trigger to initiate the change, actions designed to enable the business process
for example a service request or an exception to continue.
generated by event management.
■■ The tasks are well known, documented and
No change should be authorized without having
proven.
explicitly addressed the question of what to do
■■ Authority is effectively given in advance. if it is not successful. Ideally, there will be a back-
■■ Budgetary approval will typically be out plan, which will restore the organization to
preordained or within the control of the change its initial state, often through the reloading of a
requester. baselined set of CIs, especially software and data.
■■ The risk is usually low and always well However, not all changes are reversible, in which
understood. case an alternative approach to remediation is
Once the approach to manage standard changes required. This remediation may require a revisiting
has been agreed, standard change processes and of the change itself in the event of failure, or
associated change workflows should be developed may be so severe that it requires invoking the
and communicated. A change model would organization’s business continuity plan. Only by
normally be associated with each standard change considering what remediation options are available
to ensure consistency of approach. before instigating a change, and by establishing
that the remediation is viable (e.g. it is successful
Standard changes should be identified early when tested), can the risk of the proposed change
on when building the change management be determined and appropriate decisions taken.
process to promote efficiency. Otherwise, a
change management implementation can create Change implementation plans should include
unnecessarily high levels of administration and milestones and other triggers for implementation
resistance to the change management process. of remediation in order to ensure that there is
sufficient time in the agreed change window for
All changes, including standard changes, will have back-out or other remediation when necessary.
details of the change recorded. For some standard
changes this may be different in nature from 4.2.5 Process activities, methods and
normal change records.
techniques
Some standard changes to configuration items This section provides approaches to managing
may be tracked on the asset or configuration service changes effectively by addressing the
item lifecycle, particularly where there is a tasks carried out to achieve and deliver controlled
comprehensive CMS that provides reports change.
of changes, their current status, the related
configuration items and the status of the related Overall change management activities include:
CI versions. In these cases the change management ■■ Planning and controlling changes
and service asset and configuration management ■■ Change and release scheduling (working with
reporting is integrated, and change management release and deployment management when
can have ‘oversight’ of all changes to service CIs appropriate)
and release CIs. ■■ Communications
■■ Change decision-making and change
authorization

■■ Ensuring that remediation plans are in place way through the activities. This example shows
■■ Measurement and control authorization for change build and test and for
■■ Management reporting change deployment. In practice there may be
■■ Understanding the impact of change additional authorization steps, for example to
authorize change design or change development.
■■ Continual improvement.
Further information about the need for multiple
Typical activities in managing individual changes evaluation and authorization steps can be found in
are: section 4.2.5.4.
■■ Create and record the RFC Figures 4.3 and 4.4 show the equivalent process
■■ Review the RFC flow for some examples of standard change process
●● Filter changes (e.g. incomplete or wrongly flows.
routed changes) After a change has been built and tested, and the
■■ Assess and evaluate the change deployment procedure has been used successfully
●● Establish the appropriate level of change one or more times, then it may be appropriate to
authority use a ‘standard deployment request’ change model
●● Establish relevant areas of interest (i.e. who for future deployments of the same change. This
should be involved in the CAB) is much simpler than the full change management
●● Evaluate the business justification, process flow. Figure 4.3 shows an example of a
impact, cost, benefits, risks and predicted process flow for this kind of standard change.
performance of the change Some very low-risk changes may be delegated to
●● Submit a request for evaluation to initiate service operation staff as a change authority. The
activity from the change evaluation process change model for this kind of standard change may
(see section 4.2.5.4) be very simple, as depicted in Figure 4.4.
■■ Authorize the change
●● Obtain authorization/rejection 4.2.5.1 Normal change procedure
●● Communicate the decision with all The following sections describe the management
stakeholders, in particular the initiator of the of a normal change. The general principles set out
request for change apply to all changes, but where normal change
■■ Plan updates procedure can be modified for emergency changes,
■■ Coordinate change implementation this is described in section 4.2.5.11.
■■ Review and close change
●● Collate the change documentation, e.g. 4.2.5.2 Create and record request for change
baselines and evaluation reports The change is raised by a request from the initiator
●● Review the change(s) and change – the individual or organizational group that
documentation requires the change. For example, this may be a
●● Ensure that details of lessons learned have business unit that requires additional facilities or
been entered into the service knowledge problem management staff instigating an error
management system resolution.
●● Close the change document when all actions
are completed.
Is a major change required?
Throughout all the process activities listed above
and described within this section, information is For a major change with significant
gathered, stored in the SKMS, recorded in the CMS organizational and/or financial implications,
and reported. a change proposal may be required. More
information about change proposals can be
Figure 4.2 shows an example of a change to
found in section 4.2.4.6.
the service provider’s services, applications
or infrastructure. Examples of the status of
the change are shown in italics. Change and
configuration information is updated all the

Role
Create RFC
Change
initiator
Record RFC
Change
Change management
proposal
Requested
(optional)
Review RFC
Change
Activities assigned to the management
role ‘change management’ Ready for evaluation
may be carried out by a
change practitioner, a Assess and
change authority or the evaluate change
change management process Change
owner, depending on management
Ready for decision Work flows
organizational design
Rejected
Update information in CMS

Authorize change
build and test
Change
authority
Authorized
Rejected Coordinate change
build and test*
Change
*Activities to plan, create management
and deploy releases are
Created Work flows
part of the release and
deployment management Authorize change
process Change deployment
authority
Scheduled
Coordinate change
deployment*
Change
management Implemented Work flows
Review and close

change record
Change Closed
management,
change authority,
change initiator
Figure 4.2 Example of a process flow for a normal change
Table 4.4 shows an example of the information The change record holds the full history of the
recorded for a change; the level of detail depends change, incorporating information from the RFC
on the size and impact of the change. Some and subsequently recording agreed parameters
information is recorded when the document is such as priority and authorization, implementation
initiated and some information may be updated and review information. There may be many
as the change document progresses through its different types of change records used to record
lifecycle. Some information is recorded directly different types of change. The documentation
on the request for change form, and details of should be defined during the process design and
the change and actions may be recorded in other planning stage.
documents and referenced from the RFC, e.g. the
Different types of change document will have
business case or impact assessment report.
different sets of attributes to be updated through
the lifecycle. This may depend on various factors

Standard deployment request Role

(where the deployment Generic change
Update change and configuration information in CMS

process is tried and tested) request (from
a template)
Create and review

RFC
Initiator
Requested
Assess and evaluate
RFC Work orders
Change
management Ready for decision
Authorize and
schedule change
Change
authority Scheduled
Coordinate change
implementation*
Change
management Implemented
Review and close
change record
Closed
*Includes build and test the change
Figure 4.3 Example of a process flow for standard deployment request
such as the change model and change category, or to complete work required for a change that is
but it is recommended that the attributes are scheduled for a specific time or where the work is
standardized wherever possible to aid reporting. to be done quickly.
Some systems use work orders to progress the As a change proceeds through its lifecycle, the
change, as this enables complete traceability of the change document, related records (such as work
change. For example, work orders may be issued orders) and related configuration items are
to individuals or teams to do an impact assessment updated in the CMS, so that there is visibility of
its status and compliance to the process. Estimates
and actual resources, costs and outcome (success
or failure) are recorded to enable management
Role reporting.
Update change and configuration
Create RFC Change logging

The procedures for logging and documenting RFCs
information in CMS
Initiator
Requested should be decided. RFCs could be submitted on
paper forms, through email or using a web-based
Implement change interface, for example. Where a computer-based
Change support tool is used, it is possible that the tool
management Implemented might restrict the format.
Review and close All RFCs received should be logged and allocated
change record
an identification number (in chronological
Closed
sequence). Where change requests are submitted
Figure 4.4 Example of a process flow for a in response to a trigger such as a resolution to
standard operational change request a problem record (PR), it is important that the

Table 4.4 Example of contents of change documentation

Attribute on the change record RFC/change Change proposal Related assets/CIs
record (if appropriate)
Unique number ü
Trigger (e.g. to purchase order, problem report ü
number, error records, business need, legislation)
Description Detailed description Description at a
business level
Identity of item(s) to be changed – description of the Detailed description High-level description Service (for
desired change enhancement)
or CI with errors
(corrective changes)
Reason for change, e.g. business case Full justification, Full business case
except if a change
proposal exists
Effect of not implementing the change (business, ü Full business case
technical, financial etc.)
Configuration items and baseline versions to be ü Affected baseline/ Details of CIs in
changed release baseline/release
Contact and details of person proposing the change ü ü
Date and time that the change was proposed ü
Change category, e.g. minor, significant, major Proposed category Used for major changes
only
Predicted timeframe, resources, costs and quality of Full Full business case and
service summary of expected
implementation dates
Change priority Proposed priority
Risk assessment and risk management plan Full High-level risk
assessment for the
overall proposal
Back-out or remediation plan Full High-level plan for the
overall proposal
Impact assessment and evaluation – resources and Provisional Full business case ü
capacity, cost, benefits
Would the change require consequential amendment ü ü Plans affected
of IT service continuity management (ITSCM) plan,
capacity plan, security plan, test plan?
Change decision body ü ü
Decision and recommendations accompanying the ü ü
decision
Authorization signature (could be electronic) ü ü
Authorization date and time ü ü
Target baseline or release to incorporate change into ü
Template change plan(s) to be used ü
Scheduled implementation time (change window, ü Summary of expected
release window or date and time) implementation dates
Location/reference to release/implementation plan ü
Details of change implementer ü

Table 4.4 continued

Attribute on the change record RFC/change Change proposal Related assets/CIs
record (if appropriate)
Test results Summary and
pointer to details
Change implementation details (success/fail/ ü ü
remediation)
Actual implementation date and time ü
Evaluation report Summary and
pointer to details
Review date(s) ü
Review results (including cross-reference to new RFC Summary
where necessary)
Closure Summary
reference number of the triggering document is These should be returned to the initiator, together
retained to provide traceability. with brief details of the reason for the rejection,
and the log should record this fact. A right of
It is recommended that the logging of RFCs is done
appeal against rejection should exist, via normal
by means of an integrated service management
management channels, and should be incorporated
tool, capable of storing data on all assets and CIs
within the procedures.
and also, importantly, the relationships between
them. This will greatly assist when assessing the
likely impact of a change to one component of the
4.2.5.4 Assess and evaluate the change
system on all other components. All actions should Changes that are considered to be significant
be recorded, as they are carried out, within the should be subject to the formal change evaluation
change management log. If this is not possible for process, as described in section 4.6. There should
any reason, then they should be manually recorded be well-defined criteria to determine whether this
for inclusion at the next possible opportunity. formal change evaluation is needed, and this will
normally be documented in the relevant change
Procedures will specify the levels of access and model. A formal request for evaluation should be
who has access to the logging system. While any submitted when required to trigger the change
authorized personnel may create a change, or add evaluation process. If formal change evaluation is
reports of progress to it (though the support tool not required, then the change will be evaluated by
should keep change management aware of such the appropriate change authority as described in
actions) only change management staff will have this section.
permission to close a change.
The potential impact on the services of failed
4.2.5.3 Review RFC changes and their impact on service assets and
configurations need to be considered. Generic
As changes are logged, change management
questions (e.g. the ‘seven Rs’) provide a good
should ensure that all required information has
starting point.
been provided and filter out any requests that
seem to be:
■■ Totally impractical
■■ Repeats of earlier RFCs, accepted, rejected or
still under consideration
■■ Incomplete submissions, e.g. those that contain
inadequate descriptions or that do not have
necessary budgetary approval.

When conducting the impact and resource

The seven Rs of change management
assessment for RFCs, change management, the
The following questions must be answered CAB, ECAB or any other change authority should
for all changes. Without this information, the consider relevant items, including:
impact assessment cannot be completed, and
■■ The impact that the change will make on the
the balance of risk and benefit to the live service
customer’s business operation
will not be understood. This could result in
■■ Any associated change proposal
the change not delivering all the possible or
expected business benefits or even in it having ■■ The effect on the infrastructure and customer
a detrimental, unexpected effect on the live service (as defined in the service requirements
service. The questions are: baselines, service model, SLA) and on the
capacity and performance, reliability and
■■ Who raised the change?
resilience, contingency plans and security
■■ What is the reason for the change? ■■ The effect of the change on the organization’s
■■ What is the return required from the change? green IT or sustainability plans
■■ What are the risks involved in the change? ■■ The impact on other services that run on the
■■ What resources are required to deliver the same infrastructure (or on projects)
change? ■■ The impact on non-IT infrastructures within
■■ Who is responsible for the build, test and the organization – for example, security, office
implementation of the change? services, transport, customer help desks
■■ What is the relationship between this change ■■ The effect of not implementing the change
and other changes? ■■ The IT, business and other resources required to
implement the change, covering the likely costs,
Many organizations develop specific impact the number and availability of people required,
assessment forms to prompt the impact assessors the elapsed time, and any new infrastructure
about specific types of change. This can help with elements required
the learning process, particularly for new services ■■ The current change schedule and projected
or when implementing a formal impact assessment service outage (PSO)
step for the first time. ■■ Additional ongoing resources required if the
Responsibility for assessing each category of change is implemented
change should be assigned to a clearly identified ■■ Impact on the continuity plan, capacity plan,
change authority. It is not a best-practice issue security plan, regression test scripts and data
because organizations are so diverse in size, and test environment, service operation
structure and complexity that there is not a practices.
universal solution appropriate to all organizations.
It is, however, recommended that major change No change is without risk
is discussed at the outset with all stakeholders Simple changes may seem innocuous but can
in order to arrive at sensible boundaries of cause damage out of all apparent proportion
responsibility and to improve communications. to their complexity. There have been several
Change management is responsible for ensuring examples in recent years of high-profile and
that changes are evaluated and, if authorized, expensive business impacts caused by the
subsequently developed, tested, implemented and inclusion, exclusion or misplacing of a single dot
reviewed. Final responsibility for the IT service – in software code.
including changes to it – will rest with the service
owner. They control the funding available and will It is best practice to use a risk-based assessment
have been involved in the change process through during the evaluation of a change or set of
direct or delegated membership of a CAB or other changes, for example the risk for:
change authority.
■■ An individual change
■■ A set of changes implemented in the same
change window

■■ Impacting the timescales of authorized changes

Table 4.5 Example of a change impact and risk
on change and release schedules. categorization matrix
The focus should be on identifying the factors High impact High impact
that may disrupt the business, impede the Low probability High probability
delivery of service warranties or impact corporate Risk category: 2 Risk category: 1
objectives and policies. The same disciplines used Change
Low impact Low impact
impact
for corporate risk management or in project Low probability High probability
management can be adopted and adapted. Risk category: 4 Risk category: 3
Appendix B describes a number of different Probability
approaches that can be taken to assess and
manage risks. Each organization should have its The risk that should be considered is the risk to
own approach to risk management, but this will the business service. Changes require thorough
often be based on one or more of these best- assessment, widespread communication and
practice approaches. appropriate authorization by the person or persons
accountable for that business service. Assessing risk
Many organizations use a simple matrix like
from the business perspective can produce a correct
the one shown in Table 4.5 to categorize risk
course of action very different from that which
for changes, and from this the level of change
would have been chosen from an IT perspective,
assessment and authorization required.
especially within high-risk industries.
Example of change in a high-risk industry Change evaluation
In one volatile and competitive business Based on the impact and risk assessments, the
environment, the mobile telephone supply output of any formal evaluation, and the potential
business, customers asked IT if they were now benefits of the change, each of the assessors should
able to implement a much-needed change indicate whether they support authorization of
to the business software. The reply was that the change. All members of the change authority
it could not go forward to the next change should assess the change based on impact, urgency,
window because there was still a 30% risk risk, benefits and costs. Each will indicate whether
of failure. Business reaction was to insist on they support authorization and be prepared to
implementation because, in their eyes, a 70% argue their case for any alterations that they see as
chance of success, and the concomitant business necessary.
advantage, was without any hesitation the right
It is likely that each change or release will require
and smart move. Very few of their business
authorization from change management at
initiatives had such a high chance of success.
multiple points in its lifecycle, for example:
The point is that the risk and gamble of
■■ Before service design activity takes place
the business environment (selling mobile
■■ After service design is complete to authorize
telephones) had not been understood within IT,
check-in of the service design package and start
and inappropriate (IT) rules had been applied.
of release planning
The dominant risk is the business one and ■■ After release planning, to authorize release
that should have been sought, established, build and test
understood and applied by the service ■■ After release build and test to authorize check-
provider. Sensibly, of course, this might well in of the release package to the DML
be accompanied by documentation of the risk-
■■ Before each deployment, to authorize the
based decision, but nonetheless it is necessary
deployment
to understand the business perspective and act
■■ After deployment to authorize activating the
accordingly.
release in the target environment
■■ Before closure of the change to accept the final
configuration.

Not every change will require all of these Impact is based on the beneficial change to
authorizations. Each change model should include the business that will follow from a successful
information about when authorization is required. implementation of the change, or on the degree
of damage and cost to the business resulting
Before each authorization the change should be
from the error that the change will correct. The
evaluated to ensure that risks have been managed
impact may not be expressed in absolute terms
and that predicted and actual performance match
but may depend on the probability of an event
the business requirements. Some organizations
or circumstance; for example, a service may be
require a separate RFC for each of these steps;
acceptable at normal throughput levels but may
others use a documented workflow to manage all
deteriorate at high usage, which may be triggered
of these stages with a single change request.
by unpredictable external items.
Section 4.6 describes a formal change evaluation
The urgency of the change is based on how long
process which may be used for evaluation of
the implementation can afford to be delayed.
changes that have a significant impact, such as the
introduction of a new service. Table 4.6 gives examples of change priorities for
corrective changes (fixing identified errors that
Allocation of priorities are hurting the business) and for enhancements
Prioritization is used to establish the order in which (which will deliver additional benefits). Other
changes that have been put forward should be types of change exist, e.g. to enable continuation
considered. of existing benefits, but these two are used to
Every RFC will include the originator’s assessment illustrate the concept here.
of the impact and urgency of the change. Change planning and scheduling
The priority of a change is derived from the agreed Careful planning of changes will ensure that there
impact and urgency. Initial impact and urgency will is no ambiguity about what tasks are included in
be suggested by the change initiator but may well the change management process, what tasks are
be modified in the change authorization process. included in other processes and how processes
Risk assessment is of crucial importance at this interface to any suppliers or projects that are
stage. The change authority will need information providing a change or release.
on business consequences in order to assess
Many changes may be grouped into one release
effectively the risk of implementing or rejecting
and these may be designed, built, tested and
the change.
deployed together if the number of changes
involved can be handled by the business, the
Table 4.6 Change priority examples

Priority Corrective change Enhancement change
Immediate Putting life at risk Not appropriate for enhancement changes
Treat as emergency change Causing significant loss of revenue or the
(see section 4.2.5.11) inability to deliver important public services
Immediate action required
High Severely affecting some key users, or Meets legislative requirements
To be given highest priority for impacting on a large number of users Responds to short-term market
change building, testing and opportunities or public requirements
implementation resources Supports new business initiatives that will
increase company market position
Medium No severe impact, but rectification cannot Maintains business viability
be deferred until the next scheduled release Supports planned business initiatives
or upgrade
Low A change is justified and necessary but can Improvements in usability of a service
wait until the next scheduled release or Adds new facilities
upgrade

service provider and its customers. However, if change schedule, in addition to planned downtime
many independent changes are grouped into from other causes such as planned maintenance
a release, then this may create unnecessary and data backup. These documents are agreed
dependencies that are difficult to manage. If with the relevant customers within the business,
insufficient changes are grouped into a release with service level management, with the service
then the overhead of managing more releases desk and with availability management. The PSO
can be time-consuming and waste resources may be produced jointly with other processes,
(see section 4.4 on release and deployment including:
management).
■■ Service level management, which is responsible
It is strongly recommended that the change for negotiating and agreeing availability targets
management schedule should be prioritized based and planned outages
on business rather than IT needs, avoiding critical ■■ Business relationship management, which
business periods, but ensuring that required manages communication with senior
changes can be implemented in a timely manner. management of the customer
Pre-agreed and established change and release ■■ Availability management, which is responsible
windows help an organization to improve the for ensuring that the planned and unplanned
planning and throughput of changes and releases. downtime are within agreed targets
For example, a release window in a maintenance ■■ IT service continuity management, which may
period of one hour each week may be sufficient require planned downtime for testing and may
to install minor releases only. Major releases contribute to alternative arrangements for
may need to be scheduled with the business avoiding planned downtime.
and stakeholders at a predetermined time. This Inputs to the PSO should include:
approach is particularly relevant in high-change
environments where a release is a bottleneck or ■■ The change schedule
in high-availability services where access to the ■■ Release schedules
live systems to implement releases is restricted. In ■■ Planned and preventive maintenance schedules
many cases, the change or release may need to be ■■ Limits for planned downtime from availability
adjusted ‘on the fly’, and efficient use of change management
windows will require: ■■ Availability testing schedules
■■ A list of possible substitutes to make use of the ■■ ITSCM and business continuity management
unexpectedly vacant slot testing schedules
■■ Empowerment to make and implement release ■■ Information from the business relationship
decisions management and the service level management
■■ Internal metrics that monitor (and reflect and processes about the customer’s ability to accept
encourage best use of) change and release planned downtime.
windows Once agreed, the service provider should
■■ A clear understanding of any sequential communicate any planned additional downtime
dependencies and impact on users. to the user community at large, using the most
Whenever possible, changes should be designed, effective methods available.
built, tested and deployed in releases. The latest versions of these documents will be
Change management is accountable for available to stakeholders within the organization,
producing and distributing a change schedule preferably contained within a commonly available
and projected service outage (PSO). The change internet or intranet server as part of an SKMS.
schedule contains details of all the changes This can usefully be reinforced with a proactive
authorized for implementation and their proposed awareness programme where specific impact can
implementation dates. It also contains estimated be detected.
dates of longer-term major changes that have been
authorized as change proposals. The PSO contains
details of changes to agreed SLAs and service
availability because of the currently planned

Assessing remediation A degree of delegated authority may exist within

It is important to develop a remediation plan to an authorization level, e.g. delegating authority to
address a failing change or release long before a change manager according to preset parameters
implementation. Very often, remediation is the relating to:
last thing to be considered; risks may be assessed, ■■ Anticipated business risk
mitigation plans cast in stone. How to get back ■■ Financial implications
to the original start point is often ignored – or ■■ Scope of the change (e.g. internal effects only,
considered only when regression is the last within the finance service, specific outsourced
remaining option. services).
4.2.5.5 Authorize change build and test An example of a change authorization hierarchy
is shown in Figure 4.5. Each organization should
Formal authorization is obtained for each change
formally document its own change authorization
from a change authority that may be a role, person
hierarchy, which may be very different to the
or a group of people. The levels of authorization
example shown here. All change authorities should
for a particular type of change should be judged
be documented in the CMS.
by the type, size, risk and potential business impact
of the change, e.g. changes in a large enterprise If change assessment at level 2, 3 or 4 detects
that affect several distributed sites may need to be higher levels of risk, the authorization request
authorized by a higher-level change authority such is escalated to the appropriate higher level for
as a global CAB or the board of directors. the assessed level of risk. The use of delegated
authority from higher levels to local levels must
The culture of the organization dictates, to a
be accompanied by trust in the judgement, access
large extent, the manner in which changes are
to the appropriate information and supported
authorized. Hierarchical structures may well
by management. The level at which change is
impose many levels of change authorization, while
authorized should rest where accountability for
flatter structures could allow a more streamlined
accepting risk and remediation exist.
approach.
Communications, Communications,
decisions escalation for RFCs, Change Level of
and actions risks, issues authority risk/impact
High cost/risk
Business change – requires
Level 1 executive board decision from
executives
IT Change impacts
management board multiple services or
Level 2 organizational
or IT steering group
divisions
Change which
Level 3 CAB or only affects local
ECAB or service group
Level 4 Change manager Low-risk change
Level 5 Local authorization Standard change
Figure 4.5 Example of a change authorization model

Should disputes arise over change authorization 4.2.5.8 Coordinate change deployment
or rejection, there should be a right of appeal to The work of deploying a release is part of the
the higher level. Changes that have been rejected release and deployment management process. For
should be formally reviewed and closed. simple changes that are not part of a release, the
change management process will coordinate this
4.2.5.6 Coordinate change build and test activity.
If this change is part of a release, then the work of
Change management has responsibility for
packaging the change into a release and building
ensuring that changes are deployed as scheduled.
and testing this release is coordinated by the
This is largely a coordination role as the actual
release and deployment management process. For
deployment will be the responsibility of others (e.g.
simple changes that are not part of a release, the
people from the technical management function
change management process will coordinate this
will implement hardware changes). This role is
work.
shared with release and deployment management;
Authorized changes should be passed to the every service provider will identify the people and
relevant technical groups for building the changes. processes responsible for each activity based on the
It is best practice to do this in a formal way that size and nature of the change.
can be tracked, e.g. using work orders.
Remediation procedures should be prepared
Change management has an oversight role to and documented in advance for each authorized
ensure that all changes that can be are thoroughly change so that if errors occur during or after
tested. In all cases involving changes that have not implementation, these procedures can be quickly
been fully tested, special care needs to be taken activated with minimum impact on service
during implementation. quality. Authority and responsibility for invoking
remediation should be specifically mentioned in
Testing may continue in parallel with early live
change documentation.
usage of a service – looking at unusual, unexpected
or future situations so that further corrective action The deployment of changes should be scheduled
can be taken before any detected errors become when the least impact on live services is likely.
apparent in live operation. Support staff should be on hand to deal quickly
with any incidents that might arise.
4.2.5.7 Authorize change deployment
Some changes, especially those that are subject to
The design, build and testing of the change release and deployment management, may have
should be evaluated to ensure that risks have multiple deployment stages. Each deployment must
been managed and that predicted and actual be authorized by an appropriate change authority.
performance match the business requirements. This may require multiple RFCs to be submitted,
For significant changes, an interim evaluation but some organizations use a single RFC with
report will be received from the change multiple authorization stages. Either of these is an
evaluation process; for smaller changes the change acceptable approach, so long as every deployment
management process will carry out suitable checks. is authorized following a repeatable documented
The result of this evaluation should be passed to process.
the change authority for formal authorization to
deploy the change. 4.2.5.9 Review and close change record
If authorization is not given at this stage, the Before the change is closed, an evaluation must
change authority may request changes to the be carried out to ensure that actual performance
design or to the deployment schedule. This can is acceptable and that there are no unacceptable
lead to an iterative approach where the change risks. For significant changes an evaluation report
build and test and the authorization steps are will be received from the change evaluation
carried out multiple times until the change process; for smaller changes the change
authority is satisfied. management process will carry out suitable checks.
If the assessment suggests that actual performance
is creating unacceptable risks, the change authority
will be advised that further action is needed.

If the evaluation shows that the change is ■■ There are unexpected or undesirable side-effects
acceptable, then it should be presented as a to functionality, service levels, warranties, e.g.
completed change for stakeholder agreement availability, capacity, security, performance and
(including the closing of incidents, problems costs
or known errors that the change has resolved). ■■ The resources used to implement the change
Clearly, for major changes there will be more were as planned
customer and stakeholder input throughout the ■■ The deployment plan worked correctly (so
entire process. include comments from the implementers)
The evaluation should also include any incidents ■■ The change was implemented on time and to
arising as a result of the change (if they are known cost
at this stage). If the change is part of a service ■■ The remediation plan functioned correctly, if
managed by an external provider, details of any needed.
contractual service targets will be required (e.g.
Any problems and discrepancies should be fed back
‘There will be no priority 1 incidents during first
to CAB members (where they have been consulted
week after implementation.’)
or where a committee was convened), other
A change review, e.g. post-implementation review change authorities (if the change authority was not
(PIR), should be carried out to confirm that the a CAB), impact assessors, product authorities and
change has met its objectives, that the initiator release authorities, so as to improve the processes
and stakeholders are happy with the results and for the future.
that there have been no unexpected side-effects.
Where a change has not achieved its objectives,
Lessons learned should be fed back into future
change management (or the change authority)
changes. Small organizations may opt to use spot
should decide what follow-up action is required,
checking of changes rather than large-scale PIR; in
which could involve raising a revised RFC. If the
larger organizations, sampling will have a value
review is satisfactory or the original change is
when there are many similar changes taking place.
abandoned (e.g. the circumstances that required
There is a significantly different approach and the change are no longer current and the
profile between: requirement disappears), the change should be
formally closed in the logging system.
■■ The review of a service change – immediately
visible to the customer and scheduled for
discussion at the next service level management
4.2.5.10 Change advisory board
review meeting A change advisory board (CAB) is a body that
■■ An infrastructure change – concerned with how exists to support the authorization of changes and
IT delivers rather than what IT delivers, which to assist change management in the assessment,
will be (almost) invisible to the customer. prioritization and scheduling of changes. A CAB is
often the change authority for one or more change
Change management must review new or changed categories, but in some organizations the CAB just
services after a predefined period has elapsed. plays an advisory role. In a large organization there
This process will involve CAB members, since may be many different CABs with a global CAB
change reviews are a standard CAB agenda item. that is responsible for the most significant changes
If a formal change evaluation has taken place, and other CABs supporting different business units,
the evaluation report will be a major input to this geographies or technologies. It is important that
review. The purpose of such reviews is to establish each CAB has full visibility of all changes that could
whether: have an impact on the services and configuration
■■ The change has had the desired effect and met items within its control. For each CAB meeting,
its objectives members should be chosen who are capable of
■■ Users, customers and other stakeholders ensuring that all changes within the scope of the
are content with the results (or whether CAB are adequately assessed from both a business
shortcomings have been identified) and a technical viewpoint.

A CAB may be asked to consider and recommend When the need for emergency change arises, i.e.
the adoption or rejection of changes appropriate there may not be time to convene the full CAB, it
for higher-level authorization, and then is necessary to identify a smaller organization with
recommendations will be submitted to the authority to make emergency decisions. This body
appropriate change authority. is an emergency change advisory board (ECAB) –
see section 4.2.5.11. Change procedures should
To achieve this, the CAB needs to include people
specify how the composition of the CAB and ECAB
with a clear understanding across the whole
will be determined in each instance, based on the
range of stakeholder needs. Some of these may
criteria listed above and any other criteria that may
be permanent members of the CAB, others will
be appropriate to the business. This is intended
be invited to participate when they are needed
to ensure that the composition of the CAB will be
because of the particular changes that are being
flexible in order to represent business interests
discussed. The change manager will normally chair
properly when major changes are proposed. It
the CAB, and potential members include:
will also ensure that the composition of the ECAB
■■ Customer(s) will provide the ability, both from a business
■■ User manager(s) perspective and from a technical standpoint, to
■■ User group representative(s) make appropriate decisions in any conceivable
■■ Business relationship managers eventuality.
■■ Service owners A practical tip worth bearing in mind is that a CAB
■■ Applications developers/maintainers should have stated and agreed evaluation criteria.
■■ Specialists and/or technical consultants This will assist in the change assessment activities,
■■ Services and operations staff, e.g. service acting as a template or framework by which
desk, test management, IT service continuity members can assess each change.
management, information security
CAB meetings
management, capacity management
Many organizations run CABs electronically
■■ Facilities/office services staff (where changes
without frequent face-to-face meetings. There are
may affect moves/accommodation and vice
benefits and challenges from such an approach.
versa)
Much of the assessment and referral activities
■■ Contractors’ or third parties’ representatives,
can be handled electronically via support tools or
e.g. in outsourcing situations
email. In complex, high-risk or high-impact cases,
■■ Other parties as applicable to specific formal CAB meetings may be necessary.
circumstances (e.g. police if traffic disruptions
are likely, marketing if public products could be Electronic communications are more convenient
affected). time-wise for CAB members but also highly
inefficient when questions or concerns are raised
It is important to emphasize that a CAB: such that many discussions go back and forth. A
■■ Will be composed of different stakeholders face-to-face meeting is generally more efficient but
depending on the changes being considered poses scheduling and time conflicts among CAB
■■ May vary considerably in makeup, even across members and may also result in significant travel
the range of a single meeting and staff costs for widely dispersed organizations.
■■ Should involve suppliers when that would be Practical experience shows that regular meetings
useful, for example: combined with electronic automation is a viable
●● The external service provider if a significant approach for many organizations, enabling
part of the service is outsourced the face-to-face CAB meetings to focus on
●● The hardware service provider when understanding and evaluating difficult decisions.
considering major firmware upgrades It can be beneficial to schedule regular face-to-
■■ Should reflect both users’ and customers’ views face CAB meetings, especially when major projects
■■ Is likely to include the problem manager and are due to deliver releases. The meetings can then
service level manager and customer relations be used to provide a formal review and sign-off
staff for at least part of the time. of authorized changes, a review of outstanding

changes, and, of course, to discuss any impending a later meeting. A ‘walkthrough’ of major changes
major changes. Where meetings are appropriate, may be included at a CAB meeting before formal
they should have a standard agenda. submission of the RFC.
A standard CAB agenda should include: CAB members should come to meetings prepared
and empowered to express views and make
■■ Change proposals that have been received from
decisions on behalf of the area they represent
service portfolio management
in respect of the submitted RFCs, based on prior
■■ RFCs to be assessed by CAB members – in
assessment of the RFCs.
structured and priority order
■■ RFCs that have been assessed by CAB members The CAB should be informed of any emergency
■■ Change reviews changes or changes that have been implemented
as a workaround to incidents and should be given
■■ Outstanding changes and changes in progress
the opportunity to recommend follow-up action.
■■ Evaluation reports and interim evaluation
reports received from the change evaluation Note that a CAB may be an advisory body only,
process depending on how the organization has assigned
■■ Scheduling of changes and update of change change authority. If the CAB cannot agree to a
schedule and PSO recommendation, the final decision on whether
■■ Review of unauthorized changes detected to authorize changes, and commit to the expense
through service asset and configuration involved, is the responsibility of management
management, to understand underlying issues (normally the director of IT or the services director,
and take corrective action service owner or change manager as their
delegated representative).
■■ Failed changes, unauthorized, backed-out
changes, or changes applied without reference
to the CAB from incident management, problem
4.2.5.11 Emergency changes
management or change management Emergency changes are sometimes required
■■ Change management wins/accomplishments for and should be designed carefully and tested as
the period under discussion, i.e. a review of the much as possible before use, or the impact of
business benefits accrued by way of the change the emergency change may be greater than the
management process original incident. Details of emergency changes
may be documented retrospectively.
■■ The change management process, including
any amendments made to it during the period The number of emergency changes proposed
under discussion, as well as proposed changes should be kept to an absolute minimum, because
■■ Advance notice of RFCs expected for review at they are generally more disruptive and prone to
the next CAB. failure. All changes likely to be required should, in
general, be foreseen and planned, bearing in mind
CAB meetings represent a potentially large
the availability of resources to build and test the
overhead on the time of members. Therefore,
changes. Nevertheless, occasions will occur when
all change proposals and RFCs, together with
emergency changes are essential and so procedures
evaluation reports, the change schedule and PSO,
should be devised to deal with them quickly,
should be circulated in advance and flexibility
without sacrificing normal management controls.
allowed to CAB members on whether to attend in
person, to send a deputy or to send any comments. The emergency change procedure is reserved
Relevant papers should be circulated in advance to for changes intended to repair an error in an IT
allow CAB members (and others who are required service that is negatively impacting the business
by change management or CAB members) to to a high degree. Changes intended to introduce
conduct impact and resource assessments. immediately required business improvements are
handled as normal changes, assessed as having the
In some circumstances it will be desirable to
highest urgency. If a change is needed urgently
discuss RFCs at one CAB meeting for more detailed
(because of poor planning or sudden changes in
explanation or clarification (before CAB members
business requirements) this should be treated as a
take the papers away for consideration) in time for
normal change but given the highest priority.

Emergency change authorization development of more robust versions continues

Defined authorization levels will exist for an alongside the emergency change – then testing
emergency change, and the levels of delegated should be targeted towards:
authority must be clearly documented and ■■ Aspects of the service that will be used
understood. In an emergency situation it may not immediately (e.g. daily entry features, not end-
be possible to convene a full CAB meeting. Where of-month routines)
CAB authorization is required, this will be provided ■■ Elements that would cause most short-term
by the emergency CAB (ECAB). inconvenience.
Not all emergency changes will require the ECAB The business should be made aware of associated
involvement; many may be predictable both in risks and be responsible for ultimately accepting
occurrence and resolution and well-understood or rejecting the change based on the information
changes available with authority delegated, e.g. presented.
to service operation functions who will action,
document and report on the emergency change. Change management will give as much advance
For example, repair or replacement of server warning as possible to the service desk and other
hardware may require a small change in the server stakeholders, and arrange for adequate technical
revision or configuration that can be authorized by presence to be available, to support service
operational staff. operation.
It is important that any decision to authorize an If a change, once implemented, fails to rectify the
emergency change is documented to ensure that urgent outstanding error, there may need to be
formal agreement from appropriate management iterative attempts at fixes. Change management
has been received, and to provide proper records should take responsibility at this point to ensure
for audits of the process. that business needs remain the primary concern
and that each iteration is controlled in the manner
Emergency change building, testing and described in this section. Change management
implementation should ensure that ineffective changes are swiftly
Authorized changes are allocated to the relevant backed out.
technical group for building. Where timescales If too many attempts at an emergency change
demand it, change management, in collaboration are ineffective, the following questions should be
with the appropriate technical manager, ensures asked:
that sufficient staff and resources (e.g. machine
■■ Has the error been correctly identified, analysed
time) are available to do this work. Procedures
and agreements – approved and supported by and diagnosed?
management – must be in place to allow for this. ■■ Has the proposed resolution been adequately
Remediation must also be addressed. tested?
■■ Has the solution been correctly implemented?
The emergency change should be tested as fully
as possible. Completely untested changes should In such circumstances, it may be better to provide a
not be implemented if this is at all avoidable. If a partial service – with some user facilities withdrawn
change goes wrong, the cost is usually greater than – in order to allow the change to be thoroughly
that of adequate testing. Consideration should tested, or perhaps to suspend the service
be given to how much it would cost to test all temporarily and then implement the change.
changes fully against the cost of the change failing,
Emergency change documentation
factored by the anticipated likelihood of its failure.
It may not be possible to update all change
This means that the less a change is considered records at the time that urgent actions are being
likely to fail, the more reasonable it may be to completed (e.g. during overnight or weekend
reduce the degree of testing in an emergency. working). It is, however, essential that temporary
(Remember that there is still merit in testing even records are made during such periods, and that
after a change has gone live.) When only limited all records are completed retrospectively, at
testing is possible – and presuming that parallel

the earliest possible opportunity. An agreed new market spaces and serving new customers.
time for completion of these updates should be The following are examples of programmes and
documented when the change is authorized. initiatives that implement strategic changes:
IT operations management, technical management ■■ Legal/regulatory change
and application management staff may have ■■ Organizational change
delegated authority to circumvent certain types ■■ Policy and standards change
of incident (e.g. hardware failure) without prior ■■ Change after analysing business, customer and
authorization by change management. Such user activity patterns
circumventions should be limited to actions that
■■ Addition of new service to the market space
do not change the specification of service assets
■■ Updates to the service portfolio, customer
and that do not attempt to correct software
portfolio or customer agreement portfolio
errors. The preferred methods for circumventing
incidents caused by software errors should be to ■■ Change of sourcing model
revert to the previous trusted state or version, as ■■ Technology innovation.
relevant, rather than attempting an unplanned Change to one or more services
and potentially dangerous change. Change
Changes to the planned services (in the service
authorization is still a prerequisite.
portfolio) and changes to the services in the service
Effectively, the emergency change procedure will catalogue will trigger the change management
follow the normal change procedure except that: process. These include changes to:
■■ Authorization will be given by the ECAB rather ■■ Service catalogue
than waiting for a CAB meeting ■■ Service package
■■ Testing may be reduced, or in extreme cases ■■ Service definition and characteristics
forgone completely, if this is considered a ■■ Release package
necessary risk to deliver the change immediately
■■ Capacity and resource requirements
■■ Documentation, e.g. updating the change
■■ Service level requirements
record and configuration data, may be deferred,
■■ Warranties
typically until normal working hours.
■■ Utilities
4.2.6 Triggers, inputs, outputs and ■■ Cost of utilization
interfaces ■■ Service assets

■■ Acceptance criteria
4.2.6.1 Triggers ■■ Predicted quality of service
Requests for change can be triggered throughout ■■ Predicted performance
the service lifecycle and at the interfaces with ■■ Predicted value
other organizations, e.g. customers and suppliers. ■■ Organizational design
There will also be other stakeholders such as ■■ Stakeholder and communications plans
partners who may be involved with the change
■■ Physical change in the environment, e.g.
management processes.
building
Typical examples of types of change that trigger ■■ Measurement system
the change management process are described ■■ Plans, e.g. capacity, ITSCM, change, transition,
below. test, and release and deployment plans
Strategic changes ■■ Decommission/retire services
Service strategies require changes to be ■■ Procedures, manuals, service desk scripts.
implemented to achieve specific objectives while Operational change
minimizing costs and risks. There are no cost-
It is important to know the distinction between
free and risk-free strategic plans or initiatives.
different types of requests that will be initiated by
There are always costs and risks associated with
users. These types of request will depend on the
decisions such as introducing new services, entering
nature of the organization and services and may
include requests such as password reset, access

request or request to move an IT asset. These types ■■ Authorized change plans

of change will often be managed as standard ■■ Change decisions and actions
changes by the request fulfilment process. ■■ Change documents and records
Service operation functions will also implement ■■ Change management reports.
corrective and preventative changes via the normal
change procedure and the standard change 4.2.6.4 Interfaces
procedure. These should be managed through Change management must work with transition
change management, for example restarting an planning and support to ensure that there is a
application, which may impact a shared service. coordinated overall approach to managing service
transitions.
Changes to deliver continual improvement
When CSI determines that an improvement to a In order to be able to define clear boundaries,
service is warranted, an RFC should be submitted dependencies and rules, change management and
to change management. Changes such as changes release and deployment management should be
to processes can have an effect on service provision integrated with processes used for organizational
and may also affect other CSI initiatives. programmes or projects, with supplier
management and also with suppliers’ processes
Some strategy and service changes will be initiated and procedures. There will be occasions when a
by CSI. proposed change will potentially have a wider
impact on other parts of the organization (e.g.
4.2.6.2 Inputs facilities or business operations), or vice versa, and
Changes may be submitted as an RFC, often with the change management process must interface
an associated change proposal that provides inputs appropriately with other processes involved.
from the service strategy stage of the service
The change management process must be tightly
lifecycle. The inputs include:
integrated with change evaluation. There should
■■ Policy and strategy for change and release be clear agreement on which types of change will
■■ Request for change be subject to formal change evaluation, and the
■■ Change proposal time required for this evaluation must be included
■■ Plans – change, transition, release, test, in the overall planning for the change. Change
evaluation and remediation management provides the trigger for change
■■ Current change schedule and PSO evaluation, and the evaluation report must be
delivered to change management in time for the
■■ Evaluation reports and interim evaluation
CAB (or other change authority) to use it to assist
reports
in their decision-making.
■■ Current assets or configuration items, e.g.
baseline, service package, release package Integration with business change processes
■■ As-planned configuration baseline Where appropriate, change management should
■■ Test results, test report and evaluation report. be involved with business programme and business
project management teams to ensure that
4.2.6.3 Outputs change issues, aims, impacts and developments
Outputs from the process will be: are exchanged and cascaded throughout the
organization where applicable. This means that
■■ Rejected and cancelled RFCs
changes to any business or project deliverables
■■ Authorized changes that do not impact services or service components
■■ Authorized change proposals may be subject to business or project change
■■ Change to the services, service or infrastructure management procedures rather than the IT
resulting from authorized changes change management procedures. However, care
■■ New, changed or disposed configuration items, must be taken to ensure that changes to service
e.g. baseline, service package, release package configuration baselines and releases do follow
■■ Revised change schedule the change management process. The change
■■ Revised PSO management team will, however, be expected

to liaise closely with projects to ensure smooth smooth delivery of service. Effort also should
implementation and consistency within the be put into finding out how well the partners
changing management environments. themselves manage change, and care must be
taken to choose partner and sourcing relationships
The service portfolio management process will
accordingly.
submit change proposals to change management
before chartering new or changed services, in order Sourcing and partnering arrangements should
to ensure that potential conflicts for resources or clearly define the level of autonomy a partner
other issues are identified. may have in effecting change within their service
domain without reference to the overall service
Programme and project management provider.
Programme and project management (usually
based on PRINCE2 or PMBOK) must work in It is important to ensure that service providers
partnership to align all the processes and people (whether outsourced or insourced) provide the
involved in service change initiatives. Close change management personnel and processes that
alignment between change management and match the needs of the business and customers.
programme and project management is essential Some organizations in outsourcing situations
to ensure that the change schedule is effective refer RFCs to their suppliers for estimates prior to
and that all changes are well managed. Change authorization of changes. For further information,
management representatives may attend relevant refer to guidance in ITIL Service Design on supplier
project or programme meetings, especially at the management.
initiation stages of projects or programmes, to
identify potential risks to IT services and other 4.2.6.5 Interfaces within service
configuration items. management
All service management processes may require
For outsourced services, a key component is how
change management, for example to implement
deeply change processes and tools are embedded
process improvements. Many service management
into the supplier organization (or vice versa) and
processes will also be involved in the impact
where the release veto takes place. If the supplier
assessment and implementation of service changes,
has responsibility for the availability of the
as discussed below.
operational service, conflicts can arise.
Organizational and stakeholder change Service asset and configuration management

management The configuration management system provides
reliable, quick and easy access to accurate
Organizational and stakeholder change
configuration information to enable stakeholders
management is discussed in Chapter 5.
and staff to assess the impact of proposed changes
In some organizations there is a separate function and to track change work flow. This information
that manages organizational changes; in others enables the correct CI versions to be released to the
this aspect of change management may be carried appropriate party or into the correct environment.
out within the IT organization. It is, however, As changes are implemented, the configuration
always essential that organizational aspects of management information is updated.
change management are properly considered
The CMS may also identify related CIs that will be
and that the change management process has
affected by the change, but not included in the
appropriate interfaces with the people carrying out
original request, or similar CIs that would benefit
this work.
from similar changes.
Sourcing and partnering An overview of how the change management
Sourcing and partnering relationships cover and service asset and configuration management
internal and external vendors and suppliers who processes work together for an individual change is
are providing a new or existing service to the shown in Figure 4.6.
organization. Effective change management
practices and principles must be put into place to
manage these relationships effectively to ensure

Change management
Raise and Authorize/ Coordinate

Assess Review Close
record change reject change
change change change
request change implementation*
Release and deploy

new/changed CIs
Capture Check
Reports Identify Update release and Audit
environment records
and audits affected items records items
baselines updated
Configuration management system
* Includes build and test where applicable
Figure 4.6 Interfaces between change management and service asset and configuration management
Problem management Capacity management and demand management

Problem management is another key process, Capacity management and demand management
as changes are often required to implement are critical aspects of change management. Poorly
workarounds and to fix known errors. Problem managed demand is a source of cost and risk for
management is one of the major sources of RFCs service providers because there is always a level
and is also often a major contributor to CAB of uncertainty associated with the demand for
discussion. services. Capacity management has an important
role in assessing proposed changes – not only the
IT service continuity management individual changes but the total impact of changes
IT service continuity management has many on service capacity. Changes arising from capacity
procedures and plans, which should be updated management, including those set out in the
via change management to ensure that they are capacity plan, will be initiated as RFCs through the
accurate and up to date, and that stakeholders are change process.
aware of changes.
Service portfolio management
Every change should be assessed for its impact on
The service portfolio management process
IT service continuity arrangements. For a standard
prioritizes and charters strategic changes, and
change this will be done at the time the change
submits change proposals for these. Change
model is authorized; for normal and emergency
proposals will be a significant input to long-term
changes the assessment will be done as part of
planning for the change schedule, and will also be
change assessment.
a key input to help change management review
Information security management and authorize related RFCs.
Information security management interfaces with Some change requests will require analysis by the
change management, since changes required service portfolio management process, potentially
by security will be implemented through the adding to the service pipeline. Each organization
change management process and security will should define criteria for deciding whether these
be a key contributor to CAB discussion on many requests are managed as part of the change
services. Every significant change will be assessed management process or are passed to service
for its potential impact on information security portfolio management.
management.

4.2.7 Information management used to identify opportunities for improvement,

All change requests must be associated with which should be logged in the CSI register for
services and other CIs. This means that either they evaluation and possible implementation.
must be included within the CMS or a mechanism ■■ CSF Responding to business and IT requests
must be provided to enable cross referencing and for change that will align the services with the
searching changes related to CIs. It is very common business needs while maximizing value
for a single tool to be used for managing incidents, ●● KPI Increase in the percentage of
problems and changes, as well as the CMS, and this changes that meet the customer’s agreed
kind of tool can help to improve the efficiency of requirements, e.g. quality/cost/time
the processes. ●● KPI The benefits of change (expressed as
It is very important to be able to correlate changes ‘value of improvements made’ + ‘negative
with incidents and to review the history of impacts prevented or terminated’) exceed
changes to any CI as part of incident or problem the costs of change
management. This requires access to historical ●● KPI Reduction in the backlog of change
change information, which should be made requests
available for searches. ●● KPI Average time to implement meets SLA
Change management must have access to the CMS targets, based on urgency/priority/change
and to information and documents within the type
SKMS in order to plan and manage changes, to ●● KPI Increase in accuracy of predictions
identify stakeholders in any change, and to predict for time, quality, cost, risk, resource and
the potential impact of changes. commercial impact
●● KPI Increase in scores in survey of
4.2.8 Critical success factors and key stakeholder satisfaction for the change
performance indicators management process
■■ CSF Optimizing overall business risk
All KPIs should be SMART – Specific, Measurable,
Achievable, Relevant and Time-bound. While it is ●● KPI Reduction in the number of disruptions
relatively easy to count the number of incidents to services, defects and re-work caused by
that eventually generate changes, it is infinitely inaccurate specification, poor or incomplete
more valuable to look at the underlying cause impact assessment
of such changes and to identify trends. It is ●● KPI Reduction in the percentage of changes
better still to be able to measure the impact of that are categorized as emergency changes
changes and to demonstrate reduced disruption ●● KPI Increase in change success rate
over time because of the introduction of change (percentage of changes deemed successful at
management, and to measure the speed and review/number of changes authorized)
effectiveness with which the service provider ●● KPI Reduction in the number of changes
responds to identified business needs. where remediation is invoked
Measures taken should be linked to business goals ●● KPI Reduction in the number of failed
wherever practical – and to cost, service availability changes

and reliability. Any predictions should be compared ●● KPI Reduction in the number of
with actual measurements. unauthorized changes identified
●● KPI Reduction in the number of incidents
The following list includes some sample CSFs for
attributed to changes
change management. Each organization should
■■ CSF Ensuring that all changes to configuration
identify appropriate CSFs based on its objectives
items are well managed and recorded in the
for the process. Each sample CSF is followed by
configuration management system
a small number of typical KPIs that support the
CSF. These KPIs should not be adopted without ●● KPI Reduction in the number and
careful consideration. Each organization should percentage of changes with incomplete

develop KPIs that are appropriate for its level of change specifications
maturity, its CSFs and its particular circumstances.
Achievement against KPIs should be monitored and

●● KPI Reduction in the number and ■■ Lack of commitment to the change

percentage of changes with incomplete management process by the business, and lack
impact assessments of business sponsorship
●● KPI Reduction in number of audit ■■ Lack of commitment to the change
compliance issues for the change management process by IT management, and
management process lack of IT management sponsorship
●● KPI Reduction in number and percentage ■■ Lack of commitment to the change
of discrepancies found by service asset and management process by IT staff
configuration management verification and ■■ Implementation of changes without the use of
audit. change management
■■ Change assessment being reduced to box
4.2.9 Challenges and risks ticking, without real consideration of the risks,
costs and benefits
4.2.9.1 Challenges
■■ Introduction of delays to change
The major challenge for change management implementation without adding sufficient value
is ensuring that every change is recorded and ■■ Insufficient time being allowed for proper
managed. Regular communication of the scope assessment of changes, and pressure from
and value of change management will help to projects or the business to expedite decisions
ensure that IT staff understand the scope and
■■ Insufficient time allowed for implementation of
value of change management and do not try
changes, and attempts to fit too many changes
to circumvent the process. One very important
into a change window
way to help manage this challenge is to ensure
■■ Insufficient resources for assessment, planning
that there is active and visible sponsorship for
and implementation of the number of changes
change management from executives and senior
required by the business
management.
■■ Lack of clarity on how change management
To gain support from customers, users and IT staff, should interact with other service management
the change management process must be seen to processes, such as release and deployment
facilitate change, rather than to introduce delays. management or service asset and configuration
A change management process that is regarded as management
bureaucratic and time-wasting will not be valued. ■■ Lack of clarity on how change management
The challenge for change management is to make should interact with project management or
sure that it is seen to add value by helping changes service design activities
happen faster and with higher success rates.
■■ Excessively bureaucratic change management
In some organizations change management has processes that introduce excessive delay to
been implemented as an operational change required changes.
authorization process. It can be a challenge to
migrate to a true change management process
4.3 Service asset and configuration
that becomes involved early enough in the service
lifecycle, includes assessment of benefits and costs, management
and helps to plan and manage changes. This section addresses the process of service asset
In large organizations there can be a significant and configuration management (SACM) within
challenge to agree and document the many levels IT service management. No organization can be
of change authority that are needed to manage fully efficient or effective unless it manages its
change effectively and to communicate effectively assets well, particularly those assets that are vital
between these change authorities. to the running of the customer’s or organization’s
business.
4.2.9.2 Risks
4.3.1 Purpose and objectives
Risks to change management include:
The purpose of the SACM process is to ensure
that the assets required to deliver services are
properly controlled, and that accurate and reliable

information about those assets is available when The scope of SACM includes management of the
and where it is needed. This information includes complete lifecycle of every CI.
details of how the assets have been configured and
the relationships between assets.
ensures that CIs are identified, baselined and
The objectives of SACM are to: maintained and that changes to them are
controlled. It also ensures that releases into
■■ Ensure that assets under the control of the IT
controlled environments and operational use
organization are identified, controlled and
are done on the basis of formal authorization.
properly cared for throughout their lifecycle.
It provides a configuration model of the services
■■ Identify, control, record, report, audit and
and service assets by recording the relationships
verify services and other configuration items
between configuration items. SACM may cover
(CIs), including versions, baselines, constituent
non-IT assets, work products used to develop the
components, their attributes and relationships.
services and CIs required to support the service that
■■ Account for, manage and protect the integrity would not be classified as assets by other parts of
of CIs through the service lifecycle by working the business.
with change management to ensure that only
authorized components are used and only The scope includes interfaces to internal and
authorized changes are made. external service providers where there are assets
■■ Ensure the integrity of CIs and configurations and configuration items that need to be controlled,
required to control the services by establishing e.g. shared assets.
and maintaining an accurate and complete Most organizations have a process that tracks
configuration management system (CMS). and reports the value and ownership of fixed
■■ Maintain accurate configuration information assets throughout their lifecycle. This process is
on the historical, planned and current state of usually called fixed asset management or financial
services and other CIs. asset management. Fixed asset management
■■ Support efficient and effective service maintains an asset register, which records financial
management processes by providing accurate information about all of the organization’s fixed
configuration information to enable people to assets. Fixed asset management is not usually
make decisions at the right time – for example, under the control of the same business unit as the
to authorize changes and releases, or to resolve IT services, but the SACM process must provide
incidents and problems. proper care for the fixed assets under the control
of IT, and there must be well-defined interfaces
4.3.2 Scope between SACM and fixed asset management. Data
Service assets that need to be managed in order from the asset register may be integrated with the
to deliver services are known as configuration configuration management system to provide a
items (CIs). Other service assets may be required more complete view of the CIs. See section 4.3.4.4
to deliver the service, but if they cannot for more information about asset management.
be individually managed then they are not
configuration items. Every CI is a service asset, 4.3.3 Value to business
but many service assets are not CIs. For example, Optimizing the performance of service assets
a server will be both a CI and an asset; the and configurations improves the overall service
knowledge used by an experienced service desk performance and optimizes the costs and risks
person to manage incidents is an important asset caused by poorly managed assets, e.g. service
but is not a CI. Also, information that is stored on outages, fines, correct licence fees and failed
the server but is not under the control of change audits.
management may be a very valuable asset, but it SACM provides visibility of accurate representations
is not a configuration item. It is important to note of a service, release or environment that enables:
that many virtual assets, such as a virtual servers
or networks, may be CIs and require the same ■■ IT staff to understand the configuration and
management control as physical assets. relationships of services and the configuration
items that provide them
■■ Better forecasting and planning of changes

■■ Successful assessment, planning and delivery of be based on the organization’s business drivers,
changes and releases contractual and service management requirements
■■ Resolution of incidents and problems within the and on compliance to applicable laws, regulations
service level targets and standards.
■■ Delivery of service levels and warranties Asset policies may be applicable for specific asset
■■ Better adherence to standards, legal types or services, e.g. desktop systems.
and regulatory obligations (fewer non-
There are significant cost and resource implications
conformances)
in implementing SACM, and therefore strategic
■■ More business opportunities as the service
decisions need to be made about the priorities
provider is able to demonstrate control of assets
to be addressed. Many IT service providers focus
and services
initially on the basic IT assets (hardware and
■■ Traceability of changes from requirements software) and the services and assets that are
■■ The ability to identify the costs of a service business critical or covered by legal and regulatory
■■ Reduced cost and time to discover configuration compliance, e.g. Sarbanes-Oxley, software
information when it is needed licensing.
■■ Proper stewardship of fixed assets that are
under the control of the service provider.
principles
4.3.4 Policies, principles and basic The main policy sets out the framework and key
concepts principles against which assets and configurations
are developed and maintained. Typical principles
In distributed environments and shared services,
include:
individual service components exist within many
different services and configuration structures. For ■■ Ensuring that service asset and configuration
example, a person may use a desktop computer management operations costs and resources are
that is on the network for a building but may be commensurate with the potential risks to the
running a central financial system that is linked services.
to a database on the other side of the world. A ■■ The need to deliver governance requirements,
change to the network or the financial system may such as software asset management, Sarbanes-
have an impact on this person and the business Oxley, ISO/IEC 20000, ISO/IEC 38500 or COBIT.
process they support. In web-based services, there ■■ The need to deliver the capability, resources
may be data feeds and interfaces from and to and warranties as defined by the service level
services owned by other organizations. Changes agreements and contracts.
to these interfaces need to be managed and it is ■■ The requirement for available, reliable and cost-
important to identify interfaces such as data feeds effective services.
and the owner/custodian of these. Changes to
■■ The requirement for clear economic and
any interface items need to be managed through
performance criteria for interventions that
change management. Similarly, many services may
reduce costs or optimize service delivery. For
run on different virtual servers that are all hosted
example, specifying the age at which PCs should
on the same physical computer. Changes to the
be replaced based on cost of maintenance of
physical server could impact all of these services.
older models.
■■ The application of whole-life cost appraisal
4.3.4.1 Service asset and configuration
methods.
management policies
■■ The transformation from ‘find and fix’ reactive
The first step is to develop and maintain the SACM maintenance to ‘predict and prevent’ proactive
policies that set the objectives, scope, principles management.
and critical success factors (CSFs) for whatever is ■■ The requirement to maintain adequate
to be achieved by the process. These policies are configuration information for internal and
often considered with the change management external stakeholders.
and release and deployment management policies
■■ The level of control and requirements for
because they are closely related. The policies will
traceability and auditability.

■■ The application of continual improvement owned and managed by the SACM process, but
methods to optimize the service levels, assets others will be owned and managed by other
and configurations. processes or people.
■■ Provision of accurate configuration information More information about the content and
for other business and service management relationships between configuration records, CIs,
processes. the CMS and the SKMS may be found throughout
■■ Integration of service asset and configuration this publication, especially in sections 4.3.4.3 and
management with other processes. 4.7.
■■ Migration to a common CMS architecture.
■■ Level of automation to reduce errors and costs.
The configuration model
4.3.4.2 Basic concepts delivers a model of the services, assets and the
infrastructure by recording the relationships
Service assets, configuration items, configuration between configuration items as shown in Figure
records, the CMS and the SKMS 4.7. This enables other processes to access valuable
It is important to distinguish between service information, for example:
assets, configuration items and configuration
■■ To assess the impact and cause of incidents and
records, as these concepts are often confused:
problems
■■ A service asset is any resource or capability that ■■ To assess the impact of proposed changes
could contribute to the delivery of a service. ■■ To plan and design new or changed services
Examples of service assets include a virtual ■■ To plan technology refresh and software
server, a physical server, a software licence, upgrades
a piece of information stored in a service
■■ To plan releases and migrate service assets to
management system, or some knowledge in the
different locations and service centres
head of a senior manager.
■■ To optimize asset utilization and costs, e.g.
■■ A configuration item (CI) is a service asset that
consolidate data centres, reduce variations and
needs to be managed in order to deliver an
re-use assets.
IT service. All CIs are service assets, but many
service assets are not configuration items. The real power of service asset and configuration
Examples of configuration items are a server or management’s logical model of the services and
a software licence. Every CI must be under the infrastructure is that it is the model – a single
control of change management. common representation used by all parts of IT
■■ A configuration record is a set of attributes and service management, and beyond, such as HR,
relationships about a CI. Configuration records finance, supplier and customers.
are stored in a configuration management
database (CMDB) and managed with a ‘Danish clock’
configuration management system (CMS). It is There is a traditional Danish proverb that runs
important to note that CIs are not stored in a ‘When you have a clock in your house, you know
CMDB; configuration records describe CIs that the time – once you get two clocks you are no
are stored in the CMDB. longer certain.’ SACM delivers that one clock
■■ The service knowledge management system for all processes and so glues them together,
(SKMS) is a set of tools and databases that are delivers consistency and helps to achieve
used to manage knowledge, information and common purpose (from Hans Dithmar).
data. Many configuration items are available
in the form of knowledge or information, and The configuration items and related configuration
these are typically stored in the SKMS – for information can be at varying levels of detail, e.g.
example, a service level agreement, a report an overview of all the services or a detailed level to
template or a definitive media library. The view the specification for a service component.
SACM process is not responsible for managing
the SKMS. Some items in the SKMS will be

Service Service
Customer
options portfolio
Banking
Contract core service
Serviced by
E-banking Supported by Hosted Application Uses Technical

support Application hosting infrastructure
service service service
Business Data Web Network Network

Availability Usability Messaging Authentication
logic services services topology service
Figure 4.7 Example of a logical configuration model
Service asset and configuration management ■■ Service lifecycle CIs such as the business case,
should be applied at a more detailed level service management plans, service lifecycle
where the service provider requires firm control, plans, service design package, release and
traceability and tight coupling of configuration change plans and test plans. They provide a
information through the service lifecycle. A general picture of the service provider’s services, how
rule for the level of detail required is that you these services will be delivered, what benefits
should not include attributes or relationships unless are expected, at what cost and when they will
these create more value than it costs to maintain be realized.
them. ■■ Service CIs:
●● Service capability assets: management,
Configuration items
organization, processes, knowledge, people
A configuration item (CI) is a service asset that
●● Service resource assets: financial capital,
needs to be managed in order to deliver an IT
systems, applications, information, data,
service. Configuration items may vary widely
infrastructure and facilities, financial capital,
in complexity, size and type, ranging from an
people
entire service or system including all hardware,
●● Service model
software, documentation and support staff to
a single software module or a minor hardware ●● Service package
component. Configuration items may be grouped ●● Release package

and managed together: e.g. a set of components ●● Service acceptance criteria.
may be grouped into a release. Configuration ■■ Organization CIs – some documentation will
items should be selected using established selection define the characteristics of a CI whereas other
criteria, grouped, classified and identified in such documentation will be a CI in its own right and
a way that they are manageable and traceable need to be controlled, e.g. the organization’s
throughout the service lifecycle. business strategy or other policies that are
There will be a variety of CIs; the following internal to the organization but independent
categories may help to identify them. These are of the service provider. Regulatory or statutory
just examples – every organization will decide requirements also form external products that
whether each of these is a configuration item or need to be tracked, as do products shared
simply an attribute of a configuration item (or even among more than one group.
something that they don’t need to manage):

■■ Internal CIs comprising those delivered by Figure 4.8 shows the relationship between
individual projects, including tangible (data configuration records, stored in the CMS, and the
centre) and intangible assets such as software actual CIs, which may be stored in the SKMS or may
that are required to deliver and maintain the be physical assets outside the SKMS.
service and infrastructure.
Changes to every configuration item must be
■■ External CIs such as external customer authorized by change management and all updates
requirements and agreements, releases from must include updates to the relevant configuration
suppliers or sub-contractors and external records. In some organizations, authority to modify
services. CIs within the SKMS is assigned to configuration
■■ Interface CIs that are required to deliver the librarians, who are also responsible for modifying
end-to-end service across a service provider the configuration records in the CMS. In other
interface (SPI), for example an escalation organizations there is a separation of duties
document that specifies how incidents will be to ensure that no one person can update both
transferred between two service providers. the asset in the SKMS and the corresponding
configuration record in the CMS.
4.3.4.3 Configuration management system
To manage large and complex IT services and The CMS is also used a for wide range of purposes:
infrastructures, service asset and configuration for example, asset data held in the CMS may be
management requires the use of a supporting made available to external fixed asset management
system known as the configuration management systems to perform financial reporting outside
system (CMS). Discussion of tools for supporting a service asset and configuration management.
CMS can be found in Chapter 7. The CMS maintains the relationships between all
The CMS holds all the information about CIs within service components and may also include records
the designated scope. Some of these items will for related incidents, problems, known errors,
have related specifications or files that contain changes and releases. The CMS may also link
the contents of the item (e.g. software, document to corporate data about employees, suppliers,
or photograph), and these should be stored in locations and business units, customers and users;
the SKMS. For example, a service CI will include alternatively, the CMS may hold copies of this
the details such as supplier, cost, purchase date information, depending on the capabilities of the
and renewal date for licences and maintenance tools in use.
contracts; related documentation such as SLAs and
underpinning contracts will be in the SKMS.
SKMS
The CMS is Some CIs (such as

part of the SLAs or release
SKMS CMS plans) are in the
SKMS
Configuration Each configuration

records are record points to and
stored in describes a CI
CMDBs in
the CMS
Other CIs (such as

users and servers)
are outside the
SKMS
Figure 4.8 Example of relationships between the CMS and SKMS

At the data level, the CMS may include data from

Example of multiple configuration management
configuration records stored in several physical
databases
CMDBs, which come together at the information
integration layer to form an integrated CMDB. The In the commonly encountered partially
integrated CMDB may also incorporate information outsourced service provider, some elements of
from external data sources such as an HR database service management will be outsourced while
or financial database. Since this data is normally others will remain in house, and different
owned by other business units, agreements will be elements may be outsourced to different
needed about what data is to be made available external suppliers. For example, the network and
and how this will be accessed and maintained. This hardware support may be handled by supplier
arrangement should be formally documented in an A, environment and facilities management by
OLA. The CMS will provide access to this external supplier B, and multiple applications suppliers
data wherever possible rather than duplicating and incident management handled internally.
data. The service desk will access information to assist
them from the CMS, but that system will derive
Records used to support service management
its data input from discrete repositories – each
processes, such as incident records, problem
one a CMDB – owned and maintained by the
records, change records, release records and
three parties, but working together to supply
known error records, must be associated with
a single consistent information set. Ideally,
the specific configuration items that they relate
the service desk will have access to a single
to. Many implementations include these records
federated CMDB.
within the CMS; however, it is also acceptable
practice for them to be included in the SKMS but
outside the CMS. What is important is that there Configuration information evolves as the service
are appropriate links in place to enable all of these is developed through the service lifecycle. Often
records to be located and searched as required to there are separate mechanisms for managing
support the delivery of services. different service lifecycle stages as well as different
means of managing different applications and
Figure 4.9 shows the architectural layers of the platforms.
CMS. These layers are described in more detail in
section 4.7. The presentation layer of the CMS will The CMS typically contains configuration data and
contain views and dashboards that are required information that combines into an integrated set
by people who need access to configuration of views for different stakeholders through the
information, for example: service lifecycle. It therefore needs to be based
on appropriate web, reporting and database
■■ Change and release view Used by personnel technologies that provide flexible and powerful
responsible for change management and visualization and mapping tools, interrogation
release and deployment management and reporting facilities. The CMS is part of an
■■ Technical configuration view Used to support SKMS that includes data, information integration,
the needs of personnel in technical and knowledge processing and presentation layers,
application management functions as shown in Figure 4.9. In practice the service
■■ Service desk view For use by the service desk, provider may use different tools for different
for example when logging and managing purposes, and the CMS tool will often provide
incidents and service requests information integration, knowledge processing
■■ Configuration lifecycle view Used by service and presentation independently of other tools
asset and configuration management personnel used for the SKMS.
who are responsible for managing the lifecycle
Many organizations are already using some
of configuration items.
elements of SACM, often maintaining records in
documents, spreadsheets or local databases, and
some of these may be used in the overall CMS.
Automated processes to load and update the
CMDBs should be developed where possible so

03 - ITIL V3 2011 Service Transition ST-1-109

Uploaded by

Copyright:

Available Formats

03 - ITIL V3 2011 Service Transition ST-1-109

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

03 - ITIL V3 2011 Service Transition ST-1-109

Uploaded by

Copyright:

Available Formats

Service providers must implement changes to support the

changing needs of the business. They must ensure that these

ITIL Service Transition provides guidance on managing

ITIL® Service Transition

7188 ITIL ST AN Cover V0_3.indd 1-3 11/07/2011 11:05

7267 ITIL-ServiceTranslation v0_1.indd 1 11/07/2011 15:41

Mail, Telephone, Fax & E-mail

TSO@Blackwell and other Accredited Agents

Customers can also order publications from:

© Crown Copyright 2011

Applications to reuse, reproduce or republish material in this publication should be sent to

The Swirl logo™ is a trade mark of the Cabinet Office

First edition Crown Copyright 2007

First published 2011

Printed in the United Kingdom for The Stationery Office.

7267 ITIL-ServiceTranslation v0_1.indd 2 11/07/2011 15:41

List of figures v 4.6 Change evaluation 175

1.1 Overview 3 5.3 Stakeholder management 215

1.2 Context 6 6 Organizing for service transition 219

1.4 Why is ITIL so successful? 10 6.3 Organizational context for

4.2 Change management 60 8.3 Implementing service transition in

7267 ITIL-ServiceTranslation v0_1.indd 3 11/07/2011 15:41

9.3 Risks 256 C.12 Skills Framework for the

Appendix B: Risk assessment

Appendix C: Related guidance 279

7267 ITIL-ServiceTranslation v0_1.indd 4 11/07/2011 15:41

Figure 4.7 Example of a logical Figure 4.24 Example of service testing

7267 ITIL-ServiceTranslation v0_1.indd 5 11/07/2011 15:41

Figure 4.25 Example of a set of Figure 6.2 Example of service transition

7267 ITIL-ServiceTranslation v0_1.indd 6 11/07/2011 15:41

7267 ITIL-ServiceTranslation v0_1.indd 7 11/07/2011 15:41

7267 ITIL-ServiceTranslation v0_1.indd 8 11/07/2011 15:41

7267 ITIL-ServiceTranslation v0_1.indd 9 11/07/2011 15:41

7267 ITIL-ServiceTranslation v0_1.indd 10 11/07/2011 15:41

2011 edition Wider team

Authors and mentors Change advisory board

7267 ITIL-ServiceTranslation v0_1.indd 11 11/07/2011 15:41

Club; Helen Sussex, Logica; J.R. Tietsort,

Chief architect and authors

7267 ITIL-ServiceTranslation v0_1.indd 12 11/07/2011 15:41

7267 ITIL-ServiceTranslation v0_1.indd 15 11/07/2011 15:41

■■ Implementing a rigorous framework for ■■ Back in from a supplier, e.g. insourcing

7267 ITIL-ServiceTranslation v0_1.indd 16 11/07/2011 15:41

1.1.2.1 Processes within service transition ■■ Service testing and validation

Continual service improvement

Change management (4.2)

Auth Auth Auth Auth Auth Auth Auth Auth

Service asset and configuration management (4.3)

Transition planning and support (4.1)

Managing people through service transitions (5)

Change evaluation (4.6)

Service Service Release Release build Release Review and Service

Service validation and testing (4.5)

Knowledge management (4.7)

Focus of activity ITIL process in service Change authorization

Figure 1.2 The scope of service transition

7267 ITIL-ServiceTranslation v0_1.indd 17 11/07/2011 15:41

1.1.3 Usage 1.1.5 Target audience

7267 ITIL-ServiceTranslation v0_1.indd 18 11/07/2011 15:41

7267 ITIL-ServiceTranslation v0_1.indd 19 11/07/2011 15:41

List of figures v 4.6 Change evaluation 175

1.1 Overview 3 5.3 Stakeholder management 215

1.2 Context 6 6 Organizing for service transition 219

1.4 Why is ITIL so successful? 10 6.3 Organizational context for

4.2 Change management 60 8.3 Implementing service transition in

9.3 Risks 256 C.12 Skills Framework for the

Appendix C: Related guidance 279

2 Service management as a practice

2.3 Governance and management