This is the goal. The method is the by-product.
(You may want to read parts
one,
two,
three and
four first).
So after much discourse on billing methods and the complicated relations that exist between a client and supplier, the question remains: how do we do it? The following post outlines how we try to “bill with integrity”.
We do weekly billing
Virtually all our billing is now done on a weekly basis. We charge a fixed price (yes I know, bear with me), for between one to four developers for a week.
We prefer to put either two or four developers on a project for a week. This is best for most projects, so that they can pair program on the tasks. One developer is ok for R&D, prototyping work or very small amounts of work, but not recommended as you lose all the advantages of pairing.
When asked to quote work, we give an expectation of budget. We might recommend that a client book 3-5 weeks of time for 2 developers for example. It’s easy for everyone to work out how much that will cost, which promotes transparency.
We don’t charge extra for management time. All our management time with this billing method is rolled into the weekly cost. Therefore no nasty ‘management fees’ on the bill – what you’ve agreed to is what you get billed.
We build slack time into the project. All our rates are based on the fact that developers are unlikely to be able to spent more than four days of development time per week on a project. There are bug fixes, side projects, internal work, research, learning, review meetings, sick days, etc to consider.
We don’t stop at “enough”. We only guarantee to complete three days of work at the beginning of a project. That doesn’t seem like much a week, but because we don’t stop after the amount of work we’ve guaranteed, we’re not wasting the client’s time. If we have time we keep on going, all the way through to the five days if we can. Therefore we often over-deliver on a week’s booked work. We strive to ‘gently exceed expectations’ (as detailed in The Pragmatic Programmer; which is a must read, by the way). Pivotal Tracker helps track the velocity for a particular project, so we know how much we can expect to deliver on a project on any particular week.
So how is that different to fixed price?
There are elements of a fixed price methodology in this billing strategy. We do fix the price for a week’s work, for example. However, we don’t fix all the features that we can might deliver within a week, and we’re conservative with what we guarantee. This ensures that there is an appropriate amount of contingency built in, so if a project starts to get bogged down it doesn’t affect the schedule. Our estimates are done in half-day chunks using the planning poker method, which also makes them pretty accurate.
If a client is insistent that they need a fixed price, we simply say that we’ll add a certain percentage to the quoted cost for the number of iterations we’ve recommended to reflect the fact that we’re taking on more risk in the project. We’re quite honest about our reasons for doing this. If a client finds that difficult, we’re probably not the right company for them.
Aren’t you still charging a variable rate?
Well, sort of. You could say we’re charging per week as opposed to ‘per hour’, so what’s the difference? There are a number of distinct advantages that this model has over ’straight’ variable billing.
No need to clock time, for managers or developers. Variable billing requires meticulous records of time spent. We hardly ever need to do this now, saving the hassle of timesheet keeping, approval and complex invoicing.
Weeks are much easier to schedule than hours. Before switching to this model I found myself heading round the office at least four times a day to make sure everyone had enough work to do. Even when we made this more automatic, it was still a problem – it was really hard to commit to definite deadlines and everything was too fluid.
There’s much less context-switching for developers. With fully variable billing, everyone still found they were switching around between projects several times a day, which can be very confusing and inefficient. Now there’s at most 2-3 projects running at once, and there’s much less switching around – less than once a day for most people.
The team is much more focused over a whole week. Before we found we were effectively acting as several independent freelancers, all talking to individual clients and getting on with their work in isolation. This worked ok with much smaller projects, but it doesn’t scale to multiple team members on one project. ‘Silos’ of knowledge began to build up, and getting a new team member up to speed was hard. Now we’ve moved mostly away from variable billing, we’ve been able to pair program over the last few weeks and that’s really helped to break down the silos and promote communication. We’ll be posting about our experiences with pairing in a future post – it’s been so significant it’s probably worth another series :)
Some closing thoughts
It’s been great to write this series, because it’s really forced me to think about our billing strategy hard again, striving to ensure we have integrity about our billing. You can’t exactly write a series such as this and not be walking the talk, right? My thoughts have evolved as I’ve written it; there are some things about our current billing method that would be quite different had I not written this series.
A few extra thoughts as I round this up:
Billing is hard. That should be painfully obvious from some of the previous posts. We’ve learnt an enormous amount from our successes, but even more from our mistakes.
Ultimately it’s about the relationship. A great relationship with the client will help to soften any billing issue you get into. Likewise, a bad relationship will be hard to save if things go south.
And lastly, probably the most important thing:
We’re not done with improving our billing model. We’re on a journey, same as everyone. There are disadvantages to our current billing model too, which we’re looking for solutions to. Have you found a better way of working? Let us know!
Thanks for reading.
