5 ms·

What’s wrong with fixed-fee if a fully specified statement of work is made with clear, objective test criteria?

detaro 7y ago
That it's often extremely difficult and lots of overhead to have such a thing, and clients typically are larger than you and have less to loose by arguing about it endlessly.
- HeyLaughingBoy 7y ago
  That really depends on the project. One of the reasons I only take very small projects is that the scope is typically limited and clearly understood so it's easier to offer a fixed bid with little risk.
kradroy 7y ago
As someone who's done over a dozen fixed-fee jobs - DON'T DO IT. There are too many unknowns, even in "simple" jobs. It won't be worth your time and you'll regret it. In order to make fixed-fee contracts worth it I had to cut corners. I hated doing that, but I preferred it to dropping the contract altogether (sunk costs fallacy). I've also found the clients who insist on fixed-fee contracts to be very demanding and petty. They tended to interpret the specs liberally. It's not worth the hassle. Trust me.
- avinium 7y ago
  As someone who's been on both sides of the table - client and contractor - I completely agree. I never do or ask for fixed-fee. When I'm the client, I feel fixed-fee gives the contractor an easy backstop/fallback position - they figure they can half-ass the job and use the additional time to scout for more work. When I'm the contractor, it's the same, but in reverse - fixed-fee makes clients feel like they can demand the moon beyond spec at no additional cost. Hourly/daily rates make sure that BOTH parties have something at risk, which tends to be keep everybody in line. The contractor's at risk of the client firing them. The client's money is at risk if they keep demanding endless revisions. Actually a good lesson for business in general.
pault 7y ago
What's wrong with it is that every spec will always be open to interpretation. You will interpret it as the minimum amount of functionality; the client will interpret it as the maximum. The only spec that isn't open to interpretation is the code itself. :)
jgamman 7y ago
as the client, i would always split the project into 2 parts - a functional spec and a technical spec. my job was to interpret and write the func spec as a kind of pseudo-code version of what i thought could be built. then i would commission a fixed price job of interpreting the func spec and re-writing it as a technical spec ie, click a button and take the user to a summary of xyz turns into a bit of SQL. the tech spec must be written so that any programmer could use it to understand what needed to be done. then I'd ask for a fixed price quote to deliver on the assumption that i could get multiple quotes if needed. the benefit is that my coder who wrote the tech spec should be very comfortable with what is needed and i get to sell a lower risk $$ to my managers.
flyinglizard 7y ago
Nothing is wrong. Some of the best contracts I had were fixed cost (which is my preferred way to work over hourly). But - you need to be familiar with the system you'll be developing in, very good in what you do and price it at several multiples of your hourly assessment. I really, really don't like working hourly - I'm not selling my time after all, but my services.

That it's often extremely difficult and lots of overhead to have such a thing, and clients typically are larger than you and have less to loose by arguing about it endlessly.

HeyLaughingBoy 7y ago
That really depends on the project. One of the reasons I only take very small projects is that the scope is typically limited and clearly understood so it's easier to offer a fixed bid with little risk.

kradroy 7y ago

As someone who's done over a dozen fixed-fee jobs - DON'T DO IT. There are too many unknowns, even in "simple" jobs. It won't be worth your time and you'll regret it. In order to make fixed-fee contracts worth it I had to cut corners. I hated doing that, but I preferred it to dropping the contract altogether (sunk costs fallacy). I've also found the clients who insist on fixed-fee contracts to be very demanding and petty. They tended to interpret the specs liberally. It's not worth the hassle. Trust me.

avinium 7y ago
As someone who's been on both sides of the table - client and contractor - I completely agree. I never do or ask for fixed-fee. When I'm the client, I feel fixed-fee gives the contractor an easy backstop/fallback position - they figure they can half-ass the job and use the additional time to scout for more work. When I'm the contractor, it's the same, but in reverse - fixed-fee makes clients feel like they can demand the moon beyond spec at no additional cost. Hourly/daily rates make sure that BOTH parties have something at risk, which tends to be keep everybody in line. The contractor's at risk of the client firing them. The client's money is at risk if they keep demanding endless revisions. Actually a good lesson for business in general.

pault 7y ago

What's wrong with it is that every spec will always be open to interpretation. You will interpret it as the minimum amount of functionality; the client will interpret it as the maximum. The only spec that isn't open to interpretation is the code itself. :)

jgamman 7y ago

as the client, i would always split the project into 2 parts - a functional spec and a technical spec. my job was to interpret and write the func spec as a kind of pseudo-code version of what i thought could be built. then i would commission a fixed price job of interpreting the func spec and re-writing it as a technical spec ie, click a button and take the user to a summary of xyz turns into a bit of SQL. the tech spec must be written so that any programmer could use it to understand what needed to be done. then I'd ask for a fixed price quote to deliver on the assumption that i could get multiple quotes if needed. the benefit is that my coder who wrote the tech spec should be very comfortable with what is needed and i get to sell a lower risk $$ to my managers.

flyinglizard 7y ago

Nothing is wrong. Some of the best contracts I had were fixed cost (which is my preferred way to work over hourly). But - you need to be familiar with the system you'll be developing in, very good in what you do and price it at several multiples of your hourly assessment. I really, really don't like working hourly - I'm not selling my time after all, but my services.