Beware the dirty dozen

Mark Voigtmann, Baker & Daniels LLP -- Control Engineering, 8/1/2006

Want a good starting place for figuring out whether to accept another company's terms and conditions? Try looking for these "dirty dozen" contract flaws. If you are an integrator or outside engineer and find any of these in a proposed agreement, your internal warning bell ought to be sounding. (If you are an end user, on the other hand, you might consider engaging in a round of high fives.)

Does the absence of the dirty dozen mean the deal can always be signed? No, but it goes a long way in confirming that the terms and conditions are fair.

1. Stealing your work product legally. If the contract describes software, for instance, as a "work for hire," you are giving up your intellectual property rights. A better solution may be granting a non-exclusive, non-transferable license to software—assuming, of course, you have the bargaining power to demand it.
2. Unfair risk shifting. Contract forms sometimes present engineers with a two-edged sword: provisions imposing harsh damages for delays attributable to their work, but an absence of similar remedies if the engineer is held up because others are not prepared to proceed. Unfortunately, these "no damages for delay" clauses, even if unfair, are enforced by the laws of most states.
3. Indemnifying others for their own fault. Generally speaking, indemnification means protecting someone from the claims of a third person. Unfortunately, it is very common to see forms that require the engineer to indemnify a customer for losses caused by the customer's own negligence. This makes the engineer, in essence, the insurance company for the end user!
4. Incorporation of other contracts by reference. Contracts that make reference to other documents that are not immediately available, but seek to "incorporate by reference" those documents to make them a binding part of your deal can be dangerous for obvious reasons.
5. Unconditional warranties. Development of a control system requires coordination and communication between the end user and engineer. Only sophisticated owners realize the degree to which their participation is critical to the usefulness and functionality of the end product. Warranties should be linked to cooperation from the owner and should not be "unconditional."
6. Performance specifications. Do the specs require you to build something according to a particular plan or do they require you to build something that has a particular functionality (i.e., "produce a hundred widgets per hour")? The latter are called "performance specs" and should be avoided.
7. No limitation on damages. Without a cap in the agreement on "consequential damages," a catastrophic meltdown could break your company. If you cannot change anything else, get this changed.
8. Termination for convenience It is becoming more common for owners to insist that their contracts include a clause which gives them the right to terminate a contract "for convenience," which is to say "for no good reason at all." This is not fair treatment because taking on a project prevents taking on other work.
9. Notice deadline traps. Look carefully at notice deadlines. Forty-eight hours for giving notice of unforeseen conditions, changes, or a claim can be impossible to meet. If you cannot change them, at least highlight them so your people know that the clock is ticking.
10. Home court advantage dispute resolution. Does the agreement require all disputes to be heard in a courtroom in the home county of the end user, which happens to be 500 miles from the project site and three states away from you? Not good.
11. Back charges. Does the contract give the customer virtually unlimited opportunities to assess back charges (which can feel like an IRS audit)? It should not. There should be a notice deadline beyond which these charges are deemed waived. There should also be a process for documenting them.
12. Pay when paid. If your contract is not direct with the owner, watch out for clauses that say payment is not due to you unless the owner has paid the middleman. A better approach is to make these clauses effective only in the event your work is somehow linked to the problem causing the nonpayment.