For whatever reason when the topic of metrics comes up on monthly basis, some IT Teams get “nervous” about what they might see as a result.
Why, you might ask?
The reasons could be as varied as the applications we support. For some it may be that they are concerned that they aren’t doing as well as their IT counterparts, for others it might be that our incident durations are not going down. Whatever the reason may be the fact remains your business already knows how well you are doing. Hopefully your organization is in a position to take these metrics improve on the delivery of service.
For me, I have always believed that there is no “bad” numbers as long as we are able to use them to make an improvement in some way. Reporting should open up our options for what needs to be improved.
Take, for example, the increased numbers of incidents or requests with no understanding on what is driving this increase. As you look closely into the potential driver know this, there is always something driving them. We might not be able to see it and it may not always be something critical. If you were to ask the teams which are impacted by the influx they may have some theories, and while in many cases their gut response may be accurate, we need to quantify the drivers for this to be able to tackle things appropriately.
Take the story of the frog in the pot of water. If you were to drop a frog in a pot of boiling water it will jump right out. However if you put it in warm water and slowly turn up the heat it will sit in there, possibly until it boils. This may apply to the way that you record and ultimately report on your incidents. You may only have a few of these now but when you look back after repeated business escalations you are shocked as how you didn’t put this all together while it was happening. This is where Problem Management pays in dividends.
The key is that with any improvement initiative is to have some quantifiable information to go back to. It really won’t matter if you have a formalized problem investigation or not if you can’t prove out what you are looking at. This is why we say that to make any real improvements you can’t do it only in one process. In this case we need to manage our reporting and document it somewhere, perhaps in a knowledge base.
This discussion started out talking about the reduction of incidents and now it sounds like we need to improve in many areas just to make some improvements. It sounds daunting but we need to take a step back and identify what we want to do and keep it simple and iterative. We need to start somewhere and that somewhere is today. We might stumble a bit, but you have to walk before you can use the “Turbo Boost”.
Check out Part 3 No Failed Changes, Incidents you say