Legalities: 8 ugly contract clauses

Legal risks for automation industry companies: Add these ugly 8 contract clauses to the dirty dozen to get 20 very serious legal risks.

02/18/2011


A while ago I wrote in this space about the dirty dozen contract clauses—that lawyer-created prose that, above all others, creates big risks for companies in the automation industry.

The dirty dozen are: Limitations on damages, ownership of work product, risk shifting for delays, incorporation by reference, unconditional warranties, performance specs, termination for convenience, notice deadline traps, home court dispute resolution, back charges, pay-when-paid, and indemnifying others for their fault. (Got those memorized? My message was that if you could avoid the worst effects of those clauses in contract negotiation then you are looking pretty good.)

In retrospect, there should have been two big, fat asterisks next to that dirty dozen list.

One of those asterisks would have said that the choice of the dozen clauses was purely arbitrary. In other words, there are plenty of other offenders that can "contractually soil" control panels and PLCs.

The second asterisk would have introduced a little perspective. Whether any of those paragraphs is truly "dirty," of course, depends on who you are. Which is to say: one company's "dirty" is another company's "being careful." (Translation: Put them in your arsenal, Mr. End User. Avoid them, Mr. Integrator.)

Which brings us to today's message: With the first of those asterisks in mind (the dozen are just a starting place), I’ll add the "ugly Eight" to the list, bringing the number of offenders to an even 20.

1. "Free from defects." Perhaps there is some construction project—somewhere—where the phrase "free from defects" is appropriate in a contract, but automation projects are not one of them. Control engineering, by its very nature, involves software—and has there ever been a piece of software without defects? A global search for the word "defect" should be standard operating procedure in automation contract scrutiny. If not removed entirely, the phrase "free from defects" can be replaced with reference to best practices or industry standards.

2. Dragnet clauses. Perhaps you have seen these. Paraphrased, they purport to state—and I am not making this up—"on the off chance there is any ambiguity about exactly what it is your company agreed to do, you and we agree that you agreed to do whatever is worse for you." Now depending on what that extra obligation is, there may be arguing room about whether that is truly a binding commitment. Still—in the slippery world of automation specs, who wants to be burdened with trying to extricate themselves from that mud hole?

3. Retainage. For every ten dollars your company is owed, we will pay it nine—holding the final dollars till the end. While these "good faith" holdbacks sometimes make sense (ensuring solvency or workmanship or payment of subcontractors), there is no reason to blindly apply them. Are there equipment purchases requiring a larger fronting of cash? Is the upstream contractor (if there is one) subject to the same retainage? Is the percentage negotiable?

4. Assurances regarding site conditions. It is common for automation contracts to require a provider to vouch for the fact that the existing conditions of a facility—and even design components contributed by others—are sufficient for purposes of the upcoming project. Requiring such assurances can be fair to an extent; for instance, it is certainly not unreasonable for one to want, at a minimum, an integrator to have visited the site. Such assurances begin to cross the line when they have the provider acting, in essence, as an "insurance policy" against unforeseen conditions.

5. Audit rights/financial condition assurances. If you are a control system integrator and you have a lump-sum contract, does the end user have the right to look at your books? (If so, why? Does that make any sense?) Conversely, if you are the end user and a provider is working under a cost-plus arrangement, is there any reason you should not have this right? While the proper approach in those situations may be relatively clear, the issue is a bit stickier when it comes to confirmation of overall financial condition. Lump sum or not, if there are signs that a provider is becoming insolvent, requiring some showing of financial health mid-project seems reasonable, most would agree. However, what degree of assurance is appropriate? The matter is negotiable.

6. Bonding. Bonds reflect a guarantee from a third party (a surety) that a company will fulfill its obligations (such as paying its subs or installing a system). Although it is common to "pass through" the cost of bonds to the end user, procuring them is the catch-22 of contracting. At the risk of overstatement, bonds arguably are needed only when the bonded party's financial stability is somehow questionable. But they can only be procured if that stability is unquestionable! To observe that contracting around bonding is challenging is to state the obvious.

7. Additional insured endorsements. Another typical contractual requirement that can leave a party in unintended knots is the additional insured endorsement. This is asking your insurance company for an endorsement that gives someone else the right to make a claim on your insurance policy. Pitfall for the technology contractor: There is an extra cost to this endorsement—or it may not be available at all (for instance, it's never available on professional liability policies). Pitfall for the end user: It's not enough to have an additional insured endorsement required by the contract. You must also have the actual endorsement in hand. Owners often neglect that second step.

8. Right to correct work. If your company arguably does not fulfill its contractual obligations, does the owner have the right to step in to perform the work? It sounds like a reasonable remedy except for the usual collection of variables: Is it just any failure to perform that triggers the right or only an important failure? What notice, if any, must be given? Following notice, does the provider have the opportunity to correct the deficiency itself? Is the warranty period extended if the fix works? Must notice be given again if the fix does not work? If the owner exercises its right to correct the work, are all of the provider's remaining obligations cancelled or terminated? Creating a fair "right to correct" provision can be complicated.

So there you have them—the ugly eight contract clauses for automation. They may not make the lawyer all-star squad, but they are there on the sidelines ready to spoil your project.

Mark Voigtmann is a lawyer with Baker & Daniels llp (Indianapolis, Chicago, Washington, DC, and Beijing). His group assists the automation and process industry in structuring projects and resolving disputes. ( Mark.Voigtmann(at)bakerd.com or 317-237-1265).

- Legalities: Beware the dirty dozen - 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.)

- Need more Control Engineering Legalities?



No comments
The Engineers' Choice Awards highlight some of the best new control, instrumentation and automation products as chosen by...
Each year, a panel of Control Engineering editors and industry expert judges select the System Integrator of the Year Award winners.
Control Engineering Leaders Under 40 identifies and gives recognition to young engineers who...
Learn more about methods used to ensure that the integration between the safety system and the process control...
Adding industrial toughness and reliability to Ethernet eGuide
Technological advances like multiple-in-multiple-out (MIMO) transmitting and receiving
Virtualization advice: 4 ways splitting servers can help manufacturing; Efficient motion controls; Fill the brain drain; Learn from the HART Plant of the Year
Two sides to process safety: Combining human and technical factors in your program; Preparing HMI graphics for migrations; Mechatronics and safety; Engineers' Choice Awards
Detecting security breaches: Forensic invenstigations depend on knowing your networks inside and out; Wireless workers; Opening robotic control; Product exclusive: Robust encoders
The Ask Control Engineering blog covers all aspects of automation, including motors, drives, sensors, motion control, machine control, and embedded systems.
Join this ongoing discussion of machine guarding topics, including solutions assessments, regulatory compliance, gap analysis...
News and comments from Control Engineering process industries editor, Peter Welander.
IMS Research, recently acquired by IHS Inc., is a leading independent supplier of market research and consultancy to the global electronics industry.
This is a blog from the trenches – written by engineers who are implementing and upgrading control systems every day across every industry.
Anthony Baker is a fictitious aggregation of experts from Callisto Integration, providing manufacturing consulting and systems integration.
Integrator Guide

Integrator Guide

Search the online Automation Integrator Guide
 

Create New Listing

Visit the System Integrators page to view past winners of Control Engineering's System Integrator of the Year Award and learn how to enter the competition. You will also find more information on system integrators and Control System Integrators Association.

Case Study Database

Case Study Database

Get more exposure for your case study by uploading it to the Control Engineering 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.