Service System Transition

A Service Establishment and Delivery Process Area at Maturity Level 3

Purpose

The purpose of Service System Transition (SST) is to deploy new or significantly changed service system components while managing their effect on ongoing service delivery.

Introductory Notes

The Service System Transition process area addresses all aspects of planning, communicating, managing, deploying, and confirming that service system components effectively make the transition to the delivery environment. The scope of this process area covers both new components and significant changes to existing components.

“Significant” is defined as a change that introduces unacceptable risk that the service system will not meet its objectives. Although these practices center on the transition of service system components, the transition of an entire service system (i.e., an interdependent and integrated collection of components) can also be managed using these practices.

In this process area, the term “transition” refers to the comprehensive process of preparing for, executing, and confirming a deployment of service system components to a fully operational state while maintaining service delivery. The term “deploy” or “deployment” is more specific and refers to the activity of moving service system components into the delivery environment. In some domains, a deployment is also called a “roll-out.”

Deployments generally fall into one of three categories:

• New installation

• Replacement

• Retirement

Transition planning ensures that relevant stakeholders are properly informed of upcoming changes. Preparing for transition also encompasses compatibility evaluations of the to-be service system within the current delivery environment as constrained by existing service agreements and ongoing service delivery activities. Impacts on a service system that will be replaced or phased out over time by a new service system are considered. Impacts on service systems that share interfaces or resources with a new one are also considered, as are impacts on service continuity.

Critical aspects of service system transition include the following:

• Configuration control of service system components

• Management of internal and external interfaces

• Deployment of service system components into the delivery environment

• Stakeholder acceptance of new or revised service system components

• Management of impacts of the transition

Emergency changes to a service system may be made when approved by a designated authority according to established policies. The normal, expected order of service system transition processes may be altered to accommodate the unique needs of an emergency situation, but all relevant processes should eventually be completed once the situation returns to normal. This approach allows any unanticipated impacts associated with emergency changes to be identified and addressed.

Related Process Areas

Refer to the Incident Resolution and Prevention process area for more information about identifying, controlling, and addressing incidents.

Refer to the Service Continuity process area for more information about establishing and maintaining plans to ensure continuity of services during and following any significant disruption of normal operations.

Refer to the Service Delivery process area for more information about operating the service system.

Refer to the Causal Analysis and Resolution process area for more information about identifying causes of defects and problems and taking action to prevent them from occurring in the future.

Refer to the Configuration Management process area for more information about tracking and controlling changes.

Specific Practices by Goal

SG 1 Prepare for Service System Transition

Preparation for service system transition is conducted.

Thorough planning enables a smooth transition of service system components into the delivery environment. Compatibility analysis is critical to this preparation and is addressed within this goal. Additionally, proactive, well-thought-out transition plans with accompanying notification and training strategies clarify the transition, thus eliciting buy-in from relevant stakeholders.

As part of preparing for service system transition, review the operational concepts and scenarios for the service system, and tailor them as necessary to help ensure that planning is sufficiently thorough. Also review the criteria for service system acceptance to ensure that the service system meets those criteria.

The practices that address this goal should begin while new or changed service system components are still under development. By doing so, the needs and constraints for transition can be considered during the component’s development.

SP 1.1 Analyze Service System Transition Needs

Analyze the functionality and compatibility of the current and future service systems to minimize impact on service delivery.

The purpose of this practice is to identify and mitigate issues associated with the transition. This identification and mitigation is accomplished in part by analyzing how the current (as-is) service system will be affected by the changes anticipated for the post-transition (to-be) service system.

The transition of new or modified service system components affects the service delivery environment. Some of these effects may have been anticipated during the development of the service system.

Similarly, ongoing service delivery activities (if any), ad hoc service requests, and environmental circumstances may lead to deployment failure if the constraints they impose are not considered. Actual deployment of new or changed service delivery capabilities may need to be phased in over time because of these constraints. The service system design may need to be adjusted to make the transition feasible. Consequently, this practice should be conducted in parallel with service system development practices and should continue throughout transition to an operational state.

Refer to the Service Delivery process area for more information about preparing for service system operations.

Typical Work Products

1. Compatibility analysis of current and post-transition service systems

2. Issues to be addressed and risks to be mitigated associated with the transition

Subpractices

1. Establish a baseline of the current service system, if it has not been done previously.

Refer to the Configuration Management process area for more information about establishing baselines.

