8   Implementing service transition

Implementing service transition in a green-field situation, i.e. a starting point where no service transition exists at all, would only be likely if a new service provider is being established. Therefore, the task for most service provider organizations will be one of service improvement, a matter of assessing their current approach to the service transition processes and establishing the most effective and efficient improvements to make, prioritized according to the business benefit that can be achieved. Considerable guidance on this topic is contained within ITIL Continual Service Improvement, but the cycle will be as illustrated in Figure 8.1.

Figure 8.1 Steps to improving the service transition processes

Introducing new or improved service transition processes will mean a significant organizational change and an introduction of improved services delivered by the service provider. From that context, much of the guidance in this publication on delivering new or changed services is directly applicable to introducing service transition itself. Doing so is, in itself, a service transition exercise, since it is changing the services delivered by the service provider.

8.1     KEY ACTIVITIES IN THE INTRODUCTION OF SERVICE TRANSITION

The stages of introducing service transition will match that of other services, requiring a justification for the implementation (strategic considerations), design of the service transition components and then their introduction to the organization (service transition) before they can run in normal mode (service operation).

8.1.1     Justifying service transition

Service transition is a key contributor to the service provider’s ability to deliver quality services to the business. Service transition is the delivery mechanism between the work of design, and the day-to-day care delivered by operations. However, the service transition processes are not always visible to the customers, and this can make financial justification difficult. When setting up service transition, attention needs to be paid to ways of quantifying and measuring the benefits, typically in terms of the balance between impact to the business (negative and positive) and cost (in terms of money/staff resources) and in terms of what would be prevented by applying resource to any specific transition, such as diverting staff or delaying implementation.

Gathering of evidence on the cost of current inadequate service transition is a valid and useful exercise, addressing such issues as:

  Cost of failed changes

  Extra cost of actual transition compared with budgeted costs

  Errors found in live running that could have been detected during test transition.

8.1.2     Designing service transition

Design of the service transition processes and how they fit within an organization are addressed throughout this publication. Useful factors to consider when designing service transition are described below.

8.1.2.1     Applicable standards and policies

Consider how agreed policies, standards and legislation will constrain the design of service transition. Factors might include requirements for independence and visible accountability, such as are commonly found controlling financial sector companies or within legislation such as Sarbanes-Oxley, health insurance portability and accountability (HIPPA) or the payment card industry (PCI).

8.1.2.2     Relationships

Other internal support services

In many situations service transition must work together with parts of the organization that are transitioning other elements of a business change, such as HR, facilities management, telecoms, production control, education and training. The processes will be designed to facilitate these relationships.

The aim should be to ensure that ownership for each component of the overall service is defined and that subsequent management responsibility is clear.

Programme and project management

Major transitions may be managed as programmes or projects, based on PRINCE2 or PMBOK, and service transition will deliver its role within the appropriate umbrella. Clear areas of delineation and collaboration between programmes, projects and service transition will be required, and these need to be set out and agreed within the organization. To ensure that appropriate transition is delivered, service transition staff will be involved in agreeing key programme and project milestones and timelines, and service transition should be set up to adopt this role. For example if a project is due to deliver a major release at the end of the month, service transition must provide sufficient and timely resources to baseline and release the service, at the agreed time and according to approved quality levels.

To be effective, service transition needs to take a broader view across projects, combining transitions and releases to make the best use of available resources.

Service transition will set up and maintain (working through continual service improvement) an approach to dealing with an ongoing influx of tasks (service transitions) that must be delivered, scheduling, combining and sharing resources as appropriate. The strategy should seek to establish this role for service transition together with the delegated authority and escalation channels that enable it to deliver.

Internal development teams and external suppliers

Communication channels will need to deal with defects, risks and issues discovered during the transition process, e.g. errors found during testing. Channels both to internal teams and to external suppliers will need to be identified and maintained.

Customers/users

