The Most Essential Elements of ITIL?
Welcome back! I suppose that one normally expects that business activity tends to slow down toward year?s end as people focus on preparing for their holiday activities. Not so at Real World ITIL, however. The team here has had a very busy couple of weeks since our last entry.
Our current project involves helping a major international financial services firm implement Service Level, Configuration, Incident, Change, Capacity and Availability Management for a portion of their global IT organization. Over time, we expect that this project will serve as a springboard for the eventual introduction of ITIL-based processes into the rest of their IT.
Much has been written about how lengthy ITIL implementation projects can be - sometimes running into years. While this can certainly be true in some cases, sometimes our business drivers demand better performance than that.
What’s making this project especially interesting is that we only have about a 6-month timeline to get the essential elements of these six processes in place. This naturally begs the question ‘what do we consider the essential elements of ITIL?’
In this author’s view, the most essential elements are the lines between the boxes on the widely-published diagram of ITIL’s 10 core processes. While it’s certainly helpful that ITIL defines what the 10 processes are supposed to do, it’s really the integration of the workflows that make IT Service Delivery run better. To this extent, it may benefit larger organizations who are approaching ITIL for the first time to seriously consider implementing more than one process in a sensible way and get the interrelationships right than to first do only one process (usually either Incident or Configuration is chosen) in greater detail.
Though ITIL’s documentation presents this concept by describing the counterparts of each core process, it could really say a lot more about the whats and whys of the interactions between the core elements. (Do you agree? Click on the Comment link below to share your thoughts.) Perhaps the next version of ITIL will do better in this regard than the current version does. I believe that more detail could safely be provided without sacrificing the (understandable and valuable) generic nature of the standard.
For example, there should be a very close operating relationship between Capacity and Financial Management: Capacity provides forward-looking capacity plans to Finance, who then uses the information to establish forward-looking budgets. Finance in turn feeds actual historical spend data back to Capacity, who uses the data to, as ITIL states, manage cost vs. capacity. Then, Capacity ( using additional input from the CMDB ) sends ‘cost per unit capacity’ data back to Finance, which uses the data to generate accurate chargeback statements to IT’s clients.
It’s in documenting this back-and-forth motion of specific kinds of information and the reasons for the data flows that the Library falls short in terms of detail. Yet, getting these interfaces running is where, over the long run, the greatest overall efficiency improvements are likely to happen.
In the present case, our short timeline has caused us to reflect on the essential truth that we’re not really building six different things (though of course we have to develop at least six detailed workflows) but rather a single, integrated workflow for operating six necessary IT functions. On a schedule this aggressive, there’s no avoiding the fact that we’ll only be able to deliver a ‘Version 1.0′ process structure toward the end of the second quarter, then have to spend the next year or so adding detail & smoothing over rough spots.
We therefore must focus on getting the overall ITIL architecture right the first time, then fill in most of the details later. This means that we’ll spend more time in process integration workshops between the six process teams than in detailed design workshops within the teams.
Of course, we haven’t forgotten that ‘the devil is in the details’ when it comes to successfully getting real life workers to follow unfamiliar workflows. Implementing processes that are too vague can certainly lead to the failure of the whole ITIL initiative. Nonetheless, we believe that, when required to implement multiple processes simultaneously on a tight deadline, an appropriate balance can successfully be struck between the level of detail and the usefulness of the process designs.
An iterative approach to process implementation can work well - especially if the overall process architecture is correct from the start and also that workers and their managers have had their expectations set appropriately. Our main burden instead will be to employ effective organizational change leadership methods to ensure process adoption. We must also invest sufficient effort into facilitating appropriate political agreements between essential IT functional areas to ensure smooth handoffs of operational inputs and outputs.
Next time, we’ll do a ‘deep dive’ article on one of the least written-about processes: Availability Management.
Until then, we wish you and yours a happy and relaxing holiday season. Thanks to all of our readers for sharing our adventures through 2005 - we appreciate you following along.
Real World ITIL will be on vacation next week, so see you back here in 2006 for more adventures in IT process improvement - when we hope to hear from you!
Regards,
Scott (your moderator)
—–