Service Transition
1Introduction 2Serv. Mgmt. 3Principles 4Processes 5Activities 6Organization 7Consideration 8Implementation 9Issues AAppendeces

4. Service Transition Processes

4.1PLAN/SUPPORT 4.2CHANGE 4.3ASSET/CONFIG 4.4RELEASE/DEPLOY 4.5 VALIDATE/TEST 4.6EVALUATE 4.7KNOWLEDGE

4.1 Transition Planning And Support

4.1.1 Purpose, Goals and Objectives
The purpose of the Transition Planning and Support activities is to:

The goals of Transition Planning and Support are to:

The objective of Transition Planning and Support is to:

4.1.2 Scope
The scope of the Service Transition Planning and Support activities includes:

4.1.3 Value to business
Effective Transition Planning and Support can significantly improve a service provider's ability to handle high volumes of change and releases across its customer base. An integrated approach to planning improves the alignment of the Service Transition plans with the customer, supplier and business change Project Plans.

4.1.4 Policies, Principles And Basic Concepts
This section sets out basic concepts within that support for effective planning for Service Transition. Service Design will - in collaboration with customers, external and internal suppliers and other relevant stakeholders - develop the Service Design and document it in a Service Design Package (SDP). The SDP includes the following information that is required by the Service Transition team:

4.1.4.1 Service Transition Policy
Policies that support Service Transition are provided in Chapter 3.

The Change, Configuration and Knowledge Management policies also support Service Transition and further examples of these are provided in sections 4.2, 4.3 and 4.7.

4.1.4.2 Release Policy
The release policy should be defined for one or more services and include:

A release that consists of many different types of service assets may involve many people, often from different organizations. The typical responsibilities for handover and acceptance of a release should be defined and then they can be modified as required for specific transitions. The main roles and responsibilities at points of handover should be defined to ensure that everyone understands their role and level of authority and those of others involved in the release and deployment process.

An example of a responsibility matrix for an organization that supports client-server applications is shown in Table 4.1. Such a matrix will help to identify gaps and overlaps and typical roles can be planned for the future.

DevelopmentControlled testRelease to productionProduction
Class of objectReleased fromAccepted byAuthority to release to live environmentAccepted and supported by
Purchased packageApplication developmentTest managerChange managerOperations manager manager
Customized modulesApplication development managerTest managerChange managerOperations manager
Physical database changesApplication development managerDatabase administratorChange manager Database administrator
ServerServer builderServer managerChange managerServer manager
Desktop build (e.g. a new application)Desktop development managerTest managerChange manager Desktop support manager
Desktop application (already built and within operational constraints)Desktop development managerDesktop support Desktop support manager, Change managerDesktop support manager
Desktop computersLogisticsDesktop supportDesktop support manager, Change managerDesktop support manager
Desktop serviceService developmentDesktop supportService level management, desktop management, Change manager Service level support manager, desktop support manager
Release/Change authorizationDevelopment managerTest managerRelease manager, test manager, operations manager, desktop support service, desk user at each site, customer stakeholder, change managerService desk users
Table 4.1 Example responsibility matrix for release points during Service Transition

All releases should have a unique identifier that can be used by Configuration Management and the documentation standards. The types of release should be defined as this helps to set customer and stakeholder expectations about the planned releases. A typical example is:

A release policy may say, for example, that only strict 'emergency fixes' will be issued in between formally planned releases of enhancements and non-urgent corrections.

An extract from a release policy is shown in Table 4.2, which shows how different types of release can be defined.

