IT Employment

Ask something
Discussion Locked

Measuring IT productivity

0 helpful
9 replies

by suzanne thornberry

Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.

How do you measure productivity in your IT department? We've heard of departments that use lines of code per developer, for example, but some say that's an irrelevant measure unless you consider how well the final program does its job. Some help desks measure calls per technician or the number of PCs a tech is supposed to support. Some measure network administrators' productivity by the number of servers they support. Some companies even look for a relationship between the dollars they spend onIT and company revenues.

Are any of these measures valid? Which ones does your IT department use?

9 replies

by timwalsh

This is my favorite answer this week.

Any or all of these measures may be totally valid in one environment while being totally irrelevant in another.

The trick is that any ONE measure can be used to portray whatever level of productivity (or lack thereof) you want it to.

Lines of code means nothing without taking into account # of bugs per line or product completion on time. Is a developer who writes 1000 lines of code in one day more productive than the developer who doesn't get any written because he must track down and correct the 250 errors of the first developer? Number of calls per technician mean nothing without taking into account average time to resolve problem or complexity of problems. Is the technician who only takesone call all morning (because he must track down and solve an intermittant email problem on the Boss'es computer) less productive that the technician that takes 20 calls in the same period (and resets 20 user's passwords)? I bet the Boss won't think so. Because I support only 3 servers (all the servers on site), am I more productive than an administrator who only manages 1, or less productive than an administrator who manages 5?

I'm sure you can see where I'm going with this. Anyone who is trying to measure productivity needs to take a look at the entire operation.

Since, for the most part, the IT world is a customer-service oriented world (whether your customer is a paying client for whom you are writing custom software, or a user whose incessant minor computer problems you cheerfully fix), the ultimate measure of productivity is customer satisfaction (is the customer happy with your progress and the end result).

by fulltextus

In an enterprise environment the technology's customer is the person who use the tools provided for tech people for his/her work. But, what happen when the customer has a bad performance o makes a bad job? Of course he/she will try to blame someone else and tech people are always a good candidate. That's part of our job!

by workflowguru

