The proper amount of specificity

What is the appropriate level of detail for a specification?

06/16/2014


Specifications, by nature, are very specific. However, there is a point at which they can be too detailed and can cause conflicts with other contract documents, such as drawings, Division 01 general requirements, or the general conditions.

While they complement each other, contract documents are not supposed to duplicate information. The motto, "say it once and say it right," should always be in mind when an engineer is putting together design documents.

Contract documents—which include the contract between the owner and contractor, the project manual, and drawings—have a hierarchy, which goes from very general to very specific. At first glance, it appears that the “say it once and say it right” principle is being willfully ignored, but let's take a quick tour through the documents to show that the level of specificity in the contract documents starts broadly and then narrows.

The procurement requirements are occasionally thought of as a part of the contract documents, but they aren't, so we'll begin with the owner-contractor agreement. This agreement is a part of the contract documents and is the basis of any agreement between the owner and the contractor. It also includes all of the other contract documents via incorporation by reference.  This is a purposely broad and nonspecific agreement that defines the relationship between the two parties.

The general conditions of the contract define, in a very broad manner, who does what. This document describes administrative procedures, working hours, warranty conditions and length, payment procedures, retainage, the punch list, and closeout procedures, among other items. Again, the scope of this document is very broad. For instance, there may be a requirement for a 2-year building warranty after the end of the 1-year construction warranty. This document would define the timeframes of the warranties and name the contractor as the party responsible for the warranty. It would also point the contractor to the appropriate specification section to find further details on the expected warranty service.

The first part of the specification, Division 01 general requirements, is similar to the general conditions of the contract in that the items described in Division 01 apply to all of the specification sections and drawings. However, there is significantly more detail in Division 01 than in the general conditions. Using the warranty example, the general requirements would elaborate on what is covered under the warranty, whether products will be replaced or repaired, the response time, and whether a manufacturer's warranty is required, to name a few of the items. Overall, there is a higher level of detail in Division 01 than there is in the general conditions.

Often, the general requirements are very specific to each owner and are edited by either the owner or prime engineer. The general requirements, and any customized specification sections should provided to the engineer to use prior to or during design, as they often have special provisions that have been inserted by the owner. Click here to see the U.S. Dept. if Veterans Affairs’ general requirements and standard specifications.

Note: Master Format, the standard for organizing building system information in the United States contains Division 00 – Procurement and Contracting Requirements, Division 01- general requirements, and Divisions 02 through 48, which are used for work results. MasterFormat 2014 was recently released.

Part 1 in a Division 02 through Division 48 specification section gets even more specific, describing what constitutes a product failure and the length of special or nonstandard warranties. One needs to be especially careful when writing warranty (for a discussion of the difference between a warranty and guarantee, see the discussion here) provisions into an individual specification, as more than one well-meaning engineer has undone the work of the project manager, executive, or lawyer who wrote Division 01 by including conflicting provisions in a Division 02 through Division 48 specification.

Continuing with the warranty example, specifically naming the terms of the warranty in a product specification may actually limit the owner's rights and cause an unwarranted increase in the cost of the product. The American Institute of Architects' standard contract documents include a 1-year correction period in which the contractor is responsible for replacing or repairing any defective work. Requiring the contractor and manufacturer to provide and document a 1-year warranty to the engineer is an additional and unnecessary task, as the 1-year correction period described in Division 01 overrides any warranty provisions.

Also, if someone noticed that the warranty provisions in the Division 02 through Division 48 specification do not complement Division 01 or the general conditions, that person could argue about the true intent of the warranty. It is appropriate, however, to mention specific manufacturers' warranties, such as a 5-year warranty, or certain warranty provisions, such as replacing instead of repairing, within a Division 02 through Division 48 specification.

The proper amount of specificity depends on what you are writing, and where the language is located. Think of it as an inverted pyramid—broad requirements in at the top or in the front end of the project manual with more specific requirements, that are coordinated with the other sections of the project manual, as one gets further down into the project manual.


Michael Heinsdorf, PE, LEED AP, CDT is an Engineering Specification Writer at ARCOMMasterSpec. He has more than 10 years' experience in consulting engineering, and is the lead author of MasterSpec Electrical, Communications, and Electronic Safety and Security guide specifications. He holds a BSEE from Drexel University and is currently pursuing a Masters in Engineering Management, also at Drexel University.



No comments
The Engineers' Choice Awards highlight some of the best new control, instrumentation and automation products as chosen by...
Each year, a panel of Control Engineering editors and industry expert judges select the System Integrator of the Year Award winners.
The Engineering Leaders Under 40 program identifies and gives recognition to young engineers who...
Learn how to increase device reliability in harsh environments and decrease unplanned system downtime.
This eGuide contains a series of articles and videos that considers theoretical and practical; immediate needs and a look into the future.
Learn how to create value with re-use; gain productivity with lean automation and connectivity, and optimize panel design and construction.
Go deep: Automation tackles offshore oil challenges; Ethernet advice; Wireless robotics; Product exclusives; Digital edition exclusives
Lost in the gray scale? How to get effective HMIs; Best practices: Integrate old and new wireless systems; Smart software, networks; Service provider certifications
Fixing PID: Part 2: Tweaking controller strategy; Machine safety networks; Salary survey and career advice; Smart I/O architecture; Product exclusives
The Ask Control Engineering blog covers all aspects of automation, including motors, drives, sensors, motion control, machine control, and embedded systems.
Look at the basics of industrial wireless technologies, wireless concepts, wireless standards, and wireless best practices with Daniel E. Capano of Diversified Technical Services Inc.
Join this ongoing discussion of machine guarding topics, including solutions assessments, regulatory compliance, gap analysis...
This is a blog from the trenches – written by engineers who are implementing and upgrading control systems every day across every industry.
IMS Research, recently acquired by IHS Inc., is a leading independent supplier of market research and consultancy to the global electronics industry.

Find and connect with the most suitable service provider for your unique application. Start searching the Global System Integrator Database Now!

Case Study Database

Case Study Database

Get more exposure for your case study by uploading it to the Control Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.

These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.

Click here to visit the Case Study Database and upload your case study.