IME, timesheeting is cumbersome: especially with dynamic projects, a lot of effort is made structuring and restructuring project billing trees to keep up with changes. Alternatively, you end up with categories that are too broad to offer tracking of any meaningful granularity.

I have found that story _base_d requirements capture gives people a common unit of work against which they can record time spent. Each story needs to be coarsely defined, achievable in a reasonable period (eg., less than a week) and executed through completion. With a lightweight story repository (like xPlanner - www.xplanner.org), team members can track time worked per each requirement, needing only to record this time with the completion of the story. It isn't burdensome time recording, it yields reasonably good accuracy in where time is spent and the actual cost of development, and variance of actual v estimate. It's worked in large departments and small teams.

Of course, it needs to be valued in the environment: if not, it'll be difficult for it to take root. You should be able to model this on a specific project, but it isn't likely to be durable beyond that team without organisational commitment.