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

Yes, definitely. Furthermore, you should be focused on receiving calls about NEW issues all the time. Receiving calls on known issues over and over means the root causes aren't being fixed by IT. Service Desk managers mistakenly use "First Call Resolution Rate" as a metric - how many calls did the Service Desk resolve on the same call that the user registered the issue with. This is a false possitive - if this is "nice and high" like so many misguided managers want, all it means is that you employ a bunch of robots who are answering the same question over and over and over, and IT still sucks.

>>>My question is: How is your IT performance measured, and how do you think it should be measured?"

Malcolm Fry has written and presented extensively on the common-sense metrics for an IT service desk to track for all IT operational processes.

Some paraphrased excerpts from memory for INCIDENT MGMT:

Total number of incidents - over time, broken down by day and time-of-day. Use to predict and manage workload and staff at baseline.

Mean elapsed time to achieve incident resolution or circumvention - Also for managing workload and staff, because if it takes longer, you need more staff. Notice you don't pick an arbitrary time for a call to last - it lasts however long it has to last to get the customer working again.

First call resolution - long touted as a "great" service desk metric if it is "nice and high", this number should be low and plateau low eventually if PROBLEM MANAGEMENT is doing its job - fixing root causes. The service desk should have to solve/dispatch NEW and UNKNOWN issues more often than being a robot, since that says IT is solving old and existing problems before new ones crop up - PROACTIVENESS. Correlate this metric with the Number of Incidents over time to see if IT fixing things allows you to ramp down Service Desk staff.

There are ways to use metrics to improve the org performance, but ignorant managers frequently use metrics for personal gain and not organizational gain. They should have their bonuses withheld automagically.

I still have a working PCjr, Commodore 64, and also a Commodore 128. I got rid of my HP PA-RISC 712 pizza box, my Sun lunchboxes and pizza boxes, and my IBM RISC 7012. In college I sold my blazing fast AMD 386SX40 with 40MB HD for cash money (which I ran Linux 0.99pl14 on), when I found an old DEC VT102 terminal - I used it to dial up the modem pool with my Ven-Tel 1200 bps modem and access the DEC EP/IX system at school. ATDT, baby. The Intertubes now are not what I thought they would become back then.

The human condition is the ultimate predictor of our own futures, this hits the nail on the head. Get a n employment lawyer ASAP to help you navigate your soon-to-be employment contract with Megacorp and good luck.

DOS/Win3.1 => Win32 via Win32s was ugly. Win9x to WinNT kernel was ugly. Mac OS 6/7/8/9 to 10 was ugly. 32-bit to 64-bit is still ugly. This - this will be ugly, too. The alternative for M$ is to write off those who need XP (nyet, Windows NT-era tech) compatibility, and that doesn't let them release a new OS. They killed XP pre-maturely, released another Windows ME (Vista) and have adopted a (proven) winning transition strategy finally. Talk about the school of hard knocks for a leading company? Holy cow.

We'd been running OS2 Warp beta's next to Slackware with kernel 0.99 hacking around in the university lab, where we managed Win 3.1, MacOS, Netware and AIX for the past year. I was a pine addict after shaking my elm addiction, and had sworn off emacs for vi forever. Then, we started doing digital video editing on Windows 3.1 with Adobe Premier and some nice capture card hardware... ...and then I found CU-SeeMe live video reflector. But it wouldn't compile on Linux, so I hacked it grunge style to eliminate the errors, and, LO, it worked. We did a live streaming internet video broadcast in 1994. Thanks Linux!