Purpose

The purpose of service transition is to transition new, modified, retiring, or retired services that have been designed to deliver the strategy. Following transition, the services must meet the business expectations as established in the earlier lifecycle stages.

Objectives

The objectives of service transition include ensuring that changes to services happen as seamlessly as possible. The service releases are deployed into the supported live environment, where they can deliver the business value identified in service strategy. The new or changed service should be transitioned into the live environment without disrupting the other services and, as a result, without disrupting the business. Transition must strike a balance between avoiding risk to the live services and ensuring that the business can receive the new or changed service it requires without unnecessary delay or cost. Effective risk management is therefore also a key objective of this lifecycle stage.

A key aspect of service transition is communication. The business must know what to expect from the new or changed service in terms of its performance and use. If the business’s expectations are not managed, it may judge a transition to have failed because it did not deliver the benefits or functionality that it was expecting but that had never been part of the design.

Having said that, however, transition must ensure that the expected business value is delivered. It is a common mistake to focus on the successful installation of hardware or software and fail to ensure that the business obtains the expected value from these.

An essential part of every transition is the accompanying knowledge transfer. A chief objective of service transition is to provide good-quality knowledge and information about services and service assets.

The requirements for successful service transition are as follows:

• Careful planning of resources
• Risk assessment and mitigation
• Control of service assets to ensure that their integrity is maintained
• Efficient repeatable mechanisms for building, testing, and releasing the service to increase the chances of success while reducing the cost and risks of transition

Service transition must understand the constraints under which the service will operate and ensure that the transitioned service can operate and be managed and supported successfully under these constraints.

Scope

The guidance given in the ITIL Service Transition publication is focused on improving an organization’s capabilities for transferring new and changed services into supported environments. Its scope is wider than change management’s scope; it covers planning the release, building it, testing it, and then evaluating and deploying it. Included within the scope of service transition are retiring services at the end of their useful life and transferring services between service providers, such as during an outsourcing or insourcing exercise or when a service is moved from one outsourced service provider to another. Service transition is all about ensuring that the requirements from service strategy, which were developed in service design, are effectively realized in service operation while controlling the risks of failure and subsequent disruption. A well-designed service can be damaged in the eyes of the business if it is poorly transitioned. If it fails to deliver the benefits reliably because the planning or testing was insufficient, it may be rejected by the business.

Service transition provides guidance on managing changes to services and service management processes, ensuring that the organization is protected from unplanned consequences of changes, while still enabling successful changes that deliver business benefits. These changes may be new services or improvements to existing services, such as expansion, reduction, change of supplier, acquisition or disposal of the user base or suppliers, or changed requirements.

Service transition also covers managing the end of a live service, including decommissioning equipment, discontinuing contracts or other service components, and so on.

The scope of service transition also includes managing the introduction of changes to the service provider’s people, processes, products, or partners.

Transition includes managing the transfer of services to and from other service providers:

• Transfer to a new supplier by outsourcing the work or transfer between suppliers. Sometimes the transfer is from a supplier to in-house provision. This is called insourcing.
• Moving to a partnership or co-sourcing arrangement for some aspects of the service; this may involve multiple suppliers and is sometimes called multisourcing.

Although the service itself may not change, such transfers are not without risk, and careful planning is required to ensure that the transfer appears seamless to the business and nothing is forgotten.

Other transitions may be the result of setting up a joint venture with another organization or restructuring the organization by reducing staff (downsizing) or increasing staff (upsizing). Both of these are known as rightsizing, and the best solution will vary among organizations. Finally, work may be transferred to a location with cheaper labor costs. This is called offshoring. The organization may be involved in a merger or an acquisition.

Of course, in any organization, several of these transitions may be combined. All present risk as well as opportunity, and so must be carefully planned and executed.

The following two lists include the service transition processes. They can be categorized into two groups, based on the extent to which their activities take place within the service transition stage of the service lifecycle. The first group consists of processes that are critical during the service transition stage but influence and support all stages of the service lifecycle:

• Change management
• Service asset and configuration management
• Knowledge management

The second group consists of processes whose focus is strongly related to service transition:

• Transition planning and support
• Release and deployment management
• Service testing and validation
• Change evaluation

We will look at some of these processes later in this book (all except transition planning and support). Remember, almost all transition processes are active in other stages of the lifecycle, and transition is also impacted by processes from other lifecycle stages.

