Let me be direct and confess my opinion and intention first. I see time reporting as just a waste from an engineering organization point of view. Even though I honestly expect to be proven wrong any day, considering how many intelligent people consider time tracking to be really important, I haven’t been provided with any solid proof or evidence yet. I am writing this entry to help me clarify my own thinking and with the hope of getting some comments back and learn from them.
I expressed my opinion to an informally gathered group of engineering managers. They strongly disagreed with my point of view, so I asked them to present the group with the change or improvement performed in their teams based in time usage reports or statistics during the last year. Unsurprisingly there was none. Nobody in group has ever used the reports or data coming from the enterprise time reporting systems to actually manage her teams. They agreed this was partly due to the reports not representing the complex reality of time usage within a product development or engineering team. If it’s really important and it can provide insight into our teams and processes then we are missing the opportunity. It’s practically useless even if it could have some theoretical potential.
One other reason I frequently hear mentioned not to use time tracking reports to take decisions is the accuracy of the data in there. Tools and reports in this area provide great precision but unfortunately, as their models of how knowledge work happens are not very adequate, the data entered by the workers tend to be inaccurate more often than not. Think about your last product development day and try to report that into the timesheet of your implementation of Planview, IDTime, easyprojects or the likes that you have used. It’s not difficult, it’s simply impossible. Once you realize it, you invent a different day that matches the tool categories and processes, one that you can enter in those wonderful web forms, investing some time as well in creating that fictitious agenda after the fact. One of the managers at the informal gathering I mentioned above went as far as using a simple survey system get the data he needed to take a decision. He needed to know the percentage of effort his team invested in new features vs. maintenance. This information couldn’t be obtained accurately from their enterprise time tracking system, so he created a simple survey and have every team member answering 4 questions every other day for 2 non-consecutive weeks. Those were enough data points for him to take a decision.
I understand we need some data for the capitalization and taxes calculation and from that point of view it may be important and not a waste, but then it’s a cost coming from the accounting departing, not an engineering manager’s need.
My recipe for time tracking would be simplicity, do strictly the minimum to survive and don’t try to discern which data can be useful (YAGNI + KISS patterns). The way I see it, the main reason behind gathering all those details could be the perception they are free (as in free beer, not as in free of speech), but unfortunately they are not. There are creation, design, maintenance, data entry, report generation and other costs associated with this.
Admittedly there should be more to it than what I can see. Is there any good reason why we are doing this? Can you help me understanding the usefulness of time tracking systems for developers? Do you have a good example of how it is actually used in your company or team? Please help me understand time tracking.