[ITIL v3 Foundation Notes] The Service Transition phase of the ITIL

v3 Foundation Certification exam is covered here with an introduction of

Service Transition and the Change Management Process. Service
Transition is concerned with the delivery of a new / changed service into
operation.

Purpose, Objectives and Scope of

Service Transition

All stakeholders need to be considered in the transition

planning to ensure customers satisfaction of the service

Provide a consistent and managed approach to reduce risks

and enhance efficiency and effectiveness of service
introduction

Purpose of Service Transition

The purpose of Service Transition is to ensure that the

agreed services are now delivered from service design to
service operation effectively (deployment)

Objectives of Service Transition

Plan and manage changes to services (either introducing

new or retiring existing services) and to deploy the new
services successfully to support business objectives while
ensuring the integrity of all existing services

Ensure the service can be operated and supported according

to the service design

Manage the risks associated

Set the expectations of the business with testing on the

performance

Provide knowledge and info of the service / service assets to

relevant people to ensure smooth operation

Scope of Service Transition

Provide guidance on the development and improvement of

the required capabilities

Provide guidance on service transition between internal and

external service providers including relationship between
strategy, design and transition (also considers service
retirement and transfer of services between service providers)

Provide guidance on management of transition for the

coordination of all activities involved (among different
projects)

Communicate with all parties concerned

Processes of Service Transition

Knowledge Management

Transition Planning and Support

Change Management

Service Asset and Configuration Management (SACM)

Release and Deployment Management

Service Validation and Testing (*not covered in ITIL v3 Foundation

exam)

Evaluation (*not covered in ITIL v3 Foundation exam)

Change Management Process

[definition] A change is the addition, modification or removal of

anything that could have an effect on IT services

Change requests are submitted as Requests for

Change (RFC), the degree of formality of the RFC depends on
the extent of the change

Change Records are to be used to capture the details of

the lifecycle of the changes making references to the
configuration items affected (stored in configuration
management system), one change record for each individual
change

No change should be approved without a back-out or

remediation plan (to restore the initial configuration)

[definition] Remediations are actions taken to recover

after a failed change or release. Remediation may include

back-out, invocation of service continuity plans, or other actions
designed to enable the business process to continue.

Purpose: to control the lifecycle of all changes,

enabling beneficial changes to be made with minimum

disruption to IT services.

uncontrolled changes might cause a surge in incidents

to consider all aspects (intended and unintended) a

change may bring
Objectives

to keep abreast of and support the changes in the

business environment (by reducing incidents, disruption
and rework)

to ensure that changes are recorded and evaluated,

and that authorized changes are prioritized, planned,
tested, implemented, documented and reviewed in a
controlled manner as recorded in the configuration
management system (CMS)

to optimize risk (balance between risk of doing and risk

of not doing)

to control the assets of the infrastructure

Scope

cover everything from configuration items (servers,

infrastructure, documentation, services and configuration),
management systems and tools, processes, metrics,
solution and architecture from design strategy to continual
service management excluding organization and business
changes, and minor operational changes

manage all changes in a controlled manner on all levels

(strategic, tactical and operational) by making reference to

the service portfolio
Change management is not responsible for the

coordination of processes for the successful

implementation of projects; this will be handled through
the planning and transition support process.
Output

change schedule (CS, also an input)

projected change outage (PSO)

remediation plan
ITIL recommends the use of a change model or change

process model to handle changes in a consistent manner:

Steps for handling the change

The order in which the steps should be carried out,

including any dependencies

Responsibilities throughout the process

Timescales

Escalation procedures
Types of Changes

Standard Change a change to a service or other

configuration item, which has a preauthorizedapproach to

its execution, well understood for risks, follow
a standard procedure with a predefined trigger

e.g. installation of a new computer

RFC not required, logged as service requests

enhance the effectiveness of change

management

records need to be reviewed regularly

Emergency Change a change in response to or in

