There is a lot of resistance to timesheeting, and this appears particularly to be the case amongst development teams. As an ex-developer (and still occasional developer), myself, I remember being in the same camp. But as I’ve progressed (upwards, for the most part) and have to start accounting for my department’s cost, I have concluded that the only sensible way to gain useful metrics is via employee timesheets. Timesheets, alone, however, don’t provide all the information that I (or my superiors) require, and so should be used in conjunction with other systems and tools.
Having moved from being dead-set against timesheets in my early career, towards understanding their benefits and, ultimately, near-evangelising about them, I believe that the single most common reason why they are not so readily adopted is a matter of communication.
So what are the detractors saying? Here are some of the most common issues that I have encountered:
- It’s big brother – I don’t want my every move recorded.
- At the end of the day I can’t remember / don’t have time to record everything that I did.
- It will show that I don’t do a full day’s work & I’ll be penalised / pay docked / flogged.
- It will highlight the days when I am late for work.
I can understand all of these – I’ve felt them myself.
So what’s good about it? Here goes, in no particular order:
- No-one (at least no-one who understands how people work) expects you to put in a full day’s productive work. It’s not possible. You make tea, have a cigarette, read emails, attend meetings, get distracted by a conversation that someone else is having. These are all times when you are not ‘being productive’. But, it would be an awful place to work where you couldn’t do any of the above and were expected to be productive from the second you sat in your chair until the second you could go home. That would be a Victorian work house; you don’t work there.
In the more progressive working environments, bean bags, pool tables and games consoles are available; it’s understood that people are more effective when they are able to step away for a break – they get more done during their ‘productive’ times.
If I see a timesheet and on it Bill says that he’s spent 8 hours developing ‘Product X’, then there’s a problem; it simply can’t be true.
- So what if you get into work late? We don’t expect you to be 100% productive (see above), so the odd half hour here or there isn’t going to break the bank. If it’s going to be a regular occurrence, make an arrangement with your line manager. (The issue is not that you are late – it’s that other people see you coming in late and ‘getting away with it’. If you have made an arrangement with your manager then they can rebut any ‘tuts’ etc.) The one thing you absolutely must do, though, is apologise for being late (in the case where it’s not pre-arranged), but that’s just politeness.
As an aside, I think it’s worth stating at this point that there are two ways of implementing a timesheet system. One that tells you what a particular person was doing at a particular time of the day; and a second that simply tells you how much time was spent on each task during the day. It’s the latter that I would always advocate; It resolves a lot of the issue with people remembering what they did when the end of the day arrives and it’s quicker to enter information in this fashion. It’s true that the information entered is likely to be less accurate than ‘at the time’ recording of the information, but these things average themselves out in the long run. It also depends a lot on the granularity of your system – whether you record by the hour, half hour or quarter hour, for instance.
To a certain extent, timesheets are big-brotherish. That’s kind of the point of them. However, I see this as a good thing, rather than a bad thing. To the person who says to me “It’ll show that I didn’t work full-time on ‘Project X'”, I’ll say, “Yes, and it’ll show why.” – When my boss says “You said you’d deliver Project X by today – why is it going to be 2 days late?”, I can say “Because Bill spent 10 hours working on that little side-project you insisted on chucking into the mix.” (Although, as a good manager, I would have flagged this far sooner than d-day, of course.)
I need to know what my team are working on. I can’t sit over their shoulders 24/7 cracking a whip, I certainly don’t want them to have to work like that, and I can’t be a constant gate-keeper, making sure that nothing off-piste gets added to their work lists. But at the end of the day (both literally and metaphorically) I want to know that these things have happened and how much of a distraction they were. With this information I can better estimate timescales, costs, schedules, etc. And that’s a good thing. It’s the very nature of needing to know all these asides and distractions that makes the implementation of a timesheet system so compelling.
Rather than a conclusion, I thought I’d share my thoughts on where this is going. Firstly, I’ll be looking into ETT – Emergent Task Timing and will feed back on whether that might provide the compromise between accuracy and efficiency with regards to timesheets.
Next up will be about metrics, statistics, and KPIs. Timesheets and other tools will be involved.
You have been warned.