2. Analyze the current service system as it operates within the current delivery environment.

In some cases, documentation and operational concepts may exist for the current service system. These documentation and operational concepts can be used to better understand current operations. If the current service system is undocumented or does not exist, elicit as much input as possible from relevant stakeholders regarding current operations.

3. Analyze the service system components that are proposed for transition (e.g., the post-transition or to-be service system) for potential compatibility, functionality, or interface issues.

This analysis should use development documentation for the proposed service system components. This documentation can include operational concepts, scenarios, design documents, and workflow diagrams.

If necessary, define procedures to ensure service system compatibility prior to actual deployment. These procedures may reuse applicable verification and validation methods employed during service system development, but they should also account for additional real-world constraints that are in place once service system transition begins. Depending on the complexity of the service system and the risks associated with the transition, these procedures may range from a simple analysis and resolution of potential compatibility issues to a formal test and evaluation regimen.

4. Identify and mitigate potential issues.

Refer to the Risk Management process area for more information about mitigating risks.

SP 1.2 Develop Service System Transition Plans

Establish and maintain plans for specific transitions of the service system.

For each specific transition of the service system, a plan is established that encompasses all activities from accepting service system components to resolution of impacts on users and the delivery environment. A transition plan should identify all activities and resources that are required for a specific transition.

The following should be included in transition plans when appropriate:

• Identification of service system components ready for transition

• Deployment type (e.g., new, replacement, retirement)

• Acquisition approach

• Installation and integration of service system components within the delivery environment

• Phasing of deployment over time that satisfies operational dependencies between service system components

• Deployment acceptance criteria

• Resource constraints and restrictions

• Initial provisioning of consumables

• Rollback (or backout) procedures to “undo” the transition and restore the delivery environment to its former stable operating status

• Training of service delivery and support personnel

• Communication of transition status and service changes to relevant stakeholders

The depth of a transition plan should be appropriate for the type of transition and the criticality of the components going through transition. For example, the transition of new business-critical components may require detailed plans and schedules, risk assessment, deployment back-out procedures, and a formal review of planning materials by relevant stakeholders. Less significant transitions, such as retirement of an outdated service, may need less planning rigor.

If similar transitions were performed in the past, the results of their post-deployment reviews should be considered during transition planning. This information can speed up the planning process and help identify issues that might otherwise be overlooked.

Refer to the Project Planning process area for more information about developing a project plan.

Typical Work Products

1. Plans for service system transition

Subpractices

1. Define the deployment approach for each specific service system transition.

Consider the type of deployment (e.g., new installation, replacement, retirement) when defining an approach, taking into account that a transition may include a combination of these types of deployments. Consider priorities and constraints of relevant stakeholders.

Also define a rollback or backout strategy in the event that a deployment is unsuccessful and the service system must be restored to its former state. Include criteria for what constitutes a successful deployment versus when to back out changes.

If a service system is being retired, address topics such as user notification, error handling, archival methods, demolition, and recycling.

2. Determine the cost, resources, and schedule required for transition of the service system to a new or changed operational state.

Schedule transition activities in a way that balances work and available resources against customer and end-user needs, including the need to have time to prepare for and conduct the transition. When appropriate, use actual data from similar transitions to estimate cost, resources, and schedule.

3. Identify relevant stakeholders for transition activities.

When identifying transition stakeholders and defining their roles and responsibilities, be sure to consider outsourced stakeholders.

4. Develop a service system transition plan.

Based on the deployment approach and estimates for a transition, document a plan for the transition.

5. Obtain stakeholder commitment to the plan.

Ensure that the service system transition plan is reviewed by relevant stakeholders to obtain buy-in. Respond to review comments.

6. Establish a baseline of the transition plan.

7. If new or significantly changed essential functions are part of a transition, ensure that the service continuity plan is refreshed to include the new functionality.

Refer to the Service Continuity process area for more information about establishing service continuity plans.

Refer to the Integrated Project Management process area for more information about integrating plans and coordinating and collaborating with relevant stakeholders.

SP 1.3 Prepare Stakeholders for Changes

Prepare relevant stakeholders for changes in services and service systems.

This practice ensures that the service system transition is not impaired because of failure to prepare relevant stakeholders for all of the changes caused by introducing new or modified service system components. Relevant stakeholders should always include customers, end users, provider personnel, senior management, external suppliers, and anyone else who has a need to become aware of expected changes.

