Release and Deployment Management Tutorial

Release and Deployment Management

Welcome to lesson 5 of the ITIL Intermediate RCV tutorial, which is a part of ITIL Intermediate RCV Foundation Certification course. This lesson talks about how the release and deployment management (RDM) process contributes to RCV practices.

Let us look at the objectives of this lesson.


By the end of this ‘Release and Deployment Management’ lesson, you will be able to:

  • Understand the complete overview of the purpose, objectives, scope, and importance of release and deployment management as a process to generate business value.

  • Explain the Release and deployment management policies, principles, concepts, activities, methods, and techniques in relationship to RCV practices.

  • Discuss the concept of the release unit, along with RDM planning, release build and test, pilots, deployment, logistics, delivery, retirement, risks, and financials.

  • Review the efficient use of RDM critical success factors and key performance indicators.

In the next two sections, let us learn about the purpose, objectives, and scope of the RDM process.

Purpose and Objectives of Release and Deployment Management (RDM)

The purpose of Release and deployment management is to plan, schedule and control the build, test and deployment of releases, and to deliver the new functionality required by the business while protecting the integrity of existing services.

The objective of Release and Deployment Management is to:

  • Define and agree with release and deployment plans with customers and stakeholders

  • Ensure that each release package consists of a set of related assets and service components that are compatible with each other

  • Ensure that integrity of a release package and its constituent components is maintained throughout the transition activities and recorded accurately in the CMS

  • Ensure that all release and deployment packages can be tracked, installed, tested, verified, and uninstalled or backed out if appropriate

  • Ensure that organization and stakeholder change is managed during the release and deployment activities.

  • Record and manage deviations, risks, issues related to the new or changed service and take necessary corrective action

  • Ensure that there is knowledge transfer to enable the customers and users to optimize their use of the service to support their business activities

  • Ensure that skills and knowledge are transferred to operations and support staff to enable them to effectively and efficiently deliver, support and maintain the service according to required warranties and service levels.

Furthermore, other objectives include steps to ensure that:

  • There are clear and comprehensive release and deployment plans that enable the customer and business change projects to align their activities with these plans

  • A release package can be built, installed, tested and deployed efficiently to a deployment group or target environment successfully and on schedule

  • A new or changed service and its enabling systems, technology and organization are capable of delivering the agreed service requirements, i.e., utilities, warranties and service levels

  • There is a minimal unpredicted impact on the production services, operations and support organization

  • Customers, users, and Service Management staff are satisfied with the Service Transition practices and outputs, e.g.,user documentation and training.

Scope of Release and Deployment Management

The scope of Release and Deployment Management includes the processes, systems, and functions to package, build, test and deploy a release into production and establish the service specified in the Service Design package before final handover to service operations.

Let us now look at the RDM process as value to the business.

Value to Business of Release and Deployment Process

Effective Release and Deployment Management enables the service provider to add value to the business by:

  • Delivering change, faster and at optimum cost and minimized risk

  • Assuring that customers and users can use the new or changed service in a way that supports the business goals

  • Improving consistency in implementation approach to the business change, service teams, suppliers, and customers

  • Contributing to meeting auditable requirements for traceability through Service Transition.

Well-planned and implemented release and deployment will make a significant difference to an organization’s service costs.

A poorly designed release or deployment will, at best, force IT personnel to spend significant amounts of time troubleshooting problems and managing complexity. At worst, it can cripple the environment and degrade the live services.

Moving on, in the next section, we will discuss the policies of this process.

Release and Deployment Policies

Release and deployment management policies should be in place to help the organization achieve the correct balance between cost, service stability and agility.

Release and deployment management policies should help release and deployment management personnel to make decisions that support the overall objectives of the business.

These policies can be set at an overall service provider level, for example:

  • ‘All changes and releases must be fully tested under a realistic load before they are deployed’ or

  • For an individual service, for example,‘All changes to the service will be packaged into annual releases’

  • And ‘the only permitted changes between these releases will be to resolve problems that have a major impact on the business.’

In the next section, let us look at the release unit and its identification.

Release Unit and Identification

A ‘release unit’ describes the portion of a service or IT infrastructure that is normally released together according to the organization’s release policy. The unit may vary, depending on the type(s) or item(s) of service asset or service component such as software and hardware.

The general aim is to decide the most appropriate release unit level for each service asset or component. An organization may, for example, decide that the release unit for business-critical applications is the complete application in order to ensure that testing is comprehensive. The same organization may decide that a more appropriate release unit for a website is at the page level.

The following factors should be taken into account when deciding the appropriate level for release units:

  • The ease and amount of change necessary to release and deploy a release unit

  • The amount of resources and time needed 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

  • The storage available in the build, test, distribution and live environments.

Releases should be uniquely identified according to a scheme defined in the release policy. The release identification should include a reference to the CIs that it represents and a version number that will often have two or three parts, e.g., emergency fix releases: Payroll_ System v.1.1.1, v.1.1.2, v.1.1.3.

Let us look at an example of release unit in the next section.

How about investing your time in ITIL Intermediate RCV Certification? Check out our Course here!

Simplified example of Release Units for an IT service

Here is an example of the release unit in the IT service. The figure below gives a simplified example showing an IT service made up of systems and service assets, which are in turn made up of service components.

A ‘release package’ is a set of configuration items that will be built, tested and deployed together as a single release. Each release will take the documented release units into account when designing the contents of the release package.

It may sometimes be necessary to create a release package that contains only part of one or more release units, but this would only happen in exceptional circumstances.

As we have an understanding of release unit, let us move to the next section to learn about designing release and release packages.

Designing Release and Release Packages

For designing release and release package, the policies given here needs to be considered:

  • The release and deployment teams need to understand the relevant architecture to be able to plan, package, build and test a release to support the new or changed service. This helps to prioritize the release and deployment activities and manage dependencies

  • Dependent services will need to be built and tested in Service Transition, for example, an IT financial service may be dependent on several internal support services and an external service. There are normally dependencies between particular versions of service components required for the service to operate.

  • A release package may be a single release unit or a structured set of release units. Where possible, release packages should be designed so that some release units can be removed ¡f they cause issues in testing

In the next section, let us study the architectural elements to be built and tested in the RDM process.

Architecture elements to be built and tested

The figure given below provides an example of how the architectural elements of a service may be changed from the current baseline to the new baseline with releases at each level. The architecture will be different in some organizations but is provided in this section to give a context for release and deployment activities.

