Estimating future project timescales

[barbie]

However, it's recently been suggested that management might begin to use this timesheet data for other purposes

This is often a concern when a system is introduced, but in my experience its never been the case. My staff and I currently fill in timesheets, in the catergories you mention, in roughly 15/30 minute chunks. The aim for us is to better gauge how much effort is put into a project, so that further down the line when we have a feel for how much time is spent in all the areas, we can better estimate how long similar projects are going to take. It saves us from trying to meet ridculous deadlines.

Timesheets should never be used for "assessing individual programmer productivity and performance" as there can be all sorts of factors that are out of the control of any one programmer. What if requirements were poorly defined, and they've had to go back and rework chunks of code, is that the programmers fault? Anyone who uses simple time based metrics to gauge performance is either a bad manager or they are not the company you want to work for.

As for measuring/recording time spent working in your own time or coming up with new ideas, this can be a difficult one. I personally don't, even though I do it most of the time. As do all my staff. However, it is one thing that I do look favourably on when appraisals come up. And perhaps I should mention I've never used timesheets in an appraisal, except to remember all the projects that someone worked on. Then I am more interested in how well they performed not how long each project took.

[JanneVee]

++ tracking performance with timesheets is not a good thing at all. But I had the unpleasent experience of being mesured that way.

The result was that people started to simply to be on time with "implementation" by skipping parts of it and the things that weren't finished in the initial coding phase was pushed on to bug-fixing(unfinished implementation details are bugs right?). The result of this was a drop in code quality because the allocated time for bugs wasn't enough due to the covering of the delay in the initial implementation of code.

Time based metric is even worse than LOC count measuring.

[eyepopslikeamosquito]

Another example. I know of a company where they measured the "performance" of their support section by how quickly they closed open tickets. As you might expect, the support folks began boosting their performance rating simply by closing a ticket ... then opening a new one! Now, this annoyed the customer (who was told to start referring to a new ticket for the same problem) but, hey, they got their bonus for improved performance! The lesson here is that metrics become unreliable as soon as they are used as a basis for reward/punishment. Perhaps the best way to measure performance is from outside the team: for example, the performance of a support section is perhaps best measured by asking the customers how satisfied they are.

[ysth]

This reminds me of some grocery stores here that have started to measure employees' speed at scanning items at checkout. Some workers (even shift managers) would subvert the measurements by hitting subtotal (which stops the timer) immediately after scanning each item. The loser here is the customer, who no longer gets to see (and validate) the price of each item as it is scanned.

[DrHyde]

Of course, measuring a support team's performance is particularly tricky. *No-one* is perfectly satisfied with support teams, because they only get to interact with the support team when something has gone wrong. And that something - despite not being caused by the support team - inevitably sours the relationship somewhat. Better to measure change in customer perceptions (the customer hates us less this quarter) instead of merely what the current perception is (the customer hates us).