User login

On Measuring Time

 Stephan Dahl, May 4., 2009

Measuring Time is necessary for many things - demonstrating progress to the client, letting the organization learn from its collective experiences, and quantifying the contributions of the individuals. Yet it is commonly ignored if possible and ridiculed if not. This article tries to examine the reasons for this, and provides directions for increasing the value and reducing the hassle involved.

Obstacles to Measuring Time

Duplicate Collection

Any organization that mandates that its members provide the same data multiple times in slightly different formats to different parts of itself can rightly be suspected of not being completely in control of itself. This leads to the common practice of ridiculing the whole time tracking and metrics gathering process, which in turn leads to poor quality in the collected data.

Write-Only Data

When time data is collected, it tends to vanish into spreadsheets and consolidated summaries. If the individual can't see where the numbers go, it leads to suspicions that the numbers are being manipulated by other parts of the organization, for motives benign or dark. If the numbers may be unaccountably changed, the individuals responsible for their collection become less motivated to ensure their correctness - after all, they may be changed anyway, and tomorrow who can tell what numbers went into the soup? This, of course, leads to poor quality in the collected data.


We never know what we may be able to learn from data collected over different projects over periods of years - tomorrow we may find a clever use for the statistics we collect, only to find that it requires a large body of data to work. It therefore behooves us to keep the collected data measurements available indefinitely; It is rarely very much, in terms of raw storage, so there is no real reason not to keep it.

Inconvenient Input

The organization usually knows a lot about what its members may want to report time on - it knows the public holidays, it can remember vacation plans, and a well-planned project knows what tasks are being worked on by who.

All this information is rarely presented in a useful, digested format for the individual, who is left to keep track of time in whatever way they will. Since the individuals in question (for the reasons presented above) rarely care deeply about the quality of the numbers, this is usually a very half-hearted affair.

Requirements to Time Tracking

Having identified some of the obstacles to acquiring accurate measurements, we can now specify requirements to an organization and a system that can overcome those obstacles.

Enter Data Once Only

Any particular measurement must be entered once only. It is the responsibility of the underlying system to feed the collected numbers to any other system or organizational unit that may need them.

A user may be reporting time on multiple projects, as well as on non-project-related tasks including vacations, illness etc.; it is important that the system does not require multiple data entry in these situations.

"Entering data once" also applies to any further processing of the data - numbers must never need to be moved manually (from mail to spreadsheet to invoice to metrics etc). Any such manual movement is errorprone and reduces confidence in the values found in the downstream systems.

Keep Data Safe

Any number entered must be recoverable, by the system as well as by the entering user. If the data need to be changed, then a separate change entry is entered. Systems that don't need the change history will be fed only the end result of the initial entry plus any subsequent changes, transparently.

The System, not the User, makes the aggregates

The user enters number at the smallest practical granularity, and the system aggregates according to rules when it feeds the entered data to any other system that needs the data.

Make it Easy!

The system must show the available time-reporting tasks, granular to the level that they exist in the design, estimation and planning tool. The list of task should by default show only tasks for the specific user, for the current reporting period (week or day), but should be extensible to show all tasks that the user may report time on (including already-closed tasks, other peoples tasks, etc).

The system should require the entry of only a few numbers per day - the hours spent on each task, or start-time and end-time. The system must never require the entry of task codes or descriptions.

Tailor reporting to the Project

Different projects have different reporting and measuring requirements. It must be possible to tailor reporting such that metrics not needed for a project are not collected.