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.