The release and deployment teams need to understand the relevant architecture in order to be able to plan, package, build and test a release to support the new or changed service. This helps to prioritize the release and deployment activities and manage dependencies, e.g.,the technology infrastructure needs to be ready with operations staff ready to support it with new or changed procedures before an application is installed.

The figure also shows how the service architectural elements depend on the service Portfolio that defines the service offerings and service packages. Dependent services will need to be built and tested in Service Transition. for example,an IT financial service may be dependent on several internal support services and an external service. For more details about the structure of services, see the Service Strategy and Service Design publications.

There are normally dependencies between particular versions of service components required for the service to operate. for example,a new version of an application may require an upgrade to the operating system and one or other of these two changes could require a hardware change, e.g.,a faster processor or more memory. In some cases, the release package may consist of a set of documentation and procedures. These could be deployed via a manual update or through an automatic publishing mechanism, e.g.,to the SKMS/ or website.

To understand this better, let us take an example of a release package in the next section.

Example of a release package

A release package may be a single release unit or a structured set of release units such as the one shown in the figure.

The example in the figure shows an application with its user documentation and a release unit for each technology platform.

On the right, there is the customer service asset that is supported by two supporting services – SSA for the infrastructure service and SSB for the application service.

These release units will contain information about the service, its utilities, and warranties and release documentation.

Often there will be different ways of designing a release package, and consideration needs to be given to establishing the most appropriate method for the identifiable circumstances, stakeholders, and possibilities. Where possible, release packages should be designed so that some release units can be removed if they cause issues in testing.

Moving on, let us now understand the coordinating and deployment of service components.

Coordinating the deployment of service components

Any significant new or changed service or service offering will require the deployment stage to consider the full range of elements comprising that service – infrastructure, hardware, software, applications, documentation, knowledge, etc. Effectively, this means the deployment will contain sub-deployments for elements comprising the service, as illustrated in the figure below.

Coordinating deployment of Service Components

The combination, relationship, and interdependencies of these components will require careful and considered planning. Significant deployments will be complex projects in their own right.

To understand the deployment options, a high-level assessment of the deployment units, locations, and environments may be required, for example:

  • Assessment baseline – this is a snapshot of the relevant environment, services, and infrastructure, including ‘softer’ elements such as skills level and attitudes where applicable, should be taken as a first step.

  • Identify the components – this may include deciding the best way to break down a major deployment into components. Often there will be different ways of achieving this breakdown and consideration needs to be given to establishing the most appropriate method for all the identifiable circumstances, stakeholders and possibilities.

  • Determine the appropriate deployment approach for each.

In the next section, we will learn about release design options and their considerations.

Release design options and considerations : Big Bang vs. Phased

‘Big bang’ vs. phased Options for deploying new releases to multiple locations are described below:

  • ‘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 rollout 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.

Let us look at these options of deploying release in the form of a figure in the next section.

Options for 'Big Bang'and phased deployment

The figure shown above illustrates a possible sequence of events over time as follows:

  • There is an initial launch of ‘Release 1’ of the system to three workstations (1–to 3).Two further workstations (4+ plus 5) are then added at the same time.

  • ‘Release 2’ of the system is then rolled out in a ‘big bang’ approach to all workstations (1–to 5) at once. Two further workstations (6+plus 7) are then added, in another step.

  • There is a phased implementation of the upgrade to ‘Release 3’ of the system, initially upgrading only three workstations (1–to 3) and then the remaining four (4–to 7). A further workstation (8) is then added to the system.

In the next section, let us look at phased deployment illustration.

Phased deployment across geographical locations

The figure shown below illustrates phased deployment to some different geographical locations.

It assumes that new versions will work alongside the previous one. The example used assumes that new functionality is implemented first in the head office of the organization, then in a single branch and finally in the remaining branches.

If there are a very large number of locations to deal with, it may still take a long time to implement the initial system or upgrades in all branches, thus increasing the likelihood of needing to support even more versions of the system concurrently in the live environment.

So far we looked at release deployment options. In the next section, let us understand release design options.

Release design option and consideration: Push and Pull

First, let us look at the Push and pull approaches.

A push approach is used where the service component is deployed from the center and pushed out to the target locations. Regarding service deployment, delivering updated service components to all users – either in the big bang 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 overridden by a release that is pushed to all known users.

In order to deploy via ‘push’ approach, the data on all user locations must be available. Pull approaches do not rest so heavily on accurate configuration data, and they can trigger an update to user records. This may be through new users appearing and requesting downloads or expected users not doing so, triggering an investigation into their continued existence.

As some users will never ‘pull’ a release, it may be appropriate to allow a ‘pull’ within a specified time limit and if this is exceeded a push will be forced, e.g.,for an anti-virus update.

In the next section, we will look at automation and manual approaches.

Release design options and considerations: Manual vs. Automation

Whether by automation or other means, the mechanisms to release and deploy the correctly configured service components should be established in the release design phase and tested in the build and test stages.

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 or capacity issues that affect the service levels.

Moving on, let us look at the release and deployment models of the RDM process.

Release and Deployment Models

A service may be deployed into the production environment in a number of ways. Service Design will select the most suitable release and deployment models that include the approach, mechanisms, processes, procedures, and resources required to build and deploy the release on time and within budget. The release methods during the early build and test stages may differ significantly from live operations so plan ahead to ensure that appropriate release methods are adopted at the right time.

Release and deployment models define:

  • Release structure – the overall structure for building a release package and the target environments

  • The exit and entry criteria including mandatory and optional deliverables and documentation for each stage

  • Controlled environments required to build and test the release for each release level; there will be multiple logical and physical environments through the Service Transition stage mapped to different physical environments available to the transition team

  • The roles and responsibilities for each configuration item at each release level

  • The release promotion and configuration baseline model

  • Template release and deployment schedules

  • Supporting systems, tools and procedures for documenting and tracking all release and deployment activities

  • The handover activities and responsibilities for executing the handover and acceptance for each stage of release and deployment.

In the next section, let us look at the considerations of release and deployment models.

Considerations in Release and deployment models

Considerations in designing the release and deployment model include activities to:

  • Verify that a release complies with the SDP, architecture and related standards

  • Ensure the integrity of hardware and software is protected during installation, handling, packaging, and delivery

  • Use standard release and deployment procedures and tools

  • Automate the delivery, distribution, installation, build and configuration of audit procedures where appropriate, to reduce costly manual steps

  • Manage and deploy, redeploy, remove or retire software licenses

  • Package and build the release package so that it can be backed out or remediated if required

  • Use Configuration Management procedures, the CMS and DML to manage and control components during the build and deployment activities, e.g.,to verify the prerequisites, co-requisites and post-installation requests

  • Document the release and deployment steps

  • Document the deployment group or target environment that will receive the release

  • Issue service notifications. As we have understood the models and consideration of release and deployment process.

