Writing construction specifications is like assembling a jigsaw puzzle. Except puzzles always have a photo of the completed puzzle on the cover of the box.
Not so for construction projects. Usually construction specifications are assembled from bits and pieces, while the design team tries to decide what the completed "box cover" will be. Sometimes the specifications are finished well before the design.
When specifiers begin their work, basis of design product selections are few and far between. So how is a specifier to start?
Just like the puzzle, we search for an edge, a piece that will help define a boundary. But some edge pieces will be missing. So specifiers begin making notes and asking questions - sometimes many questions - trying to comprehend how the pieces will fit together to create the design team's artistic masterpiece.
The specification table of contents or a specifications checklist is a great tool for identifying and collecting the initial notes and questions. Specifiers start by listing the proposed sections needed to describe the project. Some sections will be certain, some will be probable, and some will be questionable depending on how the design progresses. Unless the design is complete, the first table of contents will be an educated guess based on knowledge of the project type and experience with the particular design team.
The contents will contain notes about what may be specified in each section. It will also contain questions and coordination concerns for the design team to consider while developing the design. Hopefully, the team addresses the comments and answers the questions before the specs are started.
Okay, okay! I did say "hopefully." There is still hope it could happen, someday.
Because time does not stand still and because the project manager promised the owner a draft spec for review, the specifier must start, even if not entirely ready. The unresolved comments and unanswered questions must not be forgotten. Specifiers will transfer the notes and questions from the table of contents to the draft specifications and inserts even more as the specification detail develops.
Within the specs each note and comment will remain until they are resolved.
The notes and questions are not static. As one question is answered, another may result. The specification becomes the living repository of what is needed to complete the project: additional information, decisions among options, coordination among documents, and more.
Specifiers can assign responsibility for addressing each issue. We often start our notes and questions with the party responsible: Architect, Owner, or Specifier (in our case that is Conspectus) so it is clear who must respond.
Electronic documents make notes in specifications an effective tool for collecting project data and coordinating design. Consistency is key to ensure notes and questions can be easily found. Distinct formatting so the text stands out within the specification is one way. Labeling the text with the name of the responsible party (as shown above) or simply as a "Project Note" is another. Combining formatting and labeling can provide excellent, distinctive results.
Within a single PDF file, every note for the entire project can be found, easily, and viewed in context with the search (not find) function. To make searches especially effective, begin each note with a character or set of characters that will never appear elsewhere in the document. In the example above, inserting a "|" vertical bar at the start would make all notes unique from other text. Searches for a vertical bar would locate every note and selective searches for "|Owner" would locate every note addressed only to the Owner. The result becomes a powerful coordination tool for the entire design team!
Once notes are found, the design team can simply insert a reply or add other comments and concerns as appropriate.
With automated tools, notes are easily compiled from every specification section into a single document as a convenient checklist of remaining issues. To make the compilation work the notes must be entered consistently. Extracting notes as a compiled list presents a challenge. Notes such as "Verify the following" have no meaning when taken out of context in a separate list. Some of the specification text may need to be repeated in the note to be viable when read out of context. Caution: providing a compiled list may encourage reviewers to simply rely on the list instead of reading the specification.
When answered, simply delete the note. When every note is answered and deleted, the project is ready to publish for bid and construction.
Take advantage of today's electronics and specifications to manage project data. Use the specifications as the coordination and outstanding question repository to ensure every issue is addressed before the construction documents are issued.
