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!

Ideal, and Actual, IT Performance Metrics?

timothy posted more than 5 years ago | from the spin-the-dial-shake-the-8-ball dept.

Businesses 321

An anonymous reader writes "Recently it was revealed that our company measures IT performance by the time it takes to close trouble tickets. I consider IT's primary goal to be as transparent to the user as possible, thus this metric was rather troubling to me. Shouldn't we be focused on reducing calls, rather than simply closing them quickly? My question is: How is your IT performance measured, and how do you think it should be measured?"

cancel ×


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

When testing a new blade server install... (4, Funny)

RyuuzakiTetsuya (195424) | more than 5 years ago | (#28349631)

We usually try to measure how many libraries of congress we can get to the new blade server in under 5 minutes.

our best is 12.

Re:When testing a new blade server install... (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#28349793)

Linux just isn't ready for the blade server yet. It may be ready for the web servers that you nerds use to distribute your TRON fanzines and personal Dungeons and Dragons web-sights across the world wide web, but the average computer user isn't going to spend months learning how to use a CLI and then hours compiling packages so that they can get a workable graphic interface to check the status of their blade servers with, especially not when they already have a Windows 2008 server that does its job perfectly well and is backed by a major corporation, as opposed to Linux which is only supported by a few unemployed nerds living in their mother's basement somewhere. The last thing I want is a level 5 dwarf (haha) providing me my OS.

Re:When testing a new blade server install... (-1, Redundant)

RyuuzakiTetsuya (195424) | more than 5 years ago | (#28349885)


Re:When testing a new blade server install... (3, Informative)

MyLongNickName (822545) | more than 5 years ago | (#28349945)

The whoosh belongs to you. GP is a troll. Cut and paste troll slightly modified to appear on topic. You bit.

Re:When testing a new blade server install... (3, Informative)

cbiltcliffe (186293) | more than 5 years ago | (#28350367)

Just need to upgrade your network and disk I/O. I get 14, easy. :-)

Seriously, though...I think the submitter is right. You should be trying to reduce the total number of tickets, but then you've got to be wary of trying to improve your performance score by saying "That's too small an issue to be opening a ticket for. I'll just ignore it/fix it on my lunch break/tell the user to bugger off."

I don't think any single metric is useful. Probably something like:

average # of tickets open X 2 +
average hours from open to close X 5 +
# of security breaches in past year X 100 +
# of times with no open tickets in past week X 1 =

your IT performance score. Obviously, lower is better. Change the weightings to your preference, and if you'd rather a higher number be better, divide 10 by your result.

Surely somebody's got some formula like this already. I wouldn't be surprised if there's some obscure standard somewhere that nobody uses because it'll make management look bad......

No cnt++ (4, Funny)

korbin_dallas (783372) | more than 5 years ago | (#28349637)

I thought IT got paid for the number of times they said 'No' to us during the day.

go figure.

Re:No cnt++ (3, Insightful)

rednip (186217) | more than 5 years ago | (#28350089)

I thought IT got paid for the number of times they said 'No' to us during the day.

Here's a trick, if you want them to start saying 'yes' give them more of a budget, as most 'no's comes from a lack of money.

Re:No cnt++ (4, Informative)

elrous0 (869638) | more than 5 years ago | (#28350535)

It's been my experience that most "no's" come from bad or lazy employees. Most good ones will at least explain themselves and TRY to help (even if they're underfunded).

Re:No cnt++ (4, Insightful)

Aladrin (926209) | more than 5 years ago | (#28350589)

Only for so long. Eventually you burn them out and they just decide not to bother doing extra if they company can't be bothered to fund things.

Re:No cnt++ (1)

bigpat (158134) | more than 5 years ago | (#28350543)

Here's a trick, if you want them to start saying 'yes' give them more of a budget, as most 'no's comes from a lack of money.

Or if you just want them to stop saying no, then given them no budget at all. No people, no problem.

Exactly! (5, Insightful)

Archangel Michael (180766) | more than 5 years ago | (#28350599)

I don't say "no" any longer. I ask them what their budget is for accomplishing the task they want.

me: "How much do you have budgeted for this project"

them: "Budget? You mean it costs money? I thought you could do this for free"

me: "We can't do that for free" (laughing to myself the whole time) .... later they come back ...

them: "We have $400 for the project"

me: "Does that include the licensing? Does that include ongoing support? Does that include setup, training, and installation of new infrastructure needed to support your project?"

them: "Uh, no. What do you mean?"

me: "Well, when you want a project ... say for a new building, do you just present $400 and say can you build the building for that?"

them: "Well, no, we have professional architects design the building, then we have professional contractors bid on the project, then we included additional maintenance in the budget for the new building and .... "

me: "So, what you are saying is that you don't view IT as being professional"

them: "No no no no! That's not what I mean at all."

me: "So, how come you just expected us to do what you wanted without asking us what it would take to do it?"

them: "Because it is too expensive when I do ask that"

me: "It is more expensive to do things right. If you want to do it wrong, any non-professional can quote you a lower price. You can get a building and have it built a lot less expensive if you don't hire Architects and Contractors to design and build a building, and it will get built, but it will be missing things you probably want and need. But you know this, and that is why you trust those professionals."

them: "yes, but you are too expensive"

me: "Then the answer is no"


Sometimes it is just easier to say "NO". The sad fact is, people don't respect IT professionals AS professionals. We often don't deserve it either, but that is another topic.

Re:No cnt++ (1)

Steauengeglase (512315) | more than 5 years ago | (#28350175)

Sadly a bell curve is used. If we could just say, "No" to everything we could get a few things accomplished. QA will have none of that.

Submitter is an insensitive clod (0)

Anonymous Coward | more than 5 years ago | (#28350237)


I'm a USian, and use Imperials, you insensitive clod!

obvious (2, Funny)

spikedvodka (188722) | more than 5 years ago | (#28349651)

Customer Satisfaction, and pro-active problem solving

Re:obvious (4, Insightful)

fictionpuss (1136565) | more than 5 years ago | (#28350167)

But how do you measure the success rate of a problem you solved proactively, thus ensuring it never becomes a measurable problem?

The New Tax Credits system in the UK used the same call-time metric - likely still does - it was able to get most calls averaging the artificial target of three minutes. Never mind that if you looked at the call logs you could see most callers indeed spent around 3 minutes on the phone, but never got their problem solved. The unlucky representative who got that caller when they were fuming mad, and determined not to hang up until the problem was solved, would get placed lower in internal league tables.

So it came down to politics - the terrible metrics allows us the ability to satisfy tribal instincts by ranking participants. That was the real motivation. Call centers around the country ended up competing with each other on this metric too, and the directors of the most useless call centers were the ones who got promoted to run the whole show.

But this problem is beyond NTC or IT.. it's the defining issue of this backward planet.

Re:obvious (1)

CarpetShark (865376) | more than 5 years ago | (#28350401)

Customer Satisfaction

I'm not even sure that concept exists in the minds of IT service users. Certainly not in the minds of those service users who are afraid of technology, don't understand it, and blame the admins when they press delete and something gets deleted.

pro-active problem solving

In some areas of IT, "pro-active" equates to breaking things that aren't broken.

Re:obvious (1)

cbiltcliffe (186293) | more than 5 years ago | (#28350449)

Both of these are very nebulous, and virtually impossible to truly measure.

Is your customer satisfied because you did a good job? Or because the last company they had to deal with was their communications provider who basically said "You don't owe that money? Well, we say you do. Pay up."

Have you not had any serious problems because IT is proactive at preventing them? Or just because your setup negates most of the big problems that hit the news recently?

I frequently find that the idiot IT guy who gets people back up and running after a major worm infection, enabled by said IT guy's lack of security patching, gets much higher kudos than the one that did all the preventive maintenance beforehand, and didn't get their users infected in the first place.

I think it should be measured... (5, Funny)

IntricateEnigma (148093) | more than 5 years ago | (#28349659) the number of callers left alive at the end of the day.

I concur ! (1) (410908) | more than 5 years ago | (#28350221)

In the IT company I work for, we mesure it but the number of irate salespeersons that survived inside a SL8500 with tape cleaning engaged.

count tickets never openend (5, Insightful)

molecular (311632) | more than 5 years ago | (#28349669)

I think poster has a point.
A nice metric might be the count of tickets that are never opened.
An IT-department, IMHO, should be working on making itself obsolete.

Re:count tickets never openend (3, Insightful)

Darkness404 (1287218) | more than 5 years ago | (#28349837)

But you will always, always have stupid users. Users who think something is broken when it isn't, users who will call for the stupidest reasons (such as calling because a dialog box came up), users who will complain about updates and upgrades (such as even though my keyboard's "M" key didn't work, I could type faster on it, but this new keyboard I can barely use it), and users who are generally computer illiterate (such as asking where to find a certain program whenever you have already told them 1000 times). Sure, the logical conclusion would be to fire them, but all too often it is the managers or the higher-ups who have these problems.

Re:count tickets never openend (1)

daem0n1x (748565) | more than 5 years ago | (#28349999)

Having worked for some time in an IT department years ago, the worst user I had was a dude from marketing that offered himself to "fix" the users' problems before they called us. Of course, they eventually called us, but what started as a simple problem had already become a major hassle.

It was fun to do for some time, but it's not for me.

Sounds good to me. (5, Interesting)

khasim (1285) | more than 5 years ago | (#28349843)

For example, for every fax successfully sent via the fax server without IT intervention, the IT department gets one point.

For every fax that needs IT intervention to be sent, the IT department loses one point.

For every person who becomes aware of a problem with the fax server, the IT department loses one point. No more "heroics". The goal is to be as invisible as possible to the end users.

And similar items for every other server/service that IT supports. If nothing else, it will show exactly where the problems really are.

Re:Sounds good to me. (1)

Darkness404 (1287218) | more than 5 years ago | (#28349981)

And similar items for every other server/service that IT supports. If nothing else, it will show exactly where the problems really are.

...With the users. More often than not it isn't the IT department's fault that something goes wrong but rather a user breaks it.

Re:Sounds good to me. (4, Insightful)

rjstanford (69735) | more than 5 years ago | (#28350119)

Actually, that's good - a proactive IT department would work on fixing issues that many users have difficulty with, even if that means replacing the copier contract with one that delivers a more user-friendly machine that has slightly worse "paper specs". As a random not-very-technical example.

Re:Sounds good to me. (1)

hedwards (940851) | more than 5 years ago | (#28350185)

And just out of curiosity, where does this portion of the budget come from? I'm not saying that I disagree, but IT staff isn't slave labor, chances are they'd be doing that if they were provided with adequate budget to do so.

The proactive stuff tends to be the least funded and hardest to get funding for because the owners aren't being smacked in the face with it all the time. It also tends to not be as obviously time sensitive as most of the rest of the work, like making things run quickly.

And that is what you want to be able to show. (1)

khasim (1285) | more than 5 years ago | (#28350229)

...With the users. More often than not it isn't the IT department's fault that something goes wrong but rather a user breaks it.

So your IT department ends up with servers/services that are designed correctly (by the vendor) are when a user does something stupid ONLY THAT USER IS AFFECTED.

Other servers/services are "designed" by idiots and any user can cause problems for every other user just by doing something stupid.

So the monthly meeting shows that you have
+2,000 points (-0) for service A
+1,500 points (-0) for service B
+1,000 points (-200) for service C
+300 point (-800) points for service D

Without knowing anything else about those systems, where would you probably start looking for improvements to be made?

Re:And that is what you want to be able to show. (1)

Darkness404 (1287218) | more than 5 years ago | (#28350375)

...But the IT people already know what is broken and what needs to be fixed. The problem is, upgrading the servers, replacing equipment, changing vendors all cost money something that most businesses don't have a ton of today and aren't going to give it to the IT people. Even if you show them that, they will say "well, it isn't broken all the time..." or something like that. The management's job is to save money, not to spend it. If it isn't broken you are going to have a hard time convincing them that it is worth it. They don't care about productivity because that isn't usually "measured" in the way that cost savings is.

Re:Sounds good to me. (4, Insightful)

molecular (311632) | more than 5 years ago | (#28350107)

For example, for every fax successfully sent via the fax server without IT intervention, the IT department gets one point.

For every fax that needs IT intervention to be sent, the IT department loses one point.

I like this idea, because it has the side-effect of forcing managment to define in writing and exactly the services the IT-department / infrastructure is actually supposed to provide and also forces them to define some metrics and mechanism to measure this. This enables the IT-department to respond to inappropriate requests in a nicely formal way. Also the managment can prioritize on this to help IT fend off the odd jerk that thinks their particular problem is the most important in the world and should be taken care of ASAP. Such a system would also provide transparency to managment and users as to wtf these IT-jerks are doing all day and why.

Re:Sounds good to me. (1)

Freetardo Jones (1574733) | more than 5 years ago | (#28350249)

For every fax that needs IT intervention to be sent, the IT department loses one point.

What if the intervention was needed due to no fault of anyone in the IT department? Why should they be penalized cause some asshat was incorrectly using a piece of equipment?

Re:Sounds good to me. (3, Insightful)

The Moof (859402) | more than 5 years ago | (#28350345)

Every time accounting asks "Why are we paying these guys, they don't seem to do anything," you get 5 points.

Re:Sounds good to me. (2, Informative)

haruchai (17472) | more than 5 years ago | (#28350403)

Sad to say but the more invisible the IT department is, the harder it is for them to get funding for new projects.

Re:count tickets never openend (3, Funny)

starglider29a (719559) | more than 5 years ago | (#28349859)

True! And my measure of being a good husband is how many affairs I DIDN'T have!

A) How do you count that? B) Dude, even SKYNET had an IT department.

"Yeah, uh, hi... my directive is to nuke Redmond/PaloAlto (pick one), but... heh heh... I can't find the launch codes... could you reset my... oh, wait. Here they are. The sticky note fell off my monitor."

Re:count tickets never openend (1)

molecular (311632) | more than 5 years ago | (#28350189)

True! And my measure of being a good husband is how many affairs I DIDN'T have!

A) How do you count that?
B) Dude, even SKYNET had an IT department.

A) I don't know how to count that, but the original poster asked for both actual _and_ ideal metrics

B) Following goals even when it is known that they can't be reached can still make sense and lead you the right way.

Re:count tickets never openend (0, Redundant)

molecular (311632) | more than 5 years ago | (#28350311)

True! And my measure of being a good husband is how many affairs I DIDN'T have!

A) How do you count that?
B) Dude, even SKYNET had an IT department.

A) Dont know how to count that, but initial poster asked for both actual _and_ ideal metrics

B) Following a goal even when it's unreachable can still be fruitfull by leading you in the right direction.

Re:count tickets never openend (1)

Freetardo Jones (1574733) | more than 5 years ago | (#28350477)

An IT-department, IMHO, should be working on making itself obsolete.

So in the absence of the IT department, are the software/hardware updates, amongst everything else they maintain, going to be just done by magic?

First metric... (0)

Anonymous Coward | more than 5 years ago | (#28349677)

...timeliness of the TSP reports

Re:First metric... (0)

Anonymous Coward | more than 5 years ago | (#28349849)

I think you meant TPS reports.

Re:First metric... (0)

Anonymous Coward | more than 5 years ago | (#28350553)

...timeliness of the TSP reports

good job at failing

Sliding Average (1)

PeteLarson (1557871) | more than 5 years ago | (#28349693)

I think the focus should ultimately be on reducing calls. So, perhaps, you're doing really well if the average calls per week continues a downward trend each week.

However, since many IT departments are actually split into different subdivisions, how can you measure the group that just takes calls, addresses issues, and closes tickets. It may be their ONLY job to close tickets/issues. They may have exceedingly little control over any underlying problems. So, to measure their performance, perhaps number of issues closed is not entirely wrong. But, managers of this group should be evaluated over time. Any recurring issues should be brought up as potential bugs or user training or just needing general improvement to the system, whatever that might mean.

Re:Sliding Average (4, Interesting)

Lumpy (12016) | more than 5 years ago | (#28350043)

Problem is most PHB's CANT understand that.

They think that solving it faster = better. and if the number of calls goes down, you are doing something wrong.

we were unable to fight it at comcast as the idiot CTO demanded it. so I instructed my guys to put in a ticket for EVERYTHING and if it was a instant fix, open the ticket and close it in 1 minute.

Before I left my department got an award as our ticket accounting was 4X higher than the rest of the division and we had the lowest time to resolution. Problem is that Remedy sucks so it actually slowed down my guys having to enter all those useless tickets.

Yes it's technically fudging it, but the executive in charge was not listening to any of us so we skewed it to our favor.

Re:Sliding Average (1)

pwolf (1016201) | more than 5 years ago | (#28350607)

That's what we are doing at my job (and the job I had before). Management wants to see more tickets in the reports so we look like we are busier then we really are... which we are already really busy. We make a ticket for everything we do. The smallest of issues get recorded. We were hoping this increase in ticket count would equal a new position but that didn't happen... we just get more work :|

Reducing calls... (0)

Anonymous Coward | more than 5 years ago | (#28349703)

...reduces jobs.

Smart users vs stupid ones (2, Insightful)

Darkness404 (1287218) | more than 5 years ago | (#28349707)

I consider IT's primary goal to be as transparent to the user as possible, thus this metric was rather troubling to me. Shouldn't we be focused on reducing calls, rather than simply closing them quickly?

Not for "stupid" users, the ones you see on a day-to-day basis. Now, this all depends on who you are giving support to, competent IT professionals or the day-to-day office worker. If you are giving them to fellow IT people, it should be a goal to be transparent. For the office worker the main job is productivity, that means fix the problem as soon as possible or tell them there is no problem and have a good day.

Tracking invisibility (1)

BillCable (1464383) | more than 5 years ago | (#28349709)

It's kinda difficult to measure how often something doesn't happen, unless you just track uptime. You'd need to do that on a per-workstation basis to get some idea how few calls come in. I don't think the speed of closed tickets should be the only measure. Customer satisfaction should also be tracked, both in terms of service calls and system reliability.

Measuring workstation uptime (1)

qbzzt (11136) | more than 5 years ago | (#28349915)

If the company has an IM solution, such as IBM Lotus SameTime [] , you can measure gaps. Look for holes in user availability.

If I am available on work IM 8-5, then my workstation was up during that time. If I am on work IM 8-9:12 and 9:18-5, I probably had a six minute downtime.

Ah the age old quantify IT... (0)

Anonymous Coward | more than 5 years ago | (#28349711)

Well here's a newsflash you can't quantify most IT jobs. We are an ever changing backbone to the business in most cases. Metrics are meaningless to us. If you'd like to have a way of evaluating IT then set goals. Salespeople use metrics as a way of increasing sales and ridding themselves of dead weight. As an IT person you can be on fire one week and dead the next and it's all the same. So to answer the OP, take a picture of your ass and give it to the person that originally put the thought in your head that we need to justify what we do or how quickly we do it.

Re:Ah the age old quantify IT... (2, Insightful)

Cerberus7 (66071) | more than 5 years ago | (#28349899)

Yeah, that's pretty much it. Managers and executives can't handle anything that doesn't have a nice, neat, single number that tells them everything they need to know without having to actually know what's going on.

You can count calls, count time spent on calls, how long it takes between when a call is received and a tech is dispatched. You can count how many devices you have deployed in the field. All of these numbers tell you different things, and not one of them tells you much of anything by itself. Management needs to actually be in touch with the field and truly understand what's going on in their IT department, otherwise all those numbers are pretty meaningless.

Not QUITE the stupidest metric I can think of.... (5, Insightful)

gestalt_n_pepper (991155) | more than 5 years ago | (#28349721)

But it's close. Of course, closed tickets are something a manager can measure. Needless to say, it measures nothing meaningful. For example, I tell a customer to reboot. Close the ticket. That takes little time and closed the ticket fast. In fact, I can improve my metrics by telling that same person to do this ever 4 hours for several years. OR, I can get up, go to their desk, and solve the problem permanently. It takes longer, making my metrics look bad, but in reality-land (a land far, far away from management land), that person is doing productive work longer and more efficiently because the interruption and downtime have been removed.

Re:Not QUITE the stupidest metric I can think of.. (1)

Hognoxious (631665) | more than 5 years ago | (#28349919)

Close the discussion. We have a winner.

My metric? (0, Flamebait)

courtjester801 (1415457) | more than 5 years ago | (#28349727)

Showing up on time. It usually doesn't happen.

Now pay attention (3, Insightful)

JamesP (688957) | more than 5 years ago | (#28349743)


A good metric should be

1 - Enterprisy looking
2 - Easy to gamble by the interested

Your boss wants a number, give it to them quickly. It's all BS (or 99% of it at least. Don't agree? Do the job then) in the end.

So good metrics could be.

- Unplanned downtime
- Number of users, number of bytes used, etc (that plots a nice ascending graph, and ASCENDING IS GOOD, you can print that and put it in the wall)

If they stay on 'time to close the ticket' NEEDINFO and WORKSFORME is your friend.

Another view? (1)

ITJC68 (1370229) | more than 5 years ago | (#28349749)

As someone in the support field the company I work for looks at the # of steps in the ticket to resolve the issue, the overall time in resolving the issue and the complexity of the issue. The goal is always to reduce the amount of calls and steps but call complexity also must be measured in the overall metric.

My two cents (2, Insightful)

Ltap (1572175) | more than 5 years ago | (#28349763)

Amount of service calls: s

Amount of service calls resolved: h

Server/network downtime (in hours): d

Use formula '(s / h) + 2d"

Use resulting number to chart IT support performance, assuming that the network + server uptime and stability is more important than user inconvenience. You could decide that anything above a certain threshold is too much, or use it to compare personnel with each other.

Re:My two cents (0)

Anonymous Coward | more than 5 years ago | (#28350187)

Here let's try this again:
Amount of service calls: s
Amount of service calls resolved: h
Amount of downtime: i
Amount of overhead: t

IT Performance metric = s*h*i*t

Re:My two cents (1)

rednip (186217) | more than 5 years ago | (#28350431)

So, you disagree with the submitter, as 'taken' / 'fixed' is exactly the sort of performance metric he's complaining about. Also, I hope that you just made up that formula, as it doesn't really make any sense;
Excellent employee:
s (total calls) = 100
h (total solved) = 100
d (time in hours)= 2
total 5
very bad Employee;
s = 100
h = 50
d = 2
total 6

As I see it you would have to get below half your calls resolved for calls to affect that number at all, assuming some down time.

Well.. (1)

hyfe (641811) | more than 5 years ago | (#28349829)

Any metric is, at best, indicative. You can spend all day designing a better metric and by the end, you're still not going to get anything better than, well, indicative.

As with all data-analysis, make sure that whoever's using these numbers know how bad they are. If we're dealing with reports and decisions, make sure that there's a short explanatory comment by somebody in the know about to which degree you feel that these numbers are representative (example : overall performance is improved, but averages are scewed by a large of number complicated bugs on New Product).

Oh, and if the people making decisions are MBA's unable to read a single short sentence, you're screwed either way. Then you just have to roll with it :)

Lots of different metrics (1)

z4ce (67861) | more than 5 years ago | (#28349835)

Time to resolution is a perfectly acceptable metric for a help desk department. For services some of the important metrics are availability (including performance!), mean-time-between-failure, number of new releases, percent of successful releases, etc. For specific processes you should have metrics for example for how long the new employee on-boarding process takes, or how long it takes to bring additional capacity online, etc.

I recommend you talk to someone that are experts in IT Business Service Management. If you're in the US one of my previous employers ( could help you.

now that you know... (0)

Anonymous Coward | more than 5 years ago | (#28349839)

you need to engineer easily fixable problems... up goes your rating... whee!!!

Develop an SLA w/ your company (3, Insightful)

goldspider (445116) | more than 5 years ago | (#28349857)

In my department, we have an agreement with the rest of the company outlining the level of service that must be performed within a pre-determined amount of time, based on incident priority. With the right tools, it's fairly easy to track the percentage of incidents resolved within the terms of the SLA.

Not good to count number of tickets (2, Informative)

Saint Stephen (19450) | more than 5 years ago | (#28349861)

I think that when the metric is to reduce the number of calls, the natural human tendency is to ignore calls, shift calls to other people, etc. to make it look like you're doing better when you're not.

So that's why most people look at your find versus fix ratio, the number of bugs you find versus the number you fix / the length of time it takes to fix them. It's not great to have zillions of issues, but you should always try to fix the issues as quickly as possible.

in my government job (2, Funny)

Anonymous Coward | more than 5 years ago | (#28349863)

In the low-level government job I suffered through for 2 miserable years, IT performance was measured by presence in your chair. If you kept the chair at a satisfactory egg-hatching temperature, and never made your presence otherwise known, you were a star. If you did work, you were a source of trouble.

One True Metric (2, Informative)

NonSequor (230139) | more than 5 years ago | (#28349867)

There's one metric that can capture everything:

Bits of Shannon entropy processed per hour.

Before we're going to measure anything (1)

El_Muerte_TDS (592157) | more than 5 years ago | (#28349879)

Can you please explain what defines "IT performance" so that we know what we have to measure.

opportunity for measurements (0)

Anonymous Coward | more than 5 years ago | (#28349903)

Clearly a single metric is unlikely to be best way to measure performance. A weighted some of various measurements sounds better and has the additional benefit of creating spirited discussions of what the weights should be. Brave souls even dabble with nonlinear functions of the measured items.

ITIL (4, Informative)

prakslash (681585) | more than 5 years ago | (#28349913)

Shouldn't we be focused on reducing calls, rather than simply closing them quickly?
We should be focussed on both.

My question is: How is your IT performance measured, and how do you think it should be measured?
ITIL [] principles are a great starting point.
Examples are using Key Performance Indicators (KPIs) such as at the bottom of this page [] and this page [] .

Re:ITIL (1)

goldspider (445116) | more than 5 years ago | (#28350343)

We implemented a new incident/problem management process around many ITIL practices. After 5 months of adjusting to the new processes, last month 95% of our calls were handled within SLA. ITIL works.

Metrics keeping Managers employed since .... (1)

enterprisearchitect (745160) | more than 5 years ago | (#28349925)

80% of Users are a PIA, 20% never call the help desk. Metrics can be construed in many different ways to represent a positive or negative interpretation.

Re:Metrics keeping Managers employed since .... (2, Informative)

rasper99 (247555) | more than 5 years ago | (#28349977)

I remember it as being 10% of the people (whiners) take up 90% of the support time.

Depends on the position (1)

loteck (533317) | more than 5 years ago | (#28349927)

For a level 1-2 support position, metrics should probably be focused on how efficiently tickets are resolved. Once you get into administrative functions and management, those positions should be the ones focusing on increasing stability and reducing the amount of tickets submitted in the first place. Hopefully your managers and administrators are being assessed for their success in those areas, just as the junior staff are being assessed for how efficiently they can process the issues.

Worked at a place like this (2, Informative)

Publikwerks (885730) | more than 5 years ago | (#28349931)

At my former employer, customers would call the national helpdesk, who were rated by their time on a call. Let me tell you, the type of customer service you get from that environment is crap. They would have the customer reboot their machine, and if that didn't work, they would escalate the call to a state level operations center that could dispatch technicians (where I worked). They were, for the most part, useless. They made the customers angry, and really served no purpose other than a filter.

Re:Worked at a place like this (1)

thewils (463314) | more than 5 years ago | (#28350225)

Sounds just like the place I worked at some time ago...that's why we renamed "Helpdesk" to "Hinderdesk" because all they did was hinder you from finding a solution.

Management get the behavior that it rewards. (5, Insightful)

xs650 (741277) | more than 5 years ago | (#28349937)

Management gets the behavior that it rewards, not necessarily the behavior that it pretends to ask for

Metrics = Manager is getting a bonus (3, Insightful)

Anonymous Coward | more than 5 years ago | (#28350013)

Whenever I see a metric that measures quantity instead of quality, that tells me the manager gets a bonus. Hopefully, you're getting a piece of that bonus.

Re:Metrics = Manager is getting a bonus (2, Informative)

Cerberus7 (66071) | more than 5 years ago | (#28350347)

This, too. It's a sign of a bad management structure. Useless statistics resulting in managers getting bonuses is also a great flag for "cost saving" measures that can be taken. Eliminate the managers that fit this category with no other redeeming qualities, and you'll save a boat-load of cash.

By productivity gains (1)

malkavian (9512) | more than 5 years ago | (#28350057)

in other departments when IT introduces new systems to them.

No, it's not an easy metric to obtain there, but IT is not a simple discipline to categorise. As an example, ask someone to give a hard metric on how much useful information they know (to 2 decimal places).

Re:By productivity gains (1, Informative)

Anonymous Coward | more than 5 years ago | (#28350365)


How quickly can you close calls? (2, Insightful)

randomnote1 (1273964) | more than 5 years ago | (#28350067)

Sounds pretty normal for a call center. At my last job management got excited if a case was open for over two weeks regardless if the issue was resolved or not. That's what I call great customer service!

This is why the IT department is always cut first (4, Insightful)

joeyg1973 (1199299) | more than 5 years ago | (#28350077)

Here is the problem... you are trying to assign arbitrary numbers to something that cannot be measured. These are numbers for accountants, they want one number to be able to show them where to cut cost. Problem is that there is no way to quantify how much money an IT department saves a company. Metrics have gotten out of control in this country. We are always measuring the cost and never measuring the value. How do you assign a number to a person who is not a number? How do you quantify the guy who spent all weekend fixing the server? How do you quantify the accrued knowledge of a human being? It impossible to do. The accountants never ask questions like, "How would my quality of life be affected if I couldn't get effective tech support?", "How much money would the company loose if these computers and programs didn't exist?". You need to measure the man and his work as a whole, person to person.

Ideal and Actual (2, Interesting)

sexconker (1179573) | more than 5 years ago | (#28350151)


I know about IT, having worked there for many years. In fact, I'm still working there. Keep up the good work, I know there's a lot of bullshit to put up with.


I heard some buzzwords. When can we implement them in order to actualize our potential? Also, I'll need you to stay late and fix my computer. It's got some sort of virus or something I don't know.

(As you're fixing his machine, you see a note on his desk right next to the post-it with his passwords)

Hire grad student from India [x]
Get what's his name to train him. [ ]
Fire what's his name. [ ]
Synergize. [ ]

Time to close tickets is 1 factor, not the ONLY 1 (3, Insightful)

King_TJ (85913) | more than 5 years ago | (#28350157)

I think the average time taken to close a trouble ticket is important, but it's not the only factor you want to look at.

The primary purpose of issuing unique trouble ticket numbers is to provide an easy "one stop" tracking mechanism for the issue. A customer (or employee) should always be able to reference a ticket # to support staff, and in turn, they should be able to pull up a fairly comprehensive history of what's been done so far to resolve the issue.

If you push too hard for closing tickets quickly, you'll see a tendency for new tickets to get issued on things which should REALLY be continuations of an existing ticket, held open longer.

(EG. I call in complaining that my inkjet printer won't print yellow. A ticket is created and they tell me my color cartridge is clogged up, so put a new one in and I should be fine. Ticket is closed. I switch cartridges with a new one, and discover it STILL doesn't print yellow. I call in and a new ticket is made for what's really the same issue. I'm told how to run the printer through cleaning cycles, and instructed that I may have to do it "up to 10 times" to see results. Ticket closed. I get around to trying that the next day when I get time, and even after 10 or 15 attempts, no yellow is coming out. I call back in, only to have ANOTHER new ticket opened, and the tech wastes my time asking me if I "tried a new cartridge yet?" and I have to interrupt him in the middle of re-explaining how to do a cleaning cycle. Problem is eventually determined to require a replacement printer ... but should obviously have all been filed under one ticket.)

Re:Time to close tickets is 1 factor, not the ONLY (1)

MortenMW (968289) | more than 5 years ago | (#28350283)

Did you install the new cartridge right? (You are excused if you are a manager...)

Oblig. Semi-Quote (1)

hal2814 (725639) | more than 5 years ago | (#28350205)

Boss: How many IT tickets did you close today?
IT Drone: Oh, Boss, I don't keep score.
Boss: Then how do you measure yourself with other IT workers?
IT Drone: By height.

Social metrics (0, Offtopic)

davecrusoe (861547) | more than 5 years ago | (#28350223)

We're doing a lot of social outreach, and measured by metrics like how many new members join through our outreach. We're still searching for the best metric to measure our progress in this realm. To that extent, we had to develop our own tool (!), available for free to others at [] . Cheers, --Dave

Customer Satisfaction Surveys. (2, Interesting)

wonderboss (952111) | more than 5 years ago | (#28350275)

Our competitors measure their performance by time to close tickets. They are consistently rated worst in support. We use surveys. Simple questions like: Was your problem resolved? Was it resolved promptly? We are consistently rated best in support.

Metrics on help desk tickets (1)

kilodelta (843627) | more than 5 years ago | (#28350291)

I've had some experience with this. Here's what ends up happening.

You setup a system so that a ticket is assigned, the person assigned gets into the ticket and adds comments. Technically they've answered the ticket at that point. The thing that lots of people don't want to realize is that some tickets will go on for months on end.

You f@4il it (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#28350299)

mistake of electing all along. *BSD Conflicts that of the warring []? started work on You all is to let Can connect to raise or lower the private sex party inventing excuses Troubles of those Volatile wor7d of which allows The curtains flew by BSDI who sell lost its earlier first organization first organization My calling. Now I shower Don't 6ust argued by Eric Contaminated while The latest Netcraft and that the floor to be about doing are attending a real problems that is ingesting In addition, a GAY NIGGER Recent article put Was in the tea I you have a play that they sideline Violated. In the and has instead we get there with they're gone Mac you get distracted claim that BSD is a munches the most I thought it was my

From a business point of view...? (2, Informative)

BlueKitties (1541613) | more than 5 years ago | (#28350313)

Bouncing customers is a good way to keep them from calling back -- grandma is much more likely to phone up 'lil Tim for computer advice if she knows the hotline tech is going to bounce her to ten different places; where I work, we get a good bit of troubleshooting work because the customers hate calling the hotlines provided by the manufacturer. Sadly, annoying your customers is a good way to keep them from calling back, and as long as your product is good enough people will still pay-up. E.g. I'm screwed into Suddenlink where I live. After being promised $85.01 TV/Net, I got a $100.00 bill because of hidden fees. Guess what -- I'm screwed into paying, because the only alternative (Cox) was bought out by Suddenlink.

Response Time (1)

DeckardJK (555299) | more than 5 years ago | (#28350333)

We have a help desk ticketing system that automated issues get logged in. The on call personel will get pages. Also... other individuals in the company can make requests and log issues into the system to assign them to groups or individuals. The only metric really recorded is response time to respond to the client or automated event. The first concern is communicating early that the concern has been noticed and is/will be scheduled for work.

time to resolve is sometimes misleading (1)

Col. Panic (90528) | more than 5 years ago | (#28350357)

if the helpdesk clock doesn't start until they open the ticket. i get users all the time who say they spent an hour or more on the phone with the helpdesk. i ask them for future reference if the help desk technician cannot resolve their issue within 10-15 minutes, to open a ticket and escalate the issue.

it is inexcusable for a first level tech who clearly doesn't know how to fix the issue to waste our client's time fumbling around and not resolving the issue. this is why we have tiers of support - log a ticket and send it to a more experienced technician who will save the client time. what i would like the first level techs to do is track the tickets they could not resolve and later look them up and read the audit trail so they learn what the fix was.

Dilbert does it best (0)

Anonymous Coward | more than 5 years ago | (#28350393)

Its Quality not Quantity (1)

DarthVain (724186) | more than 5 years ago | (#28350411)

I will admit I am not sure what would make the best IT metric of service. However I can tell you without a shadow of a doubt what does NOT make a good metric, and how many tickets you close is one of them.

I think my organization must use that metric for evaluation. When I call, I get a ticket. Then they generate a ticket, that they created a ticket, and send me a ticket. Then nothing happens for a long time. Then after I get tired of waiting, I call. Another ticket is generated about the first ticket. Eventually someone will look at it, and say oh we are not responsible for that, would you like use to make a ticket to flag this problem? Great. In the end months later someone may or may not call you about the final ticket that is essentially about not being able to help you at all, ask if you wish the ticket removed. Otherwise it is assumed that it has been taken care of after awhile, and thus satisfying all the rest of the tickets in some sort of orgasmic cascading ticket extravaganza. Then at year end they see they have close 8 Billion tickets, congratulate each other on a job well done, pats on back and bonuses for everyone. Hazzah!

That has been my experience so far anyway.

Proposed Metric (1)

pak9rabid (1011935) | more than 5 years ago | (#28350433)

When your only IT guy goes on vacation for a week+, measure on a scale from 1 to 10 how much he/she was missed.

Just count yourself lucky... (2, Informative)

mario_grgic (515333) | more than 5 years ago | (#28350443)

that your organization has made your job measurable. It does not matter what they measure your performance by, as long as it is something tangible.

So, you get payed by how many tickets you managed to close in a month. Fine. So, you close as many as you can in a month, resulting in lower quality of each problem fix, resulting in more tickets posted and assigned to you, resulting in you having ensured that next month you have enough tickets as well.

This can go on indefinitely, or your wise superiors might decide to measure your work somehow else.

You Need to Do Both (1)

SwashbucklingCowboy (727629) | more than 5 years ago | (#28350503)

"Shouldn't we be focused on reducing calls, rather than simply closing them quickly?"

You need to do both.

Mixture of Customer Service and Time Metrics (0)

Anonymous Coward | more than 5 years ago | (#28350525)

Customer service should be primary and just use SLA/Time metrics to make sure people aren't goofing off. People are more happy to have support from someone that is slow, communicates and is positive than someone who treats them like garbage and is quick.

Recount: (1)

Arivia (783328) | more than 5 years ago | (#28350563)

.recount toggle

IT should be focused on "customer service" (2, Interesting)

hellfire (86129) | more than 5 years ago | (#28350573)

Prior to my software company being bought out, my It department was focused on "customer service." This means that everyone in the company is treated like a customer. I personally work in our software support department and this made utter sense to me.

Under the new company, our new IT works for itself, and primarily is concerned with closing calls as quickly as possible, without regard for the quality of the information or assistance. They are concerned with reducing their own call load, but they don't try very hard, and they don't offer a lot of value over that. Any good customer service department is concerned with closing calls, but they want provide good quality service where each call is resolved as quickly as possible, but also as accurately as possible and leaving a good feeling with the customer. IT should be a resource utilitized to make the company more efficient and reduce costs, not a bunch of yahoos who fix broken PCs and then disappear back under their rock when they are finished.

In customer service, quantitative metrics are used to judge the department trends as a whole, and can be important, but even more important art qualitative measures, like surveys and feedback, example cases, and periodic reviews of every rep, team leader and supervisor. Did the rep do "The Right Thing" (tm) and how many times did they do that, and are they approaching doing the right thing 100% of the time? If a rep provided the user with the right answer, but all they did was email a timid accountant a 5 page document on setting up .NET properly just so the user can properly export his reports to an email to his boss, and then the rep closed the case and offered this less than technical person any real help, how service oriented is that, really?

Sometimes that means taking fewer cases per rep and leaving them open longer, if service improves dramatically.

No Tickets Used?? (1)

bouaketh (731170) | more than 5 years ago | (#28350581)

We don't use trouble tickets here. Our VPs are well enough aware that I am busy, as are the other 3 IT staffers trying to keep everybody moving forward. Most issues are resolved on a FIFO basis and each staffer has their own AO. Barring ISP issues most problems get taken care of the same day. Good infrastructure+ good co-workers+ VP support= Happy and Efficient IT people

Some factors to quantify quality IT (1)

jcwynholds (765111) | more than 5 years ago | (#28350595)

Some metrics to consider:

  • overall cost of IT dept.
  • Per capita trouble tickets *
  • time to close tickets *
  • cost per closed ticket
  • cost savings vs. contractors / hired guns

If you are good, then the last one will justify your existence.

* = Might also prove cluelessness of user base

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>