Saturday, 7 September 2019

Billing - A Better Alternative


When I was Head Of Development at The Cogworks we originally tried to bill by the 1/4 hour. It was insanely granular and cause many undesirable side effects and habits. Even if we rounded up numbers to meet 7hrs per day, it seemed that projects were just not profitable. It was quite hard to get my head around it, but much of this was because linking estimations to "time spent" to "billing" was causing many assumptions about workflow which were just wrong.

For example, we all should know by now that 1 dev working solidly for 7hrs is more productive than the same dev trying to work on different 1hr tasks. Nothing ever takes an hour. Downloading a code repo & getting it running could easily eat up 1 hour. Super granular estimates were linked to granular timesheets and billing which never accounted for context switching. So on paper we were always going "over budget". Crazy right?! I still find this hard to think about, as it does seem counter intuitive. Basically, when you context switch, there is a significant amount of time you need to waste on gaining speed. Kind of like a car being stopped at every traffic light.

A Simple Elegant Billing Model

  • 0.5 to 1 day billing increments
    • Use this for items which are estimated to be around an hour to several days
    • Even if an item is "estimated" as trivial (perhaps 1-2hrs), just charge 1/2 day
  • 1 - 2 week "project team" billing increments 
    • Use this for chunks of work which is estimated to be weeks to months long
    • A team may consist of 2 devs, Producer, Designer and QA
  • Emergency tickets are pre-sold at 2/3 day billing increments
    • This is essentially prepaying for disruption
    • Gives you the ability to ask the client "do you want to use your pre-bought ticket" or is this ok to just schedule into support & maintenance?
    • Tickets expire after 3 months if not used

This billing model free's up your developers from the shackles of timesheets, and also builds in adequate buffer for all those random project comms and meetings. When I introduced this at the Cogworks, it was as if a burden had been removed from day to day life. Everyone was happier.

No comments:

Post a Comment