CA Community






This Blog

Is the Service Design Package One of ITIL V3’s Unsung Heroes?

Published: September 07 2009, 03:19 PM
by Peter Doherty

I have blogged quite a bit about Service Portfolio Management so it is logical that the Service Design Package (SDP) should also be one of my heroes of V3. Why you ask? Well it is not necessarily just what is in the book as that will always be added to in real world implementations. It is this: I think of the SDP as the ecosystem that supports the Service. It is the thing that nurtures a Service through the embryonic stages of the Service being created in the vacuum that is (or more correctly, was) known as ‘Development’, it wraps itself around the Service to ensure a quality Transition, and surrounds the Service with the support processes as it lives and breathes in the ‘Run’ world. It provides the description of what the ecosystem required to support the Service from inception to retirement.

This may not be intuitively obvious as you read through the Service Design books but to some it just jumps off the pages and it is a true testament to the Service Lifecycle philosophy!

Just think about many people's (but not all) approach to delivering a Service, or more correctly an application or system. Traditionally organizations focus on the functional specifications of the system and the architecture to support it and that's what is packaged up to be thrown over the wall into production. Before it even hits the other side the project leaders are turning their back and walking away to start on their next project. It is no wonder that many Services are almost on the critical list from day one of production.

This could not be further from what should happen in the SDP, and like a Service itself, the SDP is a living thing, constantly growing as it moves forward and having different parts of the ecosystem added to it. Of course some parts will need to be locked down such as the traditional functional requirements.

The SDP should contain the functional and architectural definitions to support and return the business value that the Service is predicated on. It should look at the broader Services that it may touch as well as the organisational competencies that will be required to support it. Any process changes will be included as well as the RACI model which will flow into Learning programs. It will include measurement and management that needs to be instrumented into it so as it has a smooth interlock with Event Management as well as describing the level and type of Knowledge required supporting it. The Service Level expectations will be included as well as how to measure them as well as the types of metrics necessary.

For many of these things it will provide the high level direction whilst the detail will be the responsibility of the individual process owners. This is again an example of how V3 concentrates on producing process interlocks to break down process silos.

Now all the above sounds like goodness and one might ask the question, "What is the value of all this work?" For me it is quite simple; Quality. Quality from a holistic view, making sure that everything that is needed to provide utility and warranty is thought about up front and then delivered on.

The SDP does not tell you how you should do these things, it does point out that they are important and ignore them at your peril!

The ITIL Ninja gives the SDP 5 Shuriken (stars)!

 

By: Peter Doherty
Peter Doherty is an ITILv3 contributing author and a Principal Consultant for CA. With 25 years IT experience in Service Management as well as Enterprise Network and Systems Management, Peter Doherty is CA’s foremost Service Management evangelist in the Asia Pacific region. His day-to-day responsibility...
Read More..

Comments:

No Comments

Leave a Comment

* An asterisk indicates a required field

* :  

:

* :  

 Submit