Service Transition

4. Service Transition Processes

4.1PLAN/SUPPORT

4.2CHANGE

4.3ASSET/CONFIG

4.4RELEASE/DEPLOY

4.5 VALIDATE/TEST

4.6EVALUATE

4.7KNOWLEDGE

4.4 Release and Deployment Management

4.4.1 Purpose, Goal and Objective

• 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 (see section 5).
•  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 goal of Release and Deployment Management is to deploy releases into production and establish effective use of the service in order to deliver value to the customer and be able to handover to service operations.

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.

4.4.2 Scope

4.4.3 Value To Business

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

4.4.4 Policies, Principles and Basic Concepts

4.4.4.1 Release Unit and Identification

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 as discussed in section 4.1.4.2. 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.

4.4.4.2 Release Design Options and Considerations

Figure 4.15 Simplified example of release units for an IT service

Common options for release and deployment that are considered in Service Design are discussed below. The selected option will have a significant impact on the release and deployment resources as well as the business outcomes. It is important to understand the patterns of business activity (PBA) and user profiles when planning and designing the releases.

'Big Bang' Vs Phased
Options for deploying new releases to multiple locations are illustrated in Figure 4.16 and described below:

Figure 4.16 Options for 'Big Bang' and Phased rollout

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

Figure 4.16 also illustrates a possible sequence of events over time as follows:

• There is an initial launch of the 'Release 1' of the system to three workstations (1-3).
• Two further workstations (4+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-5) at once.
• Two further workstations (6+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-3) and then the remaining four (4-7).
• A further workstation (8) is then added to the system.

Variations of the phased approach include:

• Portions of the service are delivered to the live environment in phases, but all end users are affected simultaneously (e.g. incremental changes to a shared application).
• Each release is deployed gradually across the total population of end users (e.g. one geographical location at a time).
• Different types of service element are deployed in separate phases, e.g. hardware changes are first, followed by user training and then by the new or changed software.
• A combination of all of these approaches is usually adopted, and the plans may deliberately allow for variations in the light of actual deployment experience.

In the type of phased implementation illustrated above, it is only possible to employ this approach if the service has been designed to allow new and old versions to coexist. If this is not possible then the only alternative is to upgrade all affected parts together in a 'big bang' implementation. For elements such as documentation, for skilled staff this is rarely a problem; for many instances of hardware and software it is possible. For other transitions, such as those involving major network changes, it can be virtually impossible to achieve.

Figure 4.17 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 pilot 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 in the live environment concurrently.

Push and Pull
A push approach is used where the service component is deployed from the centre and pushed out to the target locations. In terms of service deployment, delivering updated service components to all users - either in 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 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.

Automation vs Manual
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.

Figure 4.17 Phased deployment across geographical locations

Many of the release and deployment activities are capable of a degree of automation. For example:

• Discovery tools aid release planning.
• Discovery and installation software can check whether the required prerequisites and co-requisites are in place before installation of new or changed software components.
• Automated builds can significantly reduce build and recovery times that in turn can resolve scheduling conflicts and delays.
• Automated configuration baseline procedures save time and reduce errors in capturing the status of configurations and releases during build, test and deployment.
• Automatic comparisons of the actual 'live' configuration with the expected configuration or CMS help to identify issues at the earliest opportunity that could cause incidents and delays during deployment.
• Automated processes to load and update data to the CMS help to ensure the records are accurate and complete.
• Installation procedures automatically update user and licence information in the CMS.

Designing Release and Release Packages
Figure 4.18 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.

Figure 4.18 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.

Figure 4.18 Architecture elements to be built and tested

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/website.

Figure 4.19 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 Figure 4.19.

The example in Figure 4.19 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.

Valuable Release Windows

Figure 4.20 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 Figure 4.20. 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.

4.4.4.3 Release and Deployment Models

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.

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 audit procedures where appropriate to reduce costly manual steps
• Manage and deploy/re-deploy/remove/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.

4.4.5 Process Activities, Methods and Techniques

4.4.5.1 Planning

Release and deployment plans should be authorized through Change Management. They should define the:

• Scope and content of the release
• Risk assessment and risk profile for the release
• Organizations and stakeholders affected by the release
• Stakeholders that approved the change request for the release and/or deployment
• Team responsible for the release
• Approach to working with stakeholders and deployment groups to determine the: 0 Delivery and deployment strategy
• Resources for the release and deployment
• Amount of change that can be absorbed.

Pass/Fail Criteria
Service Transition is responsible for planning the pass/fail situations. At a minimum these should be defined for each authorization point through the release and deployment stage. 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 and RFC for build and test are signed off.

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 and expensive; testing identifies that there will not be enough money to deliver the proposed design in the operations phase.
• 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%.

Build and test prior to production
Build and test planning establishes the approach to building, testing and maintaining the controlled environments prior to production. 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
• Testing the build and related procedures
• Scheduling the build and test activities
• Assigning resources, roles and responsibilities to perform key activities, e.g.:
• Security procedures and checks
• Technical support
• Preparing build and test environments
• Managing test databases and test data
• Software asset and licence management
• Configuration Management - configuration audit, build and baseline management
• Defining and agreeing the build exit and entry criteria.

Figure 4.21 provides an example of a model that can be used to represent the different configuration levels to be built and tested to deliver a service capability. The lefthand side represents the specification of the service requirements down to the detailed Service Design. The right-hand side focuses on the validation and test activities that are performed against the specifications defined on the left-hand side. At each stage on the left-hand side, there is direct involvement by the equivalent party on the right-hand side. It shows that service validation and acceptance test planning should start with the definition of the service requirements. For example, customers who sign off the agreed service requirements will also sign off the service Acceptance Criteria and test plan.

