Better Time Tracking

Time tracking of software projects is woeful and hated. Here is an attempt to address this problem. As you may know, I'm involved in improving the estimation of our organisation. The other side of estimation is time-tracking, firstly, some context;

I hate doing weekly timesheets.  I hate them because they do not help me improve project delivery. I hate them because the PMI-droids think (sic) that this is what they need. I have worked in numerous organisations where we must keep a timesheet. Usually this meant logging into the unwieldy timesheet application which someone developed in their spare time and adding my time data for the entire week just passed.

The granularity of these entries was always at the project code. So for example, if I worked every day on Project1, I would log all my time as one block against Project1. What it never captured is the fact that one particular issue took four times as long as it should have. Because time is logged only against the project we can never look at where we spent our time as opposed to where we expected to spend our time. All we get is that project1 took more time than it should have.

Part of the problem is that the PMI-droids use a very blunt instrument, the gannt chart, to try and manage the project. MS Project is a uni-directional tool. As you and I know, what happens in a software project is quite removed from the gannt chart. New tasks are needed all the time, which quickly invalidate the project plan and making it a useless artifact. Basically, there is no feedback loop.

What is needed to solve this problem is a bi-directional, bottom-up, project management tool where time is track at individual task level. Tasks need to be created at whim by individuals as needed. Time spent needs to be assigned to each task, which can then by categorized in any manner required by whoever wants to categorize. Typically, in software projects, this will be things such as phase of project, component, technology, etc.

The place I currently work at uses an issue-tracker as its central work-organizing system. It's a great tool, extremely flexible and fits our issue-tracking needs quite well. We use it for all types of work, development, support, general-day stuff. In fact, it's almost the perfect bottom-up time-tracking project management tool I'm looking for. Additionally, the corporate culture encourages people to use the tool.

However, time tracking is spotty and variable. Bottom-up issue creation is spotty. If people can get away with not creating an issue, they will. Like me, we're all lazy. The tool is a little unwieldy when it comes to entering time data. It's a couple of clicks and a bit of waiting, once you've found your issue. Like other form-based apps, it's a bit cumbersome to create a new issue too.

We initiated a daily status report about a year ago, which is itself a bit spotty and of variable use. The basic idea is that you write about what you did/achieved in a day, so that team-leads, project-managers, etc know what you're up to. It doesn't replace a daily scrum or things of that ilk.

So, now you have  the context to see my diagram.  This is my first attempt at a cause-and-effect diagram. I'm not sure I've really gotten it right. Sometimes my arrows seem like relationships rather than causes. Nevertheless, this diagram crystallizes my view on how this whole "estimation" process needs to work. This system is not in effect yet. It's close, most parts have been proto-typed quite deeply. Some parts have been released to production in a "use at your own risk" state. I'm interested in other people's experiences with putting together a time-tracking system.

I've labeled all the arcs for ease of explanation. Unfortunately, I can't really show any screenshots of things as I feel that would get into trouble from my managers.

Firstly, we've implemented the lowest possible transaction-cost time-keeping system that's possible. It's a command-line tool that allows you to log time in less than 10 seconds, create an issue in less than 30, or even edit some attributes of existing issues.  Because we're all software developers we can get away with this. It has other useful features such as listing, etc. By taking away as much friction from the process as we can we allow the possibility of more accuracy.

arc a and b:
Usage of the time-keeping system reinforces the use of the daily review process because the daily time spent is viewed during the review process. The review process confirms that the time logged into the system is valid and that nothing has been missed. The use of the daily review process reinforces the use of the time-keeping system because you know you have to validate the days work. What we have here is a reinforcing loop.

arc c and d:
There is such a concept as a project dashboard in our organisation. This dashboard is a collection of current metrics of the project. Things such as number of issues in various states, time logged, etc. It also serves as a review of who has used the daily confirmation process.  Because you know that your project lead will come after you if you don't confirm your day, you tend to do your daily review process.

arcs h and q
Developers do not know how good they are at estimating. We've developed a report that identifies different roles in each estimate and we present this data back to the developer to help them improve their estimation. My goal with this is to have a troupe of developers who can quantify their skill and thus take measures to improve it. I would love it if in their next job interview a developer could say "my estimates are +/- 10% and here I have the data to prove it". Because of this, I feel there is direct value which can be sold to developers to motivate them to keep accurate time data. Time keeping stops being a task that needs to be done to satisfy the masters, but has an element of self-interest. It's this value I'm going to be selling to the group when this gets its release.

arcs e, f, i and g
Because of the three reinforcing loops above, you end up with more accurate time-keeping. For the astute reader, you may notice that I've tried to create a value-proposition at each level of our organisation. The individual is incented and cajoled (carrot and stick) to keep accurate data. At the project level we have the dashboard that uses this data to measure the current state of play and obviously, at corporate level this information is just gold. Do you agree?

arc k
Now, once we have excellent time-keeping data it turns out we have also have a corporate estimation history. This is because we estimate and keep accurate data at the issue level. Corporate is really just an aggregation of each individual. If we tag issues in various ways it is possible to slice and dice the estimates in all sorts of ways. There is definitely room here to improve, but as a release 1 of this system it'll do.

arc n and i.
These two forces represent those that drive us towards standardized estimation methods. The estimation report highlights people's poor estimation skills causing them to look for better ways of estimating than their current method (usually finger in the air). The corporate estimate repository also highlights the same issues as it is just an aggregation of all individuals estimate history. This means, they might look for something like this. The trap is set!

arcs o, j, m, n, p
All add up to firstly, knowledge of the quality of our estimates and then hopefully an increase in the quality of our estimates.

What do people think of this little story?

tags:  estimation  function points

Comments

[Robert Bousquet]

What is this command line tool that you mention? I'm looking for something to keep track of my time on projects without leaving the Terminal. If I can find the time tracking version of devtodo, I'll be set.

[Fabio Cevasco]

@Robert

If you are looking for a terminal-based time tracking utility, then RedBook may be what you're looking for.

http://redbook.h3rald.com/

A free, open-source, interactive Ruby script to log your daily activities and track your time.

[John]

I like the arc visualizations and explanations. And I agree with your story. We use Intervals for our time tracking and task management. We built it because as developers, we had the exact same dilemma as you. The high level doesn't work. We tackle our projects from the task level, tracking time against each task and using a timesheet only as an aggregated view of the week.
http://www.myintervals.com