Why Timesheets Don't Help You Run Things

Timesheets don't help you. At least, not until you understand what they should be doing. What most companies use them for is as part of their elaborate procedural-management-political dance.

The concept of having timesheets is simple enough - have the employees write down how they spend their time. Using this information you can determine how much software costs to write, how much time is pent on other tasks, how long things take. It can give you your "velocity" - the measure of how many actual real calendar days it takes to get one ideal development day's work done.

And herein lies the rub.

Everyone, from finance director down, starts with the assumption that they won't like the numbers that come out. Because suddenly someone will realise that the software costs more than it is beng sold for, or that large amounts of time are being wasted on something. And so the first steps of the dance are danced.

The timesheets do not fit with reality - reality being defined as what is convenient for accounts or for the MD. The timesheets must therefore be brought into line with reality.

Many companies insist that time can only be booked to valid job codes. This means that nothing without a job code can consume employee time. This, in essence, forces employees to lie. Often there is no code for "time spent completing timesheets". Once you've established this principle, it's easy not to have codes for any admin tasks at all and they become free. Likewise problems (for example: queuing to use the only modem in to office) become free.

The cost of these things is distributed across many projects, effectively hiding that time-sink from view. This means that it's hard to see where the bottlenecks are. If accounts could clearly see how much time was being spent queuing for that modem, it would be easy to make a cost/benefit decision about buying more modems. Since accounts cannot see the benefit, buying more modems only has a cost to them. And the employees can only say it would save them time, rather than point to past time losses that would be averted.

Many companies insist time be booked in one hour increments. While this makes sense if an employee has a main project and a few distractions, it doesn't make sense if the employee is being interrupted by support calls. While working on one project, she is spending ten minutes an hour on the phone to customers answering questions. Since only whole hours can be billed, and each customer would require a seperate job code, and there is no job code for "misc. support", the calls vanish. The cost of user support gets subsumed into the current project.

...

Even after the data is gathered, it is subject to manipulation. Employee time is often budgetted. In these cases, projects cannot overrun. Once again, the timesheet does not agree with reality, the employee spent 10 days working on a project, but it was costed at 6. 4 days need to be hidden away - usually by recording them under another project heading, often the next project the employee should have been working on. This hides the fact that projects take longer than people think: a nice fiction for management who now get their "estimates" on target everytime, but it won't help in the long run. In a company which works on fixed price contracts, it's now perfectly possible for projects to be sold for less than their production cost, and for no-one to know about this. With no-one knowing about it, no-one can learn from it. The project did over-run: the question people should be asking is "why?"

And more importantly "How can we stop this happening again?" If the employee was learning the technology on the project, because learning time cannot be identified, this should be known about. The employee may work more dilligently than others, being slower at developing, but generating fewer support calls. If you hide both the extended development time AND the support call resource usage, you cannot tell this. If EVERY project runs behind schedule, maybe your schedules are too optimistic?

The latter case happens commonly in companies which see themselves as "Sales Led". The salesforce goes out and lands contracts. One of their tactics for doing this is to undercut the competition or to provide free support contracts. While nothing is intrinsically wrong with these tactics, if the saleman undercuts the competition to the extent that the software is sold too cheaply, it is important to realise this is happening. The wrong solution to this problem is to "fiddle" the cost of the software production down until it is under the sale price. That won't discourage the sales force from giving money away...