Last update: 02/06/2016 13:53

Purpose of Timesheets

Timesheets exist to track employees' time so that Management knows how much time was spent on which tasks. From there, it exists to serve different purposes.

The information recorded with the timesheets can be used in a number of ways. For example, at Lato Sensu Management, people record the time they have spent on which project so that we know how much needs to be invoiced customer by customer (we also distinguish between billable and non-billable tasks). Other example, in Project Management, timesheets are used by Management to track the time spent to complete a task, all people together or separately, as to compare it with the original estimate. In other instances, the time recorded to complete a task can help estimate the next same kind of task for future needs. In other situations, timesheets can help organizations to compare assignments vs. actuals and therefore better adjust the use of resources.

This post does not deal with timesheets as a means of invoicing (and all similar concerns). We rather address the way timesheets are used to track project progress and comparison with the original plan in softare development contexts, and nothing else. We therefore narrow vigorously the scope of this post.

The Timesheets Fallacy

Anyone who has worked in a closely manner with timesheets should have natural doubts about them and more particularly about the info it carries, not to mention the use we make of it.

In the author's specific case, the first time he had to record his working time was in 1987. In a small PC cell team members needed to book their working hours against a number of tasks. Unfortunately, timesheet tasks did not match real work/tasks. For example, time spent writing code that would benefit several projects could not be booked properly because such tasks simply did not exist in the timesheets system (they were mostly unknown to Management which wasn't interested in the technicality). Then, to fix this problem, employees were told to allocate this time proportionally to the projects benefitting from these common routines, which is a first false approximation because nothing can assure that indeed the benefit is proportional. Later on, as the PC Cell grew with additional resources, such common work was counted as separate tasks, which unfortunately did not match anything the department had mission to build. So, it had to remain "hidden" and each employee had to book time on other projects simply as a way to finance these tasks. We can continue on the subject but it wouldn't prove better why this became easily false info, info sane people would simply disregard.

More recently, the author came across a situation where a member of an agile team, serving multiple projects, had a timesheet task list long of 176 tasks. The result was that this fellow team leader and developer usually chose a page of tasks at random (176 tasks did not fit a single page of the timesheet system) and simply made it such that 40h got booked per week, no matter what tasks were on the page. How is that for valuable info an department digests to get better organized? You can argue that this employee was cheating. Actually, the author once sat with him to take the proper measure of the problem, and both played the game of really filling the timesheets: it took them 63 minutes to play the game in all honesty. Are we about to have a 'filling timesheet task'? That is what we're about?

Last example: in a company where the timesheets system got so slow to start up, employees filled their timesheets with weeks delay (some even months). Managers of course got nervous about that because they could not control how departmental budget was spent nor they were able to reassure ExCo about the proper handling of the annual budget.

Running Costs

When working in a project-based mode, one is soon faced with a contradiction: the department running costs, also called baseline in many contexts. What is the problem?

The problem lies with the fact that running costs are perceived as (useless) overhead. The tendency is therefore to lower them to the max [1] … by hiding them in project costs. To permit this stratagem, new vapor tasks are invented in the projects. Another way of taking it from the projects is to inflate contingency, a method that we have seen at work in may occasions. In most cases, it is not identified as cheating and, in many cases, it is not. It is simply convoluted tactics to circumvent a well-known problem, which makes our point even more sensible: what is the real info conveyed by timesheets?

Another concern of us in that matter is the unbalanced importance of real running costs versus the curent portfolio of projects, in other terms what happens when the portfolio of projects is drained out to a point where the running costs can no longer be kept hidden in the project costs. We leave it up to you to see how your own organization adjusts to this situation.

The Weight of Governance

The weight of governance is usually not well captured with timesheets, unless all related governance tasks are tracked individually [2] .

The Weight of the Context

The weight of the context is also very missing. The reality is that the impact of the context could be evaluated with timesheets but is usually not. No one for example will take/have the time to compare in what two different contexts can influence the costs. What we are about to put in evidence here is that most companies do not compare the contexts even though timesheets could be valuable info to do so. We simply have not invented A/B Organization Context Testing yet.

If not Timesheets, What Else?

It is not timesheets that must be combatted, it is the level of detail and the info we derive from the data that were collected. You probably need timesheets (this is really up to the organization to determine).

In the context of Agile projects, goals such as progress measurement and the likes are debatable because they do not prove to bring any further knowledge (and therefore value) that can benefit the company.

Effective Time Writing must respect a set of simple principles.

Rule #1: Tasks to book on must be displayable on a single page with no scrolling needed. Should you have more, then it will be assimilated/perceived as micro management or it would mean that people are multitasked, which we now know scientically as a major problem. Any of the two be aware of the fact that nobody will fill the timesheets with the expected precision. If you come to trust timesheets info (not data) in a dumb way – you or some sort of formula – it will simply make the bozos line bigger and this line is already big enough. Our recommendation is to not exceed 8 tasks people can book against.

Rule #2: Time booking should be done every day, or every week max.

Rule #3: Time booking should take less than 1 min to complete, or 5 minutes a week.

Rule #4: Timesheets approval must be done by the closest people having managerial responsibility and authority of doing it (the ones having direct "supervision").

Rule #5: If you can avoid timesheets at all, please do so and prefer Results-Oriented Work Environment (ROWE).


All these considerations need to be taken into account when trying to value timesheets information. Without the necessary distance timesheet info can easily mislead us and make us draw incorrect conclusions. Simplify timesheets to make people's life easier and to gain in precision/accuracy: do not collect data that can bearily be used in a valuable way.


[1] … This is obvious naivety: actually it is much more Machiavellian: people lower such costs down to a certain threshold they feel they can defend … and the remaining costs will be lowered year + 1.Usually

[2] … Even in that case the info that is captured is very partial because all downstream tasks delays and interruptions are not taken into account

Our website uses cookies to save your preferences. We kindly ask you to consent to our use of cookies when you first visit our website. If you do not consent, the sole recourse is to stop visiting our website. X