When is time tracking too detailed?

Question

Currently, all developers all required to "clock in" by actually clicking on a timer in our internal application. So even a discrepancy of 3 minutes from the budget needs to be accounted for.

As a PM, I find that this method has two major disadvantages:

1. The development team's morale goes down the drain during reviews (quarterly, annual) as they need to account for the over used minutes (not hours).

2. From a PM perspective, requesting budget increases goes through a whole lot of (what I feel) unnecessary red tape. Also, it dramatically increases the time spent in creating status reports as I have to sift through timesheets with a fine toothed comb.

To give you an idea of average project sizes, they can range from 200 - 1000+ hours, which makes me wonder if "by the minute" tracking has any advantages given that these are relatively smaller projects.

Question: Given the average project size described above, does it make sense to track by the minute and what is an ideal way for a developer to report time spent?

Answer 1

I don't have any solid evidence - our projects are much longer. At one point I did work for a company that required timekeeping to the 0.1 hour range. That lasted about six months before the accountants told the company President to stick to his own swim lane.

Speaking as a PM, I would have the following concerns about timekeeping with a precision of 0.5%.

• Cost/benefit. It will take longer to reconcile T&A records than most devs can earn in the period. If I have to reconcile 6 minutes, and it requires the dev, the accountant, the PM and the dev's line manager, (4 professionals for 30 minutes) I cannot imagine that it is cost effective to dedicate that much in salary to that small a putative loss. If I were in your shoes, I'd do some back of the envelope cost models, and try to grab the last six months of data and estimate what this is costing the company.
• Accuracy - I just did a resource loaded schedule and found that ~30% of my staff's time is dedicated to activities that are not devoted directly to deliverables. (coordination meetings and operational activities designed to drive the project forward, but not specifically marked for a deliverable. My numbers are probably higher than most because of where I sit, but every organization has some similar committments. "Sorry, I can't come down to the break room to celebrate the fact that you just narrowly survived a very complicated pregnancy and that you and the baby are doing fine, because that would cause a 6 minute discrepancy in my T&A report, and that would require a 45 minute meeting with my management." "Sorry, I can't come to the federally required sexual harassment seminar because I don't have a charge code on my T&A report....."
• Accuracy 2 - as others have pointed out, people interrupt other people. Sometimes they are company valuable interruptions "Can you show me that really nifty way you shaved 5 lines and 10milliseconds out of that API call? I think I could use it here". Sometimes they are not "valuable", but it would be insane to block them - when the family calls, or the hospital, the worker should take that call. I do not want to think about how to manage that.
• Work experience. Your devs have a choice. They can work at your firm, or they can work at a firm that requires ten times less precision in their time and attendance records. Requiring timekeeping 10 times more precise than the competition makes a very strong statement about the trust you place in your employees, and the value you attach to them. That is a best case scenario. Worst case - from your point of view - is that the dev can go work for a modern firm that not only doesn't require that accounting, but actually gives them 20% of their time to work on unscheduled projects. Is your firm going to pay a salary that compensates your devs for that? Once again, I think someone needs to do a CBA and determine the cost of the talent you've got, and the cost of the talent that is walking out the door for a better working experience. Remember that the best talent will walk first, and the worst talent will stay the longest.
• Work experience 2 - there is a second message hidden in this. "We value a tradition that is attached to no identifible business reason or stakeholder more than we value the opinions of our devs and our project lead/manager." I think that is a truly chilling commentary.

I know of only one firm that does this kind of micromanagement - I won't name the firm, but everyone knows of them. They have trouble getting and keeping unskilled labour, and they promote completely from within because they simply cannot hire skilled labour.

Answer 2

I've always billed to the nearest half hour. Tracking to the minute like you do would be extremely demoralizing, especially if I had to account for any discrepancies. Standing up for a healthy short walk should not be penalized.

I have often worked in environments where interruptions were usually important and somewhat frequent. Trying to track them to the minute would be difficult if possible at all.

