Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Businesses IT

Ideal, and Actual, IT Performance Metrics? 321

Posted by timothy
from the spin-the-dial-shake-the-8-ball dept.
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?"
This discussion has been archived. No new comments can be posted.

Ideal, and Actual, IT Performance Metrics?

Comments Filter:
  • 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.

    • by cbiltcliffe (186293) on Tuesday June 16, 2009 @12:40PM (#28350367) Homepage Journal

      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++ (Score:5, Funny)

    by korbin_dallas (783372) on Tuesday June 16, 2009 @12:03PM (#28349637) Journal

    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)

      by rednip (186217) <rednip@NOSpam.gmail.com> on Tuesday June 16, 2009 @12:26PM (#28350089) Journal

      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)

        by elrous0 (869638) * on Tuesday June 16, 2009 @12:49PM (#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++ (Score:5, Insightful)

          by Aladrin (926209) on Tuesday June 16, 2009 @12:52PM (#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++ (Score:5, Insightful)

          by SomeGuyFromCA (197979) on Tuesday June 16, 2009 @12:53PM (#28350615) Journal

          [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)

            by QuantumRiff (120817)
            [ADMIN] You failed to protect the data of the sales team. we were compromised, you bastards... Its your job to make sure of that...
            • 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.

          • 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)

            by Sinbios (852437) on Tuesday June 16, 2009 @01:51PM (#28351553) Homepage

            [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)

              by Anonymous Coward on Tuesday June 16, 2009 @02:43PM (#28352365)

              [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)

                by Culture20 (968837)

                [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

      • by bigpat (158134)

        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)

        by Archangel Michael (180766) on Tuesday June 16, 2009 @12:52PM (#28350599) Journal

        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)

          by Kozz (7764) on Tuesday June 16, 2009 @01:30PM (#28351213)
          Here's the short version: "Fast, cheap, accurate. Pick two."
    • 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.

    • by Anonymous Coward

      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

  • obvious (Score:3, Funny)

    by spikedvodka (188722) on Tuesday June 16, 2009 @12:03PM (#28349651)

    Customer Satisfaction, and pro-active problem solving

    • Re:obvious (Score:5, Insightful)

      by fictionpuss (1136565) on Tuesday June 16, 2009 @12:30PM (#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: (Score:3, Interesting)

        by bigpat (158134)

        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)

          by Bluesman (104513)

          But password resets should be self service and at some point they are going to be.

          No security problem there!

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

    • 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

  • by IntricateEnigma (148093) on Tuesday June 16, 2009 @12:03PM (#28349659)

    ...by the number of callers left alive at the end of the day.

  • by molecular (311632) on Tuesday June 16, 2009 @12:04PM (#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.

    • by Darkness404 (1287218) on Tuesday June 16, 2009 @12:13PM (#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.
      • by daem0n1x (748565)

        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)

      by khasim (1285) <brandioch.conner@gmail.com> on Tuesday June 16, 2009 @12:13PM (#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.

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

        • by rjstanford (69735) on Tuesday June 16, 2009 @12:27PM (#28350119) Homepage Journal

          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.

          • by hedwards (940851)
            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.
        • ...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

          • ...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 i
      • by molecular (311632) on Tuesday June 16, 2009 @12:27PM (#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.

      • by The Moof (859402) on Tuesday June 16, 2009 @12:39PM (#28350345)
        Every time accounting asks "Why are we paying these guys, they don't seem to do anything," you get 5 points.
      • Re: (Score:3, Informative)

        by haruchai (17472)

        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)

        by RingDev (879105)

        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)

        by sumdumass (711423)

        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

    • by starglider29a (719559) on Tuesday June 16, 2009 @12:14PM (#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."
  • by Darkness404 (1287218) on Tuesday June 16, 2009 @12:07PM (#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.

  • by gestalt_n_pepper (991155) on Tuesday June 16, 2009 @12:07PM (#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.
  • Now pay attention (Score:4, Insightful)

    by JamesP (688957) on Tuesday June 16, 2009 @12:08PM (#28349743)

    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)

      by dkleinsc (563838)

      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)

    by Ltap (1572175)
    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.

    • by rednip (186217)
      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.

  • by hyfe (641811)

    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

  • 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

  • by goldspider (445116) <ardrake79 @ g m ail.com> on Tuesday June 16, 2009 @12:14PM (#28349857) Homepage

    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)

      by Colin Smith (2679)

      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

  • by Saint Stephen (19450) on Tuesday June 16, 2009 @12:14PM (#28349861) Homepage Journal

    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.

  • by Anonymous Coward

    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)

    by NonSequor (230139) on Tuesday June 16, 2009 @12:14PM (#28349867) Journal

    There's one metric that can capture everything:

    Bits of Shannon entropy processed per hour.

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

  • ITIL (Score:5, Informative)

    by prakslash (681585) on Tuesday June 16, 2009 @12:17PM (#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 [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].
    • 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)

        by neurovish (315867) on Tuesday June 16, 2009 @01:35PM (#28351273)

        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.

  • 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.
  • 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.
    • by thewils (463314)

      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.

  • by xs650 (741277) on Tuesday June 16, 2009 @12:17PM (#28349937)
    Management gets the behavior that it rewards, not necessarily the behavior that it pretends to ask for
  • by Anonymous Coward on Tuesday June 16, 2009 @12:21PM (#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: (Score:2, Informative)

      by Cerberus7 (66071)

      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.

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

  • 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!
  • by joeyg1973 (1199299) on Tuesday June 16, 2009 @12:25PM (#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.
    • 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)

    by sexconker (1179573) on Tuesday June 16, 2009 @12:29PM (#28350151)

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

  • by King_TJ (85913) on Tuesday June 16, 2009 @12:29PM (#28350157) Journal

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

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

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

  • 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

  • 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.
  • by mario_grgic (515333) on Tuesday June 16, 2009 @12:44PM (#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.

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

    You need to do both.

  • .recount toggle
  • by hellfire (86129) <(deviladv) (at) (gmail.com)> on Tuesday June 16, 2009 @12:51PM (#28350573) Homepage

    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)

    by travisb828 (1002754)

    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)

    by Aladrin (926209) on Tuesday June 16, 2009 @12:58PM (#28350715)

    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.

  • 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)

    by kenp2002 (545495) on Tuesday June 16, 2009 @01:16PM (#28351027) Homepage Journal

    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.

  • by gwn (594936) on Tuesday June 16, 2009 @02:43PM (#28352363)

    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!

No one gets sick on Wednesdays.

Working...