Release and Deployment Management Tutorial

5.1 Learning Unit 5

This learning unit covers how the release and deployment management (RDM) process contributes to RCV practices. It provides a complete overview of the purpose, objectives, scope and importance of release and deployment management as a process to generate business value. Release and deployment management policies, principles, concepts, activities, methods and techniques are explained in relationship to RCV practices. The concept of the release unit is explained, along with RDM planning, release build and test, pilots, deployment, logistics, delivery, retirement, risks and financials. Efficient use of RDM critical success factors and key performance indicators are reviewed. In the next two slides let us learn about the purpose, objectives and scope of the RDM process.

5.2 Purpose 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 new functionality required by the business while protecting the integrity of existing services. The objective is to: • Define and agree 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/or 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. The objective of Release and Deployment Management is 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 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.

5.3 Objectives and Scope of Release and Deployment Management

The objective of Release and Deployment Management is 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 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. 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 business.

5.4 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 across 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 slide we will discuss about the policies of this process.

5.5 Release and Deployment Policies

Now lets discuss the policies for the release and deployment process. 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 let us look at release unit and its identification.

5.6 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 slide.

5.7 Simplified example of Release Units for an IT service

Here is an example of the release unit in the IT service. The Figure in the slide gives a simplified example showing an IT service made up of systems and service asses, which are in turn made up of service components. As we have an understanding of release unit, let us move to the next slide to learn about designing release and release packages.

5.8 Designing Release and Release Packages

For designing release and release package, the policies given here needs to be considered for the same: 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 slide let us study the architecture elements to be built and tested in the RDM process.

5.9 Architecture elements to be built and tested

The Figure in on the slide 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 slide.

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

5.11 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. 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 slide we will learn about release design options and their considerations.

5.12 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 slide.

5.13 Option for 'Big Bang'and phased deployment

The Figure on this slide 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 slide, let us look at phased deployment illustration.

5.14 Phased deployment across geographical locations

The Figure in the slide illustrates phased deployment to a number of 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 slide let us understand release design options.

5.15 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 centre and pushed out to the target locations. In terms of service deployment, delivering updated service components to all users – either in bigbang or phased form – constitutes ‘push’, since the new or changed service is delivered into the users’ environment at a time not of their choosing. A pull approach is used for software releases where the software is made available in a central location but users are free to pull the software down to their own location at a time of their choosing or when a user workstation restarts. The use of ‘pull’ updating a release over the internet has made this concept significantly more pervasiveprevalent. 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 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 slide we will look at automation and manual approaches.

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

5.17 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 slide let us look at the considerations of release and deployment models.

5.18 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,/ re-deploy, /remove or /retire software licences • 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 slide.

5.19 Phases of Release and Deployment management

Release and deployment management lifecycle consists of the following phases • Release and deployment planning g • Release build and test • Deployment • Review and close Let us discuss about 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. Deployment - 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 slide.

5.20 Phases of Release and Deployment management

The Figure shows multiple points where an authorized change triggers release and 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 slide let us understand the release and deployment plans.

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

5.22 Pass or Fail criteria

Service transition is responsible for planning the pass/ or 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 slide we will discuss about the build and test planning of the RDM process.

5.23 Build and Test Planning

Build and test planning Build and test planning establishes the approach to building, testing and maintaining the controlled environments prior to 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 licence management Service asset and configuration management – configuration audit, build and baseline management Defining and agreeing the build exit and entry criteria. So far we discussed about RDM models, lifecycle stages, pass or fail criteria, considerations , deployment plans , build and testing plans. In the next slide let us look at the different environments prior to productions.

5.24 Types of Environments Prior to Productions

LetsLet’s discuss different types of 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 slide let us check out deployment planning of RDM process.

5.25 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 slide. For better understanding, go through each deployment questions and relevant examples on these slides.

5.26 Deployment Planning

The last slide and the current slide must have helped you in understanding the planning considerations. Let us now move to the next slide to understand planning of pilots.

5.27 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 a 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 from 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 pilot users have the correct baseline before the full deployment of an authorized new service. In addition, users who were part of the pilot should be working with the same components of a 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 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 trialling 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 Wwhere 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 empiricalfirst-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 slide to understand the financial and commercial planning for release deployment.

