Skip to main content

The Service Design Package (SDP)

I was recently asked by one of my followers if I might have an example of a Service Design Package (SDP). 

When seeking to implement ITSM and ITIL, we often seek to find examples and models we can use to give us more guidance. This is no less true of the SDP.  Unfortunately when we try to seek out specific examples of a SDP it can often be difficult, if not near impossible. So why is it hard to find actual examples of a SDP? It goes to the very nature of the guidance of what we call best practices. ITIL is not prescriptive as to what should go into a SDP or what one might look like. It provides best practice guidance on the types of items contained, but not the exact look and feel of the content. Therefore each SDP will be unique to the organization that creates it. The organization, type of content, what the content says, and how it is managed are all decisions made by each organization to meet the needs of their customers and users. Just like a Service Catalog or a set of Service Level Agreements are unique, the SDP may not mean anything to someone outside the organization that is providing that service and has that particular group of customers or users.  It may also contain proprietary or confidential information. 

At a minimum the SDP should address the Five Aspects of Design: the services, tool, architecture, metrics and processes needed to deliver value to the business or end users. For some organizations this might be a long list of items, for others a few diagrams, lists, or tables of data and information. The SDP is a formal collection of information that moves with the service as it proceeds through its lifecycle, rather than being an odd collection of randomly associated documents. The key to a successful SDP is that it contains all the information needed by the Service Transition processes to build, test, configure, release and deploy the services and their underpinning components.


Hi 'Professor'

Spot on message. Funny how folk expect ITIL to be simply rolled out to the 'edges' of an organization just by opening the Core Publications. We have put together a series of articles entitled ' Itil in Practice' which maybe of interest to you, take a look at . If you consider it we would like to publish your SDP article.
Anyway, great article and of great value and benefit to those thinking of or are adopting ITIL best management practices.
Kind regards
Brady said…
One of the big improvements with the recent publication of ITIL 2011 is that the guidance includes a lot of templates in the appendices. At the end of Service Design are appendices that list the typical contents of an SDP, the Capacity Plan, SLAs and OLAs, Service Acceptance Criteria, etc.
Brady said…
One of the big improvements with the recent publication of ITIL 2011 is that the guidance includes a lot of templates in the appendices. At the end of Service Design are appendices that list the typical contents of an SDP, the Capacity Plan, SLAs and OLAs, Service Acceptance Criteria, etc.
Unknown said…
I'm sure many companies have examples of how they follow the "guidelines", it is neither inappropriate or impossible. The whole point is not to reinvent wheels. Surely examples do not need to be prescriptive
Unknown said…

if i am designing an app for my university in order to pay the fees and all,what would be the compliance requirements ,Architectural constraints and interface requirements in designing the service design package?

Hi Paul,

The short answer is that the SDP would have ALL of the documents and information related to how the app was designed and developed including any policies or known compliance or other constraints. The purpose of the SDP is to provide a living set of knowledge assets that can be passed around the lifecycle for use in each stage (e.g., deployment, operations, support, updating, etc.)

The Professor

Popular posts from this blog

What is the difference between Process Owner, Process Manager and Process Practitioner?

I was recently asked to clarify the roles of the Process Owner, Process Manager and Process Practitioner and wanted to share this with you. Roles and Responsibilities: Process Owner – this individual is “Accountable” for the process. They are the goto person and represent this process across the entire organization. They will ensure that the process is clearly defined, designed and documented. They will ensure that the process has a set of Policies for governance. Example: The process owner for Incident management will ensure that all of the activities to Identify, Record, Categorize, Investigate, … all the way to closing the incident are defined and documented with clearly defined roles, responsibilities, handoffs, and deliverables.  An example of a policy in could be… “All Incidents must be logged”. Policies are rules that govern the process. Process Owner ensures that all Process activities, (what to do), Procedures (details on how to perform the activity) and the

Four Service Characteristics

Recently I came across several articles by researchers and experts that laid out definitions and characteristics of services. ITIL provides us with a definition that can help drive the creation of value-laden services: A means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks. An area that ITIL is not so clear is in terms of service characteristics. Several researchers and experts put forth that services have four basic characteristics (IHIP): ·          Intangibility—Services are the results of actions not things. They have no physical presence and represent a logical set of elements. One way to think of service is “work done for others.” ·          Heterogeneity—Also known as “variability”; services are unique items because of the mechanisms used to deliver services-that is people. Because the people element adds variability, the service is variable. This holds true especially for th

How Does ITIL Help in the Management of the SDLC?

I was recently asked how ITIL helps in the management of the SDLC (Software Development Lifecycle).  Simply put... SDLC is a Lifecycle approach to produce the software or the "product".  ITIL is a Lifecycle approach that focuses on the "service". I’ll start by reviewing both SDLC and ITIL Lifecycles and then summarize: SDLC  -  The intent of an SDLC process is to help produce a product that is cost-efficient, effective and of high quality. Once an application is created, the SDLC maps the proper deployment of the software into the live environment. The SDLC methodology usually contains the following stages: Analysis (requirements and design), construction, testing, release and maintenance.  The focus here is on the Software.  Most organizations will use an Agile or Waterfall approach to implement the software through the Software Development Lifecycle. ITIL  -  is a best practice for IT service management (ITSM) that focuses on aligning IT services with