Service Transition

3.1 PRINCIPLES SUPPORTING SERVICE TRANSITION

3.1.1 Define a Service

Resources are tangible and intangible assets that are owned or controlled by the service provider or the organization for conversion into final products or services that are utilized by customers. Resources are converted into goods and services using knowledge, skills, experience, processes, systems and technologies, which are by themselves a special category of intangible assets called capabilities. This is described further in Service Strategy.

Figure 3.1 Service assets required to deliver services to the business

Figure 3.2 Services provide value by increasing the performance of customer assets and removing risks The term asset is used to refer either to capabilities or resources, or both depending on the surrounding context.

Services are a means for providing value to customers as shown in Figure 3.2. They are a means by which one business unit delivers value to one or more other business units, or to sub-units within itself. In this publication, business units that deliver services are commonly referred to as service providers or service units and those that use services are called customers or simply business units.

3.1.2 Service Utilities And Warranties

A warranty is an assurance that some product or service will be provided or will meet certain specifications. Three characteristics of warranty are that it:

• is provided in terms of the availability and capacity of services
• ensures that customer assets continue to receive utility, even if at degraded service levels, through major disruptions or disasters
• ensures security for the value-creating potential of customer assets.

It is important to understand that the three aspects of warranty are valid for all services though one aspect may be more critical than another. Indeed, the primary value proposition in some services is high-availability, continuity and security.

3.2 POLICIES FOR SERVICE TRANSITION

3.2.1 Define And Implement A Formal Policy For Service Transition

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

Principles:

• Policies should clearly state the objectives and any non-compliance with the policy shall be remedied.
• Align the policies with the overall governance framework, organization and Service Management policies.
• 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.
• Use processes that integrate teams; blend competencies while maintaining clear lines of accountability and responsibility.
• Deliver changes in releases.
• Address deployment early in the release design and release planning stages.

Best practice:

• Obtain formal sign off from the management team, sponsors and decision makers involved in developing the policy.

3.2.2 Implement All Changes To Services Through Service Transition

• All changes to the Service Portfolio or service catalogue are implemented through Change Management and the changes that are managed by the Service Transition lifecycle stage are defined and agreed.

Principles:

• A single focal point for changes to the production services minimizes the probability of conflicting changes and potential disruption to the production environment.
• People that do not have the authority to make a change or release into the production environment should be prevented from having access.
• Familiarity with the Service Operations organization enhances mobilization and enables organizational change.
• Increasing knowledge and experience of the services and production environment improves efficiency.
• Each release package will be designed and governed by a Request for Change raised via the Change Management process to ensure effective control and traceability.
• 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 in the Configuration Management System.

Best practices:

• The definition of a change is clearly defined.
• Internal and external changes are differentiated.
• Changes are justified through the development of a clear Business Case.
• Changes to services are defined in a Service Design Package that Service Transition can use to measure the actual vs predicted progress and performance.
• The existing Change Management process may need to 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.
• Do not accept late requests for changes that cannot be properly managed.

3.2.3 Adopt A Common Framework And Standards

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

Principles:

• Implement industry best practices as the basis of standardization to enable integration across the supply chain.
• Control the Service Transition framework and standards under Change and Configuration Management.
• Ensure processes are adopted consistently by scheduling regular reviews and audits of the Service Management processes.

Best practices:

• 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.
• Provide supporting systems to automate standard processes in order to reduce resistance to adoption.
• Ensure 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.2.4 Maximize Re-use Of Established Processes And Systems 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.

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 practices as the basis of standardization to enable integration of deliverables from many suppliers.

Best practices:

• Integrate the Service Transition processes into the quality management system.
• Use the organization's programme and project management practices.
• Use existing communications channels for Service Transition communication.
• Follow human resources, training, finance and facilities management processes and common practices.
• Design the 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.2.5 Align Service Transition Plans With The Business Needs

Principles:

• Set customer and user expectations during transition on how the performance and use of the new or changed service can be used 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 the service is 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.

Best practices:

• Adopt program and project management best practices to plan and manage the resources required to package, build, test and deploy a release into production successfully within the predicted cost, quality and time estimates.
• 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.2.6 Establish And Maintain Relationships With Stakeholders

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

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.

Best practices:

• Check with stakeholders 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.

3.2.7 Establish Effective Controls And Disciplines

• Establish suitable controls and disciplines throughout the service lifecycle to enable the smooth transition of service changes and releases.

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, release and 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.

Best practices:

• Ensure roles and responsibilities are well defined, maintained and understood by those involved and 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, 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 production services.
• Perform configuration audits and process audits to identify configuration discrepancies and nonconformance that may impact Service Transitions.

