{"id":4478,"date":"2014-10-07T20:55:42","date_gmt":"2014-10-07T20:55:42","guid":{"rendered":"https:\/\/multiacademstg.wpengine.com\/20000academy\/blog\/2014\/10\/07\/itil-service-design-package-everything-under-one-roof\/"},"modified":"2025-06-13T12:49:04","modified_gmt":"2025-06-13T12:49:04","slug":"itil-service-design-package-everything-under-one-roof","status":"publish","type":"post","link":"https:\/\/staging.advisera.com\/20000academy\/blog\/2014\/10\/07\/itil-service-design-package-everything-under-one-roof\/","title":{"rendered":"ITIL Service Design Package \u2013 everything under one roof"},"content":{"rendered":"<p>It would be easy to say that the <a href=\"\/20000academy\/blog\/2013\/06\/25\/service-design-itil\/\" target=\"_blank\" rel=\"noopener noreferrer\">Service Design<\/a>\u00a0phase of the service lifecycle only cares about design of the service, and \u2013 that\u2019s it. Actually, it\u2019s more complex than that. Namely, Service Design has to take care of inputs that are coming from <a href=\"\/20000academy\/knowledgebase\/itil-service-strategy-itsm\/\" target=\"_blank\" rel=\"noopener noreferrer\">Service Strategy<\/a>, as well as outputs, which means all subsequent phases of the service lifecycle. This means, in the real world, that e.g., business requirements or user requirements (coming from Service Strategy) are a working document during the design phase of the service lifecycle. On the other side, Service Design has to think about the testing phase or e.g., testing requirements as well (done by <a href=\"\/20000academy\/blog\/2013\/06\/11\/service-transition-itil\/\" target=\"_blank\" rel=\"noopener noreferrer\">Service Transition<\/a>\u00a0processes).<\/p>\n<p>This gets us to the point where we need to find a way to consolidate all these documents, plans, information, and knowledge needed to develop a service.<\/p>\n<h2 style=\"padding-top: 10px; padding-bottom: 10px;\">Ace in the hole<\/h2>\n<p>During the Service Design stage of the service lifecycle, the foundation of the service will be built. Service strategy triggers the design stage with the <a href=\"\/20000academy\/documentation\/service-charter\/\" target=\"_blank\" rel=\"noopener noreferrer\">Service Charter<\/a>. Then, the design phase takes place in which all requirements will be considered (e.g., business requirements, service level requirements, management requirements\u2026 etc.) and the service is designed and documented. During the transition phase, the service is built, tested, and deployed. Afterwards, the service is handed over to the <a href=\"\/20000academy\/blog\/2013\/05\/27\/service-operation-itil\/\" target=\"_blank\" rel=\"noopener noreferrer\">operational phase<\/a>\u00a0of the service lifecycle.<\/p>\n<p>So, you see, there are a lot of steps and stages before the service is operational. All of these stages have to be considered during the design phase, because errors during design will have implications in all other stages. To be sure that nothing gets forgotten or omitted, Service Design needs to reference many documents throughout the service lifecycle.<br \/>\n<div id=\"middle-banner\" class=\"banner-shortcode\"><\/div><script>loadMiddleBanner();<\/script><br \/>\n<div id=\"side-banner-trigger\" class=\"banner-shortcode\"><\/div><br \/>\nThe Service Design stage of the service lifecycle has a \u201ctool\u201d to handle documentation requirements that spread beyond the design stage \u2013 the <a href=\"https:\/\/staging.advisera.com\/20000academy\/iso-20000-documentation-toolkit\/?rel=service-design-build-and-transition-processes&amp;doc=service-design-package\" target=\"_blank\" rel=\"noopener\">Service Design Package (SDP)<\/a>. According to <em><a href=\"\/20000academy\/what-is-itil\/\" target=\"_blank\" rel=\"noopener noreferrer\">ITIL<\/a> Service Design volume<\/em>, SDP is defined as \u201cDocument(s) defining all aspects of an IT service and its requirements through each stage of its lifecycle. A service design package is produced for each new IT service, major change or IT service retirement.\u201d Basically, the SDP is a product of the Service Design phase of the IT service lifecycle.<\/p>\n<p>I noticed that companies usually generate most of the documents that we find in ITIL, but I also noticed that, as the implementation project develops, many documents get lost or forgotten, or never get updated. The SDP should ensure that such things don\u2019t occur. Therefore, the SDP needs someone to take care of it. If there is a Design Coordination process in place, then the Design Coordination manager should take care of the SDP. The Design Coordination process is rarely implemented as a stand-alone process that is, consequently, also valid for the Design Coordination manager. There is, rather, a Design Manager as a role and the SDP should be his concern. When the design phase finishes, the SDP is handed over to the Service Transition phase of the service lifecycle. Ideally, the\u00a0 Transition Planning and Support process would be the process that would take over the SDP, but I almost never found such a process in place. Usually, there is a Transition Manager and he takes over the SDP.<\/p>\n<h2 style=\"padding-top: 10px; padding-bottom: 10px;\">Form and content<\/h2>\n<p>The <a href=\"https:\/\/staging.advisera.com\/20000academy\/iso-20000-documentation-toolkit\/?rel=service-design-build-and-transition-processes&amp;doc=service-design-package\" target=\"_blank\" rel=\"noopener\">SDP<\/a> could be in the form of a single document, or several documents. Generally, it\u2019s a directory of all related documents required for effective design of the service. Not all SDPs are the same (like, e.g., not all the project plans are the same) \u2013 it depends on the service and on whether we develop a new service, or make a small, significant, or major change on an existing service. There could even be situations when no changes in the SDP are required (e.g., smaller changes that were done before, when the SDP already exists and could be used as-is).<\/p>\n<p>How do you know when an SDP or changes in the SDP are needed? The Design policy could be of great help. Such policy would define design of the service at a high level (e.g., organization, roles, responsibilities, technology used, produced documentation, etc.) and one of the parameters would be definition of the SDP (e.g., form, content, usage, etc.).<\/p>\n<p>Although it exists as an appendix in <em>ITIL Service Design volume<\/em> and contains extensive examples of the content, let me point out some of the possible content of the SDP.<\/p>\n<p style=\"text-align: center;\"><img decoding=\"async\" class=\"aligncenter size-full wp-image-4480\" src=\"\/wp-content\/uploads\/\/sites\/6\/2015\/07\/Table_81_20blog.png\" alt=\"Table_81_20blog.png\" width=\"749\" height=\"357\" srcset=\"\/wp-content\/uploads\/sites\/6\/2015\/07\/Table_81_20blog.png 749w, \/wp-content\/uploads\/sites\/6\/2015\/07\/Table_81_20blog-300x143.png 300w\" sizes=\"(max-width: 749px) 100vw, 749px\" \/><em>Table: SDP content<\/em><\/p>\n<h2 style=\"padding-top: 10px; padding-bottom: 10px;\">Necessity for structured approach<\/h2>\n<p style=\"text-align: left;\">Services, as well as the business environment, are increasing in complexity. Competition is a catalyst when change of existing services or development of new services takes place. Without a structured approach, it could all easily end in unstructured chaos. <a href=\"\/20000academy\/knowledgebase\/itil-service-acceptance-criteria-keep-control-hands\/\" target=\"_blank\" rel=\"noopener noreferrer\">Service Acceptance Criteria (SAC)<\/a>\u00a0is a kind of checklist to make sure that nothing gets forgotten. A well-structured <a href=\"https:\/\/staging.advisera.com\/20000academy\/iso-20000-documentation-toolkit\/?rel=service-design-build-and-transition-processes&amp;doc=service-design-package\" target=\"_blank\" rel=\"noopener\">SDP<\/a> goes (at least) one level higher, having in mind that the later a deficiency is detected, the more expensive it gets.<\/p>\n<p><em>To implement ISO 20000 easily and efficiently, use our<\/em> <a href=\"https:\/\/staging.advisera.com\/20000academy\/iso-20000-documentation-toolkit\/\" target=\"_blank\" rel=\"noopener\">ISO 20000 Documentation Toolkit<\/a> <em>that provides step-by-step guidance for full ISO 20000 compliance.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"<p>It would be easy to say that the Service Design\u00a0phase of the service lifecycle only cares about design of the service, and \u2013 that\u2019s it. Actually, it\u2019s more complex than that. Namely, Service Design has to take care of inputs that are coming from Service Strategy, as well as outputs, which means all subsequent phases &#8230;<\/p>\n","protected":false},"author":32,"featured_media":17209,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[391,425,344,204,346,385,347,386],"class_list":["post-4478","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog","tag-change","tag-csi","tag-itil","tag-service","tag-service-design","tag-service-operation","tag-service-strategy","tag-service-transition"],"acf":[],"_links":{"self":[{"href":"https:\/\/staging.advisera.com\/20000academy\/wp-json\/wp\/v2\/posts\/4478","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/staging.advisera.com\/20000academy\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/staging.advisera.com\/20000academy\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/staging.advisera.com\/20000academy\/wp-json\/wp\/v2\/users\/32"}],"replies":[{"embeddable":true,"href":"https:\/\/staging.advisera.com\/20000academy\/wp-json\/wp\/v2\/comments?post=4478"}],"version-history":[{"count":3,"href":"https:\/\/staging.advisera.com\/20000academy\/wp-json\/wp\/v2\/posts\/4478\/revisions"}],"predecessor-version":[{"id":18411,"href":"https:\/\/staging.advisera.com\/20000academy\/wp-json\/wp\/v2\/posts\/4478\/revisions\/18411"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/staging.advisera.com\/20000academy\/wp-json\/wp\/v2\/media\/17209"}],"wp:attachment":[{"href":"https:\/\/staging.advisera.com\/20000academy\/wp-json\/wp\/v2\/media?parent=4478"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/staging.advisera.com\/20000academy\/wp-json\/wp\/v2\/categories?post=4478"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/staging.advisera.com\/20000academy\/wp-json\/wp\/v2\/tags?post=4478"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}