The Outline Spec Dilemma: The Significance of Purpose and Clarity

Outline specifications are, from my perspective, one of the most misunderstood deliverables in the industry. Typically, an Owner’s deliverables list includes outline specs at the Schematic Design phase or early in the project, alongside the Drawings. However, this requirement is often vague at best, with only a general mention of outline specs.

Asking the question, “What does an outline spec mean or look like?” yields a wide variety of responses, ranging from “Let me ask the owner” to a blank stare. I’ve heard everything from “Just do a table of contents” to “We don’t need specs ☹️,” to “Just send the products in Part 2,” or even “Send the full specs unedited.”

What purpose does sending a table of contents serve? Does anyone review it? Is it actually used for anything? While it may be a decent starting point for the future development of a spec, I don’t believe this aligns with the intent of the term “outline spec.” Instead, an outline spec should include useful (and usable) information that contributes to the development of comprehensive specifications down the road.

Some spec writers are hesitant to invest time in developing outline specs, believing the effort wasted since these documents may not be reused. They assume they will need to start from scratch when creating full project specs. However, with advancements in digital tools and database platforms, it’s possible to maintain continuity within a single document, allowing for toggling or switching between outline specs and full specs.

I’ve seen, on occasion, architectural specifications within a project manual where a spec writer has prepared a concise outline spec with just the essentials—sustainability information, key submittal requirements such as delegated design or mockup requirements, basis of design (if available at this stage), or a list of manufacturers. Yet, other consultants often follow these divisions by inserting unedited full specs, which defeats the purpose of the requirement and creates an inconsistent, unprofessional result. I firmly believe that, just like drawings, spec deliverables from all contributors should be comparable, cohesive, and well-coordinated.

When creating outline specs, the first step should be to clarify what is actually required. Often, no one has a clear answer. To address this, I like to have a standard set of questions ready: Do you want a table of contents? A document listing section numbers, titles, and a brief description of each (essentially the summary or section includes from Part 1)? A spec narrative? A true outline in three-part format with minimal information? Or unedited long-form specs? As a spec writer, it’s critical to consider the audience—primarily creative and visual professionals who work with drawings. During these discussions, it's helpful to provide quick samples of each type of deliverable to the owner and architect for review.

What are your thoughts? What have you encountered? How do you define an outline specification?