When you don't run IT as a business, the inevitable results: bad business decisions.

This article has been podcast

An insightful remark at the IT Managment Forum set off today's train of thought:

when an organization is allowed to pick and choose what [parts of ITIL are] implemented, what gets left out are the more difficult pieces to implement--which often are the pieces that would do the heavy lifting. What gets used are pieces that already fit into the way the organization does things. When the way you do things is fundamentally broken, sticking as closely as possible to the status quo just won't cut it.

IF those implementing ITIL have experience with it and IF that person/team can be objective, then and only then is it a good idea to pick and choose. Usually, though, a halfway implementation of any framework is a fast road right back around to where you started.

If the decision on which processes to reengineer is driven by a business case then it seems to me that the "right" ones will be chosen: those where ITIL will yield an improvement.

It might be that adopting ITIL in a capability where it "fits right in" does have a ROI, e.g less training of new staff, better contracts with service providers, off-the-shelf training...

In that case doing these "easy" bits first isn't wrong. It just means the "heavy lifting" bits are still there to do and doing the "easy" bits has laid the foundation for the project that is still to come. And if it is "fundamentally broken" then the business case for doing it should be easier. The thing that is probably holding it up is the size of the decision to fix it.

On the other hand, what happens in IT is often that decisions are NOT driven by business case, in which case the result described is exactly what will happen. The path of least resistance is taken and investment sunk into projects that return little benefit because some manager thinks (or has been convinced) it is a good idea.

I'm tempted to say "what is it about IT and its inability to base business decisions on business cases?" but I suspect HR, Marketing, Sales and others are just as bad in many organisations. If you are part of a business then you should run it like a business and that means having a business case.

"Business case" is another one of those long-suffering terms that gets knocked around. I think I'm using it properly. I mean a reasoned and structured document, with supporting evidence and references, that justifies a project on either financial or strategic grounds in terms of the overall strategy and plans of the business, and which has been reviewed and approved by sufficiently senior management.

Of course the public service is not so constrained with our money, but one hopes they would still build a case for every project, based instead on how it delivers budget and/or policy compliance, but still focused on the outcome justifying the investment and the outcome contributing to overall strategy and plans.

For too long we have made many decisions in IT based on whether something will be "better" (faster, more flexible, more space, cooler) without asking the real question: "Show me the money". If the return does not exceed the investment, don't do it.

Comments

Business Case & ITIL

Presumably a business case that identifies a solid approach to service transformation would imply that some of the low hanging fruit is delivered in the early stages. At the same time, business case driven and business aligned will ensure that it's not just a matter of dropping in the easy pieces.

Look for an article on business cases

Thanks for the thought. I wrote an article in response to it. I'll let you know when it comes out.

Syndicate content