Service Design and Transition Process
ISO20000 Toolkit: Version 10 ŠCertiKit
Service Design and Transition Process
Implementation guidance The header page and this section, up to and including Disclaimer, must be removed from the final version of the document. For more details on replacing the logo, yellow highlighted text, and certain generic terms, see the Completion Instructions document.
Purpose of this document The Service Design and Transition Process sets out how new or changed services will be managed from requirements definition through to project review.
Areas of the standard addressed The following areas of the ISO/IEC 20000:2018 standard are addressed by this document: •
8. Operation of the service management system o 8.5 Service design, build and transition ▪ 8.5.2 Service design and transition • 8.5.2.1 Plan new or changed services • 8.5.2.2 Design • 8.5.2.3 Build and transition
General guidance This is a significant area of the standard that has been enhanced in the 2018 version. A strong projects process that includes early and comprehensive consideration of service management issues will be invaluable in showing compliance to the standard. Ensure everyone in your IT organization is aware of this process and the steps involved in it. It is all too common for projects to move straight to the design stage without proper consideration of the proposal, requirements and planning stages and the auditor will be looking for this at the certification audit.
Review frequency We would recommend that this document is reviewed annually.
Version 1
Page 2 of 17
[Insert date]
Service Design and Transition Process
Document fields This document may contain fields which need to be updated with your own information, including a field for Organization Name that is linked to the custom document property “Organization Name”. To update this field (and any others that may exist in this document): 1. Update the custom document property “Organization Name” by clicking File > Info > Properties > Advanced Properties > Custom > Organization Name. 2. Press Ctrl A on the keyboard to select all text in the document (or use Select, Select All via the Editing header on the Home tab). 3. Press F9 on the keyboard to update all fields. 4. When prompted, choose the option to just update TOC page numbers. If you wish to permanently convert the fields in this document to text, for instance, so that they are no longer updateable, you will need to click into each occurrence of the field and press Ctrl Shift F9. If you would like to make all fields in the document visible, go to File > Options > Advanced > Show document content > Field shading and set this to “Always”. This can be useful to check you have updated all fields correctly. Further detail on the above procedure can be found in the toolkit Completion Instructions. This document also contains guidance on working with the toolkit documents with an Apple Mac, and in Google Docs/Sheets.
Copyright notice Except for any specifically identified third-party works included, this document has been authored by CertiKit, and is ©CertiKit except as stated below. CertiKit is a company registered in England and Wales with company number 6432088.
Licence terms This document is licensed on and subject to the standard licence terms of CertiKit, available on request, or by download from our website. All other rights are reserved. Unless you have purchased this product you only have an evaluation licence. If this product was purchased, a full licence is granted to the person identified as the licensee in the relevant purchase order. The standard licence terms include special terms relating to any third-party copyright included in this document.
Version 1
Page 3 of 17
[Insert date]
Service Design and Transition Process
Disclaimer Please Note: Your use of and reliance on this document template is at your sole risk. Document templates are intended to be used as a starting point only from which you will create your own document and to which you will apply all reasonable quality checks before use. Therefore, please note that it is your responsibility to ensure that the content of any document you create that is based on our templates is correct and appropriate for your needs and complies with relevant laws in your country. You should take all reasonable and proper legal and other professional advice before using this document. CertiKit makes no claims, promises, or guarantees about the accuracy, completeness or adequacy of our document templates; assumes no duty of care to any person with respect its document templates or their contents; and expressly excludes and disclaims liability for any cost, expense, loss or damage suffered or incurred in reliance on our document templates, or in expectation of our document templates meeting your needs, including (without limitation) as a result of misstatements, errors and omissions in their contents.
Version 1
Page 4 of 17
[Insert date]
Service Design and Transition Process
Service Design and Transition Process
Version 1
DOCUMENT REF
SMS-DOC-085-4
VERSION
1
DATED
[Insert date]
DOCUMENT AUTHOR
[Insert name]
DOCUMENT OWNER
[Insert name/role]
Page 5 of 17
[Insert date]
Service Design and Transition Process
Revision history VERSION
DATE
REVISION AUTHOR
SUMMARY OF CHANGES
Distribution NAME
TITLE
Approval NAME
Version 1
POSITION
SIGNATURE
Page 6 of 17
DATE
[Insert date]
Service Design and Transition Process
Contents 1
Introduction ............................................................................................................... 8
2
Process overview........................................................................................................ 9
3
Proposals for new or changed services ..................................................................... 11 3.1
4
5
6
Planning new or changed services ............................................................................ 12 4.1
Project initiation document ........................................................................................ 12
4.2
RAID log..................................................................................................................... 12
Design and build of new or changed services ............................................................ 13 5.1
Service requirements specification ............................................................................. 13
5.2
Service design specification ........................................................................................ 13
Transition of new or changed services ...................................................................... 15 6.1
Service acceptance checklist ....................................................................................... 15
6.2
Release and deployment plan .................................................................................... 15
6.3
Updates to existing ITSM documentation and data sources ......................................... 15
6.3.1 6.3.2 6.3.3 6.3.4 6.3.5
7
Business case ............................................................................................................. 11
ITSM database ........................................................................................................................... 15 Service level agreement ............................................................................................................ 16 Service catalogue ...................................................................................................................... 16 Budgets ..................................................................................................................................... 16 Supplier and contracts database ................................................................................................ 16
Project closure ......................................................................................................... 17
Figures Figure 1: Service Design and Transition Process .......................................................................... 10
Version 1
Page 7 of 17
[Insert date]
Service Design and Transition Process
1 Introduction The purpose of this document is to set out the process for the service design and transition of new or changed services in order to ensure that the financial, organizational and technical impact that could result from service delivery and management is fully considered. Changes to existing services and the introduction of new ones are fundamental to the smooth operation of the business as they correct errors and introduce additional functionality necessary to survival in the modern economy. As described in [Organization Name] change management documentation, changes may fall into a number of categories according to their scope and urgency. This document deals with changes classified as Major by the change management process. The point at which a change request becomes sufficiently significant to be classed as Major and taken via the service design and transition process is documented in the Change Management Policy.
Version 1
Page 8 of 17
[Insert date]
Service Design and Transition Process
2 Process overview Major changes to existing services or the introduction of new ones will be managed as projects. [Organization Name] has adopted a structured management method across all of its IT projects in order to ensure that they are planned, organized and implemented in a controlled fashion. As part of this method, the deliverables of each project will be defined, and their status tracked through to completion. Risks and issues will also be managed as part of this process. A post-implementation review will be held after the project has been completed, with results being reported to the relevant parties. The main stages of the service design and transition process and their associated documents are shown in the diagram on the following page. The stages are: 1. Proposal: Once a change record has been raised and the change classified as Major, a business case will be created for the project and submitted to the IT Steering Group for approval 2. Planning: Approved projects will then be initiated, including the formation of the project team, creation of the project initiation document and initial project planning. These will be passed through the IT Steering Group for approval 3. Design and Development: The new or changed service will then be designed, including definition of service requirements, specification of infrastructure and software to meet those requirements and testing criteria, again all submitted to the IT Steering Group for approval. The required service components will then be created based on the approved design and passed to the service management function for service testing and acceptance. 4. Transition: Once tested and accepted the service is transitioned into live operation and the benefits of the new or changed service begin to be realised 5. Project Closure: The project will then be reviewed and formally closed. This happens after a variable period of time defined by the IT Steering Group The IT Steering Group, which has overall authority for IT projects, will consist of representatives from each area of the organization, including service management. This means that there will be an opportunity to discuss the service management aspects of the project at each stage, including the agreement of requirements, creation of design and handover to delivery. The service design and transition process is shown on the diagram on the following page. As per the change management process, each new or changed service (i.e. project) will be raised as a change request from the outset so that it can be assessed, approved, scheduled, and reviewed. The change management process will then be used at the appropriate time to ensure that all changes to registered configuration Items are managed effectively and recorded in the configuration management database. Change management will be concerned with specific,
Version 1
Page 9 of 17
[Insert date]
Service Design and Transition Process
individual changes rather than the overall planning of the handover from the project team to service delivery. For example, the service design and transition process will be concerned with higher level issues such as training of support staff, documentation, budgets, tools etc. whereas the change management process will be used when software is installed on a live server, cloud infrastructure is created, or a new network link is put in, resulting in a material change to the installed base.
Figure 1: Service Design and Transition Process
Version 1
Page 10 of 17
[Insert date]
Service Design and Transition Process
3 Proposals for new or changed services Before embarking on what may be a lengthy and expensive implementation process it is important to ensure that the business justification for the new or changed service is fully documented, agreed and understood. In part this will be stated in the change request that is raised initially within the change management process, but for larger pieces of work further detail will usually be required.
3.1 Business case The business case sets out the problem or opportunity that is to be addressed, the potential benefits to be gained by the organization (expressed in measurable terms) and the options available to address the problem or opportunity. A full view must be given of the pros and cons of each option (including full description, benefits, costs, feasibility, risks, issues and assumptions) before a recommended solution is proposed. This will show that: • • • •
The problem or opportunity is genuine The available options have been explored The right solution has been proposed The costs and benefits of the recommended option are clear
The business case will then be reviewed and, if appropriate, approved by the IT Steering Group. Several revisions of the business case may be required before approval is given. This document will then be re-evaluated at each stage in the process to ensure that it remains valid, in particular that: • • • •
The expected benefits are still achievable Costs have not escalated to the point where they outweigh the benefits Alternative options have not become more attractive due to internal or external changes e.g. company re-organization, mergers and acquisitions, legislation Project timescales still allow the realisation of the expected benefits to schedule (e.g. the window of opportunity is still open)
If significant changes do occur, the viability of the project will be reviewed by the IT Steering Group and a decision taken regarding its ongoing feasibility.
Version 1
Page 11 of 17
[Insert date]
Service Design and Transition Process
4 Planning new or changed services 4.1 Project initiation document Once the business case for a new or changed service has been approved, the project to deliver it can be planned. The starting point for this is the creation of the Project Initiation Document (PID) which sets out: • • • • • • • • • • • • • • •
Objectives that the project must meet Scope of the project Dependencies between this project and others Human, technical, information and financial resources allocated Constraints that must be considered Assumptions made Deliverables and their descriptions Project team structure Stakeholders in the new or changed service Authorities and responsibilities for design, build and transition Communication within the project and externally Progress reporting Timescales and milestones Risks that are known about How issues and risks will be managed during the project
In addition, an initial project plan will be defined that shows how the project activities will take place including dependencies, resources and timescales. The PID is an important document that is intended to ensure that everyone involved with the project (or affected by it) has a clear understanding of what it will and won’t deliver and how the project will be conducted. The PID must be signed off by the IT Steering Group before delivery commences.
4.2 RAID log In addition to the PID, a RAID log will be created which will record: • • • •
R: Risks to the success of the project A: Actions agreed during project meetings I: Issues that are affecting the project D: Decisions made during the project
The RAID log will be used by the project manager throughout the life of the project and will be a key input to the post-implementation review.
Version 1
Page 12 of 17
[Insert date]
Service Design and Transition Process
5 Design and build of new or changed services Once the project has been planned, the creation of its deliverables can begin. These must be based upon a clear definition of the service requirements.
5.1 Service requirements specification Requirements for the new or changed service will be defined by stakeholders as part of the project. These will be in addition to functional requirements such as business logic and cover service management areas such as: • • • • • •
Availability – days/times to be available; percentage availability requirements Security levels – sensitive data; regulatory requirements Capacity and Performance – data sizes, response times, batch turnaround times Service continuity – time to restore service; critical users Support hours and service levels Service requests and required turnaround times
These will be agreed by all parties and will form the basis of the service requirements specification document. There will be an opportunity for the service management function to identify any requirements that are outside of the norm and may be costly or difficult to meet and to highlight these before they are approved.
5.2 Service design specification Based on the agreed requirements a service design specification will be created which sets out how they will be achieved. This will specify the following attributes of the new or changed service: • • • • • • • • • • • • •
Authorities, roles and responsibilities, including other parties (external or internal) Processes and procedures to be used to deliver the service Human resource plan, including skills and competencies to deliver the service Financial resources required to deliver the service Technology requirements Plans and policies Contracts and agreements SMS changes Service Level Agreements Service catalogue updates Procedures, measures and information Testing and deployment approach Service acceptance criteria
Version 1
Page 13 of 17
[Insert date]
Service Design and Transition Process • • •
Monitoring and event management (databases, networks, errors etc.) IT service continuity provisions Information security controls
The intention is that all aspects that will be required at later stages i.e. Transition and Operation, will be specified in advance as part of the service design specification. This will ensure that the delivered system meets the requirements in all respects. The service design specification should be signed off by all key stakeholders.
Version 1
Page 14 of 17
[Insert date]
Service Design and Transition Process
6 Transition of new or changed services Once the new or changed service has been built according to the service design specification, it will be transitioned into the live environment. This will involve various stages of testing and acceptance followed by a managed release process, all under the control of the change management process.
6.1 Service acceptance checklist A list of service acceptance criteria will be created and agreed. A standard checklist will be used for this, with additions made where required for the specific service involved. Any issues arising from such testing will be recorded and addressed with the project team. Where possible, issues should be resolved but it may be agreed between the teams that some issues may remain into live running for later resolution. These will be communicated to the IT Service Desk before entering live running.
6.2 Release and deployment plan Once the new or changed service has passed acceptance testing it will be deployed according to the release and deployment plan created for this purpose in accordance with the [Organization Name] Release and Deployment Management Policy.
6.3 Updates to existing ITSM documentation and data sources In addition to the creation of documentation for each new or changed service, there is a set of existing data sources that will be updated as part of the Transition process. These are:
6.3.1 ITSM database The ITSM database (i.e. the collection of sources of information about services in the service catalogue) will be updated with details of the new or changed service so that all processes are aware of it including: •
•
Incident and service request management o New users and customers o New request types o New incident models o New categories and sub-categories Problem management
Version 1
Page 15 of 17
[Insert date]
Service Design and Transition Process
• •
•
o Details of all known errors with the service that were not resolved prior to live running Configuration management o New configuration items will be added to the CMS o The version numbers of existing CIs will be updated where appropriate Capacity management o Any additional servers and other resources will be added to the list of those monitored for capacity o The capacity plan will also be updated Service continuity and availability o Service continuity plans will be updated to allow for the recovery of the business-critical aspects of the new or changed service o The service will be monitored for availability
6.3.2 Service level agreement The SLA will be updated or a new one created to document the agreed levels of service for the new or changed service. This will be done under version control via the change management process.
6.3.3 Service catalogue The new or changed service will be added to the service catalogue together with the required details of who uses it, how it can be accessed etc.
6.3.4 Budgets Budget changes resulting from the new or changed service will be incorporated into the IT budget where appropriate and a cost model calculated for the service.
6.3.5 Supplier and contracts database Any new or revised contracts will be placed into the contracts database and the details of new suppliers entered into the supplier database.
Version 1
Page 16 of 17
[Insert date]
Service Design and Transition Process
7 Project closure The successful transition of the new or changed service into operation should signal the end of the project. However, it is important that project closure is managed effectively in order to ensure that: • • • • •
All outstanding deliverables have been accepted All outstanding tasks have been completed Lessons learned from the project may be captured The resources engaged in the project may be formally released The success of the project in delivering the benefits set out in the business case may be evaluated
A post-implementation review should be held with all stakeholders in attendance and a report produced which gives as accurate an assessment as can be given at the time of the above items. This report should be signed off by the IT Steering Group and made available to all areas within the organization that may benefit from it e.g. project management and service delivery.
Version 1
Page 17 of 17
[Insert date]