It’s difficult to get people to fill out time sheets or submit hours into some kind of system. Developers see it as boring and irritating while also being invasive: people just don’t like to be tracked.
In short, most developers hate time tracking with a purple passion.
But what if you really need time tracking? Well, all is not lost.
As a custom software development firm, we find it necessary to do 2 types of time tracking for two distinct reasons:
Task level time tracking
We have a large number of projects running at any one time, each with its own requirements, circumstances, processes and tools. For that reason, task-level time tracking is delegated to the team: both how much of it is needed and how exactly to do it is dictated by the specific project. Project Manager or Scrum Master will know best, and will make the decision, together with the team, on how to track time spent on individual tasks. Our customers (and by extension, our teams) use a variety of tools (Jira, Rally, TFS, etc.) for that purpose. We don’t push a one-size-fits-all solution on this level, but rather leave it up to the teams to regulate. Thus, there is no company-wide mandate to fill out a time sheet each day. The purpose here is to keep the decision making as close to the point of execution as possible, and to minimize intrusive activities. Also, we are very clear on why we do it: time tracking is not a way to determine and compare individual developers’ “productivity”, but to ensure the success of the team as a whole. When positioned like that, time tracking is not met with resistance.
Now, this is a different story. We bill many of our clients at the end of each month, so how do we keep track of all those hours without actually forcing people to fill out time sheets?
Unlike some consultancies, where specialists are typically working on several projects at once, our developers are usually assigned to one project at a time. With that in mind, we have implemented a simple approach based on the following scenarios:
As you can see, only developers who find themselves in scenario #4 are required to deal with time sheets occasionally; the rest is done by the software and the project managers.
This simple method yields pretty accurate results. Instead of micromanaging their people, project managers are motivated to make sure that developers’ time is spent doing productive work, and that the client is happy with the output at the end of each billing period. Nobody is going to track that Joe Schmoe worked only 7 hours on Tuesday but put in 9.5 hours on Friday. To do so would aggravate poor Joe, but would not help the project manager if Joe’s actual output was poor, despite having put in the required number of hours: if the client feels they are not getting their money’s worth, time sheets won’t help to keep them from firing you. So again, undesirable overhead is minimized, decisions are moved closer to the point of execution, and incentives are aligned.
As a side benefit from this approach, we are able to produce fairly accurate utilization forecasts that incorporates project managers’ knowledge of the client’s intentions, rather than relying on (more or less) linear extrapolation of the past data.