So why are we doing this? There will always be an aspect of reporting that will show interested parties what the status quo of your environments and service is. There should also an understanding that someone reviews the information, digests it and leverages it to either directly make improvements to customer service, processes or infrastructure or does this collectively within IT as a whole.
Sadly, I can’t think of how many times I have submitted some metrics to be reviewed by a group and someone almost always says “looks great… but could we make this bar blue instead of red?” while the aesthetics may be important to some the content is what we really want to ensure is hitting the mark.
In the beginning there needs to be a simple and clear understanding of what we want to measure and why, a few objectives. We also need to ensure that we have a vehicle to take those outputs to make improvements in some capacity. Like many of you out there who regularly provide statistics to your organization either directly or indirectly (if they are able to access a dashboard of some type on their own). You need to keep this confined to a couple of Critical Success Factors (CSF) with a few KPI’s for each. Once we get a handle on these initial ones we can add others.
Leveraging the CSF’s to make a real difference in service can be made easier if you know what you want to achieve as a result.
Types of CSF to review may include:
- How efficient a particular process is
- How well your infrastructure is performing though availability etc.
- Improving the quality of service – does it perform the way it should
- Reducing costs for the IT department
While the uses for the results of your metrics may vary they should all be ultimately leveraged to make decisions within your IT organization for service improvements in some capacity. Some of these may include:
- Using the metrics for trend analysis
- Productivity reporting
- The need for (or not) of resources – human or otherwise
- Making comparisons from date “X” to the same time last month, year etc.
Now that we know what we want to measure and why, we should determine the way in which we gather data. Depending on the ITSM solution you have (or don’t) you should really ensure that the data you capture can be reproduced in the same manner each and every time. For example if one person pulls all incident information from “last month” and the next does the “last 31 days” they may have slightly conflicting information. When you go to provide the data to your stakeholders, any discrepancy, even a small one will allow the reviewer to question the validity of the information you are providing. In some cases your audience may discredit the information entirely making it a challenge to provide and leverage these stats in a meaningful way.
There is always going to be a different level of interpretation depending on who is reviewing the data you provide. The business stakeholder may have a different take on the information provided compared with your IT Operations Manager. The important thing to keep in mind is to use this as a dialogue point between the two groups and close any gaps so that the service you provide can be the forefront of all discussions going forward.