Although I write a column on legal issues for an engineering magazine, I don't pretend to be an engineer. In fact, you would probably be within your rights to label me a "liberal arts" control engineering lawyer. What does that mean? It means that even though I may understand much better than your storefront lawyer what you are talking about when you say "integration," you will never find me writing a single line of software programming code. Or put another way, on the odd chance the "lawyer thing" doesn't work out, you can bet your pinstripes you won't find me going to the patent office with the latest breakthrough in visual recognition technology.

So why in the name of PLCs do I think I can write specifications better than you can?

I'll tell you why. Writing specs has nothing to do with science and everything to do with logic. It is in that spirit that I offer my “Seven Rules for Writing Specs.” These apply equally to specs written by owners (that are used as the basis for a bid by an integrator) and specs written by integrators (that are included within a proposal).

#1: Push performance responsibility to the other party. If you are the owner, push for the inclusion of more performance specs and fewer design specs. If you are the integrator, do exactly the opposite. A "performance spec" requires the contractor to install something that does a particular thing. A "design spec" only requires the contractor install something—without regard for whether or not the design is satisfactory. The more "performance specs" there are, the more open-ended responsibility is being handed to the engineer. Similarly, the more "design specs" there are, the more it is simply a matter of building something (and the owner or design consultant takes responsibility if the design is insufficient). Of course, whatever protections an engineer may get from following a "design spec" will be limited or nonexistent if he or she was the author of the spec or included it in the proposal.

#2: When performance responsibility cannot be transferred, push design responsibility to the other party. If you are the owner, keep every "design spec" as general as possible. In that way, the integrator is charged with the responsibility of making certain "sub-design" decisions—and will be on the hook for any mistakes. If you are the integrator, a design spec should be written so that it is dependent on the owner or its consultant providing timely and complete information about desired functionality.

#3: If none of the previous two "risk transfer" efforts works, try embedding a requirement that the other party must alert you to any problems or issues that it discovers or should have discovered in the specs before or during installation.

#4: If you are the owner, use phrases like "highest quality," "state of the art," and "free from defects." If you are the automation provider, avoid all such benchmarks (especially those listed) other than the requirements of the specs themselves. If pressed, opt for "industry practices or custom," or something similar as an alternative standard.

#5: Always include a section on commissioning and training. If you are the owner, this section is all about making sure your people know how the system works—and squeezing every last bit of data about the system from the integrator. If you are the integrator, this is all about ensuring owner cooperation and reaching an endpoint.

#6: Define terms when it is in your interest to do so. Keep them undefined (thus defaulting to "industry practices or custom") when it is not.

#7: Write clearly and be well organized, no matter what. Although it may sometimes be to your advantage to avoid defining a particular term, creating a muddled or cluttered spec really helps no one. Well…except perhaps one constituency. You guessed it: the lawyers.