3 Service transition principles
This chapter describes the key policies and principles that will enable service providers to plan and implement service transition best practice. These principles are the same irrespective of the organization; however, the approach may need to be tailored to circumstances, including size, distribution, culture and resources.
3.1 POLICIES FOR SERVICE TRANSITION
The following are examples of policies for service transition. Every service provider should agree and document policies that are appropriate for their circumstances. Endorsement and visible support from senior management contribute to the overall effectiveness. Each policy is explicitly stated and its suggested application and approach are illustrated by applicable principles and best practices that help an organization to deliver that principle. Examples of these policies include:
Define and implement a formal policy for service transition
Implement all changes to services through service transition
Adopt a common framework and standards
Maximize re-use of established processes and systems
Align service transition plans with the business needs
Establish and maintain relationships with stakeholders
Establish effective controls and disciplines
Provide systems for knowledge transfer and decision support
Plan release packages
Anticipate and manage course corrections
Proactively manage resources across service transitions
Ensure early involvement in the service lifecycle
Provide assurance of the quality of the new or changed service
Proactively improve quality during service transition.
3.1.1 Define and implement a formal policy for service transition
3.1.1.1 Policy
A formal policy for service transition should be defined, documented and approved by the management team, who ensure that it is communicated throughout the organization and to all relevant suppliers and partners.
3.1.1.2 Principles
Policies should clearly state the objectives, and any non-compliance with the policy must be remedied.
Policies should be aligned with the overall governance framework, organization and service management policies, with appropriate auditing and enforcement. This should include alignment with IISO/IEC 20000, ISO/IEC 38500 and COBIT where these have been adopted.
Sponsors and decision makers involved in developing the policy must demonstrate their commitment to adapting and implementing the policy. This includes the commitment to deliver predicted outcomes from any change in the services.
Processes should integrate teams, blending competencies while maintaining clear lines of accountability and responsibility.
Changes should be delivered in releases, except for standard changes and some emergency changes.
Deployment must be addressed early in the release design and release planning stages.
3.1.1.3 Best practice
Obtain formal sign-off from the management team, sponsors and decision makers involved in developing the policy.
3.1.2 Implement all changes to services through service transition
3.1.2.1 Policy
All service changes must be managed by the service transition lifecycle stage, except for standard changes that follow a procedure defined during the service transition lifecycle stage.
The scope of service change must be documented. This scope should include all changes to the service portfolio or service catalogue and should normally exclude business process changes and some minor operational changes.
3.1.2.2 Principles
There should be a single focal point for changes to supported services, to minimize the probability of conflicting changes and potential disruption.
People who do not have the authority to make a change or release into the supported environment should be prevented from having access.
Each release will be designed and governed by a request for change raised via the change management process to ensure effective control and traceability.
All standard changes, normal changes and emergency changes must follow policy, principles and processes defined by service transition.
Standardized methods and procedures are used for efficient and prompt handling of all changes in order to minimize the impact of change-related incidents on business continuity, service quality and re-work.
All updates to changes and releases are recorded against service assets and/or configuration items (CIs) in the configuration management system.
3.1.2.3 Best practice
The definition of a change is clearly explained.
Internal and external changes are differentiated.
Changes are justified through the development of a clear business case. This may be provided as part of the documentation for the change, or in the case of a standard change it may be predefined.
Changes to services are defined in a service design package, which can be used by service transition to measure the actual versus predicted progress and performance.
The change management process should be standardized and enforced.
Management commitment to enforcing the process is essential, and it must be clearly visible to all stakeholders.
Configuration auditing aims to identify unauthorized changes.
Late requests for changes that cannot be properly managed should not be accepted.
3.1.3 Adopt a common framework and standards
3.1.3.1 Policy
Base service transition on a common framework of standard re-usable processes and systems to improve integration of the parties involved in service transition and reduce variations in the processes.
3.1.3.2 Principles
Implement industry best practice as the basis of standardization to enable integration across the supply chain.
Control the service transition framework and standards under the direction of change management and service asset and configuration management.
Ensure that processes are adopted consistently by scheduling regular reviews and audits of the service management processes.
3.1.3.3 Best practice
Publish standards and best practices for service transition.
Provide a framework for establishing consistent processes for assuring and evaluating the service capability and risk profile before and after a release is deployed. A flowchart such as that shown in Figure 8.2 can be helpful for identifying how the various service transition processes work together to achieve this.
Provide supporting systems to automate standard processes in order to reduce resistance to adoption.
Ensure that there is management understanding of the need for standard ways of working by developing and delivering improvements based on a sound business case.
Establish the level of management and stakeholder commitment and take action to close any gaps.
Continually plan how to improve the buy-in to adopting a common framework and standards.
3.1.4 Maximize re-use of established processes and systems
3.1.4.1 Policy
Service transition processes are aligned with the organization’s processes and related systems to improve efficiency and effectiveness, and where new processes are required they are developed with re-use in mind.
3.1.4.2 Principles
Re-use established processes and systems wherever possible.
Capture data and information from the original source to reduce errors and aid efficiency.
Develop re-usable standard service transition models to build up experience and confidence in the service transition activities.
Implement industry standards and best practice as the basis of standardization to enable integration of deliverables from many suppliers.
3.1.4.3 Best practice
Integrate the service transition processes into the overall service management system.
Use the organization’s programme and project management practices (typically based on PRINCE2 or PMBOK).
Use existing communications channels for service transition communication.
Follow human resources, training, finance and facilities management processes and common practices.
Design service transition models that enable easy customization to suit specific circumstances.
Structure models such that a consistent approach is repeated for each target service unit or environment with local variation as required.
3.1.5 Align service transition plans with the business needs
3.1.5.1 Policy
Align service transition plans and new or changed service with the customer’s and business organization’s requirements in order to maximize the value delivered by a change.
3.1.5.2 Principles
Set customer and user expectations during transition as to how the new or changed service can be used effectively to enable business change.
Provide information and establish processes to enable business change projects and customers to integrate a release into their business processes and services.
Ensure that the service can be used in accordance with the requirements and constraints specified within the service requirements in order to improve customer and stakeholder satisfaction.
Communicate and transfer knowledge to the customers, users and stakeholders in order to increase their capability to maximize use of the new or changed service.
Monitor and measure the use of the services and underlying applications and technology solutions during deployment and early life support in order to ensure that they are well established before transition closure.
Compare the actual performance of services after a transition against the predicted performance defined in service design with the aim of reducing variations in service capability and performance.
3.1.5.3 Best practice
Adopt programme and project management best practices to plan and manage the resources required to package, build, test and deploy a release successfully within the predicted cost, quality and time estimates. These practices will typically be based on PRINCE2 or PMBOK.
Provide clear and comprehensive plans that enable the customer and business change projects to align their activities with the service transition plans.
Manage stakeholder commitment and communications.
3.1.6 Establish and maintain relationships with stakeholders
3.1.6.1 Policy
Establish and maintain relationships with customers, customer representatives, users and suppliers throughout service transition in order to set their expectations about the new or changed service.
3.1.6.2 Principles
Set stakeholder expectations on how the performance and use of the new or changed service can be used to enable business change.
Communicate changes to all stakeholders in order to improve their understanding and knowledge of the new or changed service.
Provide good-quality knowledge and information so that stakeholders can find information about the service transition easily, e.g. release and deployment plans, and release documentation.
3.1.6.3 Best practice
Stakeholders should verify that the new or changed service can be used in accordance with the requirements and constraints specified within the service requirements.
Share service transition and release plans and any changes with stakeholders.
Work with business relationship management and service level management to build customer and stakeholder relationships during service transition.
Work with supplier management to ensure commitment and support from key suppliers during and following transition.
3.1.7 Establish effective controls and disciplines
3.1.7.1 Policy
Establish suitable controls and disciplines throughout the service lifecycle to enable the smooth transition of service changes and releases.
3.1.7.2 Principles
Establish and maintain the integrity of all identified service assets and configurations as they evolve through the service transition stage.
Automate audit activities, where beneficial, in order to increase the detection of unauthorized changes and discrepancies in the configurations.
Clearly define ‘who is doing what, when and where’ at all handover points to increase accountability for delivery against the plans and processes.
Define and communicate roles and responsibilities for handover and acceptance through the service transition activities (e.g. build, test, deployment) to reduce errors resulting from misunderstandings and lack of ownership.
Establish transaction-based processes for configuration, change and problem management to provide an audit trail and the management information necessary to improve the controls.
Ensure that benefits realization for the business is measured and reported for every service transition.
3.1.7.3 Best practice
Ensure that roles and responsibilities are well defined, maintained and understood by those involved and are mapped to any relevant processes for current and foreseen circumstances.
Assign people to each role and maintain the assignment in the service knowledge management system (SKMS) or configuration management system (CMS) to provide visibility of the person responsible for particular activities.
Implement integrated incident, problem, change, service asset and configuration management processes with service level management to measure the quality of configuration items throughout the service lifecycle.
Ensure that the service can be managed, operated and supported in accordance with the requirements and constraints specified within the service design by the service provider organization.
Ensure that only competent staff can implement changes to controlled test environments and supported services.
Perform configuration audits and process audits to identify configuration discrepancies and non-conformance that may impact service transitions.
3.1.8 Provide systems for knowledge transfer and decision support
3.1.8.1 Policy
Service transition develops systems and processes to transfer knowledge for effective operation of the service and enable decisions to be made at the right time by competent decision makers.
3.1.8.2 Principles
Provide quality data, information and knowledge at the right time to the right people to reduce effort spent waiting for decisions and consequent delays.
Ensure that there is adequate training and knowledge transfer to users to maximize the business value created by the new or changed service and to reduce the number of training calls that the service desk handles.
Improve the quality of information and data to enhance user and stakeholder satisfaction while optimizing the cost of production and maintenance.
Improve the quality of release and deployment documentation to reduce the number of incidents and problems caused by poor-quality user documentation, support or operational documentation time between changes being implemented and the documentation being updated.
Provide easy access to quality information to reduce the time spent searching for information, particularly during critical activities such as handling a major incident.
Establish the definitive source of knowledge and share information across the service lifecycle and with stakeholders in order to maximize the quality of information and reduce the overhead in maintaining it.
Provide consolidated information to enable change and release and deployment management to expedite effective decisions about promoting a release through the test environments and into a supported environment.
3.1.8.3 Best practice
Provide easy access, presentation and reporting tools for the SKMS and CMS.
Provide quality user interfaces to the SKMS and CMS for different people and roles to make decisions at appropriate times.
After each transition is complete, publish a summary of the predicted and unpredicted effects of the change and deviations of actual from predicted capability and performance together with the risk profile.
Ensure that service asset and configuration management information is accurate to trigger approval and notification transactions for decision-making via workflow tools, e.g. changes and acceptance of deliverables.
Provide knowledge, information and data for deployment, service desk, operations and support teams to resolve incidents and errors.
3.1.9 Plan release packages
3.1.9.1 Policy
Releases are planned and designed to be built, tested, delivered, distributed and deployed into the live environment in a manner that provides the agreed levels of traceability, in a cost-effective and efficient way.
3.1.9.2 Principles
A release policy is agreed with the business and all relevant parties.
Releases are planned well in advance.
Resource utilization is optimized across service transition activities to reduce costs.
Resources are coordinated during release and deployment management.
Release and distribution mechanisms are planned to ensure that the integrity of components during installation, handling, packaging and delivery is maintained.
Emergency releases are managed in line with the emergency change procedure and are reported to management as appropriate.
The risks of remediating a failed release are assessed and managed.
The success and failure of the release package is measured with the aim of improving effectiveness and efficiency while optimizing costs.
3.1.9.3 Best practice
All updates to releases are recorded in the configuration management system.
Definitive versions of electronic media, including software, are captured in a definitive media library prior to release into the service operation readiness test environment.
Records are kept of planned release and deployment dates and deliverables with references to related change requests and problems.
Proven procedures are followed for handling, distribution and delivery of release packages, including verification.
Prerequisites and corequisites for a release are documented and communicated to the relevant parties, e.g. technical requirements for a test environment.
3.1.10 Anticipate and manage course corrections
Course corrections
When plotting a long route for a ship or aircraft, assumptions will be made about prevailing winds, weather and other factors, and plans for the journey prepared. Checks along the way – observations based on the actual conditions experienced – will require (usually minor) alterations to ensure the destination is reached.
Successful transition is also a journey – from the ‘as is’ state within an organization towards the ‘as-required’ state. In the dynamic world within which IT service management functions, it is very often the case that factors arise between initial design of a changed or new service and its actual transition. This means that ‘course corrections’ to that service transition journey will be required, altering the original course of action planned by service design in order to reach the destination agreed with the customer.
3.1.10.1 Policy
Use risk assessment and management to identify and document the range of course corrections that staff are allowed to implement.
Train staff to recognize the need for course corrections and empower them to apply necessary variations within prescribed and understood limits.
3.1.10.2 Principles
Encourage stakeholders to expect changes to plans and understand that these are necessary and beneficial.
Learn from previous course corrections to predict future ones and re-use successful approaches.
Debrief and propagate knowledge through end-of-transition debriefing sessions, and make conclusions available through the service knowledge management system.
Manage course corrections through appropriate change management, project management and baseline procedures.
3.1.10.3 Best practice
Use project management practices and the change management process to manage course corrections.
Document and control changes but without making the process bureaucratic. (It should be easier to do it correctly than to cope with the consequences of doing it wrong.)
Provide information on changes that were applied after the configuration baseline was established.
Involve stakeholders with changes when appropriate, but manage issues and risks within service transition when appropriate.
3.1.11 Proactively manage resources across service transitions
3.1.11.1 Policy
Provide and manage shared and specialist resources across service transition activities to eliminate delays and optimize utilization of resources.
3.1.11.2 Principles
Recognize the resources, skills and knowledge required to deliver service transition within the organization.
Develop a team (including externally sourced resources if required) capable of successful implementation of the service transition strategy, service design package and release. This team should have the ability to manage all required organizational change management before, during and after the service transition.
Establish dedicated resources to perform critical activities to reduce delays.
Establish and manage shared resources to improve the effectiveness and efficiency of service transition.
Automate repetitive and error-prone processes to improve the effectiveness and efficiency of key activities, e.g. distribution, build and installation.
3.1.11.3 Best practice
Work with human resources (HR), supplier management etc. to identify, manage and make use of competent and available resources.
Recognize and use competent and specialist resources outside the core ITSM team to deliver service transition.
Proactively manage shared resources to minimize the impact that delays in one transition have on another transition.
Measure the impact of using dedicated versus non-dedicated resources on delays, e.g. the impact on service transition of using operations staff who get diverted to fix major incidents.
3.1.12 Ensure early involvement in the service lifecycle
3.1.12.1 Policy
Establish suitable controls and disciplines to check at the earliest possible stage in the service lifecycle that a new or changed service will be capable of delivering the value required.
3.1.12.2 Principles
Use a range of techniques to maximize fault detection early in the service lifecycle in order to reduce the cost of rectification. (The later in the lifecycle that an error is detected, the higher the cost of rectification.)
Identify changes that will not deliver the expected benefits, and either change the service requirements or stop the change before resources are wasted.
3.1.12.3 Best practice
Involve customers or customer representatives in service acceptance test planning and test design to understand how to validate that the service will add value to the customer’s business processes and services.
Involve users in test planning and design whenever possible. Base testing on how the users actually work with a service – not just on how the designers intended it to be used.
Use previous experience to identify errors in the service design.
Build in – at the earliest possible stage – the ability to check for and to demonstrate that a new or changed service will be capable of delivering the value required of it.
Use a formal evaluation of the service design and internal audits to establish whether the risks of progressing are acceptable.
3.1.13 Provide assurance of the quality of the new or changed service
3.1.13.1 Policy
Verify and validate that the proposed changes to the operational services defined in the service and release definitions, service model and service design package can deliver the required service requirements and business benefits.
3.1.13.2 Principles
Service transition is responsible for assuring that the proposed changes to the operational services can be delivered according to the agreements, specifications and plans within agreed confidence levels.
Service transition teams should understand what the customers and business actually require from a service to improve customers’ and users’ satisfaction.
Quality assurance and testing practices provide a comprehensive method for assuring the quality and risks of new or changed services.
Test environments need to reflect the live environment to the greatest degree possible in order to optimize the testing efforts. A cost benefit analysis should be performed to prioritize investments in the test environments. Change management should consider the potential impact of changes on the effectiveness of test environments.
Test design and execution should be managed and delivered independently from the service designer and developer in order to increase the effectiveness of testing and meet any ‘segregation of duty’ requirements.
Formal evaluations of the service design and the new or changed service should be performed to identify the risks that need to be managed and mitigated during build, test, deployment and use of the service – see section 4.6.
Problem management and service asset and configuration management processes should be carried out across the service lifecycle in order to measure and reduce the known errors caused by implementing releases into supported environments.
3.1.13.3 Best practice
Understand the business value that the service helps to create and the quality criteria for the business processes and products that may be affected by the new or changed service.
Understand the business’s process and priorities – this often requires an understanding of its culture, language, customs and customers.
Comprehensive stakeholder involvement is important both for effective testing and for building stakeholder confidence, and so should be visible across the stakeholder community.
Understand the differences between the build, test and live environments in order to manage any differences and improve the ability to predict a service’s behaviour.
Test environments are maintained under the control of change management and service asset and configuration management, and their continued relevance is considered directly as part of any change.
Establish the current service baseline and the service design baseline prior to change evaluation.
Evaluate the predicted capability, quality and costs of the service design taking into account the results of previous experience and stakeholder feedback prior to deployment.
Consider the circumstances that will actually be in place when service transition is complete, not just what was expected at the design stage.
3.1.14 Proactively improve quality during service transition
3.1.14.1 Policy
Proactively plan and improve the quality of the new or changed service during transition.
3.1.14.2 Principles
Detect and resolve incidents and problems during transition to reduce the likelihood of errors occurring during the operational stage of the service lifecycle and adversely affecting business operations.
Proactively manage and reduce incidents, problems and errors detected during service transition to reduce costs, re-work and the impact on the user’s business activities.
Align the management of incidents, problems and errors during transition with the processes used during the service operation stage of the service lifecycle, in order to facilitate measurement and management of the impact and cost of errors across the service lifecycle.
3.1.14.3 Best practice
Compare actual versus predicted service capability, performance and costs during pilots and early life support in order to identify any deviations and risks that can be removed prior to service transition closure.
Perform a formal evaluation of the new or changed service to identify the risk profile and prioritize the risks that need to be mitigated before transition closure, e.g. security risks that may impact the warranties.
Use the risk profile from the evaluation of the service design to develop risk-based tests.
Provide and test the diagnostic tools and aids with the service desk, operations and support staff to ensure that if something goes wrong in testing or live use, it is relatively simple to obtain key information that helps to diagnose the problem without impacting too much on the user.
Encourage cross-fertilization of knowledge between service transition and service operation stages to improve problem diagnoses and resolution time, e.g. workarounds and fixes.
Establish transition incident, problem, error and resolution procedures and measures that reflect those in use in the live environment.
Fix known errors and resolve incidents in accordance with their priority for resolution.
Document any resolution, e.g. workarounds so that the information can be analysed.
Proactively analyse the root cause of high-priority and repeat incidents.
Record, classify and measure the number and impact of incidents and problems against each release in the test, deployment and live service operation stages in order to identify early opportunities to fix errors.
Compare the number and impact of incidents and problems between deployments in order to identify improvements and fix any underlying problems that will improve the user experience for subsequent deployments.
Update incident and problem management with workarounds and fixes identified in transition.
3.2 OPTIMIZING SERVICE TRANSITION PERFORMANCE
In order to be effective and efficient, service transition must focus on delivering what the business requires as a priority and doing so within financial and other resource constraints.
3.2.1 Metrics for alignment with the business and IT plans
The service transition lifecycle stage and release plans need to be aligned with the business, service management and IT strategies and plans.
Typical metrics that can be used in measuring this alignment are:
Increased percentage of service transition plans that are aligned with the business, IT, service management strategies and plans
Percentage of customer and stakeholder organizations or units that have a clear understanding of the service transition practice and its capabilities
Percentage of service lifecycle budget allocated to service transition activities
Quality rating of the plans including adherence to a structured approach, compliance with the plan templates and completeness of the plans
Percentage of planning meetings where stakeholders have participated
Percentage of service transition plans that are aligned with the service transition policies
Percentage of strategic and tactical projects that adopt the service transition service practices
Percentage of release planning documents that are quality assured by staff working in service transition roles.
3.2.2 Metrics for service transition
Measuring and monitoring the performance of the service transition lifecycle stage should focus on the delivery of the new or changed service against the predicted levels of warranty, service level, resources and constraints within the service design or release package. Metrics should therefore be aligned with the metrics for service design, and may include the variation in predicted versus actual measures for:
Resource utilization against capacity
Capabilities (where these can be measured)
Warranties
Service levels
Cost against approved budget
Time
Quality of service, e.g. satisfaction rating or service levels met, breached and near misses
Value
Errors and incidents
Risks.
Examples of other metrics for optimizing the performance of service transition are:
Cost of testing and evaluation versus cost of live incidents
Delays caused by service transition, e.g. due to a lack of service transition resources
Operational problems that could have been identified by the service transition processes
Stakeholder satisfaction with the transition stage
Cost savings by targeted testing of changes to the service design
Reduction in emergency, urgent or late changes and releases – reducing unplanned work
Reduced cost of transitioning services and releases – by type. For example, the cost of implementing minor infrastructure changes, or the cost of retiring customer-facing services
Increased productivity of staff
Increased re-use and sharing of service assets and service transition process assets
More motivated staff and improved job satisfaction, where this can be measured
Improved communications and inter-team working (IT, customer, users and suppliers), where this can be measured
Enhanced performance of service transition processes.
3.3 SERVICE TRANSITION INPUTS AND OUTPUTS
The main input to service transition is a service design package, which includes all of the information needed to manage the entire lifecycle of a new or changed service. The main output is the deployment into live use of a new or changed service, with all the supporting knowledge and information, tools and processes required to support the service. Table 3.1 shows the major service transition inputs and outputs, by lifecycle stage. Appendix D provides a summary of the major inputs and outputs between each stage of the service lifecycle.
Table 3.1 Service transition inputs and outputs by lifecycle stage
| Lifecycle stage | Service transition inputs (from the lifecycle stages in the first column) | Service transition outputs (to the lifecycle stages in the first column) |
| Service strategy |
Vision and mission Service portfolio Policies Strategies and strategic plans Priorities Change proposals, including utility and warranty requirements and expected timescales Financial information and budgets Input to change evaluation and change advisory board (CAB) meetings |
Transitioned services Information and feedback for business cases and service portfolio Response to change proposals Service portfolio updates Change schedule Feedback on strategies and policies Financial information for input to budgets Financial reports Knowledge and information in the SKMS |
| Service design |
Service catalogue Service design packages, including:
Requests for change (RFCs) to transition or deploy new or changed services Input to change evaluation and CAB meetings Designs for service transition processes and procedures Service level agreements, operational level agreements and underpinning contracts |
Service catalogue updates Feedback on all aspects of service design and service design packages Input and feedback on transition plans Response to RFCs Knowledge and information in the SKMS (including the CMS) Design errors identified in transition for re-design Evaluation reports |
| Service operation |
RFCs to resolve operational issues Feedback on quality of transition activities Input to operational testing Actual performance information Input to change evaluation and CAB meetings |
New or changed services Known errors Standard changes for use in request fulfilment Knowledge and information in the SKMS (including the CMS) Change schedule |
| Continual service improvement |
Results of customer and user satisfaction surveys Input to testing requirements Data required for metrics, key performance indicators (KPIs) and critical success factors (CSFs) Input to change evaluation and CAB meetings Service reports RFCs for implementing improvements |
Test reports Change evaluation reports Knowledge and information in the SKMS Achievements against metrics, KPIs and CSFs Improvement opportunities logged in the continual service improvement register |