Sponsored By

How to Write a Project Specification: Seven Rules that Save the DayHow to Write a Project Specification: Seven Rules that Save the Day

March 11, 2015

3 Min Read
How to Write a Project Specification: Seven Rules that Save the Day

The success or failure of any big project is often decided at the very start. How you set parameters and expectations up front dictate every phase of how work will be conducted. Packaging automation projects are perhaps one of the best examples of this.

To make your automation project run smoothly and effectively, follow these project specification rules from Mark Voigtmann, a lawyer at Baker & Daniels in Indianapolis who concentrates legal issues affecting automation companies.

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 can’t 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.

Author Information 

Consulting Editor Vance J. VanDoren, Ph.D., P.E., contributes articles on process control, advanced control and systems integration and edits Control Engineering's and Packaging Digest's annual Automation Integrator Guide. 

Free News Updates ... Subscribe to Packaging Digest Newsletters Now

Sign up for the Packaging Digest News & Insights newsletter.

You May Also Like