Let us learn about phases of RDM in the next section.

Phases of Release and Deployment management

Release and deployment management lifecycle consists of the following phases

  • Release and deployment planning

  • Release build and test

  • Deployment

  • Review and close

Let us discuss each phase in detail :

Release and deployment planning

  • Plans for creating and deploying the release are created.

  • This phase starts with change management authorization to plan a release and ends with change management authorization to create the release.

Release build and test

  • The release package is built, tested and checked into the DML.

  • This phase starts with change management authorization to build the release and ends with change management authorization for the baselined release package to be checked into the DML by service asset and configuration management.

  • This phase only happens once for each release.


  • The release package in the DML is deployed to the live environment.

  • This phase starts with change management authorization to deploy the release package to one or more target environments and ends with handover to the service operation functions and early life support.

  • There may be many separate deployment phases for each release, depending on the planned deployment options.

Review and close

  • Experience and feedback are captured, performance targets and achievements are reviewed, and lessons are learned.

Let us understand these phases with the help of a figure in the next section.

Phases of Release and Deployment Management

The following figure shows multiple points where an authorized change triggers release and deployment management activity.

This does not require a separate RFC at each stage. Some organizations manage a whole release with a single change request and separate authorization at each stage for activities to continue, while other organizations require a separate RFC for each stage. Both of these approaches are acceptable; what is important is that change management authorization is received before commencing each stage.

In the next section, let us understand the release and deployment plans.

Release and Deployment Plans

Plans for release and deployment will be linked into the overall service transition plan and adopt the selected release and deployment model. The approach is to derive a sound set of guidelines for the release and deployment plans that can be scaled from small organizations to large multinationals. Although smaller organizations will have less complex environments, the disciplines detailed here are still relevant.

Even within a single organization, the release and deployment plans need to be scalable since the extent of their scale of impact on the organization will vary, perhaps from impacting only one small specialist team in one location through to multinational impact on all users when introducing new desktop equipment and services or transferring services to different suppliers.

Release and deployment plans should be authorized through change management and should contain the following information:

  • Scope and content of the release

  • Risk assessment and risk profile for the release

  • Organizations and stakeholders affected by the release

  • Stakeholders that may authorize the change request for each stage of the release

  • Team responsible for the release

  • Deployment schedule for the release

Approach to working with stakeholders and deployment groups to determine:

  • Delivery and deployment strategy

  • Resources for the release build, test and deployment, and for early life support and

  • Amount of change that can be absorbed.

Let us now proceed to look at the pass or fail criteria in the RDM process.

Pass or Fail criteria

Service transition is responsible for planning the pass/fail situations. At a minimum, these should be defined for each authorization point through release and deployment management. It is important to publish these criteria to relevant stakeholders well in advance to set expectations correctly.

An example of a pass situation before build and test is:

  • All tests are completed successfully

  • The evaluation report shows no unacceptable risks and

  • Change management authorizes check-in to the DML.

Examples of fail situations include:

  • Insufficient resources to pass to the next stage.

For example, an automated build is not possible, and so the resource requirement becomes error-prone, too onerous difficult and expensive; testing identifies that there will not be enough money to deliver the proposed design in the operation stage of the service lifecycle.

  • Service operation does not have capabilities to offer particular service attributes.

  • Service design does not conform to the service operation standards for technologies, protocols, regulations, etc.

  • The service cannot be delivered within the boundaries of the design constraints.

  • Service acceptance criteria are not met.

  • Mandatory documents are not signed off.

  • SKMS and CMS are not updated, perhaps due to a process that is manually intensive.

  • The incidents, problems, and risks are higher than predicted, e.g., by over 5%.

In the next section, we will discuss the build and test planning of the RDM process.

Build and Test Planning

Build and test planning establishes the approach to building, testing and maintaining the controlled environments before live use. Build and test planning must work with service validation and testing to ensure that test plans can be carried out.

The activities include:

  • Developing build plans from the SDP, design specifications and environment configuration requirements

  • Establishing the logistics, lead times and build times to set up the environments

  • Defining a configuration baseline for the build environment, to ensure that each build is carried out in a known environment

  • Testing the build and related procedures

  • Scheduling the build and test activities

  • Assigning resources, roles, and responsibilities to perform key activities, for example, Security procedures and checks

  • Technical support Preparing build and test environments

  • Managing test databases and test data

  • Software asset and license management

  • Service asset and configuration management – configuration audit, build and baseline management

  • Defining and agreeing on the build exit and entry criteria.

So far we discussed RDM models, lifecycle stages, pass or fail criteria, considerations, deployment plans, build, and testing plans. In the next section, let us look at the different environments before productions.

Types of Environments Prior to Productions

Let’s discuss different types of the environment prior to productions. Various controlled environments will need to be built or made available for the different types and levels of testing as well as to support other transition activities such as training. Existing deployment processes and procedures can be used to build the controlled test environments. The environments will need to be secure to ensure that there is no unauthorized access and that any segregation of duty requirements are met.

The types of environments, both logical and physical, required during release and deployment management may include:

  • Build environments - Used to compile or assemble the release package or service assets.

  • Unit test environment - Used for verifying the functionality, performance, recovery and usability characteristics of an individual service component, e.g., online procedure.

  • Assembly test environment - Used for verifying the functionality, performance, recovery and usability characteristics of an assembly of service components.

  • Integration environment - For building and integrating service components.

  • System test environment - Used for testing all aspects of the integrated service architecture, including the application and technical infrastructure; substantial user acceptance testing is executed in this environment.

  • Service release test environment - Used to install, build and test a release package in a controlled environment; this is often combined with the system test environment.

  • Service operation readiness test environment - Used for testing the service and service unit capabilities before promotion into live; may include the service management acceptance test, some operational acceptance tests and user acceptance tests of the end-to-end service.

  • Business simulation environments - To enable testing of the service in the context of the business process it supports.

  • Performance/load/stress test environment - To enable testing of performance and throughput.

  • Service management simulation environments - To enable testing of service management activities such as logging and managing incidents, service requests, and changes.

  • Training environments - Sometimes this may include an established test database that can be used as a safe and realistic training environment.

  • Pilot environments - Including conference room pilots.

  • Backup and recovery environments - For example, disaster recovery.

