Slashdot Mirror
Ask Slashdot: Good Metrics For a Small IT Team?
First time accepted submitter shibbyj writes "I'm a member of a small 3 person IT team for a medium sized business (approximately 300-350 employees) that has multiple locations internationally. I have been tasked with logging our performance using the statistics from our ticket management system. I've also been tasked with comparing these stats and determining if we are performing above or below what is considered optimal. I'm wondering what people opinions are on what good metrics should be in regards to mttr mtbf etc. I have had trouble finding information on this."
One of you is getting fired
"what good metrics should be in regards to mttr mtbf etc"
Easy, there are no good metrics. Metrics don't lead to improved business outcomes, they rarely cover enough variables to tell the whole story, so all they lead to is people gaming the metrics, most likely leading to worse business outcomes.
Metrics are favoured by lazy management.
Simple... if you have a 3 person IT team at a 300 employee company and your site / it infrastructure isn't in nuclear meltdown your probably doing good. Looks like they are going out of house for IT. Welcome to the cloud-future, where your job is dissolved for magic.
There is no metrics system that can't be gamed.
If you set it for "total tickets fixes" (higher=good): you just encourage people to report trivial problems you can fix easily.
If you set it for "total tickets" (higher=bad): you refuse to do things, add features etc, or you make it hard to contact IT to log a fault
If you set it for "time taken per ticket" (higher=bad): you end up pushing kludge solutions
If you set it for "user rated response" (higher=good): you end up blackmailing the end users to rate you 10/10 otherwise their emails/logs/dirt etc get published and sent to boss/wife/etc
Ask your manager how their performance is evaluated? Then start suggesting ways they could bust their KPIs, and they should get the drift.
1. make your numbers.
nobody actually cares what 'the numbers' are, or if they actually mean anything. but you have to make them.
you might ask yourself - isn't this a huge waste of time? isn't it completely counter productive? doesn't it actually decrease efficiency? aren't the metrics measuring completely the wrong thing? as the slashdot story the other day said, aren't bad metrics actually worse than no metrics, because they cause people to do inane, wasteful things to make their numbers?
well, your problem is that you are asking yourself. in a corporate environment, do not ask. just do.
just make the numbers.
hopefully, if you get good enough at 'making your numbers', you will have time left over to actually do some work.
2. but what about the theory of capitalism, the free market, efficiency, etc?
its all bullshit. just like the theory of communism was bullshit. what statistics and 'numbers' were reported to the government were just flat out garbage. people somehow managed to make the system work through personal relationships and working-around the assholse in charge. but most of the theories it was built on have no resemblance to reality. think about it - if efficiency really made for the best corporation, why would you be spending 4 hours a week filling out meaningless statistical performance reports that nobody will ever read, let alone understand?
the only difference between the soviet union and 'the west' is that 'the west' still hasnt collapsed yet.
Might as well close the comments now. :-)
Go look up Robert Austin's book on measurements and management. Read it and recognize that you've been given a task that is at best counterproductive and at worst impossible. Dust off your resume, because it may be more than one of you that are getting fired. ..bruce..
Bruce F. Webster (brucefwebster.com)
Totally agree.
My small team was taking a beating and getting little support from management. Issues were piling up, we were getting randomized, and I felt like I needed another staff member. Management wouldn't budge though. I needed to prove to them that I could manage my department better. Nobody even cared about IT metrics at our company. Rather than see them as an evil thing, we embraced them to gain credibility in our organization.
We started by outlining some of our support boundaries, types, and set goals for response times. Then we customized our ticket system and added in some categories and priorities.
For Support (meaning something is broken and must be fixed)
High pri: 24 hour solution
Medium pri: 1 week
Low pri: 3 months or more, not a critical metric
We also had a "Request" category (not a fix, but doing standard tasks like toner replacement, adding e-mail alias, help train someone, etc.). These had different goals for solutions. We even had ticket categories for maintenance and projects. Though they junk up the ticket system, it allowed us to track time going into other tasks and paint a picture of a staff member's whole day of work, not just the support end.
Some of our favorite metrics:
1. Average time on support OR request tickets aggregated by our team or split down to individual staff members, and divided by priority level.
2. Total time spent on tickets by user (so I know if we're actually working or lounging around). ---this is a motivator for staff to actually enter tickets and get credit for their work. Some flexibility is necessary here because people eat lunch and go to the bathroom - you can't expect this to add up to 40 hours a week perfectly.
3. "Most troublesome user or department." I don't advertise the data on this report, but it lets me know who to focus on with either training or nudging their boss a little. Execs get interested in this once in a while, and the users that found out we keep such a log try to keep off of it. Many will joke about it, but still ask "Hey I'm not in the top 10, right?" It encourages users to be a little smarter and not lean so heavily on IT for silly things.
4. Most troublesome product - THIS IS BY FAR THE BEST METRIC. This has helped me gain support in dropping old junk software, getting better solutions, setting up training for people, or creating general awareness that we need to improve. For example when I was able to quantify how much time it took when people forgot their passwords for our cloud-based e-mail password, I got support for Office 365 and ADFS for single sign-on. In the interim, people stopped took a little more personal responsibility because they realized that password stupidity = preventing us from getting value-added projects done. Stuff like this is beautiful because it takes most of the heat off of IT staff, and informs other managers of our company-wide pain points that we should invest in.
5. On the same lines as #3, identifying how many high pri tickets are out there vs. medium or low (and possibly categorizing by customer or department) can sometimes sniff out IT abusers that need stuff now now now. Tread on this carefully as you don't want to constantly wage war with your metrics, but with some political prowess and some data to back you up, you can start solving some of these problems.
#3 and #4 are big for us. Don't just think of metrics in terms of how you will hang yourself. Think about the bigger picture and answer questions that will help motivate your team in a positive way, get credit for what they/you do, and enable you to tell a better story to management. You probably will want to develop two sets of metrics - a more detailed set for yourself so you can manage effectively and proactively identify problems (and solve them in advance before your boss gets to it), and a more general set for your boss so you can deliver a simple and concise picture without getting him too involved with the details you can handle yourse