Why Hourly Charging can be a Win-Win for Client and Agency

Posted by Paul on March 11, 2015

Along with writing documentation, quoting and estimating on complex programming work are some of the most time consuming and difficult tasks a developer has to undertake. Although often a necessary evil, estimating usually lies outside of the type of work a programmer is best at and often doesn't align well with their strengths or interests which mostly include doing the programming work itself. Alas they are often the only team member capable of estimating because of the deep technical knowledge only they possess. That being said, the somewhat surprising fact is that even the very best developers are often unable to estimate accurately. The natural bias is usually to underestimate a project or task because it may be very quick and easy to describe in words, but once the task has started it may become obvious that the system must only work in a certain way which will require significant extra time.

It is possible to estimate accurately on projects that are very similar to ones already completed or projects that are made up of features that have been completed before (although joining those could cause issues) but generally speaking the time taken to complete software projects has a very high degree of unpredictability. This is why many large scale IT projects make the news for going over budget such this £11.4bn NHS IT project or this £100m BBC IT project. This is rarely due to neglegence on the part of the supplier or client, more often it's just the nature of IT work itself although there are of course exceptions.

Of course the IT industry is one of the biggest industries in the world and although compared to many others is still very young, it's been around long enough for some brilliant and practical minds to have come up with workable solutions in terms of project management methodologies. Just briefly, one of the first is now called "waterfall". This is where the entire system is "scoped out" and a detailed specification of the entire system is written out before any code is written. More recently "Agile" has been in vogue where a project is split up in to far smaller tasks which are group together in to "sprints" usually lasting between a week and a month. With this approach it's possible to adapt the system being developed to user needs or based on new insight gained during the development thus far, hence it's agile.

At Antropy we rarely (okay never) work on projects with £11.4bn budgets or even £100m budgets (although we have worked on six-figure projects) and much of the work we do is bug fixing and support type work. While not big enough for Agile, Waterfall is also pretty inefficient here too. Both of these methodologies add far too much overhead to be useful when a bug fix or new feature might take from 2 hours to 3 days. Understandably though, our clients do like an idea of the cost before giving us the go-ahead, we're not keen on writing blank cheques either.

So we have 2 main options:

  1. We can provide a fixed quote for bug fixes/new features, meaning we'll have to spend time investigating your current code, exploring your requirements coming up with a figure and then adding considerable contingency to cover unknowns. We'll also have to round up very small tasks to the hour or half hour due to administrative overhead such as invoicing/management etc.

  2. But there is another way, which does require an element of trust but often works out far quicker and cheaper. That solution is for us to work hourly on your tasks. Now this suits a certain type of work well, such as multiple bug fixes or lots of small new features and changes. This is because bug fixes are the sort of task where if you know enough to estimate accurately then you already know how to solve the bug and getting to a point where you can estimate is where most of the time will have been spent.

For these types of task, working hourly is perfect! Our developers log time in a special online tracking tool as they work and write comments about what they've done in each block of time logged. At the end of the month we provide a detailed timesheet of the date, time, length and detail of every bit of time spent.

But what if something ends up taking too long? Good question, and of course we can let our client know well in advance if a certain issue looks like it's going to take more time than expected. On the whole we complete things far more efficiently this way as we won't have to estimate in detail, provide a written proposal, send a deposit invoice and a balance invoice, chase those up, then refuse additional changes as "out of scope" ... instead we can just get started. Recently one of our PHP developers, James has proudly turned round and said a couple of times "that's done, 4 minutes logged!" For another client we completed a basic ecommerce site setup and go-live for around £600+VAT when working this way.

So for small, ad-hoc bits of web development work, consider setting up an hourly account with us - you may be pleasantly surprised!

blog comments powered by Disqus