2 min min read - December 5, 2014
"laws were most numerous when the commonwealth was most corrupt" Tacitus
Time tracking in projects is one of most hated elements of project management. It's not without a reason. From company point of view visibility on time usage (when time and work are resources) has huge value as it eliminates unknowns. The problem is that business is not always ready to hear the answers.
In the end literal time tracking always turns out another corrupting law (as in the quote) or evidence of such corruption. I would like to present three scenarios how time tracking can (or shouldn't) be used - all founded on my experience:
Most of mature organisations I worked with never used actual time tracking. They used pointing systems from agile methodologies like Scrum, Kanban or Lean and accepted that value of points is dynamic in periods.
Agencies are very different from actual product owning companies. Agency has precise budget and doesn't own decision on shape of the product. Agencies therefore try to unify products. This way they can defend budgets in front of the client by comparing them to real cases from the past.
There is situation, when time tracking can work as a "sword with two blades". In case of working with unexperienced product owners, who extend expectations without investment in resources (time, people, culture and knowledge). Many of us know quite arrogant questions like: "why it takes so long? what have you been doing? it is so easy, why we are delayed?". First of all in many times such questions are result of giving deadlines to set (or growing in time) goals without listening to the feedback/estimation (or without using LEAN methods which exclude long term planning at all).
For both Agencies and developers who needs defence strategy I suggest using Toggl. I have no connections to their team, but I personally used it and it saved me a lot of pain. It adds value to existing task management software and doesn't require replacing them.