Developing the Business Case for ITIL - Evergreen Systems · 2017-10-09 · Developing the Business Case for ITIL ... medium and large enterprises are developing the business case

Developing the Business Case for ITIL

[email protected]

Table of Contents

I. Executive Summary ....................................................................... 2 II. Why Develop the Business Value of ITIL? ................................... 4 III. Leveraging ITIL for Quality Gains and Cost Reduction ............. 5 IV. Today’s Market Value of ITIL ...................................................... 5 V. ITIL and Drivers: Q3 Survey: Calculating Business Value............ 7 VI. Developing an ITIL Strategy ....................................................... 8 VII. Incident and Problem Management .......................................... 9 A. Incident Management .................................................................. 10 B. Problem Management .................................................................. 12 C. Calculating Gains on Incident/Problem Management Improvement .. 13 VIII. Change, Release and Configuration Management ............... 13 A. Change and Release Management ................................................ 14 B. Business Process Re-engineering .................................................. 14 C. Change Management Lifecycle Improvements ................................ 15 C.1. Change Management Planning ................................................... 15 C.2. Change Management Approval ................................................... 16 C.3. Change Management Execution ................................................. 16 C.4. Change Management Review ..................................................... 17 D. Configuration Management .......................................................... 18 E. Calculating Gains: Change, Release and Configuration Management 20 IX. Service Level and Financial Management ................................ 21 A. Service Level Management ........................................................... 21 B. Financial Management ................................................................. 22 C. Calculating Gains on Service Level and Financial Management ......... 24 X. The Changing Face of IT Metrics ................................................ 25 XI. Summary and Conclusions ....................................................... 27

2 BVITIL_1111_fin

Developing the Business Case for ITIL A Step-by-Step Guide to Developing the Business Value for ITIL and IT Process Improvement

I. Executive Summary Even though less than half of today’s small, medium and large enterprises are developing the business case value for their IT projects, this type of ROI analysis will be increasingly demanded by executive management. IT departments that hope to fund major projects will have to provide benchmark metrics both before and after project funding and show achievement of those goals before additional projects will be funded. Findings from Evergreen Systems’ Q3 2006 Survey on Calculating the Business Value of ITIL highlight the fact that although ITIL initiatives are on the radar screen for a majority of enterprises, organizational resistance to change and unproven business value, due to a lack of metrics, still plague the implementation of many of these projects. Service quality and service delivery are still top priorities, and enterprises seem more focused than ever on exactly which initiatives are being targeted (CMDB, Service Catalog, Incident and Problem Management and Change and Release Management). However, a good deal of work still needs to be done in the areas of root cause and work flow analysis, and organizations that have actually done this work, and have metrics and deliverables associated with the analysis, are few and far between. Even with an overall business plan, all new ITIL projects require executive support and long-term funding. ITIL programs that do not have a clear strategy at the start are most likely to show little or no business value, as their organizations will resist the necessary changes. As Incident and Problem Management are addressed, it is important to clarify the distinction between these two that ITIL makes. Incident Management involves restoring normal business operations as quickly as possible after an ‘incident’. Problem Management, on the other hand, focuses on finding and removing the ‘root causes’ of an incident to prevent it from recurring. ITIL makes this distinction to prioritize keeping the business running first and foremost and fixing the root cause in the background. Incident and Problem Management may be measured based on metrics like time to restoration of service, service quality, efficiency gains and simplification, risk mitigation, and improved usability of processes. These may be associated with KPIs (Key Process Improvements) that can be linked with management goals and objectives, which may be quantifiable.

3 BVITIL_1111_fin

Success with ITIL improvements in the areas of Change, Release and Configuration Management presents a greater challenge in that these areas ultimately impact all of the IT organization. This significantly raises the degree of organizational change required and touches many silos of existing processes. Potential improvements in the Change and Release Management processes can include reduction of system failures, reduction in failed changes, risk reduction and improvements in efficiency, accuracy and service quality. Most potential for gain in Change Management comes from re-engineering and automating high-volume IT workflows. Configuration Management can normally calculate gains based on software and hardware asset reconciliation and underutilization and can result in redeployed assets that can save dollars on additional equipment, under-optimized procurement processes and sub-optimized software licensing agreements. Service Level Management is tied strongly to SLAs (Service Level Agreements) and can yield cost savings metrics through greater service availability and reduction in penalties associated with unmet SLAs. Financial Management can also yield cost savings in the areas of underutilized and unaccounted for assets, which can also yield additional savings in taxes, inventory and insurance. Finally, metrics are more important than ever to IT, and the types of metrics associated with projects have expanded. Efficiency, effectiveness and customer satisfaction metrics lead the way for the development of a ‘core’ set of metrics, particularly for IT infrastructure projects. These metrics address both ‘hard’ and ‘soft’ dollars and should be applied both before (as benchmark objectives) and after IT projects (as a percentage of metrics achieved). Even though few companies are currently establishing these metrics to measure the value of IT to the business, there is a clear trend towards doing so. In the future, fewer and fewer projects will be funded without these financial and business value justifications. In addition, companies are beginning to develop matrices of metrics that measure not just single projects, but service delivery on an end-to-end basis. Businesses are also relying less on metrics that evaluate IT internally, such as number of servers per system administrator, and more on those that look at IT’s impact on the business. Finally, the most forward-thinking practitioners in the area of metrics for IT process improvement believe that metrics must be developed in conjunction with the business’ ‘maturity’ in meeting a hierarchy of needs, beginning with security and system availability and effectiveness and ending with innovation, aimed at balancing client impact against operational effectiveness.

4 BVITIL_1111_fin

II. Why Develop the Business Value of ITIL? In Optimize magazine’s just-completed CIO effectiveness survey of more than 700 CXOs, 7 out of 10 CXOs say the most important criterion in considering the effectiveness of a CIO is the CIO’s ability to support companywide business strategies.1 Metrics demonstrate that kind of support in hard-to-argue terms. However, CIO Insight’s July 2006 survey on business value and ROI for IT revealed that only 6 out of 10 companies measure the business value of IT.2 Small firms are least likely to measure what benefits their IT investments are bringing, but even among large companies (those with revenues over $1 billion), one out of five do no kind of valuation at all, not even such basic measurements as cost savings or customer satisfaction. On average, only 41% of companies’ IT budgets undergo an ROI assessment, and only half do an ROI assessment both before and after an IT project is completed. All investors examine past performance prior to investing, so why doesn’t business hold IT to the same standards? The answer is that business is starting to hold IT to financial performance and ROI standards. Consider the following: A new IT strategy at Hewlett-Packard has Hewlett-Packard’s CIO Randy Mott

