Do ITIL for the Right Reasons: Lifecycle Adoption

There have been lots of articles and blog posts written about not implementing or "doing" ITIL. That we still see these articles means there is still a need for the fundamental message. So, let's take a totally different approach drawn from ITIL itself.

It starts with a basic question: What is a closed-loop system? Before answering this question, you might respond by asking, "That sounds a bit technical. What does the concept of a closed-loop system have to do with an article about ITIL lifecycle adoption? What does a closed-loop system have to do with ITIL, period?" The answers might surprise you. To avoid a technical answer, we need a little background and four definitions drawn from ITIL v3.

First, we need to establish a frame of reference: Typically attempts at implementing ITIL processes or doing ITIL fail. One of the purposes for this article is to make that point clear. For now, ITIL v3 isn't about process (though there are clearly more than 20 processes documented in the five core books). This makes it easy to fall into the mental trap thinking that ITIL is merely doing or implementing the documented process. That's only a very small part of the much larger picture. ITIL isn't the end. Implementing or doing ITIL suggests it is. No, the real goal isn't ITIL! ITIL is a descriptive framework that describes best practice for IT service management (ITSM).

ITIL v3 takes everything in prior versions of ITIL (plus processes and functions that existed in many organizations but weren't formally documented in v2) and reorganizes the information around the concept of lifecycles. This recognizes the realities that services are conceived, created, transitioned into operation, and eventually outlive their usefulness only to be retired. Existing services are subject to change either to correct a problem or to add (improve) functionality. From the time the service is approved and chartered, it's subject to potential improvement.

Processes support services ― not the other way around. This is an important point. ITIL isn't the goal, it's the use of the ITIL best practice processes that allow an organization to work toward IT service management; with ITIL processes supporting IT-based services.

Just to make the point, ITIL processes don't exist in isolation. For example, Demand Management (documented in the Service Strategy book) works with and feeds information to Capacity Management (documented in the Service Design book). Demand, as the Service Strategy book suggests, pulls capacity. In fact, the book contains the following sentence: "Demand and capacity are far more tightly coupled in service systems even when compared with just-in-time (JIT) manufacturing."

In other words, ITIL is about ITSM. The processes it describes are not the end, they are set in the context of understanding service lifecycles. But this raises questions about four specific areas; the four definitions we need to understand the closed-loop system: service, service management, lifecycles, and service management lifecycles.

Let's take them one at a time:

ITIL v3 defines a service as: "A means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks." What does this mean?

Twenty-five years ago Peter Drucker wrote in the book Innovation and Entrepreneurship, that "[q]uality in a product or service is not what the supplier puts in. It is what the customer gets out and is willing to pay for." A bit later in the book is this sentence: "Customers pay only for what is of use to them and gives them value. Nothing else constitutes 'quality'."

According to Drucker it's the customer belief (or perception) of quality that's important. This means IT needs to understand the outcomes, including appropriate levels of service that customers want/need IT to facilitate. What the customer values is the link to quality. In fact, the ITIL glossary defines quality as: "The ability of a product, service, or process to provide value."

What about the costs and risks part in the definition of service? Consider you arrive home and it’s dark. You enter the house and flip the switch and expect the lights to come on. You don’t care about what your electric utility had to do to generate, distribute or get into your home. You just want light when you flip the switch. If there happens to be a power failure it’s their responsibility, not yours. IT customers view IT as a service provider, in exactly the same way you view your electric utility. They just want to push (or click) a button and have things work.

ITIL defines service management as: "A set of specialized organizational capabilities for providing value to customers in the form of services."

Again, there's the concept of value.

What about the, "specialized capabilities" part, what does that mean? Among other things, it refers to crafting a cohesive, coordinated and controlled mechanism to discover, understand, and deliver services that facilitate the right outcomes while removing constraints (costs and risks) for customers.

Consider the earlier comment about the link between Demand and Capacity management and what it suggests is that the, "specialized capabilities," include this type of communication and coordination between processes. The concept of specialized organizational capabilities also precludes process silos, processes that exist in isolation, processes that are implemented as discrete processes devoid of any lifecycle considerations, even if they use ITIL as the source.

This is one of the reasons I suggested that implementing processes isn't the goal for ITIL. The same types of relationship discussed about demand and capacity management exist between every other ITIL documented process.

Moving on ― the definition for a lifecycle: "The various stages in the life of an IT service, configuration item, incident, problem, change, etc. The lifecycle defines the categories for the status and the status transitions that are permitted."

The lifecycle definition suggests a degree of control (defined categories, status, and status transitions). In other words, we see the concept of control inherent in both the concepts of service management and lifecycle ― a type of referential integrity.

We're almost ready to get back to the closed-loop system question but we still need the definition for service management lifecycle: "An approach to IT service management that emphasizes the importance of coordination and control across the various functions, processes, and systems necessary to manage the full lifecycle of IT services. The service management lifecycle approach considers the strategy, design, transition, operation and continual improvement of IT services."

Now we have it explicitly. When considered across the lifecycle, service management includes coordination and control between functions (teams or groups of people and their tools), processes (structured and measurable sets of activities designed to produce a specific outcome for a stakeholder), and systems (one or more related things that work together in a connected way to achieve an overall objective).