Hourly Rates Considered Harmful

So here you are, on a project, and everything is going great. You are delivering value, your customer is happy, and all is well and right with the world. You are doing Agile – including the parts like pairing and TDD that lots of people pay lip service to but far fewer actually do. You even are getting to use innovative technology like F#, Clojure, JRuby, Hadoop, NoSQL, Knockout.js, or one of dozens of technologies that somehow manage to enhance your productivity. Awesome!

One problem though. Your rates are too high. Can you help us train this group over here to be like you? They work for 1/3 your cost, and don’t ask us lots of hard questions all the time.

Sigh.

Of all the ways to sell services of higher end technology consultants – if I had to choose a worst way – I think I would end up with hourly rates. It is the same measurement vendor management departments in most large companies use to “price” the services of said consultants.  Unfortunately, it is a number that, in isolation, tells you very little of importance, for two main reasons:

  • Measurement of effort at the wrong level of precision
  • Measurement of cost irrespective of value delivered

Measurement of effort at the wrong level of precision

How many people are doing estimates on a per hour basis? There may be a few, but I highly doubt there are people other than GANTT chart driven control freaks looking to normalize that kind of thing. The reality is that, as a developer, I have a mix of useless hours, and a few really good ones where the vast majority of the value get’s delivered. The whole hours thing is a vestige from the temporary employment industry where programming was considered a fancier form of typing. We need to recognize it for the vestigial tail it is.

What should replace it? I am a big fan of weekly or monthly rates when working under a time and materials contract. I don’t mind the idea of “per person-sprint” either – which fits nearly into the idea that we would rarely fund only a percentage of a given sprint or iteration. I am open to other models that match funding with the unit of work, but do so in a way that you can know in advance (i.e. I would reject per story on the basis of you can only estimate effort – and it brings on too many potential fights or negotiations about how big a story ended up being).

Measurement of cost irrespective of value delivered

The precision issue, however, isn’t the biggest issue. The biggest issue I have with hourly rates is that they are the denominator in a much more important number, that being ratio of value delivered to cost. This issue is an old one, well covered in Joel Spolsky’s post on the subject. The specific problem – however – for higher end consulting firms, is that rates tend to be higher. Without considering value delivered in part of the equation, rate conversations tend to always be self-defeating, as it highlights the cost, without talking about the value.

The problem, of course, is that value delivered is often a squishy thing to measure, while you can read the cost per hour right off the invoice. To me, this is the biggest reason why Continuous Delivery is important, particularly the kind that has a feedback loop that measures financial performance – it allows us to actually measure the numerator in the value delivered equation. In the best of all worlds, we move to a funding model that funds the Minimum Viable Product up front, but then moves to a Evidence Based Funding model (aka “Continuous Funding”) based on value delivered via Continuous Delivery.

Something Has To Be Done

The funding model is broken. It has been for a long time, leading to sub-optimal results. Competition by rate irrespective of value delivered is a race to the bottom, leading to all sorts of bad outcomes for companies that get involved. Sadly, too many do. Continuous Delivery is a start, perhaps if we can get to Evidence Based Funding – we can actually sustain continuous delivery.

About these ads
Post a comment or leave a trackback: Trackback URL.

Comments

  • Ben Edwards  On October 19, 2011 at 3:07 am

    This is a great post. I always say that it is hard to just put your hourly rate out there on its own because, in a vacuum, it will look high. It isn;t until 2 months into a project and we’re nearly done with something other teams told them would take 6 months or more does that rate look a lot better.

  • Brian C  On October 20, 2011 at 12:34 pm

    This applies to any type of deliverable, software, engineering, web development, copy writing, etc.

    Although I have an hourly rate in mind, I estimate jobs in half or whole day chunks, and propose an explicit deliverable for a fixed dollar amount. This works best for small projects, say 5 days’ expended effort, and I find it best to break bigger projects into chunks that I can estimate with more confidence.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 29 other followers

%d bloggers like this: