Service Design and Transition Procedure

1. Introduction

A service that is badly designed or carelessly introduced costs far more to repair in live operation than it would have cost to get right beforehand. This procedure sets the stages through which every new service, every significant change to an existing service and every withdrawal of a service must pass, and the evidence required at each gate.

2. Purpose

The purpose is to make sure that new and changed services meet the requirements of customers and other interested parties, can be operated and supported by the people who will run them, are secure and resilient, and move into live operation with the knowledge, tools, agreements and records needed, and that services leave operation without loss of data, obligation or support.

3. Objectives

• Every new or changed service has a recorded set of requirements agreed with the customer or service owner before design starts.
• No service enters production without a design package that has passed verification, and without acceptance by the service owner and operations.
• Service level, capacity, availability, continuity and security requirements are designed in, and each one is tested before acceptance.
• Every transition has a plan with dates, owners, risks and a backout route that is reviewed at the transition gate.
• [90%] of transitions complete within the planned dates and budget, and fewer than [5%] cause a major incident in the first [30 days].
• Every transition ends with a review within [30 days] of go-live and the lessons are recorded.

4. Scope

• In scope: new services; changes to services that alter targets, scope, location, supplier or technology in a way that needs design (a major change); the retirement or transfer of services.
• In scope: planning of the transition, the service design package, acceptance criteria, testing, handover to operations and closure.
• Out of scope: routine and standard changes to a live service (see the Change Management Procedure), and the build and release mechanics of software (see the Release and Deployment Management Procedure and the System Development and Maintenance Procedure).
• Applies to: service design manager, project and transition managers, service owners, architects, engineers, test leads, resolver groups, service desk, information security, suppliers and customer representatives.

5. Terms and definitions

6. Roles and Responsibilities

7. Service Design and Transition Process

7.1 Inputs and outputs

7.2 Process flow and gates

1. A proposal for a new, changed or retired service is registered by the service owner on the transition schedule.
2. Requirements are captured and agreed (gate 1: requirements approved).
3. The service design package is created or updated (gate 2: design verified).
4. The transition plan is created, and the build and test environment prepared (gate 3: ready to test).
5. Testing and acceptance are carried out (gate 4: service accepted).
6. Rollout through change and release management, followed by handover to operations (gate 5: go-live authorised, then handover accepted).
7. Early life support runs for the agreed period.
8. Verification, review and closure (gate 6: transition closed).

7.3 Capture new or changed service requirements

1. Register the proposalThe service owner or project sponsor raises a transition request that states the purpose, expected benefits, customers, dates and budget. Output: entry on the transition schedule. Target: [2 working days] after the proposal is approved in principle.
2. Screen for riskThe service design manager assesses scale, novelty, number of suppliers, data sensitivity and effect on existing services, and sets the transition level (small, medium or large). Target: [3 working days]. Large transitions require a risk assessment under the Product Risk Assessment Procedure.
3. Gather requirementsThe service owner works with customers and interested parties to document functional needs, service levels, hours, volumes, capacity, availability and continuity needs, security and privacy needs, legal and contract needs, support model and reporting. Owner: service owner. Target: [10 working days] for a medium transition.
4. Define acceptance criteriaEach requirement is given a way to prove it is met, using the acceptance criteria table. Owner: service owner with the test lead.
5. ApproveRequirements are reviewed by architect, resolver groups, finance and information security. The service owner approves them. Output: signed requirements (gate 1).
6. Control change to requirementsA change to approved requirements is recorded, assessed for cost, time and risk, and approved by the service owner before the design is changed.

7.4 Create or update the service design

1. Plan the designThe architect and service design manager agree design tasks, owners and dates. Output: design plan.
2. Design the serviceProduce the service design package covering the items below. Owner: architect. Target: [15 working days] for a medium transition.
3. Review for supportabilityResolver groups and the service desk review the package for how the service will be operated, monitored and supported. Findings are logged and answered.
4. Update related documentsThe service catalogue entry, service level agreement, operational level agreements and supplier contracts are drafted or updated in step with the design. Owner: service owner.
5. Version and baselineThe package is stored under document control with a version and approval date.

The service design package contains at least the following.

• The service description, scope, customers and service owner.
• Architecture, data flows, interfaces, and the configuration items to be created or changed.
• Service level targets, measurement methods and reporting content.
• Capacity, availability and continuity design, including recovery objectives.
• Security and privacy design, with the risk assessment and control list.
• Roles, support model, runbooks, monitoring and alert design, and training needs.
• Suppliers and agreements, costs and charging.
• Transition approach, test approach and backout approach.
• Exit and retirement approach for the service.

7.5 Design verification

Verification checks that the design meets the approved requirements and can be built, tested and operated. It is done at a design review that includes people who did not produce the design.

1. PrepareThe design manager issues the package to reviewers at least [3 working days] before the review.
2. ReviewReviewers check traceability from each requirement to a design element, and answer the checklist below. A finding is rated blocking, major or minor.
3. ResolveBlocking and major findings are fixed and re-checked before gate 2. Minor findings are accepted with owner and date.
4. ApproveThe service design manager records the decision (approved, approved with conditions, or rejected) with the names of reviewers. Output: design review record.

7.6 Transition of the new or changed service

1. Create the transition planThe transition manager writes the plan: activities, dates, owners, environments, dependencies, risks, communications, training, data migration, go-live window, backout, early life support and acceptance. Output: transition plan. Target: [5 working days] after gate 2.
2. Assess riskRisks to customers, to live services and to security are listed with owners and controls. High risks are escalated to the service owner and the process owner.
3. Authorise resourcesThe service owner confirms budget and staff; finance confirms funding.
4. Prepare the buildEnvironments, test data and tooling are prepared; configuration items are registered as planned in the CMDB under the Configuration and Asset Management Procedure.
5. TrackThe transition manager reports progress, risks and issues [weekly] to the service owner and updates the transition schedule.

7.7 Testing and acceptance

1. Plan testsThe test lead writes the test plan: scope, types, environments, data, entry and exit criteria, defect handling and who attends. It is reviewed by the service owner. Owner: test lead.
2. Run testsTests are executed and results recorded against each acceptance criterion. Defects are logged with severity. Retests are done after fixes.
3. Test operationResolver groups run operational acceptance: monitoring alerts fire, backups and restores work, failover works, runbooks are correct and the service desk can handle typical questions.
4. Test with customersCustomer representatives take part in user acceptance testing where the service is customer-facing. Their sign-off is recorded.
5. ReportThe test lead issues a test report with criteria met and not met and all open defects, and recommends accept or reject. Target: [2 working days] after testing ends.
6. DecideThe service owner decides at gate 4 to accept, accept with conditions, or reject. Conditions have owners and dates. Output: acceptance record.

7.8 Rollout and handover to operations

1. Request go-liveThe transition manager raises the change and release request with the test report, acceptance record and backout plan. The change authority decides under the Change Management Procedure; the release manager deploys under the Release and Deployment Management Procedure.
2. CommunicateCustomers, users, the service desk and suppliers are told what will change, when and how to get help, at least [3 working days] before go-live for a customer-facing change.
3. Go-liveThe deployment runs in the approved window. The transition manager and release manager confirm completion, run post-implementation checks and decide on backout if criteria are not met.
4. Hand overHandover is accepted by the resolver groups and the service desk: documents, runbooks, contacts, monitoring, known errors and open defects are transferred. The handover record is signed. Target: [at go-live].
5. Early life supportExtra support and daily review of incidents run for [30 days] for a large transition and [10 days] for a medium one. The transition team stays on call.
6. Update recordsThe service catalogue, CMDB, service level agreement, supplier register and knowledge base are updated within [5 working days].

Retirement of a service follows the same gates in reverse: requirements are the customer notice period and data obligations; the plan covers notice, data return or deletion, migration of customers, removal of access and configuration items, termination of supplier agreements, and removal from the catalogue. The service is removed from production only after the service owner confirms in writing that notice has run and data has been dealt with.

7.9 Verification, review and closure

1. Verify outcomesAfter early life support the service owner and transition manager compare results with the requirements: targets met, incidents, customer feedback, cost against budget. Target: [30 days] after go-live.
2. Hold the reviewA review meeting records what went well, what did not, and the causes. Findings go to the improvement log under the Service Reporting and Continual Improvement Procedure.
3. Close open itemsOpen defects and conditions are moved to problem, change or improvement records with owners; none is left on the transition record.
4. CloseThe process owner closes the transition, releases project resources and archives the records.

8. Interfaces with other processes

9. Key Performance Indicators

10. Records and evidence

Annexure A: Transition request form

Annexure B: Service acceptance criteria

Annexure C: Handover checklist and acceptance record

Annexure: Document history

11. Exception

Exceptions to this document are allowed only where compliance is not practicable and the risk has been assessed. A request must state what is to be excepted, why, the risk it creates, the compensating controls, and an end date no later than [6 months]. It is approved in writing by the document owner and the risk owner, recorded in the exceptions register, and reviewed at the end date. An exception does not change the document.

12. Enforcement

Compliance is monitored through internal audits, management review and routine checks by the document owner. Non-compliance is reported through the incident or non-conformity process and handled under the organisation's disciplinary procedure, and under the terms of any contract for people who are not employees. Serious or repeated non-compliance may lead to loss of access and, where the law is broken, to referral to the authorities.

13. Review

This document is reviewed at least every [12 months], and when there is a significant change to the organisation, its systems, its risks or the law, or after an incident that shows it was not effective. Each review is recorded in the revision history.

ISO/IEC 20000-1:2018 references

Related documents

• Change Management Procedure
• Release and Deployment Management Procedure
• Service Catalogue Management Procedure
• Capacity and Demand Management Procedure
• Availability and Service Continuity Management Procedure
• Information Security Management for Services
• System Development and Maintenance Procedure
• Product Risk Assessment Procedure