Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Ask Slashdot: Good Metrics For a Small IT Team?

samzenpus posted more than 2 years ago | from the measuring-up dept.

Businesses 315

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."

Sorry! There are no comments related to the filter you selected.

Hahaha (5, Insightful)

mewsenews (251487) | more than 2 years ago | (#38392346)

One of you is getting fired

Re:Hahaha (5, Insightful)

ITConsultant (2525166) | more than 2 years ago | (#38392432)

As a professional IT consultant, I would concur with the parent statement.

Also, the title is a bit redundant: all IT teams are small.

Re:Hahaha (5, Informative)

Anonymous Coward | more than 2 years ago | (#38392622)

Yes, this.

Management wants to eliminate someone and wants to do so in an "objective" way to hide the fact that they're firing someone while probably giving the CEO a fat Christmas bonus. You're tasked with figuring out which of the three of you gets fired and how you can cloak this in enough "objectivity" that no one can object to it. Your best bet is to make this shit up. Figure out who the weakest link besides yourself is, or who you like the least, and generate a system of metrics that's biased towards eliminating that person. Use lots of acronyms and jargon. Also, make sure no one at work reads Slashdot.

totally irrelevant CAPTCHA: forgive

Re:Hahaha (3, Insightful)

Anonymous Coward | more than 2 years ago | (#38392794)

If there were any justice in the world firings would start at the top. Fuck management and their big salaries. What the fuck are they doing that they have to be paid so much? What value do they bring to a company? They're too happy to fire you to make more money for themselves (the fact that most people are one paycheck away from financial ruin doesn't seem to bother them) but do they ever get fired even if they run the company into the ground? Fuck no. I'd love nothing more than to see some of the bosses I've had in the past be out there pimping their own wives and daughters to make enough to cover the mortgage that month. Hell, they should be taking loads bareback from guys with AIDS. They deserve it.

Re:Hahaha (5, Funny)

Jeremiah Cornelius (137) | more than 2 years ago | (#38392800)

The very core of your writing while sounding reasonable initially, did not sit perfectly with me after some time. Somewhere throughout the paragraphs you actually were able to make me a believer but just for a very short while. I however have got a problem with your leaps in logic and one would do nicely to fill in all those gaps. If you can accomplish that, I will surely end up being fascinated.

Re:Hahaha (0)

Anonymous Coward | more than 2 years ago | (#38393416)

The very core of your writing while sounding reasonable initially, did not sit perfectly with me after some time. Somewhere throughout the paragraphs you actually were able to make me a believer but just for a very short while. I however have got a problem with your leaps in logic and one would do nicely to fill in all those gaps. If you can accomplish that, I will surely end up being fascinated.

Which part sounded "reasonable" to you? Was it the part about bosses being forced to "pimp their own wives and daughters", or the part about bosses being forced to get some "bareback from guys with AIDS."?

BTW, I'm not the Anonymous Coward from the post in question. I'm a totally different Anonymous Coward.

Re:Hahaha (1)

Anonymous Coward | more than 2 years ago | (#38393466)

I'll take "pimp their own wives and daughters" for 800, Alex.

Re:Hahaha (4, Insightful)

Anonymous Coward | more than 2 years ago | (#38393468)

Yet another AC here.

If there were any justice in the world firings would start at the top. Fuck management and their big salaries. What the fuck are they doing that they have to be paid so much? What value do they bring to a company? They're too happy to fire you to make more money for themselves (the fact that most people are one paycheck away from financial ruin doesn't seem to bother them) but do they ever get fired even if they run the company into the ground? Fuck no. I'd love nothing more than to see some of the bosses I've had in the past be out there doing actual work.

Is this better?

Re:Hahaha (4, Funny)

wmelnick (411371) | more than 2 years ago | (#38393528)

An obvious troll. In order to become management you have had to prove yourself over the course of many years. While you may think those above you are useless, they would not be there had they not done what you did first and for probably longer than you have.

Re:Hahaha (0, Redundant)

bsane (148894) | more than 2 years ago | (#38393552)


Re:Hahaha (1)

Ethanol-fueled (1125189) | more than 2 years ago | (#38393396)

Top-poster advice giver whore here, again.

Aggregate a list of companywide credentials, exploits, proprietary(especially humiliating) information, and publicly release it(don't sell it, that's tacky - and put it up with adequately-protected domains in non-American-siezable countries publicly documenting and e-mailing your former employer's customers the damning information) for the "LOLs"(a slang term meaning 'laughter at another's expense').

Make them pay.

Re:Hahaha (0)

Anonymous Coward | more than 2 years ago | (#38393532)

This is at least more subtle than the guidelines I was just given for my team's performance reviews (in fact every lead got the same guidelines): 20% outstanding, 60% doing their jobs, 20% underperforming. *Must* fit the reviews into this spread, no questions. Preparing us for what I assume are 20% cuts across the board is one thing, making us unfairly give people bad reviews just so management can feel good about canning good people is fucking horseshit. There are rumblings of a revolt, but it's hard when they have you by the balls. I hate working for a large corporation.

Re:Hahaha (1)

aurizon (122550) | more than 2 years ago | (#38393546)

Yes, make the shit up, but with a veneer of plausibility, that a lawyer in a improper dismissal law suit will tear to shreds, and the lucky fired one get a year or two of lawsuit wages. Then you get fired, and there is another lawsuit, at which your earlier chicanery is revealed, you go to jail, you are forced to form a protective alliance, you find you like it...

Re:Hahaha (0)

Anonymous Coward | more than 2 years ago | (#38392892)

> One of you is getting fired

This should be modded Insightful

Done in one (4, Funny)

Weaselmancer (533834) | more than 2 years ago | (#38392928)

Seriously I just have to say that this is the single funniest comment I've ever read on Slashdot. Laughing, pointing at the screen, drug my wife over here to have her read it funny. Brutal. Absolutely brutal.

From one cynical bastard to another, I salute you.

Re:Done in one (1)

ohnocitizen (1951674) | more than 2 years ago | (#38393454)

"drug my wife over here to have her read it funny" - It is a hilarious comment, but did you have to slip your wife a little meth/crack soup just to hear her read it in her "zombie donald duck" voice?

Re:Hahaha (1)

SpacePunk (17960) | more than 2 years ago | (#38393140)

I was coming in here to say that. LOL

Re:Hahaha (5, Insightful)

JoeMerchant (803320) | more than 2 years ago | (#38393160)

One of you is getting fired

On a three person team, metrics are irrelevant - personality and politics are 100% more important than technical skill.

If you've got 15-20 people and it's time for a 10% downsizing, or (less realistically), performance based bonus or advancement, then metrics start to be something worth looking at.

When I had to choose between 2, my boss asked me who was my choice, I told him, he agreed, I started to tell him why, he stopped me and said: "it doesn't matter why, I'm just glad that we came up with the same answer."

Re:Hahaha (3, Interesting)

Anonymous Coward | more than 2 years ago | (#38393506)

Concur with the "someone is getting fired". 3 people supporting 300+ people. That's overtaxed, even school teachers only have to deal with 30 potential-assholes for 8 hours a day and have to put in unpaid overtime because you can't just leave things when the shit hits the fan 10 minutes from clocking out.

As for metrics, serious or otherwise, 3 person team, you should already know who the weakest link is (hint, -you- if you don't come up with a solution.) The boss always asks the least intimidating person, therefor the boss thinks you're the one who could find a reason to fire one of other two people.

Personally I'd tell the boss that you're understaffed as it is, and this is taking time away from valuable IT time.

And if you want a "but I want to do it" answer. The best metric to use "whoever does the worst halfassed job consistently" , also known as the person who shoves work off onto other coworkers (like your boss is doing) when it's they should have taken ownership to begin with.

Re:Hahaha (0)

Anonymous Coward | more than 2 years ago | (#38393316)

And your boss is lazy.

I just can't add anything to that (4, Insightful)

bfwebster (90513) | more than 2 years ago | (#38393418)

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..

Re:Hahaha (-1)

Anonymous Coward | more than 2 years ago | (#38393488)

One of you is getting fired

One of you is getting fired

One of you is getting fired

One of you is getting fired

Lovely bear keychain, so convenient and beautiful! As the gifts send to your friends, classmates and lovers.
You are worth it! More surprise on the It's the right toys mall [] ! toys shop toy store novelty toy

Metrics suck (5, Informative)

SJ2000 (1128057) | more than 2 years ago | (#38392362)

Didn't we just have a story [] about how metrics suck?

Re:Metrics suck (2)

JMJimmy (2036122) | more than 2 years ago | (#38392468)

Great read too. I question this:

determining if we are performing above or below what is considered optimal

How do you determine 'optimal'? How you determine that determines the metrics you use.

Re:Metrics suck (4, Interesting)

Ethanol-fueled (1125189) | more than 2 years ago | (#38392518)

Top-post whore responder advice giver here. As somebody who works in a company with very similar numbers described in the summary, the few IT personnel should take over some of the infrastructure programming duties like databases and internal support software and use their existing knowledge of the corporation to prepare to either take on more work or transfer to a different position or department within the company.

Don't know how to program? Hit the books - your job may depend on it.

Re:Metrics suck (4, Informative)

ScuzzMonkey (208981) | more than 2 years ago | (#38392530)

Bad metrics suck, good metrics are useful data.

As folks have already mentioned, time to answer and time to resolve are both important, and I think you have to watch for re-opened as well to curb "how fast can I shove this under the bed?" resolution games.

My favorite is average tickets per user, though. Particularly on a small team, what you really want to gear your measurements toward is preventing incidents in the first place. It is helpful to know what your overall ticket volume looks like, then, and to aim to decrease it over time in the same way you might try to decrease time to answer and time to resolve. That's important, because as the previous article suggests, if you will get what you measure... and your overall goal should not simply be to answer tickets faster and resolve them more quickly, but to not have as many in the first place*. Every issue represents a waste of somebody's time and therefore corporate resources that could be put to more productive uses. Steadily decreasing mtta and mttr are nothing to cheer about if your ticket count is increasing.

But you can keep it simple. You can drown yourself in metrics and lose sight of why you're tracking them and what you really want to accomplish. You may not really need any more than these few; better to start small and add what you need when you need it. I know there's always tension over getting a system in place that can capture what you need for historical purposes when you realize you need to know something new down the road, but resist the urge to over-collect. Half the time you won't need it all and are just wasting time getting it in the system.

* There is a caveat to this; in some organizations, I actually DO want to see an increasing ticket/user count, at least for a time. This is something I shoot for when relations between IT and users have broken down badly enough that users have stopped reporting problems to IT because they feel it's useless, and their issues are never resolved anyway. In those cases, a rising ticket count can represent an increasing trust level, which is good. You generally won't fix issues you don't know about.

Re:Metrics suck (1)

realityimpaired (1668397) | more than 2 years ago | (#38392784)

First call resolution is almost as important as 7 day repeat rate... while you do want to look at things like mttr, you want to be careful with using that as a hire 'em and fire 'em metric, because it will encourage people to cherry pick easy problems, and can penalize the people who get stuck with the hard issues. It takes 5 minutes to configure somebody's e-mail client, but it will take much longer if you have to order parts to replace defective hardware.

Re:Metrics suck (4, Informative)

CAIMLAS (41445) | more than 2 years ago | (#38392888)

Metrics is just a management word for "bad statistics".

With a distribution of 3, it's not really possible to have statistics of meaningful nature. You've got shared responsibilities and bounce things off of each other. One person may open and close more tickets, have a shorter duration for tickets, etc. - but he's only doing the actual "work". The others may be giving him all the input necessary to complete the task(s).

Ideally, your ticketing system will reflect, very vaguely, who's doing work and who is not, but even then it's not going to be well representative of what's actually going on.

People do different types of work, of different levels of difficulty. For instance, I may do one ticket on Monday, three on Tuesday, and one for Wednesday through Friday. Why? Aside from the fact that I'm bad about actually doing tickets for my work (my god, I'd not have the time for work, and then there'd be more things that aren't getting done, making us -all- look bad), there's the reality that my tickets aren't terribly easy, often requiring hours of log perusal and research to try to fix problems. Meanwhile, the guy who knocks out 40 tickets a week - malware disinfection, workstation reinstalls, etc. - has fairly wrote work of a repetitive nature, comparably. Also, he's following instructions or asking for advice on a regular basis, even if I'm not his boss.

You said so yourself: you're a member of a 3-person IT team. The only use 'metrics' have here aside from what should be plainly obvious in a group of 3 (who's fucking up, who's not getting back to people, who's not doing work) is to keep track of what amounts to customer requests and problems. X workstation needs to be reinstalled, Y server has a crashing whatever, and so on. If you're working on and sharing a ticket queue, you are all mutually responsible for all of the tickets: if something isn't getting done, it's everyone's fault (or nobody's fault). You may consider presenting your metrics in the light of this reality (like statistics, metrics can lie, too).

Re:Metrics suck (1)

Anonymous Coward | more than 2 years ago | (#38392946)

"My favorite is average tickets per user, though."

You can't think of a single way to game that?

This is exactly like the classic security design problem. People can design security systems that they can't break into, not systems that can't be broken into.

Re:Metrics suck (1)

Anonymous Coward | more than 2 years ago | (#38393458)

Average tickets per user guarantees you lose the best people first.
Since they always end up with the non-trival problems which take non-trivial time to resolve.

Good way to fuck the company though, and since they are firing you anyway .....

Re:Metrics suck (1)

sjames (1099) | more than 2 years ago | (#38393470)

The problem with metrics is that if you look closely enough at things to actually KNOW if they're good or bad, you know enough to not need them.

Is the guy with the lowest average tickets slow or is he the guy that takes the hard ones because the rest of the team doesn't stand a chance of solving them? If you know the answer to that question, he is already evaluated, what do the metrics contribute? As you point out, a declining ticket count can be very good or very bad. If you know which it is, you already know how you're doing.

There can be SOME value to measuring, but all too often, metrics are like the guy that thinks the bathroom scale can actually measure to 0.1 pounds because he's pretty sure he can eyeball 10 positions between lines on the dial.

Re:Metrics suck (2)

Sarius64 (880298) | more than 2 years ago | (#38393046)

When help tickets are all that matters, you'd be surprised how many tickets get generated.

Re:Metrics suck (5, Interesting)

MichaelKristopeit422 (2018884) | more than 2 years ago | (#38393446)

i'm dealing with a bug detecting team in india right now through a client (their choice to use them)... they use "fixed" bugs as their main metric.... so they file tons of bugs... we waste tons of time explaining why there isn't a bug, then they agree and say "ok we'll mark it fixed" and we say "mark it rejected" and they say "ok we'll mark it fixed".

it's a nightmare.

metrics and quotas will only lead to less overall return... unless, of course, you're just trying to create a jobs program.

Re:Metrics suck (1)

jginspace (678908) | more than 2 years ago | (#38393284)

I think the main thing the submitter can take away from that article is that you measure the availability of systems rather than trying to painstakingly log activities among the IT staff. What is considered 'optimal' is not covered in the previous story. You'd be working on something like: Internet access only being down 5 mins per day; email for 10 mins; each workstation only suffering 30 mins per month - or whatever. The most important stats probably won't be in your 'ticket management system' - the good news is that you can generate lots of juicy data automagically - Nagios [] .

Here's a few... (5, Informative)

HerculesMO (693085) | more than 2 years ago | (#38392372)

Time to answer call, time to resolve ticket, abandoned tickets (unresolved).

If you google a few of those it will bring some more, but that's a simple start.

Re:Here's a few... (4, Informative)

suutar (1860506) | more than 2 years ago | (#38392400)

Number of calls back after initial call (measuring, in theory, how often the initial call resolved the issue) Number and duration of system outages (if you're doing sysadmin stuff as well as support stuff)

Re:Here's a few... (1)

h2oliu (38090) | more than 2 years ago | (#38392766)

These are both good. I'd mod up if I could.

call / ticket time is bad metrics (1)

Joe_Dragon (2206452) | more than 2 years ago | (#38392630)

as not all ticket take the same time.

Do want quick password resets to count the same as doing some think that needs a more time? like setup / reload a pc?

Re:call / ticket time is bad metrics (5, Informative)

DarthBart (640519) | more than 2 years ago | (#38393358)

I got written up once because my ticket stats were radically different than the other people on my team. 15% lower "total time on tickets" but 20% more tickets closed. I was apparently fudging numbers and closing unresolved tickets.

Fortunately, a trip to HR with a ream of printouts from closed tickets proved otherwise.

Still left the company a few months later.

Re:Here's a few... (2)

fsckmnky (2505008) | more than 2 years ago | (#38392922)

Don't forget to correlate any metrics collected internally, with your customers experience ratings.

Metrics collected internally without correlation can easily be gamed.

If you data mine the metrics against customer satisfaction, you'll see who is naughty and who is nice.

You get what you reward, not good work (3, Insightful)

perpenso (1613749) | more than 2 years ago | (#38393292)

Time to answer call, time to resolve ticket, abandoned tickets (unresolved).

In business school it is a common theme in various classes that you get what you reward, not what you ask for, not what is necessarily best for the organization. Here is a highly relevant Dilbert cartoon illustrating this point, [] .

The underlying problem is that metrics applied to humans leads to people working towards the metrics, not necessarily doing good work. It is a classic environment for unintended consequences. Its not even that the people are necessarily being opportunistic, there is also a certain amount of practicality. If you are being measured by some metric and keeping your job or getting a raise is dependent upon that metric you may quite rationally decide to act to that metric rather than what is necessarily in the best interest of customers.

Are you measured by resolved tickets? Then tickets will get resolved quickly. Not necessarily thoroughly, completely, or robustly resolved. Which leads to related followup tickets because of a minimal effort put into resolving the original ticket. I saw this in a programming environment where the tickets consisted of new features or bug fixes.

Are you measured by abandoned tickets? Then tickets will get resolved, even if they don't reasonably deserve to be considered resolved. You will get things unnecessarily classified as "unable to duplicate", "insufficient information", etc.

In these two examples, where is the difficulty of the task factored in? Not all task, tickets, are equivalent. Furthermore sometimes there are external dependencies, a part is being shipped, where is this factored in?

The metrics you offer are reminiscent of stats from call centers. There such metrics are a little more reasonable, not perfect but perhaps OK, given that the calls are somewhat equivalent in the amount of effort required, a small number of minutes not hours, and that they are randomly assigned. Over the period of say a month the large number of calls handled by any operator will resemble a normal curve with respect to effort required. For an IT organization the evaluation period may need to be some number of years to get to a normal curve with respect to effort required.

Re:Here's a few... (1)

Anonymous Coward | more than 2 years ago | (#38393448)

Seems to me that a good first metric should be:

1. The 3 of you have a paid vacation of at least one month, without anyone covering your jobs.
2. You come back and see what happened during your absence. If everything is fine, there are two options:

A. You're so great that your preparedness made possible to withstand your absence
B. You're not required.

As second metric, I leave to you how to differentiate between A and B. :)

easy (5, Insightful)

Anonymous Coward | more than 2 years ago | (#38392378)

"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.

Re:easy (4, Funny)

mewsenews (251487) | more than 2 years ago | (#38392422)

Metrics are favoured by lazy management.

Look, using metrics doesn't indicate lazy management.

Look, using metrics that you don't have available doesn't indicate lazy management.

Look, using metrics that you don't have available so you ask your staff to measure their own metrics doesn't indicate lazy management.

Look, using metrics that you don't have available, so you ask your staff to measure their own metrics, but you don't know what metrics they should measure, so they end up asking Slashdot what some good metrics are, doesn't indicate lazy management.

What are those acronyms? (0)

Anonymous Coward | more than 2 years ago | (#38392388)

You could sure start by explaining what "mtrr" and "mtbf" mean!

Re:What are those acronyms? (0, Offtopic)

19thNervousBreakdown (768619) | more than 2 years ago | (#38392420)

memory type range registers and millisecond-timed blowfish fucking

My point exactly! (-1)

Anonymous Coward | more than 2 years ago | (#38392458)

Thanks for confirming my point that these are non-standard. Shame on the author.

Re:My point exactly! (0)

Anonymous Coward | more than 2 years ago | (#38393568)

mean time to resolution
mean time between failure

Check a hard drive manufacturers website and every one will list a mtbf for their drives. That one is a standard.

Re:What are those acronyms? (1)

Anonymous Coward | more than 2 years ago | (#38392710)

MTBF = Mean Time Between Failures
MTRR should be MTTR = Mean Time To Repair

Explanations would've been nice for convenience but frankly if you didn't know those acronyms anyway you probably don't have much to contribute to answering the question.

3 People? (5, Insightful)

stevenfuzz (2510476) | more than 2 years ago | (#38392398)

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.

Re:3 People? (2)

hedwards (940851) | more than 2 years ago | (#38392528)

Doesn't mean they aren't going to try to work with 1 fewer. I remember working an understaffed job a while back and they still managed to figure out how to eliminate an extra position. It didn't work well and stressed out the employees, but they were able to cut the position.

I'm guessing they'll try that here, even if they do have to give up and hire somebody back.

Good luck (1)

U8MyData (1281010) | more than 2 years ago | (#38392406)

I'm afraid if some one is asking for metrics of three people supporting 350 in international terms does not know what the hell they are asking for or what it is that you 3 do. That being said, it can be expected you will be scrutinized over every little detail. Be careful. I won't ask, but I do wonder who you work for. I have been a similar situation and it is completely frustrating. Good luck...

Re:Good luck (4, Interesting)

ScuzzMonkey (208981) | more than 2 years ago | (#38392594)

It's not unusual for management to be clueless about what exactly it is that their IT staff does on a daily basis, nor is it unnatural that they should take an interest. Often, it's a good sign when they actually ask the guys doing the work what the metrics should be... it indicates some degree of trust, and they haven't simply read an "IT Management for Dummies" book over the weekend laying out some arbitrary system that isn't going to fit your organization.

As a more cynical commenter points out, it also provides the opportunity to create a measurement system that you can game to make you look good. But I think it isn't a terrible sign that the bosses care what their employees are up to. It may represent an opportunity to explain what you think is important that perhaps they hadn't considered previously.

Above optimal? (2)

Anonymous Coward | more than 2 years ago | (#38392424)

You're always below optimal, by definition of optimal.

Re:Above optimal? (1, Insightful)

DWMorse (1816016) | more than 2 years ago | (#38392486)

I think you've confused "peak" with "optimal."

Peak = best possible output

Optimal = most satisfactory

You can tune an engine to run within optimal specs. But if you run it at peak nonstop...

optimal? (5, Informative)

Anonymous Coward | more than 2 years ago | (#38392428)

talk about flow, about bottle necks. Visualize workflow. Look at Henrik Kniberg's paper on kanban as applied to IT Ops. My guess is that your ticketing systems will provide low value data on volumes on resolution time - gear up - visualize the pipeline. check - turn the conversation around to "business value" - don't get wrapped in the ropes of volumetrics /peace.

Re:optimal? (3, Informative)

bbutton (90403) | more than 2 years ago | (#38392810)

+1 for this answer. Kanban is a great way to generate actually useful metrics for a team, project, or department. You'll be able to calculate things like how long it takes the average ticket to work its way through your processes, where tickets tend to get stuck (cumulative flow diagram), and where the sources of waste are in your processes.

In addition to the book mentioned above, I also like this one by David Anderson: []

I've led several teams using Kanban as a way to visualize our workflows and measured the cycle times for each work item through our processes. By driving out common causes of variance between work items, its possible to arrive at a consistent cycle time per item. You can then use any process improvement technique you like to show tangible improvements in cycle time.

-- bab

No Metrics (4, Insightful)

Anonymous Coward | more than 2 years ago | (#38392436)

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.

Re:No Metrics (0)

Anonymous Coward | more than 2 years ago | (#38393012)

Or if you're less scrupulous...

Total ticket fixes means I just close tickets early without a proper resolution, force them to open another if the problem still exists (it will).
Total tickets means I just close the ticket early and continue to work on it, or I consolidate tickets into 1 ticket.
Time taken per ticket means I just close tickets early, and move on, "What? The problem isn't fixed? Must be a different issue!"
User rated response means I make sure they know this affects me, and that I will know what they submit, and then try to become friends.

What I love is when management wants to use subjective measures, and wants me to rate myself. I then select the maximum ratings, almost across the board, a few would be less than max, but not much. This then makes it awkward for them to mark me significantly lower, as they'd be slamming it in my face, and calling my a liar. This means my ratings end up being on average higher than everyone else's. Hooray! More money!

99% of the time, if you think you need metrics, you're doing it wrong.

P.S. I know I'm an arsehole.

Ahh, metrics, good. (3, Insightful)

DWMorse (1816016) | more than 2 years ago | (#38392444)

Metrics. Excellent, I hate when bosses use the Imperial system.

All jokes aside: If you care about your job in this economic climate, I suggest you do what your 2 other teammates are doing - picking through the stats that make YOU look the best. The company isn't going to look out for you. IT is an expense to be cut, remember. Boosts the temporary bottom line, promotes "growth" in this fiscal quarter, gets the investors going so the CEO can shuffle another fold into his golden parachute. If non-important metrics are selected that sacrifice your job, it's a brief victory lap straight into the unemployment line.

We can't answer your question, though. In the end, I recommend you watch a clip from "Office Space" - wherein the Bobs interview the employees:

Bob: "So tell me, what is it, exactly, that you do here?"

If you can't answer that question, you probably should be job hunting already. Or should have kept a copy of the job posting from when you applied.

Metrics (1)

mysidia (191772) | more than 2 years ago | (#38392450)

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.

Standard ticketing system metrics are no good. Add a post-incident survey to your customer interactions. Your metrics don't measure performance, unless you can actually measure how 'hard' the ticket is intrinsically / what skill is required, and how well the ticket is solved.

A good solution might prevent further issues, a bad solution might cause more issues to occur. The fewer IT support issues a customer has, the more each resolution was worth, because that indicates their problem was actually solved.

Define a new metric: "Ticket importance" = Importance level given to the issue by the customer relative to the other issues.

Define a new metric: "Customer Happiness" = Score given by the customer with the resolution of the issue, from 0% to 100%.

Define a new metric: Revenue per Ticket = Revenue of applicable IT support Service Delivered per period of time divided by average Number of Trouble tickets for that service for the same period of time.

Define a new metric: Ticket Weight = Rank of the ticket out of all other tickets issued by the service, as a percentage. 100% would indicate it's the only ticket that matters, 0% would indicate solving the ticket is not an accomplishment, e.g. wasted time

Define a new metric: Ticket worth = Ticket Weight * Revenue per Ticket

Define a new metric: Ticket resolution value = Ticket Worth * Customer Happiness.

Sum the resolution value of all the tickets solved by IT support personnel. When multiple IT persons are involved in the same ticket, calculate total hours spent on the ticket, and divvy out the 'Resolution points' based on the amount of time spent on that ticket by each team member.

so if i build an incredibly shitty IT system (1)

decora (1710862) | more than 2 years ago | (#38392726)

where people are constantly calling me asking to fix stuff, then my numbers will be awesome!

god, capitalism is awesome.

Re:so if i build an incredibly shitty IT system (1)

mysidia (191772) | more than 2 years ago | (#38393280)

where people are constantly calling me asking to fix stuff, then my numbers will be awesome!

I think you missed the part where total IT service revenue for that application is divided by the number of tickets. The more tickets for a specific IT service, the less the issue resolution is worth.

The fewer total tickets for that service, the more each resolution is worth.

For a team of 3 people? (2, Insightful)

Anonymous Coward | more than 2 years ago | (#38392460)

Is shit broken?
Does shit get fixed fairly quickly?
Are your people busy, but not swamped?

A good measurement.... (1)

Anonymous Coward | more than 2 years ago | (#38392500)

..... is how much failure they have!
If shit is working, don't come bitching! Don't ask about shit you don't know shit about and do your job like you are doing yours!

Easy, start by choosing what you need to change (2)

colonel (4464) | more than 2 years ago | (#38392552)

- Percentage of staff with ITILv3 foundations certification: zero.

I know this because of your question. Watch thes videos as a start: [] -- and sell a formal training course to your management.

The people joking about how one of you is getting fired, or you're all getting outsourced. . . probably true. Learning ITIL is all about learning what's important to your business stakeholders, how to monitor/measure these things, and how to make sure you're always making the right decisions based on the business priorities.

  If you can't convince them to pony up for you three to take the certification course, then pay for it out of your own pocket, you'll need it to find a new job.

Look for a new job (2)

multiben (1916126) | more than 2 years ago | (#38392556)

Seriously. Once management fall under the belief that they can have reports automagically generated for them by measuring your working habits, you will never hear the end of it. Why does X have less keystrokes per hour than Y? You only committed 15 lines of code yesterday. You must not be working. Why did this junior employee fix 100 bugs, when this senior only fixed 10? And take a look at yesterday's topic too.

Exactly. (1)

Weaselmancer (533834) | more than 2 years ago | (#38393080)

I found this gem in the other metrics thread the other day.

-2000 lines of code. []

Make up your own! (0)

Anonymous Coward | more than 2 years ago | (#38392564)

1. Create your own database, with a numeric field per employee, plus a comment field.
2. Each time that employee does something stupid, enter a record with "-1" (or whatever value is appropriate) in their field. Enter a comment if you want.
3. Each time that employee does something good, enter a record with a "+1", etc.
4. This is better than just completely making up crap, since you have a record, and you can justify stuff if needed.

After all, what's a bunch of meaningless statistics compared to what you really think? All you need is a way to keep track of the latter.

!@#$ (rant follows) (0)

Anonymous Coward | more than 2 years ago | (#38392582)

And while you're all gathering metrics the real work isn't getting done. That'll help you look good. With an A-hole boss like that, you'd be better off floating your resume. Also, what definition of "optimal" are we talking about?

I work in a support center (0)

Anonymous Coward | more than 2 years ago | (#38392606)

I've been an ISP call center supervisor and dealt with implementing goals and metrics, have worked in small IT depts, and currently working as a support engineer for business support.

Your metrics are threefold:

1) Phone metrics - this is how long people are on hold, average call length, abandon rate. Call length throw out the window. If you don't have a queuing system ignore phone metrics entirely
2) Ticket system metrics - the only important automated metric is how fast you responded to incoming e-mails. Once a month the manager should randomly select some cases are review them with a scoring system you develop. This helps determine if you are helping customers properly or spend a lot of time ignoring them, etc.
NOTE: It is useful to have ticket volume and average time per ticket from a perspective of sorting our if you need more staff based on volume, but it is not an individual metric.
3) Satisfaction surveys. These are the only one that are valid for individuals. They should be sent out after a ticket is closed, not months later, and cover a variety of topics. Low scoring surveys need to be investigated and if needed thrown out (as often a user being told "no, it is against our policy" will give all low scores when in reality the tech did their job perfectly)

In a 3 person IT dept you should know if the number of active tickets in increasing, decreasing, or holding steady. If it is increasing, you need more people. Holding steady you may be ok on personnel, but you may need more depending on responsibilities and how many hours you are working. Decreasing is good. It does not mean you should get rid of personnel though.

Hide decreasing numbers from management. Insist different issues be different tickets and that "quick 30 second question" gets recorded. One of the reasons that metrics in a small center suck is that most of you are probably doing 2-3 small unrecorded tasks for each recorded one. Management does not see this. All they see is the ticket system.

As for what is industry average numbers. There is no such thing. Each business is different and unique. You have to use historical information about ticket/case volume, active load levels, and phone call volume to generate your businesses numbers.

You can use Numara Track IT (-1)

Anonymous Coward | more than 2 years ago | (#38392612)

Use track it for tracking ticket, inventory and software. []

Add something (3, Informative)

BenEnglishAtHome (449670) | more than 2 years ago | (#38392632)

Your ticketing system needs or needs to have added an automatic followup to the customers. The system sends out an email after every ticket asking "Did the problem get resolved in a reasonable amount of time? Did the IT staff respond in a way that enabled you to get back to work?" Nothing more complex than that, though you can parse things out by ticket priority (though deciding what's a higher priority than other things is, just by itself, a major undertaking).

Your goal should be to increase the percentage of positive responses.

Why this touchy-feely stuff instead of a hard metric? Easy. There are no metrics that work in your situation. It's quite easy to argue that there are no metrics that work, period.

By adding this email feedback to your ticketing system, you have met the requirement to come up with a metric derived from the ticketing system.

Selling this to management can be simple, depending on how you handle it. Something along the lines of "Given that the IT staff is so idiotically understaffed, we must be given the agility to solve problems instead of meeting random metrics. Only our customers can know if we met their needs, considering all pertinent factors. Someday, when we actually have enough people and money to divide work more rigidly, we can add metrics like timeliness of ticket closure, etc." Then you hope they never notice that you never divvy up the work rigidly. All of this requires having an IT manager who is dedicated to the inescapable truth - that their function is to keep the MBAs off your ass and let you do your job.

I've worked where my performance was measured in this way. It can be heaven.

One more thing - if your upper management doesn't already have faith in you, they'll never go for it. They need to already appreciate your contribution to go along with this. The very fact that they're asking for metrics tends to suggest they don't sufficiently appreciate you now. If that's the case, than all I can say is that I've worked under those circumstances, too, and my heart goes out to you.

Doomed from the start (3, Insightful)

lucm (889690) | more than 2 years ago | (#38392644)

> determining if we are performing above or below what is considered optimal

Scenario 1: you are below optimal -> you are inefficient so they replace you
Scenario 2: you are above optimal -> you are overkill so they replace you

Bottom line, I would rent The Wire and learn how to "juke the stats" because that's the only way you won't get to jump on that grenade.

Been there, done that - my advice: be just under optimal so you have room to grow and show improvement, but don't be too low so they don't feel the need to consider a business case for outsourcing.

Superoptimal?? (1)

Jimbob The Mighty (1282418) | more than 2 years ago | (#38392646)

Optimal being 'Best possible', how does one perform above what is optimal? You are either perfect (optimal) or not perfect (sub-optimal).

Re:Superoptimal?? (0)

Warwick Allison (209388) | more than 2 years ago | (#38393230)

Well, for example, working 18 hours days is above optimal. Is this so hard for younger retards than me to work out?

figure out your goals first (1)

ronpaulisanidiot (2529418) | more than 2 years ago | (#38392656)

you can set the goals of your stats ahead of time if you're clever. make it your goal to find many long-term problems, to ensure that your tiny department won't be axed too soon. otherwise if you show a great record of solving problems quickly, you will be rewarded by being downsized.


Anonymous Coward | more than 2 years ago | (#38393010)

there is wisdom in that statement...

ask (1)

mikem170 (698970) | more than 2 years ago | (#38392686)

I'd try to find out what they really want. Are they concerned about head count? Customer satisfaction? Having a good answer to justify their budget?

Customer Satisfaction? (2)

Above (100351) | more than 2 years ago | (#38392690)

I'm not with most IT management on this one, but I always thought the best metric was customer satisfaction. For instance every time I open a ticket with Cisco I get a survey at the end of like 5 questions. Was my problem resolved, was the person polite, etc.

The other metrics suggested are things to graph and look at trends. Are repair times getting worse or better? Is the average time per ticket going up or down? They are great int he aggregate. They break down quickly when divided. Only one guy on your team knows network devices, so he gets all the network devices which include the 8 hour fiber cuts, so his times always are worse than the guys fixing printer problems, as an example. You have to be very careful as you start to divide them up.

At the end of the day though you're trying to make the customer happy. Track it, and see how your staff is doing. If people are happy with their IT support, your department will be seen in a more positive light.

how to survive in the corporate environment (5, Insightful)

decora (1710862) | more than 2 years ago | (#38392692)

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.

Customer Satisfaction (2)

jwkane (180726) | more than 2 years ago | (#38392764)

The only truly meaningful metric is customer satisfaction. After each ticket is closed send a survey email to the user. If your team plows through enough tickets you get a statistically significant success % per tech that you can compare to the other techs.

Without knowing a lot more about the nature of tickets it is hard to give a better response. It might be very important to gauge the difficulty (trivial-hard) and novelty (common-rare) of tickets but it could also be a waste of time. Does one tech plow through dozens of tickets a day or a few? Are the techs specialized? Anything email related goes to joe, hardware issues to tom, etc.. Are the tickets auto-generated from emails, called in or do they fill out a web form?

Given the size of the team the company thinks 1) you aren't getting the job done, 2) one or more people on the team are dead weight or 3) you are overworked and need more people. I wouldn't bet on #3.

Re:Customer Satisfaction (1)

CockMonster (886033) | more than 2 years ago | (#38393392)

Umm, i must say that after dealing with our IT dept the last thing I want to do is fill out a survey for them

Metrics - A lazy manager's out every time. (3, Insightful)

LazLong (757) | more than 2 years ago | (#38392770)

Falling back to metrics is a lazy manager's way of proving to her superiors that her drones are operating at peak efficiency. The most lazy of all will rely on utterly meaningless metrics such as the number of help tickets closed per day, per individual per day, etc. A metric such as this is completely useless as all tickets don't require an equal amount of effort to complete. Diagnosing a problem due to an intermittent hardware issue doesn't take the same amount of effort as helping a user change their password. Unfortunately these types of issues generally comprise the vast majority of tickets generated and therefore often end up being the ones that are 'measured. ' This often leads to a drop in morale and thereby negatively impacts performance; ironically the opposite of what the whole exercise is attempting to accomplish.

Trouble ticket data is primarily useful for detecting trends, thereby helping an IT team appropriately focus their human capital on issues that will enable their users to be more efficient. Going back to the password issue above, the speed and alacrity with which the IT staff help users change their passwords isn't a useful metric at all. A more meaningful metric would be the frequency of password change requests before and after the installation of a self-service password reset solution that was put in place in response to the analysis of help ticket data that showed that this was one of the most frequent issues and one that could be easily solved with little effort and financial expenditure. Measuring a sharp drop in password reset requests would show that the solution worked and was therefore beneficial to the organization by enabling users to help themselves, resulting in their having more time to concentrate on their primary tasks, and also by allowing IT staff to allocate their resources on issues that are less amenable to resolution via automation.

Unfortunately, in my experience, ticket systems get used to determine useless metrics such as the first example mentioned above, and therefore end up being the bane of IT staff, rather than a useful analytical tool.

Hmm (1)

lightknight (213164) | more than 2 years ago | (#38392830)

While not a standard metric, consider the amount of time you spend planning and implementing upgrades to your infrastructure, as opposed to the amount of time spent supporting it. In a healthy company, the weight is towards planning and implementing upgrades to your infrastructure, where not a day passes that a new piece of equipment isn't being delivered. Why, you ask? Because it shows that there are enough people to handle the daily problems adequately, freeing up others to plan for several months (or years) into the deliver a feature before it is requested, to move the network to a faster speed before you hit bottlenecks, to ensure that people spend more time completing their work on their machines than waiting for their machine to finish a task or complete an upload / download. To take time consuming, menial tasks away from the workers, and free them up to pursue tasks that might bring in more money for the company.

In an unhealthy company, you spend more of your time dreaming about upgrades. You end up taking care of old, inefficient equipment, and are stuck in meetings, trying to explain why a minor upgrade can have a large impact to a group of people who are 'too busy' to learn anything more technical than messaging on their Blackberrys / iPhones, which they do while you speak. You don't have enough people to perform adequate daily support, and plan for future upgrades (which may require several hours of research, and speaking with vendors on the phone, to get a proper quote; on top of studying new technology or attending a training course). If you've hit a bottleneck in the last several months for any feature on a computer / network, and you're not Google / IBM / someone playing with a supercomputer, you're doing it wrong.

But then, you get what you pay for. If you are a company like this, leave. The company isn't going to grow, the culture is dead, and you have a chance to short the stock before the collapse. They'll keep switching CEOs / figureheads, and merging, but that kind of corporate culture is like a virus. See what happened to HP when Compaq merged with them.


Metrics Suck (except one) (1)

thatkid_2002 (1529917) | more than 2 years ago | (#38392980)

Customer/User satisfaction. If problems are solved in a reasonable way (in terms of time considering your workload, budget and expertise) then that's the only thing management should care about. You're not running a support call center where your job is to read solutions from pre-written scripts - you're solving real problems with real people. There is no script.

Management should be surveying their employees and your reports and work out if more people are needed to do general support. Are you finding time to do project work? If no, then maybe they need to hire somebody to keep users off your back a few hours a day while you do projects.

Re:Metrics Suck (except one) (1)

supremebob (574732) | more than 2 years ago | (#38393324)

Nope, that doesn't work either. By rating tech support people on user satisfaction, you're basically asking them to beg/bribe/coerce their users into giving them a high satisfaction rating in order to save their jobs.

The best example of this would be my local Audi dealer...Audi only gives bonuses to staff that gets a 5 out of 5 customer rating, so they practically beg their customers to either give them a perfect rating or to not to bother rating them at all. How are you supposed to give a honest review after hearing that, knowing that you're basically screwing the person out of their bonus if you give them a "4" rating for ANY aspect of your visit?

You would think that the talented technicians would get the higher support ratings, but in reality the technicians who are the best at schmoozing their users will get them.

umm... (0)

Anonymous Coward | more than 2 years ago | (#38393024)

is it possible to perform "above optimal" ?!?

Turnaround time (1)

pablodiazgutierrez (756813) | more than 2 years ago | (#38393054)

If you have to go down that path, I'd go with TAT. Simple to measure even over old data, hard to game consistently, and closely related to customer impact. If you want to, weigh it by customer-perceived severity of each request so that people don't boost their numbers by cherry picking easy tickets.

What really matters (1)

dark grep (766587) | more than 2 years ago | (#38393122)

There is only one metric that really matters, and that is what your users think. You can collect all the stats you want, and put whatever spin you like on the figures, but if your users think you suck, then in the view of 99% of the company, you suck.

So my suggestion is; do what Cisco and other customer focused companies do, and for every ticket closed, send a satisfaction survey to the user. Don't make it long, it only has to be 4-7 questions where they rate the key things you did on a scale of 1-5, and should take the user less than 2 minutes to complete.

Then, you will have incredibly meaningful stats to show the good work you are doing. Or, you will have the precise information that shows what you need to do to get recognized for doing good work.

Just think about it., what is better:

a. For the last month there were 82.5% if tickets were resolved within the department KPI target,


b. For the last month 82.5% of staff indicated they were happy or very happy with IT support

Tickets don't matter, users opinion do (1)

dirk (87083) | more than 2 years ago | (#38393134)

The best answer is to not use tickets as your metric. I worked at a smaller company and our metric was a simple yearly user survey. We would ask what they thought of their equipment, the how the support team did (response time, niceness, knowledge, etc) and even took it so far as to ask for suggestions on what could be improved. In the end, how many tickets you close really doesn't matter. What matters is how happy your users are. If you are doing the job correctly, the majority of your users will at least be satisfied, if not happy. If the majority are unhappy, this will give you specific ideas on areas you can improve on.

Not enough info (1)

koan (80826) | more than 2 years ago | (#38393138)

1: You didn't give enough information on what you support to get an accurate answer.
2: You shouldn't be the one evaluating your own own job (see very first post)
3: Here are several common metrics which may or may not apply to your situation as they were pulled from a couple of very large corporations metrics system.
CSAT: customer satisfaction based on automatically emailed surveys
AHT: average handle time, or the time you spent on the phone resolving the issue
ACW: average call waiting or how long did they have to be on hold to talk to you
Call Resolution: self explanatory
Logging: how much did you actually log in tickets to the number of calls received.

It gets pretty granular after this with things like "overall satisfaction" "agent expertise" (you're the agent) "agent listening"

One last thing, I actually snorted reading the first post because I had an "Office Space" flash back, time to hide your red Swingline.

Metrics which truly gauge performance. (1)

pgward (2086802) | more than 2 years ago | (#38393206)

Some metrics have been shown to be clear indicators of good performance in IT teams. Hopefully the following equations are clear enough. 1./ Number of metrics minus number of metrics known by employees 2./ Time in day minus time spent on developing metrics 3./ Number of metrics forgotten divided by Number of managers who care about metrics

Amateurs (1)

jotaeleemeese (303437) | more than 2 years ago | (#38393360)

I can only imagine that most people replying with derision about metrics have never been in the position of having to justify what they are doing, and when they have been they have acted dishonestly.

People that actually work in the real world, with real companies with real budgets, and that have some self respect, honesty and pride in what they do will have to justify their salaries or rates somehow, and one of the tools used is some kind of metrics.

A professional will find metrics that are meaningful to both their team and their bosses or paymasters, and contrary to what most people are implying here, they can be quite useful to identify reasons for which a team is overworked and maybe bring somebody else on board.

It should also be pointed out that proper metrics may point to a team that is overstaffed, but an honest professional should not fear this since drawing a salary for doing nothing is frankly not my idea of a honest day's work (those people asking to make up or game the metrics simply are unethical, if you think metrics are a sham then do please suggest how you intend to evaluate obejectively if you are becoming better or worst at doing your job).

Try personal experience (0)

Anonymous Coward | more than 2 years ago | (#38393414)

Yes, good metrics are useful. But you only have three employees. Don't you, I dunno, know them? It isnt hard to figure out who sucks and who doesnt when you only have two other people you work with.

Nagios + Redmine (1)

rwa2 (4391) | more than 2 years ago | (#38393424)

Nagios [] isn't too difficult to set up to monitor lots of things, and lots of useful uptime metrics for every service, planned and unplanned maintenance, etc. fall out quite naturally from it. And you can kinda just keep adding modules to it into it and grow it until it's full of awesome.

I haven't personally used Redmine [] yet, but have been using Trac and everyone seems to agree that Redmine is the clear successor in terms of lightweight but capable trouble-ticket / project / task management systems.

Convert the metrics to money (0)

Anonymous Coward | more than 2 years ago | (#38393438)

As a previous commenter suggested, you should use metrics that will increase the performance of the IT department. Remember, you get what you measure.

So, what you should do is this:

Use the number of tickets prevented as a metric.
Then, in the report for your boss, calculate the average amount of time that each ticket takes, and multiply that by the average hourly wage.
Then for one of the metrics you can use the amount of money each employee has saved the company.

Assuming the figures look good, and they probably will (after all, thats the power of statistics, you can make them seem to support any course of action) your boss will probably be quite impressed by the performance of EVERYONE in your department, and suddenly you all would seem more essential.

Metrics are Good (0)

Anonymous Coward | more than 2 years ago | (#38393474)

Sorry, but I'm biased. I love metrics. I hate how some people misuse metrics, but when used properly they are awesome tools.

Anyhow, you want to measure the number of calls, average time on a call, average call waiting, calls transferred, calls abandoned, service desk availability, call severity, and categorization of call. With a small shop, you need to look at what else you do outside of support calls.

Ideally, you'd use the statistics to find trends. Like say, you find a particular printer brand breaks more often than others. So you can switch manufacturers. I have never turned to statistics to fire someone. Instead I review this information to see how we can improve.

Another important factor is user satisfaction. I send out bi-annual questionnaires to our users, since perception counts more than about anything else. For help-desk, the users are the customers. So I view customer satisfaction as extremely important and tie these reviews to bonuses (not call statistics).

Finally, I would suggest you have each member rate each other and themselves.

Chances are, you don't have the metrics in place for it to accurately measure what you really need. So, I'd start with surveys of your users.

One final note, 1 IT person per 100 users is a good ratio. Anything less and you will experience downtime (or experience a high amount of outsourcing). Make sure they see what financial detriment losing a person would yield. Find out if they are looking to cut costs and if that's the case, look for ways to do that. Whether it's your cell phone bill, network bill, amount outsourced, hardware leases, etc.

Easy Metric! (0)

Anonymous Coward | more than 2 years ago | (#38393570)

Determine the cost of hiring an outside consultant ($100/hr to $250/hour, depending on country and regions within that country), then show how much less you cost the company! Then again, as an outside consultant, I do the same amount of work in 4 hours that a regular employee does in 8 ;-)

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?