All longitude and no latitude: the joy of timesheets

Ah yes, time. Bit of a sticky one. We can’t evade it, escape its ravages or turn it back. It’s only a 30 minute walk from the Thames Barrier to the Greenwich Observatory, but while the former can contain (if not quite literally turn back) the tide, the latter can only mark time. There is a long and fascinating history of the relationship between time and tide.  In inventing reliable marine chronometers, John Harrison – whose story was memorably told in the Dava Sobel novel Longitude – not only reliably measured time, but made safe sea travel possible. Appropriately, his early timepieces are on display in Greenwich too, at the National Maritime Museum. To prove the point that time is inexorable, the first three are still running. So next time you fill in a timesheet, now you know one of the people to thank for the opportunity.

At which point, a confession. It’s not so much that I struggle to embrace the joy of timesheets (although that’s true), but that I struggle to do so when I see how they’re used – not by the people completing them, but by the people collecting and collating them. (And, quite often, not collating them.) The first absurdity is working out how to log all the time you need to spend logging your time. Timesheets impose their own overhead on the productivity they are supposedly monitoring. Every 15 minutes we spend recording our time is 15 minutes lost to a more productive task. It’s enough to spark anyone’s inner Dilbert cartoon (speaking of which …)

My own inner Dilbert duly sparked, a more serious point. Timesheets are, like most other spreadsheets based around recording, simply a historic snapshot. Compiling them doesn’t change anything – except, ironically, to take up more of our time. We’ve argued before that the most important question is ‘Why?’, and timesheets are a prime case.

As someone pointed out in the beautifully titled post Time Sheets are the Agile Antichrist (Rant Alert!) at upstarthq:

In my opinion once you’ve reached the point at which you’ve so far distanced yourself from value generation that the metric used to gage [sic] performance is time, with no relation to throughput or quality, then it’s time to scuttle the ship.”

Humanity’s faith in the idea that you must measure things to be able to manage them has led us to some absurd places, mainly as it’s too tempting to maximise our energies measuring what’s easiest to measure. And those ticking hands make ‘time’ a much easier, more quantifiable entity than quality or (heaven forfend) ‘purpose’. I’ve previously mentioned one fine example of the granular detail being present and correct and the bigger picture being absurd: a University responding to a research funding application process, where the staff time spent on making the application cost more than the funding received. At least in that example, one of the Vice-Chancellors had the wit and gumption to get the time spent making the application recorded so that calculation could be made: for once, timesheets proved a valuable point. ‘Why are you doing that?’ is always a better first question than ‘How long are you likely to be spending on that?’.

But I’ve lived through far sillier. One medium-sized IT company had started, in true 90s fashion, as a bunch of geeks in a garage. A few successful years later, it was now a larger bunch of geeks (with a sprinkling of creatives and admin types) in an office that looked oddly like a garage most of the time. In those heady pre-dot.com crash days, projects were routinely hugely profitable: websites were the new ‘must have’ of the season, and companies had no idea what to pay for one – but they were sure they needed one. (There are several other rants to be had there, but perhaps for another day …) Quoting was all a bit ‘rule of thumb’ – so many hours for design, for programming, for testing – but the geeks who’d worked on similar projects had input to the quote, based on past experience of similar projects. If any of us had been the type to wear a tie, we would have had to loosen them or succumb to a fit of the vapours – but it worked very profitably. It also acknowledged, surprisingly intelligently, that even the most informed estimate of the amount of time required to complete the brief would have very little impact on how much the client was willing to pay. Mostly, the decision was “Can we do x in n days for £yK?”. (And mostly it was ‘yes’, depending on the size of ‘£yK’.)

Then the crash came, and a reality check arrived. This also cleared the air of a surprising number of people who thought they could just fling up a website and be the next Jeff Bozos, which was a blessing. The majority of these people got a short sharp lesson in supply and demand without us having to stop designing, programming or copywriting long enough to deliver it to them. But it also meant that more sensible businesses became rather more interested in budgets, timescales, costs and so on. (They also, as the web grew up a little, wanted more sophisticated websites with slight more point to them. Some of us were left feeling a little like Slartibartfast, pining for the good old days of crinkly fjord modelling on unlimited time and materials …)

So it was declared that a timesheet system was needed so we could measure Estimates against Actuals. One of the geeks have previously written such a system, it was duly installed and stern emails circulated that it must be completed every week, capturing time against project codes in 15 minute chunks. (Er, do we have these? Who issues those? What was the code for that project again? Do we issue the code when they accept the quote, or when we start the sales process? Do we have different codes for different stages? And so on.) And lo, everyone worked late every Friday feeding the new digital cuckoo.

Six months later, the geek in question checked the server. No-one had ever accessed any of the reports. And a few more months later, this vast pile of carefully captured data still sat unviewed. Word spread. People were recording an hour’s flower arranging, 15 minutes flossing, 30 minutes in meetings with each other that hadn’t happened. Claiming outrageous periods of time having their bikini lines waxed, when any self-respecting HR team would surely now it should be an hour absolute max. The most frequently chosen sub-category of our labours was ‘Creative writing’, apparently: as we only employed 1 copywriter out of a team of 23, we were obviously a fantastically literary office.

And than about a year later, our brave geek turned off the system without saying anything. (As the management team didn’t complete timesheets, they didn’t log in anyway.) As far as I’m aware, other than in mocking moments in bars, no-one mentioned the timesheet system again. As there was a separate production control system, the same arguments about resources, deadlines and capacity raged on … and the point had been missed. All that data that would have informed the estimating and quoting process – so that the company could decline jobs that would never be profitable – was never viewed. As the market tightened, we worked longer, harder, and usually less happily. Designers and programmers were castigated for not meeting deadlines that had been reverse-engineered from quotes. Not so much cart before the horse, as lovingly building a cart and leaving it in the stable to rot after the horse bolts.

As I can’t put it better than one of the comments on a post at techdarkside.com, let me just quote from it:

There’s actually a good reason to track time: estimation. A lot of organizations with salaried employees implement time tracking systems for exactly this reason (and then never use the data).

How does it work, you ask? Let’s say I’m UberMegaCorp and I bill my clients by the project, on a contract basis, and pay my employees a fixed salary. I set the delivery date, the number of resources required, and rates based on the scope of the project, the complexity of the tasks, and the skills of my resources. If I grossly overestimate, I’ll bid myself out of the contract. If I grossly underestimate the time and resources involved, my employees are going to be very overworked…which leads to an unhappy, unproductive employee (and occasionally homicidal rage, but let’s forget about that for now). If I slightly underestimate, my employees probably won’t be disgruntled the first or second time, but constantly doing it will wear on them, and I’ll be cheating my shareholders out of profits.”

Mercifully, my erstwhile colleagues mostly managed to forget about their own homicidal rage most of the time too. But if you want evidence of the potential pitfalls of measuring without understanding why, or what you’re measuring for, there are some pretty hefty boot-shaped dents in some web server cases somewhere in Birmingham that might give you pause for thought.

Add to: Facebook | Digg | Del.icio.us | Stumbleupon | Reddit | Blinklist | Twitter | Technorati | Furl | Newsvine

Add to FacebookAdd to NewsvineAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to Furl

Filed under: behavioural change, HR, leading performance, life, line managers, management, relationships, reward and recognition, talent management
Link to original post

Leave a Reply