Communication with customers and users is important to ensure that the transitioned service will remain focused on current business requirements. The requirements at actual transition may evolve from the needs identified at design stage, and communication channels with the customer will be the source of identifying those changes. Effective communication will benefit from an agreed strategic stakeholder contact map (see section 5.3.2). In many circumstances this communication will be routed through business relationship management or service level management (SLM), but these channels need to be identified and designed into the service transition processes also.

Other stakeholders

Other stakeholders will need to interface with service transition, and these should be identified for all foreseeable circumstances, including in disaster recovery scenarios, and so liaison with IT service continuity management (ITSCM) should be catered for. Other possible considerations might include:

  IT stakeholders, e.g. networks, IT security, data management

  Stakeholders outside IT but within the organization, e.g. facilities management, HR, physical security

  Stakeholders outside the organization, e.g. landlords and regulatory bodies.

8.1.2.3     Budget and resources

The tasks required to deliver service transition should provide an overall net benefit to the organization (or they should be revisited and revised) but nonetheless they do require funding, and the service transition strategy should address the source and control of financial provision.

Funding approach

A mechanism for controlling the funding of the transition infrastructure must be established, including:

  Testing environments  In many organizations testing groups (including specialist testing aspects such as usability testing) are not under the direct control of transition. The relationship and authority to engage and allocate resources needs to be established, understood, maintained and managed.

  Configuration management system (CMS) and service knowledge management system (SKMS) These will specifically require funding for the technology and skills essential to their effectiveness.

The costing of transition objectives must be an integral part of design. This applies whatever the funding mechanism may be, and will involve serviced transition and customers working with design. Typically, the transition options will be costed and a business risk-based decision reached.

Resources

Similarly to the options and issues faced when considering funding, supply and control of other resources will need to be addressed within the service transition strategy, for example:

  Staff – for example, the allocation of project resource to transition activities

  Central infrastructure – for example:

  Central test data – a compromise between data that is broadly applicable and re-usable as against that which is focused on individual services/features

  Network resources for distribution of software, documentation and for testing of networked elements of services to be transitioned.

Test environment management is a major item of expenditure and a significant resource element in many organizations. Under-funding and/or under-resourcing in this respect (either through lack of numbers or lack of requisite skills) can cause expensive errors and problems in supporting live services and have severe detrimental effects on an organization’s overall business capability.

8.1.3     Impact of introducing service transition on existing projects

Experience shows that it is not advisable to attempt to retrofit a new transition’s practices onto projects that are under way; the benefits from the improved (and still unproven) practices are unlikely to outweigh the disruption caused by changing horses in midstream. If a particular transition is especially problematical, and it may be relevant to force a change of attitude, then an exception could be justified.

One technique that has worked in organizations is capturing ‘in-flight’ initiatives and bringing them into line with the new approach. This involves adjusting projects currently going through design/transition and adjusting their planning to fit in with the new procedures, typically at acceptance test/go-live stage. For this to be successful, conversion strategies form ‘old transition routes’ to the new procedures should be considered, designed (and tested where possible) as part of the design responsibility.

8.1.4     Cultural change aspects

Even formalization of mostly existing procedures will deliver cultural change; if implementing service transition into an organization involves installing formal processes that were not there before, the cultural change will be significant. Experience shows that staff working in change management, and even those evangelizing change among others, are potentially as resistant to change in their own areas as anyone else.

While it is important to focus on gaining the support of service transition staff working directly in service transition, it is equally important that those supporting, and being supported by, service transition understand why the changes to procedures are being made, the benefits to themselves and to the organization, and their changed roles. The cultural change programme should address all stakeholders and should continue throughout and after transition, to ensure that the changed attitudes are firmly embedded and not seen as a fashion accessory that can be dispensed with after the initial high profile has faded.

Considerably more information on cultural change can be found in Chapter 5.

8.1.5     Risk and value

