Service Design Package

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.

What is a Service Design Package?

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;

• Scope - what a service is
• Users / Location - who it can be consumed by
• Compliance - the business, regulatory and statutory constraints that it has to exist within
• Requirements - the warranty, utility, quality and satisfaction characteristics that it has to meet
• Processes - that will be used to manage the service on a day-to-day basis
• Products - the tools that will be used to deliver the service. This includes everything from SaaS solutions to bespoke applications
• Partners - the sub-contractors you use to deliver parts of the service
• People - the individual roles and functions that will govern and manage all of the above

“Good service starts, and ends, with having great people..”. Source: me

What should it be?

An SDP should be the definitive source of information for anyone requiring an understanding of 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 overlapping, documents that are regularly reviewed and maintained to ensure currency.

What should be included within an SDP?

The following is based on my years of experience in designing and building ITSM solutions as part of a Managed Services provider.

Depending on your situation e.g. internal service 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.

Service Description - the what and the when…

A Service Description is a 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;

• Contractual Service Description - part of a customer/supplier legal agreement where what is being delivered needs to be concise
• Service Catalogue (Public) - part of your businesses website/marketing collateral where you describe the services you offer
• Service Catalogue (Internal) - the portal where your internal IT department lists the services that users get as standard or that can be ordered

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.

Service Management Design - the how and tho who…

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, the 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 of relatively mature and emergent technologies, the following should be considered;

• Integration
• Robotic Process Automation
• Artificial Intelligence
• Augmented and Virtual Reality
• Smart Locker / Vending solutions
• Self-healing systems

DATA MAP - crucial to both understanding where the data 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, 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 a 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 life and ongoing.

TECHNICAL REFERENCE DOCUMENTS - such as…

• Enterprise Architecture
• High-Level Designs for Networks, Applications, Infrastructure, Integrations, Enterprise Management, Data Management
• ISMS, Role Based Access Controls etc
• Disaster Recovery, Backup, Recovery and Data Retention

Ops Policies, Processes and Procedures

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…

• Incident, Problem and Event
• Call Handling, Knowledge Articles and escalation management
• Major Incident Management
• Change (Normal, Standard and Emergency), Release, Knowledge and SACM
• Information Security, SIEM, Access Control etc
• Applications Management, Agile and DevOps
• Capacity and Availability
• IT Service Continuity
• Technical Management, Patch Management, On-Premise vs Hybrid vs Cloud and Technical Refresh
• Request Catalogue and Fulfilment
• Management Information, Billing and Invoice to Cash
• Continual Service Improvement

Things to avoid…

Based on my, not inconsiderable experience, try to avoid the following.

• Trying to fit all of the above into a single document, it doesn’t work and creates a monolithic document that no one, other than insomniacs, will want to read
• Re-inventing the wheel, re-use is awesome and helps to create consistency (as long as it is consistently good!)
• Repetition, say it once and cross reference, where practical. Adopting a Document as Code approach can greatly help with this

In our company, we all have 2 jobs: 1) to do our job and 2) to improve it - Toyota

A final word…

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…