In the next two sections, let us check out deployment planning of RDM process.

Deployment Planning

There are many planning considerations that need to be considered. Planners should be able to answer the questions included in Table in this and the next section. For better understanding, go through each deployment questions and relevant examples of these sections.

Deployment Question


What needs to be deployed?

  • Do you have a good understanding of the service and release that is being deployed?

  • What are the components that make up the release package?

  • What are the business drivers for the deployment?

  • Is it required to meet a critical business need?

Who are the users?

  • Which users are affected by the deployment?

  • What language do they use?

  • Do they need any special training?

Are there location dependencies?

  • Are there any holidays, shutdowns or other interruptions to normal business at this location?

  • What level of detail needs to be recorded, e.g., building, floor, room?

Where are the users?

  • Are all the users and systems local to the deployment, or are some remote, and how will this affect the logistics?

Who else needs to be prepared well in advance?

  • Do the service desk and support staff need training?

  • Are there any access issues to be solved –security or physical?

When does the deployment need to be completed?

  • Does the deployment need to be completed by a certain date and time or can it be completed by following a flexible schedule?

Why is the deployment happening?

  • Is the deployment needed to fix a problem or is it required for some new functionality that has been requested, and do the users understand what is coming?

What are the critical success factors and exit criteria?

  • How will you know that the deployment has been successful?

  • Who will authorize the deployment?

  • How will you know when the deployment is finished?

Let us now move to the next section to understand planning of pilots.


Planning of Pilots

Pilots are useful for testing the service with a small part of the user base before rolling it out to the whole service community. It is important to determine the appropriate scope of a pilot (how much of the service is to be included in the pilot, size of department or user base). This is a key step in establishing the pilot effort.

If the scope is too small, insufficient functionality and implementation variations will be tested, and the likelihood of significant errors not being discovered until full deployment is higher.

If the scope is too large, it will not deliver sufficient speed and flexibility to provide the expected benefits but will effectively be the first deployment.

A pilot can be used to establish the viability of most, if not all, aspects of the service. But this will only happen if all stakeholders are actively involved in the pilot and use the service as if it were part of a full deployment.

The pilot should include steps to collect feedback on the effectiveness of the release and of the deployment plan.

This can include:

  • Surveying views and satisfaction from:

  • End users

  • Customers

  • Suppliers

  • Service desk and other support staff

  • Service operation functions

  • Data and knowledge management – statistics on use and effectiveness

  • Analysing statistics from service desk calls, suppliers, capacity, and availability.

Commitment to support the pilot is required from all involved parties. Obtaining that commitment can be a challenge since pilots typically will represent additional work for those users involved over and above their day jobs. Collaboration with suppliers and support staff (who may have to support two versions of a service in parallel or deliver a small separate unit dedicated to supporting the pilot) must also be obtained.

Planning should accommodate rolling back a pilot. This will be required if there are significant failures during the pilot and may be needed to ensure that the pilot users have the correct baseline before the full deployment of an authorized new service.

Also, users who were part of the pilot should be working with the same components of service as other users after the full deployment, rather than the setup put in place for the pilot. If a decision is made not to roll back the pilot, it is essential to verify that pilot users have exactly the same final configuration as other users. This simplifies day-to-day operations in IT service management.

Although a pilot is often thought of as one trial in the live environment before rolling a service out across the full customer and user environment, there may be justification for a range of pilots, e.g., one for deployment to each geographical region. Many considerations are relevant, with the best solution for a given circumstance being a balance between benefit and cost.

Factors that influence the number of pilots include:

  • Speed and cost A single pilot will be cheaper and faster than multiple trials and will be the obvious choice for a homogeneous organization where a single pilot will encounter (almost) all eventualities and so provide a high degree of confidence that a successful pilot would be followed by a successful deployment across the wider organization.

  • Diverse organization In an organization with a range of circumstances across the user base, or with multiple operating environments, a matching range of pilots may be sensible, with a trial in each of the areas. These can be managed in parallel, with simultaneous trialing in each environment, which reduces elapsed time but increases management overheads and complexity. Alternatively, by running the pilots serially, lessons learned in one environment may be usefully applied to the subsequent pilots, since even in a diverse organization there is likely to be significant common ground, e.g., within the actual service components.

Examples of significant diversity include:

  • Different training methods needed for different groups

  • Technology

  • Language or culture

  • Network capability

  • Pilot options where alternative solutions are possible for a major deployment

It may be worth trying each of the options in a separate pilot (preferably in closely matched areas to make comparisons meaningful). Armed with the results from each pilot, a decision as to the approach for the main deployment can be taken based on solid empirical first-hand evidence. Political considerations Internal or external political issues may mean that a specific group or groups must be involved – or not involved – in a pilot for a new or changed service.

Let us now move on to the next section to understand the financial and commercial planning for release deployment.

Financial or Commercial planning

Financial and commercial aspects will need to be specifically checked before the deployment, and activities should be added to the deployment plans where necessary.

For example:

For an understanding of Working capital, we should assess whether sufficient funds available to deliver the customer expectations, e.g., to fund initial changes to gain emotional acceptance during the deployment?

For Contracts and licenses, we should assess whether do we have all necessary contract and license transfers been arranged?

For Funding, we should assess if the funding is available for the supporting systems to manage the service, e.g., CMS and related licenses?

For Intellectual property, we should assess if the full range of IP, its ongoing ownership and usage have been addressed, including:

Software developed by one of the parties

Documentation such as user manuals?

In the next section, let us look at the build and test key steps and techniques.

Release Build and Test: Key steps and techniques

During the release build and test stage, the common services and infrastructure need to be managed carefully, since they can significantly affect the build and test of a technology-enabled service and its underlying technology infrastructure.

Following are the key steps and techniques for release build and test stage:

Release and build documentation - Procedures, templates, and guidance should be used to enable the release team to take service assets and products from internal and external suppliers and build an integrated release package efficiently and effectively.

Acquire and test input configuration items and components - Configuration items and components (e.g., services, service assets) are acquired from projects, suppliers, partners and development groups. To prevent the acquisition of unknown and potentially risky components for a build, it is essential to use CIs that have achieved a certain quality level or components from a catalog of standard components that have been previously assessed, tested and authorized for use in specific conditions.

Otherwise, a request for change should be submitted to assess the component and either incorporate it into the standards catalog or accept it as a one-off exception for this release.

