Sms doc 050 1 design and transition of new or changed services process

Design and Transition of New or Changed Services Process

ISO/IEC 20000 Toolkit Version 6 ŠCertiKit 2016

Design and Transition of New or Changed Services Process

Implementation Guidance (The header page and this section must be removed from final version of the document)

Purpose of this document The Design and Transition of New or Changed Services 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:2011 standard are addressed by this document: 5. Design and transition of new or changed services 5.1 General 5.2 Plan new or changed services 5.3 Design and development of new or changed services 5.4 Transition of new or changed services

General Guidance This is a significant area of the standard that has been enhanced in the 2011 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 organisation 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.

Toolkit Version Number ISO/IEC 20000 Toolkit Version 6 ŠCertiKit 2016.

Document Fields This document may contain fields which need to be updated with your own

Version 1

Page 1 of 17

[Insert date]

Design and Transition of New or Changed Services Process

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 on the ribbon) 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 i.e. so that they are no longer updateable, then 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 then go to File > Options > Advanced > Show document content > Field shading and set this to “Always”. This can be useful to check that you have updated all fields correctly.

Further detail on the above procedure can be found in the Toolkit Completion Instructions within the Project Resources folder.

Copyright notice Except for any third party works included in this document, as identified in this document, this document has been authored by CertiKit, and is © copyright CertiKit except as stated below.

CertiKit is a trading name of Public I.T. Limited, a company registered in England and Wales with company number 6432088 and registered office at 5 Falcons Rise, Belper, Derbyshire, DE56 0QN.

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.

Disclaimer Please Note: Your use of and reliance on this document template is at your sole

Version 1

Page 2 of 17

[Insert date]

Design and Transition of New or Changed Services Process

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 3 of 17

[Insert date]

Design and Transition of New or Changed Services Process

[Replace with your logo]

Design and Transition of New or Changed Services Process

Document Ref. Version: Dated: Document Author: Document Owner:

Version 1

Page 4 of 17

SMS-DOC-050-1 1 [Insert date]

[Insert date]

Design and Transition of New or Changed Services Process

Revision History Version Date

Revision Author

Summary of Changes

Distribution Name

Title

Approval Name

Version 1

Position

Signature

Page 5 of 17

Date

[Insert date]

Design and Transition of New or Changed Services Process

Contents 1

INTRODUCTION ....................................................................................................................................... 7

2

PROCESS OVERVIEW ............................................................................................................................. 8

3

PROPOSALS FOR NEW OR CHANGED SERVICES ........................................................................ 11 3.1

4

PLANNING NEW OR CHANGED SERVICES .................................................................................... 12 4.1 4.2

5

PROJECT INITIATION DOCUMENT ............................................................................................................ 12 RAID LOG .............................................................................................................................................. 12

DESIGN AND DEVELOPMENT OF NEW OR CHANGED SERVICES.......................................... 13 5.1 5.2

6

BUSINESS CASE ....................................................................................................................................... 11

SERVICE REQUIREMENTS SPECIFICATION ............................................................................................... 13 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 ITSM Database ............................................................................................................................. 15 6.3.2 Service Level Agreement ............................................................................................................... 16 6.3.3 Service Catalogue ......................................................................................................................... 16 6.3.4 Budgets ......................................................................................................................................... 16 6.3.5 Supplier and Contracts Database ................................................................................................. 16

7

PROJECT CLOSURE .............................................................................................................................. 17

List of Figures FIGURE 1 - DESIGN AND TRANSITION OF NEW OR CHANGED SERVICES PROCESS ........................................................ 10

Version 1

Page 6 of 17

[Insert date]

Design and Transition of New or Changed Services Process

1

Introduction

The purpose of this document is to set out the process for the design and transition of new or changed services in order to ensure that the financial, organisational 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 Design and Transition of New or Changed Services process is documented in the Change Management Policy.

Version 1

Page 7 of 17

[Insert date]

Design and Transition of New or Changed Services 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, organised 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 design and transition of new or changed services 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 [Service Provider] 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 organisation, including [Service Provider]. This means that [Service Provider] will have an opportunity to discuss the project at each stage, including the agreement of requirements, creation of design and handover to delivery.

The design and transition of new or changed services 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.

Version 1

Page 8 of 17

[Insert date]

Design and Transition of New or Changed Services Process

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, individual changes rather than the overall planning of the handover from Project to [Service Provider].

For example, the design and transition of new or changed services 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 or a new network link is put in, resulting in a material change to the installed base.

Version 1

Page 9 of 17

[Insert date]

Design and Transition of New or Changed Services Process

Design and Transition of New or Changed Services Process

Proposal PROJECT STAGES

SERVICE DOCUMENTATION

Steering Group Approval

Planning

Steering Group Approval

Design and Development

Steering Group Approval

Transition

Steering Group Approval

Project Closure

Project Initiation Document

Business Case

Service Requirements Specification

Service Design Specification

Service Acceptance Checklist

RAID Log

Highlight reports

New Incident Models Problems and Known Errors New Service Requests New Configuration Items Event Management Service Reporting

ITSM Database

Project Management Documents

Post-Project Implementation Review

Release and Deployment Plan

Project Plan

Service Level Agreement

Service Catalogue

Budgets

Supplier Contracts Database

Figure 1 - Design and transition of new or changed services process

Version 1

Page 10 of 17

[Insert date]

Design and Transition of New or Changed Services 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 organisation (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: a) b) c) d)

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: a) The expected benefits are still achievable b) Costs have not escalated to the point where they outweigh the benefits c) Alternative options have not become more attractive due to internal or external changes e.g. company re-organisation, mergers and acquisitions, legislation d) 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 on-going feasibility.

Version 1

Page 11 of 17

[Insert date]

Design and Transition of New or Changed Services 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, development 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:    

Risks to the success of the project Actions agreed during project meetings Issues that are affecting the project 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]

Design and Transition of New or Changed Services Process

5 Design and Development 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 ITSM 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 [Service Provider] 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 Monitoring and event management (databases, networks, errors etc.)

IT service continuity provisions

Version 1

Page 13 of 17

[Insert date]

Design and Transition of New or Changed Services Process



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]

Design and Transition of New or Changed Services Process

6 Transition of New or Changed Services Once the new or changed service has been developed 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 [Service Provider] 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 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 o Details of all known errors with the service that were not resolved prior to live running

Version 1

Page 15 of 17

[Insert date]

Design and Transition of New or Changed Services Process

 



6.3.2

Configuration Management o New configuration items will be added to the CMDB 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 IT Service Continuity and Availability o The IT Service Continuity Plan 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 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 IT 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]

Design and Transition of New or Changed Services 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 organisation that may benefit from it e.g. project management and service delivery.

Version 1

Page 17 of 17

[Insert date]