Seven rules for writing specs
Mark Voigtmann -- Control Engineering, 4/1/2007
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.
-
While, in a legal aspect, everything in this article may be valid, I could not disagree more on the effectiveness of creating specs in this manner. Before the project has even started, a confrontational system is put in place. The purpose seems to be setting up who is to be blamed when the project fails, which will most likely be late, overbudget, and not work as expected when both sides are acting as adversaries. This thought process is much of what is wrong with the legal system.
A sucessful project must be thought of as every participant on the same team. Both sides will succeed if a project is well thought out, agreed upon up front, with all concerns and problems brought out into clear view as early as possible.
Given that, I will be using this as a guide to see if my potential customers or vendors are playing this type of game.
Mitch Doty - 2007-16-5 09:53:00 CDT -
Thank you Mark, for a conscise, well written set of guidelines that can be easily applied. As an engineer that sits at both sides of the bargaining table, I find this one of the most insightful articles I have read. I will start using these right away.
Dirk Forsythe - 2007-3-5 07:57:00 CDT -
I agree that performance specs are safer in some respects, but one must be careful to put enough technical “teeth” in the document to ensure that you will get the level of quality that you desire. The performance spec for a Mercedes and a Yugo would probably be very similar.
Ronald E. Stewart - 2007-3-5 07:48:00 CDT
All My Best Ideas are Stolen
09/01/2007Make this or make it do this?
04/30/2006Get the Most from a System Integrator
03/31/2007
View All Control Engineering Webcasts from CTL