SERVICERelease definition*Naming/
Numbering		Frequency/
Occurrence		Release window
Store serviceType ASS _XAnnual (Feb)Wednesday 01.00-04.00 hours
Type B or CSS_l.x or SS 1.1.xQuarterlyNot holiday weekends
EmergencySS-1. 1.1.xAs requiredNot 1 September to 31 January
e-store web serviceType AESWnnn x6 months01.00-02.00 hours
Type B and CESWnnn_l.xMonthlyNot holiday weekends
EmergencyESWnnn_1.1.xAs requiredNot 1 October to 10 January
e-store delivery serviceType AESDnnn x6 months01.00-02.00 hours
Type BESDSnnn 1.xQuarterlyHighest level of authorization required during holiday
Type CESDnnn l.l.xMonthlyweekends
EmergencyESDnnn_1.1.1.xAs required 
*Release Definitions
  • Type A: Something that impacts the whole system/service
  • Type B: A release that will impact part of the system, e.g. single sub-system or sub-service
  • Type C: Correction to a single function
  • Emergency: A change required to restore or continue service to ensure the Service Level Agreement (SLA) is maintained
Table 4.2 Extract from a service release policy for a retail organization

4.1.5 Process Activities, Methods And Techniques
4.1.5.1 Transition Strategy
The organization should decide the most appropriate approach to Service Transition based on the size and nature of the core and supporting services, the number and frequency of releases required, and any special needs of the users - for example, if a phased roll-out is usually required over an extended period of time.

The Service Transition strategy defines the overall approach to organizing Service Transition and allocating resources. The aspects to consider are:

Service Transition lifecycle stages
The SDP should define the lifecycle stages for a Service Transition, e.g.:

For each stage there will be exit and entry criteria and a list of mandatory deliverables from the stage.

4.1.5.2 Prepare for Service Transition
The Service Transition preparation activities include:

The configuration baselines help to fix a point in history that people can reference and apply changes to in a manner that is understandable. Any variance to the proposed service scope, Service Strategy requirements and Service Design baseline must be requested and managed through Change Management.

At a minimum, it should be accepted (by design, transition and stakeholders) that the Service Design and all the release units can be operated and supported within the predicted constraints and environment. The evaluation activity described in section 4.6 performs the evaluation of the SDP and Service Acceptance Criteria and provides a report to Change Management with recommendations on whether the RFC should be authorized.

4.1.5.3 Planning And Coordinating Service Transition
Planning an individual Service Transition
The release and deployment activities should be planned in stages as details of the deployment might not be known in detail initially. Each Service Transition plan should be developed from a proven Service Transition model wherever possible. Although Service Design provides the initial plan, the planner will allocate specific resources to the activities and modify the plan to fit in with any new circumstances, e.g. a test specialist may have left the organization.

A Service Transition plan describes the tasks and activities required to release and deploy a release into the test environments and into production, including:

Allocating resources to each activity and factoring in resource availability will enable the Service Transition planner to work out whether the transition can be deployed by the required date. If resources are not available, it may be necessary to review other transition commitments and consider changing priorities. Such changes need to be discussed with change and release management as this may affect other changes that may be dependents or prerequisites of the release.

Integrated planning
Good planning and management are essential to deploy a release across distributed environments and locations into production successfully. An integrated set of transition plans should be maintained that are linked to lower-level plans such as release, build and test plans. These plans should be integrated with the change schedule, release and deployment plans. Establishing good-quality plans at the outset enables Service Transition to manage and coordinate the Service Transition resources, e.g. resource allocation, utilization, budgeting and accounting.

An overarching Service Transition plan should include the milestone activities to acquire the release components, package the release, build, test, deploy, evaluate and proactively improve the service through early life support. It will also include the activities to build and maintain the services and IT infrastructure, systems and environments and the measurement system to support the transition activities.

Adopting programme and project management best practices
It is best practice to manage several releases and deployments as a programme, with each significant deployment run as a project. The actual deployment may be carried out by dedicated staff, as part of broader responsibilities such as operations or through a team brought together for the purpose. Elements of the deployment may be delivered through external suppliers, and suppliers may deliver the bulk of the deployment effort, for example in the implementation of an off-theshelf system such as an ITSM support tool.

