What Goes into an ITIL Business Case
Dont look for evidence of ITIL there isnt 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. I will soon devote a whole article to this interesting state of affairs (being skeptics and all).
Best practice is not always good practice, for two reasons. First, as an interesting business thinker from that great country New Zealand, Mark Di Somma says: World class best practice looks like everyone else." What ever happened to differentiation? Zig when they zag?
Second, best practice can result in over servicing the customer; unnecessary gold-plating. I will explore this in a future article too.
People, process, technology: remember that from your sheep-dipping (ITIL Foundations training)? It gives us two points of weakness.
It comes as no surprise 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 of fixating on the technology (those geeks again). I would argue that at the time 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.
In the previous column, we talked about presenting your case strategically. Make sure the way the case is explained does these things:
1) Takes away pain or fear. SOX compliance is a common one right now. Managers just want to make it go away. There are managers too who just want to kick the ITIL box and move on. The bunker-buster is a This-must-never-happen-again" decree from the board. One of those and you will be including a new staff canteen as part of the project scope.
2) Delivers on key people's personal agendas. What new CIO can resist being the one who ITIL-ised the department? Here is a radical concept: Go ask the decision maker what they want from the project. If you can never get an appointment to talk about what you need, try this topic for a change.
3) Aligns with key business initiatives. A quality drive is a good one. Throw on all that continuous process improvement and Deming Cycle stuff in ITIL theory. SAP implementations are a gift too. They over-run so badly no one notices an extra million to ensure the IT infrastructure can cope with the flood of support calls and the deluge of changes.
4) Uses the right buzz-speak. ITIL is not necessarily the right buzz-speak for your organisation and the decision-makers in question.
If you think about these four points, there is one final simple rule: don't call it ITIL (unless the decision-maker wants to hear ITIL). Call it "IT Operational Support for SOX Compliance," "IT Transformation 2010 Exciting Times for IT," "Customer Oriented Services," "Projected Operational Enhancements for 2007," or "budget item 17."
There you have it. Make sure the business case is solid with money. Avoid apparent strengths that can be weaknesses. Apply your strength strategically by aligning with what the business wants ( to hear). You know you can succeed.
The IT Skeptic is an ITIL professional and active itSMF member who, for obvious reasons, prefers to remain anonymous. More thoughts from the IT Skeptic can be found at IT Skeptic.org.