Skip to main content

Payback time for ITIL

This article was written by Bob Mathers and printed in CIO Canada on March 8, 2009. Since it covers one of my favorite topics, the ROI of ITIL, I am sharing the whole article with you.


The ‘version 3’ updates of the Information Technology Infrastructure Library, released in the spring of 2007, have breathed new life into ITIL. Certainly, it has sparked renewed interest from CIOs.
 
By applying a common language and best-practice guidelines for managing basic functional processes, ITIL goes beyond a basic focus on infrastructure cost efficiency and personnel productivity. As such, it is especially popular within organizations that are committed to performance improvement and seek to take their strategies to the next level.

Increasingly, however, many executives are questioning the payback of investments in ITIL. It’s not that ITIL has failed. Indeed, evidence shows that a vast majority of executives involved in ITIL initiatives believe that the guidelines have produced benefits. However, few can quantify those gains in terms of cost savings or quality improvements.

This gap between perceived gains and actual results should be of particular concern in today’s difficult economy, when demonstrating a direct impact on the bottom line is essential, and when initiatives limited to soft returns are likely candidates for elimination.

Today, top-performing organizations are reassessing their approach by focusing on concrete results and quantifiable returns on investment from ITIL and other process improvement initiatives. Many of these efforts aim to identify discrete processes within the organization that need fixing, and take a more discrete approach to defining potential benefits and gauging results on an ongoing basis.

CHALLENGE IN GAUGING BENEFITSBy design, ITIL process guidelines cover a broad range of functions that impact performance in a variety of areas across the enterprise. This wide reach presents a challenge in terms of gauging the benefits of ITIL. Specifically, how do you assess the impact of a specific process change when that process spans the entire IT organization, which in turn is influenced by a number of dynamic factors? Moreover, how do you determine where to begin in terms of developing and implementing a plan to adopt ITIL principles throughout the organization?

Another challenge of quantifying cost benefits from ITIL adoption is that the benefits often relate primarily to quality of service rather than to costs. For example, while change management and problem management may reduce the number of calls into the Service Desk, incident management can make the Service Desk more efficient in fixing calls. This increases user confidence in the service, and encourages users to call the Desk for simple problems they would otherwise try to fix themselves. The net result: the number of calls remains constant, as do costs.

However, the benefits are undeniable – better service, higher user satisfaction, and higher productivity – since end users spend less time fixing IT problems and more time doing their jobs.

CIO STRATEGIES
One approach executives are taking to address these challenges is to recognize that an effective ITIL program need not be an all-or-nothing proposition that applies to all practices across all service areas. Rather, businesses are focusing on addressing the areas that have the most direct impact on operational performance in terms of cost, productivity, and service quality. Therefore, initial ITIL efforts are typically focused on incident management, change management, and problem management.

Incident Management refers to the processes and procedures in place to react to situations that arise in an organizational setting, ranging from a call to a Help Desk to getting a user whose PC has crashed back online. Key metrics include response time, resolution time, length of outage, and so forth. The emphasis here is on addressing problems efficiently, rather than on addressing the underlying cause of the problem.

Change Management is concerned with understanding and controlling how seemingly innocuous changes to IT systems and business applications can ripple through an organization and affect stability and quality of service and functionality available to end users. In this area, metrics – such as percentage of incidents caused by changes – seek to identify the impact of changes on organizational performance. The goal of process improvement is to understand and minimize those impacts.

Problem Management seeks to establish processes to proactively resolve problems by addressing root causes. Here, the emphasis shifts away from firefighting mode to avoiding problems in the first place. Appropriate metrics, as well as appropriate linkages between metrics and organizational goals, are essential.

Another approach is to integrate ITIL with other process frameworks such as CoBit to create hybrid models that suit the specific objectives of the organization. This trend reflects the experiences and lessons learned from earlier forays into ITIL, which confirmed that ITIL is not a one-size-fits-all panacea. CIOs today are taking a less doctrinaire approach, and picking and choosing from different models that best suit their unique requirements.

HOLISTIC AND DETAILED
The most effective way to quantify the benefits of ITIL and similar methodologies is to apply a management framework that takes a holistic yet detailed view of process changes and identifies and tracks improvement on an ongoing basis. Such a framework analyzes process improvement over time from three perspectives: cost, productivity, and service quality.

Consider, for example, the impact of improving processes around incident resolution. A benefits-oriented analytical model assesses the following: What is the impact on the unit cost of the operation, in this case the cost to resolve an incident?

What is the impact on productivity, in terms of number of incidents handled by agent per day? What is the impact on service quality, in terms of time to resolve an incident?

