Subscribe PDF Download Back Issues     Vol.  2.40 OCTOBER 11, 2006

I'm all in favor of keeping dangerous weapons out of the hands of fools. Let's start with typewriters.

            - Frank Lloyd Wright (1868-1959)

By Larry Cooper

Have you noticed that the plethora of industry articles, newsletters, and Webinar invitations that arrive in our Inbox with the really catchy titles generally fail to live up to the expectations they set for themselves?

Case in point, I recently received an article that purported to describe “The” Critical Success Factors (CSF’s) for ITIL. While it did have some CSF’s in the approximately 50 items listed, they were in the minority. Mostly it seemed like a stream of consciousness.

I thank the author for sharing his innermost thoughts, but I’d much prefer it if he had taken the time to at least organize those thoughts before he felt the urge to blast them into my already overloaded Inbox. It would seem that computer keyboards and e-mail have taken the place of the typewriter of Mr. Wright’s day.

The terms CSF’s, KPI’s, metrics, outcomes and benefits are sprinkled liberally throughout IT service management publications and articles. In this, the first of a three-part DITY, I will define each of these terms in the context of IT Service Management.

In Part 2 I will look at an ITSM implementation project where they are operationally defined, and in Part 3 I will delve into an operational IT Service Management environment where continuous service improvement through measurement and analysis of what they tell us about performance becomes the objective.

Hopefully, after my own opening, I’ll live up to your expectations. Either way, I welcome your feedback.  Let’s start with the main topic of the article that got my attention for all the wrong reasons.

Critical Success Factors

Critical success factors were first introduced by D. Ronald Daniel in a 1961 Harvard Business Review (HBR) article^[1]. Daniel highlighted the types of information needed to support top management activities.  He said that an organization’s information system should be selective and center on providing detail around three to six success factors that help the organization achieve success.

In 1979 Rockart defined CSFs as the limited number of areas in which satisfactory results will ensure successful competitive performance for the individual, department or organization. CSFs are the few key areas where “things must go right’ for the business to flourish and for a manager’s goals to be attained.^[2] The official ITIL Glossary defines it as “Something that must happen if a Process, Project, Plan, or IT Service is to succeed”

In an IT service management context, there are a number of fairly general critical success factors that must be present for an ITSM implementation project to be successful:

1. Strong executive leadership that clearly defines the objectives for implementing IT Service Management, are visible in their support of the organizational transformation that is necessary for success, are willing to communicate their commitment and the reasons why it is necessary , and who will continue to support it after implementation. They must resist the tendency to allow operations to revert to their old habits of expediency.
2. A maturity assessment of the existing IT processes that compares how well you do now to ITIL best practices must be undertaken as the first real step on the road to IT Service Management. If you do not know where you are, if you do not know what gaps exist in your current environment to what ITIL best practice would recommend, and if you do not know where you want to be, it is highly unlikely you will have a successful ITSM implementation. It is critical at this stage for the organization to recognize what it does already and to build from that base. It is a rare IT organization that does not have something to build on so don’t irritate everyone in IT by ignoring that fact.
3. Clear and measurable goals that are in line with the objectives of the ITSM implementation project or the service management process, that are based on unambiguous criteria, and  that can be used to determine whether the goals have been met.
4. Clearly defined roles and responsibilities for the project staff who are to implement IT Service Management as well as for those who must execute it in an operational mode must be established. The roles of the business, the various IT staff, as well as vendors and external support organizations need to be well defined, communicated and adhered to if the ITSM project and the subsequent operations are to be sustainable.
5. A well defined implementation and a continuous service improvement plan are critical. The implementation itself is about instituting organizational change. To do so, the roles, strategy and implementation plan must not only be well defined but clear and communicated to all stakeholders. The implementation project must be designed to deliver on its goals and objectives (look for a future DITY on setting up an ITSM implementation project). All affected personnel must be trained and ready for their new assignments. And all of this must occur before the implementation is done.  After implementation, a continuous service improvement program needs to be put in place to help the organization to sustain the momentum and move up the maturity scale.

6. Systematize each process in order to achieve true IT Service Management.  You need to use performance measurement of each process to help identify improvement opportunities. The real work begins when the implementation project ends.

Metrics

When we use the term metric we are referring to a direct numerical measure that represents a piece of business data in the relationship of one or more dimensions. A simple metrics statement is the “number of CI’s in error each month”. In this case, the measure would be the number CI’s found to be in error and the dimension would be time (month).

Metrics are not the KPI’s themselves; rather they are needed in order to determine if our KPI’s have been satisfied. The KPI that might use the above metric could be “% reduction in CI’s in error each month” – you need the number actually in error in order to determine the % of reduction over the previous month’s # of CI’s in error.

Key Performance Indicators

Key performance indicators represent a particular value or characteristic that is measured to assess whether an organization’s goals are being achieved. They reflect the critical success factors, stakeholder needs, and the expectations of the organization. For KPIs and their measures to be effective, the organization’s goals need to be specific, measurable, agreed, realistic and time-based. KPI’s can use both financial and non-financial metrics.

Some important concepts from the preceding discussion need to be highlighted:

• "Organization’s goals." It’s imperative that KPIs aren't set to standard industry goals but to your goals for your business. They must reflect your circumstances not industry averages.
• "KPI’s…need to specific…measurable, realistic, and time based." You must look at KPIs over time as you make improvements to your ITSM processes based on those KPIs. After a change is made to a process, did it drive KPIs in the direction we expected? Do the KPIs still have value or do they need to be updated or even replaced by others that are more meaningful given current conditions?
• "Agreed”. This is imperative as everyone must be on the same page, and the KPIs must be constructed by people with different viewpoints on the service or process being measured.

