Beware the dirty dozen
Legalities: 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.) Link to 8 more.
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.
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.
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.
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!
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.
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."
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.
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.
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.
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.
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.
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.
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.
This is just the start, though. Also read: Legalities: 8 ugly contract clauses.
Mark Voigtmann is a lawyer with Baker & Daniels, LLP (Washington, DC, Indiana and China). His group assists integrators and automation end users in structuring projects and resolving dispute. Contact him at Mark.Voigtmann@bakerd.com or 317-237-1265.
Case Study Database
Get more exposure for your case study by uploading it to the Consulting-Specifying Engineer case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.