committing to driving $1 billion in business benefits this year, double that in 2007 and $2.5 billion by 2008. 3

A goal at the University of Pittsburgh’s Medical Center to have IT cut in half the time it takes to deliver a data-sharing project to hospital clinicians. 4

Global Crossing CIO Dan Wagner wants IT managers and staff to attend a total of 500 sales calls in 2006 in support of the company’s back-from-the-brink emphasis on business growth.5

As these companies cross over from financial restructuring and IT cost-cutting strategies, they are growing again and looking for new metrics to measure progress, including metrics that are tied to the success of the lines of business that they support. “CFOs and boards of directors will continue to insist on metrics such as ROI and return on capital,” says Ian Campbell, CEO of Nucleus Research. “Return tends to be the driver for all investment decisions,” he says.6 Even in business outsourcing,

1Push your IT value or suffer suspicion, Mark Samuels, Computing, October 19, 2006, VNU Network VNU Business Publications. 2 July 2006 Survey: What’s the Value of IT? At Many Companies, It’s Just Guesswork, Allan E. Alter, Ziff Davis CIO Insight, July 12, 2006. 3 Business Apply New Metrics In Measuring IT’s Value, Eric Chabrow, Information Week, October 23, 2006. 4 Ibid. 5 Ibid. 6 Ibid.

5 BVITIL_1111_fin

metrics that let business and technology management measure the value of every partner are being required increasingly. Metrics charting the value that internal IT contributes as opposed to what outsourcing contributes also drive in-sourcing versus outsourcing decisions. “Convincing the Financial director to fund technology projects is perhaps the most important part of an IT director’s role. Indeed, analyst Gartner suggests that spending initiatives are largely funded on the perception of the value expected by the business sponsor.”7 Developing business case value for IT projects is not currently commonplace, but executive management will increasingly demand that this type of ROI analyses be done. Additional funding for major IT projects will not be forthcoming unless IT departments provide benchmark metrics both before and after project funding and show achievement of those goals.

III. Leveraging ITIL for Quality Gains and Cost Reduction With IT executives under this mounting pressure to reduce the cost and complexity of IT, while increasing productivity and implementing a growing number of strategic initiatives, ITIL best practices offer the best promise to help IT management cope. Nevertheless, executive management is only willing to invest in initiatives that have clearly demonstrated business value, with accompanying metrics to prove it.

The Information Technology Infrastructure Library (ITIL) defines best practices for running IT more effectively at the enterprise level, assisting IT management in developing consistent processes and procedures across technical ‘silos’. In the U.S. alone, there are more than 200,000 IT staff who have gained ITIL certification, with the number doubling each year.

So it is no surprise that an increasing number of IT executives are looking to ITIL to help relieve overburdened IT staff and increase efficiencies. Nevertheless, executive management is unwilling to fund any initiative in this competitive environment that cannot be reinforced with clear, documented value, a business case and a return on their investment.

IV. Today’s Market Value of ITIL ITIL essentially re-engineers the services provided by large IT departments from the perspective of their customers, eliminating unnecessary duplication of effort and presenting a consolidated set of consistent service offerings to end users. Reported gains include the following:

7 Samuels, op.cit.

6 BVITIL_1111_fin

A 30% overall efficiency gain, from research conducted by IDC with 11 different Global 2000 organizations from different sectors and geographies. Specific gains include: 8

o Incident management and help desk support: 40.5% o Managing and supporting servers: 30.9% o Change management: 28.4% o Managing and maintaining network infrastructure: 23.1% o Maintaining configuration database: 22.8% o Managing applications: 10% o Problem management: 9.4% o Service level management: 8.5% o Average number of network devices controlled per FTE up 57% o Average reduction in headcount growth: 12.2%

The IDC study also documented significant gains that include:

o Three-year cost of investment: $2.1 million o Annual cost savings and increased revenue: $14.5 million o Net present value of three-year savings: $26.7 million o Payback period: 11.8 months o ROI over three-year life of project: 422%

A $500 million savings from Proctor & Gamble, as well as a 6-8% reduction in operating costs and a 15-20% reduction in technology personnel.9

A 25-35% reduction in time required to process changes across the infrastructure, a 39% reduction in systems abends and a 75% reduction in ongoing compliance workload from Food Lion, an 1,100-store grocery chain, working with Evergreen Systems.

Gartner research also surveyed 350 senior IT executives in 2005 and determined that “There was a strong positive correlation between those not using ITIL, and the degree to which respondents felt their infrastructure was under-funded.…We believe this reflects their focus on creating a service driven organization, the need to be competitive and greater maturity.”10 In 2000, target response time for resolving Web incidents at Caterpillar IT was 30 minutes, but it hit that goal only 30% of the time. Then Caterpillar implemented ITIL. Now its IT providers hit the mark more than 90% of the time, and Caterpillar has been able to grow its business exponentially in the past five years with only a 1% increase in its IT budget. 11

Clearly, enterprise clients in all commercial sectors are beginning to harvest and document the cost reductions and efficiency gains yielded from ITIL and other IT process improvement projects.

8 Determining the Return on Investment from Deploying Integrated IT Service Management, IDC, April 2006. 9 Introduction to ITIL: Early US Adopters Show Business Value, Elizabeth Ferrarini, EnterpriseLeadership.org. 10 The Information Technology Infrastructure Library Improves Infrastructure Investment, Gartner research, June 9, 2006. 11 Ibid.

7 BVITIL_1111_fin

V. ITIL and Its Drivers: Q3 Survey on Targeting and Calculating the Business Value In Q3 2006 Evergreen conducted a survey on developing the business value of ITIL at the annual itSMF National Conference. One hundred (100) IT managers, directors and executives from 90 companies, organizations and institutions participated in the survey, designed to: Gauge their organizations’ commitment to ITIL initiatives such as Change,

Problem and Incident Management.

Assess how thoroughly these organizations had analyzed and re-engineered their processes to conform to these core initiatives.

Calculate how many of these efforts had been quantified and measured via standardized metrics.

Identify if the targeted projects were being delivered via phases and milestones.

Participants responded to a variety of questions around their top ITIL initiative priorities, as well as how they attempted to analyze and calculate the value of re-engineering those initiatives, with some interesting results:12 Respondents rated service quality, efficiency/cost reduction and IT/business

