At an automation conference a couple of years ago, an executive approached me after my presentation and said, "You can talk about contracts all you want, but what you're saying simply doesn't apply to many of these companies. Some of these people operate on a handshake. The rest get by with proposals and purchase orders."

Part of what he said was true. Integration of a facility often is not the subject of a detailed written contract with, say, 30 single-spaced pages and four or five exhibits.

But his other point—that contract law has little application to the automation environment—was plain wrong. Here's why. Handshakes, purchase orders, and 30-page, single-spaced agreements are all contracts. They all determine the rights of the parties. They all can be legally binding. And they all have the capability of turning an otherwise profitable business opportunity into a nightmare if the wrong "term" is included.

Operating with a "we don't use contracts" mindset is one of the top misconceptions of technology companies when it comes to legal matters. Here are three others that come to mind:

Terms and conditions—Perhaps you are feeling legally protected as long as you transmit a copy of your terms and conditions sheet with your proposal or purchase order. But are you really? For instance, what happens when your customer (or integrator) responds by sending you its own contradictory terms and conditions? Does this mean the deal is off? Probably not—especially if the participants go forward with the project regardless (as they typically do). But that exchange of "dueling terms" and conditions may change the very nature of the project you are undertaking.

How? Consider this: It is often the case (at least in the United States, according to a law in nearly every state called the Uniform Commercial Code) that conflicting terms cancel each other and only the remaining agreed-to points are recognized as binding. Or, if you are doing business in the European Union, one or more of your terms may simply be stamped unenforceable by the government in question.

Round hole, square peg—If a process or control solution is just one small component of a much larger construction project, you may find yourself being asked to sign your name to a contract that looks and sounds very much like a construction contract. But does this form work for construction involving technology companies, or is it like trying to insert the proverbial square peg through a round hole?

I vote for the latter, because the construction contract will not adequately address the concept of "commissioning" (unless your idea of commissioning is a "punch list"). And the warranties in that contract are going to be difficult to translate to the world of sensors and relational databases. Furthermore, intellectual property provisions are almost guaranteed to be insufficiently detailed for the needs of the end-user, integrator, or equipment supplier.

Intellectual ambiguity—A mistake made by many companies is simply taking intellectual property for granted. But the risks are many. Perhaps you know of the patent infringement lawsuits filed by a company called Solaia Technology against users of control systems. The patent in question (U.S. Patent No. 5,038,318) relates to PLCs that feed data directly into a spreadsheet program, thus allowing operators to view the operation of the PLCs with a personal computer interface.

Regardless of what you may think of those lawsuits, defending against them is costly. And the issue of who pays the attorneys might have been addressed in the automation contract at the front end—whether in the form of a handshake, purchase order, or detailed agreement.