This is an excellent way to approach a project, that is, if it is a new application, and not an upgrade or enhancement of an existing one.

I recently contracted to do a software design document, teaming with a group of engineers and mathematicians to do a simulation product.
My part was only the security and database portion, as well as the SQL to move data between the database and a thrid party software product. I was paid separately for the design work. The design document, when published was indeed shopped around, both by the overall client, but the outfit I teamed with as well (never again though) but in the end I received the actual programming modules contract as well. This was my first one in an environment like that, but in the end, it has all come together, and with no room for misunderstandings or mis-interpretations either. Changes have come in the form of change orders, with an appropiate price tag to each, and it is working out very well. This is the best part, because it seems like everytine they test a particulat bell or whistle, they clamor for even more.


>Just another point to ponder. Whil Hentzen once talked to a group I participated in and his approach was to break a project up into two projects. The first was a time and material project to gather requirements and write a functional specification. At the end of this time, the client had a document they could farm out to anyone they wanted to actually do the work for a fixed price bid. The second part was the fixed price contract to actually build the application. Whil usually got the second part (although it was not a given) because he was very familiar with the work needed.
>
>Just my $0.02.