An organization's level of Customer Satisfaction will result from its Process Maturity. Address PM systematically:
1. Set expectations up front by involving key stakeholders in process definition
2. Optimize key workflow
3. Implement a fast-trackworkflow automation system that:
a) Uses intelligent task initiation and routing
b) Tracks accountability
c) Provides strategic information (the KPI's - key performance indicators - and analysis that apply to the process at hand) to fuel process improvement.
Although many are beginning to see the light, too few orgs have even completed step 1!

by tom.chambers

Suzanne,

I've been on both sides of the fence (hw/sw) and it is quite difficult for anyone to measure the ROI in IT. On the development side one could argue that poor requirements analysis could highly underestimate or overestimate the lines of code that should be developed for a given project. So, how do you truely measure performance in that area? I don't have a solid answer other than make sure that sound req/analysis are done with a schedule everyone can live by. Then, you can measure productivity by meeting milestones on a project, not by the number of lines of code someone develops.

On the hardware side its slightly different. Support is dynamic environment. Poor equipment or network configuration can drive technicians and managers insane. In my experiences, a average PC tech can handle between 25-50 PCs and have time to do other things like PM (Preventive Maintenance) or user training. Also, tools like network monitoring/analysis software can alert support to potential or existing problems usually before anyone notifies them of it. Again, having someone with a good understanding of the environment is critical. Not necessarily someone with bagfull of certification acronyms on their business card but, someone who is calm in a storm and who can think clearly under pressure and who knows where to look for solutions to problems.

The bottom line is to have objective and reasonable expectations. PC's have become quite dependable as long as you buy quality product.

by rafiqul.islam

We do it in the form of KPIs(key performance measurement indices) at the Asia Pac level. Below is a brief on that, hope you find it interesting:

-------------------------------------------------
PROCESSES

Apply and practice project managementprinciples to manage IT initiative/s and support existing systems.

OUTPUTS

Publish IT monthly highlights incorporating the performance measure indices.

PERFORMANCE MEASURE

A. Project Performance
Index to measure percentage of completed projects having met objectives, on time & within budget compared to the baseline or approved changes to baseline.

B. Audit Compliance
Measure the number of Audit observations and recommendations.

Determine data and track KPIs

A.Project Performance
Index:
Actual cost incurred x Actual time spent x 100
-------------------- ----------------
Baseline cost Baseline time

Targeted index value in the range of 0.95 to 1.05

It is suggested that cost includes capital purchases, other general expense (like travel, etc) and external manpower cost incurred by the project. However, individual countries may adopt their respective cost definition standards. Time includes hours budgeted /spent by IT resources for the project.

Plan, estimate & track for projects involving person-days of 10 or more. Report the statistics for index tracking in monthly highlights as follows:
-Project Detail
-Budgeted/Revised Cost
-Actual cost
-Budgeted/Revised Time
-Actual time
-Target completion schedule

Upon project completion, compute and report the index in monthly highlights & the designated document titled – “IT KPI 2002”under project section of Asia Pacific Knowledgebase.

B. Audit Compliance

To minimize the number of Audit recommendation/s, the target being zero

-------------------------------------------------

by james r linn

It is indeed challenging to measure productivity in terms of developers. Instead think of measuring how well they meet their committments and deadlines. Now some of that is affected by how well requirements are gathered. But from a customer's perspective, its how often they meet the schedule with the expected product that counts. Currently reading a book called "the ProjectManagement Scorecard" which would help you in this area.

As for the operational areas you can look at similar targets -if you standard for completing level 3 calls is 8 hours, then what percentage of calls are completed within that time? What is the availability of servers/services? What is the call abandon rate at the help desk? How many calls are the help desk resolving immediately as opposed to assigning to other groups?

As to the larger measures - IT budget as a percentage of company revenue - use it, but compare it against your previous years - hard to find equivalent companies to compare against. Number of employees is a mugs game especially if you use contractors. The best indicators are employee satisfaction and customer satisfaction.

James

by thechas

You need to tailer the metric to the assigned task.

For someone writeing code, the metric would involve the complexity of the project, the time to produce the code, and the quality of the end product.

For IT support, the metric needs to take into account the user "downtime" versus the IT staff "idle" time.
(If downtime approaches zero, you are likely over-staffed.)

Chas

by management consultant

The primary reason for creating metrics is to improve the performance of someone or something. There are two fundamental problems that keep many metrics from satisfying this objective:

Problem (1): Most metrics are developed from data that applies only under specific conditions which existed when the data was collected. When the requirements (or job, or programming language, or test plan, or developers, or etc.) change, then the validity of any previous or "baseline" metric, which was derived based upon a different environment, becomes suspect. Solution: Specific metrics should be developed from data that contains enough detail to make them useful for the various situations that will be encountered in a normal work environment. Aggregated data can be used to develop metrics that adequately describe technical progress and financial position; but this data is usually not detailed enough to help improve individual people, processes or products.

Problem (2): There is no reason to create metrics if there is no way to reproduce the actions which created the results being measured. Solution: Clearly define your company processes so that they are repeatable and usable in most likely scenarios. Then insure that all personnel are performing their tasks according to those processes. Many metrics make sense when acceptable processes are available and in use.

The best metrics are those that are automatically created by a standardized system - not by an individual who is taskedto create them. Use an "organization-level" (not "company-level") data collection system to collect data at a level of detail that supports independence from requirements, programming language, etc.

Check http://www.adv-management.com for an example of a system that will help you define (and refine) your processes, easily create data at the right level of detail, and automatically create many useful "built-in" metrics.

by drnz_54

Hear Hear! All good output is based on good input and good process! So why not use good process to design which KPI's are relevant to your particular enterprise. Use the old software metric design methodology GQM and apply it to your performance metrics:
G: Goals: Identify the strategic objectives of the enterprise AND the IT division (your CIO/CTO should know these in his/her sleep!)Are the goals customer satisfaction or cost reduction or output increases or quality or revenue increases---some of these can be in conflict with one another--find out the priorities!
Q: Questions:What questions need to be answered in order to tell you you are meeting the strategic objectives you've defined? Example:Are my customers happy;Are my costs being reduced--you will have many questions to answer for each goal.
M: Metrics: Design the metrics that will answer the questions--there will be many many of these, sometimes just to answer one question. Make sure that you can a)identify data sources foreach metric b)identify data collection methods for each metric c)configure your data collection methods d) define the calculations you need do on the data and metrics to get the answer to your questions. e) define the the levels of acceptable performance for each metric.
Use these methods and you will have a set of KPIs that are meaningful to your enterprise.

This discussion is closed to new replies.