Having a go at ITIL’s flow

In ITIL’s best practice view of the world, services are thought of in strategy, they’re designed, transitioned and put into operations in a specific lifecycle. This is how services are born and retired, or so it says. Continual service  (CSI) is done in support of all the activities, or is supposed to be done like that. We all know that ITIL is documented common sense, but we know that reality is very different.

You see in many places services, and sub-services, are there for ages. New services can be introduced, but it doesn’t happen that often. What does happen is the replacement of one technology over the other (think about upgrading from one version of Exchange to another). You can say that the service is different since it can bring new technological features, but it, at it’s core, is the same service. Technology comes and technology goes, but the fundamentals of the service should still provide value regardless of the underpinning technologies.

The problem is that many IT shops don’t quite follow ITIL’s proposed lifecycle flow. They “live” mostly in operations, and transition is performed poorly (mostly change and configuration. And configuration is really immature). It is indeed a sad state of affairs. But, what would happen if we looked at ITIL’s flow from another perspective?

Let’s use LeanIT’s concepts of value stream mapping, flow and unit of work. Visualize a value stream mapping and place ITIL’s lifecycle close to one another. Strategy, design, transition and operations fit together quite nicely and you would think that the unit of work, the service, will flow from strategy to operations logically. And that would be fair. But where would you put CSI? At the end? In the classic ITIL circular diagram, CSI goes around all of the other lifecycles. At the top of all of the other activities? Maybe, but that is not quite the way I envision it.

Having recognized that 80% of the services are quite established, then what could ITIL’s unit of work could be? Here’s my thought: improvements.

Go back to the value stream mapping image I drew for you. Now change the image of the unit of work from a service to an improvement. How would that look like? There may be multiple entry points in the value stream; maybe some improvements​ go through each lifecycle stage, or they may go through a few. But you have a unit of work that could potentially traverse each lifecycle stage, and as it moves along the value stream, it picks up and delivers value. Not only that but if you visualize it this way, you can identify potential waste factors or impediments that stand in the way of the improvement, and take action to remove them from the value stream.

How would this work in practice? Say you have identified an improvement in operations. You would need to gather key stakeholders, the business in included!, to look at the value stream of the service and determine where the improvement, the unit of work should start. Did you miss understanding user profiles? Then start at strategy. Do you need to revisit design specifications, service level agreements, vendor contracts or your capacity plans? Start in design.

Failed change? Poor information available to make decisions? Transition is your entry point. Problems are not handled correctly? Users are complaining about poor service? Operations is where it’s at (but we may want to loop transition here, too!) And so on.

For this to work, two things are important:

• Everyone needs to be ‘in’ the game. That is, everyone should feel empowered to identify an improvement and identify all of the necessary stakeholders to actually work on it
• The mindset needs to change as it relates to the lifecycle. Value stream mapping will help here. It is linear relative as to the improvement identified. And there may be different entry points based on what the improvement is

And there you have it. It is just a different way of looking at the ITIL lifecycle. And I have to remind you that management commitment will make this happen. This will never succeed if management does not understand the end result: improvements​, and the delivery of value to our customers and stakeholders. It’s that simple.

If you try this out, I would like to hear from you. Drop me a line.