He really advocates project/value based fees instead of time based fees.
This guy is not a software consultant. So beware, beware, beware this advice, because that little detail matters a lot.
It's easy to charge project based fees when you (a) are an expert negotiator and speaker and (b) your project is not built of either hardware or software. If the deliverable is a paper report, a Powerpoint presentation, or a new org chart, it is relatively easy to work around or gloss over any problems that arise and still deliver on time and make the client happy. You have a ton of flexibility. Unless you're drafting legal documents, editing the English or changing the color of a graphic has no wide-ranging ramifications.
If the deliverable is a working machine, you're up against the laws of nature:
For a successful technology, reality must take precedence over public relations, for nature cannot be fooled. -- Richard Feynman
You'll end up running three weeks late because the client makes a "trivial" reinterpretation of the spec at the last minute, and the old library won't meet the new spec, but the new version of the library will, so you upgrade, but the new version has a different API, and one of those new API calls has a bug...
I've used both time-based and value-based and my answer is an unequivocal "It depends on the project." I'm a pretty creative person and I hate to box myself in by saying "Never do it this way", especially when some very smart people have advocated both/multiple ways. I suggest taking a risk-analysis approach towards estimating as well whereupon you figure out what the mean time to complete, best, and worst times. This can give you confidence (after you've done it awhile) in your guesstimates and that confidence allows you to move more into the value-based pricing. I definitely wouldn't suggest value-based pricing for someone who had not had loads of time-based pricing experience.
The goal is to generate more income and not less, so you need to set up a system that provides for that. You can abstract out the core of the project, set a fee for that and tack on hourly rates for things outside the initial scope. You have to be careful in how you do things but it should ultimately lead to more money.
If you're happy making $x/hour or whatever then by all means continue to do so. If you're looking for more, you may want to start exploring other billing models.
Comments
You should consider reading some of Alan Weiss' consulting books. He really advocates project/value based fees instead of time based fees.
Million Dollar Consulting: http://www.amazon.com/gp/redirect.html?ie=UTF8&location=...
Getting Started In Consulting: http://www.amazon.com/gp/redirect.html?ie=UTF8&location=...
Value Based Fees: http://www.amazon.com/gp/redirect.html?ie=UTF8&location=...
I'd recommend these three books and check out his website @ http://www.summitconsulting.com/
He really advocates project/value based fees instead of time based fees.
This guy is not a software consultant. So beware, beware, beware this advice, because that little detail matters a lot.
It's easy to charge project based fees when you (a) are an expert negotiator and speaker and (b) your project is not built of either hardware or software. If the deliverable is a paper report, a Powerpoint presentation, or a new org chart, it is relatively easy to work around or gloss over any problems that arise and still deliver on time and make the client happy. You have a ton of flexibility. Unless you're drafting legal documents, editing the English or changing the color of a graphic has no wide-ranging ramifications.
If the deliverable is a working machine, you're up against the laws of nature:
For a successful technology, reality must take precedence over public relations, for nature cannot be fooled. -- Richard Feynman
You'll end up running three weeks late because the client makes a "trivial" reinterpretation of the spec at the last minute, and the old library won't meet the new spec, but the new version of the library will, so you upgrade, but the new version has a different API, and one of those new API calls has a bug...
[UPDATE: This link, recommended elsewhere on the page, has a succinct summary of the argument in favor of time-based fees: http://30sleeps.com/blog/2007/09/27/set-your-hourly-rate/ ]
I've used both time-based and value-based and my answer is an unequivocal "It depends on the project." I'm a pretty creative person and I hate to box myself in by saying "Never do it this way", especially when some very smart people have advocated both/multiple ways. I suggest taking a risk-analysis approach towards estimating as well whereupon you figure out what the mean time to complete, best, and worst times. This can give you confidence (after you've done it awhile) in your guesstimates and that confidence allows you to move more into the value-based pricing. I definitely wouldn't suggest value-based pricing for someone who had not had loads of time-based pricing experience.
I agree 100% with your last sentence.
The goal is to generate more income and not less, so you need to set up a system that provides for that. You can abstract out the core of the project, set a fee for that and tack on hourly rates for things outside the initial scope. You have to be careful in how you do things but it should ultimately lead to more money.
If you're happy making $x/hour or whatever then by all means continue to do so. If you're looking for more, you may want to start exploring other billing models.