Billing with Integrity (part 1)
Billing is a thorny issue for most developers. At Eden we’ve billed via various means over the last few years, and have recently settled on a new method which is worth me taking some time to explain. If you’re in software development, it might help you to rethink the way you’re charging your time to clients – our new billing method has made our lives much easier, and improved communication with our clients.
But first, a bit of background on various ways developers bill clients for their work.
Fixed price – Billing per project
Are you sure you want to do this? There is no undo.
As a developer, I have an aversion to billing a fixed price for a whole project. In my opinion it pits the client and the supplier against each other, especially when parts of the project change (as they inevitably do).
The fixed price concept is borrowed from traditional engineering, when costs and requirements had to be worked out fully in advance as things were hard to change. Imagine you are a building contractor, you’ve just poured the concrete for the foundations, and your client pops over to ask for the building to be moved slightly to the left?! Because things are difficult to change after the work has been done, it costs a lot to do so. Therefore it makes sense to work out the costs fully in advance, and charge a fixed amount. If things need to be changed after the fact, there’s a rigorous (and expensive) process that is worked through, usually costing the client a bunch of money.
Some software developers behave as if the same was true of writing code. They put together a brief, build a website, possibly as a cut-price deal. Then they charge a fortune to change the homepage text, or add an extra button. We often get calls from clients who are fed up with being charged for four hours of time to change the wording round in one sentence. Ultimately, unlike in the construction industry, software (especially web-based software) isn’t and shouldn’t be hard to change. Why do we behave like it is?
Sure, expertise is valuable, and one argument for this sort of charging had made the round in various forms and is often used as a defense for this practice. However, I’m more concerned with communication: let the client know what the ongoing bills are likely to be before you start. Otherwise they have no way of measuring how much your expertise is actually going to cost, and therefore no idea about the true cost of the project. Because all projects change, a so called ‘fixed price’ gives clients less information that they would normally have.
Tune in next time for more discussion on why fixing prices for whole projects is also bad for project quality (subscribe for the latest updates). If you’re in a hurry for an “answer”, you could always peek at our pricing pages if you want to know how we bill :)
I’ve found a fixed price billing is good for:
* small projects (< 1 man month is my cutoff)
* known systems (e.g. CRUD system, invoicing programs)
* experienced developers (domain and estimates)
With smaller projects, there is a lot less that needs to be thought about and the unknowns can be added into an overhead, since they shouldn’t be that significant. Known systems are also easier because the customer and developer *should* already know how it works so there isn’t much room for experimenting. Finally experienced developers tend to have the confidence with their estimates, tools, and team so they are able migrate some of the risks.
All said, it’s difficult to know upfront if a project should be fixed price or not. It really comes down to how well the customer and developer communicate. If it’s a fixed price and both parties flex and adapt to changes within the scope, the project should turn out fine.
I’ve worked on some projects that started as fixed price and then turned into an hourly project as it grew. I’m interested in seeing how this series goes, maybe I’ll find another tool to add to my pricing toolkit.
Hi Eric,
Interesting comments. We return the concept of smaller fixed projects later on in the series. There are advantages as you mention which we have attempted to incorporate into our model.
Thanks
Chris
thank you for this information..
That's a great article. It's very nice and informative. But I want to know more about Billing. Can you give me more info about it? Thanks in advance.
This is the first article in a five part series… Click on the link
in the last paragraph to see the next article.
Thanks
Chris
In most respects, I think it's no contest: Fixed pricing wins hands down for lots of reasons. It holds the potential for higher margins. It provides a strong incentive to clients and remodelers alike to buy right. And it keeps clients' prying eyes away from parts of the business, like markup, that they wouldn't understand anyway.
[...] Parts 1, Part 2 and Part 3 argue that fixed price arrangements are inappropriate for software development because they’re implicitly set up to pit client and supplier against each other. This wastes valuable project budget and time on working out what to do when the project changes. I concur. [...]
test
Really great information in your blog. Please write more so that we can get more updates in your blog. Thanks a lot!
regards
sears parts