What Goes into an ITIL Business Case
Money, justification and a little creative thinking, writes ITSM Watch columnist The IT Skeptic.
E-MAIL
PRINT
COMMENT
SHARE
Digg
del.icio.us
Newvine
furl
StumbleUpon
BlinkList
Newsvine
Magnolia
Facebook
Tailrank
Slashdot
Technorati
Google Bookmarks
Yahoo Favorites
Windows Live
AskThe previous article said the strength of a business case is money, real or imagined. The strategy of a business case is how it is aligned with the target organisation. With strength and strategy, and a little luck, you can succeed.
| Other Articles by The IT Skeptic | |
ITIL Must Embrace the Collective
Stop Calling ITIL Best Practice
What You Need to Know About "ITIL Compliant"
|
It is not executive management that we need to convince, not at first. We should be convincing ourselves. In theory, IT should not attempt anything that does not have a positive ROI for the business (though of course in practice that can be hard to prove when building or maintaining infrastructure).
We see too often where the ops manager or CIO subjectively decides to do ITIL then starts a great work of fiction called a business case to validate their decision. Most IT organisations have learned to talk like a business but not to think like a business.
So, first do the business case as an exercise. Does it stack up? If not, why are you taking it to the business? How is it in the best interests of the organisation as a whole? If you still feel it is the right thing to do, then work out why and include those arguments in the business case.
Of course, you may be proposing an ITIL project because you can all see redundancy looming and ITIL looks good on a CV. Even if the business case is as wobbly as a BS15000 certification franchise, this article will still help you get the business case through.
The keys to a strong ITIL business case are some basic things:
Someone at the ITIL consultancy Pink Elephant posted an excellent rule of thumb for ROI at blog.evergreensys.com: “[Y]ou set your maturity target for process improvement at CMM3. You then analyse the incident data and determine what percentage of incidents would not have occurred with a CMM3 level of process implementation. From this, you can calculate the ROI”.
Thankfully the operational side of IT tends to have strong metrics to support business cases, and to involve repeatable processes where efficiencies can be made. Nevertheless, the dollars will seldom be enough, so make up the "shortfall" in the business case with risk, compliance, and strategic advantage.
Risk is the easy one if management are at all risk sensitive. As we said last time, reducing risk can be a compelling argument if (a) there is focus on that risk right now due to scrutiny or a recent embarrassment, and (b) the person who owns the money owns the risk.
Find the audit office, risk manager, or chief security officer to find out what concerns them about IT. Get them needling your decision-maker, or at least threaten the decision-maker with them. If you are a bank, use Basel II. Security is the obvious domain to talk about risk, but do not neglect the other ITIL domains. Reducing production outages or speeding mean-time-to-repair can have a dollar value, but they also reduce risk.
Compliance is really easy once a compliance requirement has been slapped on the business. SOX, ISO9000, and coming soon ISO/IEC 20000. Also, look for a big customer contract that has some process or quality SLAs in it.
There may also be internal requirements. A much-talked-about example is “transparency” or “business alignment." If this is a genuine formal requirement on IT from the business, good, use it. If it is just words then it is not an argument. There must be a real pain.
Strategic advantage is much harder for back-room stuff like IT operations but you can argue increased flexibility and responsiveness, and faster time to market with new IT systems.
