Using the Service Design Package to Transfer KnowledgeIf communication between your teams is an issue, ITIL v3 has an app for that, writes ITSMWatch columnist George Spafford.
For example, even though a lot of knowledge is gained during testing, known errors arent always communicated to the service desk and the incident and problem resolution teams. This leads to diminished effectiveness―as opposed to knowing these matters before new or changed services are rolled out. With ITIL v3, thought has been given about improving the transfer of knowledge. One new construct, the Service Design Package (SDP), can markedly improve knowledge transfer if it is designed and implemented with the supporting processes correctly.
ITIL identifies that the Service Design Manager role is responsible for service quality, which is the collection and documentation of requirements and then conformance to those requirements. This role is also responsible for the creation and maintenance of the Service Design Package (SDP), which formally documents the aforementioned business, service and operational requirements plus much more. In a sense, the ideal SDP provides the reader with everything there is to know about the design of the service including past, present and future plans.
To support IT service management (ITSM) efforts overall, the SDP is a powerful and critical element. We understood the need to document total service requirements prior to ITIL v3 and now we have not just suggestions for the process but the SDP as well.
In the Service Design volume, not only do we have processes for consideration but there is also a very interesting hidden jewel in the back of the book. It is Appendix A The Service Design Package and is definitely must-read for organizations who understand that knowledge needs to be formalized and transferred in a more formal, timely and accurate manner.
Building on this appendix, the SDP should cover the following broad categories:
- Header This contains the unique record/configuration item ID for the SDP itself, the applicable service, change control information, and so on.
- Requirements These are the business requirements, scope of the service plus stakeholder contact information.
- Service Design Contains the holistic service requirements including functional requirements, service level requirements, operational requirements, and the architecture of the service and its various component configuration items including relationships.
- Organizational Readiness Assessment This is the business case that outlines the expected benefits and costs plus assessments of the required resources and capabilities of the service provider.
- Service Lifecycle Plans Includes overall program information, transition plans, operational acceptance and service acceptance criteria.
The SDP has two huge benefits for IT. First, having a well thought out template that supports the organizations processes helps the various IT stakeholders to understand from what must be defined and implemented in a service. The template helps reinforce a standard approach. Second, anyone with a question about a service knows where to go initially for an answer; ambiguity is tremendously reduced at multiple levels.
For example, if in the SDP, the Service Transition plan identifies policies and standards around monitoring and event management, then the design teams will understand that they must design and document in these areas. The development groups understand what they must create and document. The test groups then have an idea what will be needed in the design and execution of test plans. Once in operation, if someone has a question about event, then they know not only to check the SDP but also what section of the SDP.
For groups considering how to start their SDP effort, there are many approaches. One is to use a document template with the users completing the necessary sections or submitting their input to the Service Design manager who owns the creation and updating of the file. Another is to use a database to store data coming from an application. The usual benefits of using a database and application exist such as structured data, rules, granular security, audit logs, and so forth.
With that said though, the important need is to define and implement the processes that enable the creation and management of the SDP not to mention the actual use of it. The main point is that there are many ways to begin process improvement efforts and gather benefits without huge tool investments. It would be better to start with a basic SDP and evolve over time vs. never starting due to lack of funding for a tool.
One important tip: the SDP isnt a one-time document or database record. It must be maintained as changes are introduced. This means that Change Management, Release & Deployment and other relevant processes must be designed to engage Service Design to keep the SDP current in a timely and accurate manner. Also, as a detective control, it would also be wise to audit the SDP at least annually, or after major changes, for accuracy. This will help capture situations where production services do not match the SDP and how this happened should be investigated and processes improved.
In closing, organizations searching for a better way to share knowledge about services should investigate the Service Design Package and the overall Service Design lifecycle phase that governs its creation and maintenance. There are tremendous benefits to be had by formalizing the documentation of requirements and services plans in a structured manner and then making this knowledge available to the stakeholders. IT organizations that havent looked at Service Design and the SDP yet, are strongly urged to do so now.
George Spafford is an experienced consultant, a prolific author and speaker, and has consulted and conducted training on strategy, IT management, information security and overall process improvement globally. He can be reached at email@example.com.