How Would You Benchmark an IT/IS Department? 144
ferretworks asks: "Our IS/IT department has been asked by our CEO to find a way to benchmark ourselves against IS/IT departments from other companies with similar technologies (none specific). This sounds like an innocent enough request, but diving into it has made me realize that this is, not necessarily undiscovered country, but a desolate one and rarely visited. So, my poll to the community is: In your Opinion, what is best way to benchmark an IS/IT department and what categories/sub categories would you base your judgment and ratings on?"
Metrics (Score:2, Informative)
Helpdesk (4 employees): Their mainly measured on how many helpdesk "tickets" they can close without sending the problem off to a 2nd level tech. They can reset passwords, add printers, etc.. They can remote also into users desktops to provide assistance. Their resolution rate of about 40%. The remaining tickets are passed up to the 2nd level.
2nd level techs (6 employees): They are expected to close "standard" tickets within 16 business hours from the time the call is taken at helpdesk. They will visit users in their cubes to assist. They're expected to close 95% of their tickets each month within the 16 hour time frame. Anything they cannot fix goes to 3rd level techs.
3rd level techs (4 employees): They get 8 additional hours to close ticket (24 total). They provide final resolution or call the proper vendor for support. They are held to 95% completion rate for non-vendor issue calls.
Telecom (3 employees): They handle call flow, broken phones, fax server, etc.. They have 16 hours to provide resolution from the time call is taken. They also are expected to close 95% of their tickets in that time.
IT Ops (15 employees): They handle AS/400 (logins, reports, administration issues) and backups. Same 95% within 16 hours without vendor assistance.
We also have programmers, database admins, and special system admins. Not sure how they're measured.
About 100 employees in all making up 10% of the company. Here are some other things we measure monthly:
Spam blockage as percentage of total incoming email, viruses stopped/detected, faxes in/out, calls in/out, internet usage as percentage of total pipe ("tube" :-) size, # helpdesk tickets opened vs number resolved by helpdesk/2nd level/3rd level/telecom/ops. Wish I had more but I can't find the metric reports on out Intranet but I hope this post assists a little.
A few things to measure... (Score:2, Informative)
You need to turn this around in favor of your department, and it would be a very good idea to take a look at what metrics you can apply that will serve a twofold purpose - to set a baseline of current performance, and to set a moving target for constant improvement. In other words, the things you measure should paint a picture of things that your department can and should improve on, if given the resources to do so. An open ended reporting task like this is a setup from the start, but you need to turn it into a chance to show both how well the department is working with what it has, and how much better it could be working if management would let it. That means finding out where your human resources are being wasted, and making recommendations for refocusing those efforts, finding out what parts of your infrastructure are money sinks, finding support costs that can be reduced with changes, and justifying expenditures that will have a concrete benefit to your department's ability to meet the business needs.
If you don't have them already, now's also a good time to start setting realistic SLAs and tracking compliance with them - for everything from backup/recovery time, recovery time objectives, recovery point objectives, helpdesk call resolution times, server reliability, etc. Just make sure they are realistic, and within reach, and re-evaluate them frequently.
Formal statistical process control methodology such as Six Sigma can be useful in the IT department, but only with the people to make it work, and an organization large enough that it can see enough cost savings to justify having a formal quality team. In order for statistical process control to help, everybody has to be onboard, from management to the lowliest member of the department. If you can achieve this, the rigid define, measure, analyze, improve, control methods of Six Sigma can probably create a savings of cost, labor, and sanity within your department.
I would also look at regulatory compliance as a benchmark. Even if your company is not publicly traded, the tight controls that are necessary for public companies to comply with Sarbanes Oxley (SoX) often lend themselves to better IT practices - formal validation of your IT controls (access to information, physical and logical access to systems, authentication credentials, least privilege, auditing, etc) is a good idea.
Do users have local administrator access to their desktops? If so, why? What applications are requiring it?
Do you have an audited software inventory? If not, what's stopping you?
Do you have controls to prevent unauthorized software installation?
Do you have controls to insure virus scanning and security patching are done appropriately?
Do you have controls to make sure than users have no more access rights than their responsibilities require?
Do you have controls to keep track of why users have the access rights they have, and who approved it?
Measuring your disaster recovery capabilities, and realistic evaluation of the scenarios they have to survive are also a must:
What are your worst single-failure scenarios?
What are your worst two-failure scenarios?
What can be done to mitigate the above?
What has already been done to mitigate the above?
I'd also take a good look to see whether your department is spending it's time putting out fires, or keeping them from starting - if you are just barely keeping up, then it would be good to look at why, and what can be done to change that. Take a good hard look at your helpdesk, and apply the 80/20 principle - roughly 20% of the causes will be responsible for 80% of the calls - what can be changed that will improve the situation there?
From the end user perspective, what issues are most disruptive to users? What issues are hurting the productivity of use