order to prevent a business-critical error

need to have a clear definition of the authority

levels associated with emergency changes (e.g.

emergency change advisory board (ECAB)

may not have enough time for extensive testing

documentation may need to be updated

afterwards
risk of failure is high

Normal Change

Typical flow (all information stored in SKMS):

Create the request for change (RFC) ->

trigger the creation of the change record

Review the RFC sufficient information,

appropriate budget, is it practical by the change

manager
Assess and evaluate the change (after

approval of RFC) need Change Proposal?

Who raised the change?

What is the reason for the change?

What is the return required from the

change?
What are the risks involved in the

change?

What resources are required to deliver

the change?

Who is responsible for the build, test,

and implementation of the change?

What is the relationship between this

change and other changes?

Authorize the change by a change

authority usually CAB, update the change
schedule and projected service outage (PSO) with a
remediation plan

Plan updates build and test

Coordinate change implementation to

ensure changes are deployed as scheduled
Review and close the change pass the

acceptance criteria: success -> close the change

record; failure -> remediation plan or workaround

Change Proposal: submitted for major change

that involves significant cost, risk or organizational
impact, before the new/change service is chartered,
normally created by Service Portfolio management.
Change proposals include a high-level description of the
change, a detailed business case (including risk
assessment) and schedule for design and
implementation. When authorized, the service is
chartered.

RFC should specify the details of the change,

including the risks, benefits, costs, and proposed
schedule for implementation, depending on guidelines.

Change Advisory Board (CAB)

determine whether normal changes should be

authorized

include people from business and technical sides,

stakeholders to reflect a balanced view

Change management process is an trigger for change

evaluation process

Change management involve the assessment of a large

number of other processes (e.g. capacity, IT service continuity,
security, etc.)

Transition Planning and Support Process

a key process for Service Transition

covers the interface between service transition, project

management and business engagement

needs to work with

Technical Management Function: provides

resources for managing the infrastructure

Application Management Function: provides

resources for managing applications
Purpose: to plan and coordinate the transition

activities across different processes at a high level with

coordination of resources and capabilities (availability and
schedule)
Objectives

plan, coordinate and monitor resources and various

parties for the transition and associated activities within
the budget and timeframe

establish new requirements for management

information systems and tools and other management
systems

ensure repeatable processes (a framework) are

adopted during transition of different services

identify and manage risks according to organization

risk management framework
Scope

plan future transition needs

maintenance of policies and standards

provide transition guidance and plan for achieving

business goals

coordinate and prioritize resources for multiple

transition needs

review and improvement current process and plan for

future transition needs

Not including the detailed plans for building, testing and

deployment

Service Asset and Configuration

Management Process
control over the assets under IT management in an efficient

and effective manner

Purpose of SACM: to ensure the control of IT assets for

services by having an accurate record of theassets and their

relationships and configuration
Objectives

ensure proper management of IT assets through

identification, recording (with historic data) and control

(verification)
manage the integrity of configuration items (CIs) which

are controlled by change management

an item of infrastructure that is managed to

deliver a service
all configuration items are service assets, but not

vice versa (e.g. knowledge of technician is asset but not

configuration item)
create a configuration management system

holds all information about CIs and their

relationship
may make use of automatic tools to capture the

data

four layers: Presentation, knowledge processing,

information integration, data

Scope

all configuration items (CIs)

identify and apply control to elements of the

infrastructure that are to be managed as service assets

baseline, maintain and control through change

management all CIs with a configuration management

system (CMS) in configuration management databases
(CMDBs)
any interfaces with internal and external configuration

items (e.g. shared assets), e.g. license management

Activities

Management and planning

There is no standard template for determining the optimum

approach for SACM. The management team and
Configuration Management should decide what level of
Configuration Management is required for the selected
service or project that is delivering changes and how this
level will be achieved. This is documented in a
Configuration Management Plan. Often there will be a
Configuration Management Plan for a project, service or
groups of services, e.g. network services. These plans
define the specific Configuration Management activities
within the context of the overarching Service Asset and
Configuration Management strategy.
Configuration identification

Define and document criteria for selecting

configuration items and the components that compose

them

Select the configuration items and the

components that compose them based on documented
criteria

Assign unique identifiers to configuration items

Specify the relevant attributes of each

configuration item

Specify when each configuration item is placed

under Configuration Management

Identify the owner responsible for each

configuration item.
Configuration control

Configuration control ensures that there are adequate

control mechanisms over CIs while maintaining a record of
changes to CIs, versions, location and
custodianship/ownership. Without control of the physical or
electronic assets and components, the configuration data
and information there will be a mismatch with the physical
world. No CI should be added, modified, replaced or
removed without an appropriate controlling documentation
or procedure being followed.
Status accounting and reporting

Each asset or CI will have one or more discrete states

through which it can progress. The significance of each
state should be defined in terms of what use can be made
of the asset or CI in that state. There will typically be a
range of states relevant to the individual asset or CIs. A
simple example of a lifecycle is: development or
draft approved withdrawn. The way CIs move from
one state to another should be defined, for example, an
application release may be registered, accepted, installed
or withdrawn.
Verification and audit

The activities include a series of reviews or audits to:

Ensure there is conformity between the

documented baselines (for example, agreements,
interface control documents) and the actual business
environment to which they refer

Verify the physical existence of CIs in the

organization or in the DML and spares stores, the
functional and operational characteristics of CIs and to

check that the records in the CMS match the physical

infrastructure

Check that release and configuration

documentation is present before making a release

Definition of Terms

Service Asset any resource or capability that could

contribute to the delivery of a service

Configuration Item a service asset that needs to be

managed in order to deliver an IT service

Configuration Record a set of attributes and

relationships about a CI in configuration management
databases (CMDBs)

Configuration Model a model of the services,

assets, and infrastructure of each configuration item
and their relationships to each other for planning and
decision use
One of the most crucial factors is to define the level of

detail required to manage configuration items successfully

Categories of CI suggested by ITIL include:

Service Lifecycle CIs documents that provide

information on the plans and requirements for the services,
including costs and benefits

Service CIs service capability and service resource

assets; service model, package, etc.

Organization CIs documentation relating to

organizational policies or standards

Internal CIs internal assets such as software or

hardware

External CIs external customer requirements and

agreements

Interface CIs documentation relating to end-to-end

service provision across multiple service providers

Definitive Media Library (DML)

consists of a number of software libraries or file

storage areas (physical or electronic), which are managed
and kept separate from the live, test, or development
storage areas

stores master copies of versions that have passed

quality assurance checks

requires policies for retention, security, backup,

archive, etc.
Definitive Spares

spare components and assemblies that are maintained

at the same level as the comparative systems within the
controlled test or live environment
Configuration Baseline

the configuration of a service, product or infrastructure

that has been formally reviewed and agreed on
Snapshot

the current state of a configuration item or an

environment

snapshots are recorded in the CMS and remain as fixed

historical records

Knowledge Management Process

control over the assets IT manages in an efficient and

effective manner
Purpose: to ensure timely retrieval of relevant ideas,

perspectives, experience, and information to the correct

audience for informed decision making (facilitate reuse of
knowledge)
Objectives

improve decision making by providing correct and

timely information

reuse of knowledge for efficiency and effectiveness

maintain a service knowledge management

system (SMKS)
[definition] SKMS is a set of tools and

databases that is used to manage knowledge,

information and data. The SKMS includes the
configuration management system, as well as other
databases and information systems. The SKMS includes
tools for collecting, storing, managing, updating,
analyzing and presenting all the knowledge, information
and data that an IT service provider will need to
manage the full lifecycle of IT services.

manage the data and information

includes sources such as the service portfolio,

definitive media library, information in SLAs, OLAs and
contracts, budgets, cost models, and service
improvement plans, error information, etc.

gather, store, analyze and share knowledge

Scope

the management of data and information across the

service management processes

share of information with customers and users

NOT including the detailed collection and maintenance

(in Service Asset and Configuration Management)
Data-Information-Knowledge-Wisdom Structure

(DIKW)

data raw facts, e.g. date and time of incidents

information data in context, e.g. average time

between incidents

knowledge apply experience (the tacit

experiences, ideas, insights, values and judgements of
individuals), context, and understanding to the information

analysis, e.g. average time between incidents increased by

10% when a new service is introduced

wisdom apply the knowledge with common-sense

judgement / contextual awareness for improvement or
better results, e.g. the increase in average time between
incidents is due to poor documentation

Release and Deployment Management

Process
Purpose: the build, test, and deployment of the release is

successfully delivered with minimal adverse impact to

business and other services

to ensure the process is planned, scheduled and

controlled
Objectives

to define and agree on deployment plan

with stakeholders

create and test release packages

maintain the integrity of the release packages (store

in definitive media library)

ensure the new / changed services meets utility and

warranty needs

capture lessons learned

ensure knowledge transfer to users and IT staff

(support and operation)
Scope

the processes, systems, and functions required to

deliver a release into production

build, ensure testing and deploy the release to the

utility and warranty requirements

handover of service to operation teams

manage all CIs and things related to the release

Release Policy

should be defined for the release of each service /

group of service

specify the types of releases that need to be controlled

e.g. major release, minor release, emergency release

outlines the roles and responsibilities, use of definitive

media library, customer expectation, acceptance criteria,
authorization requirements, criteria for handover, etc.
Four Phases of Release and Deployment

Release and Deployment Planning begins

with planning a release and ends with change
authorization to create the release

Release Build and Test the release package is built,

tested, and checked into the DML, end with authorization to
include the package in DML

Deployment deploy the package from DML and

handover of service to operation, early life support might
be needed for faster response and knowledge transfer

Review and Close capture lessons learned and

address issues
Big bang versus Phased

Big-bang option the new or changed service is

deployed to all user areas in one operation. This will often
be used when introducing an Application change and
consistency of service across the organization is considered
important.

Phased approach the service is deployed to a part of

the user base initially, and then this operation is repeated
for subsequent parts of the user base via a scheduled roll
out plan. This will be the case in many scenarios such as in
Retail Organizations for new services being introduced into
the stores environment in manageable phases.

Push and Pull

A push approach is used where the service component

is deployed from the centre and pushed out to the target
locations. In terms of service deployment, delivering
updated service components to all users either in bigbang or phased form constitutes push, since the new or
changed service is delivered into the users environment at
a time not of their choosing.

A pull approach is used for software releases where the

software is made available in a central location but users
are free to pull the software down to their own location at a
time of their choosing or when a user workstation restarts.
The use of pull updating a release over the internet has
made this concept significantly more pervasive. A good
example is virus signature updates, which are typically
pulled down to update PCs and Servers when it best suits
the customer, however at times of extreme virus risk this
may be.
Automation versus Manual

Whether by automation or other means, the

mechanisms to release and deploy the service components
should be established in the release design phase and
tested in the build and test stages of the new or changed
service. Automation will help to ensure repeatability and
consistency. The time required to provide a well designed
and efficient automated mechanism may not always be
available or viable. If a manual mechanism is used it is
important to monitor and measure the impact of many
repeated manual activities as they are likely to be
inefficient and error prone. Too many manual activities will
slow down the release team and create resource/capacity
issues that affect the service levels.

Other Processes of the Service Transition

Service Validation and Testing Process: to ensure the

service will perform as specified and be designed through
service strategy and service design through testing and
validation with customers

Change Evaluation Process: to check the predicted

performance against the actual performance achieved by the
new or changed service