KPI’s are used in conjunction with CSF’s and must have a target that is to be achieved. The target for a KPI can be expressed as a percentage, a simple ratio, an index, a composite average or in a statistical context. Whatever is chosen as a KPI and a target must be actually measurable though. At the outset, keeping the number of KPI’s for a single CSF in the range of 3-5 is recommended.

A KPI is a key part of a measurable objective, which is made up of a direction, KPI, benchmark or target and a timeframe. For example: “5% reduction of CI’s in error each month" where “reduction of CI’s in error each month” is the KPI. See the DITY “5 Steps To Transparent Metrics” for an excellent discussion on how to define KPI’s and their metrics using the GQM method.

Metrics are used in conjunction with KPI’s to measure CSF’s. A KPI then, is simply a metric that is tied to a target to determine if we have met our CSF. Most often a KPI represents how far a metric is above or below a pre-determined target. In the examples above, you are able to determine whether the target for CI’s in error is being met by comparing the metric to the target for the KPI.

Now let’s turn our attention to benefits and outcomes.

Benefits and Outcomes

The terms benefits and outcomes when applied to a business context were popularized in a book called “The Information Paradox: Realizing the Business Benefits of Information Technology” by John Thorp of the DMR Consulting Group published in 1998. The practice became known as Benefits Realization and is now carried on by many top-performing organizations. The approach though was years ahead of its time.

First let’s define the key terms in Benefits Realization:

• Outcomes: the results sought, including either intermediate outcomes in the chain, those outcomes that are necessary but not sufficient to achieve the end benefit, or ultimate outcomes, the end benefits to be harvested.
• Initiatives: actions that contribute to one or more outcomes.
• Contributions: the roles played by elements of the Results Chain, either initiatives or intermediate outcomes, in contributing to other initiatives or outcomes.
• Assumptions: hypotheses regarding conditions necessary to the realization of outcomes or initiatives, but over which the organization has little or no control. Assumptions represent risks that you may not achieve desired outcomes. Any change to an assumption during the course of the benefits realization process should force you to revise your map.
• Results Chain Technique: used to build simple yet rigorous models of the linkages among the four core elements of the benefits realization process: outcomes, initiatives, contributions and assumptions.

Benefits realization is used at the beginning of a project to determine what benefits will accrue to an organization should they choose to execute the project. As all of the potential benefits from a project do not accrue at the same time, or may do so without going through intermediate steps or outcomes, it becomes critical to understand what will be achieved at each project stage, and especially whether any benefits will accrue if a project is cancelled either partially or in its entirety.

The genesis of the benefits realization approach was due to the large number of IT projects that were getting cancelled without delivering any real value (or benefit) to the sponsoring organization. Benefits realization helps you to identify the benefits of doing something and the initiatives that would be needed to be executed to achieve them.

As the initiatives that are needed to be carried out on a project get structured as discrete entities that deliver either a direct benefit or an intermediate outcome, it thus becomes possible to determine, in later project stages, the effects of the cancellation of a specific initiative - i.e. what benefits will we not get if we cancel it. This is a powerful business tool for protecting project investments.

An important point to note with benefits realization is the recognition that not all benefits are accrued upon project completion – many may take years before they can be fully reaped by the organization. To track the benefits accrual, a ‘benefits register’ is set up which usually contains the following kinds of information about each outcome:

• Description of outcome
• Contribution – what/to whom does it contribute
• Metric/Frequency – how do measure its realization
• Measurement method
• Baseline value
• Target value/date
• Tolerance limits
• Action if outside tolerance limits
• Accountability
• Benefits profile – i.e. increase, decrease, ratio, etc.

This register then becomes like a dashboard that can be used to determine if the results of having conducted the project are in line with the expectations that were established at its inception.

Just as with any other significant project investment, the benefits that will accrue from conducting an ITSM implementation project need to be clearly defined and the initiatives that are needed to be kicked off to achieve them must be carefully planned. This is where the maturity assessment mentioned earlier comes in. It will help you determine the sequence of your ITSM implementation and understand which benefits will accrue from each initiative and when they will accrue. This also helps with setting and managing expectations as well as demonstrating the value of ITSM in manageable increments. Over time, just as with any other project type, you can then track your own benefits register to demonstrate the value that the ITSM project delivered.

Summary

In summary, anyone that is planning to implement IT Service Management needs to understand the clear distinction between CSF’s, KPIs, Metrics, Benefits and Outcomes. You cannot apply what you do not understand, so understanding the differences in these key ITSM concepts and how to apply them appropriately to your ITSM project, is a key ingredient to a successful implementation.

In the next DITY in this series I will discuss the link between Benefits Realization, CSF’s, KPI’s and Metrics and how they can help you execute a successful ITSM implementation project. In the  final DITY in the series I’ll demonstrate how they contribute to not only being able to achieve the value that ITSM can bring but also how they underpin an ongoing Continuous Service Improvement Program (CSIP). Keep watching your Inbox!

--

About Larry Cooper
Mr. Cooper is co-founder of ISM Canada, an Authorized itSM Solutions provider and a VAR for Touchpaper’s ITBM Suite of products.  Mr. Cooper has spent more than 28 years in IT in the public and private sectors where he has held roles such as a Software Developer/Programmer Analyst, Manager of Operations, Lead for Business Process Re-engineering, various Project Manger roles on projects upwards to $100M, and A/Director, Business Technology. He has written and been published in books and industry articles on variety of topics. He holds three project management certifications including a PMP, an IT Service Manager certification, and is an EXIN accredited Master’s level trainer.

Where to go from here:

Entire Contents © 2006 itSM Solutions LLC.  All Rights Reserved.