Interpreting your IT Service Management Data & Reporting

Customer Billy asks for help in producing his first management report. He's read our IT metrics white paper and other KPI posts, but writes 'my problem is one of interpreting the data. I've got a lot of data and interpreting it all is doing my head in. My predecessor never did any reports'.

First of all, be clear about why you are writing the report, and who the report is for. Is it for your own benefit to help you manage the IT service more effectively, or is it to show someone else how well or otherwise IT service is managed & delivered? Be absolutely crystal clear in your own mind about this. Having asked Billy about this, the audience is primarily himself and his team.

Right now, their team has a functioning Incident Management and Asset Management process, so this is what Billy should look at first. The next six months will see them define a Problem Management process, and begin work on their Service Catalog.  Both of these will increase the options for reporting.

One of the things that the white paper does is group different types of performance data together. Some of the data is really easy to understand: Input data and Output data. Input data is primarily the raising of Incidents, and Output data is the resolution of those Incidents.

If you are reporting monthly, why not look at 3 things:

  • Incidents logged month-on-month over the past 3 months
  • Incidents resolved month-on-month over the past 3 months
  • Backlog at the end of each month

First of all, you can get all three values from report ES1 – it's an Executive Summary report you'll find in SerioReports – just put in your data range and run it (there is a lot more data there as well, which I'll ignore for now).

Billy's question was about interpretation. So, where's some things you can ask yourself:

Is the number of Incidents logged rising or falling, when looked at month on month? If it's falling then great, if it's rising then try to examine why that is.

Remember some fluctuation is to be expected ('statistical significance') but a significant jump of (say) 15% or more is something to look at more closely..by running more reports. For example, run reports by Problem Area or Department – is one particular technology or use group responsible for the increase? If so, why? (at this point, examination of individual Incident records can often be quite revealing).

When looking at the number of resolutions, is it broadly in keeping with the number of Incidents being logged, or is there a backlog developing? If there is, why do you think this is so?

Asking these questions will help you identify problems, but will also (hopefully) lead you to solutions. As an example from my own career, an increasing backlog (and worsening timeliness of resolution) at a company I once worked at was due to increasing amounts of staff sick leave. I already knew we had problems in this regard, but it was revealing nonetheless to see the results on service delivery (the IT service chart and the sick leave chart correlated).

My own reporting schedules have typically been: run some standard reports (report I always run each month) and then, from time to time, run others to 'dig a little deeper'.

In addition, you can look at timeliness of resolution from a Service Level Agreement perspective (you'll also find this on ES1, amongst many others).

Bottom line: obtain data that reflects your own IT service management disciplines, and apply some though about what this means for your IT service group.

Categories: