A thought on making service design better

I have a theory to share with you: I think that many IT organizations are short-changing themselves by not thinking about service design in a holistic manner. Specifically, they don’t think about how “solving to the left” — that is during design — can prevent problems during transition and operations.

First, there is no realization as to what the end result of the design phase is. According to ITIL, what leaves the design phase is a new or updated service design package (SDP) which is, in essence, the blueprint for your service. Like any other blueprint, say for an airplane or a building, it has all the necessary information needed to build, test and operate that which it defines. The problem, and the generalized perception in IT, I think is that a) “Technology changes so fast we really can’t go back to the drawing board to create a design” (not an excuse) or b) “Well, we are doing availability, capacity and service continuity. We’re good. Right?” (Yes. But…)

For the first part of the problem mentioned above, I think that the perception of creating an SDP is that it is way too much work, and “no one needs to create a stinkin’ design document in the first place because who will read it in the first place?” However doing good systematic and holistic service design activities is very healthy to the organization, since it can actually make you think about how all of the different parts integrate and work together.

For the second part, yes you may be doing some service design activities. But very often they are done as an extension of operational (i.e., reactive) activities. When something happens to your availability, capacity or SLA targets, organizations tend to react. Thus these activities, when executed reactively, are glorified extensions of event management. You may do some improvements to the fundamental design of a component, a server or an application, but you’re really not improving the service. And by the way, you may not be incorporating lessons learned as improvements of the design.

In my mind, a design is not set in stone; there are always things to improve. What makes design activities highly valuable to your organization is the integration of key resources and capabilities in a single, all-encompassing activity that considers all the characteristics of an end-to-end service, and the value it brings to the business as a whole. You might be thinking that there is no way your organization can afford to “go back to the drawing board now” after an IT service has been in operation for some time.

But I would challenge that notion and say that revisiting a service design package is one of the best ways to improve a service. For example, when an issue is fixed after some problem analysis, and it is recognized as having to do with design, that improvement becomes a permanent feature of your service’s fundamental design. Improvement upon improvement, your services and the capabilities and resources that work to deliver it, should also become better at delivering the service based on the found improvements.

It is also through the improvement of the service that other “downstream” improvements stemming from service design can be acted upon and improved. For example, new knowledge to create, improvements in the data structure of the configuration management database, or new information for the service desk to use. If all the required resources are actively participating in the improvement of the project, all of them should see beneficial and actionable improvement actions related to the service.

There are two possible ways you can do this.

First, treat the design as a minimum viable product. I’m sure you’ve heard about this. I’ve seen it defined as “the smallest thing you can build that delivers customer value.” I am sure that you have delivered whatever it is you do for a while. That can be your starting point to document your service blueprint and all its parts, requirements and components. It does not have to be a lengthy document, just the key requirements and components at a level that is easy to understand by everyone relative to the value the service is provided. Think about a well-formatted wiki page, or a knowledge article in any leading ITSM tool set. But, in order to do this you have to get all of your resources together, including both the operations people (and especially the service desk) and the customer to fully understand what is valuable.  Yes it may take a while, which brings me to my second point.

Second, treat it as a series of continuous improvement (kaizen) events. As you know, kaizen is a philosophy of working continuously to improve. What you want to do is a improve iteratively, without pause, to achieve the result which is a living, adaptable and always-up-to-date SDP. Empower and challenge your resources to iteratively build this. Give them an objective, time and space to understand and build them and also make them understand that this mentality of continuous improvement has to become the mantra of your organization.

I contend that ITIL service design activities are more than just input/output transforming “processes.” They are capabilities and skills that work best when executed together and continuously in a holistic fashion that produces continuous, iterative improvements. They have no beginning and no end; they should be a part of your IT organization’s core competencies. As a matter of fact, I think you should never be “done” with service design.

When the next big thing hits your service operations group, and before you start blaming your service desk or change management, ask yourself this question: “Could we have designed our services better so that his never happened in the first place?”