ROI and ITIL:
Every IT manager intuitively understands the difficulty of achieving, and as importantly, demonstrating, a return on investment for technology projects. We all know the drill – delays, changing requirements, changing environments, all leading to challenges in meeting the stated goals of the project. These issues are particularly acute for large, multiphase deployments such as an ITIL implementation.
The IT department has become the central artery of a large number of organizations. This central artery increasingly finds itself in a predicament – increasing dependence on its services with decreasing budget is putting an enormous strain on the organization. The annual cost in terms of downtime, compliance costs, and organizational inefficiency is high.
The IT Infrastructure Library (ITIL) offers a solution. But a first look at ITIL can be challenging for IT managers: A massive high cost project which is hard to sell to management and promises returns many years in the future and only after significant investment. If you can pick concrete milestones and, for each milestone, demonstrate and measure the value provided to the organization, much of this risk would be mitigated.
What can you pick as a first milestone in an ITIL project which will make others say: “Wow, yes this is the right way to go?” What can you do to get management to buy into your vision? Read on.
The Miracle in Detroit
Our quest is to find that magical milestone; a milestone that makes believers out of nonbelievers, a milestone that can be realized quickly with limited resources. First, we went out to several high performing organizations and began asking them what this milestone would look like. Not surprisingly there was no clear cut answer.
So we stepped back and began asking the question in a more quantifiable manner: what is the one metric that could be used to show management how much work is actually required to keep the clogged arteries running as of this moment. We considered several alternatives - uptime, downtime, and % utilization of infrastructure – but none was able to capture the essence of what we were after. Then one day sitting in the offices of a senior executive at one of the largest companies in Detroit the answer presented itself.
Cost of IT Operations - Amount of Change
Could it be that simple? What about automation? What about strategic planning? An intense session followed and it emerged that this executive had saved hundreds of millions of dollars in operational cost across three different companies during his career. And this was not theory: he had the numbers to prove it! The gist of the conversation went as follows:
What is the IT cost of running fax machines? We set them up and then the secretaries take care of the paper in them. I don’t have to touch them afterwards. Why? Because there is no change to them, when they break we throw them out and get new ones, connect them to the network and we are done? When I look at areas where my people are spending most of their time, they are usually areas of large change: either planning for it, or testing it, or rolling it out or recovering from the effects of it, or discovering something which should not have changed. When something goes wrong we are chasing what has changed.
Even if you look at development organizations, the more people you have, the more change in terms of updates is happening to the application servers. The entire operations budget and how to narrow it down comes to one variable “Change”.
Wow! Where are the savings?
Armed with this insight we began asking questions about the various processes that constitute the ITIL framework. In particular, we wanted to know what variables people felt the cost of those processes depended upon. The results were illuminating. First, we learned that three variables are enough to quantify the change environment:
1. Number of request for changes (RFC)
2. Number of file changes
3. Number of releases (a release is a batch of changes grouped together for build, test and push)
