Making the Case for IT Service Management
Making the case for IT Service Management. Is it all worth it?
Richard LaRocque, ing. ITIL V3 Expert
IT Service Management Lead
IT Service Management has had its ups and downs in terms of popularity. Organizations get on the bandwagon, initiate massive projects, develop detailed processes, buy and implement a plethora of tools and applications, and end up wondering if it was all worth it. After all, it’s often not a trivial task to recognize the true benefits of ITSM.
So how can the case be made if benefits are so difficult to recognize? Firstly, it’s important to set clear objectives from the start. One does not do ITSM for the sake of doing ITSM. ITSM should be seen as a means to an end, not an end in itself. ITSM should fix something; target clear and well understood pain points. Identifying these critical pain points is an essential first step in making the case for ITSM. Knowing what the target is (or are), not only allows the organization to focus its attention but also provides a way to start defining a better case for ITSM.
Once the organization as identified key pain points, it’s then necessary to find ways to quantify that pain. This requires some investigation. For example, it’s one thing to know that there are issues at the service desk but another entirely to boil these down to one or two measurements. Through analysis, it should be possible to identify key performance indicators (KPI) that can accurately represent the pain points. These KPIs should be compelling enough to feed directly into the hard benefit part of the equation, demonstrating the potential effect of ITSM. If not, then the KPIs – or even the pain point(s) – ought to be re-evaluated; re-stated.
With the right KPIs in hand, the next step is to financially quantify changes in their value. For example what does it mean to the organization if the number of dropped calls at the service desk is reduce by a certain percentage? This is where financial creativity comes into play. Relationships between data items that may, on the surface, appear totally disconnected must be uncovered, inferred. Financial analysts may be of great assistance here as they have the experience and knowledge to understand the numbers and their possible relationships.
Armed with clear pain points, accurate KPIs and solid supporting financial information, the next step is to determine what impact good ITSM practices will have on the metrics. Again here research, analysis and creativity are essential; rarely are answers easy to find. How can it be determine what impact a good incident management process will have on a specific KPI in a specific organization? So many factors come into play. Although “industry standard” metrics, as provided by research organizations, may provide credence to organization specific numbers, they should not be seen taken as gospel truth. Who’s to say that the results of a change in one (or even many) other organization will also materialize in another? Because it’s impossible to know how differences in organizations will affect the results, there are no real shortcuts: organization-specific quantification must at least be attempted.
Once satisfactory quantification of ITSM benefits is achieved – satisfactory does not mean perfect – making the case is a matter of comparing these hard benefits to the actual costs of the solution. This is where softer benefits of ITSM can help tip the scale. Implementation of ITSM is expensive and hard benefits may not be enough to fully justify the investments, but things like quality of service, better management information, and best practice-based process standardization can augment overall value.
What is clear is that building the case for ITSM is hard work but, I believe, essential to the success of its implementation. Even if the organization is convinced it’s the right thing to do, without a strong business case, there are always unanswered questions that hang over the initiative, like the sword of Damocles. One or two questions from a senior manager could be enough to jeopardize the project.
In my next post, I’d like to discuss establishing the project to implement ITSM: its structure, its approach, its do’s and don’ts.