First posted: Jul 13 2023
Read time: 7 minutes
Written By: Steven Godson
Greetings!
In this article I will be exploring the concept of the Service Design Package, what it should be and what should be included within its scope.
Service Design Package, abbreviated to SDP, is a term that initially appeared in ITL® v3 which was first published in 2007, is a collection (the package part) of documents and artefacts that describes;
“Good service starts, and ends, with having great people..”. Source: me
An SDP should be the definitive source of information for anyone requiring an understanding on what a service should deliver and how it delivers that service.
It should provide different views so that it can be used by different stakeholders with different perspectives.
It should be useable, accessible and written in plain English (or whichever language is relevant).
It should be a number of complimentary, and not over lapping, documents that are regularly reviewed and maintained to ensure currency.
The following is based on my years of experience of designing and building ITSM solutions as part of a Managed Services provider.
Depending on your situation e.g. internal servicer provider (“The IT department”) or a Managed Service provider (external organisation to the one buying the services), you may consider some of these to not be relevant.
And, depending on your situation, you may be correct. However, all of the following areas should at least be considered when creating an SDP.
A Service Description is the shiny document that, depending on your scenario, your customers and / or users will read to understand what the service is that they are consuming / paying for.
The common scenarios under which these tend to exist are;
However, there is a common set of information, described below, that a Service Description should cover.
SCOPE - this is where you clearly describe what the service is and what it will, and as importantly will not (exclusions), delivers.
SERVICE LEVELS & PATTERNS - this is the level of service that a consumer should expect to receive and when the service will be available to them.
GOVERNANCE - how the service will be governed, who the key points of escalation are and what the measurement periods will be.
CHARGES - inescapable, but possibly less relevant in an internal IT department setting, how much the customer will pay for the service(s) that you are describing is important.
A Service Management Design (or Architecture or Blueprint or…) is the document where you describe how the service is going to be put together to deliver the service.
It covers the various building blocks needed, and how they interact, to deliver the service(s) covered by the SDP.
Typically, in no particular order, this includes;
SCOPE - this is where you clearly describe what the service is and what it will, and as importantly will not (exclusions), delivers.
RCTM - the Requirements Capture and Traceability Matrix where all the requirements that the service(s) need to meet are captured.
COMPLIANCE - the legislative, regulatory and industry standards that the service(s) need to comply with. Examples include ISO20k, ISO27001, Payment Card Industry (PCI) etc
UTILITY / WARRANTY - what the service(s) provide functionally, the utility, and when the customer / user can expect the service to be available to them, the warranty or Service Levels.
PROCESSES - the ITSM processes that need to be used for the service(s), whether there is any “localisation” needed or whether bespoke processes are needed.
TOOLSETS - the shiny toys that the service and support functions will use to underpin the ITSM process and technical activities required to manage the service. Given the availability or relatively mature and emergent technologies, the following should be considered;
DATA MAP - crucial to both understanding where the data that will feed into your billing and performance measurement of the service, as well as helping you to understand your position as it relates to data residency and access legislation / regulations.
Data is like garbage. You’d better know what you are going to do with it before you collect it. - Mark Twain
ROLES & FUNCTIONS - the individual roles and functions, within your organisation, that will perform day to day management or technical support functions to support the service(s). Examples are Service Desk, Security Operations Centre, Service Delivery Manager or Release Management.
PARTNERS / SUPPLIER MANAGEMENT - the third parties, and how they will be managed / governed, they will deliver aspects of the service(s). Thought needs to be given as to how Service Levels will be flowed down to them.
INFORMATION SECURITY - either described separately, or interwoven into all of the above, a description of how Information Security will be managed against the defined Information Security Management System (ISMS).
It takes 20 years to build a reputation and few minutes of cyber-incident to ruin it. - Stephane Nappo
RAID - the identified Risks, Assumptions, Issues and Dependencies of the service(s), both for the transition to live and ongoing.
TECHNICAL REFERENCE DOCUMENTS - such as…
A service can be described beautifully and designed to within an inch of its life but, when the brown and sticky hits the spinning blades, it is the operational processes and procedures, based on well thought out policies, run by well trained people that will see you through. Consideration should be given to…
Based on my, not inconsiderable experience, try to avoid the following.
In our company, we all have 2 jobs: 1) to do our job and 2) to improve it - Toyota
Ultimately the SDP scope you use has to meet the needs of the business environment that you are working in. Hopefully this article has been of some use and has given you a good idea of the types of areas that need to be addressed.
I wish you well on your ITSM journey…