Tick, Tick, Timesheets!

by: Grant Rule

"Time is running out, and it's later than you think!" That, it seems, is the experience of many project managers. Why is there never time enough? Why does adherence to deadlines present such a problem?

Most organisations require staff to complete timesheets, but this is often seen as a painful chore. Timesheets are submitted, because the Personnel Department insists or for payroll. The information may be used for billing time to other departments or invoicing the customer. Unfortunately, few project managers or teams actively use the data. Yet it is such a rich resource for managing progress and project stability (a pre-requisite for achieving CMM^® Maturity Level 4).

Even where timesheet data is used by a project team, it is generally used only to update the schedule, usually by means of a task list and Gantt Chart. This really doesn't produce any deep understanding of the project's process, status or the likelihood that requirements will be fulfilled on schedule. Could you be missing a few tricks?

Let's look at how we might use timesheet data to improve the common practice of asking each team member to estimate, or re-estimate, the effort required to complete each assigned task. Project managers usually require team members to report the status of their assigned tasks with respect to the Original Planned Effort, Effort Expended and Estimated Effort to Complete. But how reliable are such estimates? Try plotting the percentage variance between estimate and plan for each task on a control chart. At least you'll see whether the team's estimates are worth anything.

The illustration in Figure 1 shows a task estimating process that results in estimates an average of 13% below actual. Furthermore, the process is erratic and needs improvement. Three tasks have come in under estimate: does this indicate that some team members are using a different, possibly better process? Could the rest of the team learn from their experience?

If your project has a product breakdown structure that enables you to identify a sequence of small 'releases' (whether they are really released to the users or not), it is informative to plot the cumulative effort actually expended against the planned effort expenditure. Figure 2 shows a project that is progressively consuming more effort than planned. Unless the budget is extensible, or pre-emptive action is taken, this project is going to run out of funds well before it has completed its objectives.

Many projects describe their customer's requirements in terms of use cases or user stories. This degree of granularity makes it feasible to track the Project Delivery Rate (PDR) achieved as each incremental delivery is made (see Figure 3). A control chart of the PDR per delivery illustrates the stability of the development process and can help identify special causes of variation and trends.

The example illustrated in Figure 3 seems to show a trend towards an increase in the normalised effort per release (ie, productivity is decreasing) and the process seems to be suffering from increasing variability. Early investigation of the special cause of this variation may make all the difference between success and failure for the project.

These three figures are just a sample of the information that can be extracted from typical project data. Complicated measures and tools aren't necessary. Much can be done with simple, common measures such as effort, duration, size and counts of the number of defects and their severity.

With just your normal timesheets, your work breakdown structure and a spreadsheet, you too could soon have your project running under statistical process control.