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)
Technorati Tags: “infrastructure library” “itil” “blog” “manager” “asset manager” “asset”
—–