>
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.
>

Yet all the time, people do this sort of work on a fixed-bid basis. Take a government K for example. You cannot perform any aspect of those on a TM basis.

Creating a spec is nothing more than another kind of project.


>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.
>

All the time, clients want to get consultants to commit to fixed-price bids on weak/marginal specs. No spec is every 100% accurate. The difference between the spec and what you actually have to deliver I suppose is the risk. The better the spec, the lower the risk I suppose.

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

If it makes sense to do so. If there is a spec lacking, I will not commit to a fixed-price K. The risk is simply too great.


>
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.".
>

Let's take a hypothetical situation. Lets say you agreed to do a job for X dollars to deliver Y. What the client does not know is that within the scope of work covered by X, there is also a deliverable called Z - that the vendor will soley benefit from. If I the client find out about it and further, I can show that the marginal work expended for Z - that if it did not occur - would not impact delivery of my project - I the client could recover.

In other words, if the client is funding development of something else that he will never get the benefit of - and that if you would take those additonal buried dollars out and the client would still get his project - the client could recover.

If you think I am alluding to fraud here - you would be correct. Also, if the K was padded my misrepresentations made by the consultant - hiding behind the K will not help.

Do you see where I am going here????