Customer-clients regularly come to me with contracts that have:

1. no objective criteria to measure success/failure

2. all of the liability for delays, failure to perform, etc. allocated to the Customer

3. do not have sufficient input from the technical people that will actually be working on the project.

4. no contractual remedies for failure.

5. no change management process.

Point #1 is the most important. In this case, if there were objective criteria to measure success, then the breach of contract case is simple to prove. It is like engaging in the design/plan phase of development before you even sign the contract. If a customer can't figure out what objective criteria it needs, it's probably not a good time to enter a $40M contract. Take for example, the objective criteria that the EDS software will meet the minimum process per second with 150 active users. Easy, does it do? If not, see points 2 and 4.

Point #2 is often overlooked. Customers regularly sign contracts that permit a vendor to deliver something non-conforming on the delivery date and not be in breach. The contracts are also usually written so that the additional time spent correcting the non-conforming deliverables are paid by the Customer. These are usually sneakily inserted under the "right to cure" a breach provision. At some point, the vendor (not the customer) should be paying.

Point #3 is necessary in order to establish point #1 and point #2. Management has this idea: oh we need ___ system. Let's find a vendor of ___ system. However, it is the technical people that need to set the objective criteria and then be able to test that it was met.

Point #4 is the stick with which you beat the Vendor into meeting those requirements. Every customer should be asking, "what happens if they don't deliver?" I say, "show me the money." Of course, you can customize however you see fit. Customers however don't usually ask.

Finally, point #5 is so painful its hard to write about. A lot of time and money is lost because the customer does not have a good internal change management process. In addition, the customer does not put that change management process in writing with the vendor. Any change management process should be coordinated through a project manager. The process should require 1. estimates of cost and 2. affect on time line. These should require signature of someone higher up the chain than the project manager if there is a big impact on price or time--what constitutes a "big impact" should be spelled out (e.g., more than $10,000 or more than a 1 week).