Seven rules for writing a project specification

Mark Voigtmann, a lawyer at Baker & Daniels in Indianapolis, concentrates his practice on legal issues affecting automation companies. From his experience with structuring projects and resolving legal disputes, he has formulated seven rules for writing a project specification. They apply equally to specifications written by owners (used as the basis for a bid by an integrator) and specs written by integrators (that are included within a proposal). Here are Voigtmann's Rules, courtesy of the author:

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). 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 "design specs" as general as possible. That way, the integrator is charged with the responsibility of making certain "subdesign" decisions—and will be on the hook for any mistakes. If you are the integrator, a design spec should be written so that it's 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. Opt for "industry practices or custom," if pressed, as an alternative standard.

5: 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 bit of data about the system from the integrator. If you are the integrator, this is all about ensuring owner cooperation and reaching an end point.

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. Muddled or cluttered specs help no one except one constituency: The lawyers.