Though we don't have any "client billable hours" all our developers have to fill out timesheets in order to gain R&D tax concessions from the government.
You fill out your time, in 15 minute intevals, on various development projects, and in various categories, such as: requirements, design, code, code review, test, bug fixing, talking about the cricket, and so on. I don't enjoy this administrative chore yet accept it's necessary to get the concession.
However, it's recently been suggested that management might begin to use this timesheet data for other purposes, such as assessing individual programmer productivity and performance and for payment of bonuses. This worries me. Once programmers realise you are doing this, they may start telling lies on their timesheets, thus ruining any value the data may have.
I often take specifications home to read on the train ... or uncover a new design idea in the middle of the night while sitting on the loo. How do you enter this sort of thing into a time sheet system? And how can you verify its accuracy? I also fear an overly onerous timesheet system may stifle innovation and creativity and make it harder for us to attract and keep quality developers.
I'm interested to hear about what you do. Do you fill out a timesheet at work? What is this information used for? How is its accuracy verified? What granularity (e.g. 15 minute intervals) and categories (e.g. requirements, design, code, test) do you use?