The distinct lack of trust indicated by requiring every minute to be accounted for is a known bad practice. If you can't trust your staff, replace them. If you can trust your staff, show it and treat them like professionals.

The reports I have seen indicate that tracking time to individual work items at normal detail adds about 3% to the cost of a project. I have no idea how much more your detail costs. I would break it out and ask for a budget increase to cover the cost of time accounting.

Asking for budget increases is usually difficult. Try gathering some backlog items which are unlikely to get done in the next year and ask for a budget for them. Repeat for a couple of years, and you may be able add the extra budget into your base budget.

I have yet to work somewhere where periodic reviews were done well. Typically, reviews are done late. (We need to complete last periods review now, because its time to do this years review.)

I would suggest this approach. Provide feedback when needed. Provide lots of deserved positive feedback. Track it as you provide it, and summarize for the quarterly and annual review.

Answer 3

When is time tracking too detailed? When you ask the question about why you're tracking to that granularity and no one in your organization can tell you why.

We track time in 15-minute increments. Why? Because that is what we've agreed to with certain clients.

Answer 4

It depends on what is done with the information. I'd advise collecting the minimum you need.

At my place we just record what project we were working on for the day but we only really care about whether time is being spent on a capex project or not so the lack of precision is not a problem.

If it's being collected for something valuable and needs to be to that level of precision, so be it. So long as everyone knows why it's being collected it shouldn't cause morale issues.

Answer 5

I think the fundamental question that isn't being asked is, "What is the purpose of time tracking?" Depending on your answer for your group should influence the answer.

For my group, we work on very large features: an individual feature takes on average 9 months to 1 year to develop and around 2000 hours of estimated work.

I view time-tracking to have 3 general purposes (one or more of which may apply to a particular project):

1) Time-tracking to improve future estimations. This is the one I currently use most often. We spend a fair amount of time up-front developing a detailed effort estimate in both hours and elapsed time. Generally engineers are assigned to project on a full-time basis (we find that increases efficiency rather than mind-share on multiple projects, but that would be a different thread). Instead of having engineers do time-sheets we have project managers mark at the end of each week how many FT and PT engineers worked on the project. We find that using that to measure actuals against planned provides a high relative accuracy for looking at where we need to improve our estimations in the future.

2) Time-tracking for billable work. This is best used when a contract requires that we demonstrate actual hours performed to complete a project. For the purpose of billable work, .5 hours has always proved sufficient for customers.

3) Time-tracking for auditable work. Basically, the same as #2, but applies especially for government or other contracts where the time spent on a project can be audited by the customer even in the case of fixed-priced contracts. The same granularity of .5 hours has always sufficed to demonstrate area of focus.

Generally speaking, I have found that the smaller the time granularity you require of team members the lower your overall accuracy. Additionally, a smaller granularity may lead the audience to perceive a higher level of accuracy then there really is. When required, stick to .5 - 1.0 hour granularity. The audience understands that there is some play in that number but that it provides a general output of how time is spent.

But, only engage in time-tracking once you understand what the purpose is for tracking time - don't do it just to "monitor" or tick-a-box that you are doing it. You will not know what to measure and will likely fall into a trap over-enforcing an onerous policy that isn't delivering value.

Answer 6

It only makes sense if you are required to track time by outside requirements. For example if hours and minutes are billable or if you are on a government "cost plus" contract.

Issue 1 of morale is to be expected. Professionals don't like to be treated that way. I have had to fill out time cards, but clocking in is generally not well received.

Answer 7

People have been punching in for work for decades. There is no morale loss there. I don't see much of a difference between the human looking at a clock and writing in his/her time or using an application; the behavior is the same. One is known to be ambiguous, imprecise, and a source of fraud and the other is the opposite. I am not sure why either would expose or hide "unproductive" time unless the application causes time to stop when you walk away from your work station.

Focusing on variance by minutes is more an issue of the person doing the analysis, not the tool. If they are trying to understanding the the causes of the variability by minutes, then their analysis sophistication is elementary at best. Fix that.