Implementing ITSM -- Failing To Learn Is Learning To Fail

Recently, several blogs and articles have offered “top ten” type lists for succeeding with ITSM implementations.  (See for instance http://www.itsmwatch.com/tech/article.php/11702_3579296_2) Since Gartner now places ITIL at the “Peak of Inflated Expectations” on its “Hype Cycle” – where expectations exceed results by the widest margin, this is very timely and topical advice. Gartner is in essence saying that is may take some time to realize the ITIL’s full potential due to implementation difficulties.

Many of these blog entries are based on the writer’s experience with ITSM implementations, just as we would expect.  However, we need to keep in mind that – given the relative newness of ITSM in many areas – commentators may be drawing on relatively small samples for their insights.  What strikes me as I read these blogs and hear success (and failure) stories, is how strikingly similar most ITSM implementations really are to other IT projects.  There are some differences, of course, but the basic project structure – aligning with business, securing organizational support, developing the solution, and driving organizational change – is the same.  Unfortunately, this similarity is cause for concern:  industry studies have shown that only 28% of IT projects are unqualified successes.

Fortunately, this also means there is in fact a wealth of experience we can learn from to improve the odds of ITSM success.  For over ten years now, the Standish Group (www.standishgroup.com ) has surveyed thousands of companies to understand the causes of IT project failure and success.  The findings are published biannually in the highly influential “Chaos Study”.  The leading success factors have remained fairly consistent over time and have enabled smart organizations to significantly increase their project success rates.

Following are some of the key success factors cited in the Chaos Study, and my observations on how they apply to ITSM implementations:

• Executive Support – Perhaps the most critical and obvious.  Almost all implementations hits bumps along the way, so consistent support is a must.   The tougher question is “who are the stakeholders?”  Remember that ITSM is about improving service to business.  If you don’t have the support of business, you’re project is likely at risk.
• User Involvement -- Too many ITSM implementations begin with some ITIL experts in a room developing their idealized process model.  Unfortunately, this Ivory Tower exercise is often a waste of time (see Standardized Infrastructure below) and misdirected.  Early effort should be directed to working with users to understand how processes currently work, gather change recommendations, and measure the ability of the organization to implement those changes.
• Experienced Project Management – ITIL certifications do not equate to experienced project management.  Make sure you have project management that has been through an ITSM implementation before and understands more than process.  Seek external, professional help if you can’t meet these criteria internally.
• Clear Business Objectives – Don’t fall into a trap here.  “Implement change management” is not a clear business objective.  It is really just a means to the end of improving the service provided to business.  Any project must have measurable goals for improving the efficiency and effectiveness of IT services to risk becoming irrelevant and failing.
• Minimized Scope – This is critical.  Just about every successful ITSM project I have heard of starts by implementing an achievable, manageable set of business objectives and their supporting processes.
• Standardized Infrastructure – At first blush, this may seem to have more to do with software development than process implementation.  Think again!  The old rule of thumb is that an application is about 80% infrastructure and only 20% new code.  The Chaos Study indicates that virtually all projects that create infrastructure are doomed to failure because it is an inefficient use of resources.   ITSM projects are really no different.  Existing best practice based process models, such as the IBM Tivoli Unified Process (downloadable from http://www-306.ibm.com/software/tivoli/features/it-serv-mgmt/itup/index.html ) probably contain 80% of what an organization needs to document their operational processes.  Do your project a favor and use one of these models as a starting point.  You’ll lower cost and risk.
• Formalized Methodology – Yes, ITIL is a formalized collection of best practices observed in the IT industry, but it is infamously quiet on implementation guidance.  If you haven’t already considered it, look into industry models like CMMI or leverage a consultant with proven services for assessing your organizations needs and ability to change, and for developing realistic implementation roadmaps.
• Reliable Estimates -- “We’re changing a few processes, how hard could that be?”  The short answer is “very”.  Change is always hard.  The Chaos Study has shown that the average IT project has a 63% time overrun and a 45% budget overrun.  Bottom line: make sure your staff remains optimistic, but keep your project estimates realistic and conservative.

Rob Goodling

rgoodlin@us.ibm.com

Comments

[Doug McClure]

Great post Rob! I've added some additional comments based on my recent experiences here: http://dougmcclure.net/blog/?p=58

[James Governor]

yes indeed - good stuff rob.

[Michael Krigsman]

One of the few articles that dives into real project success factors.

www.projectfailures.com