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 CSFs 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 CSFs, KPIs, metrics, outcomes and benefits are sprinkled liberally throughout IT service management publications and articles. In this DITY I will define each of these terms in the context of IT Service Management.
Hopefully, after my own opening, I'll live up to your expectations. Let's start with the main topic of the article that got my attention for all the wrong reasons.
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:
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 CIs in error each month." In this case, the measure would be the number CIs found to be in error and the dimension would be time (month).
Metrics are not the KPIs themselves; rather they are needed in order to determine if our KPIs have been satisfied. The KPI that might use the above metric could be "% reduction in CIs in error each month" – you need the number actually in error in order to determine the % of reduction over the previous month's # of CIs in error.
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. KPIs can use both financial and non-financial metrics.
Some important concepts from the preceding discussion need to be highlighted:
KPIs are used in conjunction with CSFs 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 KPIs 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 CIs in error each month" where "reduction of CIs in error each month" is the KPI.
Metrics are used in conjunction with KPIs to measure CSFs. 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 CIs 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.
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:
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:
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.
In summary, anyone that is planning to implement IT Service Management needs to understand the clear distinction between CSFs, 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.
[1] Daniel, D. Ronald, "Management Information Crisis," HBR September-October 1961, p. 111.
[2] Rockart, John F., "Chief Executives Define Their Own Data Needs," Harvard Business Review, March-April 1979, p. 85.