Figure 4.21 Service V-model to represent configuration levels and testing

The V-model approach is traditionally associated with the waterfall lifecycle, but is, in fact, just as applicable to other lifecycles, including iterative lifecycles, such as prototyping, RAD approaches. Within each cycle of the iterative development, the V-model concepts of establishing acceptance requirements against the requirements and design can apply, with each iterative design being considered for the degree of integrity and competence that would justify release to the customer for trial and assessment.

Level	Requirements and Design	Build/Deliverable	Validation and Testing
Level 1 Customer/Business Needs	Structured definition of contract requirements	Customer contract (based on Service Portfolio, SLP)	Service Test and Evaluation Determines whether a service can enable the users and customers to use the service to support their business needs (is fit for purpose and fit for use).
Level 2 Service Requirements	Service requirement specifications and SAC, traceable back to the contract requirements	Service capability and resources to deliver against the SLA and service requirements	Service Test Test the Service Acceptance Criteria are met. Includes validation of service performance against the service level requirements and SLA in pilots, deployment and early life support.
Level 3 Service Solution	SDP, Service model, service environments	Solution/system required to deliver service capability; includes the Service Management and Service Operations capabilities	Service Operational Readiness Test To evaluate the integration and operation of the service capability and resources. It verifies that the target deployment organization and people are prepared to deploy and operate the new or changed service in the live environment, e.g. deployment systems and team, Service Operations, customers, users and other stakeholders. Tests include scenario-based testing such as simulation and service rehearsal.
Level 4 Service Release		Release package	Service Release Test A test that the service components can be integrated correctly and that the release can be installed, built and tested in the target environments. Service release testing includes non-functional testing that can be performed at this level.
Level 5 Component and Assemblies	Component and assembly test specification	Component or assembly of components	Component and Assembly Test Test that a service component or assembly of components matches its detailed specification. Components or assemblies are tested in isolation, with a view to their delivering as specified, in terms of inputs generating expected outputs. Evidence of component quality or testing earlier in the chain may be obtained for test evidence, from both internal and external suppliers.
Table 4.8 Levels of configuration for build and testing

Further details on validation, testing and service evaluation are provided in sections 4.5 and 4.6. The test strategy defines the overall approach to validation and testing. It includes the organization of validation and testing activities and resources and can apply to the whole organization, a set of services or an individual service.

Typical levels of configuration for build and testing are shown in Table 4.8.

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 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 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 Operations readiness test environment - 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
• Service Management simulation environments
• 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, e.g. disaster recovery.

Planning 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 determining 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 then insufficient functionality and implementation variations will be trialled and the likelihood of significant errors not being discovered until full rollout is higher. If the scope is too large it will not deliver the speed and flexibility that deliver the benefits, but will effectively be a first rollout.

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 it would be done in a full rollout.

The pilot should include steps to collect feedback on the effectiveness of the deployment plan. This can include:

• Surveying views and satisfaction from:
  • End users
  • Customers
  • Suppliers
  • Service desk and other support staff

• Network management
• Data and Knowledge Management - statistics on use and effectiveness
• Analyzing 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 be supporting 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 before the full rollout of an authorized new service. New services tend to be piloted with test equipment and this needs to be rolled back to its original state. 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 rollout, not the setup put in place for the pilot. This simplifies, day-to-day operations in IT Service Management.

Although a pilot is often thought of as one trial in the production environment before rolling a service out across the full customer and user environment, there may be justification for a range of pilots, e.g. a pilot 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 pilots, and is 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 roll-out 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 overhead and complexity. Alternatively, by running the pilots serially, lessons learned in one environment may be usefully applied to the subsequent ones, since even in 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.
• Trialing options - Where alternative solutions are possible for a major rollout, 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 rollout can be taken based on solid empirical evidence.
• Political considerations - Internal or external political issues may mean that a specific group or groups needs to be involved - or not involved - in a pilot for a new or changed service.

Planning Release Packaging and Build
Planning the release packaging and build activities includes the activities to develop the mechanisms, plans or procedures for the following:

• Verifying the entry/exit criteria
• Managing stakeholder change and communications by:
• Obtaining and maintaining the list of contacts and their details
• Communicating the proposed changes, the expected benefits and how the change affects the organization and staff
• Training people and transferring knowledge
• Establishing the Services and service assets, e.g. agreements and contracts are in place
• Agreeing schedules:
  • Agreeing the delivery schedules and handling any changes/delays
  • Finalizing the logistics and delivery procedures and checklists
  • Scheduling and allocating controlled transition environments, facilities and tools for: i) acquisition of service assets and components, and ii) release packaging, building and testing
