Ideal, and Actual, IT Performance Metrics? 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?"
When testing a new blade server install... (Score:5, Funny)
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... (Score:4, Informative)
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......
Re: (Score:3, Informative)
The whoosh belongs to you. GP is a troll. Cut and paste troll slightly modified to appear on topic. You bit.
No cnt++ (Score:5, Funny)
I thought IT got paid for the number of times they said 'No' to us during the day.
go figure.
Re:No cnt++ (Score:4, Insightful)
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++ (Score:5, Informative)
Re:No cnt++ (Score:5, Insightful)
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++ (Score:5, Insightful)
[sales to IT] We need (something that is a huge security risk).
[IT to sales] No.
[sales to administration] waaaahhh.
[admin to IT] Do it.
[IT] Grumble grumble fuck you. *does it*
[sales] yaaay!
[Admin] Damn IT.
Shit hits the fan, IT is blamed. Goto 10.
Re: (Score:3, Insightful)
Re: (Score:3, Insightful)
[IT] We requested $X for the job, you gave us $X/100 for the job, we couldn't. We warned you what the risks were in these 12 Emails, 2 Printed Letters and numerous phone calls. You didn't care because it cost too much at $X but was worth it for $X/100. Now you have to pay $X x 100 to fix your short sightedness.
Don't blame us if you didn't understand the risks.
You need accountability (Score:3, Interesting)
If a business service owner signs off then what is the problem? They are the ones getting fired when it all goes to shit.
Just make sure your change management board includes them, and finance as well. If you have a change management system you can even point to the change number and the requestor and say this guy caused N million doillars worth of bad press/whatever to the share price,
It isn't ITs job to say no, it's ITs job to explain the risks.
Re:No cnt++ (Score:5, Insightful)
[sales to IT] We need (something that is a huge security risk).
[IT to sales] No.
[sales to administration] waaaahhh.
[admin to IT] Do it.
[Competent IT with minimal people skills] No, and here's why
[Admin] Ok, it was a dumb idea.
Re:No cnt++ (Score:5, Insightful)
[Sales to IT] We need (something that is a huge security risk).
[Good IT] Here's a slightly different solution that addresses your needs without creating a security risk.
[Sales] Great, thanks!
[Good Admin to IT] Good job understanding the client's needs and thinking outside the box to get it done.
Re: (Score:3, Insightful)
[Sales to IT] We need (something that is a huge security risk).
[Good IT] Here's a slightly different solution that addresses your needs without creating a security risk.
[Sales] Great, thanks!
[Good Admin to IT] Good job understanding the client's needs and thinking outside the box to get it done.
No, it goes like:
[Sales to IT] We need (something that is a huge security risk).
[Good IT] Here's a slightly different solution that addresses your needs without creating a security risk.
[Sales] No, Dammit, we asked for (something that is a huge security risk). We already marketed (something that is a huge security risk). We'll lose $$$ if we don't get (something that is a huge security risk).
[Bad Administration to IT] ZOMG! $$$? Doit doit doit!
[Good IT to Bad Administration] But we'll likely lose
Re:No cnt++ (Score:5, Insightful)
Re: (Score:2)
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! (Score:5, Insightful)
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:Exactly! (Score:4, Informative)
Re:Exactly! (Score:4, Insightful)
The point is to get them to the point of asking "what do we need in order to do _______", rather than assuming we can do it, for nothing, by next Tuesday.
Just the other day, we had a server motherboard die. Wouldn't even POST properly. The director of the dept the server is used for said that was unacceptable that they would be down for a couple of days while the server was being repaired.
I said that if this were truly the case, they would have a standby server, with a current backup of the database ready in stand by mode at all times, for fail over.
The problem is, they don't want to pay for a standby server, or the systems infrastructure to make sure that the DB can failover gracefully to the standby hw in the RARE event like this.
It costs money to do things like this, and sometimes lots more than it is actually worth. I find out all the time how much things are worth to people when stuff breaks, and when I quote a system setup that will work in the event of failure like what I described.
When they found out how much it would cost for a redundant system, even after the failure, they didn't pony up the $$, while maintaining that it was unacceptable to be down for any length of time.
How does one break that mentality, I'll never know.
Re: (Score:3, Insightful)
Re: (Score:3, Informative)
Your COLO probably bought RACKS of identical servers, and for every rack has one hot standby. THAT is what I would do if I were running a COLO.
When running a large operation it is easy to bury an extra standby server in with 24 or 48 other servers (add 1/24 or 1/48 to the cost of each server). However when you order the server as a one off, you can't double the cost just to have a hot spare.
Here is an example.
Let us assume you're building a server, and it cost $5000. Are you gonna cry over the $210 needed f
Re: (Score:3, Interesting)
You missed the point. THE point is that they never really had a budget in the first place. They thought it could be done for nothing, by next Tuesday.
Much of what geeks do, and I see it a lot here on /. is that we tend to be DIYers. We see a high end server and say things like "I can build it for less". And people begin to expect that we can do things for less than to do it right, with engineered pieces.
Yes, we can build a off the shelf server to hold terabytes of storage for cheap. Too bad it is in a mini
Re: (Score:2)
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.
Stop asking to do stupid things (Score:2, Insightful)
Stop asking to do stupid things like
- run an internet server without a firewall
- Setup accounts without passwords
- Use 1-off proprietary software when we've selected the best solution for everyone in the company. Too bad our selection costs 3x more than the other stuff.
- Bring a 64-way server up without a fail over, test, dev, and DR instances too.
- Bring a 32-way server up this week, when your project hasn't been approved yet. These things take about a month to get delivered and another month to get instal
Re:Stop asking to do stupid things (Score:4, Informative)
The last company I worked at, I was the manager in a department of 130 people. When I left, the company had deployed server #100,000 to its datacenter.
I understand CM well, but (and I hope you're exaggerating), if your IT team requires backout plans for "Install OS" as a deployment step, then someone needs to step in and reign in the bureaucrats.
obvious (Score:3, Funny)
Customer Satisfaction, and pro-active problem solving
Re:obvious (Score:5, Insightful)
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: (Score:3, Interesting)
But how do you measure the success rate of a problem you solved proactively, thus ensuring it never becomes a measurable problem?
That is simple: fewer number of calls or calls about a particular problem is the success rate of solving a problem proactively. Strictly speaking the IT Service desk shouldn't be solving problems, just getting customers back to the point where they can use the service again or work around some problem. Management and the level 2 engineers should be the ones solving the problems.
We have a problematic metric with password resets, they don't take very long but are the biggest amount of calls our help desk ge
Re: (Score:3, Funny)
But password resets should be self service and at some point they are going to be.
No security problem there!
Re: (Score:3, Funny)
No security can withstand the incredible power of having huge balls.
Re: (Score:2)
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.
In some areas of IT, "pro-active" equates to breaking things that aren't broken.
Re: (Score:2)
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 p
I think it should be measured... (Score:5, Funny)
...by the number of callers left alive at the end of the day.
I concur ! (Score:2)
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 (Score:5, Insightful)
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 (Score:4, Insightful)
Re: (Score:2)
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. (Score:5, Interesting)
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: (Score:2)
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. (Score:5, Insightful)
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: (Score:2)
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. (Score:2)
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
Re: (Score:2)
Re:Sounds good to me. (Score:4, Insightful)
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. (Score:4, Insightful)
Re: (Score:3, Informative)
Sad to say but the more invisible the IT department is, the harder it is for them to get funding for new projects.
Re: (Score:3, Interesting)
I have been recently working on a system to do just this. We already had an audit system that some of our apps were using, but after generating a set of usage reports showing the volume of usage we managed to get some more buy in and it is now being used by almost all of our apps.
To go even further, we are trying to get access to the help desk's database so that we can generate reports comparing usage to tickets.
Metrics like these can still pose some risk for mis-interpretation. It'll definately be more use
Re: (Score:3, Interesting)
I was thinking of a system similar to that. My solution came from actually being replaced because i was doing too much preventative maintenance. In my case, my replacement did no preventative maintenance and downtime were much longer plus his work load was much greater.
In order for it to be effective, you need to consider lost profit or down time potential too. I created some hypothetical numbers where the user is evaluated by costing the company 100 points a day and makes the company 300 points. so on a no
Re:count tickets never openend (Score:4, Funny)
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."
Smart users vs stupid ones (Score:3, Insightful)
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.
Not QUITE the stupidest metric I can think of.... (Score:5, Insightful)
Now pay attention (Score:4, Insightful)
s/metrics/bullcrap
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.
Re: (Score:3, Informative)
Basically what the parent poster is pointing out is that absolutely any metric that management can come up with can be fooled.
For instance, now that you know that "time to close the ticket" is the metric, you can always close the ticket and then go work on the problem rather than the other way around. Or if it's an average time to close, you can get a pal who works in another department to open up a bunch of phony tickets for you to resolve quickly.
To quote extensively from Joel Spolsky [joelonsoftware.com]:
Robert Austin, in his book Measuring and Managing Performance in Organizations, says there are two phases when you introduce new performance metrics. At first, you actually get what you wanted, because nobody has figured out how to cheat. In the second phase, you actually get something worse, as everyone figures out the trick to maximizing the thing that you're measuring, even at the cost of ruining the company.
Worse, Econ 101 managers think that they can somehow avoid this situation just by tweaking the metrics. Dr. Austin's conclusion is that you just can't. It never works. No matter how much you try to adjust the metrics to reflect what you think you want, it always backfires.
My two cents (Score:2, Insightful)
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: (Score:2)
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.. (Score:2)
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 a
Lots of different metrics (Score:2)
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 Manageme
Develop an SLA w/ your company (Score:4, Insightful)
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.
Read up on ITIL (Score:3, Insightful)
It's IT management from a wholistic point of view.
SLAs are only one aspect of IT management.
There is no point measuring something unless you are going to do something with the information. Are your metrics getting better because things are getting better or are you just getting better at fighting the same old problems. Are you measuring a metric because it's easy to meassure or because the business needs that metric to be good?
Ultimately the idea is to get incidents themelves to zero because that means a sm
Not good to count number of tickets (Score:3, Informative)
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 (Score:2, Funny)
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 (Score:3, Informative)
There's one metric that can capture everything:
Bits of Shannon entropy processed per hour.
Before we're going to measure anything (Score:2)
Can you please explain what defines "IT performance" so that we know what we have to measure.
ITIL (Score:5, Informative)
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 [wikipedia.org] principles are a great starting point.
Examples are using Key Performance Indicators (KPIs) such as at the bottom of this page [itlibrary.org] and this page [itlibrary.org].
Re: (Score:2)
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.
Re:ITIL (Score:4, Funny)
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.
In my organization, the number of priority 1 incidences have dropped by 95% since implementing ITIL. That is mostly because there is so much paperwork and hassle involved in opening a priority 1 incident that nobody opens them anymore. ITIL works.
Depends on the position (Score:2)
Worked at a place like this (Score:2, Informative)
Re: (Score:2)
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. (Score:5, Insightful)
Metrics = Manager is getting a bonus (Score:3, Insightful)
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: (Score:2, Informative)
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 (Score:2)
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).
How quickly can you close calls? (Score:2, Insightful)
This is why the IT department is always cut first (Score:4, Insightful)
Re:This is why the IT department is always cut fir (Score:3, Interesting)
I think you're stretching things a bit.
"How do you quantify the guy who spent all weekend fixing the server?" You look at the number of times it's happened and you figure out how much it would cost to get that level of service agreement from an outside vendor.
The accountants are much more likely to be asking questions like "how would the business be affected if we outsourced IT at a cost of X, thereby allowing us to save Y in salaries, at a cost of Z in reduced productivity due to longer resolution times".
Ideal and Actual (Score:3, Interesting)
Ideal:
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.
Actual:
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 (Score:4, Insightful)
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.)
Oblig. Semi-Quote (Score:2)
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.
Customer Satisfaction Surveys. (Score:2, Interesting)
Metrics on help desk tickets (Score:2)
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.
From a business point of view...? (Score:2, Informative)
time to resolve is sometimes misleading (Score:2)
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 tic
Its Quality not Quantity (Score:2)
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. Event
Proposed Metric (Score:2)
Just count yourself lucky... (Score:3, Informative)
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 (Score:2)
"Shouldn't we be focused on reducing calls, rather than simply closing them quickly?"
You need to do both.
Recount: (Score:2)
IT should be focused on "customer service" (Score:3, Interesting)
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.
SLAs (Score:2, Insightful)
We are big on SLAs. Department directors have to sign off on an SLA before IT will support their stuff. Actually this is how IT gets it's budget.
For example, marketing comes to IT and asks for a service like sales tracking. After figuring out what they want we give them a quote with SLA and how much it will cost. After buildout there is a sign off and the service is available for use. To the users there is no concept of hardware of server. They just know if their stuff is working or not. I mean they a
Stupid metrics (Score:4, Insightful)
Stupid metrics are part of the problem. When I worked for Gateway, they wanted your call average to be between 7 and 11 minutes. If you went above for the week/month, you were too slow and bad at your job. If you went below, you were probably just getting people off the phone without solving their problems.
That metric worked for most people, because they talk slow and have to look up every single issue.
For me, it was killer. I was consistently getting 5 minutes averages, even with that inevitable once-a-day 1-hour phone call. I got reprimanded twice about it before I gave up and quit. Almost every caller was happy with how I helped them. The others couldn't be helped, or I made a mistake. (I told a guy he could clean his keyboard, once... They had switched to keyboards that fall apart if you try to open them, apparently. In my defense, I had offered to send one, but the guy thought cleaning it would be a lot faster.)
Also note that a certain percentage of calls were recorded and reviewed, and I -never- got talked to about any of my calls. The only complaint I had was the keyboard guy. And yet I still got yelled at for short call times.
Again, stupid metrics are stupid. Call-time has nothing to do with customer satisfaction.
You're, right mostly (Score:2)
If they're just monitoring how quickly tickets get closed and faster is always better, then your observation of the utility of the metric is spot on. Otherwise, productivity is a valid measure and how fast someone turns around work is important.
Corporate IT performance, and support/operations performance can include a timeliness measure, but the interpretation and use of the metric matter. So, for instance, the correct use of such a measure would be to see if a technician is turning work around quickly en
ITIL (Score:3, Informative)
The metric is valid when looking at the model where you have INCIDENT MANAGEMENT versus PROBLEM MANAGEMENT.
That first line of call-in is about making sure the human caller gets to a human as quickly as possible. Within 15 minutes flipping that call should be done OR escalated to PROBLEM MANAGEMENT. The reasoning is while you are talking with somone there is another caller trying to get a hold of someone.
Turn Around time is relevant to INCIDENT MANAGEMENT versus PROBLEM MANAGEMENT. The problem is when there is not a clear difference between incident and problem management groups.
Three metrics that are needed:
Caller Hold Time
Call Turn Over Time
Ticket Resolve Time
Hold time is the customer's experience in getting thier problem addressed. Not neccessarily resolved, but addressed.
Call Turn Over Time is key on hinting at the type of problems. If 90% of your calls are resolved in under 5 minutes, you more then likely have training issues. If 50% are resolved in the first 5 minutes and 25% are escalated to PROBLEM MANAGEMENT then you may have a process failure or technical issue.
Ticket resolve time is over all the volume of touble you have in regards to the severity of the problem. Logging 1200 hours a week of SEV1 tickets tells of serious problems verus 1200 hours a week of SEV3 or 4 problems.
Mostly management uses those metric for determining what areas need to be addressed. They are not performance metrics on their own, in fact useless for measuring performance. You would need at least the % of tickets escalated to even start determining performance.
This of couse is under the assumption of a split between INCIDENT and PROBLEM management.
Fire Fighting is all that counts (Score:3, Insightful)
Years ago I learned that most managers are so remarkably ignorant of what good IT workers do, you know preventative work that ensures users can do their jobs without interruption, that the only way to get ahead is to be a bad IT worker.
Meaning if you let all sorts of bad stuff happen and then rush in and be the savior of the day you will be rewarded with promotions and bonuses.
A few years ago, just before I left my last job, I demanded a job review having gone 6 years without one. I got to sit through my review by the VP in charge of the division I supported and my direct IT boss from Denton Tx, only to be criticized for not socializing with some techs who came up from Denton to help with a move of the office 80 mile to a new city. I had elected to do my appointed tasks for the move, baby the servers and double check backups prior to taking them down packing them up and reinstalling them in the new sites server room.
Had I done the socializing I would have ignored my duty to the corporation but not been f*cked over during the review. If the servers had not come up I would likely have been heralded as a saint had I been able to resurect them too.
It makes no sense but my advice is don't bother with looking at meaningful metrics unless it is to satisfy your own needs. Focus on the only metric management sees... Crisis frequency and crisis resolution... be the superhero!
Re: (Score:2, Insightful)
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. M
Measuring workstation uptime (Score:2)
If the company has an IM solution, such as IBM Lotus SameTime [ibm.com], 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.
Re: (Score:3, Informative)
I remember it as being 10% of the people (whiners) take up 90% of the support time.
Re:Sliding Average (Score:5, Interesting)
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: (Score:2)
Re: (Score:3, Insightful)
There are three types of companies.
Generic
Brands with no real value
Brands with a good reputation, worthy of trust.
A Generic company honestly should not give a crap about user satisfaction. Your goal should be to spend as little $/user as possible without resulting in lawsuits. You are selling crap and people are buying it because it is cheap. They won't care about customer satisfaction, otherwise they would have bought a brand