Time sheets revisited

Time sheets: The base for what to charge your client, how much you have burnt through your project budget, how good you and your team are at estimating, proof that you've done "your 8 hours", or that you clearly should be paid more as you did 55 billable hours this week.

Behind all of this is the concept that time (and multiplied by hourly rates costs) drives everything. All good?

Sure, why not. Except that this assumes we are getting paid for time ...

We are not getting paid for time

Ever. Almost1. Customers don't care how much time we spend (they care about the delivery time, but that is a question for resourcing). We are getting paid for value. Time is a measure we apply when we don't know the expected value, or tracking the value is deemed too difficult - for either you'd need to ask the question why you are doing it in the first place.

This thinking is driving a new approach to pricing, value-based pricing, with Ron Baker being one of its more vocal advocates. It proposes to find out what your service is worth to your customer - and evaluate if you are happy to do it for this cost.

I tend to agree, somewhat. I agree that everything should be based on the value for the customer. But I have some issues with its conclusion that if something is costing you $5, but is worth $5,000, then you can charge $5,000. Sure I could, it just feels ... wrong. I realise though how non-scientific my objection is, given that I don't even have the formula to determine what is appropriate. It is somewhat related to how many new cars I can buy from the difference ... anyhow, I digress, this is about time sheets, not finding the right price.

If we are getting paid for value, then time & materials don't make sense - and neither does a time sheet, as the customer isn't interested in the time we spent. And it certainly doesn't fit into an agile mindset, where everything is value-driven.

We also need to be profitable, though - which means we need to know our costs.

What if we don't know our costs?

Estimating is one way of knowing your costs - but not very precise: In software development you (hopefully) never exactly do what you have done before. Add to this uncertainty different experience levels, wrong paths travelled, and merely the form you may find yourself in on any given day, and an estimate is just a simple guess - something the #noestimates guys point out.

Another approach is not knowing, but instead controlling your costs: Set a price (perhaps based on estimating), and then manage your scope accordingly2. Ron Jeffries' "Thoughts on Estimation" provides some further guidance.

Tracking time is always after the fact - it doesn't tell how much it is going to cost. It may tell you after the project that you haven't controlled your scope correctly, or that you forgot to estimate something ... but didn't you know that already, during the first week? So, why do you need time sheets?

"But what if my customer wants time sheets?"

I don't think this is the right question. Why does your customer want them? In fact:

Why does anyone want your time sheets?

Most will answer something like:

  • to see if we just paid more than we needed to
  • to learn how good I was/we were at estimating
  • to see how Bob compares to Alice - of course only to help Bob develop to another Alice
  • to manage under- or over-allocation of resources

Let's face it: All of these are for the purpose of control - even if they don't look like it. Their purpose is to direct things differently next time.

At best this is well intentioned. But don't you already know that you mistrust your team or vendor? And don't you already know how good you were at estimating (see above)? And that Bob is slow at writing? And that Alice stays until nine every night? Bob knows. And Alice knows. Do you really need a time sheet as confirmation?

What does it help to know that developing feature X took four days? If you ever need to re-do feature X, why don't you just use the one you already developed? In reality, some features will look similar - however, the circumstances change: different environments, different people, progressing experience, progressing technology, they all make historic time analysis somewhat useless.

And further: By making your vendor, or Alice and Bob, complete a time sheet you are telling them that, as above, you will take care of allocation, efficiency and resources - so they don't need to care. Is that the behaviour you want to drive?

Numbers are absolute

Time sheets capture numbers - and numbers are absolute in their nature. Keeping time sheets assumes that time is recorded correctly - which is far from correct: The numbers recorded are not absolute, and therefore quite meaningless for any calculation.

Even if you manage to take some tolerance into account, unless you are ok to be 30% wrong, this isn't a good metric to start. So why waste your time to record, analyse or do whatever with figures that aren't worth anything?

Conclusion

Time sheets are useful if you:

  • Don't care about the value to your customer
  • Don't trust your team/vendor
  • Can't be bothered paying attention to your team
  • Need pseudo-scientific measurements to control lead

Neither of these works well for us. It brings the best out of developers - and vendors - if they are asked to think and act for themselves. I admit the first point is at times tempting when the value isn't apparent. But I can say, after years of completing and poring over time sheets: I never learnt anything from them.

  1. I think babysitters are the only exception, as they aren't paid for an outcome - in fact, there are paid so there isn't any outcome.

  2. I agree managing scope can be tricky as customers always want more. However, they also want you to succeed (if they don't you have a bigger problem). An open discussion goes a long way here.