The usual approach to pricing service work is the hourly rate - a simple model that is easily understood, and translates well across different disciplines and businesses. Service work often has so many variables that an hourly rate seems to offer a good compromise between a fixed-price quote, and ensuring the supplier has flexibility to charge for unknown future work.
However, in practice, the hourly rate is a poor option for both parties. Taking software development as an example, it can be hard as a supplier to demand (or
not to demand) extra fees for hours incurred over original quote. For the customer, there is the worry that the hours will rack up quickly without results, or that she may end up paying for unused hours. At its most basic level, rewarding time with money encourages laziness - what incentive is there for a supplier to finish the job quickly, only to be paid less?
Charging an hourly rate really does no favours for either the supplier or the customer, yet continues to be the status-quo, as it's hard to find any simple alternative.
The Goal: Remove Time from the Equation
Like others, one of the many reasons I set up business was to escape the confines of
time equals money. In fact, as any business owner will likely attest, you'll often spend considerably more time working on your business than for which you'll ever see financially reward - but that's all part of the fun!
In trying to break the reliance of time from income, I started looking at different ways of estimating and managing my client projects. This is usually achieved in two ways: employ people, and generate profits on their time; or build and sell assets.
For a small software company, assets are often the dream: a product - or range of products - that keeps selling, and requires roughly the same investment in time whether you've sold one or one thousand. Whilst this is the dream, there is more often than not a huge upfront cost involved. If you're bootstrapping your company, it's likely client work will be essential in generating income to cover your bills.
Trial and Errors
After a few projects based on a standard hourly rate, I decided to embrace iterative development. The idea was to charge on a per-iteration development cycle. Each iteration was a fixed period of time (usually 2 weeks), and was charged at a fixed price. The amount of work completed in this cycle would be used to estimate the amount of work that could be completed in the next iteration. This was very simple interpretation of agile project management with velocity tracking.
The process seemed to make sense, but in practice was still bound to time. Essentially, I was quoting on a bi-weekly rate rather than an hourly rate. This resulted in the same problems, just without the fidelity of tracking individual hours.
Another realisation was just how rarely projects fit into the neat time-boxes we assign them. Often an iteration would extend beyond 2, or even 3 weeks, simply because the day-to-day running of business (for both parties) takes time. In this situation, it would be completely inappropriate to charge for 2 iterations, but with the project held up, and my velocity was reduced to 1!
I'd fallen into the trap of worrying more about the process (paperwork!) than the end-result. It was clear I needed to completely remove time from the equation, and concern myself with output.
Focus on Results: Agile Project Estimation & Tracking
With this in mind, I've decided to revise my iterative estimation and projection process using a simplified take on the agile process. Throughout a project, each user feature (or
story) is assigned a number of points based on its estimated difficulty. The majority of stories should be 1 point, a story that is known to prove difficult is assigned 2 points, and an unknown (e.g. developing something that is likely to require a high degree of research) is assigned 3 points. There are alternatives, such as using the Fibonacci sequence, but to my mind the simplicity of this model is an advantage for both me and the customer.
Rather than charging by time, I'll cost a project on the total number of points it contains, with each point priced at a known constant. For example, assuming a £200-per-point price, then a 2-point story would be charged at £400.
Of course, the accuracy of using this approach is in gathering, and successfully distilling, initial requirements. But by breaking the project into achievable stories and points, the customer can see a break-down of exactly where their budget is being spent, and revise or prioritise accordingly.
From the developer's point of view, this approach maintains the flexibility that comes from hourly rates. If the customer requests new or changed functionality, then new features (and hence points) will be allocated to the project. I'll continue to use the iterative project approach in estimating how much work can be completed within a fixed time-frame, and continue to track velocity so that the accuracy of these estimates can be improved.
Things Will Change: Stay Agile
There are, of course, going to be imperfections in the process. This will certainly be the case with the subjective parts of a project. Stories are necessarily concrete and describe functionality, so how can points be assigned to the graphic design of an application's interface? I think this will just have to be left to experience of estimating, but I hope that using a pricing structure that is measurable, flexible and rewards efficient and effective development will prove beneficial to both parties.
I'll post updates on how this approach goes, but in the meantime please feel free to discuss your thoughts in the comments below.