An essential starting point is a detailed baseline analysis from which to measure progress. Subsequently, as process improvement practices are adopted, snapshot measures of cost, quality, and productivity can be taken within a given scope of operations. In the case of incident management, tracking the number of incidents is relatively easy, as is tracking process changes relative to a reduction in the number of incidents.

However, since the environment is subjected to a variety of influences, the challenge is to determine cause and effect and to understand whether changes in unit cost, productivity, and quality result from process improvements, or whether those changes reflect some other factors. This can be done by defining milestones to which specific process changes are linked, and then instituting a time lag (say, milestone plus one week) to allow time for the process change to have an impact.

Ideally, a dashboard-type of analytical model results, one that needn’t be overwhelmingly complex, but that does go into sufficient detail to track benefits and demonstrate the impact of ITIL and/or other process improvements.

TYING PROCESS METRICS TO BUSINESS GOALS
Another essential success factor in quantifying the benefits of ITIL and related initiatives is to effectively link process maturity metrics to broader business goals.

In the area of problem management, process improvement aims to identify and resolve issues that cause problems. Metrics should incent actions that identify the source of problems so that they can be eliminated. In a Service Desk, first-contact resolution is often used to assess the productivity of individual agents. Agents who consistently resolve fewer contacts than their peers may require additional mentoring or training, while the practices of the very productive agents can be used as a model for other agents.

And this does not apply only to IT processes. Consider a bank that provides customers a confusing telephone self-service option to change their PINs. Callers quickly become frustrated and abandon the service to talk to a live agent. Because the customer problem is easy to solve, the first-call resolution rate approaches 100 percent. Call center management has no incentive to search out and prevent this type of call, because then the calls could be avoided altogether. Fewer calls would push down the overall resolution rate, which would reflect poorly on management performance. Meanwhile, the customer experience suffers.

In this instance, an effective problem management process defines incentives for agents to identify problems (here, a confusing self-service option) and subsequently tracks the impact in terms of reduced number of customer calls to reset PINs. The value of that improvement can be quantified by calculating increased agent productivity (time saved by eliminating unnecessary calls), as well as by surveying customers no longer subjected to a frustrating online experience. CIOs are increasingly moving beyond the realization of soft benefits from ITIL and other process improvement models to achieve quantifiable benefits within specific operational areas. Key success factors include establishing a baseline of performance to provide a context, focusing on discrete functions, applying appropriate metrics, defining cause/effect linkages, and tracking benefits over time.

Comments

Popular posts from this blog

The Four Ps of Service Design - It’s not all about Technology

People ask me why I think that many designs and projects often fail. The most common answer is from a lack of preparation and management. Many IT organizations just think about the technology (product) implementation and fail to understand the risks of not planning for the effective and efficient use of the four Ps: People, Process, Products (services, technology and tools) and Partners (suppliers, manufacturers and vendors). A holistic approach should be adopted for all Service Design aspects and areas to ensure consistency and integration within all activities and processes across the entire IT environment, providing end to end business-related functionality and quality. (SD 2.4.2) People:   Have to have proper skills and possess the necessary competencies in order to get involved in the provision of IT services. The right skills, the right knowledge, the right level of experience must be kept current and aligned to the business needs. Products:   These are the technology managem

What Is A Service Offering?

The ITIL4 Best Practice Guidance defines a “Service Offering” as a description of one or more services designed to address the needs of a target customer or group .   As a service provider, we can’t stop there!   We must know what the contracts of our service offering are and be able to put them into context as required by the customer.     Let’s explore the three elements that comprise a Service Offering. A “Service Offering” may include:     Goods, Access to Resources, and Service Actions Goods – When we think of “Goods” within a service offering these are the items where ownership is transferred to the consumer and the consumer takes responsibility for the future use of these goods.   Example of goods that are being provided in the offering – If this is a hotel service than toiletries or chocolates are yours to take with you.   You the consumer own these and they are yours to take with you.               Note: Goods may not always be provided for every Service

What is the difference between Process Owner, Process Manager and Process Practitioner?

I was recently asked to clarify the roles of the Process Owner, Process Manager and Process Practitioner and wanted to share this with you. Roles and Responsibilities: Process Owner – this individual is “Accountable” for the process. They are the goto person and represent this process across the entire organization. They will ensure that the process is clearly defined, designed and documented. They will ensure that the process has a set of Policies for governance. Example: The process owner for Incident management will ensure that all of the activities to Identify, Record, Categorize, Investigate, … all the way to closing the incident are defined and documented with clearly defined roles, responsibilities, handoffs, and deliverables.  An example of a policy in could be… “All Incidents must be logged”. Policies are rules that govern the process. Process Owner ensures that all Process activities, (what to do), Procedures (details on how to perform the activity) and th