Metrics for IT Management

We all know of our basic type of metrics (say uptime/downtime, traffic in/out) and from there we branch into looking at what ITIL provides (such as say, change management). When you go looking for software to monitor/measure/report or god forbid quantify these, you come up with either Cognos or Accenture. Now, not to shove a stick in the big players eyes (and not to say they don't offer good products), what does the little guy do? The manager who has 5-8 staff and an ever growing room of equipment.

As managers, we should have a keen insight not only into the health of our little patch but also to what changes are coming up and what kind of issues we are facing. In many cases, they are easy to identify but they aren't so easy to quantify, in fact most of the managers I have met in these positions know exactly what is happening - they also know that gathering that data into anything which the PHB's will understand is sometimes a task of no insignificant effort.

Graphs, for the most part are dime a dozen, anyone with a basic understanding of RRdtool and associated higher level software (nagios, mrtg, etc.) knows that the information exists and to some extent is already quantified. Part of the problem is that information isn't unified, the PHB's are going to glaze over if you have them look at 200 individual uptime/availability graphs - they just want to be able to say "our systems have 5 9's of reliability and availability" followed by a string of buzzwords they barely understand.

This is all well and good, but those graphs forget about one very key aspect of IT and IT Management - the PEOPLE. Those systems don't install themselves, they don't operate in autonomous vacuums and they sure as hell don't fix themselves when the fecal matter hits the oscillating bladed cooling device. This is a fact which tends to get forgotten once you get past the manager level - it only get remembered when budget time comes around the CTPHB has to protect his patch of the organization. Then and in almost every case I've seen only then, does the need suddenly appear on the collective doorstep saying "I need this information by next Tuesday".

Change Management will tell you when changes occurred, why they occurred, were they successful, the approximate time estimate. Human Resources might be able to tell you the amount of overtime that was accrued for your team (that is if you work in a company which is kind enough to give overtime to IT employees or time off in lieu - side note HAHAHAHAHAHA). If we have learned anything, getting information from other departments is usually an exercise in frustration and when we do get that information, it tends to be in a format which is as useful as a one armed man paddling a canoe.

So, what do you do if you aren't lucky enough to hae Cognos/Accenture/Remedy at hand and an HR department that isn't bent on world domination through hot cocoa samplers? Well, it's a damn good question, one which I'm really only starting to look into. The simplest thing we as managers can do is record the activities, could be excel, could be a trivially whipped php/mysql db. The second part of that is presentation, if everything is running fine, great, if there are areas where you need resources, then now you have easy concise graphs even the most basic poo flinging PHB monkey can understand.

Normal Work Hours + Department Request (Pie Chart)
- by department
- by employee/resource
Extended Work Hours + Departmental Request (Pie Chart)
- by department
- by employee/resource
Project Work Hours + Proejct Request (Pie Chart)
- by project
- by employee/resource
Resolution Work Hours + Issue
- by system
- by department
- by employee/resource
Unified System Health Histogram (supported by break-out graphs as required)
- by year
- by quarter
- health issues coded to system and or department
- by cause
Usage Histogram
- by service (internal nework, external nework, systems)
Tickets In Start / Tickets Out End Histogram
- min / median / max
- by department
- by system
- by year
- by quarter

Now, there will be those who argue that ITIL provides for all of these things. If you don't have ITIL training or as a group nobody has it, then it becomes a bit of a different story. It's an even bigger story about actually integrating ITIL into an organization.

At the end of the day, we want to showthe organization the value we bring to it and the value we bring to the departments. We also want to show where we need resources to make sure everyone else achieves the organizational goals.

Just think of it this way, a picture is worth a thousand words and as PHB's have a limited vocabulary, well, you see where I'm going.