alignment as their top drivers for ITIL initiatives. Eighty percent (80%) of respondents rated service quality as the top business driver for ITIL initiatives, with cost reduction (74%) and alignment between IT and the business (64%) rating second and third in importance.

Resistance to organizational change (78%) and unproven business value (50.5%) were rated as the most significant barriers to ITIL initiative adoption.

More than half (57%) reported that their current ITIL direction focuses on improvement of end-to-end IT service delivery, stressing Change, Configuration and Release Management.

Top ITIL initiatives were identified as CMDB (64%), Incident and Problem Management (57%), Service Catalog (57%) and Change and Release Management (52%). Only 34% have a published ITIL strategy.

Less than half (45%) have analyzed their top five incidents by call volume, and of these only 31% have performed root cause analysis on their top problems and less than 10% have business goals with ROI to improve these processes.

Less than 30% have baselined their top five change workflows end-to-end. Of these, less than 19% have re-engineered these and less than 10% have quantified risk reduction and quality/cost efficiency gains that could result from re-engineering.

12 Developing the Business Value of ITIL Survey Results, Evergreen Systems, November 2006.

8 BVITIL_1111_fin

Less than 19% have implemented four to five reusable change models based on risk and materiality.

The findings show that while ITIL initiatives are being considered by a majority of enterprises, the implementation of many of these projects is being hampered by organizational resistance to change and unproven business value, due to a lack of metrics. Enterprises indicate that service quality and service delivery are top priorities, and they are more focused than ever on exactly which initiatives are being targeted, (CMDB, Service Catalog, Incident and Problem Management and Change and Release Management). However, a good deal of work still needs to be done in the areas of root cause and work flow analysis, and organizations that have actually done this work and have metrics and deliverables associated with the analysis, are few and far between. Some recommendations from the study are to: Analyze their top incidents by call volume.

Perform root cause analysis on their top incidents.

Determine implementation costs and return on investment (ROI) for implementing solutions to these top incidents.

Baseline their top change workflows, end-to-end.

Calculate what re-engineering these workflows would cost and what it would save in efficiencies, calculating ROI and any possible risk reduction.

Implement four to five re-usable change models based on risk and materiality.

The remainder of this paper will focus on how exactly to accomplish this work, and ultimately, how to apply metrics to this re-engineering effort as well.

VI. Developing an ITIL Strategy Once a company has determined that an ITIL approach warrants further investigation, it is key to understand the nature of an ITIL transformation, the logical steps for implementing ITIL and the business value that it will drive. The best practices of ITIL can be applied incrementally in a phased approach, but that approach must be guided by an overall strategy and plan that maps to the 11 ITIL disciplines that define the delivery of IT services enterprise-wide. To be successful, all of IT must adapt to a common, synchronized way of delivering its goods and services to simplify and accelerate the work. This can be challenging, because many IT organizations are currently organized around technology ‘silos’ and are not well adapted to driving common process across these disciplines. ITIL is an organizational transformation activity, which can take a long time to execute. Success comes from transforming the work of IT from silos of technical activity to operating as one IT enterprise. The key challenge is organizational change, that is, getting people to change the way they work.

9 BVITIL_1111_fin

Development of an ITIL strategy is not unlike the development of any organizational change undertaking in a large organization, and a well-validated approach to this has been documented by John Kotter.13 Establish a sense of urgency.

Create a coalition.

Develop a clear vision.

Share the vision.

Empower people to clear obstacles.

Secure short-term wins.

Consolidate efforts.

Keep the effort moving forward.

Anchor the change.

These changes all require executive support, long-term funding and an overall business plan. ITIL programs that do not have a clear strategy at the start are most likely to show little or no business value, as their organizations will resist the necessary changes.

Building a high-level strategy and plan can be done in a few weeks at a modest cost with outside consultants (like Evergreen) who specialize in this kind of activity and can then be used to determine if the business case justifies moving forward. Businesses undertaking this activity on their own can use this approach to discovery and leverage ITIL best practices to document business value.

Most programs begin by focusing on one or two programs that illustrate clear need and then begin to apply ITIL best practices while also improving a key part of IT’s business. This is an excellent way to limit project risk and the duration of the initial phase and maintain a reasonable scope. Success in this first, limited phase then garners support, builds consensus, gets executive buy-in and usually provides a logical set of activities for the next phase.

What follows are key questions and areas of focus, by each ITIL area, that can assist in building high-level business justification for improvements in that area. Although this is by no means a one-size-fits-all approach, this general path has started many organizations onto the path of broad-based IT process improvements.

VII. Incident and Problem Management ITIL improvements in service support, particularly with Incident and Problem Management, tend to be easiest and fastest to achieve in that they focus on the help desk function, which lends itself to the collection of metrics. Improvements in processes and supporting technologies can show significant gains in efficiency, quality of customer service and reductions of call volumes and downtime.

13 A Force for Change: How Leadership Differs from Management, John Kotter, 1990.

10 BVITIL_1111_fin

An important distinction that ITIL makes between Incident and Problem Management is that Incident Management involves restoring normal business operations as quickly as possible after an ‘incident’. Problem Management, on the other hand, focuses on finding and removing the ‘root causes’ of an incident to prevent it from recurring. ITIL makes this distinction to prioritize keeping the business running first and foremost and fixing the root cause in the background.14

A. Incident Management

Incident Management affords the opportunity for the collection of metrics around functions like detection and recording, classification, diagnosis, resolution and recovery and closure. Gains areas can be uncovered through interviews with help desk staff. A good approach is to review the top five incident types from the following three perspectives. Criticality of impact to the business

Call volumes

Highest cost to resolve Analysis of the data gained below outlines areas for gains in: Efficiencies

Process simplification and improvement

Service quality improvements

Matching workforce with demand loads

Applying effort commensurate with incident value

Restoring service more quickly

Incident Analysis Table

Review incident workflow for each type of incident to determine if appropriate for the value of the incident type.

Interview the help desk staff asking:

o What would they change?

o What are their frustrations and why?

o Have there been achievements?

o What activities are seen as no value added?

o Are incidences classified logically and simply?

Has anyone in Incident Management been ITIL Foundation trained?

o How have they applied what they have learned?

o If they could change anything, what would it be?

14 Getting a Head Start on ITIL, Randy Steinberg, InfoWorld, October 20, 2006.

