Establishing a Service Design Methodology

As more IT organizations adopt the processes of the IT Infrastructure Library (ITIL®), the turf wars continue between the application development groups and the "infrastructure groups" (anyone who doesn't develop software) around the use of a Systems Development Lifecycle (SDLC) or the use of ITIL. As I wrote in a previous DITY, while it is an interesting question, "...it is the wrong question to ask."

I think anyone who has participated in this kind of battle will have to admit that arguing that the ITIL has the best approach is a hard position to defend. The simple fact of the matter is that it doesn't. Or probably a better way to spin it, it has a rather immature approach to the entire subject of service design.

Yes, even though there is an entire book of the IT Service Management Lifecycle dedicated to it, a seasoned IT professional has to take the whole approach with a "grain of salt." Although there is a lot of good guidance in the Service Design volume, it is missing two critical aspects necessary for achieving the status of the "grand universal practical guide to designing IT Services."

Okay, so what's wrong with it? A quick look at the five aspects of Service Design gives us the first clue:

1. Requirements Gathering
2. Design Supporting Management Systems (in effect lifecycle phase support)
3. Design Architecture & Supporting Technology
4. Design Support Processes
5. Design Measurement Systems

The second clue comes from looking at the processes of the Service Design phase:

• Service Catalog Management
• Service Level Management
• Information Security Management
• Capacity Management
• Availability Management
• IT Service Continuity Management
• Supplier Management

The third clue is when you look at the diagram below and ask the simple question, "How does the ‘design process' work?"

Okay, there it is; there is no "design process!"

Or more to the point, despite much good advice and guidance, there is no controlling, or overarching mechanism that causes an IT Service design to have a "beginning, middle and end."

I resorted to making up something that I call a "service design bus" so I could explain the bi-directional flow of information among the Service Design "processes" (processes is in quotes, because most are grouped capabilities, not processes, but that is a subject of another DITY).

But there is no "bus controller," "dispatcher" or "ticket-taker."

... and there is nothing that would lead the ITSM process implementer to adopt or design a design methodology that addresses the comprehensive needs of both the hardware and software sides of an IT Service design.

Now many "ITIL purists" will argue that the role of "overarching control" falls to the organization's program and project management methodology. However, the "ITIL pragmatists" understand that many IT organizations' program and project methodology comes out of a shrink-wrapped box of software and has a 15-page user's guide.

Bolt-on Process

Since we have been told that there will not be an ITIL v4, I suggest that any would-be implementer of the Service Design processes consider bolting on another process to the Service Design phase of the IT Service Management lifecycle. Actually, it is more of a "copy and paste" of a process from the Service Transition phase – the Planning & Support process.

A Service Design Planning & Support process would be responsible for:

• Promoting the adoption of a common design methodology
• Ensuring that the Service Design processes align with the Business' desired outcomes
• Identifying and controlling risks associated with the design processes
• Planning the capacity and resources necessary to produce the service design
• Supporting the design teams
• Coordinating design activities across projects, suppliers and service teams

Having such a process would not eliminate the need for program and project management, but it would provide a standardized set of activities and tasks, associated with a standard design methodology that could virtually "plug into" a standard project template.

Bolting it On

There is currently a role in Service Design called the Service Design Manager. I liken it to being "an ambassador without portfolio"; it is a role without any supporting processes or activities.

Standing up a Service Design Planning & Support process would address this through the establishment of Service Design policies that would include the adoption or design and development of a standard design methodology, program and project management integration, the establishment of the required technology architectures, management of stakeholder relationships, knowledge transfer and service team support.

Applying a Method to the Madness

I noted earlier that there is no "design process." Often when process and methods are discussed, the terms are used interchangeably. While similar, they have a distinct difference.

A process is a sequence of operations or events over time which produce desired outcome. Processes are made up of a series of actions, events, or steps which contain methods.

A method is a way of doing something in a systematic way by the orderly arrangement of specific techniques. Each method has a process. From the perspective of an "ITIL pragmatist," a service design methodology would deal with the "how" of designing a service and define the "when" things will happen (time sequence of events or actions).

Design methodologies are often supported by tools, but are not dependant on them. So, those among you who start salivating (or sweating) at the prospect of "yet another tool" can calm down. There are a large number of design conceptual models and frameworks to choose from as a starting point. Pick the one that best fits the culture of your organization; remember you can get anyone to do what they want to do. Managing the cultural change is actually more of a problem than the actual design of an appropriate design methodology.

Summary

I had an occasion to speak to a large gathering of senior IT executives a couple of years ago. I was talking on the topic of IT Service planning and design. I asked my audience to raise their hands if they would fly on an airplane designed using methods used by their IT shops. Out of over one-hundred attendees I only had one person raise his hand. It turns out he ran the IT shop for a nearby nuclear power plant.

Studies over the past several decades have all drawn the similar conclusion that over 80% of system (service) errors can be traced back to a failure in the design of the service. It stands to reason as a practical matter that an IT organization considering implementing the processes of the Service Design phase of the IT Service Management Lifecycle consider bolting on a planning and support process and adopting a standard design methodology.