Joel your
question about unsuccessful ITIL implementations is a good one.
Although I can’t really provide any specific customer detail for a
case study due to confidentiality, yet I can provide some overall
insight and opinion based upon experience and other guidelines I’ve
seen through industry analysts, scar tissue and the wisdom of others
In
my opinion, the only real failures are those companies who choose “NOT”
to adopt ITIL best practices. Success improves from there. That
said, some companies embarking on this journey only achieve minimal
levels of success. In my view, ITIL implementations can struggle in a
couple of key areas:
- Overall Program Management
- Focus to Technology as the Solution
Program ManagementITIL
implementations are usually large and complex and solid Program/Project
Management discipline is required. Some companies start the struggle
with grand plans based upon a huge scope and unreasonable expectations
– then lack the organizational maturity (People & Process) to
deliver to the expectations. The desire for real, quick value can be
overwhelming and must be balanced with the realization that this is a
“journey”, not a “sprint”. Getting strong sponsorship up front is
critical. Beginning with a true assessment, needs/gap analysis and
identification of how to lay a solid foundation while achieving quick
wins with real business value can help to avoid that “period of blame”
that can quickly set in. It’s kind of like building a house – or more
specifically – like a large renovation and expansion project. In the
first year, you are laying a new/additional foundation with a huge
amount of new or altered processes and changes in the culture. Yet,
you are living in the house at the same time, so you have to face up to
the challenge to achieve/maintain business value and sustain momentum
until the roof is on, the carpet is in and the new areas are
“livable”. Your new foundation could possibly be a simple start in
the area of things like “asset management” & then extending that to
“Configuration Management” or by enabling some key wins in the areas of
configuration management and incident/problem management with vision to
move next to release and change. Bottom line: start with a real
baseline/foundation and build quick wins and value on that.
Solid
Program/Project Management with focus to project initiation (scope,
sponsorship, communications) is a real help in this area. Yet,
sometimes, even those who drink the cool-aid and apply best project
management practices struggle. The best guidance I could provide for
those struggling with current projects is: revisit your roadmap, limit
your scope and extend your project as best you can and always deliver
with a business value mindset. Even if you have a “failed” project in
your lap, it may still be salvageable through recognition of the value
you have already achieved, resetting expectations, re-aligning scope
with business value, and re-visiting your tools, roadmaps and next
steps.
Technology Mindset - The
root causes of failure to achieve expectations in ITIL implementations
can be often be a misplaced focus to the “technical” rather than the
people and processes. It is not uncommon for the tool selection and
purchase to come first (hey, there’s a glut of very good software sales
teams out there). While software plays a huge role in ITIL, a tool
first approach can actually impede success. To me, ITIL is not using
best practices to use or manage technology - It’s about planning,
executing and continuously improving a core set of processes to affect
business outcomes. The technology simply supports that. I’ll sum it
up like this…”would you buy a $10,000 lawn mower (tool) before you
executed the process of obtaining financing, house-hunting and
determining what type of property you even want. Probably not… but it
you did … would you then allow your lawnmower (tool) to drive the
process of purchasing your home (location, financing, funding, etc…)?
What if you decide you want a condo? Hello Craigslist!
A
solid CMDB is the key to any successful ITIL journey and there can be
numerous speed bumps along the journey to a successful implementation.
Try not to think of a CMDB as a technology and definitive reference
repository. Rather consider it an overall set of processes, technology
and culture designed to provide information to deliver business
decisions and outcomes. Some software vendors may try to espouse
their CMDB as the definitive repository. Try not to think of your
CMDB as a single database. Successful CMDB systems usually contain a
variety of information and data in various repositories across your
organization (known as “federated” data). Relying on a single point
of information sets you up for a slew of “data integrity and
credibility” issues the first time your replicated data delivered from
the single CMDB fuels incorrect decisions. The key success factor here
is to enable a comprehensive CMDB systems and processes that provide
referential integrity and “metadata” pointing to the real, “trusted
sources” of the data where it resides – not trying to get it all in one
place.
Once
you know where to get the real, trusted data and are able to refine
your contextual mapping to business services, the challenge is to make
transform the data to information and knowledge - actionable to the
decision making processes that consume it.
There
are many other reasons that ITIL projects struggle… continue reading
through Evergreen’s blogs, whitepapers and I’m sure you’ll find more…
Hope this helps!
Scott M. Davis Process Consultant
Evergreen Systems
512 983-6492
scott.davis@evergreensys.com