11 BVITIL_1111_fin

Review Service Level Agreement commitments.

o Are they appropriate for the incidences that they cover?

o Are they met effectively? If not, why not? What change needs to be made?

o Review incidences processed per help desk workstation in general.

Review staffing levels mapped against incident volumes over time:

o Analyze call loads, staff and resolution times to determine under or overstaffing. Can service level commitments be modified to match staffing more effectively? Is the organization overstaffed or understaffed?

How are service level expectations formulated and communicated to the customer base?

o How are results communicated?

Review the latest customer service surveys in light of efforts above.

o What are the top three to four areas of improvement identified by the customers?

o What has been done about them?

o What adjustments can be made to improve customer service quality?

o What tradeoffs, if any, become apparent?

What remote diagnostic and resolution tools are in use?

o How effective are they?

o Are they applied consistently? Given a working knowledge of current technologies in this area, what might be applied or used more effectively and what gains would come from this?

How are self service and user self help knowledge tools used?

o Might they be improved based on what is learned above?

If used, how have self service and diagnostics aids reduced incident volume?

o Have they increased first call resolution rates/decreased end-user down time?

o What do end users think of these? Which, if any, has been most successful and why?

o What additional applications of these technologies would be valuable?

Are high-volume, recurring incidences being transferred to problem management for root cause analysis?

o Are high-impact incidences being transferred to problem management?

o How has the problem management process improved the incident management process? If not, why not?

12 BVITIL_1111_fin

B. Problem Management

The goal of Problem Management is to minimize adverse effects of errors in the infrastructure and to prevent the occurrence or minimize the impact of errors, incidences and problems. This is done by either eliminating the root cause or developing a reasonable workaround. Typical activities include identifying, classifying, investigating and eliminating or minimizing the problem by eliminating or minimizing the root cause. ITIL defines Problem Management as having both reactive and proactive sides, with reactive being driven by Incident Management and proactive being driven by the identification and resolution of problems before incidences occur.

Most potential for gain will be uncovered by discussing the Problem Management process with those involved and by analyzing resolution effectiveness for identified problems. Review the top 10 problems analyzed by criticality of impact to the business, volume of incidences and highest cost to resolve.

Problem Analysis Table

What are the top 10 problems resolved through root cause analysis?

o How were they classified and selected?

o What was the number and impact of relevant incidences prior to resolving the problems?

o What was the value of resolving these problems—availability, service quality, accuracy, work reduction, risk reduction?

What are the top 10 problems pending resolution through root cause analysis?

o Why are they pending?

o What are the number and impact of relevant incidences?

o What is this costing the organization? What was the value of resolving these problems—availability, service quality, accuracy, work reduction, risk reduction?

o What will it cost to address the problems?

Review problems at a high level by status, service type, customer impacted, type of problem, etc.

Analyze by logical grouping for broader root cause issues such as:

o A class of software that does not meet our quality standards

o An overly complex systems approach that is unreliable

o Poor development discipline in a particular organization

o Lack of effective training in application functionality undermining the business value

o Poor technology standardization undermining reliability

o Poorly developed support processes for a given class of system

13 BVITIL_1111_fin

C. Calculating Gains on Incident and Problem Management Improvement

Analysis of this data should complete the circle begun with Incident Management, shedding light on the value and opportunity to deliver various levels of service and to: Restore service more quickly.

Align staff and costs with value, to focus on key service quality improvement areas.

Reduce operating risk.

Improve systems usability.

Simplify processes.

Capture efficiency gains.

Improve end-user service level management (by setting appropriate expectations and delivering to those).

Calculating the business value of these gains can be tricky, but listed below are some relationships between efficiency gains and the calculation of the value of those gains: Expedited restoration of service may be linked to:

o Increased productivity on the part of end users (calculated with contract costs, pay rates or FTEs, depending on the metrics utilized by various industries).

o Costs saved on penalty fees associated with committed SLAs (or conversely, penalty fees collected by way of proving that an outage was technology rather than service related, for outsourced technology).

o Cost efficiencies gained from greater service availability (linked to increased productivity or, in the case of ‘fee-for-services’ scenarios, increased fees for services that stay up).

Incident and Problem Management improvement may be associated with KPIs (Key Process Improvements), which can often be linked with management goals and objectives that may be quantifiable.

Increased customer satisfaction as a result of fewer problems with the internal help desk, which in some cases can be traced to better customer retention and increased sales.

VIII. Change, Release and Configuration Management Success with ITIL improvements in the areas of Change, Release and Configuration Management presents a greater challenge in that these areas ultimately impact all of the IT organization. This significantly raises the degree of organizational change required and touches many silos of existing processes.

14 BVITIL_1111_fin

A. Change and Release Management

Because Release Management is at the highest level a type of change, Change and Release Management will be grouped together into one category. The goal of Change Management is to ensure that standard approaches are used for all changes made to the IT infrastructure, yielding efficient and accurate outcomes.

Change Management controls changes to all Configuration Items (CIs) and follows a lifecycle approach—Plan, Approve, Execute, Review. At a higher level, change is the workflow engine of IT. It links customer requests with outcomes end to end through IT. Typical activities in the lifecycle of Change Management include: Planning—proposing a change; justifying the need, identifying the business

benefit and assessing the impact, risks and costs associated with the change.

Approving—reviewing and validating the proposed change and ensuring impacted entities have the opportunity to provide feedback.

Executing—managing and coordinating the change and ensuring correct completion.

Reviewing—reviewing change outcome and impacts; evaluating lessons learned, if applicable, and closing the change request.

B. Business Process Re-engineering

Classic Business Process Re-engineering efforts show the greatest gains when looking at workflows that are more complex (have a greater number of steps and approvals) and cross three or more areas (silos) in going from start to finish. Organizations that have not baselined and re-engineered the top five to six high-volume workflows in IT can see efficiency gains of 25-40%.

To provide adequate evidence of the value of re-engineering, select three high-volume workflows crossing three or more areas. Examples may include IT security approval processes, medium-level software programming changes (such as 20-40 hours of code development), IT procurement actions, server operating systems or database upgrades. Using a spreadsheet, interview those involved from end to end to create the

‘as-is’ process state. Review the workflow for unnecessary steps, duplicative activities, excessive manual activities, excessive delays and rework caused by inaccuracies and errors due to poor end-to-end understanding and communication.

Build the desired state by devising the most simple, streamlined approach to meet the business requirements and assume the use of basic Change Management technology to automate communications and workflow.

Measure the expected change in efficiency and elapsed time.

In practice, simple workflow end-to-end redesign can be done in a working session with the relevant parties. By facilitating discussion of the current state and its drawbacks, it is relatively straightforward to build the desired state, step by step, as the current state is being documented. Additional refinement of the desired state can be done after the working session.

15 BVITIL_1111_fin

C. Change Management Lifecycle Improvements

Key improvements can also be found in the four phases of the Change Lifecycle—Plan, Approve, Execute and Review. A great deal of IT time and energy goes to Change Management execution. For most organizations, there are valuable opportunities for improvement in other areas that are often overlooked.

C.1. Change Management Planning Most potential for gain in this area will be uncovered by discussing the Change Planning process with those handling the IT change requests. Typical improvements come from raising the bar for change approval (saying no to changes that are not justified), empowering those requesting the change to plan it, matching level of effort in change planning with the materiality of the proposed change, and clarifying and communicating expectations related to change submission completion and lead times. The table below should assist in analyzing the Change Planning process for improvement opportunities.

Change Management Planning Analysis Table

How many different types of changes are there; how are they grouped?

Is there a process to group changes into five or six types, based on risk and materiality (cost and business value)?

o If so, is there a reliable process for ranking changes that is not self selected by the requestor?

Have change requestors (users) been empowered through some type of self service function to create and submit change request packages?

o Are there clear submission guidelines and change lead times based upon the risk and materiality weighting of the proposed change? Have these been well communicated?

What percent of change requests have errors or lack appropriate support and must be returned for rework?

What percent of change requests are non standard for lead time? (Short notice or emergency changes arising from lack of advanced planning.)

What percent of change requests are rejected based on not meeting minimum business justification levels?

What backlog of change requests exists at this stage?

o How does it break down by change request type?

o What should the level be, and what impact does it have on the business, if any, at the current level?

General Improvement Questions:

o Ask staff what they would change, if anything?

o What is most frustrating in their jobs and why?

o What achievement(s) are they most proud of?

o What activities do they see as adding no value?

16 BVITIL_1111_fin

C.2. Change Management Approval Most potential for gain in the Change Management Approval area will be uncovered by discussing the Change Approval process with those who handle it. Typical improvements come from streamlining and routing approval processes based on risk and materiality, reducing approval activities by screening out unqualified requests, reducing time required by standardizing and improving the quality of the requests, and planning work more efficiently by raising compliance with submission lead time standards.

Change Management Approval Analysis Table

Are there different levels of approval process and oversight?

o If so how are the levels defined?

Are they directly linked to the change planning activities?

o Does the level of impact analysis vary with the risk or materiality?

What percentage of change requests are rejected at the Change Advisory Board level?

o What are the top three reasons for rejections?

Incomplete? Undetermined risk? Poor impact analysis? Lack of business value?

o What are these rejections costing the business?

What percent of change requests reviewed for approval are non standard for lead time? (short notice or emergency changes arising from lack of advanced planning)

o What are these emergency requests costing the organization?

What percentage of change requests are reviewed by the Change Advisory Board that are not worthy of their involvement?

o How do these submissions get to this level?

o Does this create risk by limiting the time available to review truly critical change requests?









C.3. Change Management Execution Most potential for gain in the area of Change Management Execution will be uncovered by discussing the Change Execution process with those doing the work and passing it from silo to silo. Typical improvements come from streamlining and reducing complexity by grouping similar workflows and reducing them to a

17 BVITIL_1111_fin

manageable number. For example, all server upgrades are ‘essentially’ the same, yet many organizations have completely different workflows for each type of server platform.

Executing via common workflows makes the work of IT less customized and more replicable. Gains in efficiency, simplicity, accuracy and service quality are common, along with reductions in cost and risk. These improvements come from: Filtering approval processes based on the risk and materiality of the

proposed change.

Reducing approval activities by screening out unqualified change requests

Reducing work time required by standardizing and improving the quality of the requests.

Planning work more efficiently by having staff comply with change submission lead time standards.

Key questions to uncover business value are included in the table below.

Change Management Execution Analysis Table

Which, if any, high-volume activities have been grouped into common workflows?

Which, if any, workflows have been redesigned (at the enterprise level) and automated in Change Management?




What percentage of changes were emergency?

o For non-emergency changes treated as such, what was the cost to the business to handle these?

What was the root cause?






C.4. Change Management Review Most potential for gain in the area of Change Management Review will be uncovered by discussing the Change Review process with those performing the review work. For most organizations, effective change review is the most neglected change activity.

Changes that do not fail, but don’t perform well for some reason or other are rarely reviewed. Changes that fail during execution or illustrate themselves as software

18 BVITIL_1111_fin

failures are obvious and should be considered separately. More subtle changes need to be examined separately and root causes examined. Changes that cause serious failures, often evidenced by unplanned downtime or worse, usually do receive in-depth analysis. These often result in major systematic course corrections, but only after the fact, when high costs have been incurred. Red flags should go up for changes that fail during initial execution, but more subtle changes should be investigated thoroughly as well. Many IT organizations operate reactively and thus ignore these more subtle changes, spending the majority of their time on reactive analysis. Typical improvements come from better change review activities that reduce the number of failures and also the number of changes that fail in execution, thereby reducing the number of ‘near’ failures. Questions for analysis of the Change Management Review function are listed in the table below.

Change Management Review Analysis Table

Review the failed changes and the changes that caused failures in a given period by type, risk, materiality and configuration item (CI). Consider:

o Which changes failed and had to be reversed?

Review root causes and actions taken

o Which changes caused system failures?

Review root causes and actions taken

o Which changes consistently take longer than projected; why?

Is there an unrecognized risk here?

o Review cost and risk to the business for all of the above. Consider incident volume related to these changes to help determine impact to the business.

o For any CI with a high percentage of changes, was deeper analysis performed? If so, what were the findings?

What percentage of changes were emergency and high-risk changes?

o Review root causes and actions taken

Analysis of the findings in Change Management from the perspectives of basic re-engineering of key, high-volume workflows and key improvement points in each of the four phases of the Change Management lifecycle should point out clear opportunities for business value improvement. These include improvements in service quality, accuracy and agility, efficiency and reductions in risks and costs.

D. Configuration Management

