I like project-based billing but a lot of people don't, because it exposes them to risk (scope changes, unexpected complexities, client downtime) that they can avoid with time & materials billing. A weekly rate is, to a customer, pretty close to the same interface as a project rate, so if you're thinking about charging project rates, consider weeklies instead.
Also remember that part of the idea of upping your billing increment is not accepting piecemeal work.
I'm interested to know how you manage the risk inherent in project-based billing.
In my experience it is simply unworkable: the client will provide the vaguest of specifications and providing them with a set-in-stone price raises unrealistic expectations. The requirements are simply too fuzzy at the outset of a project to be able to price it accurately.
Of course the solution only becomes more concrete as the project progresses and requirements change and crystallize based on feedback. This is expected behaviour of course, but I've never been able to reconcile it with project-based billing.
Do you simply allow a certain buffer zone and take the good with the bad?
I'll just quote myself: "Personally, I figure out the worst-case scenario and price it for that."
Experience helps with the above. Obviously you can never know precisely how much effort something will take. Stuff comes up. Even if the work itself is stupid easy, it might take you 2 hours to find the exact line of code that needs to be changed and sometimes it takes 5 minutes. And you never know which is which. So charge for 2 hours.
the client will provide the vaguest of specifications and providing them with a set-in-stone price raises unrealistic expectations.
Clearly define the parameters of the project. Clearly define what you will do. Don't do any more or any less than that.
If the client needs something extra done, and this happens, simply price that out separately.
The requirements are simply too fuzzy at the outset of a project to be able to price it accurately.
I agree. Experience and clearly defined parameters and contract goes a long way in project based billing. If requirements are fuzzy then we developers need to help the client to make them clear by asking the right questions.
Comments
I like project-based billing but a lot of people don't, because it exposes them to risk (scope changes, unexpected complexities, client downtime) that they can avoid with time & materials billing. A weekly rate is, to a customer, pretty close to the same interface as a project rate, so if you're thinking about charging project rates, consider weeklies instead.
Also remember that part of the idea of upping your billing increment is not accepting piecemeal work.
I'm interested to know how you manage the risk inherent in project-based billing.
In my experience it is simply unworkable: the client will provide the vaguest of specifications and providing them with a set-in-stone price raises unrealistic expectations. The requirements are simply too fuzzy at the outset of a project to be able to price it accurately.
Of course the solution only becomes more concrete as the project progresses and requirements change and crystallize based on feedback. This is expected behaviour of course, but I've never been able to reconcile it with project-based billing.
Do you simply allow a certain buffer zone and take the good with the bad?
I'll just quote myself: "Personally, I figure out the worst-case scenario and price it for that."
Experience helps with the above. Obviously you can never know precisely how much effort something will take. Stuff comes up. Even if the work itself is stupid easy, it might take you 2 hours to find the exact line of code that needs to be changed and sometimes it takes 5 minutes. And you never know which is which. So charge for 2 hours.
Clearly define the parameters of the project. Clearly define what you will do. Don't do any more or any less than that.
If the client needs something extra done, and this happens, simply price that out separately.
Example?
I agree. Experience and clearly defined parameters and contract goes a long way in project based billing. If requirements are fuzzy then we developers need to help the client to make them clear by asking the right questions.