Typical Work Products

1. Transition notification strategy

2. Transition training strategy

Subpractices

1. Establish and maintain a transition notification strategy.

2. Implement the notification strategy to keep relevant stakeholders informed about scheduled changes in services and service availability during the transition.

Ensure that the notification strategy addresses how rollback or back-out will be communicated, if appropriate.

3. Establish and maintain a transition training strategy.

The transition training strategy may encompass a broad range of orientation and training activities involving customers, end users, service delivery and support personnel, managers, and senior leadership, as appropriate. The transition training strategy should also encompass activities that ensure the effectiveness of the training after it has been provided, such as testing, piloting, or surveys.

4. Implement the training strategy.

Refer to the Organizational Training process area for more information about establishing an organizational training tactical plan.

SG 2 Deploy the Service System

The service system is deployed to the delivery environment.

This goal focuses on obtaining service system components (from the configuration control authority when appropriate) and installing and integrating them into the delivery environment. This process is conducted according to the tactical plan for service system transition.

Deployment may cause both planned and unplanned effects on service system operation. Identifying, assessing, and controlling these effects is an essential part of achieving a successful deployment.

SP 2.1 Deploy Service System Components

Systematically deploy service system components into the delivery environment based on transition planning.

The preparation for transition, including the tactical plan for service system transition, is used to guide the deployment.

Typical Work Products

1. Installation records

2. Deployment evaluation artifacts

Subpractices

1. Confirm that service system components to be deployed are placed under configuration control as appropriate.

Refer to the Configuration Management process area for more information about establishing baselines.

2. Install the service system into the delivery environment.

This subpractice involves packaging, distributing, integrating, and installing service system components into the delivery environment. Installation and integration details should be included in the tactical plan for service system transition.

3. Validate service system components in the delivery environment.

Ensure that the deployed components operate as expected. Operational scenarios and procedures can be used to evaluate the new or modified service system. Deployment acceptance criteria, which were defined as part of the tactical plan for transition, may need to be revised as part of this evaluation.

Refer to the Service Delivery process area for more information about preparing for service system operations.

4. In the case of service system component retirement, archive the service system components appropriately and remove them from the delivery environment.

Ensure that interfaces with the retired service system components are adequately handled.

SP 2.2 Assess and Control the Impacts of the Transition

Assess the impacts of the transition on stakeholders and service delivery, and take appropriate corrective action.

Transition activities extend past installation of new service system components in the delivery environment. The service provider must ensure that service operations are not adversely affected by recent changes.

Often, this assessment period may extend through several iterations of the new functionality to help ensure that unintended effects are not realized. For example, in the medical domain, a pediatric clinic may implement specific services to support parents of children with special needs. Services could include a facilitated parents’ group, centralized therapy sessions, and educational guidance. Assessing the impacts of these new service system changes would require gathering input from families with children of various ages and diagnoses. It may take some time to gather these data and ensure that the new services are positively affecting relevant stakeholders.

Additionally, this practice ensures that a deployment does not degrade other aspects of the service system or service delivery in general. Unanticipated impacts are addressed in a timely manner and as detailed in the tactical plan for transition. Back-out plans may be implemented as needed based on adverse system impacts.

Refer to the Incident Resolution and Prevention process area for more information about identifying, controlling, and addressing incidents to closure.

Typical Work Products

1. Post deployment review

2. Deployment assessment artifacts

Subpractices

1. Use data gathering methods to obtain input from relevant stakeholders about the deployment.

2. Proactively communicate information about deployment impacts.

Communication should be handled as determined by the tactical plan for service system transition and should, at a minimum, include confirming with relevant stakeholders that a transition has completed successfully.

3. For significant impacts, refer to the tactical plan for details about how and when deployment backout or rollback should be performed.

4. Continue to assess and control impacts until deployment issues are resolved.

Impacts that potentially or actually interfere with service delivery are service incidents that should be handled through the project’s incident management system.

5. Conduct a post-deployment review.

This review identifies, collects, and documents lessons learned from the deployment. This information may be useful both for current service system operation and for future transitions. Relevant stakeholders should be included to address questions such as the following:

• Is the new functionality operating effectively?

• Have other aspects of the service system been degraded?

• Have stakeholders been negatively affected?

• Has the new functionality of the service system been thoroughly evaluated through sufficient use?