ITIL Release and Deployment

Management
"Release and Deployment Management aims to build, test and deliver the
capability to provide the services specified by Service Design and that will
accomplish the stakeholders' requirements and deliver the intended objectives"
Release and Deployment management includes all the processes, systems and
functions necessary to package, build, tests and deploy Release components
into the live production environment. This process is also responsible for
training end users and operating staff as well as circulating documentation on
the newly deployed Release or the Services it supports. By educating the end
users, Release Management aims to protect the live environment.
Going into more details, the aim of Release and Deployment Management is to
build, test and deliver capabilities or skills according to the specifications
provided by Service Design, so that the Service requirements demanded by the
stakeholders are realized.
To minimize the incidence of Changes in Service Assets and IT infrastructure
and to provide users with stable Services, a single Release contains multiple
Changes.
Organizations must closely coordinate the issues of new Releases with
customers, users and IT operating staff. To avoid any possible resistance to the
new Releases, organizations must bring in experts to manage the different
types of expectations from all stakeholders. All stakeholders involved, including
organizational staff must agree on defined acceptance criteria for the Releases.
The CAB should give its authorization for the release of Services into the
production environment only after the Release has been tested and concluded
successfully.
Release Management is not to be confused with Change Management. This is
because Release Management focuses on implementing Changes while Change
Management focuses on Change control and monitoring.

4.1 Purpose, goals and objectives

Purpose
The purpose of Release and Deployment Management includes:

Outline and agree to Release and Deployment plans with customers and
stakeholders

Make sure that each Release Package consists of a set of related and
compatible assets and Service components

Make sure that the integrity of a Release Package and its components is
maintained throughout transition activities and recorded accurately in the
CMS

Make sure that it is possible to track, install, test, verify and/or uninstall
or back out all Release and Deployment packages as appropriate
Manage organizational and stakeholder change during Release and
Deployment activities
Document and manage deviations, Risks and issues related to a new or
changed Service and take the necessary corrective action
Transfer knowledge to enable customers and users to use the Service
Transfer skills and knowledge to operations and support staff to help
them deliver, support and maintain the Service effectively and efficiently,
according to required Warranties and Services levels

Goals

Deploy Releases into production

Establish the effective use of Services to deliver value to the customer
Be able to hand over the Services to Service Operations

Objectives

Make sure of the presence of clear and comprehensive Release and

Deployment plans that enable customer and business change projects to
align their activities with these plans

Ensure that a Release Package can be built, installed, tested and

deployed efficiently to a deployment group or target environment
successfully and on schedule

Ensure that a new or changed Service and its enabling systems,

technology and organization are capable of delivering the agreed Service
requirements, that is Utility, Warranty and Service levels

Ensure that there is minimal unpredicted Impact on production Services,

operations and the support organization

Ensure that customers, users and Service Management staff are satisfied
with the practices and outputs of Service Transition, for example, user
documentation and training
Scope of Release and Deployment Management
Release and Deployment Management includes all the processes, systems and
functions necessary to package, build, test and deploy Release components
into the live production environment. This process is also responsible for
training end users and operating staff, as well as circulating documentation on
the newly deployed Release or the Services it supports. By educating the end
users, Release Management aims to protect the live environment.
In addition, Release and Deployment Management sets up all Services
specified in the SDP before handing the Services over to Service Operations.
Release and Deployment Management Outputs

An approved Service Release Package and its associated deployment

packages

An updated Service package or Service bundle that defines the end-toend Service(s) offered to customers

An updated Service Portfolio and Service Catalogue

An updated contract portfolio

Documentation for a transferred or decommissioned Service

Additional outputs to Continual Sercice Improvement (CSI) consist of

suggestions and observations on the Changes required to improve processes,
especially within Service Design and Service Transition and possibly within
Service Strategy and in business processes and relationship management.

4.3 Business Value of the process

With a well-planned and implemented Release and Deployment process, the
Service costs of an organization can decrease significantly. On the other hand,
a poorly designed Release or Deployment process can force IT personnel to
spend significant amounts of time on troubleshooting Problems and managing
complexity. It can also result in crippling the environment and degrading live
Services.
Release and Deployment Management ensures the implementation of a
structured process, leading to a number of benefits as listed below:

Deliver Change faster, at optimal cost and minimal Risk

Enable the use of the new or changed Service by customers and users in
a manner that supports business goals

Contribute to meet audit requirements for traceability through Service

Transition

Improve consistency in the implementation approach across the

business change, Service teams, suppliers and customers
Uses of the Release Management Process

Critical or large hardware rollouts, especially when they depend on a

related software Change in business systems. A hardware rollout should
not be made, for example, for each PC that needs to be installed

Major software rollouts, especially initial instances of new applications

along with accompanying software distribution and support procedures for
subsequent use, if required

Bundling or batching related sets of Changes into manageable units

4.4 Release unit and release design options and

considerations
4.4.1 Release Policy
A Release policy is an input to Release and Deployment Management from
Service Design and is discussed in Service Transition Planning and Support, a
process that is not covered in Release, Control and Validation (RCV).
The Service Transition process of Transition Planning and Support provides
overall strategic governance and guidance as input to the Release and
Deployment Management, Evaluation and Service Validation and Testing
processes. A key output if this process is the development of a Release policy
The Release policy should be defined for one or more Services. It includes:

Unique ID, numbering and naming conventions and descriptions of

Release types
Roles and responsibilities at each stage
Frequency of Releases
Approach for accepting and grouping changes into a Release
Means to automate the build, installation and distribution processes
Baseline rules for capture and verification
Exit criteria, entry criteria and authority for acceptance of a Release at
each Release stage and environment
Criteria and authorization to exit ELS and operations handover

4.4.2 Release Types

The various types of Releases should be defined because this helps set
customer and stakeholder expectations about planned Releases.
Guidance for packaging Releases as Major, Minor or Emergency is defined in
the Release policy. Release and Deployment Management will then consider
each Release to determine its correct classification based on the guidance in
the Release policy.
Service

Release definition

Naming/numbering Frequency/occurrenc
e

Windows
Server
image

Minor/Major/Emergency WS2012R2_vx_xx

Monthly/quarterly

4.4.3 Release Units