Release packaging - Build management procedures, methodologies, tools, and checklists should be applied to ensure that the release package is built in a standard, controlled and reproducible way in line with the solution design defined in the service design package. As a release package progresses towards live use, it may need to be rebuilt (for example, if a newer version of a CI or component needs to be incorporated quickly to fix errors or if the documentation needs to be updated).

Build and manage the test environments - Effective build and test environment management is essential to ensure that the builds and tests are executed in a repeatable and manageable manner. Inadequate control of these environments can result in unplanned changes compromising the testing activities and causing significant re-work.

Dedicated build environments should be established for assembling and building the components for controlled test and deployment environments.

Service testing and pilots - The testing activities are coordinated through test management, which plans and controls the testing execution as described in section. Testing aims to build confidence in the service capability before final acceptance during pilot or early life support. It will be based on the test strategy and model for the service being changed.

The test criteria reflect the anticipated conditions in which the service is expected to operate and deliver benefit. However, these surrounding circumstances may change, and in many modern situations, such change is almost inevitable and often unpredictable. These changes and their impact on service testing and acceptance must be observed, understood and documented.

Their consequences need to be expressed regarding changed acceptance criteria and updates to the service charter. This will need the collaboration and input of the business, customers, and other affected stakeholders, which may well include suppliers and operations. The service designer will be involved in making any amendments since this knowledge may assist in building in additional and relevant flexibility to designs of future new or changed services.

Service rehearsals - A service rehearsal (sometimes referred to as ‘model office’) is a simulation of as much of the service as possible in an extensive and widely participatory practice session. It is the ultimate stage of internal testing – the last stage before any live public running. This is like a ‘dress rehearsal’ of a play, setting out all the elements – costume, lighting, etc. – in a last private run-through of the performance.

It can deliver significant benefits by identifying errors and unworkable procedures before they impact the business in live operation. However, service rehearsals are complex, time-consuming and relatively expensive to prepare, deliver and document. A careful and deliberate balance is therefore required between the anticipated costs and the issues that they could prevent.

Pilots - Pursuing the theatrical analogy seen in service rehearsal if the service rehearsal is the ‘dress rehearsal’ – the last practice before being seen by the public – then the pilot is the ‘off-Broadway’ run of a play. It is done for real and in public, but for a small audience only and with the expectation of further (hopefully minor) polishing of the performance, script, scenery, and effects.

Conducting a pilot is easier to control as it is deployed to a smaller environment or user base. A pilot sets out to detect if any elements of the service do not deliver as required and to identify gaps and issues in service management that put the service and the customer’s business and assets at risk.

It does not need to cover all service and system functionality but will focus on the areas of risk and perform enough of the service to determine if it will work sufficiently well in deployment.

It aims to ensure that the service capability supports delivery of the service requirements and service level requirements. As far as possible it should check that the utilities are fit for purpose and the warranties are fit for use.

So far, we discussed the key steps and techniques, now let us look at the steps for planning and preparing deployment.

Planning and Preparing for Deployment

The planning and preparation activities prepare the group for deployment. This is an opportunity to prepare the organization and people for the organizational change. The overall approach to planning the deployment is described in release and deployment planning. During the actual deployment stage, the detailed implementation plan is developed.

This includes assigning individuals to specific activities. For example, a specific individual may be assigned to deliver training for a training activity on the deployment plan.

The entry criteria for planning and preparing a target deployment group or environment include:

  • Deployment stakeholders are sufficiently confident in the service release to deploy the release, own their aspects of deployment, and are committed to the deployment

  • Senior management, customers, the business, and service provider teams accept the deployment costs, management, organization and people implications of the release as well as any organization, function, and process changes.

Let us take an example to understand the activities involved in this process.

Example of a set of deployment activities

An example of the deployment activities that apply to the deployment of a target group is shown in the figure below.

Example of Deployment Activities

Preparing for deployment includes assessing each deployment group’s readiness to receive and implement a release package, identifying gaps that need to be filled and planning the activities required to deploy, transfer or decommission,/ retire services or service assets.

It may also include transferring a service or a service unit within an organization or between organizations, as well as moving and disposal activities.

Next, let us look understand how to assess the readiness of target group during deployment.

Deployment: Assess readiness of target group

Although the deployment assessment should be conducted early, it should be revisited periodically. The results of this assessment are fed into detailed implementation planning for the target deployment group. The readiness assessment for a deployment group includes:

  • Financial aspects and assets

  • Issues and risks in delivering the current services that may affect the deployment

  • Applicable health, safety, security and environmental regulations, supplier and procurement aspects.

  • The current capability of the business customers and users to use and gain value from the new or changed service

  • Current service, service capability and resources used

  • Current Service Management capability and resources

  • Identifying requirements to tailor the new or changed service or underlying solution

  • Organizational readiness

  • Aspects relating to applications, information and data Infrastructure, and facilities

Let us now move to the next section on developing deployment plans.

Deployment: Develop plans

Here, let us discuss the steps required for developing a plan for deployment.

Firstly, planning for a specific deployment includes assigning specific resources to perform deployment and early life support activities. The activities include:

  • Risk mitigation plans, developing transfer /transition, upgrade, conversion, disposal, retirement plans

  • Logistics and delivery planning

  • Tailoring processes, procedures, and knowledge

  • Knowledge transfer and training stakeholders in how to use, benefit, manage, support and operate the new or changed service

  • Communicating with the people involved

  • Making any changes in an emergency of continuity plans and procedures

  • Mobilizing the Service Operations and support organization

  • Mobilizing users to be ready to use the service

  • Additional activities identified from the assessment

The next step is to verify the detailed deployment plans, perform any deployment readiness tests, and raise an RFC to be authorized through the Change Management process. The service is then ready for deployment.

Moving ahead, let us understand the different activities involved during deployment.

Deployment: Perform Transfer, Deployment, and Retirement

This section provides the different activities such as transfer, deployment, and retirement. In the subsequent sections, we will get into the details of each of these activities.

The following activities provide an example of the different aspects that will be performed in the order specified in the deployment plan:

  1. Change/transfer financial assets

  2. Transfer/transition business and organization

  3. Deploy processes and materials

  4. Deploy service management capability

  5. Transfer service

  6. Deploy service

  7. Decommissioning and service retirement

  8. Remove redundant assets

  9. Remediate/back out the release

Let us look at the first activity, which is Transfer.

Perform Transfer, Deployment, and Retirement - Transfer Financial Assets

Changes and transfers of financial assets need to be completed as part of the deployment. This will include but is not constrained by the following:

  • Any changes in supplier financial agreements and charges

  • Purchase or transfer of annual support and maintenance costs including systems to manage the service, e.g.,CMS

  • New license costs and renewals

  • Annual disaster recovery contracts with third parties

  • Provision or transfer of working capital

  • Transfer of intellectual property

Let us move on to discuss transfer/transition business and organization in the next section.

Perform Transfer, Deployment, and Retirement - Transfer/Transition Business and Organization

Transfer of a business unit, service or service unit will involve a change in the organization itself. Activities that need to be performed include:

  • Finalize organization structure, roles, and responsibilities.

  • Communicate change in organization, roles and responsibilities.

  • Ensure that people adapt to and adopt new practices. This requires good communication of the consequences and requirements of the deployed service, e.g., best use of resources to deliver the message; understanding personal and group concerns; and ensuring messages to diverse and related groups are consistent and appropriate.

  • Engender, at the very least, acceptance and preferably active support of the changes imposed on people.

  • Ensure that people understand the continuity plans and procedures.

Let us proceed to the next activity which is Deploy process.

Perform Transfer, Deployment, and Retirement - Deploy Processes and Materials

Deploy or publish the processes and materials ready for people involved in the business and service organization change, e.g., users and Service Operations teams that need to execute the new or changed processes.

The materials may include policies, processes, procedures, manuals, overviews, training products, organizational change products, etc. Training people to use new processes and procedures can take time, particularly for a global deployment to consisting thousands of people.

In the next section, let us look at deploy service management capability.

Perform Transfer, Deployment, and Retirement - Deploy Service Management Capability

Deploy new or changed processes, systems, and tools to the service provider teams responsible for Service Management activities. Check that everyone is competent and confident to operate, maintain and manage the service by the service model and processes.

Remove or archive unnecessary services and assets, e.g., processes, procedures, and tools. During deployment monitor the service against the service model and performance standards as far as possible. Let us proceed to understand transfer service in the next section.

Perform Transfer, Deployment, and Retirement - Transfer service

Transferring a service will also involve organizational change described earlier in this section. The issues around transferring a service and the activities that need to be performed include:

  • Reviewing the service performance, issues, and risks, by performing some service tests and a service evaluation prior to the transfer

  • Configuration auditing of service assets and configurations

  • Finalizing service catalog (add or remove the service) and related information

  • Sending a service notification to communicate the change to relevant stakeholders.

When the change includes a transfer of service provider, e.g., new outsourcing, insourcing, change of outsourced provider, then and some specific elements need to be considered that include:

  • Managing contract changes

  • Managing changes to existing agreements

  • Updating contract details and information in the SKMS

  • Transferring ownership of service assets and configuration items, remembering to update the CMS.

In the next section, let us understand the deploy service.

Perform Transfer, Deployment, and Retirement - Deploy service

Deploy the service release and carry out the activities to distribute and install the service, supporting services, applications, data, information, infrastructure, and facilities. These will include:

  • Distributing and delivering the service and service components at the correct location and time

  • Building, installing and configuring the services and service components with any converted or new data and information

  • Testing the system and services according to the installation and acceptance tests and producing the installation and test reports

  • Recording any incidents, unexpected events, issues or deviations from the plans

  • Correcting any deviations that are outside the design limitations and constraints.

So far we have discussed the transfer and deployment activities, let us now look at decommissioning and service retirement in the next section.

Perform Transfer, Deployment and Retirement - Decommissioning and Service Retirement

Some specific aspects need to be considered for decommissioning and retiring services and service assets. For example, the procedures for retiring, transferring (e.g.,to another budget holder) or redeploying service assets need to take into account any security, confidentiality, licensing, environmental, or other contractual requirements. This includes:

  • Removing deployed copies of software and data from retired hardware; failure to do this may result in license contravention or in staff using unsupported software

  • Identifying licenses and other assets which can be redeployed; software being retired from use in one area may well remain in active use elsewhere

  • Disposing of equipment according to environmental policies and procedures

  • Updating or archiving processes, procedures, standards, documentation and any other data or information in the SKMS that

  • were used to support the retired service

  • Updating records in the CMS

  • Moving assets that can be redeployed to secure

  • storage areas if required.

  • Records of retirement, transfer, and disposal should be maintained and used to update other information such as license information

Let us now look at activities to remove redundant assets.

Perform Transfer, Deployment, and Retirement - Remove redundant assets

To remove redundant assets, a comprehensive understanding of the assets used by a retired service needs to be gained and managed. With a full understanding, any redundant assets can be identified and removed, therefore potentially saving license fees, liberating capacity and preventing accidental use. Failure to develop and properly perform these activities can result in:

  • Wasted disk space and licenses

  • Overpayment of license and maintenance fees

  • Removal of assets associated with the redundant service but also used by other services, therefore causing incidents within those services, e.g.,common software components and network elements.

Next, let us understand the remediate and back out the release.

Perform Transfer, Deployment, and Retirement - Remediate/back out the release

A decision may be made to remediate the release because:

  • A documented milestone is not met during the deployment

  • A deployment step fails or behaves in an unexpected manner

  • Verification shows that the deployment has not succeeded.

So far we discussed the activities involved in the deployment of release. In the next section, let us look at verifying deployment on completion of the activities.

Verify Deployment

When the deployment activities are complete, it is important to verify that users, Service Operations, other staff, and stakeholders are capable of using or operating the service.

The tests should specifically verify that:

  • The service, service assets and service capability/resources are in place, e.g.,by performing an audit such as a configuration audit of the deployed baseline against the as-planned baseline

  • Updates to documentation and information are completed, e.g.,service catalog, contracts, agreements, contact details

  • Communications, orientation and learning materials are ready to distribute to stakeholders, Service Operations, and users

  • All roles are assigned to individuals/organizations

  • People and other resources are prepared to operate and use the new or changed service or service capability in normal, emergency and disaster situations

  • People have access to the information necessary to use, operate or support the service

  • The measurement and reporting systems are established to measure the performance of the service and underlying resources.

This is a good point to gather feedback on the deployment process to feed into future improvements, e.g., using satisfaction surveys. Report any issues and incidents and take corrective actions as necessary. Successful confirmation of the deployment verification triggers the initiation and launch of early life support for the deployment group.

Let us now move on to discuss early life support in the next few sections.

Early Life Support

