After almost ten years of contracting work as webdeveloper, I have set some simple rules for myself:
* If project is described, specced and scoped well: fixed price.
* I can spec, scope and describe the project with the client; never for the client: most simply don't read piles of specs, misunderstand wireframes and so on. We then have a specced project, which allows me to offer it fixed-price.
* In all other cases, I won't ever work fixed price, because one thing is guaranteed: the noneexisting specs will shift, the wireframes in the head of the client will be "different then you understood them" and you will go over your allocated time, on your own money.
* A middleground solution would be to give a fixed price for the well-known territory (setting up a set of servers, installing, say, Drupal with some wellknown modules) but move over to hourly rates for all the (as yet undefined) custom work.
To sell this to clients, I simply give them a vast discount on hourly rates: after all, the client is carrying the risk.
If a client does not understand this, then I bail out of the project: I can simply not afford to carry the risk of
a) Not getting payed for several months, because of a delay of several months.
b) With every additional 100 hours, seeing your "wage" drop another few dollars. I have had projects, where in the end, I worked for less then I would have made, had I spend these hours working in the MacDonalds. You can explain a client that having their developers carry such a risk, will bring themselves the risk that at a point the developer will simply quit (without pay): leaving the client with a huge amount of wasted time and still no releasable project.
Comments
After almost ten years of contracting work as webdeveloper, I have set some simple rules for myself:
* If project is described, specced and scoped well: fixed price.
* I can spec, scope and describe the project with the client; never for the client: most simply don't read piles of specs, misunderstand wireframes and so on. We then have a specced project, which allows me to offer it fixed-price.
* In all other cases, I won't ever work fixed price, because one thing is guaranteed: the noneexisting specs will shift, the wireframes in the head of the client will be "different then you understood them" and you will go over your allocated time, on your own money.
* A middleground solution would be to give a fixed price for the well-known territory (setting up a set of servers, installing, say, Drupal with some wellknown modules) but move over to hourly rates for all the (as yet undefined) custom work.
To sell this to clients, I simply give them a vast discount on hourly rates: after all, the client is carrying the risk. If a client does not understand this, then I bail out of the project: I can simply not afford to carry the risk of a) Not getting payed for several months, because of a delay of several months. b) With every additional 100 hours, seeing your "wage" drop another few dollars. I have had projects, where in the end, I worked for less then I would have made, had I spend these hours working in the MacDonalds. You can explain a client that having their developers carry such a risk, will bring themselves the risk that at a point the developer will simply quit (without pay): leaving the client with a huge amount of wasted time and still no releasable project.
I really like that middle-ground solution. I might do something like that if I get another free-lance job. Thanks.