All the lifecycle processes should be linked closely together, and it is important to define the interfaces between processes when designing a service or improving or implementing a process.

Figure 11.1 shows all of the processes described in the ITIL Service Transition publication.

Processes that are largely within the service transition stage of the service lifecycle are shown within the central rectangle; the other stages of the service lifecycle that come before and after these processes are shown in the smaller, darker rectangles. The service transition processes that support the whole lifecycle are shown in the mid-color rectangles.

Not included in the diagram, but considered one of the release, control, and validation processes, is Request Fulfillment, from the Service Operation lifecycle stage. This process is covered in Chapter 3, “Event Management, Request Fulfillment, and Access Management.”

Value to the Business

Selecting and adopting the best practice as recommended by ITIL will assist organizations in delivering significant benefits. Adopting and implementing standard and consistent approaches for service transition will benefit the business by making it easier for projects to estimate the cost, timing, resource requirement, and risks associated with service transition. This in turn enables a higher volume of successful change because less rework will be required. Other benefits include clear processes that are easy to adopt and follow and sharing assets across projects while avoiding clashes between transition projects that require the same asset (such as a test environment) at the same time. Avoiding such clashes will also reduce delay. Following the advice will also minimize the effort spent on managing the service transition test and pilot environments.

Good service transition ensures the following benefits:

• Better expectation setting for all stakeholders involved in service transition, including customers, users, suppliers, partners, and projects
• Increased confidence that the new or changed services can be delivered to specification without unexpectedly affecting other services or stakeholders
• Ensuring that new or changed services will be maintainable and cost-effective and improving the control of service assets and configurations

Use of the transition processes affects other lifecycle stages and promotes and supports an overall service management approach. For example, throughout the lifecycle we can observe interactions between change management and other processes such as service level management, availability and capacity from design, financial management from service strategy, and incident and problem management from service operation.

Transition does not just connect service design to service operation; it provides an interface and connection between all stages of the lifecycle.

Development of a Service Transition Strategy

To manage service transition activity appropriately, the organization should decide on their approach based on the size and type of the services provided, the number and frequency of releases required, and any specific requirements from the users.

The service transition strategy will cover the definition of the overall approach adopted by the organization to managing service transitions and allocating resources. Each organization will be different in its requirements, but the aspects to be considered should include the following:

• The purpose and objectives of service transition
• The organizational context of service transition, in relation to customers and contractual obligations from suppliers
• The scope, specifying the inclusions and exclusions
• Applicable standards or regulatory requirements either internal or external, including adherence to industry standards and contractual obligations
• Stakeholders and organizations involved in transition, which could include
  • Third parties, suppliers, service providers, and strategic partners
  • Customers and users
  • Service management
• Framework for service transition:
  • Policies, processes, and procedures for service transition, including service provider interfaces (SPIs)
  • Integration with program and project management methods and policies
  • Roles and responsibilities
  • Resource planning, and estimation, for transition
  • Training requirements for the transition
  • Change and release authorization
  • Knowledge usage, including experience, expertise, tools, historical data, and existing knowledge within the organization
• Transition criteria, including entry and exit for each release stage, stopping or restarting activity, success, and failure
• Requirements identification and content of the new or changed service, including
  • Services to be transitioned, along with the target locations, customers, and organizational units affected
  • Release definitions
  • SDP (which should include architectural design)
  • Environments to be used (locations, organizational, and technical)
  • Planning and management of environments (commissioning/decommissioning)
  • People, including the assignment of roles and responsibilities, authorization matrix, training, and knowledge transfer requirements
• Approach to transition:
  • Transition model
  • Plans for managing changes, knowledge, assets, and configurations
  • Baseline and evaluation points
  • Configuration audit and verification points
  • Identification of authorization points
  • Identification of change windows
  • Estimation, resource, and cost planning for transition
  • Preparation for the transition
  • Change authorization and change evaluation
  • Release and deployment activities
  • Error handling
  • Monitoring progress and reporting
  • Service performance and measurement, including key performance indicators and targets for improvements
• Deliverables for the transition activities (some mandatory, some optional documentation), which will include
  • Transition plans
  • Release policy and plans
  • Build, test, and deployment plans
  • Evaluation plans and reports
  • Transition closure report