• Developing procedures and mechanisms using available Configuration Management, release, content/electronic publishing and other tools to:
  • Build, copy, promote, distribute, audit, install and activate a release
  • Manage software licences, digital rights and Intellectual Property Rights IPR)(
• Converting systems and users from the current applications and technology to the new or changed service, e.g. migrate or reformat application data and information
• Developing the Service Management capability and resources for:
  • Conducting site surveys
  • Updating service information, e.g. service catalogue, release documentation
  • Building and preparing the management systems and other operational systems, e.g. systems and event management, measurement systems
  • Operating and handling the predicted capacity required for support
  • Operating the controlled environments including procedures to scale up capacity if required
  • Documenting and providing the information to be created and/or updated during transition, e.g. remediation plans to be issued and published
  • Installing the new or changed service ready for activation
  • Transferring/transitioning a service or service team or organization
  • Decommissioning and/or disposing of service assets and components
  • Retiring services
• Assessing the readiness of a target deployment group (customers, users and Service Operations staff) to take a release
• Defining and agreeing the exit criteria.

Deployment question	Examples
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, shut-downs 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?
What is the current capability of the service provider?	What are the current services, processes and Service Management capability - capacity, financial aspects, current systems and infrastructure?
Table 4.9 Questions to be answered when planning deployment

Deployment Planning
There are many planning considerations that need to be considered. Planners should be able to answer the questions included in Table 4.9.

Logistics and Delivery Planning
Once the overall deployment approach is understood, develop the logistics and delivery plans. These plans deal with aspects such as:

• How and when release units and service components will be delivered
• What the typical lead times are; what happens if there is a delay
• How to track progress of the delivery and obtain confirmation of delivery
• Availability of secure storage where required  Managing customs and other implications of international distribution.

As well as the delivery aspects, there are typically consequential logistics to be dealt with, e.g. decommissioning and disposing of redundant items, including software and licences, hardware, skills, computer and staff accommodation, support contracts (utility supply, maintenance, cleaners etc.). There may also be a need for temporary equipment (e.g. swing equipment) or throwaway software that is required for the transition. If the transition plans call for any parallel running of services or equipment, this is particularly taxing from a logistics perspective, since double facilities are likely to be required for a short time. Once the logistics and delivery plans have been determined, they need to be communicated to all stakeholders, including formal notification to those consulted in deriving the plan.

Delivery is not sufficient; successful logistics requires that the components arrive and perform as required. Therefore deployment planning for all despatched items - hardware, software, documentation, and training - will address how components are tracked and documented on delivery. This should include:

• Checking against a definitive list of required service assets and components' unique IDs and versions
• A delivery note detailing the components to be delivered, including unique IDs, versions and quantities
• What there should be (contents list to check against)
• What needs to be there to meet it, in terms of equipment, prerequisites and co-requisites
• How to ensure it is correct/working - what tools, parameters, feedback mechanisms, Acceptance Criteria need to be applied?
• Metrics for monitoring and determining success of the release deployment effort.

Financial/Commercial Planning
Financial and commercial aspects will need to be specifically checked before the deployment and activities added to the deployment plans where necessary. For example:

• Working capital - Are sufficient funds available to deliver the customer expectations, e.g. to fund initial changes to gain emotional acceptance during the deployment?
• Contracts and licenses - Have all necessary contract and licence transfers been arranged?
• Funding - 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 has been addressed, including:
• Software developed by one of the parties
• Documentation such as user manuals?

4.4.5.2 Preparation for Build, Test and Deployment

An independent evaluation of the service and release design uses the validation report and results (see 4.6.5). This evaluation checks that the change to the services or service offering will deliver the predicted outcomes, i.e. the service expected by the user or customer. If there are issues, an interim evaluation report is prepared. This report lists the deviations from the SDP, a risk profile and recommendations for Change Management. If there are deviations in the service level requirements then the service package, SLP or SAC may be changed (via Change Management) and action should be taken to modify the proposed service release and related changes. Successful completion of the evaluation of the Service Design baseline ensures that service release build and test starts with a stable, baselined and approved design.

For some releases the Service Transition Manager may need to assign individuals or establish a team of competent people to execute the plans. If individuals are not dedicated there is risk that they may be diverted to work on other projects. Such risks need to be mitigated as they are often the cause of delays. On most occasions, the introduction of a technologyenabled service requires training for the release, deployment, build and test teams. The training needs of these groups will be at different levels. Recognition of the different skill sets, capabilities and competencies within the various groups is a useful prerequisite in identifying the necessary training. In specifying the training programme, the number of people that require training needs to be determined, and the way the knowledge can be provided needs to be considered. While the need for training differs from release to release, the impact of training can be significant. For example if support staff are spread around many locations, specific training, automated mechanisms, such as e-learning or computerbased training (CBT) solutions over the internet or intranet, may become an attractive proposition.

Examples of training needs include:

• Interpreting the Service Design documentation and plans
• Use of support tools, e.g. for central release staff
• Changes in health and safety requirements
• Changes in security policies and procedures
• Technical training
• Service Management and process training, e.g. new build procedure for new configuration item type.

4.4.5.3 Build and Test

• Usage of the build and test environments
• Standardization and integration aspects
• Management of the configurations:
• During the build and test activities, e.g. version control, baseline management, control of inputs and outputs from a build or test stage
• Recording the complete record of the build so that it can be rebuilt if required
• Maintaining evidence of testing, e.g. test results and test report
• Controlling access rights to physical and technology components, e.g. setting parameters
• Checking that security requirements are met
• Verification activities, e.g. prerequisites are met before a build or test begins
• Managing environmental issues, e.g. space, cooling, power, fire precautions, accessibility and safety measures
• Preparing and controlling the service release ready for promotion to the next environment
• Promoting or handing over the service release to the next stage or team.

Configuration baselines of the controlled environments and the release package before and after an installation, build or deployment are recorded in the CMS to provide a restore point. The configuration information also needs to be updated to reflect the receipt and implementation of a release unit or the complete release package to a deployment group or target environment. The definitive version of the release package (approved in service release test) must be placed in the DML even where the release package consists only of documentation for a hardware upgrade. The release package must always be taken from the DML to deploy to the Service Operations readiness, service acceptance and live environments.

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. Procedures and documents for purchasing, distributing, installing, moving and controlling assets and components that are relevant to acquiring, building and testing a release include:

• Contract and agreements (e.g. for ordering new equipment or software)
• Purchase requests and ordering
• Request fulfilment
• Goods inwards and delivery
• Health and safety guidelines
• Security policies and procedures
• Leasing agreements
• Intellectual property rights/digital rights
• Support agreements
• Procedures for:
• Managing service and infrastructure configurations
• Distributing and installing software
• Distributing, translating and converting data and information
• Delivering, installing and moving equipment
• Cleansing data and media
• Disposing of documentation, media and equipment
• Building, commissioning and decommissioning test environments, infrastructures and facilities
• Publishing knowledge, information and data
• Validation and testing
• Change Management
• Service Asset and Configuration Management
• Acceptance and authorization
• Documenting licence agreements and licence headings together with 'proof of licence'.

• Printed licence confirmation documents from software manufacturers (with security features)
• Electronic licence confirmation documents from software manufacturers held on controlled-access websites
• Certificates of authenticity (COAs), which are typically engraved, or with other security features. These may be loose pieces of paper, pieces of paper pasted onto manual covers, labels glued onto equipment, labels printed or glued on retail boxes.

The proposed solution should be documented to enable knowledge gathered during the build and test stages to be handed over to the Service Operations and Continual Service Improvement to be retained for future releases. It is important that the information is ordered and maintained in a systematic manner as during the build and test activities updates to the documentation will be required. The documentation includes:

• Roles and responsibilities
• Process descriptions and procedures
• Support and operations manuals, service desk scripts etc.
• Communications, training and knowledge transfer deliverables
• User manuals with work instructions
• Service information
• Business context and marketing information
• Service catalogue, SLA and supporting documentation:
• Hardware and software information
• Logical and physical architectural overview
• Detailed technical descriptions and references
• Technical information
• Service Management and operations plans
• Business continuity planning details
• Index of documentation for the service and release - baselined.

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 change will need to be raised to assess the component and either incorporate it into the standards catalogue or accept it as a one-off exception for this release.

The acquisition activities include:

• Interfacing with procurement processes to acquire the components (or with internal production departments if supplied in-house)
• Capturing and recording:
• New or updated service assets and CIs through
• SACM
• Receipt of components
• Delivery, change and release documentation from the supplier
• Checking, monitoring and reporting the quality of incoming CIs and service components
• Ensuring that proof of licence can be demonstrated where required
• Initiating action if quality is different from expectation, and assess the likely impact of this on the transition
• Updating status of configuration items in SACM, e.g. to indicate that they are ready to be released into the next stage or rejected.

Verification activities to check the components destined for a release package or build include:

• Establishing that all items are bona fide, and have genuinely been ordered or commissioned
• Standard labeling and naming conventions have been applied as specified in the design specifications for the CIs and service components
• Recording externally acquired items and checking these against their delivery and release documentation
• Checking that:
• Developed products and service components have successfully passed appropriate documented quality reviews
• All software is as expected and no malicious additions are included (e.g. software items that could contain viruses)
• All amendments to previous versions or configuration baselines have been authorized by Change Management and no other amendments have been included - this may require a configuration audit and comparison facilities to check against the desired configuration
• All definitive items have been added to the DML and correctly recorded in the CMS
• Rejection/return of components is adequately controlled and documented.

Issues, non-conformance, known errors and deviations reports about the quality of service components and any risks should be passed to the relevant stakeholders, e.g. quality assurance, CSI, Service Design.

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 production 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; if the documentation needs to be updated.

The key activities to build a release package are:

• Assemble and integrate the release components in a controlled manner to ensure a reproducible process.
• Create the build and release documentation including:
• Build, installation and test plans, procedures and scripts
• Details of how to monitor and check the quality of the release and how to recognize and react to problems
• The automated or manual processes and procedures required to distribute, deploy and install the release into the target environment (or remove it as necessary)
• Procedures to back out release units or remediate a change should a release fail
• Procedures for tracking and managing software licences and digital rights.
• Install and verify the release package.
• Baseline the contents of the release package.
• Send a service notification to inform relevant parties that the release package is available for installation and use.

If testing of a release package is successful, the release and the contents of the release package are placed under the control of Configuration Management, baselined and verified against the release design and release package definition. From this point all changes to the release package are managed through Change Management, e.g. to fix an error in testing. If at any step the testing of a release package does not complete successfully, reassessment and rescheduling of the release is managed through Change Management.

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 means that unplanned changes can compromise the testing activities and/or cause significant re-work. Dedicated build environments should be established for assembling and building the components for controlled test and deployment environments.

Preparation of the test environments includes building, changing or enhancing the test environments ready to receive the release.

An IT service is, on most occasions, built from a number of technology resources or management assets. In the build phase, these different blocks, often from different suppliers, are installed and configured together to create the solution as designed. Standardization facilitates the integration of the different building blocks to provide a working solution and service.

Automating the installation of systems and application software onto servers and workstations reduces the dependencies on people and streamlines the procedures. Depending on the release and deployment plans, the installation may be performed in advance (for example, if equipment is being replaced) or it may have to occur in situ in the live environment.

The physical infrastructure elements, together with the environment in which they will operate, need to be tested appropriately. Part of the testing may be to test the replication of the infrastructure solution from one environment to another. This gives a better guarantee that the rollout to the production environment will be successful.

Test environments must be actively maintained and protected using Service Management best practices. For any significant change to a service, the question should be asked (as it is for the continued relevance of continuity and capacity plans): 'If this change goes ahead, will there need to be a consequential change to the test data?' During the build and test activities, operations and support teams need to be kept fully informed and involved as the solution is built to facilitate a structured transfer from the project to the operations team.

4.4.5.4 Service Testing and Pilots

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 package, including the SLP. 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.

An example of tests that can be executed during release and deployment is shown in Figure 4.22. Further details of these tests are described in section 4.5 on validation and testing. In practice, the test types overlap the different levels of testing to provide a full range of testing across the service life.

A service release test checks that the service components can be integrated correctly and that the release can be installed, built and tested in the target environment.

Service Operations readiness testing ensures that a service and its underlying application and technology infrastructure can be transferred into the production environment in a controlled manner. It provides a level of confidence that the new or changed service will provide the level of service specified in the service requirements and service level requirements. However, it is too early to finalize the SLA at this point. The SLA is finalized in the pilot or more usually in early life support before the Service Transition is closed. The service operational readiness test aims to:

Figure 4.22 Example of service testing through Service Transition

• Determine whether a service and its underlying service assets can be released into the production environment, the first time and for subsequent deployments
• Ensure that the business processes, customers, users and service provider interfaces (SPIs) are capable of using the service properly
• Ensure that the service teams are capable of operating the service and using the Service Management systems properly.

Tests that are conducted as part of service operational readiness test include:

• Deployment readiness test - to ensure that the deployment processes, procedures and systems can deploy, install, commission and decommission the release package and resultant new or changed service in the production/deployment environment
• Service Management test - to ensure that the service performance can be measured, monitored and reported in production
• Service Operations test - to ensure that the service teams will be able to operate the service in production
• Service level test - to ensure that the new or changed service will deliver the service level requirements
• User test - to ensure that users can access and use the new or changed service, e.g. they have access to the updated service catalogue and contact details for the service desk
• Service provider interface test - to ensure that interfaces to the service are working
• Deployment verification test - to ensure that the service capability has been correctly deployed for each target deployment group or environment.

Service Rehearsals
One testing method is to simulate as much of the service as possible in a service rehearsal (sometimes referred to as 'model office'). A service rehearsal 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 establishing errors and unworkable procedures before they impact the business in live operation. However, they 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 risk damage profile that they could prevent.

A service rehearsal takes place just before deployment of the service; if held too early there is a significant chance that the environment, technology, people and legislation into which the service is being released will change and invalidate the results. If too close to the declared release date any issues found will not be addressed before the service goes live.

The objectives of the service rehearsal include:

• Confirmation that all stakeholders have been identified and are committed to operating or using the service if not this will be evidenced through lack of players for roles within the service rehearsal
• Ensure that all stakeholders have processes and procedures in place and are ready to receive process and resolve incidents, problems and changes relating to the new or changed service
• Testing the effectiveness of 'mistake-proofing' included within the service procedures. (Mistake proofing, often referred to by the Japanese term 'Poca Yoke', is about introducing advance warnings of user mistakes or bad practice and where possible introducing steps in the procedures to prevent these mistakes - such as electrical switch interlocks, and check-sum digits in data entry.) While testing can check how a service reacts for predicted user error, the service rehearsal will encourage unforeseen behaviour and establish how that behaviour affects the service's ability to deliver the required benefits.

The service rehearsal requires adequate representation from all stakeholders, with commitment to providing staff for - typically - a full day rehearsal for a new or significantly changed service. It is often beneficial to involve 'ordinary' representatives of the stakeholder community, not those with previous experience or knowledge of the service. Typical mistakes will be more likely to come from typical users - those who have been involved in design and development will find it impossible to 'unlearn' and will be coloured by their expectations of service behaviour.

The focus of a service rehearsal is typically on one day of actual rehearsal, but successful delivery of a service rehearsal involves more stages, including preparation and analysis, mirroring the Plan-Do-Check-Act cycle. Typical stages for a service rehearsal would include the following activities.

Plan - prepare for the day
Request for a service rehearsal - the project or service implementation teams consider that a service rehearsal would be appropriate and trigger the process with a request.

Tasks include the following:

• Appoint a rehearsal manager who gathers all relevant information.
• Identify key and secondary processes.
• Identify all stakeholders and their contact information.
• Produce initial rehearsal guide - the script to be followed.
• Establish and document typical examples of incidents, service requests, capacity and availability issues and other events that will need to be handled when the service is live.
• Produce documentation to allow the simulation, processing, tracking and analysis of the expected scenarios.
• Identify all stakeholders, supplier and service provider personnel who need to be involved and ensure their commitment, through direct funding, internal commitment etc.
• Create detailed scripts - in collaboration with customer or account manager.
• Invite all stakeholders to planning and preparation meetings and briefings (could be by documentation, e-mail, Webinars etc. if physical briefings are not practicable.)

Do - deliver the rehearsal
Hold meetings to:

• Introduce the objectives, documents, involvement, recording etc.
• Walkthrough the scenarios and scripts to establish authenticity of the approach at a detailed level
• Carry out the rehearsal, i.e. let the players deliver the script and observe the processing of key events and elements, e.g. follow an incident through from occurrence to loggings, diagnosis, resolution, recovery and closure.

Check - document the day
Tasks include:

• Analysing and evaluating the results of the rehearsal and determining the implications
• Producing a written test report on the rehearsal, with recommendations, e.g. re-work the service before deployment
• Recording identified errors, issues and risks.

Act - take action following the rehearsal
Considering the results from the rehearsal, the options will be:

• Declare service to have passed without serious concern.
• OR consider that the service is not suitable for progressing at this stage and refer back to Service Design and/or Service Transition for re-work and rescheduling. (It may occasionally be that service rehearsal shows that the actual environment within which the service is expected to function is different enough from expectation to prevent acceptable behaviour from the service in reality - this might require rethink and revision at the Service Strategy and/or business process level.)
• Review and close the service rehearsal, providing improvement ideas to CSI, SD and ST management as appropriate.

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/user base.

A pilot sets out to detect if any elements of the service do not deliver as required and to identify gaps/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 service utilities are fit for purpose and the warranties are fit for use.

Establish clear objectives for the pilot implementation such as:

• To establish metrics and provide confidence that the predicted performance and service levels will be met
• To evaluate the actual benefits and costs achieved during the pilot against the Business Case
• To create acceptance of new processes and ways of working within the user base, service provider and suppliers
• To identify, assess and mitigate some of the risks associated with a full deployment.

As there are likely to be design changes and improvements that need to be built into the release before full deployment, it is important to agree how these will be funded up front. It is also important to ensure that there is a common understanding about how the pilot implementation will be signed off.

During the pilot the release and deployment team should:

• Be ready to invoke contingency/recovery procedures
• Involve key people that will be involved in the full deployment
• Ensure that people involved in the pilot are trained and that they understand their new/changed role and responsibilities
• Document necessary operational and support procedures, information and training material that can not be adequately simulated in a test environment
• Establish the viability of training and support documentation and modify where necessary
• Establish customer, user and stakeholder interaction with the service in real-time situations, e.g. with real business decisions being made
• Capture appropriate metrics in order to compare to the service performance model
• Establish additional criteria that may need to be met before full deployment starts
• Determine the likely level of service support and Service Management resources that will be required and resolve any issues
• Discover and fix issues and errors early and fix many of them before final deployment. This includes the less critical minor irritations and eccentricities of a service that would not necessarily cause non-acceptance but do significantly reduce the emotional acceptance of the service among the user community
• Document improvements and where appropriate incorporate them into plans for full deployment.

When the release has been in use for a sufficient period during a pilot it is important to check that the service is capable of delivering the requirements of the customer, user and the Service Design as well as the predicted outcomes (although not all these will be realized at this point).

If the pilot is of sufficient length, it may be appropriate to conduct an independent evaluation to compare the actual vs predicted service capability and performance (specified in the Service Design) on behalf of the stakeholders, users and customers. This evaluation includes a risk assessment on whether the service will continue to deliver the service requirements, e.g. service levels and warranties.

The outputs from a successfully delivered service pilot will include:

• New or changed service and capability that have been tested and evaluated
• Pilot test report and results
• A report generated by the evaluation function, which is passed to Change Management and which comprises: an updated risk profile, deviations report, recommendation
• Key stakeholder agreement that the release is ready for a full deployment
• Demonstrated benefits of the service (within agreed tolerance levels)
• Confirmation that the deployment team has tested the deployment process and accepts the cost model,
• deployment model and metrics to be used for monitoring during deployment and early life support 
• Target deployment groups in different geographical locations accepting the service release and committing
• to the deployment plans, particularly groups with different cultures and languages.

4.4.5.5 Plan and Prepare For Deployment

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 they are committed to the deployment (see section 5.2).
• 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.

An example of the deployment activities that apply to the deployment for a target group is shown in Figure 4.23.

Figure 4.23 Example of a set 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 will also include transferring a service or a service unit as well as move and disposal activities.

Assessment
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 identifies:

• Issues and risks in delivering the current services that may affect the deployment. The kinds of risk include:
  • Lack of dedicated internal resources and external supplier resources
  • Lack of training, skills and awareness
  • Unplanned or late change in requirements
  
  
• Anticipated impacts, e.g. on the organizational structure, environment for the new or changed services, direct customers and users, partners, suppliers
• Gaps that need to be filled.

The aspects to assess include:

• Financial aspects and assets:
• Current and required working capital
• Establishing new or changed contracts, licences, IPR and digital rights
• 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 including:
• Service structure
• Service dynamics
• Service metrics and reports, including warranties and service levels achieved
• Current Service Management capability and resources:
• Differences from the prerequisites for deployment, e.g. inadequate licensing arrangements, network bandwidth
• Current operations and support resources, e.g. tools, people
• Support resources and workloads as there may be a significant increase in the number of incidents per user that can stretch the resources for managing incidents, problems and fixes
• Performance reports and improvement plans
• Ability to predict and track the actual incident and problem volumes during deployment; this may require updating asset or user records with the date and time of installation or deployment to enable trend analysis
• Identifying requirements to tailor the new or changed service or underlying solution, e.g. processes, procedures, work instructions
• Organizational readiness:
• Role, resource and skills gap analysis
• Training needs analysis
• Ability to assign competent individuals to the required roles
• Motivation and empowerment - does the current organization and culture encourage the application of the required skills? Is there the right leadership and commitment?
• Assess the readiness of customers, users, service provider staff and other stakeholders such as suppliers, partners
• Aspects relating to applications, information and data:
• Access to application, information and data
• Accessing secret, restricted or confidential documents and data
• Knowledge and experience in using the application, users and support staff
• Infrastructure and facilities:
• Difficult access, e.g. located high up in a building without appropriate lifting equipment (elevator or crane, etc.); city centre with restricted parking; remote locations
• Intermediate and final storage and stores for definitive hardware and media
• IT equipment space and capacity requirements such as:
• size and equipment footprints
• power requirements and circuit-breaker ratings
• uninterruptible power supply (UPS) and generator loadings
• temperature and humidity requirements
• heat outputs and air-conditioning requirements
• door clearance and engineering access requirements
• cabling requirements
• Electromagnetic interference (EMI) and radio frequency interference (RFI) requirements
• Air quality requirements
• Weight and false floor loadings
• Network considerations
• Equipment health, safety, security and environmental requirements.

Develop Plans and Prepare For Deployment
Planning for a specific deployment includes assigning specific resources to perform deployment and early life support activities. While developing these plans, identify and assess risks specific to this deployment group by using the service model to identify business and service critical assets that have the highest risk of causing disruption. The activities include:

• Risk mitigation plans
• Developing transfer/transition, upgrade, conversion, disposal, retirement plans
• Logistics and delivery planning:
• The service assets and components for deployment, establishing how and when they will be delivered, and confirmation that delivery has been successfully achieved and recorded
• Site preparation in accordance with applicable health, safety, security and environmental regulations and requirements
• Tailoring processes, procedures and knowledge, e.g. language translation, time frame adjustments
• Knowledge transfer and training stakeholders in how to use, benefit, manage, support and operate the new or changed service:
• Identify essential and potential recipients of training (such as customer, users, ITSM, service desk, support, operations, deployment teams, projects)
• Update of service desk with knowledge of the target deployment group and their environment
• Communicating to the people involved:
• About the changes and the expected benefits
• How the change affects the organization and staff
• 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.

4.4.5.6 Perform Transfer, Deployment and Retirement

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.

Transfer/transition Business and Organization
Transfer of a business unit, service or service unit will involve change to the organization itself. The subject of organizational change is addressed in Chapter 5. 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.

When the change includes a transfer of service provider, e.g. new outsourcing, insourcing, change of outsourced provider, then some specific elements need to be considered, e.g. organizational change, quick wins to avoid confusion and higher staff turnaround.

Competent people with the right skills are required to perform the deployment, operate and manage the new or changed service in the business, customer and service provider organization. The related activities include:

• Recruit staff with appropriate skills. Rather than developing new skills for existing staff, it may be more efficient to recruit new staff who already have the required skills. This may be in addition to existing staff, or may require the replacement of some staff with inappropriate skills, with more relevant staff for the revised circumstances of the new service.
• Identify existing people (e.g. staff, suppliers, users) with appropriate skills, moving or re-allocating people as necessary. For the skills required to actually deploy the new or changed service, temporary secondment, or even overtime, may be the most efficient approach.
• Consider outsource/contract resources to provide the required skills. This is similar to seconding internal staff, but in this case buying the temporarily required skills from external providers where they already exist. If skills are needed longer term, a requirement to pass those skills on to permanent (or longer term) staff can be useful.
• Provide training. Manage the training logistics, coordination, setup, communications, registration, delivery and evaluation activities including users and Service Operations teams.
• Execute the knowledge transfer plan and track progress to completion.
• Evaluate competence of new and changed staff and other people.

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 thousands of people.

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

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

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.

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 licence contravention or in staff using unsupported software
• Identifying licences 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
• Moving assets that can be redeployed to secure storage areas if required. If the assets being retired are remaining in use elsewhere, especially for hardware, the released assets may serve a useful role as spare equipment to be retained in asset stores for speedy redeployment in the event of failures. Records of retirement, transfer and disposal should be maintained and used to update other information such as licence information.

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

As part of the clean-up activities it is important to delete or archive redundant data, information and records related to the previous service or products. The full scope and scale of a service or service asset needs to be considered, and this should extend to the following areas:

• Support contracts with third party suppliers, as changes in likely usage may require renegotiation of contracts.
• In-house second/third level support staff with specialist knowledge may no longer require that knowledge. This may require re-assessment of their role, level of payment, retention etc. and opportunities for redeployment may be identified.
• Service desk workload may be affected.
• Records within the knowledge base relating to the decommissioned components may need to be archived and deleted.

4.4.5.7 Verify Deployment

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

4.4.5.8 Early Life Support

Figure 4.24 Example of early life support activities

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.

Figure 4.25 Illustration of the benefits of targeted early life support

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. An example of a deployment performance graph is shown in Figure 4.25.

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 Figure 4.25 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.

4.4.5.9 Review and Close A Deployment

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

4.4.5.10 Review and Close Service Transition

• Checking that all transition activities completed, e.g. documentation and information is captured, updated, secured, archived
• Checking that accurate metrics were captured.

Independent evaluation of the service release uses the outputs from deployment. This evaluation checks the actual performance and outcomes of the new or changed service against the predicted performance and outcomes, i.e. the service expected by the user or customer. An evaluation report (see 4.6.6) is prepared that lists the deviations from the SP/SLP/SDP, a risk profile and recommendations for Change Management. If there are deviations in the service level requirements then the service package, SLP or SAC may need to change (via Change Management, in agreement with the customer representative and other stakeholders). Successful completion of the evaluation ensures that the service can be formally closed and handed over to Service Operations and CSI.

A transition report should be produced that summarizes the outcomes. As part of producing such a report a post transition workshop could be held involving all parties as a 'lessons learned' exercise. Lessons learned and improvements are fed into Change Management for a post implementation review and into Continual Service Improvement for future transitions.

4.4.6 Triggers, Input and Output, and Inter-process Interfaces

The inputs are:

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

• Release and deployment plan
• Completed RFCs for the release and deployment activities
• Service notification
• Updated service catalogue with the relevant information about the new or changed service
• New tested service capability and environment including SLA, other agreements and contracts, changed organization, competent and motivated people, established business and Service Management processes, installed applications, converted databases, technology infrastructure, products and facilities
• New or changed Service Management documentation
• Service package that defines the requirements from the business/customer for the service
• SLP that defines the service level requirements, e.g. hours of service, business critical services, data and periods, service level targets
• SLA, underpinning OLAs and contracts
• Service model that describes the structure and dynamics of how the service is operated and managed
• New or changed service reports
• Tested continuity plans
• Complete and accurate configuration item list with an audit trail for the CIs in the release package and also the new or changed service and infrastructure configurations
• Service capacity plan that is aligned to the relevant business plans
• Deployment ready release package (baselined) - for future deployments
• Service Transition Report.

Deployment is completed with a handover of the new or changed service to operations on successful completion of the post implementation review of the deployment conducted within Change Management.

4.4.7 Information Management

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

Other data and information will also be captured and recorded within the broader service knowledge management system. This could include:

Deployment information, history of the deployment itself, who was involved, timings etc.

• Training records, typically held by HR in many organizations, but relating to ITSM staff the responsibility for their update will logically rest with ITSM also.
• Access rules and levels
• Known errors. Typically a new or changed service will be introduced with identified errors, which while not according to the original Service Design specification are nonetheless minor enough in nature to be acceptable in live operation. These may well be under active investigation and resolution by the service builders, or may be considered acceptable. In either case the errors will be deployed into the live error database as an element of the deployment of the live service. This information will be available through the SKMS to the service desk who will then be able to link incidents reported against these known errors.

As part of the clean-up activities it is important to delete or archive redundant records related to the previous service or products.

4.4.8 Key Performance Indicators and Metrics

4.4.8.1 Customers Or Business

• Variance from service performance required by customers (minimal and reducing)
• 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 increases the negative perception on the service provider organization as a whole.

4.4.8.2 Service Providers

• Reduced resources and costs to diagnose and fix incidents and problems in deployment and production
• Increased adoption of the Service Transition common framework of standards, re-usable processes and supporting documentation
• Reduced discrepancies in configuration audits compared with the real world.

4.4.9 Challenges, Critical Success Factors and Risks

• 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 releases
• Encouraging a risk management culture where people share information and take a pragmatic and measured approach to risk.

Critical success factors include:

• The new or changed service capability and resources are built in the target environment or deployment group.
• The new or changed service has been tested against the Service Design.
•  The service capability has been proved in a pilot deployment.
• Re-usable test models are developed that can be used for regression testing in future releases.

Risks to successful release and deployment include:

• Poorly defined scope and understanding of dependencies in earlier 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:
• Management incompetence
• Inadequate corporate policies, e.g. security, software licensing
• Inadequate adoption of management practices
• Poor leadership
• Finances:
• Shortage of finances
• Delays move deployment into different financial year
• Lack of clarity on funding for changes/fixes during transition
• Controls:
• Lack of definition of the required controls leads to poorly evaluated and unauthorized changes, adversely affecting release and deployment plans
• Difficulty tracking and managing software licences, e.g. due to complexity
• Unexpected or changes in regulatory controls or licensing requirements
• Management of organizational change
• Unclear expectations/objectives from customers, users, suppliers and other stakeholders
• Cultural differences/misunderstandings
• Human factors
• With suppliers/partners i
• Poor communication
• Organizational change impacts employee morale
• People issues with infringement of personal data protection criteria
• Personality clashes
• Key personnel who have inadequate authority to fulfil their roles
• Poor staff recruitment and selection procedures
• Lack of clarity over roles and responsibilities
• Vested interests creating conflict and compromising quality
• Individual or group interests are given unwarranted priority
• Poor commitment and decision making
• Failure to obtain appropriate approval at the right time
• Indecision or late decision making
• Lack of operational support
• Inadequate or inaccurate information
• Health and safety compromised
• The time allowed for release and deployment - will it make or break the project?
• Suppliers/sourcing/partnering relationships during transition:
• Failure of suppliers to meet contractual requirements; this could be in terms of quality, quantity, timescales or their own exposure to risk
• Delays in contract negotiation
• Organizational change impacts employee morale, employee and supplier performance
• Data protection impacts data sharing
• Shrinking resource pool from disaffected employees
• Governance issues:
• Senior management commitment is missing in one or other of the organizations
• The supplier management function is not mature or is non-existent
• Changes in work practices and procedures adversely affect one or other of the organizations
• Inadequate 'back-out' or 'contingency' plan if sourcing/partnering fails
• Application/technical infrastructure risks:
• Inadequate design
• Professional negligence
• Human error/incompetence
• Infrastructure failure
• Differences/dependencies in infrastructure/ applications
• Increased dismantling/decommissioning costs
• Safety being compromised
• Performance failure (people or equipment)
• Breaches in physical security/information security
• Unforeseen barriers or constraints due to infrastructure.

Supporting Material META - Release Mgmt Becta- Intro to Release Management MOF - Stabilize Service Management Function MOF - Deploy Service Management Function

---