Lord of the Metrics

Every organization is looking at understanding IT performance. As a department, IT should be vigilant at applying information processing capabilities that benefit the business. In order to meet this requirement IT must provide the following services while managing costs and prioritizing requests to optimize value:

  • Operate and support the infrastructure required to process, store, secure, and communicate information
  • Operate and support the business applications that process information
  • Provide technology consulting, training, and planning services
  • Employ, train, and deploy staff required to provide these services
  • Plan, develop/purchase, test, and implement new infrastructure or software to fix problems or
  • provide enhanced information processing capabilities to the business

Every organization will have slightly different metrics for measuring IT performance. For my organization I have decided to report on the following:

  • Helpdesk tickets –Number of open vs closed
  • Network outages – Number of hours wan circuits are down vs SLA
  • Software development life cycle (SDLC) – Number of projects in each phase of the SDLC and average times in each stage.
  • Email – # of emails entering the organization vs being blocked due to spam, virus, etc.
  • Equipment uptime – Average equipment availability
  • Project budget – Approved estimated budget vs actual and % completion
  • Application performance – average availability

Some of the metrics represent averages while others are reported in the form of a graph. I have decided to  report these metrics on a regular basis (monthly is the minimum recommended reporting period),so that I can spot  trends across the reporting periods. In some cases the trends are more important than the actual value. No averages can hide significant problems. Some of the data elements are designed to identify significant problems that may go unnoticed by simply reporting averages. So in some instances I am capturing specific data points with a roll up.

IT Metrics Continued – CIO to CIO

In my previous post, IT Metrics Introduction – CIO to CIO, I discuss that CIOs need to focus more on presenting business relevant metrics. I discuss that CIOs should look at presenting 3 metrics that can show the value of IT.

  • IT Investment Value – Present the value of IT investments by looking at the cumulative return of the entire portfolio

This metric is generated by sorting all projects in the portfolio by their net present value (NPV). If you graph this out with Total $ value on one axis and number of projects on the other axis and each project value plotted you can graphically see where projects stand.

Don Lewis recommended that on portfolio value measurements, success metrics for individual projects should be established prior to implementation and then measured and reported for some period after go-live. While this is a bit more micro level, it can feed into the metric of return on portfolio. (Thanks Don. Good thought).

  • IT Spend – New investments versus operational spending

IT departments begin devoting more and more of its budgets to maintenance. By looking at the IT spend ratio on new investment versus operational spending you can begin to get a sense of where budgets are being devoted. According to Forrester Research, the average IT organization spends 70% to 80% of its budget on maintaining the status quo versus only 20% to 30% on new initiatives. Best practices companies have taken this ratio to 60/40, and some are actually driving toward 50/50. Measuring and reporting this ratio can be a key indicator of both the efficiency of IT as well as IT value creation this ratio can be a key indicator of both the efficiency of IT as well as IT value creation.

  • Service Availability – IT performance compared against service-level agreements

I am not a fan of surveys. I think they are a snapshot in a point in time and are difficult to get proper feedback. IT performance compared against service-level agreements (SLAs) are a much better metric.

When SLAs are divided by mission critical applications or business services, they can be valuable indicators. With SLAs you can quantify and qualify the business impact of failing