• Schedule of milestones
• Financial requirements, which should include budgets and funding

Service Transition Lifecycle Stages

The lifecycle stages applicable to the transition of a new service should be defined and agreed to in the service design package. A useful approach would be a project management methodology, which would allow checks at the end of each stage, before proceeding to the next.

Typical stages might include

• Acquire and test new configuration items (CIs) and components
• Build and test
• Service release test
• Service operational readiness test
• Deployment
• Early life support
• Review and close service transition

For each stage, it is important to define the entry and exit criteria, which may be used as “quality gates” at specific stages through the transition.

Preparation for Service Transition

The service transition preparation activities include the following:

• Reviewing and accepting of inputs from the other service lifecycle stages
• Reviewing and checking the input deliverables—for example, the service design package, service acceptance criteria, and evaluation reports
• Identifying, raising, and scheduling requests for change (RFCs)
• Checking that configuration baselines are recorded in the configuration management system (CMS) before the start of service transition
• Checking transition readiness

All of these activities provide a point of reference and support a successful transition by ensuring that a baseline is in place to track progress. Tracking and tracing the progress will ensure that any variation or course change to the transition is identifiable and managed appropriately. Change evaluation will have a key role to play in the recommendation of authorization of a change, allowing the business to confirm their acceptance of, and readiness for, the transition.

Our basic requirement for readiness must be

• The agreement of the stakeholders who will be participating in, or be receiving, the transition
• That we have a suitable plan for the transition
• That it is going to provide the service as designed and documented in the service design package

The service design package will have been subject to evaluation as part of its sign-off, carried out by the change evaluation process. This interim report will be an important input into the preparation for our transition activity because it will identify the likelihood of successful implementation.

Planning and Coordinating Service Transition Activities

To coordinate the processes in the service transition stage, it is necessary to plan each transition to ensure that the work is completed effectively and efficiently. As part of the strategic approach to transition, it is important to identify the service transition model that will be used at this point. Each transition will have its own requirements, dependent on the desired outcome, and should have a specific plan. The plan should cover the following sections as a minimum:

• The work environment and infrastructure
• Schedule for the activities
• The activities and tasks to be undertaken
• Resource and budget allocation
• Issues and risks that can be identified at the start and will be added to as the plan is carried out
• Lead times and contingency for any specific actions or equipment

IT environments are complex and often distributed across a wide organizational structure. Managing the introduction of a new service or a change to an existing service is complicated and full of dependencies. It is vital to take an integrated approach to planning transitions. It is important to make sure that the overall plans are aligned and supportive of the individual plans for each stage of the transition. For example, the release and deployment plans need to consider that utilization of specific resources for testing may have very specific schedules.

If the transition relates to a new service or change to an existing service, it will require an overarching plan, which should include

• Milestone activities
• Release components, package release, build, test, deploy, evaluate, early life support
• Build and maintain services and IT infrastructure
• Measurement systems

Since there are likely to be a number of activities taking place at the same time, ITIL recommends adopting a project management approach. This allows for the coordination of all the activities as a program.

A number of project management methods can be used—for example, PRINCE2 or A Guide to the Project Management Body of Knowledge (PMBOK® Guide). But whatever the approach adopted, it is important to ensure that all the activities are coordinated. Larger releases such as those with a greater impact on the business, or perhaps involving a more complex approach, will probably be managed as projects in their own right.

Provide Transition Process Support

One of the key purposes of the ITIL Service Transition publication is the advice it provides to the stakeholders involved with the changes being carried out. This includes guidance to project managers (who may not have service management expertise) about the factors that are important for service management—for example, policies and processes that will enable the service transition to work effectively.

Transition planning and support provides assistance with the administration of the activities that are taking place, and should liaise with the program and project office.

Service management is heavily dependent on successful and meaningful communication, particularly when working on changes to the live environment. Service transition provides guidance on communication plans, which should cover the following:

• Objectives of the communication
• Defined stakeholders
• The content of the communication
• The frequency and format
• Measurement of whether the communication is successful

While the plans are being carried out, it is important to make sure there are sufficient monitoring and progress reports to establish the success of the plans.

Regularly monitoring progress will help identify if the plans are still appropriate for the business. Over the lifetime of a project, it is possible that business needs will have changed, and monitoring progress will help to identify whether any correction to the plan is needed.