Early life support (ELS) provides the opportunity to transition the new or changed service to Service Operations in a controlled manner and establish the new service capability and resources. An example of the ELS activities is shown in the next section.

In Service Design, the stakeholders will have agreed with the entry and exit criteria from early life support, but it may be necessary to finalize the performance targets and exit criteria early in this stage. This can help to understand the deployment verification process and set customer and stakeholder expectations about the handover of the service to Service Operations.

ELS provides appropriate resources to resolve operational and support issues quickly, centrally and locally, to ensure that the users can use the service to support their business activities without unwarranted disruption.

The deployment teams should analyze where users and support resources will experience issues and problems, perhaps based on previous experience; for example, clarification about:

  • Role assignments, roles, and responsibilities

  • Financial and funding arrangements

  • Procurement and request fulfillment

  • Security policies and procedures

  • Raising incidents and change requests

  • Escalation procedures

  • Complaints procedure

  • Using diagnostics tools and aids

  • Software licensing rules.

During ELS, the deployment team implements improvements and resolves problems that help to stabilize the service. The Continual Service Improvement publication provides relevant information on measurement and service improvements. The deployment resources will gradually back out from providing the additional support as the users and service teams become familiar with the changes and the incidents and risks reduce.

Metrics for the target deployment group or environment measure service performance, the performance of the Service Management and operations processes and teams and the number of incidents and problems by type. The deployment team aims to stabilize the service for the target deployment group or environment as quickly and effectively as possible.

Let’s look at an example in the next section.

Example of Early Life Support Activities

The image below shows an example of ELS as described in the last section.

Example of Early Life Support Activities

Early life support (ELS) provides the opportunity to transition the new or changed service to service operation in a controlled manner and establish the new service capability and resources. The formal handover of the new or changed service to the service operation functions happens in two stages.

At the beginning of early life support, there should be a formal notification that the service is now in live use. At the end of early life support, there should be a formal notification that all SLAs are now being enforced and the service is fully operational.

Moving on, let us look at another illustration of the benefits of early life support.

Illustration of the benefits of targeted early life support

Variation in performance between different deployment groups and service units should be analyzed, and lessons learned from one deployment used to improve subsequent deployments.

Benefits of Early Life Support

The example depicted in the figure above shows the number of incidents for two branches of a retail organization that have the same number of users and the same deployment schedule. In “deployment A” the incident levels have reduced faster.

On further investigation, the Service Transition manager discovered that the team responsible for “Deployment A” was more competent at training users and transferring knowledge to the service desk so that they could help users to be more effective more quickly.

During ELS, the deployment team should ensure that the documentation and knowledge base is updated with additional diagnostics, known errors, workarounds and frequently asked questions. The team should also resolve any knowledge transfer or training gaps. At agreed milestones in early life support, it is important to assess the issues and risks, particularly those that impact the handover schedule and costs.

Service Transition monitors the performance of the new or changed service in early life support until the exit criteria are achieved.

These include when:

  • Users can use the service effectively and efficiently for their business activities

  • Service owners and process owners are committed to manage and operate the service in accordance with the service model, performance standards, and processes

  • Service delivery is managed and controlled across any service provider interfaces Consistent progress is being made towards delivering the expected benefits and value at each milestone in early life support

  • Service levels and service performance standards are being consistently achieved without unexpected variation before formal handover to Service Operations

  • SLAs are finalized and signed off by senior management and customers

  • Unexpected variations in the performance of the service and customer assets such as changes in residual risks are monitored, reported and managed appropriately

  • Checking that training and knowledge transfer activities are completed by obtaining positive confirmation from the target audience. This may be in the form of competency tests

  • The service release, the SLA, other agreements and any contractual deliverables are signed off.

Let us now understand the activities involved in review and close of the deployment process.

Review and Close a Deployment Activities to Include

When reviewing a deployment, the following activities should be included:

  • Capture experiences and feedback from the customer, user, and service provider satisfaction with the deployment, e.g., through feedback surveys.

  • Highlight quality criteria that were not met.

  • Check that any actions, necessary fixes, and changes are complete.

  • Review open changes and ensure that funding and responsibility for open changes are agreed before the handover.

  • Review performance targets and achievements, including resource use and capacities such as user accesses, transactions, and data volumes.

  • Make sure there are no capability, resource, capacity or performance issues at the end of the deployment.

  • Check that any problems, known errors and workarounds are documented and accepted by the customers/business and suppliers.

  • Review the Risk Log and identify those that impact Service Operations and support. Address risks or agree on an action such as moving the risks to the Service Transition Risk Log.

  • Check that redundant assets have been removed.

  • Check that the service is ready for the transition from early life support into Service Operations.

Each deployment should consider whether any relevant issues have been detected that should be passed through to CSI, such as:

  • Feedback on the deployment model and plan

  • Errors in procedures detected

  • ‘Near misses’ where things could have gone wrong in foreseeable circumstances or where intervention was required

  • Incorrect data or information in relevant records

  • Incident and problems caused by deployment

  • Problems with updating records. Deployment is completed with a handover of the support for the deployment group or target environment to Service Operations.

  • A post-implementation review of deployment is conducted through Change Management.

In the next section, let us look at the triggers of the RDM process.

Release and Deployment Management: Process Triggers

Triggers for Release management would be - Receipt of an authorized change to plan, build and test a production-ready release package

Triggers for Deployment management would be - Receipt of an authorized change to deploy a release package to a target deployment group or the environment, e.g., business unit, customer group, and service unit.

Like any other process, let us now look at the inputs and outputs of this process in the next section.

Preparing for a career in ITIL Intermediate RCV? Check out our Course Preview here!

Release and Deployment Management : Process Inputs and Outputs

The inputs and outputs of the RDM process are discussed below:

First, the inputs of the process can be:

  • Authorized RFC

  • Service package, SLP

  • 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 catalogs

  • 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.

The outputs are for the process can be:

  • Release and deployment plan

  • Completed RFCs for the release and deployment activities

  • Service Notification

  • Updated service catalog with 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

  • SLA and depending OLAs and contracts

  • The 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 configuration item list within audit trial for the CIs and the release package

  • the new or changed service and infrastructure configuration

  • service capacity plan that is aligned to the relevant business plans

  • deployment ready release package baselined feature deployments

  • service transition reports.

Deployment is completed with the handover of the new or changed service, operations on successful completion of the post-implementation review of the deployment conducted within change management.

Let us proceed to learn about the interfaces of RDM process.

Release & Deployment Management: Interfaces

Let us discuss the interfaces of Release and Deployment Management one by one:

