A product can be current in the selection guide and out of date in the specification. The owner may have chosen an available finish, and whoever is procuring it may have the right model number, while the person preparing a submittal is still reading requirements written for the previous product.
Catching that takes someone who can trace the selection through the documents and decide which requirements need to be revised. A shared product list helps organize the information, but the person reviewing it still has to open the source material and check it against the project's requirements.
Catherine Smeykal, who has written specifications for projects in the MasterFormat standard by working through selection guides one product category at a time, describes this problem in her article on turning material selection guides into specifications. The approach she describes maps each product category to its MasterFormat section, places product data in Part 2 of the three-part SectionFormat structure, installation in Part 3 and submittal and warranty requirements in Part 1, and treats the guide and the specification as linked documents that are reviewed together at every update. The workflow below follows that approach and extends it to the schedules and drawing details that a product change also reaches.
Start with the selected product and its source
A selection guide helps people compare choices. It may show a product's appearance, available finishes, options and price tier. A specification has to describe the project requirements clearly enough for the work to be priced, supplied, installed and reviewed.
That means a product name is only part of what has to move between the two documents. Depending on the product and the project, the reviewer may also need dimensions, performance characteristics, accessories, installation requirements, submittal requirements and warranty terms.
For each selection, keep a record of the manufacturer, product line, exact model where one applies, selected finish and current decision status. Some finishes carry conditions of their own, such as whether the product will sit under UV light or needs a particular installation method, and those belong in the record from the day the finish is selected. At minimum, keep what Parts 1, 2 and 3 of the section will need. Include the source of the technical information and its date or revision. A manufacturer's current data sheet is a more useful reference than a model number copied from an old project.
Where a choice is still open, leave that status visible. An unresolved selection needs a named decision owner and a place in the review.
Map the selection to the documents it affects
A selection guide and a specification do not necessarily divide the work the same way. One flooring page in a guide might cover products that belong in several specification sections.
MasterFormat provides the numbers and titles for organizing specifications by work result. Use the applicable section titles and the project's own specification structure to build the map, then add the schedules and drawing details that also refer to the product. CSI's standards overview explains the role of MasterFormat.
For a hypothetical flooring replacement, the map might include the selection guide, the relevant specification section, and the other sections that correlate with it, such as the one covering transitions to adjacent materials. The reviewer decides whether the change also reaches substrate preparation, accessories or other requirements, and that depends on the replacement product and the project.
The map should be specific enough to use during review. A section number, a sheet reference or a schedule location gives the person making the change somewhere to start. It should also be clear to someone who was not in the room. A change like this passes through many hands before approval, not because of oversight nobody needs, but because that is how many people it takes to put up a building.
Carry the requirements into the specification
In a section written to the three-part SectionFormat structure, the information is organized under Part 1 General, Part 2 Products and Part 3 Execution. MasterFormat says where the section belongs; SectionFormat organizes the text inside it. CSI's SectionFormat overview describes it as a uniform standard for arranging the specification text in a project manual's sections.
Part 2 is where the selected product's characteristics usually sit: manufacturer, material, model, finish and the performance requirements that apply. Each of those needs checking against current technical information and the project's design decisions.
The review also has to reach the other two parts. Part 1 may need submittal, quality assurance or warranty requirements updated. Part 3 may need provisions for examination, preparation, installation, field quality control, cleaning and protection.
Which part a person knows best depends on their role. Catherine works mostly in Part 2, Products, because as a designer she is the one selecting them, and by her own account she only scratches the surface of Part 1 and Part 3. The review has to cover all three regardless of who starts it.
Under a project's own requirements for proposed alternatives, substitutions and approvals, a product that looks similar, or that meets one listed characteristic, may still need review against the remaining requirements, and the approval path has to agree with the contract documents.
Review a change as one connected task
Suppose the guide replaces a flooring product, but the specification still names the earlier line. The review starts by identifying the proposed replacement and pulling its current technical information.
From there, the reviewer compares the dimensions and available finishes, checks whether the installation instructions call for anything different, and reads any finish schedule and details that show the product against the intended result. Each question gets resolved for the particular replacement product before the revised documents are issued.
A useful change record gives each reviewer what they need to follow the decision:
- The previous product and the proposed or approved replacement
- The technical source used to check the replacement
- The specification sections, schedules and details reviewed
- The person responsible for each unresolved decision
- The status of the document revisions and their final review
Keep the decision status and the document status separate. A product may be approved while the specification revision is still pending, or a draft section may already carry a proposal that has not been approved. Both situations need to be visible.
Keep a shared product record, with a review step
A spreadsheet or database, as Catherine suggests, can hold the current product information and point at the documents that use it. That gives the team one place to record a change and see which documents are due for review.
It still needs maintenance. Someone has to check whether the manufacturer's information is current, whether the selection has been approved and whether the issued documents reflect that decision. If software helps find references or compare versions, the reviewer should be able to open the underlying source and confirm what it found.
Before an issue, compare the selection record with the affected specification sections, schedules and details. Record any remaining question, who owns it and how it will be resolved through the project's established process.
The practical aim is a product change that can be traced from the selection through to the requirements used by the people supplying and installing it. When those connections are visible, a reviewer works through specific decisions instead of guessing which document holds the latest answer.
Based on an article contributed by Catherine Smeykal, adapted for Setmark.