Weaknesses of ITIL business cases
In previous posts we have been looking at ITIL business cases. The last one looked for the strong arguments for ITIL. There are some common weaknesses.
Don’t look for evidence of ITIL - there isn’t any. Not real solid research evidence. There is anecdotal evidence from CIOs who have just spent X million dollars of company funds and are asked what kind of return they got on the investment. There is the usual “how would you rate your brilliance in choosing ITIL, on a scale from 1 to 5” nonsense from analysts that would not get past the editors of a peer-reviewed journal. But there is no scientific evidence whatsoever that ITIL makes a difference.
Best practice is not always good practice, for two reasons. Firstly, as an interesting business thinker from that great country New Zealand, Mark Di Somma says: “World class best practice looks like everyone else” (http://www.markdisomma.com). What ever happened to differentiation? Zig when they zag? Secondly, best practice can result in over-servicing the customer; unnecessary gold-plating. (see Core Practice (CoPr, copper not gold, get it?).
People, Process, Technology: remember that from your “sheep-dipping” (ITIL Foundations training). It gives us two points of weakness in our process-centric proposal:
It comes as no surprise that the geek-controlled-industry overlooks the people aspect. People do not like change, especially when it threatens their jobs or when it threatens processes they built and own. Do not expect universal support – be prepared for active white-anting of your business case.
And please please please avoid the Great IT Trap: getting fixated on the technology (those geeks again). The IT Skeptic would argue that at the point when you are building a business case for an ITIL project you cannot possibly know what technology you need. That will require a smaller business case of its own once you understand what is your desired TO-BE state, as the consultants would say. You need a pretty clear picture of what you have and where you are going before you start evaluating tools.
This post is an extract from the ITSkeptic's ITSMWatch article What Goes into an ITIL Business Case
Made in New Zealand 
Comments
Good stuff
You've hit upon the two biggest issues.
The focus on people and human change issues is, indeed, one overlooked by ITIL and seriously underestimated by implementers.
A too-early fixation on technology is, as you correctly point out, the other major risk. The need to create a shared management vision and a common understanding of the long-term desired future state before selecting technology is self-evident. The need for a good preliminary business case including the cost of software can, however, be somewhat ameliorated by putting a place-holder cost fo rthe probable technologies.
Where we may part is on the concern about differentiation. In most cases, IT is not a direct revenue generator for a company. It is, most often, a very important support services function. We should consider, therefore, if there is much reason for anything other than careful optimization of value (quality v. cost). Perhaps we should consider if differentiation of process is likely to produce increased value?
Cary King
Minerva Enterprises
Managing Partner
www.MinervaE.com
differentiation
James, I meant differentiation in the sense of differentiating oneself from one's competitors.
Cary, you're probably right that there usually isn't an opportunity to differentiate competitively, but ther5e migth be. I'm just saying ask the question, don't assume. Maybe an outsourcer could differentiate by saying "Oh we don't do ITIL, that holds us back from the superior service we offer where...."
Differentiation - agree
Well, you have me there. I was thinking in terms of significant differentiation of big process.
IMO the battleground for differentiation will come in the the actual delivery of consistent, superior customer experiences. Our "customers" learn to trust us, and value the services, one experience at a time.
I openly confess that I'm not nearly the fan of ITIL that many people who are on this seem to be. ITIL is not law. ITIL is not a standard. ITIL is not even well peer-reviewed. I generally prefer the USMBOK because it is more inclusive of actual existing standards - not so much just made up stuff. ITIL is, however, a good reference source, with good ideas - just apply with care.
Business Service Management is, and will be for a while still, a fertile ground for innovation. For instance, Charles Betz is coming out with some great stuff - his view of portfolio lifecycles particularly resonates.
On the whole, I'm a big fan of process LEGOs. Or, as implemented in IT: Service-Oriented Architecture, plug-and-play, process reuse - for services and processes as well as technology.
In 2005 Thomas Davenport published a nice HBR article - The Coming Commoditization of Processes. In the current HBR Merrifield, Calhoun and Stevens have described The Next Revolution in Productivity. Recommended reading.
Cary King
Minerva Enterprises
Managing Partner
www.MinervaE.com
Differentiation take 2
I think the same logic appliesd, you can't differnetiate your service internally or externally unless you are capable of delivering the differentiated service consistently, and you shouldn't differentiate compared to internal or external services if there is no business need for it. What you should do though is check against externally provided services to ensure you are at least delivering an acceptable basic service. External providers are, of course, guilty of selling a poor basic service having sold it to senior management on the basis of non-value adding bells and whistles.
I can certainly see an outsourcer saying "We aren't ISO 20000 certified, that would hold us back...."
PS Any chance you could integrate a spellchecker? I tend to add comments when I'm on the move and you know what these small keyboards are like.
Basis for Evaluation....
The way that I read your comment (especially considering your previous post), it sounds like that you believe that the service provider should compare themselves to other providers to build a baseline for what is acceptable service. Am I reading this correctly?
external baseline
I think they should to some degree, because even an internal service provider is in implicit competition with external providers. Having said that I accept an internal service provider might well have a different value proposition to an external provider which means the comparison cannot always be a like-for-like one.
Many IT departments I come across remain very insular: If they haven't done something you suggest it translates in to "it must be impossible/pure theory" rather than a wake up call to go see what others are already doing.
Another useful comparison is, of course, to other internal providers. I came acrosss one IT department that was badly wrongfooted by the facilities management team introducing an on-line ordering system for basic consumables. It was the business who amde an unwelcome comaprison that you could order cd-roms, toner, mouse mats etc using an online system that told you at once what the expected delivery date would be, and led to deliveries usually within the same working day whilst in the same time period you would still be struggling to find the right form to fill in to order the same things from IT
Baselines, Expectations and Requirements
James,
I don't have any issue with baselining -- either internally or externally. I recognize that there is value in it.
The thing that I didn't see reflected in the comments was how initial requirements for such systems are determined, nor how this factors into setting proper expectations with the customer/user.
Without establishing these two data points, a baseline doesn't have quite the impact that it could. Ideally, it would be great to evaluate this in conjunction with the cost of service to the customer and the providers cost to deliver.
Without establishing a proper context, on what basis can you really determine what is good/bad? IMO, this leaves you in a situation where it ends up being relative to the preferences (and prejudices) of the person making the determination.
kengon
Comb charts
Ken,
I agree with you. Where a lot of IT customer satisfaction surveys, and ITIL business cases, fall down is that they totally ignore the customer's baseline expecatation. That's why for years I've been advocating the use of comb charts, where you first of all get the customer to determine how important an aspect of service is (preferably including an element of scarcity, that is not allowing the customer to mark everything as a 10 but to allocate a limited number of points, in any proportion, over a range of choices)and then get them to assess how well you are performing. Over performance in an area the customer doesn't rate is an indication of possible wasted effort. Only an indication of course, because if something is working well the customer might undervalue it.
The example of the ordering system is of another service provider actively modifying your customer's baseline perspective. IT managers forget at their peril, for instance, that most users and customers make frequent, unwilling, use of call centres to manage vast amounts of our lives, and that those interactions with non-IT help desks influence their perception of the IT help desk.
Service differentiation
This is a key point isn't it? I've seen a lot of attempts at SM improvement hampered because a senior manager on the SM side gets it into their head that you have to provide different service levels to different customers regardless of any business value. Typically the obsession with "Bronze, silver and gold service levels" seems to come from IT departments that in reality struggle to deliver even the most basic bronze service. What is most striking is when IT and the business have different views on where differentiation is needed - and on a positive note isn't unknown for IT to have a better idea of this than the business.