Slashdot Mirror
Ask Slashdot: Good Metrics For a Small IT Team?
First time accepted submitter shibbyj writes "I'm a member of a small 3 person IT team for a medium sized business (approximately 300-350 employees) that has multiple locations internationally. I have been tasked with logging our performance using the statistics from our ticket management system. I've also been tasked with comparing these stats and determining if we are performing above or below what is considered optimal. I'm wondering what people opinions are on what good metrics should be in regards to mttr mtbf etc. I have had trouble finding information on this."
One of you is getting fired
Didn't we just have a story about how metrics suck?
Time to answer call, time to resolve ticket, abandoned tickets (unresolved).
If you google a few of those it will bring some more, but that's a simple start.
The price is always right if someone else is paying.
"what good metrics should be in regards to mttr mtbf etc"
Easy, there are no good metrics. Metrics don't lead to improved business outcomes, they rarely cover enough variables to tell the whole story, so all they lead to is people gaming the metrics, most likely leading to worse business outcomes.
Metrics are favoured by lazy management.
You could sure start by explaining what "mtrr" and "mtbf" mean!
Simple... if you have a 3 person IT team at a 300 employee company and your site / it infrastructure isn't in nuclear meltdown your probably doing good. Looks like they are going out of house for IT. Welcome to the cloud-future, where your job is dissolved for magic.
I'm afraid if some one is asking for metrics of three people supporting 350 in international terms does not know what the hell they are asking for or what it is that you 3 do. That being said, it can be expected you will be scrutinized over every little detail. Be careful. I won't ask, but I do wonder who you work for. I have been a similar situation and it is completely frustrating. Good luck...
You're always below optimal, by definition of optimal.
talk about flow, about bottle necks. Visualize workflow. Look at Henrik Kniberg's paper on kanban as applied to IT Ops. My guess is that your ticketing systems will provide low value data on volumes on resolution time - gear up - visualize the pipeline. check http://www.infoq.com/minibooks/priming-kanban-jesper-boeg - turn the conversation around to "business value" - don't get wrapped in the ropes of volumetrics /peace.
There is no metrics system that can't be gamed.
If you set it for "total tickets fixes" (higher=good): you just encourage people to report trivial problems you can fix easily.
If you set it for "total tickets" (higher=bad): you refuse to do things, add features etc, or you make it hard to contact IT to log a fault
If you set it for "time taken per ticket" (higher=bad): you end up pushing kludge solutions
If you set it for "user rated response" (higher=good): you end up blackmailing the end users to rate you 10/10 otherwise their emails/logs/dirt etc get published and sent to boss/wife/etc
Ask your manager how their performance is evaluated? Then start suggesting ways they could bust their KPIs, and they should get the drift.
Metrics. Excellent, I hate when bosses use the Imperial system.
All jokes aside: If you care about your job in this economic climate, I suggest you do what your 2 other teammates are doing - picking through the stats that make YOU look the best. The company isn't going to look out for you. IT is an expense to be cut, remember. Boosts the temporary bottom line, promotes "growth" in this fiscal quarter, gets the investors going so the CEO can shuffle another fold into his golden parachute. If non-important metrics are selected that sacrifice your job, it's a brief victory lap straight into the unemployment line.
We can't answer your question, though. In the end, I recommend you watch a clip from "Office Space" - wherein the Bobs interview the employees:
Bob: "So tell me, what is it, exactly, that you do here?"
If you can't answer that question, you probably should be job hunting already. Or should have kept a copy of the job posting from when you applied.
There's a spot in User Info for World of Warcraft account names? Really?
I have been tasked with logging our performance using the statistics from our ticket management system. I've also been tasked with comparing these stats and determining if we are performing above or below what is considered optimal.
Standard ticketing system metrics are no good. Add a post-incident survey to your customer interactions. Your metrics don't measure performance, unless you can actually measure how 'hard' the ticket is intrinsically / what skill is required, and how well the ticket is solved.
A good solution might prevent further issues, a bad solution might cause more issues to occur. The fewer IT support issues a customer has, the more each resolution was worth, because that indicates their problem was actually solved.
Define a new metric: "Ticket importance" = Importance level given to the issue by the customer relative to the other issues.
Define a new metric: "Customer Happiness" = Score given by the customer with the resolution of the issue, from 0% to 100%.
Define a new metric: Revenue per Ticket = Revenue of applicable IT support Service Delivered per period of time divided by average Number of Trouble tickets for that service for the same period of time.
Define a new metric: Ticket Weight = Rank of the ticket out of all other tickets issued by the service, as a percentage. 100% would indicate it's the only ticket that matters, 0% would indicate solving the ticket is not an accomplishment, e.g. wasted time
Define a new metric: Ticket worth = Ticket Weight * Revenue per Ticket
Define a new metric: Ticket resolution value = Ticket Worth * Customer Happiness.
Sum the resolution value of all the tickets solved by IT support personnel. When multiple IT persons are involved in the same ticket, calculate total hours spent on the ticket, and divvy out the 'Resolution points' based on the amount of time spent on that ticket by each team member.
Is shit broken?
Does shit get fixed fairly quickly?
Are your people busy, but not swamped?
Yesterday's Slashdot, to be exact: http://it.slashdot.org/story/11/12/14/225204/the-four-fallacies-of-it-metrics
-- This sig is only a test. If this were a real sig it would say something witty. --
..... is how much failure they have!
If shit is working, don't come bitching! Don't ask about shit you don't know shit about and do your job like you are doing yours!
- Percentage of staff with ITILv3 foundations certification: zero.
I know this because of your question. Watch thes videos as a start: http://pmit.pl/en/it-management/free-itil-v3-course-collection-of-itil-v3-moviesdarmowe-szkolenie-itil-v3-zbior-filmikow-o-itil-v3/ -- and sell a formal training course to your management.
The people joking about how one of you is getting fired, or you're all getting outsourced. . . probably true. Learning ITIL is all about learning what's important to your business stakeholders, how to monitor/measure these things, and how to make sure you're always making the right decisions based on the business priorities.
If you can't convince them to pony up for you three to take the certification course, then pay for it out of your own pocket, you'll need it to find a new job.
Seriously. Once management fall under the belief that they can have reports automagically generated for them by measuring your working habits, you will never hear the end of it. Why does X have less keystrokes per hour than Y? You only committed 15 lines of code yesterday. You must not be working. Why did this junior employee fix 100 bugs, when this senior only fixed 10? And take a look at yesterday's topic too.
1. Create your own database, with a numeric field per employee, plus a comment field.
2. Each time that employee does something stupid, enter a record with "-1" (or whatever value is appropriate) in their field. Enter a comment if you want.
3. Each time that employee does something good, enter a record with a "+1", etc.
4. This is better than just completely making up crap, since you have a record, and you can justify stuff if needed.
After all, what's a bunch of meaningless statistics compared to what you really think? All you need is a way to keep track of the latter.
And while you're all gathering metrics the real work isn't getting done. That'll help you look good. With an A-hole boss like that, you'd be better off floating your resume. Also, what definition of "optimal" are we talking about?
I've been an ISP call center supervisor and dealt with implementing goals and metrics, have worked in small IT depts, and currently working as a support engineer for business support.
Your metrics are threefold:
1) Phone metrics - this is how long people are on hold, average call length, abandon rate. Call length throw out the window. If you don't have a queuing system ignore phone metrics entirely
2) Ticket system metrics - the only important automated metric is how fast you responded to incoming e-mails. Once a month the manager should randomly select some cases are review them with a scoring system you develop. This helps determine if you are helping customers properly or spend a lot of time ignoring them, etc.
NOTE: It is useful to have ticket volume and average time per ticket from a perspective of sorting our if you need more staff based on volume, but it is not an individual metric.
3) Satisfaction surveys. These are the only one that are valid for individuals. They should be sent out after a ticket is closed, not months later, and cover a variety of topics. Low scoring surveys need to be investigated and if needed thrown out (as often a user being told "no, it is against our policy" will give all low scores when in reality the tech did their job perfectly)
In a 3 person IT dept you should know if the number of active tickets in increasing, decreasing, or holding steady. If it is increasing, you need more people. Holding steady you may be ok on personnel, but you may need more depending on responsibilities and how many hours you are working. Decreasing is good. It does not mean you should get rid of personnel though.
Hide decreasing numbers from management. Insist different issues be different tickets and that "quick 30 second question" gets recorded. One of the reasons that metrics in a small center suck is that most of you are probably doing 2-3 small unrecorded tasks for each recorded one. Management does not see this. All they see is the ticket system.
As for what is industry average numbers. There is no such thing. Each business is different and unique. You have to use historical information about ticket/case volume, active load levels, and phone call volume to generate your businesses numbers.
as not all ticket take the same time.
Do want quick password resets to count the same as doing some think that needs a more time? like setup / reload a pc?
Your ticketing system needs or needs to have added an automatic followup to the customers. The system sends out an email after every ticket asking "Did the problem get resolved in a reasonable amount of time? Did the IT staff respond in a way that enabled you to get back to work?" Nothing more complex than that, though you can parse things out by ticket priority (though deciding what's a higher priority than other things is, just by itself, a major undertaking).
Your goal should be to increase the percentage of positive responses.
Why this touchy-feely stuff instead of a hard metric? Easy. There are no metrics that work in your situation. It's quite easy to argue that there are no metrics that work, period.
By adding this email feedback to your ticketing system, you have met the requirement to come up with a metric derived from the ticketing system.
Selling this to management can be simple, depending on how you handle it. Something along the lines of "Given that the IT staff is so idiotically understaffed, we must be given the agility to solve problems instead of meeting random metrics. Only our customers can know if we met their needs, considering all pertinent factors. Someday, when we actually have enough people and money to divide work more rigidly, we can add metrics like timeliness of ticket closure, etc." Then you hope they never notice that you never divvy up the work rigidly. All of this requires having an IT manager who is dedicated to the inescapable truth - that their function is to keep the MBAs off your ass and let you do your job.
I've worked where my performance was measured in this way. It can be heaven.
One more thing - if your upper management doesn't already have faith in you, they'll never go for it. They need to already appreciate your contribution to go along with this. The very fact that they're asking for metrics tends to suggest they don't sufficiently appreciate you now. If that's the case, than all I can say is that I've worked under those circumstances, too, and my heart goes out to you.
> determining if we are performing above or below what is considered optimal
Scenario 1: you are below optimal -> you are inefficient so they replace you
Scenario 2: you are above optimal -> you are overkill so they replace you
Bottom line, I would rent The Wire and learn how to "juke the stats" because that's the only way you won't get to jump on that grenade.
Been there, done that - my advice: be just under optimal so you have room to grow and show improvement, but don't be too low so they don't feel the need to consider a business case for outsourcing.
lucm, indeed.
Optimal being 'Best possible', how does one perform above what is optimal? You are either perfect (optimal) or not perfect (sub-optimal).
you can set the goals of your stats ahead of time if you're clever. make it your goal to find many long-term problems, to ensure that your tiny department won't be axed too soon. otherwise if you show a great record of solving problems quickly, you will be rewarded by being downsized.
three comments and I am forever at terrible karma
Comment removed based on user account deletion
I'm not with most IT management on this one, but I always thought the best metric was customer satisfaction. For instance every time I open a ticket with Cisco I get a survey at the end of like 5 questions. Was my problem resolved, was the person polite, etc.
The other metrics suggested are things to graph and look at trends. Are repair times getting worse or better? Is the average time per ticket going up or down? They are great int he aggregate. They break down quickly when divided. Only one guy on your team knows network devices, so he gets all the network devices which include the 8 hour fiber cuts, so his times always are worse than the guys fixing printer problems, as an example. You have to be very careful as you start to divide them up.
At the end of the day though you're trying to make the customer happy. Track it, and see how your staff is doing. If people are happy with their IT support, your department will be seen in a more positive light.
1. make your numbers.
nobody actually cares what 'the numbers' are, or if they actually mean anything. but you have to make them.
you might ask yourself - isn't this a huge waste of time? isn't it completely counter productive? doesn't it actually decrease efficiency? aren't the metrics measuring completely the wrong thing? as the slashdot story the other day said, aren't bad metrics actually worse than no metrics, because they cause people to do inane, wasteful things to make their numbers?
well, your problem is that you are asking yourself. in a corporate environment, do not ask. just do.
just make the numbers.
hopefully, if you get good enough at 'making your numbers', you will have time left over to actually do some work.
2. but what about the theory of capitalism, the free market, efficiency, etc?
its all bullshit. just like the theory of communism was bullshit. what statistics and 'numbers' were reported to the government were just flat out garbage. people somehow managed to make the system work through personal relationships and working-around the assholse in charge. but most of the theories it was built on have no resemblance to reality. think about it - if efficiency really made for the best corporation, why would you be spending 4 hours a week filling out meaningless statistical performance reports that nobody will ever read, let alone understand?
the only difference between the soviet union and 'the west' is that 'the west' still hasnt collapsed yet.
where people are constantly calling me asking to fix stuff, then my numbers will be awesome!
god, capitalism is awesome.
The only truly meaningful metric is customer satisfaction. After each ticket is closed send a survey email to the user. If your team plows through enough tickets you get a statistically significant success % per tech that you can compare to the other techs.
Without knowing a lot more about the nature of tickets it is hard to give a better response. It might be very important to gauge the difficulty (trivial-hard) and novelty (common-rare) of tickets but it could also be a waste of time. Does one tech plow through dozens of tickets a day or a few? Are the techs specialized? Anything email related goes to joe, hardware issues to tom, etc.. Are the tickets auto-generated from emails, called in or do they fill out a web form?
Given the size of the team the company thinks 1) you aren't getting the job done, 2) one or more people on the team are dead weight or 3) you are overworked and need more people. I wouldn't bet on #3.
Falling back to metrics is a lazy manager's way of proving to her superiors that her drones are operating at peak efficiency. The most lazy of all will rely on utterly meaningless metrics such as the number of help tickets closed per day, per individual per day, etc. A metric such as this is completely useless as all tickets don't require an equal amount of effort to complete. Diagnosing a problem due to an intermittent hardware issue doesn't take the same amount of effort as helping a user change their password. Unfortunately these types of issues generally comprise the vast majority of tickets generated and therefore often end up being the ones that are 'measured. ' This often leads to a drop in morale and thereby negatively impacts performance; ironically the opposite of what the whole exercise is attempting to accomplish.
Trouble ticket data is primarily useful for detecting trends, thereby helping an IT team appropriately focus their human capital on issues that will enable their users to be more efficient. Going back to the password issue above, the speed and alacrity with which the IT staff help users change their passwords isn't a useful metric at all. A more meaningful metric would be the frequency of password change requests before and after the installation of a self-service password reset solution that was put in place in response to the analysis of help ticket data that showed that this was one of the most frequent issues and one that could be easily solved with little effort and financial expenditure. Measuring a sharp drop in password reset requests would show that the solution worked and was therefore beneficial to the organization by enabling users to help themselves, resulting in their having more time to concentrate on their primary tasks, and also by allowing IT staff to allocate their resources on issues that are less amenable to resolution via automation.
Unfortunately, in my experience, ticket systems get used to determine useless metrics such as the first example mentioned above, and therefore end up being the bane of IT staff, rather than a useful analytical tool.
While not a standard metric, consider the amount of time you spend planning and implementing upgrades to your infrastructure, as opposed to the amount of time spent supporting it. In a healthy company, the weight is towards planning and implementing upgrades to your infrastructure, where not a day passes that a new piece of equipment isn't being delivered. Why, you ask? Because it shows that there are enough people to handle the daily problems adequately, freeing up others to plan for several months (or years) into the future...to deliver a feature before it is requested, to move the network to a faster speed before you hit bottlenecks, to ensure that people spend more time completing their work on their machines than waiting for their machine to finish a task or complete an upload / download. To take time consuming, menial tasks away from the workers, and free them up to pursue tasks that might bring in more money for the company.
In an unhealthy company, you spend more of your time dreaming about upgrades. You end up taking care of old, inefficient equipment, and are stuck in meetings, trying to explain why a minor upgrade can have a large impact to a group of people who are 'too busy' to learn anything more technical than messaging on their Blackberrys / iPhones, which they do while you speak. You don't have enough people to perform adequate daily support, and plan for future upgrades (which may require several hours of research, and speaking with vendors on the phone, to get a proper quote; on top of studying new technology or attending a training course). If you've hit a bottleneck in the last several months for any feature on a computer / network, and you're not Google / IBM / someone playing with a supercomputer, you're doing it wrong.
But then, you get what you pay for. If you are a company like this, leave. The company isn't going to grow, the culture is dead, and you have a chance to short the stock before the collapse. They'll keep switching CEOs / figureheads, and merging, but that kind of corporate culture is like a virus. See what happened to HP when Compaq merged with them.
I am John Hurt.
Seriously I just have to say that this is the single funniest comment I've ever read on Slashdot. Laughing, pointing at the screen, drug my wife over here to have her read it funny. Brutal. Absolutely brutal.
From one cynical bastard to another, I salute you.
Weaselmancer
rediculous.
Customer/User satisfaction. If problems are solved in a reasonable way (in terms of time considering your workload, budget and expertise) then that's the only thing management should care about. You're not running a support call center where your job is to read solutions from pre-written scripts - you're solving real problems with real people. There is no script.
Management should be surveying their employees and your reports and work out if more people are needed to do general support. Are you finding time to do project work? If no, then maybe they need to hire somebody to keep users off your back a few hours a day while you do projects.
there is wisdom in that statement...
is it possible to perform "above optimal" ?!?
If you have to go down that path, I'd go with TAT. Simple to measure even over old data, hard to game consistently, and closely related to customer impact. If you want to, weigh it by customer-perceived severity of each request so that people don't boost their numbers by cherry picking easy tickets.
To do list for Windows
I found this gem in the other metrics thread the other day.
-2000 lines of code.
Weaselmancer
rediculous.
There is only one metric that really matters, and that is what your users think. You can collect all the stats you want, and put whatever spin you like on the figures, but if your users think you suck, then in the view of 99% of the company, you suck.
So my suggestion is; do what Cisco and other customer focused companies do, and for every ticket closed, send a satisfaction survey to the user. Don't make it long, it only has to be 4-7 questions where they rate the key things you did on a scale of 1-5, and should take the user less than 2 minutes to complete.
Then, you will have incredibly meaningful stats to show the good work you are doing. Or, you will have the precise information that shows what you need to do to get recognized for doing good work.
Just think about it., what is better:
a. For the last month there were 82.5% if tickets were resolved within the department KPI target,
or
b. For the last month 82.5% of staff indicated they were happy or very happy with IT support
The best answer is to not use tickets as your metric. I worked at a smaller company and our metric was a simple yearly user survey. We would ask what they thought of their equipment, the how the support team did (response time, niceness, knowledge, etc) and even took it so far as to ask for suggestions on what could be improved. In the end, how many tickets you close really doesn't matter. What matters is how happy your users are. If you are doing the job correctly, the majority of your users will at least be satisfied, if not happy. If the majority are unhappy, this will give you specific ideas on areas you can improve on.
"Information wants to be expensive" - Stewart Brand, the same guy who said "Information wants to be free"
1: You didn't give enough information on what you support to get an accurate answer.
2: You shouldn't be the one evaluating your own own job (see very first post)
3: Here are several common metrics which may or may not apply to your situation as they were pulled from a couple of very large corporations metrics system.
CSAT: customer satisfaction based on automatically emailed surveys
AHT: average handle time, or the time you spent on the phone resolving the issue
ACW: average call waiting or how long did they have to be on hold to talk to you
Call Resolution: self explanatory
Logging: how much did you actually log in tickets to the number of calls received.
It gets pretty granular after this with things like "overall satisfaction" "agent expertise" (you're the agent) "agent listening"
One last thing, I actually snorted reading the first post because I had an "Office Space" flash back, time to hide your red Swingline.
"If any question why we died, Tell them because our fathers lied."
Some metrics have been shown to be clear indicators of good performance in IT teams. Hopefully the following equations are clear enough. 1./ Number of metrics minus number of metrics known by employees 2./ Time in day minus time spent on developing metrics 3./ Number of metrics forgotten divided by Number of managers who care about metrics
Time to answer call, time to resolve ticket, abandoned tickets (unresolved).
In business school it is a common theme in various classes that you get what you reward, not what you ask for, not what is necessarily best for the organization. Here is a highly relevant Dilbert cartoon illustrating this point, http://dilbert.com/strips/comic/1995-11-13/.
The underlying problem is that metrics applied to humans leads to people working towards the metrics, not necessarily doing good work. It is a classic environment for unintended consequences. Its not even that the people are necessarily being opportunistic, there is also a certain amount of practicality. If you are being measured by some metric and keeping your job or getting a raise is dependent upon that metric you may quite rationally decide to act to that metric rather than what is necessarily in the best interest of customers.
Are you measured by resolved tickets? Then tickets will get resolved quickly. Not necessarily thoroughly, completely, or robustly resolved. Which leads to related followup tickets because of a minimal effort put into resolving the original ticket. I saw this in a programming environment where the tickets consisted of new features or bug fixes.
Are you measured by abandoned tickets? Then tickets will get resolved, even if they don't reasonably deserve to be considered resolved. You will get things unnecessarily classified as "unable to duplicate", "insufficient information", etc.
In these two examples, where is the difficulty of the task factored in? Not all task, tickets, are equivalent. Furthermore sometimes there are external dependencies, a part is being shipped, where is this factored in?
The metrics you offer are reminiscent of stats from call centers. There such metrics are a little more reasonable, not perfect but perhaps OK, given that the calls are somewhat equivalent in the amount of effort required, a small number of minutes not hours, and that they are randomly assigned. Over the period of say a month the large number of calls handled by any operator will resemble a normal curve with respect to effort required. For an IT organization the evaluation period may need to be some number of years to get to a normal curve with respect to effort required.
I can only imagine that most people replying with derision about metrics have never been in the position of having to justify what they are doing, and when they have been they have acted dishonestly.
People that actually work in the real world, with real companies with real budgets, and that have some self respect, honesty and pride in what they do will have to justify their salaries or rates somehow, and one of the tools used is some kind of metrics.
A professional will find metrics that are meaningful to both their team and their bosses or paymasters, and contrary to what most people are implying here, they can be quite useful to identify reasons for which a team is overworked and maybe bring somebody else on board.
It should also be pointed out that proper metrics may point to a team that is overstaffed, but an honest professional should not fear this since drawing a salary for doing nothing is frankly not my idea of a honest day's work (those people asking to make up or game the metrics simply are unethical, if you think metrics are a sham then do please suggest how you intend to evaluate obejectively if you are becoming better or worst at doing your job).
IANAL but write like a drunk one.
Yes, good metrics are useful. But you only have three employees. Don't you, I dunno, know them? It isnt hard to figure out who sucks and who doesnt when you only have two other people you work with.
Might as well close the comments now. :-)
Go look up Robert Austin's book on measurements and management. Read it and recognize that you've been given a task that is at best counterproductive and at worst impossible. Dust off your resume, because it may be more than one of you that are getting fired. ..bruce..
Bruce F. Webster (brucefwebster.com)
Nagios isn't too difficult to set up to monitor lots of things, and lots of useful uptime metrics for every service, planned and unplanned maintenance, etc. fall out quite naturally from it. And you can kinda just keep adding modules to it into it and grow it until it's full of awesome.
I haven't personally used Redmine yet, but have been using Trac and everyone seems to agree that Redmine is the clear successor in terms of lightweight but capable trouble-ticket / project / task management systems.
As a previous commenter suggested, you should use metrics that will increase the performance of the IT department. Remember, you get what you measure.
So, what you should do is this:
Use the number of tickets prevented as a metric.
Then, in the report for your boss, calculate the average amount of time that each ticket takes, and multiply that by the average hourly wage.
Then for one of the metrics you can use the amount of money each employee has saved the company.
Assuming the figures look good, and they probably will (after all, thats the power of statistics, you can make them seem to support any course of action) your boss will probably be quite impressed by the performance of EVERYONE in your department, and suddenly you all would seem more essential.
Sorry, but I'm biased. I love metrics. I hate how some people misuse metrics, but when used properly they are awesome tools.
Anyhow, you want to measure the number of calls, average time on a call, average call waiting, calls transferred, calls abandoned, service desk availability, call severity, and categorization of call. With a small shop, you need to look at what else you do outside of support calls.
Ideally, you'd use the statistics to find trends. Like say, you find a particular printer brand breaks more often than others. So you can switch manufacturers. I have never turned to statistics to fire someone. Instead I review this information to see how we can improve.
Another important factor is user satisfaction. I send out bi-annual questionnaires to our users, since perception counts more than about anything else. For help-desk, the users are the customers. So I view customer satisfaction as extremely important and tie these reviews to bonuses (not call statistics).
Finally, I would suggest you have each member rate each other and themselves.
Chances are, you don't have the metrics in place for it to accurately measure what you really need. So, I'd start with surveys of your users.
One final note, 1 IT person per 100 users is a good ratio. Anything less and you will experience downtime (or experience a high amount of outsourcing). Make sure they see what financial detriment losing a person would yield. Find out if they are looking to cut costs and if that's the case, look for ways to do that. Whether it's your cell phone bill, network bill, amount outsourced, hardware leases, etc.
mean time to resolution
mean time between failure
Check a hard drive manufacturers website and every one will list a mtbf for their drives. That one is a standard.
Determine the cost of hiring an outside consultant ($100/hr to $250/hour, depending on country and regions within that country), then show how much less you cost the company! Then again, as an outside consultant, I do the same amount of work in 4 hours that a regular employee does in 8 ;-)
Well, when they say small, I'm the sole IT worker and thus the IT Manager at a 4 server, 40 workstation business so my only metrics are: I didn't make them spend a bunch of money, nothing lit on fire, I didn't quit. That's seriously about it and this quarter, I got all but the middle one but I wasn't the one who ordered that HP workstation, nor would I have, so it's sort of a gray area lol.
Touch up your Resume', go tell your boss to get bent, pound sand, etc. and look for a new place to work. Anyone who needs metrics on a three person team deserves anything they get, up to and including a swift kick in the ass. If the manager can't figure it out on his or her own, they should be the one being sent out the door with boxes.
"My immediate reaction is "WTF? What kind of moron doesn't make things 64-bit safe to begin with?" Linus
Before you do anything else, read Robert Austin's book, "Measuring and Managing Performance in Organizations".
The points I got from the book:
1) Measuring the wrong thing or in the wrong way makes things much, much worse.
2) Good measurements are possible but take a lot of hard work.
3) Measuring things that are easy to measure is almost certainly wrong.
I also endorse BenEnglishAtHome's comment timestamped 8:55pm.
I manage a department roughly the same size for a company about the same size.
I use two main metrics to see how we're doing:
1. The IT budget should be about 3% of the total company revenue. That's pretty average for companies of this size. If you're significantly under or significantly over, you need to do some soul searching to figure out why.
2. Every year we put together a survey and ask the exact same questions. Its going on 5 years now so we can compare our performance year over year. We ask about 20 questions and score them on a scale of 1-5. Things like 'hows training?' to 'how well does your cell phone work?'
Counting trouble tickets is mostly a worthless exercise. Although, you can manipulate it to your advantage. Start closing 120 tickets this month, 140 next month, etc. When you get to 240 tickets a month you can take that graph to upper management and say, "we're working twice as hard as we were 7 months ago and need to hire someone."
In the end, you have two ways to view this: as a bullshit exercise (and possibly an excuse to fire someone as others have said) or as a way to attempt to objectively evaluate your department.
----- obSig
"...determining if we are performing above or below what is considered optimal."
optimal, adj.: most favorable or desirable; best; optimum [Webster's New World Dictionary]
How can you possibly perform above optimal?
We know where leadership by an anti-intellectual "strongman" who scapegoats minorities and likes boisterous rallies goes
There are a number of ways you can do this:
1) For the next few weeks, only deal with issues in the ticketing system that can be resolved quickly. This shows how responsive you are on the "count of problems solved" and "time to resolution".
2) Always upgrade easy problems to "Extremely Urgent", so that they get picked up first (as per above).
3) Do NOT under any circumstances touch a complicated problem that requires consideration or actual work. Find someone to outsource it to. Then blame the outsourcing costs and lack of efficiency (obviously they do not have the same fast response time as you) for the problem.
Seriously: In a 3 man team, you and your manager should KNOW who is working and who is on facebook all day. If you are all working hard, then it is not time to add more pressure by introducing metrics, it is time to hire more help. If on the other hand you are all on facebook all day - well - then good luck to you in your new job at Walmart....
Meus subcriptio est nocens Latin quoniam bardus populus reputo is sanus callidus
Any metric is open to interruption.
It comes down to what specific information you would find useful. Once you determine that, then you need to CONSISTENTLY generate metrics using the same method. Until you have historical information, it’s just a number.
MTTR and Network Reliability are more than enough to keep you busy period-to-period. I suggest one full page of information for each. It should include the core metric (current, historic, & average), a paragraph summery of significant events, and a detailed breakdown. (Class, status, category, priority, location, application, etc)
Optimal MTTR for high-availability systems is typically 2 or 4 hours.
Optimal Network Reliability for high-availability systems is 99.999% up-time.
Then YOU use this information to determine where there is room for improvement. The first thing that should stand out with MTTR is how support ticket categories and priorities are not used effectively.
Once you have consistently calculated numbers and have historical references, sharing the information with management actually has value. It provides a view into your part of the organization they can understand.
I'd suggest "MTTD" and "AQ"
Mean TIme to Douchebaggery : Have your boss recruit some internal people to call your department with simple but real problems, and act like users who don't know anything. Record how long it takes the customer support rep to start acting like a complete douchebag. Longer times are better.
A-hole Ratio: As the manager, you should really know who the biggest a-holes on your team are. Determine if that's having a negative impact on other members of your team. Calculate the a-hole benefit (Tickets Closed) vs. perceived a-hole cost (lost productivity in tickets).
Both of these have a direct impact on your department's productivity. If people are individually productive but bad for business as a whole, get rid of them. But if they are "that good", maybe you need people who can better work with these a-holes.
Can they be gamed? Sure, by being less of a douchebag, or less of an a-hole. Sounds like a win-win.
Yes, I'm being flip. And yet, not really.
...means that your team may not have enough work to go around. I'm of the mindset that having a regularly light workload is good for an IT team, so that they're available when the ^#@$ hits the fan as it eventually will, murphey's law and all. But your managers probably are not.
Some users just want to get paid while other people do their job for them. If you are doing your job properly (and have a very different job to them) you are going to inadvertantly annoy them when you eventually have to tell them to do their job themselves. There's plenty of other situations because ultimately the user is not really when the loyalty has to lie - the organisation that pays you is supposed to be where the proirities are set. Even in retail the customer is not always right, that glib bit of heart warming bullshit isn't going to save your job if the customer tries to screw the company over (eg. shoplifter).
You can make the users more satisfied by employing attractive people to break the bad news that something will take a long time to fix instead of silently and rapidly fixing it. The user may be happy but they are not getting a lot done which conflicts with where the loyalties should really lie.
With a three person team, I would measure success by how many times / month things are completely f@ck4^ up. No more than once and you're doing great.
Performing above optimum is per definition not possible. So asking for this proves the Management is acting below optimum, measured by their ability to apply basic logic.
For such a small group I think it might be a better solution to just look at the tickets, filter for those with especially high response time, for those which where closed and reopened frequently, and for those which took longest for the first reply. Based on your gut feeling what management really wants (Do they look for excuses to fire people? Do they really want to improve the system?) you would either come up with a metric that strengthens your position most or with a metric which shows the bottleneck of your service or with a list of the worst cases [not by metric, but by common sense combining the different aspects] and try to find a common pattern / root cause to improve on.
Trolling is a art!
If the question is whether you are performing above or below what is considered optimal, the answer is easy. Below. Nobody performs above optimal, and pretty much nobody performs at an optimal level. If your IT department requires three full time employees to handle 300-350 clients you aren't that rare exception unless there're a lot of responsibilities beyond supporting those 350 clients (like say if you also manage 1000 web servers).
Instead of cataloguing work that was performed, catalog how time was spend when doing work. That is, measure what is needed to improve, not easily misinterpreted stats. This will provide the information needed to increase efficiency by identifying common time wasters. E.g.:
Get stop watches. Identify high-level classifications of tickets (e.g., research, talking to person that filed, filling out paperwork, etc). Randomly select 1 out of 10 tickets as they are being assigned. Have the people record, to the minute, what they are doing for each ticket (get stopwatches, if need be). Have them record what, if anything, presented a non-productive obstacle (e.g., key information was missing from the ticket). Then compile the results.
Take this all with a pinch of salt; I'm simply an armchair analyst.
You need to reverse the metrics. Instead of looking at your performance, you identify the users and services that are negatively impacting your performance. Your current idea assumes IT demands are constant and your team is variable, but you should be thinking that you're efforts are constant and IT demands can be variable. Does the VP of Incompetence consume too much of your time asking again how to do a mail merge and initiate "projects" that make no sense and waste your efforts? Your metrics should show that he is negatively affecting the bottom line and should be eliminated. Instead of an expense you're now a "profit center".
It metrics for a any shop can be a bit tough. Its all going to depend on what upper management is considering to be optimal performance and what they value. If nothing has been framed up for you, my suggestion would be to first try and tackle this from a customer perspective. Focus in on the following metrics:
Customer Satisfaction: Create a survey that you send out to random customers in your company that ask the following questions(these are just examples):
1) Was your issue resolved?
2) Do you feel it was resolve in a timely fashion?
3) Do you turn to IT as a resource to fix your problems?
Also, it might not be a bad idea to do a little reading up on ITIL, so far as methodologies are concerned.
In short, if you take this tactic and they throw it back at you and do not consider it important then they are just trying to get numbers to support a specific action, try to figure out what that is (what exactly are you trying to accomplish?). Personally, I've always taken the stance with management, listen I understand outsourcing is always a concern if that is the case let me know so we can work together to make is successful. Outsourcing is a fact in life in modern IT, you would be surprised how far you can go with this type of attitude.
Just my thoughts...
To measure the metrics you specified meaningfully, without wasting time over analyzing you should look up Process Behavior Analysis. Its a simple yet complex way of measuring any metrics over a long period of time, allowing you to apply concepts like `Continual Improvement` to those metrics to get them to where you want. Other metrics could be per productive hour, Backlog,if you have Sev1,2,3,... and you have targets, measure % Sev1,2,3 resolved out of criteria, if you do changes, measure %failed changes, or measure the types (e.g HW failure) of work coming in to explain certain deviations in your other metrics,etc... hope this puts you on the right track
Game them to prove that you should be staffed at 6 people and not 3. The only metric that is of importance is how many tickets/issues are open. Not to be confused with projects. Often projects and system maintenance are not captured in a ticket system, and probably should not be. Ticket systems are for keeping track of open issues and to help schedule resources and prioritize. Any metrics you ween out of them are bogus and up for interpretation. For example, average time to completion. Perhaps one person is tasked with tickets that are second tier and take more time. Perhaps a problem requires a replacement part which needs requisitioning and then happens to be on back order. It may take 2 months to resolve at no fault of the IT person.
The biggest issue with metrics is that in order to hope to have and usable data, each and every tech must spend significant time documenting issues. No matter how small the issue. This means for a 5 minute task, you could spend an additional 5 minutes creating a ticket, documenting the work and then closing the ticket. And if management is trying to capture time, forget it. I have seen employers sum up the time listed in tickets and interrogate the IT worker what they did with the other part of the day, ever threaten them with pay deduction. But then when things reach that level, people game the system to prevent problem and the metrics are useless.
How many issues are open? Zero, then you are overstaffed. Is the company losing money because things aren't getting done? Either the people aren't working hard enough or you are understaffed. Any manager worth his weight, knows if his people are skilled and/or goofing off. Metrics can't tell you.
I really hope you have good categories for your tickets. One of the things the business never understands (or refuses to understand) is that a significant number of the tickets should NOT be used as a metric to indicate there is a problem with the IT systems. If someone calls you because they need access to a shared folder, that's not an IT "issue" - it's a user request. Yes, they all take your time, and they need to be counted to show the total workload - but those types of tickets should not be used by the business to say "there's too many IT issues - you suck". Of course, there are many other types of tickets that should be categorized separately from real "issues" - including user training issues, password issues, client SW requests, etc. Just because you track it as a ticket doesn't mean it's a "problem".
Also: If there are lots of "easy" things you do that are not tracked as tickets - then you're hosed. Without metrics to back-up your claim that you spend XX% of your time talking to users, you have nothing.
We are having a year long experience in ticketing and performance stats/metrics systems (i.e. Atlassian Jira in combination with Tempo, nut that is just my two cents) and I see it like this:
For a system to deliver good metrics it needs a certain time to be setup and configured according to the requirements.
No one and no system (do not believe the high-gloss printouts!) can be setup in 5 minutes.
So it all boils down to this:
The setup will take probably a couple of days until you have tweaked everything and the color scheme pleases your boss.
By that time it is clear *who* gets laid off: *the one who configured that system* !
"Why?", you ask.
Simple answer: the other two were able two handle the IT workload without the third *"who was playing arodung with new software"*.
Questions anyone ?
The question is what management want from IT. Let them define what they want and need, then you can create metrics to show them to what degree you are providing it.
There is a pretty good chance that they will be clueless.
As a sidenote: measuring the performance of a 3 person team using the ticketing system sounds pretty stupid to me. There are just not enough numbers to provide it. Do you REALLY create tickets for everything you do?
And if it is of any comfort: In our 100K employee company with a pretty well structured IT support organization, most of the the metrics are still useless. This is proven by the fact that we are asked to do/not to do certain things "because they hurt our numbers", not because it makes sense from a productivity perspective.
And while we are at it: The simplest and most informative metrics I have see on a helpdesk (this was 1st line):
- Time to pick up phone (80% to be in less than 30 seconds)
- % of tickets resolved at 1st line (minimum 75 %)
- User satisfaction survey at certain numbers
If you can't spot the sucker at the table, it's you.
--
$tar -xvf
Let him just browse through the results modded up here. There's a couple of salient details most replies seem to agree on:
1. It's downsizing time
2. a 3 man team for this company is too small... if the team isn't universally despised, they're doing fine.
3. metrics can be gamed easily, especially ticket-related metrics.
4. Using metrics seems a poor replacement for actually knowing the team and knowing how they're doing.
In other words, if we take the reactions here to be a nice average of "the industry", then "the industry"'s response to this question is that it's mostly pointless, a waste of their time better spent on IT, lazy management and, last but not least, the signal that it's time to start looking for employment elsewhere.
If that's what your boss is after, then by all means: look for employment elsewhere. If that isn't his goal, perhaps reading through the deluge of rather adversarial replies here might give him some insight into how this is perceived.
Twice you used the phrase "been tasked with". This is not the English you learned in school. Is your wife 'tasked with' washing the dishes?
There is a certain kind of lizard who embraces corporate speak, perhaps to kiss the ass of management or impress co-workers. This is a soulless sort of individual who is doomed to a lifetime of servitude.
If you reclaim your dignity, speak correctly and stand up straight you will either be respected or fired. Either way you will have found a better path in life.
...omphaloskepsis often...
It is very difficult to tell you, given the information on hand, what the numbers should be. I really depends on how complex your infrastructure is, what applications you are using, the skillset of the employees. The only metric on hand, I can think of, is a statistics on how satisfied your users are, so every time a user closes a ticket, he has to indicate his satisfaction with a number from 1-10. We did a study and found that we had an overall satisfaction of above 4, which was better than average for the industry.
Besides that I would suggest setting up some cycle-time KPI's, and then work on reducing response times at time to completion.
Place I currently work, each team/department have a set of Service Level Agreements that are set for a year. Each department has a different set of SLAs (Note this is not done at a individual level). Each monthly team brief, your SLAs are discussed. If you keep hitting/exceeding your SLAs then a review at a higher level in the organisation is undertaken to question if the SLAs that the team/department set are too easy or not relevant any more.
It seams to work.
I don't understand how you can get any useful metrics from helpdesk tickets without weighting the tickets based on the complexity of the problem.
I work as the lone IT guy in an SME (100+ employees, 2 sites, a bunch of servers and 50 odd desktops, 30 odd laptops and anything else that is vaguely IT related) and have been asked to produce reports on tickets. I had to explain that I only open tickets for problems that take longer than 10 mins or so, or problems that are more complex than expected, or are recurrent. I don't open tickets for all the regular work like checking backup jobs, patching and updating, reading email alerts etc.
So it seems obvious to me that if you ticket every single fault, and you are trying to produce metrics based on those tickets then unless the resultant work carries a score based on complexity you aren't going to produce very useful metrics. I would be tempted to guess at a weighting on opening the ticket and then again on resolution, have those tickets peer reviewed (by the other helpdesk techs) and take an average. So if you resolve 20 tickets a day and the problem is simple the weighting should reduce the value of each of those tickets, but if you spend all day on a really awkward problem then the weighting should make the value of that ticket equal about the same as closing 20 tickets in the same amount of time.
Implementing such a system would take a lot of work which I'm sure could be better spent on /.
Nice piece, i remember looking somewhere else to do with this. Made me want to do another search in yahoo for more info and found your blog post. Great piece
As other have stated, you company and your department are unique. The only criteria is: does anyone complain? Does IT hold up new products/expansion? If the answer to both of those is "No", then there is no problem. Carry on.
Any metrics you collect will be totally pointless. Work for a company of morons? All tickets will be simple "How do I turn the monitor off?" types and solved in seconds. This makes you look good. The users will like you for helping them.l
Work for a company of technical literates? Any tickets they raise are bound to be utter bastards that take weeks of investigation/implementation because the user will fix most issues themselves. This makes you look bad but the users will still like you for not getting in their way.
So perhaps there is one metric: how many complaints has the team received and what action was taken to resolve those complaints?
Also, I'd look at updating the CV and begin to look for a new job. Better to leave than be pushed (unless voluntary redundancy is in the offing)
At the end of the day stats are used to compare people.
Why not take a 'free-market' approach:
Have people 'bid' points for tickets and the lowest bidder gets to do the work.
When they complete the ticket they get the 'points'.
This way how 'hard' a ticket is 'priced' in and people tend to do the tickets that they are best suited to.
Sig (appended to the end of comments you post, 120 chars)
Use this opportunity to show that you need 10 people!
Around 2002, my team had 15 people for a company with 65,000 employees. We were always behind and couldn't find qualified help at the current rates being paid. There was a 4 yr backlog of projects.
By using metrics, we showed that more people were needed. We got them.
We weren't "IT", so our metrics don't really help you. Look up "IT Operations" to find those. However, with a team so small, there's a point that you can't go smaller without losing critical skills and capabilities even if you are 100% *nix shop. I've worked at tiny companies (3 people) and some of the largest (over 120K employees). If there's a need for an "IT" department, then it probably needs 3 people. It may be possible to have 1 full-time and 2 consultants to save money. I dunno.
Like everyone else here says - someone will be fired. If you want to make a point, leave and then the company will quickly learn how important YOU were.
Measuring performance. Leave the company, there's erratic reasoning behind such an idea - so the first post really nailed it.
Work with improvements and measure to pinpoint what could be good to improve, and if the improvement did work.
O RLY?
This is your statement, only with proper grammatical structure. So much nicer, huh?
I agree! The worst part about this that I've personally seen is that the (needless/unethical) termination of employees seems to have no effect on the upper management's future career path at all!
A while back, the CTO of a small development shop basically ran the whole gig into the ground (due to his own negligence [implication]), resulting in 14 people getting laid off. He was so incompetent that he himself was even fired ("laid off") on the spot. However, that didn't stop him! Years later he walks into my new place and ends up becoming *my* boss, complete with a fat salary and a lot of confidence from the bean counters.
There's no justice in the world! My sense of optimism/justice is certainly not helped by the fact that when you are in upper management, it seems that you aren't really "fired"; you are just "asked" to consider resigning.
Talk about frustrating!
Did you miss on this one?
http://www.google.es/url?sa=t&rct=j&q=bad%20it%20metrics&source=web&cd=2&ved=0CDwQFjAB&url=http%3A%2F%2Fit.slashdot.org%2Fstory%2F11%2F12%2F14%2F225204%2Fthe-four-fallacies-of-it-metrics&ei=QDjrTtaEKYufOqKw8asI&usg=AFQjCNHSyBkJ3WIN3Ii2ypE9Ga4b0Er0nA
If the overall work gets done, it's ok. If the work doesn't get done and there is an acceptable reason, it ok too. Otherwise it's not ok. There are always people that are better at one thing than others, but that doesn't mean the other people don't contribute other things, which you forget to measure. When the team is too big you should look at essential knowledge/experience, contributions to the team, etc. to figure out who to drop.
Metrics, like statistics, can be manipulated to appear to show many different things.
Surely there's some way you can dream up a metric that says you're all overworked and need to hire more people?
Just a thought
... and today's pet project has
What a tragic waste of time and resource. Use the time you're supposed to be gathering metrics to look for a new job.
I noticed that a lot of people seem to submit recommendations about your interaction with customers, but you could be also servicing the servers and network. If that's the case then add in there the number of outages that had no impact to the users. A power supply in a server went down, but the server had dual power supplies and no one noticed. Someone had a good idea at convening management to spring for that extra money. You connect your access switches with dual links and one of them went down?
If your going to collect metrics, let them know how much downtime the company avoided because you guys did your job. I've seen too many bad metrics around how much a person caused the company, only to find that 80/20 rule ended up biting them. 80% of the work was done by 20% of the workforce so all the murphy law scenarios only hit a limited number of people because they are the ones that did all the work. While all the people that sit back and did nothing reap'd all the metric glory.
-- Ed Bugg --You have freedom of choice, but not of consequences.--
"I'm a member of a small 3 person scapegoat team for a medium sized group of sociopaths (approximately 300-350 employees) that has multiple execution locations internationally. I have been tasked with building some gallows using our own intestines. I've also been tasked with ensuring the noose is the correct fit for my neck and determining that each of the 3 nooses are optimally aligned with the height and weight of the 3 team members. I'm wondering what people opinions are on what is the real reason we're being asked to do this is and what good metrics should be in regards to rope length, time to kill etc. I have had trouble finding information on this."
This is the kind of crap that happens when companies with a crappy business model start realizing that they are spending more than they are making and begin making cut backs under the pretense of "efficiency".
Try to leave on your own terms if you can, rather than have the rug swept out from underneath you.
"Don't be so humble - you are not that great." - Golda Meir
Although you can get metrics from your call tracking system, Customer Surveys are a better judge of performance. Don't get me wrong, measuring the ability of the IT department to document stuff has its place but in the end you want to measure how well they are doing their job. Their job includes more than just the ability to write up a ticket.
"I myself am made entirely of flaws, stitched together with good intentions."
I think it is because IT doesn't have teeth, has no political leverage, and they have real skills which make people jealous. They are going to fire someone and expect everyone else to work harder.
Democracy Now! - your daily, uncensored, corporate-free
if you're above optimal you need to redo your calulation...just saying
I was recently involved in putting together a small team to provide MIS reporting in an area where there's never been an MIS team, or any decent kind of metric other than volume, and identified mistake, before. Important how to define mistake, as they are often lagged, by days, months, or years, yet somewhere down the line a financial impact is identified. How is your team structured, how did you tailor the structure to the task?
The team consists:
In the above we tried to keep redundancy in key skill set for the task, mainly utilising our required Office packages plus SQL which I didn't mention but some have, while mixing it up with some strong skill flashes in all that can let them have an individual impact. Hopefully we'll tread new water and everyone will do well. Key is, did you and/or OP think how to structure your team, or were you just 'selected' as an existing team to fulfill a new task?
Firstly, with such a small team, I would focus on team metrics rather than individual. Also, with any given metric, be sure that EVERY aspect of that metric is directly controlled by your department. If anybody else can impact the metric, it's not a valid measure for your department. Finally, keep them as simple as possible, they are useless (and possibly detrimental) if they are difficult to understand, or worse yet, easy to misinterpret.
At our company (similar size) we use Jira for ticketing. I use the VertygoSLA plugin (hope nobody's offended by the free plugs for these products, I have no affiliation with either). Then we created levels of impact (productivity impact, and how many are affected) on the company, and assigned acceptable response and completion times for each level of impact.
To keep it brutally simple, we just track % responded and % completed within the SLA time. The VertygoSLA plugin allows the times to be automatically "frozen" if we need approval or more information, or if the case is put on hold for any reason.
What gets measured, gets done. The problem is not metrics, the problem is POOR metrics.
In case you missed it, here is the link to the story.
If you want the article itself, there ya go.
Having read that article, and the ones the author links to, it is quite clear why IT, and business in general, is in such shambles. People want to continually measure things, but they don't know what they want to measure.
I hadn't realized it, but I have been saying the same thing the author of the article said for some time: what is your goal? I use this quote from Seneca:
If a man does not know to what port he is sailing, no wind is favorable
This simple phrase should apply to every project, every metric, every everything. What is your ultimate goal? What do you want to accomplish? Only then can you answer the question: how do I get to that point.
We will bankrupt ourselves in the vain search for absolute security. -- Dwight D. Eisenhower
Initially your small group of IT support worked like this:
"Hey, I can't get the frammit to modal on my machine."
"Let me take a look. OK, fixed. You needed the clugal plugin. This is how you use it."
Now management wants to track metrics:
"Hey, I can't get the frammit to modal on my machine."
"You'll have to submit a trouble ticket."
"Trouble ticket assigned"
"Problem identified. User is trying to use a function he does not have software for, a clugal plugin."
"Close Ticket."
"Wait, what about my clugal plugin?"
"You'll have to submit a trouble ticket."
"Trouble ticket assigned"
"Clugal plugin installed."
"Close Ticket."
"So how do I use this plugin?"
"You'll have to submit a trouble ticket."
"Trouble ticket assigned"
"User training provided for plugin."
"Close Ticket."
METRICS: Resolved three trouble tickets!
It's a trap!
I also work in a small company with two staff in IT. Myself and a web developer. We do use metrics to report to upper management how well systems are running. What I've done is create an excel spreadsheet with all of the systems we have running, the licenses, version and comments for each system. We then assign that system a 1 to 5 score and average the total at the end for a total composite score. One is if there are no problems, five is for serious issues. I generate this spreadsheet every month and send it to my boss. The other Major part to a small operation is customer service. In a small company, how happy your end users are imho more important than if the systems are running perfectly. We have to market ourselves and make sure we are available if anyone needs us. Being personable and friendly is very important. A final point of advice. Please don't make the metrics too complex. Management may be looking to let somebody go. However, they also may be looking to see what needs to be fixed and/or improved for capital expenditures. Metrics help track trends and you can use them to get the equipment and/or programs you need if you design them correctly.
... "number of * between anger management episodes"?
*Days, hours, minutes as appropriate.
Bukowski said it. I believe it. That settles it.
I worked in the field of performance metrics for almost 10 years and my work was never been geared toward getting people fired. I've worked as an internal and external consultant assisting departments in establishing meaningful metrics and targets so they can monitor their performance. Departments and individuals can then modify work practices and see the effect that these changes have. They can conduct small scale experiments and use the results to bolster a case for funding. They can ensure that the important things get done and extrapolate the effect of poor performance and provide means to mitigate those effects - so there are lots of good business reasons for measuring performance other than figuring out what person to fire.
My interpretation of the OP was to compare this small IT department's metrics to some industry benchmark - not to compare the performance of one employee to another. All the commenters telling this fellow to dust off his resume might be right on, but I can tell you this isn't always the case. There is a website (I'm not affiliated in anyway) called kpilibrary.com (KPI meaning Key Performance Indicators) and they have aggregated data from their user base which may yield some useful information. I think you can indicate the size of your company and industry to get more comparable metrics. You'll never get a perfect comparison - but it's a starting place. Hope this helps.
Metrics measure tasks. In a small IT department, your tasks are less specialized and you have more duties. Working for a large (100+ people) IT dept, I have a very specific job. In a small IT dept of my past employment, I did a little bit of absolutely everything. The work that it would take to quantify each different type of task against every other based on demand and usefulness would probably cost more than the money saved by firing someone if you want an accurate metric. It's something that has to be studied over long periods of time, and is constantly changing as the company changes (so by the time you get your answer, it may be incorrect). It may be easy to measure metrics for someone who writes Crystal reports all day, but it's not as easy to measure metrics for someone who is a Analyst/Admin/Helpdesk/Developer/WorkstationTech/InventoryControl.
Find out which ones are important to the business - start counting them. Create a pipeline of system improvement projects - work on them. Document everything you do. The gods will smile upon you.
Simple solution, write a report, but spin it as overtaxed IT and blame problems on inept / unsupportive management.
Metrics aren't bad, it is how they are misinterpreted and misused that can be good or bad. I'd suggest creating automated ways to track as many metrics as you can, and sharing only ones you want, when you are ready.
For you, they can be used to further certain agenda items. For example:
- Remote office X is creating abunch of cruddy tickets. They accounted for 10% of the tickets, but 50% of the effort due to unclear descriptions and not trying to reproduce the problem.
- We have spent 25% of our effort on IE6 issues over the last month. Even though IE6 is installed on 1/20th of the machines, it is taking up a disproportiate amount of our time. I strongly recommend we officially stop supporting IE6 and move to a more modern browser.
These are just a few we track. Each member of the team has access to these. I dont use them as goals, but instead we review them as a team when we are concerned there is a problem. Understanding and being able to measure some of HOW your work helps you understand if you can make improvements.
- Tickets opened by user / department (who is creating the most workload for you?)
- Avg Ticket Lifetime (how long is the average ticket open?)
- Avg number of tickets in queue per day, over time (is work / backlog increasing or decreasing?)
- Avg number of tickets that get returned to the IT queue (we measure this 'roughly' by the number of tickets that have more than X responses from IT staff) (this could be an indication of not completing the work correctly the first time)
- Avg time spent per ticket (we have seperate field to track time spent working on issue since last note) (allows for stats, it takes us roughly 2 days to complete 4 hours of work on a certain type of ticket)
- Avg time spent per ticket per creator (allows me to clearly identify certain teams as creating bad / time wasting tickets)
- If you set ETCs, # of tickets that missed ETC (broken down by team member so you can work on setting better ETCs, training, or teaching them to ask for help instead of beating head on wall)
There are no industry standards for this. Small IT teams probably do alot of different things. I also don't know how your ticketing process works. I also don't know what your IT staff does. Do you code? Do you run servers? Do you do desktop support? Set up phones? Im a DBA.
This is what I would do. Give them what they think they want.
1. start opening tickets for just about everything you do. Even trivial things. Do them, write when you do. Then close them immediately. They probably rate this on how long they are open. So the narrower the ticket, the less time its open.
2. always greatly over estimate how long it will take to get something done. this way you can't be late. Do not come in too early or next time they will make the timer shorter.
3. require as much work as possible to be done through tickets. Don't respond to alot of email questions. You need tickets. Don't answer too many questions. Tickets again. If you need tickets to determine how well you are doing, then tickets they will get. If you close less tickets because you are helping people who don't open tickets then, you need to stop doing this. Yes, I know this slows down productivity, but you need to perform to the rating system.
4, find a way to make stuff up about industry standards. Find some standard. Find some way to make it look like most people do a horrible job. Show how you guys are GREAT. This is vague, because I don't have a clue how to get an industry standard. There are not any.
5. Prioritize managers and people who have visibility to senior managers. Make regular people wait, the managers need to come first. Make important things wait, the managers need to come first. Drop what you are doing to help executives. Make sure to create tickets and lots of them for it. You need to look like you are getting work done more than getting work done.
My point was that a "satisfaction metric" is almost useless unless applied as how satisfied their direct management is with their performance after considering several factors. In such a case it's not a single metric anymore.
Outside of very well defined situations it is not easy to come out with measurements that can effectively describe a situation to people with no grounding in the field they are trying to manage. "Metrics" are no replacement for IMHO the more effective management style of asking somebody with a clue how things are going, even if that means passing messages up and down a tree.
Since the entirety of this thread is a circle jerk for the coders that don't understand the need for Architects, Project Managers, Directors and CIOs. I thought I would give you my thoughts on this subject from the Director level.
Given the size of your employee base and only have 3 IT people, I am going to assume that its strictly a help desk staff.
Finding useful metrics for management outside of IT is a pain and always will be, but for my own benefit as management IN IT, here is what I have found helps me make decisions or determine the success/failure of a decision or plan.
Make sure the categories in your help desk are detailed enough to get you metrics that matter first off. For example:
Software => [ Office 2010, JabberIM, CustomerCRM, ect ]
Hardware => [ Networking, VOIP, Harddrive, Ram, ComputerGen, ect ]
Metrics like "total open tickets" or "closed this month/week/day" ect are not very usefull to me. I usually want to see "average time to close" or "average response time". I want to see how long it is taking for the help desk to respond to tickets of varying severity, and how long the resolution of the tickets take. Then when looking at those over the long term, you want to see trends. For instance, I would be concerned with seeing Hardware tickets for workstations trending upwards in the time it takes to resolve them. If I compare it to the trend for the number of tickets opened in that category and found that they have not increased, but time to resolve them has, then it tells me that either more training is needed for my help desk people to fix them. Or the tools and diagnostic software they are using is not sufficient ect..
If I start seeing upwards trends in both tickets opened, and time to resolve them in all categories, then maybe I am understaffed? Maybe the conversion to Office 2012 from 2010 is slowing it down all other categories cause they are tied up with those.
Overall though, yes, unless you have an IT minded manager,director or CTO/CIO reviewing these, the stats will be meaningless. Because a lot of IT knowledge will need to go into the metrics to properly interpret them and make management decisions based off of them.
By being asked this, this is a good thing! Take the time to put together these stats, but go ahead and put some explanation in there. Show management that you can interpret the stats and explain the good/bad of each of the stats and what they mean. KISS KEEP IT SIMPLE STUPID. You get into IT management positions by not only understanding the tech. But by being able to CLEARLY AND SIMPLY explain it to the rest of the execs.
This is something that a lot of coders and other techs DO NOT GET. Blabbering IT speak to management is the dumbest thing you can do. You need to break it down for them, find real-world analogies to explain what you are trying to describe. If you can break down the issue into simple conversation that makes sense to management.. You'll be moving up the ladder before you know it. Its dangerous to hide these metrics, to complain about them or to make them too complicated for NON IT management because then you are just inviting yourself to be fired and replaced with outside contractors.
We had a new IT director show up a few years ago that came around to talk to everyone about their hopes and dreams and all the rest of it. Because he cared about us as people. Shortly after that the IT department shrunk by a third.
It's Friday. I took the night off. I will be VPNing in tomorrow to do a bunch of stuff. I have to go in on Sunday to do a bunch of other stuff I can't do remotely.
Fuck this shit.
Having had the delightful good fortune of being the 'it manager' of a 300-ish person company I will tell you that when you have 3 people, there are no meaningful metrics. Work load is too elastic and with a 10k user company, there won't be enough context in which to evaluate any metrics anyhow.
The questions are instead answered with common sense :
- Do my people have good work ethic?
- Do our solutions work, and are we encouraging best practice?
- Do we do what the business needs, in time to meet the businesses goals?
- Are the people paying the bills happy?
And that's all you can do. Trying to evaluate SLAs, ticket closures, and other non-statistics won't produce anything meaningful.
For what it's worth, after 20 years of this business most of the stats I've seen from big businesses (100K + employees) were worthless at best and downright misleading at worst, where notoriously bad employees were actually able to game the system by cherry picking easy-close tickets, refusing to give their names when customers with hard issues called, hanging up on users, and not creating tickets when issues required followup to avoid having long ticket times. Those people end up getting rewarded, which demoralizes everyone and encourages defection.
Unfortunately, in an absence of common sense and connection to the work, management refuses to admit their lack of competence of judgement and would rather tout metrics as a serious tool.
"No good deed goes unpunished"
Give upper management a metric of how many issues you actually solve, including the ones where you close the issue right after hanging up the phone. You management will probably be flabbergasted and shut up about any more burdens of measurement. Don't bother about trying to show which person closed most issues, it just makes your performance worse. In a well working group, there will be some people with skills to deal with the nasty troubles and some who zip through the simpler oes. Both types are needed, and measurements on an individual level may ruin the total performance of the group.
Acoustic perception, fine motor skills, attention, memory, creativity, hand-eye-coordination, in addition to sound-memo and arranging the musical scale, you can also play songs and combine colours with tones. On the other hand ,there are lots of alternative to play, but on the other, there is enough room for own ideas and melodies. www.bangtoysmall.com It's the right toys malltoys shopnovelty toy toy store !
It's the right Maternity Fashion,Pregnancy Fashion,Pregnancy Dress,Maternity Dress,Fashion Accessories !
1 IT person for each 100 people they are supporting. Make sure when entering the amount of time worked on tickets it equals at least 80% of the workday. Average production of a worker is actually about 70 to 75% of the day. The remaining time is typically spent on research, admin, etc. Include in your time on your tickets all the time spent researching a problem, waiting on hold for a SME/Vendor support, etc. Also ensure they know that if there are only 2 of you the probability of lack of support at any given time will go up. One person is sick and the other has a doctor appointment or goes to lunch, etc. there is zero support during that hour or couple hours. Hope this helps. Oh and let us know what your new job is. Merry Christmas!
The Thing is.