According to ITIL, Configuration Management “provides a logical model of the IT infrastructure by identifying, controlling, maintaining, and verifying the version of all Configurations Items in existence.” A Configuration Item (CI) is defined as a component of the infrastructure. All the detail and relationship information about CIs is stored in a repository—the Configuration Management Database (CMDB). All ITIL processes access the CMDB, which is fundamental to consistency across ITIL processes.

19 BVITIL_1111_fin

One can think of the ITIL Service Management processes as IT workflow and the CMDB as an information store. Workflow accesses the information store to plan and execute more effectively. Many organizations are working on CMDB functionality today, but few have an operational CMDB. If there is no CMDB ‘baseline’ today, then how can one assess the potential value of a CMDB in the organization? The answer lies in assessing the following: Improvements related to IT asset effectiveness.

Improvements in effective Incident and Problem Management.

Improvements in Change and Release Management.

Providing source data for compliance activities In most cases, the CMDB will be a superset of IT asset management information, and as such, analysis can yield useful information from classic IT asset management queries. The table below can assist in that assessment.

Configuration Management Execution Analysis Table

Do we have an accurate IT hardware and software discovery capability?

Have we reconciled discovered software assets with significant software license agreements?

o Have we used this information in negotiations with the vendor?

o Have we gone a step deeper and reviewed license use by user?

Have we done the same for hardware assets?

Have we done the same for telecom assets/circuits?

Have we done the same for outsourced relationships where pricing may be based in part, or in whole, on some asset count?

Have we used this data to reconcile insurance and property tax costs?

Have we reconciled assets with department managers to recover underutilized assets?

Is the data being used in chargeback system by department?

IT staff that provide level 1-3 support can be valuable resources in this area, as they understand the value of having asset and configuration information at their fingertips during incident diagnosis. The table below can assist in this analysis.

Asset and Configuration Management Data Analysis Table

What are the top three to four incident types that could be resolved more effectively by having asset and configuration data easily available?

o What is the cost of not having this information? How are these resolved?

o What volume of incidences does this affect?

o For these incidences, what is the end-user downtime impact?

20 BVITIL_1111_fin

Is lack of asset/configuration information the root cause of any problems today?

o Could effective asset data eliminate any common types of incidences?

o What would be the value of this?

E. Calculating Gains on Change, Release and Configuration Management

Potential improvements in the Change and Release Management processes can include the following: Reduction of systems failures.

Reduction in failed changes.

Reduction of risk.

Improvements in efficiency, accuracy and service quality. Gains could come in all phases of Change and Release Management, including planning, approving, executing and reviewing changes and releases, as well as the core re-engineering of the high-volume workflows.

In each Change Management activity, there should be an analysis to determine what asset and configuration information would improve the speed and accuracy of the activity. For most organizations, informal repositories of asset and configuration data are maintained in each technical silo, with varying degrees of accuracy. The cost of the maintenance of these multiple repositories should be explored, as well as impacts and failures that may arise from inaccurate data.

Most change failures are self inflicted and caused by the unintended consequences of changes. For many of these failures, the root cause of the failure is an inability to accurately understand the true impact of a proposed change. The root causes of all change and system failures should be examined, and a determination should be made as to which of those could have been prevented by accurate impact analysis. Most potential for gain in Change Management comes from re-engineering and automating high-volume IT workflows (changes), viewed in two ways:

Basic re-engineering of key, high-volume IT workflows.

Key improvement points in each of the four phases of the Change Management lifecycle.

One way to approach calculating the value of Change and Release Management is: Calculate productivity, time and expense associated with the major high-

volume IT workflows currently.

Once re-engineered (projected for re-engineering) re-calculate those same productivity, time and expense figures with the new workflows.

21 BVITIL_1111_fin

Key improvement points in each of the four phases of the Change Management lifecycle should also be examined for value gains. Configuration Management can be a bit easier for calculating gains. The areas detailed below should be investigated for calculating value: Accurate software discovery can yield reconciliation between software assets

and licensing agreements, which can generate real-dollar savings and be used in software-site and seat-licensing negotiations.

Similar types of reconciliations can yield additional dollars when applied to hardware, telecom and outsourced assets. Accurate inventory quickly turns up where funds are being ignored or underutilized.

Reconciliation of all this data can produce additional savings in taxes and insurance costs as well.

Recovering underutilized assets from other departments saves money as well and can result in redeployed assets, which can save money on expenditures for additional equipment.

Many organizations are fairly advanced in IT asset management practices and have recovered millions of dollars by eliminating unnecessary expenditures. Good snapshot areas include comparing the number of knowledge workers with the number of PCs owned and the number of servers per employee in the organization, benchmarked against others. Especially close attention should be given to expensive enterprise license agreements and their degree of use. Insight gained from this area can help assess the potential value of improvements.

IX. Service Level and Financial Management

A. Service Level Management

According to ITIL, “the goal of Service Level Management (SLM) is to maintain and improve IT service quality by establishing and monitoring performance commitments”, in line with business or cost justifications. Many organizations set goals in this area, but struggle to achieve any consistent performance against them, as the processes and data supporting the measurements are not complete or reliable. Establishing goals in SLM without the ability to perform effectively against them can actually hurt customer service ratings, as expectations are raised but then are not met.

Most potential for gain in SLM will be uncovered by discussing it with the people who negotiated the Service Level Agreements (SLAs) and those who work to deliver services under the requirements of those agreements. The most basic efforts in SLM can create fairly significant business value if the effort is made to analyze the agreements and their administration. Many organizations have only begun to leverage the gains presented by analyzing SLM and funding those projects. If no SLAs exist, proceed on to the next section, as the table below is meant to assist in analyzing SLM policy and SLAs. When reviewing the table below focus on the policy of SLM and the top three to four SLAs.

22 BVITIL_1111_fin

Service Level Management Analysis Table

What is our SLM policy, and why and how was it developed?

o What adjustments have been made to it since its creation? Why?

o What is the greatest opportunity to improve it, and why?

What value can be derived from it, and how might it be measured?

What are the top three SLAs, and why are they most important?

o How was the value for SLAs derived?

o What have the results been—positive and negative?

o How have these helped the business? How has the business measured these improvements?

o What unexpected benefits, if any, have come from using SLM?

What additional SLAs would be useful and why?

o How might they add value to the business?

Have customer satisfaction surveys been reviewed against SLA goals and outcomes?

o What has been learned and how can it be applied?

o Has Problem Management data for root cause issues and the way in which it affects SLAs been reviewed? How recently?

