>>Reading another post, the question was raised (at least in my mind), "What constitutes due diligence?".


Any client that comes to you with a project that is riddled with ambiguity is setting you up for a bit loss. One of the most important steps in creating a solution is developing the Software Design Plan (SPD) in which the specifications are clearly spelled out. Any changes requested by the client from the original plan then come as separately costed change orders. Relying on discussions, ideas and meeting minutes are a fast track to trouble and over budget. I have been there, done that.

The ideal is a separate proposal for the SDP, and then another for the development (according to the specifications) In this way the developer and the client can develop a clearer picture of the functions, appearance, and usability in the product being purchased, as well as a more accurate mething of controlling (or at least tracking) the cost. For the experienced developer, there is the advantage of "beating the bid" by re-using code previously developed and stored in personal libraries.

Due diligence is the requirment that one gives a dollars' value for a dollar charged, and does not deliver an imcomplete application, but charges the full contract price. The courts have traditionally given wide interpretations as to what level of effort constitutes "due diligence."