Ideal, and Actual, IT Performance Metrics?

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

Comments

When testing a new blade server install...

[RyuuzakiTetsuya]

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

our best is 12.

Re:When testing a new blade server install...

[MyLongNickName]

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

Re:When testing a new blade server install...

[cbiltcliffe]

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

[korbin_dallas]

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

go figure.

Re:No cnt++

[rednip]

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

[elrous0]

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

[Aladrin]

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

[SomeGuyFromCA]

[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:No cnt++

[QuantumRiff]

[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:No cnt++

[Sinbios]

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

[MushingBits]

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

writes up reasons for reluctance with clear worst case scenarios, makes admin sign off and keeps multiple copies.

*does it*
[sales] yaaay!
[Admin] Damn IT.

Shit hits the fan, IT is blamed.

Paperwork is whipped out, meeting held with all parties simply to ask how this can be avoided in future, let PHBs dangle in their own rope without saying more

Needless to say there will be multiple later-rinse-repeat cycles until learning occurs.... but it usually does eventually.

Re:No cnt++

[Anonymous Coward]

Right, right. Because IT people are going to be more persuasive than SALES people who make their LIVING persuading people.

It's far easier to get someone to say "yes" than it is to tell them that what they're doing is fundamentally wrong or broken. You can only sugar coat so much.

Re:No cnt++

[Anonymous Coward]

[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:No cnt++

[Culture20]

[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 $$$$$ when (something that is a huge security risk) is exploited.
[Bad Administration to IT] We _WILL_ lose $$$ if you don't do it. Forget it. FU. You're fired for being a recalcitrant douchebag. We'll hire someone who will do it for less money than we pay you.

Re:No cnt++

[Culture20]

How quaint. You think IT gets invited to meetings and is allowed to present documentation in their defense.

Re:No cnt++

[Archangel Michael]

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

obvious

[spikedvodka]

Customer Satisfaction, and pro-active problem solving

Re:obvious

[fictionpuss]

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

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

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

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

Re:obvious

[bigpat]

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

But password resets should be self service and at some point they are going to be. At which point our Service Desk metrics are going to get screwed up because suddenly we will have far fewer calls but the average time spent per call will go up. Depending on which metrics management has been caring about, this will either be understood as an overall improvement or will be misunderstood as some negative change in the quality of service.

It takes some management understanding to make sense of metrics, otherwise if you have management which is out of touch with operations then you are going to have problems.

Re:obvious

[Bluesman]

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

No security problem there!

Re:obvious

[Sj0]

No security can withstand the incredible power of having huge balls.

I think it should be measured...

[IntricateEnigma]

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

count tickets never openend

[molecular]

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

Re:count tickets never openend

[Darkness404]

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

Re:count tickets never openend

[starglider29a]

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

Smart users vs stupid ones

[Darkness404]

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

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

Not QUITE the stupidest metric I can think of....

[gestalt_n_pepper]

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

[JamesP]

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:Now pay attention

[dkleinsc]

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:

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

[Ltap]

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.

Sounds good to me.

[khasim]

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

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

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

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

Re:Sounds good to me.

[molecular]

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

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

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

Re:Sounds good to me.

[rjstanford]

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

Re:Sounds good to me.

[The Moof]

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

Re:Sounds good to me.

[haruchai]

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

Re:Sounds good to me.

[RingDev]

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 useful to view them as a trend line with notations as to deployment dates and business factors that lead to peeks in errors per usage. But the over all trend should be a downward slope as the software matures.

I don't know if I would directly compare numbers from one app to another, but after a sufficient period of data collection, you should be able to identify goals in error per use performance and determine if one application is ahead or behind the curve.

The goal in my case is to try to negotiate the replacement of old VB6 applications that have higher error per usage rates than their modern cousins. But I won't have the data to back up my theory for a while yet :(

-Rick

Re:Sounds good to me.

[sumdumass]

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 normal day, it would be 200 point average. I then rated the different applications and services they used based around how long they were in it and weight them appropriately. Something like the accounting app might be 40 because 30 percent of their normal workload is using it and they might need information from it to accomplish another 10 percent of their workload. Not sending faxes from the PC or IE not allowing them to shop for new shoes online was a 5. The IT ticket was 100 for anything done. And all this was divided between a normal shift of 8 hours to get an hourly rate.

Anyways, when something broke, lets say email and it effected 2 users which need it for 20 percent of their work. Suppose they were off line with it for 3 hours and it turned out that IT fixed it within an hour after being able to allocate resources to it (let's say someone sent a large email to these people which kept locking up their email clients and the solution was to copy the email out of their accounts, delete it inside it and allow them to open it externally with some other viewer). Lets also assume that an update would have fixed the email client's preview feature and it wouldn't have been locked up if updates were installed. Ok, so the costs would be the 200 x 2 employees divided by eight to get the per hour cost then multiplied by 3 hours, 200*2 /8 *3 for 150. the email was 20 percent of their work so 150*.20 drops it down to 30 points. It took IT one hour so now it's 130. If preventative maintenance could have discovered the issue with the preview and certain types of large emails and applied the patch before the user was interrupted and was able to do this for less then 130, then it benefits to do the maintenance. It's hard to justify and compare if the user isn't effected, but after they are, then it goes.

BTW, I picked an email client update because something like the scenario I described wouldn't be included in an automatic update from MS as it isn't a security risk, The PM would be looking through the non security related updates availible and applying them periodically as their organization's requirements dictate.

Develop an SLA w/ your company

[goldspider]

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

Not good to count number of tickets

[Saint Stephen]

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

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

in my government job

[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

[NonSequor]

There's one metric that can capture everything:

Bits of Shannon entropy processed per hour.

Re:Ah the age old quantify IT...

[Cerberus7]

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

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

ITIL

[prakslash]

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

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

Re:ITIL

[neurovish]

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.

Worked at a place like this

[Publikwerks]

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.

Management get the behavior that it rewards.

[xs650]

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

Re:Metrics keeping Managers employed since ....

[rasper99]

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

Metrics = Manager is getting a bonus

[Anonymous Coward]

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

Re:Metrics = Manager is getting a bonus

[Cerberus7]

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.

Re:Sliding Average

[Lumpy]

Problem is most PHB's CANT understand that.

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

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

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

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

How quickly can you close calls?

[randomnote1]

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

This is why the IT department is always cut first

[joeyg1973]

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

Ideal and Actual

[sexconker]

Ideal:

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

Actual:

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

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

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

Time to close tickets is 1 factor, not the ONLY 1

[King_TJ]

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

Customer Satisfaction Surveys.

[wonderboss]

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.

From a business point of view...?

[BlueKitties]

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

Just count yourself lucky...

[mario_grgic]

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.

IT should be focused on "customer service"

[hellfire]

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.

Exactly!

[Archangel Michael]

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!

[lukas84]

I prefer answering "Yes, of course! I'll send you a quote in a few days".
Makes people shut up fast.

Re:Exactly!

[Kozz]

Here's the short version: "Fast, cheap, accurate. Pick two."

Re:Exactly!

[Archangel Michael]

The point is to get them to the point of asking "what do we need in order to do _______", rather than assuming we can do it, for nothing, by next Tuesday.

Just the other day, we had a server motherboard die. Wouldn't even POST properly. The director of the dept the server is used for said that was unacceptable that they would be down for a couple of days while the server was being repaired.

I said that if this were truly the case, they would have a standby server, with a current backup of the database ready in stand by mode at all times, for fail over.

The problem is, they don't want to pay for a standby server, or the systems infrastructure to make sure that the DB can failover gracefully to the standby hw in the RARE event like this.

It costs money to do things like this, and sometimes lots more than it is actually worth. I find out all the time how much things are worth to people when stuff breaks, and when I quote a system setup that will work in the event of failure like what I described.

When they found out how much it would cost for a redundant system, even after the failure, they didn't pony up the $$, while maintaining that it was unacceptable to be down for any length of time.

How does one break that mentality, I'll never know.

We the few, have done so much, with so little for so long, we are now attempt the impossible with nothing.

Re:Exactly!

[Archangel Michael]

You missed the point. THE point is that they never really had a budget in the first place. They thought it could be done for nothing, by next Tuesday.

Much of what geeks do, and I see it a lot here on /. is that we tend to be DIYers. We see a high end server and say things like "I can build it for less". And people begin to expect that we can do things for less than to do it right, with engineered pieces.

Yes, we can build a off the shelf server to hold terabytes of storage for cheap. Too bad it is in a mini tower case instead of a rackmount chassis, and using SATA drives at 7200 RPM, instead of SAS drives at 10,000 (or 15,000), using onboard or cheap RAID rather than battery backed up RAID controller, etc and etc.

I can build two of those cheap ones for the cost of an expensive one. But that doesn't mean it is better.

There are three ways to build a system.

1) Cheap.
2) Expensive.
3) Right.

Right includes things like proper design, engineering, and build out, and planning for things that non-professionals would never think of. It is often more expensive that even #2. But in the long run the actual cost is less (time, effort, maintenance, performance, upgrades etc).

Doing things right is not easy, or else people would do things right the first time.

Re:Exactly!

[Hydian]

Don't you think you guys have a problem if it takes you days to replace a dead motherboard? At the co-location our company uses, we had a server fail on us which was fixed in a matter of hours. The server is hosted in the US so it wasn't even during their office hours.

It depends completely on your warranty terms and whether or not the part you need is available. Not everybody has a 24x7x4 warranty on their equipment.

Re:Exactly!

[Fulcrum of Evil]

How many spares do you have on hand? Do you order mobos from newegg or go to frys? If the company won't spring for a reliable infrastructure, they probably won't go for spare parts either.

Re:Exactly!

[Archangel Michael]

Your COLO probably bought RACKS of identical servers, and for every rack has one hot standby. THAT is what I would do if I were running a COLO.

When running a large operation it is easy to bury an extra standby server in with 24 or 48 other servers (add 1/24 or 1/48 to the cost of each server). However when you order the server as a one off, you can't double the cost just to have a hot spare.

Here is an example.

Let us assume you're building a server, and it cost $5000. Are you gonna cry over the $210 needed for the spare ? Will you cry over $5000 for the spare?

The difference is that when you have MANY it is much easier to cover the spare.

Re:This is why the IT department is always cut fir

[Chirs]

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

There are cases where it really doesn't make sense for a shop to handle their own IT. On the other hand, there are definitely cases where it does.

SLAs

[travisb828]

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 are marketing people. Any problems that occur are tracked by our ticketing system, and its just a matter of tracking resolution time, incident severity and number of incidents. All of this is defined in the SLA. Resolution time usually comes into play when looking at service availability, and in the incident review process for high or critical outages.

For our team individual performance usually comes down to how well we contribute to the team. My review is not that much different from a kindergarden report card. "Plays well with others" is now "Maintains positive relationships with external partners"

Stop asking to do stupid things

[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 installed, configured, connected to the SAN and ready for applications
- Allow an outsourced vendor unlimited access to internal networks with 10,000+ servers without a corp-2-corp VPN in place.
- Send and accept unlimited sized emails without any virus and malware checks.
- Demand something fast because YOU didn't schedule and budget properly - MARKETING, this is for you.
- Run a machine that will be hacked easily and turned into a torrent, porn, music, VoIP server a few months after it gets placed onto the network.

Re:Stop asking to do stupid things

[Achromatic1978]

You should try working in a monolithic corporate structure, EVERYTHING is like that. It sucks. But it pays well.

The last company I worked at, I was the manager in a department of 130 people. When I left, the company had deployed server #100,000 to its datacenter.

I understand CM well, but (and I hope you're exaggerating), if your IT team requires backout plans for "Install OS" as a deployment step, then someone needs to step in and reign in the bureaucrats.

Stupid metrics

[Aladrin]

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.

Read up on ITIL

[Colin Smith]

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 smoothly running infrastructure operating exactly as the users and business expect it to. Not exactly possible, but at least it provides a direction to move in... And if your incident management system is any good, it'll tell you where the problems are, and where money should be spent to fix them. That may be user training, education on the portfolio of services that IT provide, or replacing a critical application that falls over every 10 minutes or is too slow, etc etc.

ITIL

[kenp2002]

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.

You need accountability

[Colin Smith]

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.

Fire Fighting is all that counts

[gwn]

Years ago I learned that most managers are so remarkably ignorant of what good IT workers do, you know preventative work that ensures users can do their jobs without interruption, that the only way to get ahead is to be a bad IT worker.

Meaning if you let all sorts of bad stuff happen and then rush in and be the savior of the day you will be rewarded with promotions and bonuses.

A few years ago, just before I left my last job, I demanded a job review having gone 6 years without one. I got to sit through my review by the VP in charge of the division I supported and my direct IT boss from Denton Tx, only to be criticized for not socializing with some techs who came up from Denton to help with a move of the office 80 mile to a new city. I had elected to do my appointed tasks for the move, baby the servers and double check backups prior to taking them down packing them up and reinstalling them in the new sites server room.

Had I done the socializing I would have ignored my duty to the corporation but not been f*cked over during the review. If the servers had not come up I would likely have been heralded as a saint had I been able to resurect them too.

It makes no sense but my advice is don't bother with looking at meaningful metrics unless it is to satisfy your own needs. Focus on the only metric management sees... Crisis frequency and crisis resolution... be the superhero!

Re:Only two measures matter

[gurps_npc]

No. That is how many businesses measure, but it is not good business sense.

There are three types of companies.

Generic

Brands with no real value

Brands with a good reputation, worthy of trust.

A Generic company honestly should not give a crap about user satisfaction. Your goal should be to spend as little $/user as possible without resulting in lawsuits. You are selling crap and people are buying it because it is cheap. They won't care about customer satisfaction, otherwise they would have bought a brand name.

You correctly describe a no real value brand. Middle satisfaction is the goal.

But a real brand (like Apple) needs HIGH satisfaction. They want it as high as possible. This sell their product at a premium, using their reputation as the reason. They need people to say it is worth spending more for their product.

Similarly, the same thing works for a company that wishes to maintain a good reputation as being on the cutting edge. If you are a law firm, like say the one I work in, and you are trying to attract the best lawyers, it helps a TON to be known as someone with the best stuff and 'it just works.' (to copy a certain slogan). You can't do that if people go around saying nothing works and IT doesn't get back to you. You need IT to solve your problems ASAP, keeping all employees happy and not thinking "This wouldn't happen if I took that job at XXXX"