Everybody Hates Time Tracking

It’s difficult to get people to fill out timesheets 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:

1. Tracking time spent on individual tasks. This granular kind of time tracking (with accuracy of about ½ hr – 1 hr) takes place on the project level, and is especially widely used with Agile processes such as Scrum. The objective is to see whether the iteration is on track (no pun intended) and to refine estimations by looking at actual hours spent on various tasks during retrospectives. This can help uncover systemic errors with estimations, making iteration level planning more precise.
2. Tracking time spent on individual projects/accounts (utilization tracking). This is also done on the project-by-project basis, and in our case is essential for billing (much of our work is Time & Material). The accuracy here is more coarse, roughly between ½ and 1 day.

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. The 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 timesheet 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.

Utilization tracking

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 timesheets?

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:

1. If a developer is assigned to the same project for the whole month, we automatically calculate his hours based on the amount of working hours in that month, adjusting them for sick days, vacation, etc. (that data is available in our HR/accounting application and is accessed by our in-house billing system via EAI)
2. If during the month a developer is reallocated from one project to another, we calculate the hours in the same way and based on the date of his new assignment.
3. If someone is putting in overtime, his or her manager will explicitly track those overtime hours.
4. In a relatively rare case of a developer being assigned to one project, but occasionally helping on another project as a consultant, that individual is required to track his/her hours on one of the two projects, the rest being calculated automatically by the system.

As you can see, only developers who find themselves in scenario #4 are required to deal with timesheets 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, timesheets 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 benefits from this approach, we are able to produce fairly accurate utilization forecasts that incorporate project managers’ knowledge of the client’s intentions, rather than relying on (more or less) linear extrapolation of the past data.