Significant deployments will be complex projects in their own right. The steps to consider in planning include the range of elements comprising that service, e.g. people, application, hardware, software, documentation and knowledge. This means that the deployment will contain sub-deployments for each type of element comprising the service.

Reviewing the plans
The planning role should quality review all Service Transition, release and deployment plans. Wherever possible, lead times should include an element of contingency and be based on experience rather than merely supplier assertion. This applies even more for internal suppliers where there is no formal contract. Lead times will typically vary seasonally and they should be factored into planning, especially for long time-frame transitions, where the lead times may vary between stages of a transition, or between different user locations. Before starting the release or deployment, the Service Transition planning role should verify the plans and ask appropriate questions such as:

Anticipating changed business circumstances
A new version of a retail organization's point of sale system was designed and ready for transition to the operational environment. Although the new version offers added features, most improvements related to ease of use, ease of support and maintainability of the software. The transition was originally scheduled for installation in September, but delays in third party suppliers meant the service fails ready for test and subsequent deployment in late November; due for installation two weeks after acceptance testing begins. The initially planned approach of involving 20% of user staff in acceptance trials and store disruption across the user base was no longer appropriate. With the Christmas sales boom imminent, such disruption was not appropriate, and would have been prevented by the annual change freeze. Instead, a longer, slower but less resourceintensive acceptance testing approach was selected with rollout to stores rescheduled for late January. Where the transition approach does require rethinking and probable alteration, this should be delivered through the formal Change Management process, since the consideration of alternatives and agreement of the revised transition approach must be properly documented. However, for foreseeable scenarios, where the path of action is documented as an accepted reaction to the circumstances, authority to record and proceed with a change may be delegated to Service Transition or other appropriate party for approval, e.g. customer or project. For example, where the Service Transition milestone dates and release dates can be achieved with the same cost and resources with no impact on the service definition.

4.1.6 Provide Transition Process Support
4.1.6.1 Advice
Service Transition should provide support for all stakeholders to understand and be able to follow the Service Transition framework of processes and supporting systems and tools. Although the planning and support team may not have the specialist resources to handle some aspects it is important that they can identify a relevant resource to help projects, e.g. specialists to set up Configuration Management or testing tools.

Projects should implement Service Transition activities and tasks in accordance with applicable Service Transition standards, policies and procedures. However, Project Managers are not always aware of the need to adopt these standards, policies and procedures. When new projects start up the Service Transition and planning and support role should proactively seek opportunities to establish the Service Transition processes into the project quickly - before alternative methods are adopted. Another approach is to work closely with the programme or Project Support and offer support to projects via this route.

4.1.6.2 Administration
The Service Transition Planning and Support role should provide administration for:

Changes that affect the agreed baseline configuration items are controlled through Change Management. Plans and progress should be communicated and made available to relevant stakeholders. The stakeholder list is defined in the service package received from design and Service Transition should establish the continued relevance of that list, and update it as necessary.

4.1.6.3 Progress Monitoring And Reporting
Service Transition activities require monitoring against the intentions set out in the transition model and plan. Measuring and monitoring the release and deployment will (at the conclusion) establish if the transition is proceeding according to plan.

Maintaining an oversight of the actual transitions against the integrated Service Transition plans, release and change schedules is essential. It includes monitoring the progress of each transition periodically and at milestone or baseline points as well as receiving and chasing updates.

Management reports on the status of each transition will help to identify when there are significant variances from plan, e.g. for project management and the Service Management organization to make decisions and take action.

In many cases the transition plans will require amendment to bring them into line with a reality that has changed since design. This is not synonymous with bad design or error in selecting transition models, but merely a reflection of a dynamic environment.

4.1.7 Triggers, Input And Output, And Interprocess Interfaces
The trigger is an authorized RFC for a Service Transition. The inputs are:

Outputs:

4.1.8 Key Performance Indicators And Metrics
Primary key performance indicators (KPIs) for Transition Planning and Support include:

Other KPIs for an effective transition and support process include:

[To top of Page]

Visit my web site