A Release Unit is that portion of a Service or IT infrastructure that is normally
released together, according to the organization's Release policy.
Typically, a Release Unit is a collection of infrastructure items that perform a
useful function when packaged together.
While the size of the unit may vary, depending on the type(s) or item(s) of
Service Assets or Service components, such as software and hardware, you
must aim to decide the most appropriate Release Unit level for each Service
Asset and component. For example, to make sure that an application has been
thoroughly tested, your organization might decide that the Release Unit for
business-critical applications is the complete application.
Factors for release Units
Some factors to take into account when deciding the appropriate level for
Release Units are:

The amount of Change necessary for releasing and deploying a Release

Unit

The amount of resources and time required to build, test, distribute and
implement a Release Unit

The complexity of interfaces between the proposed unit and the rest of
the Services and IT infrastructure

Release
window
Last
Monday of
the Month

Availability of storage capacity in the build, test, distribution and live

environments

4.4.4 Release Approaches

Design options
Characteristics
Big bang

Deploy the new or changed Service to all users

in one go

Phased

Deploy the new or changed Service to all users

in a phased manner, usually deploying the
device to only part of the user base initially

Push

Deploy the Service component from the center

and push it to the target locations

Pull

Deploy the Service component to a central

location from where users are free to pull the
software down to their own location

Big Bang
This approach aims to deploy a new or changed Service to all users in one go,
that is, to launch the Release all at once. This is often used to introduce an
application Change across the organization to ensure Service consistency.
Phased
A diametrically opposite approach is the phased approach. In this, the device is
initially deployed to part of the user base and the operation is then repeated
for subsequent parts of the user base via a scheduled rollout plan.
Push
As the name "push" suggests, the Service component is deployed from the
center and pushed out to the target locations.
Pull
Pull relies on the user to download the software (pull cannot be used for the big
bang approach) because some users may never download the software, an
organization may choose to eventually push a Release to get all users to the
same level; this reduces support complexity and cost.
Service Deployment
As far as Service Deployment is concerned, delivering updated Service
components to all users, either in big-bang or phased form, constitutes a push.
This is because the new Service is delivered to users at a time not chosen by
them, that is, the Service is pushed into the user's environment.
Planning and Defining Service Release and Deployment
There are two ways to do this:

Use an automated mechanism for Release and Deployment

Perform the process manually

Pros and Cons of Release Mechanisms

Mechanisms

Pros

Cons

Automated mechanism

More error-free

Needs more time to develop.

May not always be a viable optio

Manual

Needs less development time

Needs more monitoring.

Needs more Impact measureme
Process may be slow and error-p

Automation
This helps ensure repeatability and consistency:

In automated Configuration Baseline procedures, which save time and

reduce errors in capturing status

In automatic comparisons of the actual "live" configuration with the

expected configuration or CMS
Manual
There is a need to monitor and measure the Impact of many repeated manual
activities because they are likely to be inefficient and error prone. Too many
manual activities will slow down the Release team and create resource or
capacity issues that affect Service levels.
4.4.5 Release Packages
Release Package
A Release Package may be made up of one Release Unit or a structured set of
Release Units. As far as possible, Release Packages must be designed in such a
way that some Release Units can be removed if they cause issues during
testing.
Baseline
A baseline is:

A benchmark used as a reference point

The trusted state of an item

Each Release consists of a Release Package, which is baselined.
Baselining a Release and placing it under the control of the Configuration
Management process ensures that there is consistency in all further Changes to
the Release. It also helps monitor improvements in the Release.
The Release Package must be built in a standard, controlled and reproducible
way in line with the solution design defined in the SDP. You may need to
rebuild this package further in the Release and Deployment process.
4.4.7 Release Models
Define:

Release structure

Release exit and entry criteria

Controlled environments

Roles and responsibilities for each CI at each Release level

Release Promotion and Configuration Baselines model

Template Release and Deployment schedules
Supporting systems, tools and procedures for documenting and tracking
all Release and Deployment activities
Handover activities and responsibilities for executing handover and
acceptance for each stage of Release and Deployment

Service Design selects the most suitable Release and Deployment model for a
Release. This model includes the approach, mechanisms, processes,
procedures and resources to build and deploy the Release on time and within
budget.

4.5 Release and Deployment Planning Approach

Service
Design

Plan and
prepare
release

Build
Service
Plan and
and test testing and prepare for
pilots
deployment

Early Life
Support
Release and Deployment Management Activities
1 Plan
a Release and Deployment plans
b Pass/fail criteria
c Build and test prior to production
d Planning pilots
e Planning Release packaging and building
f Deployment planning
g Logistics and delivery planning
h Financial and commercial planning
2 Prepare for build, test and deployment
3 Build and test
a Release and build documentation
b Acquiring and testing input Cis and components
c Release packaging
d Building and managing test environments
e Service testing and pilots
f Service rehearsals
g Plan - preparing for the day
h Do - delivering the rehearsal
i Check - documenting the day
j Act - taking action following the rehearsal
k Pilots
2 Plan and prepare for deployment
a Assessing

Transfer,
deploy,
retire

Review and
close Service
Transition

Se
Op

2
3
4
5

b Developing plans and preparing for deployment

Perform transfer, deployment and retirement
a Transferring financial assets
b Transferring/transitioning the business and organization
c Deploying processes and materials
d Deploying the Service Management capability
e Transferring the Service
f Deploying the Service
g Decommissioning and Service retirement
h Removing redundant assets
Verify deployment
Perform Early Life Support
Review and close a deployment
Review and close Service Transition

4.5.1 Plan and prepare for Release

Plan and Prepare Release Activities:

Create Release and Deployment plans

o
Is authorized through Change Management
o
Includes the Release scope, its content, Risk assessment and
profile; identifies organizations and stakeholders, Change approvers,
Release team, delivery and deployment strategy, resources and
amount of Change that can be absorbed by the organization as part
of the Release

Create Release criteria, that is, pass/fail criteria

Plan pass/fail situations
Pass example: all tests are completed successfully; the evaluation
report and Request for Change (RFC) for build and test are signed off
Fail example: Service Operation does not have the capabilities to
offer Service attributes

Build and test a pilot prior to production

Establishes the approach to building, testing and maintaining the
controlled environments prior to production
Leverages the Service V-Model

Plan pilots
o
Pilots are useful for testing the Service with a small part of the
user base before rolling it out to the entire community