As with all transitions, decisions around transitioning should not be made without adequate understanding of the expected risks and benefits. In this specific situation the risks might include:

  Alienation of support staff

  Excessive costs to the business

  Unacceptable delays to business benefits.

The risks and beneficial values require a baseline of the current situation, if the changes are to be measurable. Measures of the added value from service transition might include:

  Customer and user satisfaction

  Reduced incident and failure rates for transitioned services

  Reduced cost of transitioning.

8.2     AN INTEGRATED APPROACH TO SERVICE TRANSITION PROCESSES

The processes involved in the service transition stage of the service lifecycle are not independent of each other. The relationships between them are complex and it is not possible to design and implement them separately.

Figure 8.2 shows an example of the steps that might be required for a single service transition. This is a greatly simplified flowchart, showing major steps only. Each service provider will need to plan and design service management processes based on a full understanding of how they will fit together to support the overall goals of the organization.

Figure 8.2 An example of a path through the processes that might be required for a single service transition

An integrated plan for introduction or improvement of service transition processes should be based on an understanding of how the processes fit together; the roles and responsibilities of all the people involved; and matching the inputs, outputs and triggers of each process step with the corresponding steps in other processes.

This integrated plan should result in an integrated set of processes, with:

  A clear understanding of how the processes will work together in practice for different types of transition

  Each required input being the output of another process step

  Each activity having roles that are accountable and responsible, and people that fill those roles

  An integrated set of critical success factors (CSFs), key performance indicators (KPIs) and metrics that support the objectives of the organization

  An integrated improvement plan to ensure that planned changes to each process will work correctly with planned changes to other processes.

8.3     IMPLEMENTING SERVICE TRANSITION IN A VIRTUAL OR CLOUD ENVIRONMENT

Organizations that are implementing virtualization or cloud architectures must consider the impact of these on the design, implementation and operation of service transition. These environments can be very dynamic, often requiring the rapid provisioning of new virtual servers or migration of virtual servers between hosts to support changing workloads. In order to get maximum value from the architecture, it is likely that many activities will be automated – for example:

  Creation, deployment and retirement of virtual servers

  Adding physical resources to provide greater capacity to an existing virtual server

  Moving a virtual server from a physical server that requires maintenance to a different physical server.

This automation can lead both to difficulties and to opportunities in implementing effective service transition processes, and the service provider must understand these and provide robust processes that are able to function effectively in this environment. This will often require tools that are more sophisticated than those used in a traditional environment, and these tools will need to be integrated with the tools used for automation.

In some organizations there may be an increased need for configuration information to manage the dynamic nature of the configurations. The service provider may need to document all allowed configurations and identify preferred configurations for use by incident management, problem management, change management and other processes. In other organizations it may be sufficient to document the configuration at a higher level and rely on discovery tools to identify the current state when needed. The decision as to which of these approaches is appropriate will depend on many different factors, including the agreed warranty for the service and the need to meet specific service levels.

The virtualization or cloud architecture may require the creation of new configuration item (CI) types, release models, change models and standard changes. It is likely that the tools, activities, authorities, roles and responsibilities for creating and managing virtual servers will be completely different from those used for deploying and managing physical servers. Often these activities will be carried out by different organizations or service units and the relationship between them will be managed by a contract, service level agreement (SLA) or operational level agreement (OLA). The change management and release and deployment management processes must be designed to work seamlessly across both physical and virtual servers, and the configuration management system must be able to reflect the complexity of the relationships. The scope of service transition must be well defined, and understood by everyone who might be involved. Roles and responsibilities must be defined to work across all internal and external parties involved. End-to-end supply chain agreements and an integrated supplier management process must be in place, linked to data in the CMS and in the service catalogue.

In a different context, an organization that moves its services from a traditional insourced data centre to a public cloud may find that its service asset and configuration management needs are greatly simplified, since the underlying complexity is now managed by an external service provider. There is still a need to carry out service asset and configuration management, but the CIs are likely to be at a much higher level.