Service design coordination

  • The SDP is a major input to release and deployment management.

  • Release and deployment management also has a significant role to play in the production of the SDP.

  • Plans and packages should be developed and documented during the service design stage of the service lifecycle, and service design coordination will ensure that these are documented in the SDP.

Transition planning and support

  • Transition planning and support provides the framework for release and deployment management to operate in, and transition plans provide the context for release and deployment plans.

Change Management

  • Change management provides the authorization for the work that is carried out by release and deployment management, and release and deployment management provides the actual execution of many changes.

  • Release and deployment plans are a significant part of the change schedule, and these must be managed together.

Service Asset and Configuration management

  • Release and deployment management depends on data and information in the CMS and provides many updates to the CMS. It is important that these updates are coordinated and managed properly as otherwise the data will not be kept up to date.

Service validation and testing

  • Release and deployment management must coordinate with service validation and testing, to ensure that testing is carried out when necessary, and that builds are available when required by service validation and testing.

Like any other process information management is very essential for the RDM process. Let us look at the details on this in the next section.

Release & Deployment Management : Information Management

The Information Management emphasizes that:

Throughout the deployment process, appropriate records will be created and maintained.

As configuration items are successfully deployed, the CMS will be updated with information such as:

  • 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

Other data and information will also be captured and recorded within the board of service knowledge management system. This could include deployment information, history of the deployment itself, who is involved, timing, etc.

Known errors typically a new or changed service will be introduced with identified errors which were 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 or may be considered acceptable.

Now in the next few sections, we will discuss the critical success factors of the RDM process.

Release & Deployment CSFs And KPIs

The following table includes some sample CSFs for RDM process. Each organization should identify appropriate CSFs based on its objectives for the process. Each sample CSF is followed by a small number - a typical KPI that support the CSF. These KPI should not be adopted without careful consideration. Each organization should develop KPIs that are appropriate for its level of maturity in CSFs and its particular circumstances.

Achievement against KPIs should be monitored and used to identify opportunities for improvement which should be logged into the continue service improvement CSI registered for evaluation and possible implementation.



Defining and agreeing to the release plans with customers and stakeholders

  • Increased number and percentage of releases that make use of a common framework of standards, re-usable processes and supporting documentation

  • Increased number and percentage of releases that meet customer expectations for cost, time and quality

Ensuring integrity of a release package and its constituent components throughout the transition activities

  • Reduced number of CMS and DML audit failures related to releases

  • Reduced number of deployments from sources other than the DML

  • Reduced number of incidents due to incorrect components being deployed

Ensuring that the new or changed service is capable of delivering the agreed utility and warranty

  • Reduced variance from service performance required by customers

  • Number of incidents against the service (low and reducing)

  • Increased customer and user satisfaction with the services delivered

  • Decreased customer dissatisfaction –service issues resulting from poorly tested or untested services increase the negative perception of the service provider organization as a whole

  • Reduced resources and costs to diagnose and fix incidents and problems in deployment and live use

Ensuring that there is appropriate knowledge transfer

  • Reduced number of incidents categorized as ‘user knowledge’

  • Increased percentage of incidents solved by level 1 and level 2 support

  • Increased score in surveys of the customer, user, and service operation function satisfaction with release and deployment management

Let us now discuss the risks and challenges involved in

Risks & Challenges

The challenges for release and deployment include:

  • Developing standard performance measures and measurement methods across projects and suppliers

  • Dealing with projects and suppliers where estimated delivery dates are inaccurate, and there are delays in scheduling service transition activities

  • Understanding the different stakeholder perspectives that underpin effective risk management for the change impact assessment and test activities

  • Building a thorough understanding of risks that have impacted or may impact successful service transition of services and release

  • Encouraging a risk management culture where people share information and take a pragmatic and measured approach to risk.

The risks to successful release and deployment include:

  • Poorly defined scope and understanding of dependencies in early lifecycle stages leading to scope creep during release and deployment

  • Using staff that are not dedicated to release and deployment activities, especially if the effort is a significant amount of their time

  • Management incompetence

  • Inadequate corporate policies - For ex. Security and software licensing

  • Inadequate adoption of management practices

  • Shortage of finances - Delays move deployment into different financial year

  • Lack of clarity on funding for changes, fixes during the transition

  • Lack of definition of the required controls lead to poorly evaluated and unauthorized changes adversely affecting release and deployment plans.

  • Difficulty tracking and managing software licenses

  • Unexpected or changes in regularity, controls, or licensing requirement

  • Management of organizational change.

In the next section, let us discuss the typical RDM activities performed on a daily basis by Service Operation.

Typical RDM activities performed on a daily basis by Service Operation

Release and Deployment Management is covered primarily in ITIL Service Transition, but there are some aspects that service operation staff would be involved in, on a day to day basis. These may include:

  • Actual implementation actions regarding the deployment of new releases, under the direction of release and deployment management, where they relate to service operation components or services.

  • Participation in the planning stages of major new releases to advise on service operation issues

  • The physical handling of CIs from/to the definitive media library (DML) as required to fulfill their operational roles –while adhering to relevant release and deployment management procedures, such as ensuring that all items are properly booked out and back in.

  • Participation in activities to back out unsuccessful releases when these occur.

Let us quickly summarise this module in the next section.


Let us now quickly recap on this lesson. In this module we looked at:

  • The purpose of Release and Deployment Management is to plan, schedule and control the build, test, and deployment of releases, and to deliver the new functionality required by the business while protecting the integrity of existing services

  • A well-planned and implemented release and deployment will make a significant difference to an organization’s service costs

  • The following activities provide an example of the different aspects that will be performed in the order specified on the deployment plan: transfer financial assets, transfer /transition business, and organization, deploy processes and materials, deploy Service Management capability, transfer service, deploy service, decommissioning and service retirement, and remove redundant assets

  • Deployment is completed with a handover of the support for the deployment group or target environment to Service Operations; a post-implementation review of deployment is conducted through Change Management

The next lesson talks about Request Fulfillment.

  • Disclaimer
  • PMP, PMI, PMBOK, CAPM, PgMP, PfMP, ACP, PBA, RMP, SP, and OPM3 are registered marks of the Project Management Institute, Inc.

Request more information

For individuals
For business
Phone Number*
Your Message (Optional)
We are looking into your query.
Our consultants will get in touch with you soon.

A Simplilearn representative will get back to you in one business day.

First Name*
Last Name*
Work Email*
Phone Number*
Job Title*