Plan the Release package and build

o
Verifying the entry/exit criteria
o
Managing stakeholder change and communication
o
Training people and transferring knowledge
o
Establishing the Services and Service Assets
o
Agreeing to schedules

Deploy the plan

o
What needs to be deployed, who and where are the users, and are
there location dependencies?
Release Criteria

Service Transition is responsible for planning pass/fail criteria for a Release.

Each Release must have a defined set of minimum pass/fail criteria.
Defining these criteria falls under the scope of the Service Transition process.
The criteria must at least be defined for each authorization point through the
Release and Deployment stage.
To set expectations correctly, it is important to publish pass/fail criteria to
relevant stakeholders well in advance.
Examples of Pass Situations

All tests are completed successfully

The evaluation report and the RFC for build and test are signed off
Examples of Fail Situations

The build test does not allow the process to move to the next stage
because of insufficient resources

Service Operation does not support particular Service attributes

Service Design does not conform to Service Operation standards for

technologies, protocols, regulations and so on

The Service cannot be delivered within the design constraints'

boundaries

SAC are not met

Mandatory documents for going to the next stage are not signed off

Both the SKMS and the CMS are not updated. This could be because of a
manually intensive process

Incidents, Problems and Risks are higher than expected

Advantages of Running a Pilot

A pilot is useful to:

o
Test the Service with a small part of the user base before rolling it
out to the entire Service community
o
Establish the viability of most, if not all, aspects of the Service
o
Determine the scope of any pilot used in testing very carefully
o
Very large scope will not allow you to deliver the Service at the
required speed and flexibility
Having a group of end users try the Service before its full deployment has
immense benefits. The level of pilot testing you want to perform depends on
the size and scope of your migration project. For larger projects, a formal,
carefully planned pilot is essential. For a project of any size, it is good to have
selected end users to test the system before full deployment.
You must determine the scope of any pilot used in testing. If the scope is too
large, you will not be able to deliver the Service at the required speed and with
the required flexibility. In fact, a pilot with a large scope will effectively turn out
to be a first rollout.
Release Pilots
Some of the factors to consider are

The speed and cost of running multiple pilots

The diverse nature of the organization

Trial options
The inclusion or exclusion of specific user groups

In some situations, it makes sense to run a range of pilots on the Service or

Change. This could be different pilots for different geographical locations,
different user groups and so on. Multiple pilots provide the Service Desk with
data on benefits and pass/fail situations for a range of users. The Service Desk
can analyze this data and roll out the best solution.
Types of Release Environments
The types of environments, both logical and physical, required during Release
and Deployment include:

Build environment
Iis used to compile or assemble the Release Package or Service
Assets

Unit test environment

o
Is used to verify the functionality, performance, recovery and
usability characteristics of an individual Service component, such as
an online procedure

Assembly test environment

o
Is used to verify the functionality, performance, recovery and
usability of an assembly or individual Service component

Integration environment
o
Is used to build and integrate Service components

System test environment

o
Is used to test all aspects of the integrated Service architecture,
including application and technical infrastructure. Substantial user
acceptance testing is also executed in this environment

Service Release test environment

o
Is used to install, build and test a Release Package in a controlled
environment. This type of environment is often combined with the
system test environment

Service Operations readiness test environment

o
Is used to test the capabilities of the Service and Service Unit
before promotion into live. This type of environment may include a
Service Management acceptance test, some operational acceptance
tests and user acceptance tests of end-to-end Service

Business simulation environments

Service Management simulation environments

Training environments
o
May include an established test database that can be used as a
safe and realistic training environment

Pilot environments
o
May include conference room pilots

Backup and recovery environments

o
May include the disaster recovery process
After the build and test planning stage for the controlled environments is
completed, pilots are planned.

Release Check
You need to check financial and commercial aspects before the deployment
and add activities to the deployment plans, where necessary. You need to
check the following:

Whether you have sufficient funds available as working capital to deliver

o customer expectations

Whether you have all the necessary contracts and licenses

Whether you have funding available for the supporting systems to

manage the Service

Whether IP concerns, such as the full range of IP and its ongoing

ownership and usage, have been addressed; this includes:
o
Software created by one of the parties
o
User manuals and other documentation
4.5.2 Build and Test
Preparing for Build, Test and Deployment
Validate the Service Design and the Release Design against the requirement for
the new or changed service.
To map build, test and deployment:

Record, track and measure any Risks and Issues against the Services,
Service Assets and Cis within the Service Package

Prioritize issues and actions to ensure timely resolution

Keep a validation report and its associated results ready for evaluation
It is critical to map the Service Design and the Release Design against the
requirement for the new or changed Service. This activity must be done before
authorizing the build and test stage. At the end of this activity, you should have
constructive feedback on Service Design.
Independent Evaluation
An independent evaluation of the Service and Release Design checks if the
Change to the Services or Service offering will deliver the predicted outcomes.
Interim Report
If the evaluation throws up any issues, an interim report is prepared.
The report lists:

Deviations from the SPD: The Service Package may be changed

Risk profile

Recommendations for Change Management

Technology-Enabled Service
Release, Deployment and Build and Test teams need to be trained on using
new technology.
These teams will have different skill sets and, consequently, their training
needs will vary.

Examples of training needs include:

Interpreting the Service Design documentation and plans

Use of support tools: e.g. for central release staff

Changes in health and safety requirements

Changes in security policies and procedures

Technical training

Service Management and process training, e.g. new build procedure for
new configuration item type
Build and Test
Some key aspects that need to be managed during the Build and Test phase of
Release and Deployment are:

Use of build and test environments

Creating and implementation of standards

Management of configurations
o
Implementing Configuration Management during build and test
activities
o
Maintaining a record of the complete build
o
Keeping testing evidence and documentation
o
Maintaining access controls to physical and technology
components
o
Verifying whether security arrangements are met
o
Managing environmental issues
o
Readying the Service Release for promotion to the next
environment
o
Handing over the Service Release to the next stage or team
Updating the CMS
The CMS is updated with the Configuration Baselines of the controlled
environment and the Release Package before and after an installation, build or
deployment.
The Service Provider must ensure that only the definitive version of the Release
Package is placed in the Definitive Media Library (DML). The Release Package
must always be taken from the DML to deploy to service Operation.
Release and Build Documentation
Use procedures and templates to build and test a Release.
It is a best practice to use procedures and templates to build and test a Release
because they help the Release team build a Release Package efficiently and
effectively.
The procedures and templates include:

Contract and agreements

Purchase requests

Request Fulfilment

Goods inwards and delivery

Health and safety guidelines

Security policies and procedures

Leasing agreements
Intellectual Property Rights (IPR)
Support agreements
Procedures
o
Manage Service and infrastructure
o
Distribute and install software
o
Distribute, translate and convert data and information
o
Deliver, install and move equipment
o
Clean data
o
Dispose documents
o
Build and manage test environments
o
Validate and test
o
Manage Change
Managing Service Assets and configurations
Managing acceptance and authorization
Documenting license agreements

Documentation
Document a new Release to ensure all the gathered information is handed over
to the Service Operations and CSI teams.
This documentation includes:

Roles and responsibilities

Process descriptions

Any manuals or Service Desk scripts used

Knowledge transfer documents

User manuals

Service information

Marketing information

Service Catalogue

Technical information

Service Management and operations plans

Business continuity plans

Index of all documentation

Managing Cis and Components
Cis and their components need to be acquired from projects, suppliers,
partners and development groups. It is essential to use Cis that have achieved
a specific level of quality or use standard components that have been
assessed, tested and authorized for use in specific conditions.
Verification activities for the components of a Release Package or build include:

Ascertaining that all items are bona fide

Verifying if standard naming conventions have been followed

Recording externally acquired items and checking them against their

delivery and Release documentation

Checking that all software is as expected, all definitive items have been
added to the DML, the rejection of components and software is as
expected and so on

Release Packaging Activities

The key activities to build a Release Package are:

Collect and integrate Release components in a controlled manner

Make and build Release documentation, including:

o
Build installation and test plans, procedures and scripts
o
Information on how to monitor and check the quality of a Release
and how to recognize and react to Problems
o
Automated or manual processes and procedures required to
distribute and deploy the Release
o
Procedures to back out Release Units
o
Procedures for tracking and managing software
You must apply build management procedures, methodologies, tools and check
lists to create the Release Package. This ensures that the Release Package is
built in a reproducible way.
Baselining Release Package
If the Release Package passes testing, the Release and its contents are placed
under the control of Configuration Management, baselined and verified against
the Release Design and Release Package definition. After this, any Changes in
the Release Package are managed through Change Management.
Build and Manage Test Environments
An effective build and test environment ensures that builds and tests are done
in a repeatable and manageable manner. It is critical to establish dedicated
test environments that are used for assembling and building components for
controlled test and deployment environments.
It is good practice to maintain and protect test environments using Service
Management best practices.
Build and Test

Prepare for build, test and deploy:

o
Validate the Service Design and the Release Design against the
requirement for the new or changed Service offering before
authorizing the Build and Test stage
o
Record, track and measure any Risks and issues against the
Services, Service Assets and Cis within the Service Package, SLP, SDP
or Release Package
o
Produce a validation report and its associated results ready for
evaluation
o
Ensure that the required training for the Release, Deployment,
Build and Test teams is validated and complete
o
Manage all Changes through Change Management
Key Aspects During Build and Test Activities
Key aspects that need to be managed during the activities to build and test a
Service or Service offering are:

Use of the build and test environments and standardization and

integration aspects
Management of configurations:
o
During the build and test activities, for example, during version
control, baseline management and control of inputs and outputs from
a build or test stage
o
Recording the complete build so that it can be rebuilt, if required,
and maintaining evidence of testing, for example, test results and
test reports
o
Controlling access rights to physical and technology components,
for example, setting parameters and checking that security
requirements are met

Other focus areas in this step include:

Release and build documentation

Acquire and test input Cis and components

Release packaging
Aim of Testing
Testing aims to build confidence in the Service capability prior to final
acceptance during pilots or ELS
The steps to conduct testing and pilot are:

Coordinate the testing activities of Service Validation and Testing

Build confidence in the Service capability prior to final acceptance during

pilots or ELS

Follow the Deming steps

Run the pilots

Test Types
Test types overlap during different levels of testing to provide a full range of
testing across the Service Lifecycle.
Some examples of test types are:

Service Release Test

o
Checks that the Service components can be integrated correctly
and that the Release can be installed, built and tested in the garget
environment

Service Operations Readiness Test

o
Ensures that a Service and its underlying application and
technology infrastructure can be transferred into the production
environment in a controlled manner. This test aims to:

Establish whether a Service and its Service Assets can be

released into the production environment

Make sure that the business processes, customers, users

and Service Provider Interfaces (SPIs) are capable of using the
Service correctly

Ensure that the service teams are capable of operating the

Service and using the Service Management systems

Deployment Readiness Test

Ensures that the deployment processes, procedures and systems

can deploy, install, commission and decommission the Release
Package
Service Management Test
o
Ensures that Service performance can be measured, monitored
and reported in production
Service Operations Test
o
Ensures that the Service teams will be able to operate the service
in production
Service Level Test
o
Ensures that the new or changed service will deliver the Service
Level Requirements (SLRs)
User Test
o
Ensures that users can access and use the new and changes
Service
Service Provider Interface Test
o
Ensures that the interfaces with the Service are working
Deployment Verification Test
o
Ensures that the Service capability has been correctly deployed
for each target deployment group or environment
o

Service Rehearsals
A Service Rehearsal is a type of testing method that aims to stimulate as much
of the Service as possible in an extensive and widely-participated-in practice
session. This is the last stage of internal testing before any public, live run of
the Service.
Successful delivery of a Service Rehearsal involves one or more stages,
including preparation and analysis, following the Deming cycle's steps:

Plan: Prepared for the day of the service Rehearsal

Do: Delivers the rehearsal

Check: Documents the findings of the rehearsal

Act: Take action after the rehearsal

