Time Tracking in IT Projects
Everyone agrees that having being able to know where one’s time is spent is a Good Thing. However, there is no greater gap between understanding the need for a process and the pain involved in actually implementing the process than with time tracking. Everyone I know working in information technology hates the whole idea of time tracking.
Managers, however, love the ability to receive the data, manipulate the data, derive business metrics from the data, and make business decisions based on the data. They don’t seem to worry too much or question the accuracy or validity of the data, though.
So why do the IT worker bees hate it so much? A number of reasons come to mind.
First, it’s additional work above and beyond (and not at all related to) the work of deliverying software to the business. It takes time to sit down at the end of the week and enter those hours into the time tracking application.
Next, the information may already be captured (albeit in a different format) in another forum. Consider the ubiquitious weekly status meeting — don’t we already talk about the progress made in the past week and doesn’t this translate to hours worked? To the IT worker, this feels very much like duplication of effort; something lazy (in the good sense of the word) IT people hate.
Another thing is that many time tracking applications (especially the home grown ones) do silly things like force you to account for all hours in a week. So even though management is interested in caculatng the total cost of a project derived from man-hours, some genius Microsoft Access programmer decides to enforce some arbitrary number of hours be accounted for including those not related to any project.
When IT people enter time into a time tracking system they usually do it at the end of the week on Friday afternoon. They sit down at their workstation and try to recount the entire week and where they spent their time. So they do this in isolation, even if they worked with other teammates during the week. There is no way the numbers are going to match each other.
Finally, by working alone at the end of the week, you have to remember the various contexts of the past week. Your mind isn’t thinking about any one project, your brain has to make a mental leap back to all of those times you worked a task, then you have to sum the results, and enter the totals. Then you move along to the next project. Not only are these kinds of estimates not accurate, it’s tedious, repetitive work (inefficient?) work.
So the real problem with time tracking in information technology isn’t lazy workers (the bad kind), or poor tools (though there are plenty of these), it’s a combination of things that add up to a miserable and inaccurate experience directly related to context. Specifically the context we as technology workers find ourselves in when asked to report our time.
Is there a better way? I think so. Consider the weekly status meeting we talked about earlier. In those type of meetings we’re free to let our brains dig deep into the work of the last week. All conversation during these meetings is about the current project, including how much time we spent working various tasks.
[At this point some the discussions should point out all of the different places where time tracking is useful…leading to a consolidation of similar data, and ultimately the solution I’m proposing].
Because the context is completely the project, we’re able to provide more accurate information, collaborated with the other team members, and drawn from collective memories & notes.
All that remains at this point is to tie together all projects and people to see where they are spending their time. Since most management teams only care about the cost of the project, everyone is happy.
This article was originally published on 2005-06-17 21:56:43, while I was a member the University of Washington School of Medicine IT staff.