Branimir Valentic It would be easy to say that the Service Design phase of the service lifecycle only cares about design of the service, and – that’s it. Actually, it’s 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 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 Service Transition processes).
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.
Ace in the hole
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 Service Charter. Then, the design phase takes place in which all requirements will be considered (e.g., business requirements, service level requirements, management requirements… 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 operational phase of the service lifecycle.
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.
The Service Design stage of the service lifecycle has a “tool” to handle documentation requirements that spread beyond the design stage – the Service Design Package (SDP). According to ITIL Service Design volume, SDP is defined as “Document(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.” Basically, the SDP is a product of the Service Design phase of the IT service lifecycle.
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’t 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 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.
Form and content
The SDP could be in the form of a single document, or several documents. Generally, it’s 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) – 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).
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.).
Although it exists as an appendix in ITIL Service Design volume and contains extensive examples of the content, let me point out some of the possible content of the SDP.
Table: SDP content
Necessity for structured approach
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. Service Acceptance Criteria (SAC) is a kind of checklist to make sure that nothing gets forgotten. A well-structured SDP goes (at least) one level higher, having in mind that the later a deficiency is detected, the more expensive it gets.
You can find out more about defining clients’ requirements in this free white paper: ITIL implementation in your IT organization.
