No, I didn't fail to factor that in to the equation. A developer should not only have fixed price deals, if for no other reason than not every job is suited to it.

For example, a job to design a system and create a functional specification should never be a fixed price job. Even if you (as the developer) know the industry, you probably don't know the specifics of this one client. The unknowns are too great, IMO, to risk a fixed price deal.

However, given a GOOD functional specification, the creation of the actual system would most likely be a decent candidate for a fixed price deal. The environment should be layed out for you in the specs. You can factor these into your fixed price bid. The risk factors go down.

Fixed priced jobs should be one of the tools a developer/consultant employs.

As for burying anything, I'm not sure I understand. Once a fixed priced deal is signed, you (the developer) are under no obligation that I know of to disclose anything about the underlying process. The client has signed off on a price that they will pay you in exchange for services/deliverables. To me, this implies that the perceived value of the agreed upon deliverables is equal to or greater than the price of the thing. Once agreed upon, the client can't go back in the middle of the project and say, "Oh my, it's not costing you as much to produce this thing as I thought. Therefore, I'm not going to pay you as much as I agreed to.".

The objective for the developer is to charge a price greater than or equal to the cost of producing the deliverables. When determining the fixed price, the developer should first try and ascertain the "value" to the client. Once that is calculated, gleaned or determined with the use of tea leaves, you now have a basis upon which to base your price. Don't determine the price based only on your costs.

The question should not be "How much am I willing to do this job for?". It should be "How much is it worth for me to do the job?". The first question derives the value from the developer's value system while the second derives it from client's.

>But.... you fail to factor in the most important variable of all... RISK
>
>There is more risk associated with a fixed-price job. IMO, the developer bears more risk. Thus, in order to properly equate the two (TM vs Fixed Price) - the Fixed Price number must be discounted by the requisite risk.
>
>On one hand, the developer will charge more because of the risk. At the same time, the additional charge must be discounted by the risk. Only at the end of the project will you know whether you won/lost/pushed. Looking prospectively, one must discount accordingly.
>
>Whether one can quantify the risk or not is another issue....
>
>There is no question that one can "bury" many things in a fixed price K. A savvy client however, will still require substantiation of those "other" items. People that bury items play on and hope to cash-in on the ignorance of others.
>