Constructing Construction Specifications Years ago buildings were designed and constructed using 16 specifications; currently the updated Master Format has 48 specifications slots covering everything relevant to a building.

Jim Sinopoli PE,   LEED BD+C, RCDD, Managing Principal, Smart Buildings LLC Contributing Editor

The process of designing and constructing a building may have hundreds or thousands of aspects. One of those aspects is the important development of construction specifications. Construction specifications are a large part of structuring and communicating the design, performance and construction to the owner and the contractor. Construction Specification Institute created MasterFormat, which is an indexing system for organizing construction data, particularly construction specifications. Years ago buildings were designed and constructed using 16 specifications; currently the updated Master Format has 48 specifications slots covering everything relevant to a building.

The prime focus of construction specifications are to:

(a) Embody the concepts and expectations of the building owner who may have gathered advice from designers, engineers, contractors, suppliers, manufacturers and others to provide direction and guidance on the building owner’s benefits, needs, approaches and cost.

(b) Be very clear in stating the requirements of the contractor.

The construction documents delineate the detail and the requirements for the construction and installation. Construction documents are binding legal documents. The contractor is legally bound to install the equipment, materials or systems as per the construction documents. The construction documents identify the responsibilities of the contractor, any interrelationships between the contractors and other parties involved in the construction, and the contractor’s rights. Many times construction documents are used to obtain government permits for the construction project.

Design versus Performance Construction Specifications

Specifications have two variations; one is a design specification, the other being the performance specification. Design specification explicitly state the requirements of the contractor without any deviation and the work has an implied warranty; performance specifications simply identify the results to be obtained, leaving the responsibility to the contractor as to determine how to achieve the performance results. And to further confuse the issue, there are times when the work involves both design and performance.

The construction specifications will describe the work and the required result, quality, installation practices, materials, coordination, documentation, etc. of the work.

Ambiguous Words

The designer’s responsibility in preparing the specifications is to clearly articulate requirements and responsibility.  If a specification uses words such as “any”, “all”, “always”, “some”, ”appropriate”,” handle”, “etc.”, “it” “user-friendly”, “seamless”, “state-of-the art”, robust, flexible, heretofore, securely mounted, carefully performed, common practice”, “minimize”, “maximize”, optimize”, “should” or phrases such as “as required” or “as appropriate”, it is not conveying specific enough information to the contractor.

Reuse of Specification

There are some designers that create a specification that is used over and over, sometimes simply changing the client name. A designer who has successfully utilized the specification will continue to use it because it minimizes their risk and work. In this case, the designer will need to clearly identify the unique needs of each project and revise the specifications appropriately. The larger issue may be a lack of interest in innovation or emerging technology that may be a disservice to the building owner.

Specifying Building Software

Information technology has relentlessly penetrated building systems, the result being many more software applications are being deployed in buildings. These include building automation, building management systems, facility management systems, work order systems, asset management, maintenance system, inventory systems, space planning and management, move management, room reservation systems, capital planning, energy and environmental management, integration platforms and other software monitoring and managing sub-systems.

Procurement of software requires design or performance diligence much the same as construction specifications. It requires the quantification of as many variables as possible, must truly reflect the client’s needs and environment, and clearly convey the information to the potential contractors.

Visualization is important in representing abstract data and understanding the meaning of the data. Specifications needs to identify who in the organization needs or can use the building data; this may include facility manager, building owners, general public, etc. Each group will require varying information displayed in different ways. Many vendors will have standard dashboard which may be a starting point in deciding on what the project requires. These dashboards are what many clients see as the project deliverables.

This is where a “hard” bid is different than an RFP. If the award of a contract is solely based on price you want to make sure that as much information as possible is quantified so the bids reflect similar efforts and deliverables. You will want to identify the number of data points, the number of dashboards, the number of applications, hardware requirements, the availability of control drawings, what is to be supplied by the client’s IT department, and the IT department’s standards for hardware and software.

In addition, the specifics of the building control systems, other sub-systems to be integrated, the responsibilities and required coordination of contractors for the sub-systems and the project schedule will all be considered during procurement.

The number of data points is fundamental to pricing the variety of software applications because each point needs to be configured in the software. This is quite a task to quantify the requirements of the programming document in as much detail as possible.

[an error occurred while processing this directive]The client must identify the required performance of the software. There are several performance indicators you will want to examine, such as user response time, throughput on the system, and reliability.

These requirements address redundancy, recovery time of software functions, resource utilization, backups of hardware and software, data loss and connectivity. If you are using a hosted solution on an enterprise basis and lose connectivity to a building, what happens to the building’s data?

Once the software and systems are installed identify the testing, acceptance and commissioning; there is a handoff process.

Much of what happens during the close-out and handoff of the software implementation is simply related to good project management.

Here are a few suggestions

• Establish a review and approval process for customized dashboards as to not get caught in an endless loop of revisions and reviews.
• If the installers are different than the manufacturer of the software, get the manufacturer’s representative to manage startup of the completed system.
• Address the warranty period including emergency and non-emergency services, vendor response times and software upgrades and changes.
• Have the contractor provide initial formal training and refresher training during the warranty period.
• Require that the vendor prepare a user manual specific to your configuration
• Obtain all hard and soft copy documentation related to the installation, including record submittals.
  

In a growing and rapidly changing marketplace for management systems, integration and software, it is important to take a methodical approach in the procurement and deployment of software and focus not so much on the marketplace but rather your unique requirements and building operations. 

The major parts of a specification will lay out the administrative and procedural requirements of the contractor on the job, list the equipment, materials and products required for the system and job, and describe how the products and equipment are to be installed, post installation requirements, documentation, warranties, etc.

Drawings

The other half of the construction documents are the drawings, an integral component in order to convey the design intent of the systems. The drawings show locations, relationships, dimensions, detail, etc. Many times the drawings for integrated systems show a schematic of systems being connected and or a chart listing of data points.