Selecting Metrics to Demonstrate IT Value
IT is a considerable financial outlay for most businesses, and IT organizations must continually prove their strategic value. They can effectively demonstrate the value of their contributions by selecting and reporting metrics, but the challenge is to choose the right metrics.
Fri, June 10, 2011
Network World — This vendor-written tech primer has been edited by Network World to eliminate product promotion, but readers should note it will likely favor the submitter's approach.
IT is a considerable financial outlay for most businesses, and IT organizations must continually prove their strategic value. They can effectively demonstrate the value of their contributions by selecting and reporting metrics, but the challenge is to choose the right metrics.
In order to select the right metrics for your key performance indicators (KPIs) you must gain a clear understanding of metric characteristics. An effective metric meets the following criteria:
• Is tied to a business goal.
• Is important to the customer.
• Measures a single condition or event.
• Is easy to measure and report.
• Has specific results that support decision making.
IN DEPTH: Revitalizing IT's worth
Use the fewest metrics possible but enough to verify that you are receiving adequate information to make informed decisions. This approach helps you to focus on priorities.
Metric characteristics form a boundary that separates possible KPIs from all possible metrics. A good example of a metric might be "percentage of IT budget supporting projects." This metric is tied to the goal of responding quickly to business pressures. It is important to the CIO and the business customer. It measures the value IT brings to a business, is somewhat easy to measure, and gives management an idea how well IT responds to business pressures. Another metric, such as "number of service level agreements (SLAs)," may not be valuable if no SLAs currently exist and no efforts are underway to build any.
Just as IT organizations will change in maturity, so will the metrics used to measure success. The situation on which the metric is reporting may be usurped over time by other, more relevant situations, or the maturity of what is measured may move to a "steady state" condition. Progress may limit the value of a metric over time. The concept of metric aging can be demonstrated by the following example:
IT strives to become more efficient by eliminating shadow IT (work by IT that is adding value but is not measured). The plan is to eliminate shadow IT by edicts and by preventing IT employees from receiving credit for incident resolution without creating a ticket.
By eliminating shadow IT projects, such metrics as "number of incidents captured by the service desk per month" can be expected to go up. As users learn to open tickets to get their issues resolved, the number of service desk tickets is likely to increase. As time goes on, however, the number of service desk tickets per month may level off. If this occurs, the metric loses much of its value, and it may make sense to replace it with a new one, such as "the average cost of a desktop incident." It's important to re-evaluate your metric choices once a year.


