Blogs

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.

--
Originally posted By Professor P. Ross S. Wise to www.itsmprofessor.com