Keeping timesheets up to date is one of the least favorite activities for most developers I know. Most of them regard it as a pointless activity, done only under duress, satisfied by doing the minimum at the last possible moment. "The stuff I have to fill in just duplicates information in the issue tracker, e-mail, source code control system. No one reads this stuff, anyway." At the same time, many of these developers are very meticulous when it comes to change logs, bug reports, and blogging about issues that matter to them.
What's going on here?
There's a bunch of valid complaints here.
Part of the reason for the dissatisfaction is that timesheets are typically designed to satisfy bookkeepers and accountants, and that's it. The information that the developers need to provide has no value for them. So, what can be done?
1. Don't force people to enter duplicate information.
Here's one strategy. Let timesheets be a place to aggregate and annotate information from other sources. It should be easy to extract a day's worth of source control logs, issue tracker logs, e-mail logs, appointment calendars, contact logs, as chronologically tagged items which can be annotated. If it's not easy, you are probably using the wrong tool. Now the annotations provide a narrative thread, a sense-making context for the day's, the week's, the month's work. Nothing is duplicated. Everything is cross-referenced. Everything is in one place so it's easy to search, easy to overview.
2. Make the timesheets provide value for the developer.
Addressing point 1) above already improves the value of the tool to developers, by giving them an easy way to discover the historical context for development activity.
A good time tracker comes into its own, though, as a tool for improving personal productivity.
One aspect of this that receives a lot of attention is estimation. Everyone complains about estimation: how bad it is, how difficult it is, how unreasonable other people's estimates are. First of all, developers need to be the ones who ultimately estimate their own work. Those who are unfortunate enough to work for organizations that force them to work to other people's estimates eventually find that their best weapon for fighting against unreasonable estimates is to make provably better estimates. Thus another way to make timesheets provide value for developers is to allow them to be a tool for provable estimation. Once estimates are tracked and monitored in a visible way, people have a chance to get feedback that allows them to learn to make better estimates the next time around.
Finally, a good timesheet should explain why projects diverge from estimates. There are essentially two reasons for this. The first is poor estimation. As discussed above, estimation skills will improve with experience if the proper information is provided as feedback and personal productivity is emphasized.
The second reason that estimates are sometimes off relates to the fundamental uncertainty of development. This technical uncertainty provides the opportunity to exercise the creativity and innovation which makes software development a rewarding activity for most developers. Given an experienced, skilled estimator, a divergence from schedule often flags innovation. To the extent that innovation adds value to a company, this should be rewarded, not punished! If a task finishes early - look for some clever insight that resulted in a shortcut. If a task takes longer than estimated, this points to some unforeseen difficulty, a technical challenge that required innovation to solve. The software is more more valuable, because it solves a more difficult problem. In either case, the company has benefitted from some technical knowledge or capability which has improved its technological competitiveness.
What is required to enable this? Each task must have an estimate field associated with it, which must be provided at the moment it is created. As work progresses, remaining budgeted time declines. Any changes to the estimate are tracked and flagged as events (which might trigger some action). Eventually the estimated time left is 0, and the task is finished. The estimate and accumulated time on task can be tracked historically, to provide the required feedback for planning and retrospective analysis.