3.2.8 Provide Systems For Knowledge Transfer And Decision Support

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

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 there is adequate training and knowledge transfer to users to reduce the number of training calls that the service desk handles.
• Improve the quality of information and data to improve user and stakeholder satisfaction while optimising the cost of production and maintenance.
• Improve the quality of documentation to reduce the number of incidents and problems caused by poorquality user documentation, release, deployment, support or operational documentation.
• 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 and finding information, particularly during critical activities such as handling a major incident.
• Establish the definitive source of information and share information across the service lifecycle and with stakeholders in order to maximize the quality of information and reduce the overhead in maintaining information.
• Provide consolidated information to enable change, Release and Deployment Management to expedite effective decisions about promoting a release through the test environments and into production.

Best practices:

• Provide easy access, presentation and reporting tools for the SKMS and CMS in order.
• Provide quality user interfaces and tools to the SKMS and CMS for different people and roles to make decisions at appropriate times.
• Summarize and publish the predicted and unpredicted effects of change, deviations from actual vs predicted capability and performance together with the risk profile.
• Ensure Service Asset and Configuration Management information is accurate to trigger approval and notification transactions for decision making via workflow tools, e.g. changes, acceptance of deliverables.
• Provide knowledge, information and data for deployment, service desk, operations and support teams to resolve incidents and errors.

3.2.9 Plan Release And Deployment Packages

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

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.
• Release and distribution mechanisms are planned to ensure the integrity of components during installation, handling, packaging and delivery is maintained.
• Emergency releases are managed in line with the emergency change procedure.
• The risks of backing out or remediating a failed release are assessed and managed.
• The success and failure of the releases packages is measured with the aim of improving effectiveness and efficiency while optimizing costs.

Best practices:

• 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 operations readiness test environment.
• Record the planned release and deployment dates and deliverables with references to related change requests and problems.
• Proven procedures for handling, distribution, delivery of release and deployment packages including verification.
• Pre-requisites and co-requisites for a release are documented and communicated to the relevant parties, e.g. technical requirements for test environment.

3.2.10 Anticipate And Manage Course Corrections

Policy:

• Train staff to recognize the need for course corrections and empower them to apply necessary variations within prescribed and understood limits.

Principles:

• Build stakeholder expectation that changes to plans are necessary and encouraged.
• Learn from previous course corrections to predict future ones and re-use successful approaches.
• Debrief and propagate knowledge through end-oftransition debriefing sessions and make conclusions available through the service knowledge management system.
• Manage course corrections through appropriate Change Management and baseline procedures.

Best practices:

• Use project management practices and the Change Management process to manage course corrections.
• Document and control changes but without making the process bureaucratic (it must be easier to do it right 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 about changes when appropriate, but manage issues and risks within Service Transition when appropriate.

3.2.11 Proactively Manage Resources Across Service Transitions

• Provide and manage shared and specialist resources across Service Transition activities to eliminate delays.

Principles:

• Recognize the resources, skills and knowledge required to deliver Service Transition within the organization.
• Develop a team (including externally sourced resources) capable of successful implementation of the Service Transition strategy, Service Design package and release package.
• 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.

Best practices:

• 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 vs nondedicated resources on delays, e.g. using operations staff who get diverted to fix major incidents, scheduling issues with test facilities.

3.2.12 Ensure Early Involvement In The Service Lifecycle

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

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.

Best practices:

• 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 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 an independent evaluation of the Service Design and internal audits to establish whether the risks of progressing are acceptable.

3.2.13 Assure The Quality Of The New Or Changed Service

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

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.
• Ensure that Service Transition teams understand what the customers and business actually require from a service to improve customer 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.
• 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.
• Perform independent evaluations of the Service Design and the new or changed service to identify the risks that need to be managed and mitigated during build, test, deployment and use of the service - see section 4.6.
• Implement problem and Configuration Management processes across the service lifecycle in order to measure and reduce the known errors caused by implementing releases into production.

Best practices:

• Understand the business's process and priorities - this often requires an understanding of their culture, language, customs and customers.
• Comprehensive stakeholder involvement is important both for effective testing and to build stakeholder confidence, and so should be visible across the stakeholder community.
• Understand the differences between the build, test and production environments in order to manage any differences and improve the ability to predict a service's behaviour.
• Test environments are maintained under Change 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 evaluation of the change.
• Evaluate the predicted capability, quality and costs of the Service Design taking into account the results of previous experience and stakeholder feedback prior to release and 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.2.14 Proactively Improve Quality During Service Transition

• Proactively plan and improve the quality of the new or changed service during transition.

Principles:

• Detect and resolve incidents and problems during transition to reduce the likelihood of errors occurring during the operational phase and directly 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 production processes in order to measure and manage the impact and cost of errors across the service lifecycle easily.

Best practices:

• Compare actual vs 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 an independent evaluation of the new or changed service to identify the risk profile and prioritize the risks that need to be mitigated prior to 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 production 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 transition and 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 production 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.

---