5.28 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 licences we should assess whether do we have all necessary contract and licence transfers been arranged? Is funding available for the supporting systems to manage the service, e.g. CMS and related licences? Intellectual property Has the full range of IP, its ongoing ownership and usage been addressed, including: Software developed by one of the parties Documentation such as user manuals? In the next slide let us look at the build and test key steps and techniques.

5.29 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 catalogue 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 catalogue 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/or 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 prior to 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 in terms of 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 public live 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/ or 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 about the key steps and techniques, now let us look at the steps for planning and preparing deployment.

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

5.31 Example of a set of deployment activities

An example of the deployment activities that apply to the deployment for a target group is shown in the Figure. 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.

5.32 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. 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 slide on developing deployment plans.

5.33 Deployment : Develop plans

Here lets discuss on the steps required for developing 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 to the people involved Making any changes in 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.

5.34 Deployment : Perform Transfer, Deployment and Retirement

This slide provides the different activities such as transfer , deployment and retirement. In the Subsequesnt slides 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 on the deployment plan. Let us look at the first activity which is Transfer, in the next slide.

5.35 Perform Transfer, Deployment and Retirement

In this slide we will disucss about Transfer financial assets Changes and transfers of financial assets need to be completed as part of 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 licence 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 about transfer/transition business and organization in the next slide.

5.36 Perform Transfer, Deployment and Retirement

Transfer of a business unit, service or service unit will involve change to 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.

5.37 Perform Transfer, Deployment and Retirement

Under the deploy activity, let us discuss about Deploy processes and materials in this slide. 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 slide let us look at deploy service management capability.

5.38 Perform Transfer, Deployment and Retirement

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 in accordance with the service model and processes. Remove or archive redundant 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 undersand transfer service in the next slide.

5.39 Perform Transfer, Deployment and Retirement

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 catalogue (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 slide let us understand the deploy service.

5.40 Perform Transfer, Deployment and Retirement

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 on the transfer and deployment activities, let us now look at ahd decommissioning and service retirement in the next slide.

5.41 Perform Transfer, Deployment and 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. Let us now look at activities to remove redundant assets.

5.42 Perform Transfer, Deployment and Retirement

To Rremove redundant assets, Aa 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 licence fees, liberating capacity and preventing accidental use. Failure to develop and properly perform these activities can result in: • Wasted disk space and licences • Overpayment of licence 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 release.

5.43 Perform Transfer, Deployment and Retirement

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 about the activities involved in deployment of release, in the next slide let us look at verifying deployment on completion of the activities.

5.44 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 catalogue, 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 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 about early life support in the next few slides.

5.45 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 slide. In Service Design, the stakeholders will have agreed 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 analyse 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 fulfilment • 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, performance of the Service Management and operations processes and teams and the number of incidents and problems by type. The deployment team’s aim is 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 slide.

5.46 Example of early life support activities

This shows an example of ELS as described in the last slide. 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. 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 on early life support.

5.47 Illustration of the benefits of targeted early life support

Variation in performance between different deployment groups and service units should be analysed and lessons learned from one deployment used to improve subsequent deployments. The example shown in the figure 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 are 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 deployment process.

5.48 Review and Close a Deployment Activities to Include

When reviewing a deployment the following activities should be included: • Capture experiences and feedback on 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 handover. • Review performance targets and achievements, including resource use and capacity 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/or suppliers. • Review the Risk Log and identify those that impact Service Operations and support. Address risks or agree 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 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 a deployment is conducted through Change Management. In the next slide let us look at the triggers of the RDM process.

5.49 Release and Deployment Management :Process Triggers

•Triggers for Deployment management would be Receipt of an authorized change to deploy a release package to a target deployment group or environment, e.g. business unit, customer group and/or service unit. Like any other process let us now look at the inputs and outputs of this process in the next slide.

5.50 Release and Deployment Management :Process Inputs and Outputs

The inputs are:and outputs of the RDM process are as follows, 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 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. The outputs are for the process can be: • Release and deployment plan • Completed RFCs for the

  • 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*
Phone Number*
Job Title*