Pilots
While a Service Rehearsal is done for and with internal personnel, a pilot is
done for real users but only for a small targeted audience.
A pilot aims to find out if any Service elements will not deliver as required and
identifies gaps in Service Management that put the Service and(or the
customer's business and assets at risk. While it does not need to focus on all
the Service and system functionalities, it should check that the Service utilities
are fit for purpose and that the Warranties are fit for use.
Activities of the Release and Deployment Team During Pilots:

Be prepared to bring recovery procedures into play

Involve important people who will be involved in the full deployment

Make sure that the people involved in the pilot are trained

Make sure that operational and support procedures that cannot be

simulated in a test environment are documented

Make sure that training and support documentation is viable

Establish customer, user and stakeholder interaction with the Service in
real-time situations
Obtain appropriate metrics to compare to the Service performance
model
Establish additional criteria that may need to be met before full
deployment starts
Determine the probable level of Service support and Service
Management resources that will be needed
Check for and fix issues and errors early on
Record improvements

Deliver Pilots Outputs

The outputs of a successfully delivered pilot include:

New or changed Services

Pilot test reports

Evaluation of a function-generated report

Key stakeholder agreement

Demonstrated benefits of the Service

Confirmation that the deployment team accepts the cost model

Target deployment groups in different geographical locations accepting

the Service Release
4.5.4 Plan and Prepare for Deployment
Release and Deployment Planning
Includes all the activities involved in planning and preparing a deployment
group for deployment, effectively preparing the organization and its people for
organizational Change. At this stage, you develop the detailed implementation
plan, including assigning individuals to specific activities during the actual
deployment stage.
Service Design and to some extent Service strategy as well are responsible for
assessing initial organizational Change readiness and identifying stakeholders.
Service Transition is responsible for validation the ready state designed in the
Service Design phase.
Planning and Preparing for Deployment
Before you plan and prepare a target deployment group or environment, make
sure that you have met these minimum entry criteria:

Made the deployment stakeholders feel confident and committed to the

Service Release and own their aspects of deployment

Made sure that the senior management, customers and business and
Service Provider teams:
o
Accept the deployment costs
o
Understand the management, organization and people
implications of the Release
o
Understand all required process Changes
Preparing for Deployment

To prepare for deployment:

Assess each deployment group's readiness to receive and implement a

Release Package

Identify gaps that need filing

Plan the activities required to deploy, transfer or decommission/retire

Services or Service Assets

Plan the transfer of a Service or Service Unit

Plan move and disposal activities

Assessing Readiness
To assess organizational readiness:

Perform the deployment readiness assessment activity early in the

transition

Revisit it periodically and feed the assessment results into detailed

implementation plans for the target deployment group
Readiness Assessment Steps
1 Identify all issues and Risks that might affect the deployment or delivery
of current Services
these issues and Risks include:
a Absence of dedicated internal resources and external supplier
resources
b Absence of training skills and awareness
c Unscheduled or late Changes in requirements
2 Take into account all anticipated Impacts on:
a Organizational structure
b The environment of new or changed Services
c Direct customers, users, partners and suppliers
2 Any gaps that need to be filled
Aspects to Assess
You assess for:

Financial implications, such as:

o
The current required working capital
o
The status of new and changed contracts
o
The validity of licenses
o
The status of IPR and digital rights

Applicable health, safety, security and environmental regulations

Current capability of business customers and users to use and get value
from the new or changed Services

Current Services, Service capability and resources used, including:

o
Service structure
o
Service dynamics
o
Service metrics and reports, including Warranties and Service
levels achieved

Current Service Management capability and resources, including:

o
Differences from the prerequisites for deployment such as
inadequate licensing arrangements or network bandwidth
o
Current operations and support resources, such as tools and
people

Support resources and workloads

Performance reports and improvement plans
Ability to predict and track actual Incident and Problem volumes
during deployment
Definition of requirements to alter the new or changed Service or
underlying solution
Organizational readiness, including
o
Role, resource and skills gaps
o
Training needs
o
Ability to assign competent individuals to appropriate roles
o
Motivation and empowerment, for example, whether the current
organizational culture encourages the application of the required
skills with the right leadership and commitment
o
Readiness of customers, users, Service Provider staff and other
stakeholders, such as suppliers and partners
Applications, information and data, including:
o
Access to secret, restricted or confidential applications,
information, documents and data
o
Knowledge and experience of user and support staff
Infrastructure and facilities, including:
o
Difficult access
o
Intermediate and final storage and stores for definitive hardware
and media
o
IT equipment space and capacity requirements
o
Electromagnetic interference (EMI) and radio frequency
interference (RFI) requirements
o
Air quality requirements
o
Weight and false floor loadings
o
Network considerations
o
Environmental requirements related to equipment, health, safety
and security
o
o
o

Develop Plans and Prepare for Deployment

Develop plans and prepare for deployment by assigning specific resources to
perform the deployment and ELS activities.
You develop plans and prepare for deployment by assigning specific resources
to perform the deployment and ELS activities. The activities you perform
include:

Create Risk mitigation plans

Develop plans for transfer/transition, upgrade, conversion, disposal and

retirement

Plan logistics and delivery, for example:

o
Prepare Service Assets and components for deployment,
establishing how and when they can be delivered and confirming that
delivery been successfully achieved and recorded
o
Prepare sites according to applicable health, safety, security and
environmental regulations and requirements

Tailor processes, procedures and knowledge, for example, incorporate

language translation and timeframe adjustments
Transfer knowledge and train stakeholders on how to use, benefit,
manage, support and operate the new or changed service. To do this, you:
o
Identify essential and potential recipients of training such as
customer, users, IT Service Management (ITSM) teams, the Service
Desk, and support, operations and deployment teams and projects
o
Update the Service Desk with knowledge of the target deployment
group and its environment
Communicate the following to the people involved:
o
Changes and their expected benefits
o
How the Changes affect the organization and staff
Make any emergency Changes in continuity plans and procedures
Mobilize Service Operations and the support organization
Mobilize users to be ready to use the Service
Perform any additional activities identified from the assessment

The final step is to verify the detailed deployment plans, perform any
deployment readiness tests and raise an RFC for authorization through Change
Management. This ensures that the Service is ready for deployment.
Plan and Prepare for Deployment

This is an opportunity to prepare the organization and people for Change

Entry criteria for planning and preparing a target deployment group or

environment include:
o
Deployment stakeholders are confident in the Service Release
o
All stakeholders accept the deployment costs, management,
organization and people implications of the Release as well as any
organizational, functional and process Changes

Run a readiness assessment for the deployment

Develop plans and prepare for deployment

4.5.5 Transfer, Deploy and Retire
Deployment day
The activities performed on the day of the deployment are:

Transfer financial assets

Transfer the business and organization

Deploy processes and materials for users

Deploy the Service Management capability

Transfer the service

Deploy the Service

Decommission and remove redundant assets

Verify the deployments, ELS flowcharts and exit criteria

Transfer Financial Assets
To start the deployment, you must first transfer the financial assets that need
to be executed as part of Deployment Management. These assets include:

Intellectual property

Changes in supplier financial agreements and changes

All annual support and maintenance costs, including systems to manage

the Service such as the CMS
Charges for the purchase of new licenses or renewal fees
Costs for annual disaster recovery contracts with third parties
Working capital

Transfer the Business and Organization

You must note that transferring the business and organization to a new location
will affect the organization as a whole.
The activities needed to implement these Changes are:

Decide the organization structure, roles and responsibilities

Communicate Changes in the organization, roles and responsibilities to

all the stakeholders

Communicate the consequences and requirements of the deployed

Service, ensuring that new policies are adopted. Some examples or such
requirements are the optimum use of resources to deliver the message,
acquisition of the correct understanding of personal and group concerns
and consistent and appropriate communication of messages to diverse
and related groups

Ensure that continuity plans and procedures are understood well

Other Activities During Transferring/Transitioning
In case the Change includes a transfer of Service Provider, you need to
consider some specific elements, such as organizational Change and quick
wins, to avoid uncertainty. You will also need to make sure that you have
competent people, with the right skills, who are able to perform the Deploy and
Operate activity and manage the new or changed Service in the business,
customer and Service Provider organization.
Activities related to making sure you have the right people for the job include:

Recruiting staff with suitable skills. In most organizations, it might be

more efficient to recruit new staff who already have the required skills
rather than to develop new skills in existing staff. Whether this will be in
addition to the existing staff or involve replacing some staff with
inappropriate skills is a decision for the organization to make

Naming existing people, for example, staff, supplier and users with the
required skills and transferring or reallocation people as needed

Keeping outsources/contractual resources as a back-up arrangement to

provide the required skills

Organizing appropriate trainings and managing the training logistics,

coordination, setup, communications, registration, delivery and evaluation
activities, including users and Service Operations teams

Defining the knowledge transfer plan and checking progress

Assessing the competence of new and changed staff and other people
Deployment Processes and Materials for Users
Materials may include policies, processes, procedures, manuals, overviews,
training products, organizational Change products and so on.

After sharing the materials, check whether the users are competent and
confident to operate, maintain and manage the Service. At this time, remove or
archive redundant Services and Assets.
Transfer the Service
Transferring a Service includes the following activities:

Perform Service tests and follow an Evaluation process before a Service

is transferred. This helps review the performance of the Service and the
issues and Risks associated with it

Perform configuration audits of Service Assets and configurations

Add or remove Services to finalize the service Catalogue

Communicate the Change to relevant stakeholders by sending a Service

notification
Deploy the Service
To deploy the Service, you must:

Distribute and deliver the Service and Service components

Build, install and configure the service and Service components with any
new information

Test the system and the Service per the defined test plan and collate the
test results

Record all Incidents

Correct any deviations

Decommission and Remove Redundant Assets
Redundant assets: Redundant data, Information, Records related to the
previous Service or products
To retire or decommission a Service:

Remove deployed copies of software and data from retired hardware

Identify licenses and other assets that can be reused in the organization

Dispose equipment according to environmental policies and procedures

Move assets that can be redeployed to a secure area

Update DML
You may need to retire a Service after a specific interval of time. This ensures
that the service does not include defunct aspects. Failure to perform retirement
or decommissioning activities may lead to license contravention or the staff
using unsupported software.
You must also remove any redundant assets at this stage. These may include
redundant data, information and records related to the previous Service or
products they may also include support contracts with third-party contractors
and so on.
4.5.6 Release Verification
To verify the deployment:

Ensure that the Service, Service assets and Service capability resources
are in place

Complete information and documentation updates, such as Service

Catalogues, documentation, contract agreements and contract details
Update the orientations, communications and learning material so that
they can be readily distributed to stakeholders, Service Operations and
users
Assign different roles to individuals or organizations
Ensure the use of a new or changed Service or Service capability in
normal, emergency or disaster situations
Ensure appropriate access to the information necessary to use, operate
or support the Service
Establish measurement and reporting systems to measure Service
performance

Conducting satisfaction surveys are a good way to gather feedback on the

deployment process and to help make improvements in the future, you should
report any issues and Incidents and take the right actions as quickly as
possible.
Types of Tests to Verify Service
1 Services, Service Assets and Service capability/resources are in place, for
example, by performing an audit such as a configuration audit of the
deployed baseline against the as-planned baseline
2 Updates to documentation and information are completed, for example,
the Service Catalog, contracts, agreements and contract details
3 Communications, orientation and learning materials are ready to distribute
to stakeholders
4 Operations are verified and users are informed about the operations that
will be taking place
5 All roles are assigned to individuals/organizations
6 People and other resources are prepared to operate and use the new or
changed Service or Service capability in normal, emergency and disaster
situations
7 People have access to the information necessary to use, operate or
support the Service
8 Measurement and reporting systems are established to measure the
performance of the Service and underlying resources
9 Gather feedback on the deployment process to feed into future
improvements, for example, using satisfaction surveys
10 Report any issues and Incidents and take corrective actions as necessary
4.5.7 Early Life Support
For some Services, we choose to have an ELS program. ELS helps in the
transition of the new or changed service into the Service Operations phase in a
controlled manner. It also establishes new Service capabilities and resources.
The stakeholders agree on start and exit criteria for ELS during the Service
Design phase. However, you can decide the finalization of the performance
targets and exit criteria at this stage. During this stage, you can understand
the deployment verification process. You can also set customer and stakeholder
expectations for the handover of the Service to Service Operations

ELS gives the right resources to quickly, centrally and locally resolve
operational and support issues so that users can use the Service without
unwarranted disruptions to support their business activities. The deployment
teams should examine where issues and Problems are likely to occur, based on
earlier experience.
Examples of ELS Issues and Problems
Clarification about:

Role assignments, roles and responsibilities

Financial and funding arrangements

Procurement and request fulfilment

Security policies and procedures

Raising incidents and change requests

Escalation procedures

Complaints procedure

Using diagnostics tools and aids

Software licensing rules

ELS Mechanism
After the Release is successfully deployed, you can initiate the ELS mechanism
for the deployment group.
The deployment team:

Provides stability to the Service by implementing improvements and

resolving Problems. The deployment team progressively stops providing
assistance once users and Service teams are familiar with the new
Changes and there is a reduction in Incidents and Risks.

Ensures that all documentation and the knowledge base are up-to-date,
with current information on other diagnostics, Known Errors, Workarounds
and FAQs

Resolves any transfer of knowledge or gaps in training

4.5.8 Review and Close the Deployment
To review and close the deployment:

Record feedback on customer, user and Service Provider satisfaction

Make note of missed quality criteria

Check the completion status of fixes and Changes

Review open Changes

Review performance targets

Review and Close Activities

A formal review that is appropriate to the scale and magnitude of the

Change needs to be completed

A review of the Service Transition should include

o
A check that all transition activities have been completed. For
example, documentation and information are captured, updated
secured and archived
o
A check that accurate metrics were captured

4.6 Triggers, Inputs and Outputs of the process

Triggers
The receipt of an approved RFC to deploy a production-ready Release Package
triggers the Release process, and the receipt of an approved RFC to deploy a
Release Package to a target deployment group or environment, such as a
Business Unit, customer group, or Service Unit, triggers the deployment
process.
Inputs
A primary input for the Release and Deployment Management is an authorized
RFC .
Other inputs include:

An SLP

An SDP, including Service model and SAC

IT Service continuity plan and related business continuity plan

Service Management and operations plans and standards

Technology and procurement standards and catalogues

Acquired Service assets and components and their documentation

Build models and plans

Environment requirements and specifications for build, test, release,

training, disaster recovery, pilot and deployment

Release policy and release design from Service Design

Release and deployment models including template plans

Exit and entry criteria for each stage of release and deployment
Outputs
Some key outputs of the Release process are:

Release and deployment plan

Completed RFCs for the release and deployment activities

Service notification

Updated service catalogue with the relevant information about the new
or changed service

New tested service capability and environment including SLA, other

agreements and contracts, changed organization, competent and
motivated people, established business and Service Management
processes, installed applications, converted databases, technology
infrastructure, products and facilities

New or changed Service Management documentation

Service package that defines the requirements from the

business/customer for the service

An SLP that defines the service level requirements, e.g. hours of service,
business critical services, data and periods, service level targets

An SLA, underpinning OLAs and contracts

Service Model that describes the structure and dynamics of how the
service is operated and managed

New or changed service reports

Tested continuity plans

Complete and accurate CI list with an audit trail for the Cis in the release
package and also the new or changed Service and infrastructure
configurations
Service capacity plan that is aligned to the relevant business plans
Deployment ready Release Package (baselined) for future deployments
Service Transition Report

The deployment process is said to be complete after a handover of the new or

changed service to Service Operations. This transfer takes place only after the
successful completion of the Post-Implementation Review (PIR) of the
deployment process conducted within Change Management.
Release and Deployment Management Interfaces with Other Processes
The relationships of Release and Deployment Management with other
processes in the RCV context:

Throughout the deployment process, appropriate records will be created

and maintained. As Cis are successfully deployed, the CMS will be updated
with information such as:
o
New or changed Cis
o
Relationships between requirements and test cases
o
Installation/build plans
o
Logistics and delivery plans
o
Validation and test plans, evidence and reports
o
New or changed locations and users
o
Status updates (for example, from allocated to live)
o
Change in ownership of assets
o
License holding

Other data and information will also be captured and recorded within the
broader SKMS. This could include:
o
Deployment, information, history of the deployment itself, who
was involved, timings and so on
o
The HR in many organizations holds the training records of its staff
but the responsibility for the update of the ITSM staff records will
logically rest with ITSM also
o
Access rules and levels
o
Known Errors. Typically, a new or changed Service will be
introduced with identified errors that, while not according to the
original Service Design specification, are nonetheless minor enough
in nature to be acceptable in live operation. These may well be under
active investigation and resolution by the Service builders of may
considered acceptable. In either case, the errors will be deployed into
the live error database as an element of the deployment of the live
Service. This information will be available through the SKMS to the
Service Desk, which will then be able to link Incidents reported
against these Known Errors.
o
As part of clean-up activities, it is important to delete or archive
redundant records related to the previous Service or products

4.7 Recording and Maintaining Service Deployment

Information
Deployment Process
In the deployment process, you need to create and maintain appropriate
records. Each time you deploy a CI, you must update the following information
in the CMS:

New or changed configuration items

Relationships between requirements and test cases

Installation/build plans Logistics and delivery plans

Validation and test plans, evidence and reports

New or changed locations and users

Status updates (e.g. from allocated to live)

Change in ownership of assets

License holding
In the deployment process, you must also capture and record other information
that falls into the scope of a broader SKMS.
This could include:

All deployment information, history of the deployment, who was involved

in the process, timings and so on

All training records. The HR team holds this information in many

organizations. However, the ITSM team is also responsible for maintaining
this type of information related to ITSM

Access rules and levels

Known Errors. In any organization, a new or changed Service will be

introduced with identified errors. These errors are not according to the
original Service Design specifications but are minor enough in nature to be
acceptable in live operation. These could be errors under investigation and
the Service builders may be in the process of resolving them. These
Known Errors could be considered acceptable. In either case, the errors
will be deployed into the live error database as an element of the
deployment of the live Service.
This information will be available through the SKMS to the service desk who will
then be able to link incidents reported against these known errors. As part of
the clean-up activities it is important to delete or archive redundant records
related to the previous service or products.

4.8 Process Measurement

Key Performance Indicators
Some examples of customer or business KPIs are:

Increased customer and user satisfaction in relation to the delivered

Services

Fewer Incidents, as measured against a Service

Minimal or reducing deviation from the Service performance required by

customers

Reduced customer dissatisfaction

As with all other processes, it is important to monitor and report the

performance of Release and Deployment Management. Appropriate action
should be taken to improve the performance.
Examples of Service Provider KPIs
Some examples of Service Provider KPIs are:

Reduction in the number of resources and the cost of fixing and

diagnosing Incidents and Problems in both the deployment and production
processes

Greater use of the common standards framework, reusable processes

and supporting documentation of Service Transition

Reduction in the number of discrepancies identified in configuration

audits, as compared to other organizations

4.9 Roles and Responsibilities

Roles in Planning, Execution and Managing Release and Deployment
1 The Release and Deployment Manager:
a Manages different aspects of the end-to-end Release process
b Updates the SKMS and CMS
c Coordinates the build and test environment and Release teams
d Ensures that all teams follow the organization's established policies
and procedures
e Reports the progress of the Release to the management
f Builds the Service Release and Deployment policy and plans
g Handles Release Package design, build and configuration
h Ensures Release Package acceptance, including business sign-off
i Manages Service rollout planning, including the deployment method
j Deals with Release Package testing to predefined acceptance criteria
k Ensures Release Package sign-off for implementation
l Deals with communication, preparation and training
m Audits hardware and software before and after the implementation of
Release Package Changes
n Manages hardware installation, both new as well as upgraded
o Ensures the storage, traceability or auditability of controlled software,
in both centralized and distributed systems
p Deals with the Release, distribution and installation of packaged
software
2 The Release Packaging and Build Manager:
a Establishes the final Release configuration, for example, knowledge,
information, hardware, software and infrastructure
b Builds the final Release delivery package
c Tests the final delivery before the product is tested independently
d Establishes and reports unresolved Known Errors and Workarounds
e Provides input to the final implementation sign-off process
f Interfaces with other functions:
i
Security Management

ii
Test Management
iii
Change Management
iv
Service Asset and Configuration Management (SACM)
v
Capacity Management
vi
Availability Management
vii
Incident Management
viii
Quality Management
The deployment staff:
a Perform the final physical delivery of the Service implementation
b Coordinate Release documentation, including technical Release notes
and manage communications training and customer and Service
Management
c Plan the deployment process interface with Change and Knowledge
Management and SACM
d Provide feedback on the effectiveness of the Release
e Provide technical and application guidance and support throughout
the Release process, including for Known Errors and Workarounds
f Record deployment metrics to ensure that they are within agreed
SLAs
ELS is considered a vital part of the Release and Deployment phase. ELS
should start before a Service is operational. The ELS staff:
a Provide IT Service and business, functional support before Service
Operations finally accepts the Service
b Ensure the delivery of appropriate support documentation
c Provide Release acceptance for ELS
d Provide initial support in response to the Incidents and errors
detected within a new or changed Service
e Adapt initial usage elements, such as:
i
User and support documentation, including service Desk scripts
ii
Data management, including archiving
b Embed activities for a new or changed Service
c Ensure formal transition of the Service to the Service Operations and
CSI phases of the Service Lifecycle
d Monitor Incidents and Problems and undertake Problem Management
during Release and Deployment along with raising RFCs, when
required
e Provide initial performance reporting and undertaking performancebased Service Risk assessment

Release and Deployment Manager

The Release and Deployment Manager: Plans designs, builds, configures and
tests all the software and hardware required to create a Release Package. The
Release Package will be used for delivering or making Changes to the
designated Service. The Release and Deployment Manager delegates some of
the responsibility to the relevant subprocess of the Release team. The items
that are delegated are:

Service documentation, including Service Portfolios, Service Catalogues,

SLAs, Operational Level Agreements (OLAs) and Underpinning Contracts
(UCs)

Application programs developed in-house

Software developed by external vendors, including customized software,

standard off-the-shelf software and utility software
Hardware and its specifications
System software provided by suppliers
Assembly instructions and documentation, including user manuals

The Release and Deployment Manager also manages all deliverables, right
from their purchase or development to their configuration and implementation.

4.10 Challenges, Risks and Critical Success Factors

(CSFs)
Challenges
The challenges of Release and Deployment Management are:

Development of standard performance measure and measurement

methods followed in different projects and by different suppliers

Inaccurate estimation of delivery dates from projects and suppliers,

which leads to delays in Service Transition scheduling activities

Different perspectives of stakeholders

Risk assessment to evaluate past and future Impacts on the Service

Transition of Services and Releases

Ability to encourage information-sharing to enhance a Risk Management

culture
CSFs

Building new or changed Service capability and resources in the target

environment or deployment group
Testing new or changed Services against Service Transition
Providing Service capability in a pilot environment
Developing reusable test models that are further used for regression
testing

Risks

Employing staff not fully dedicated to Release and Deployment activities

Scope creep during the Release and Deployment process resulting from
the poor understating of the defined scope and dependency in earlier
Lifecycle stages
Failure to obtain appropriate approval at the right time
Insufficient operational support
Use of inaccurate or insufficient information
Miscalculation of the time required to complete a project
Not employing proper health and safety measures, compromising them
Inadequate back-out or contingency plan in the event of sourcing or
partnership failures

Other Release and Deployment Management Risk Factors

Management Risks
o
Management incompetence

Insufficient corporate policies or management practices in place

Poor leadership
Financial Risks
o
Insufficient finances
o
Financial delays, leading to deployment in different financial years
o
Insufficient funding clarity for Changes or fixes during transition
o
Complexity in tracking and managing software licenses
Control Management Risks
o
Unclear definition of the required controls, leading to poorly
evaluated and unauthorized Changes that adversely affect Release
and Deployment plans
o
Difficulty in tracking and managing software licenses
o
Unscheduled and unexpected regulatory controls or licensing
requirement changes
Organizational Change Management Risks
o
Vague expectations or objectives from customers, users, suppliers
and other stakeholders
o
Cultural differences or misunderstandings
o
Unclear communication
o
Organizational Changes impacting employee morale
o
Personality clashes
o
Key personnel having inadequate authority to accomplish their
roles
o
Insufficient recruitment and selection procedures
o
Unclear roles and responsibilities
o
Vested interests creating conflicts, leading to compromises in
product quality
o
Individual or group interests receiving unwarranted priority
Application or Technical Infrastructure Risks
o
Inadequate design
o
Professional negligence
o
Human error or incompetence
o
Failure of infrastructure
o
Infrastructure or application differences or dependencies
o
Increase in dismantling or decommissioning costs
o
Compromising product safety
o
People or equipment performance failure
o
Physical security or information security breaches
Governance issues
o
Insufficient senior management commitment
o
Immature supplier management function
o
Large number of adverse Changes in work practices and
procedures
o
o