Are reviews with customers regularly scheduled, and do those reviews update and align the SLM process with what matters most to the business?

Has the SLM portfolio been reviewed against the business’s ability to deliver recently?

o Was this done in light of peak demand periods rather than just average demand over time?

o How are ‘business critical SLAs’ reviewed against other SLAs?

o Are variable response times offered at different cost points? If not, should they be?

Is response time being evaluated against value delivered?






B. Financial Management

The goal of Financial Management is “to provide cost effective stewardship of the IT assets and resources used in providing IT services.” ITIL takes this concept further, to include “resources used in providing IT services. Financial Management provides the essential management information to ensure that services are run efficiently, economically, and cost effectively.” Services usually involve people, processes and assets.

23 BVITIL_1111_fin

This information enables us to effectively: Account for and control IT’s expenditures.

Attribute costs to the appropriate users.

Plan and make decisions regarding current and potential new IT services.

Provide a reasonable business approach to cost recovery for the purpose of chargeback.

While reviewing the data in the table below, it would be useful to also consider data gathered in Incident and Problem Phase 1 and Change Management Phase 2. For asset effectiveness, refer to data gathered in Configuration Management Phase 2. For balancing service levels and costs refer to data gathered in SLM, in the previous section.

Financial Management Analysis Table

Is there a system for recovering costs from customers?

o How has it added value to the business?

o How has it improved the management of IT?

Has it helped balance the demand for IT services with capacity to deliver in any meaningful way?

Has it identified services of little or no real value?

What action has been taken as a result?

o Does it give customers more choice in actively managing their IT costs?

What is the customer’s level satisfaction with this system?

o What are the top three improvements that should be made to it and why?

What has been done to identify the actual cost of delivering key services?

o What are the lessons learned and how has the business benefited from this learning?

What actions have we taken to encourage efficient use of resources by customers?

o What are the lessons learned, and how has the business benefited from this learning?

o What services are being provided at no cost?

Which services are most abused by IT’s customers, i.e., by duplicating IT’s efforts?

What are these services costing the business in aggregate?

Is there a mechanism that could be used to encourage more customer efficiency?

What actions have been taken to influence customer actions, such as providing incentives to use non-critical resources?

Have IT costs been analyzed over specified periods of time, i.e., days, weeks, months, quarters, etc.?

o Lessons learned?

24 BVITIL_1111_fin

o Has the cost structure been designed for peak levels only, or has variability been built in?

Has variation for essential and non-essential services been built in?

How has financial data been used in capital planning and tradeoff analyses?

o How did it help the business?

o What other opportunities for gain in this area might be unexplored?

o Have full lifecycle costs of classes of assets and systems been examined, (including software, hardware, maintenance, programming, support, staffing, training, integrations, upgrades, etc.) in making upgrade and replacement decisions?

C. Calculating Gains on Service Level and Financial Management

Service Level Management is tied strongly to SLAs. Service providers establish SLAs with their customers as a way to ensure thedelivery of specified ‘levels’ of services. Generally SLAs offer discounts on charges for services if levels are not met or offer various ‘sliding-scale’ fees for specific levels of service. Financial gains from properly administering SLAs may be calculated via the following: Costs saved on penalty fees associated with committed SLAs (or conversely,

penalty fees collected by way of proving that an outage was technology rather than service related, for outsourced technology).

Cost efficiencies gained from greater service availability (linked to increased productivity or in the case of ‘fee-for-services’ scenarios, increased fees for services that stay up).

Financial Management deals with the management of IT’s costs, including the costs of service delivery as well as the cost of the management of assets. Financial Management gains can be calculated by examining efficiencies associated with better asset management, as well as by calculating IT’s ‘cost’ basis and charging for IT services accordingly: Accurate software discovery can yield reconciliation between software assets

and licensing agreements that can generate real-dollar savings and be used in software-site and seat-licensing negotiations.

Similar types of reconciliations can yield additional dollars when applied to hardware, telecom and outsourced assets. Accurate inventory quickly turns up where funds are being ignored or underutilized.

Reconciliation of all this data can produce additional savings in taxes and insurance costs as well.

Recovering underutilized assets from other departments saves money as well and can result in redeployed assets, which can save money on expenditures for additional equipment.

Cost ‘plus’ fee calculation that ties fees to specific service levels, measured via SLAs, will allow IT to ensure that it covers its costs and in some cases allows for some return on the investment via chargebacks.

25 BVITIL_1111_fin

X. The Changing Face of IT Metrics Any discussion of the development of a business case or return on investment (ROI) that did not explore the topic of metrics would not be complete. Metrics must be applied to the service delivery and funding models of IT to calculate the value of IT process improvement to the business. Metrics can measure the business value obtained from IT in more than just dollars. Metrics might (and should) also measure: Efficiencies (such as reduced labor costs, increased productivity and cost

savings.

Effectiveness (such as improved SLAs, greater service availability and fewer incidents).

Customer satisfaction (measure by surveys, improved quality of service and reduced help desk wait times).

Hard numbers (such as direct costs or SLA penalties) can be applied to most metrics, but some must be expressed in ‘soft-dollar’ requirements. Hard-dollar metrics usually apply to costs and expenses, yields or savings, whereas soft dollars generally apply to headcount, FTE (full time equivalent) or other benefits that are important yet less measurable by the business. In Gartner’s annual study of IT executives15, “IT Operations Continues to Progress Toward Transformation”, 57% of respondents reported operating at level 2 (proactive) process maturity, which was a 17% increase from the pervious year’s study. By aligning their processes with ITIL best practices, many are moving towards the availability and measurement of services on an ‘end-to-end’ basis. Gartner’s study showed that metrics that can be applied on an ‘end-to-end’ service availability basis will show more value to the business and ultimately lend themselves to more credible IT value calculations. However, individual metrics that measure incremental components of ‘end-to-end’ availability will still have to be applied for both ‘soft’ and ‘hard’ dollars to develop a solid business case and good ROI for ITIL initiatives. This ‘end-to-end’ approach to service delivery and availability metrics becomes even more crucial when new trends in IT value calculation are considered. Hewlett-Packard’s CIO Randy Mott just finished a three-year IT overhaul, the goal of which is to create a world-class IT organization and state-of-the-art computing infrastructure while driving down costs at the same time. New metrics are being utilized in this project:16

15Use Business-Level Metrics to Assess IT Outsourcing’s Value, Gartner research, November 9, 2004 16 Chabrow, op.cit.

26 BVITIL_1111_fin

Delivery of 98% of IT projects on time by 2009, as compared to 81% n 2006.

Contributing $3 billion in IT organizational ‘annual benefit’ in 2009, compared to the $5.5 billion contributed from 2006 through 2008.

Producing ‘benefit per developer’ of $450,000 by 2009, three times more than 2005.

Increasing IT staff time spent on innovation- developing new capabilities versus supporting existing ones- to 80% in 2009, compared with 46% in 2006.

HP’s IT department conducts a cost-benefit analysis on each project to find the business benefit of the project, either expense savings that drop to the bottom line or new revenue opportunities. Mott also uses many metrics together, rather than focusing on just one: Number of active projects.

On-time delivery.

Project phase ‘time boxing’.

Time spent on innovation versus sustaining technology.

Cost benefit analyses completed.

Annual benefit per project. This is only one example of how business technology executives are relying less on metrics that evaluate IT internally (the number of servers per system administrator, for example) and more on those that look at IT’s impact on the business. “Once popular measurements such as IT investment as a percentage of company revenue miss the value IT brings to a company,” says Gary Scholten, CIO of Principal Financial Group. “That’s really an old-school kind of metric,” he says. “It’s an interesting data point, but not an area of focus for us.”17 This approach doesn’t ignore metrics that look internally at IT performance (useful in benchmarking against competitors), but sees greater value in measuring how IT impacts corporate operations and uses these metrics to ‘enhance’ more traditional performance metrics. Electronics parts distributor Avnet measures spending on infrastructure and applications against gross profits, which, unlike revenue or expenses, reflects how efficiently the company operates and “doesn’t allow IT spending to get out of sync with the money we spend on other operational expenses,” CIO Steve Phillips says.18 CIOs have to strike a balance between measuring performance to squeeze costs and making sure they’re spending on the ‘right’ projects to improve the business. Vanguard Group CIO Paul Heller thinks of metrics in something like Maslow’s

17 Ibid. 18 Ibid.

27 BVITIL_1111_fin

Hierarchy of Needs, where the most ‘basic’ needs are satisfied before others above it are addressed:19 Security and disaster recovery are the foundation.

System availability and responsiveness are next in importance.

Project delivery comes third, including timing and budget.

Quality, speed and efficiency in software development come fourth.

External client measures, such as usage of new web features or services are fifth.

Innovation, plotted to address client impact on one axis and operational impact on the other, sit at the top of the needs ‘pyramid’.

This thinking seems to mirror the idea of IT and ITIL process maturity. Only companies that are ‘mature’ at the lower levels are prepared to address the next level of IT needs higher up in the chain. In summary, efficiency, effectiveness and customer satisfaction metrics lead the way for the development of a ‘core’ set of metrics, particularly for IT infrastructure projects. These metrics address both ‘hard’ and ‘soft’ dollars and should be applied both before (as benchmark objectives) and after IT projects (as a percentage of metrics achieved). Even though few companies are currently establishing these metrics to measure the value of IT to the business, there is a clear trend towards doing so. In the future, fewer and fewer projects will be funded without these financial and business value justifications. In addition, companies are beginning to develop matrices of metrics that measure not just single projects, but service delivery on an end-to-end basis. Businesses are also relying less on metrics that evaluate IT internally and more on those that look at IT’s impact on the business. Finally, the most forward–thinking practitioners in the area of metrics for IT process improvement believe that metrics must be developed in conjunction with the business’ ‘maturity’ in meeting a hierarchy of needs, beginning with security and system availability and effectiveness and ending with innovation, aimed at balancing client impact against operational effectiveness.

XI. Summary and Conclusions Even though less than half of today’s businesses are developing the business value and ROI to justify IT spending, that trend is changing quickly. Going forward, IT departments must develop business value justification and ROI to fund new projects. This is evidenced by increasing pressure on IT executives to not only justify investments via traditional internal metrics but also to expand into metrics that quantify IT’s value to the business, such as ‘annual contribution’ to the

19 Ibid.

28 BVITIL_1111_fin

business, ‘benefit per developer’ and other types of metrics like increasing IT staff time on innovation versus operations. Specific metrics must be captured and developed for such ITIL practice areas as Incident and Problem Management; Change, Release and Configuration Management; and Service Level and Financial Management. In general, efficiency, effectiveness and customer satisfaction, applied to these practice areas, lead the way for the development of ‘core’ metrics, particularly for IT infrastructure projects. These metrics address both ‘hard’ and ‘soft’ dollars and should be applied both before (as benchmark objectives) and after IT projects (as a percentage of metrics achieved). Although each of these areas will have their own specific metrics prior to business case development, these metrics must be merged to reflect results based on ‘end-to-end’ service delivery. These ‘end-to-end’ metrics should reflect values that reach across the lines of business, highlighting the overall contribution to the business. This approach integrates traditional, internal IT performance metrics with broader business value metrics. Businesses must also develop metrics in conjunction with their maturity in meeting a hierarchy of needs that focus first on security and system availability and effectiveness and end with innovation, all aimed at balancing client impact against operational effectiveness. Finally, the entire development of business value process should be linked to a broader ITIL strategy that involves creating consensus around the acceptance of ITIL projects and selling the business value using metrics, return on investment and overall value contributed to the business by ‘end-to-end’ service delivery. This process should culminate in striking a balance between measuring performance for cost cutting and assuring that the ‘right’ projects, those that will provide real business and strategic value to the business, are funded. About Evergreen Systems Evergreen Systems is a highly specialized technology consulting firm focused on helping companies maximize the value of IT to their businesses. Evergreen specializes in ITIL (Information Technology Infrastructure Library) business case development and consulting and offers services that include Service Catalog development, Change Management consulting, Configuration Management Database (CMDB) development and Asset Management. From strategic planning, to policy development, through execution, Evergreen makes sure that what gets planned, gets done. Leaders in insurance, finance, healthcare and retail rely on Evergreen to address today’s major business challenges, including making ITIL and COBIT operable; understanding and organizing IT assets for better planning and execution; developing automated, streamlined compliance processes; and maximizing benefits through change, configuration and asset management. Global 2000 organizations work with Evergreen for sound strategy, flawless execution and measurable results.

Documents

Developing the Business Case for ITIL - Evergreen Systems · 2017-10-09 · Developing the Business Case for ITIL ... medium and large enterprises are developing the business case