David Stutzman
It's linear - just like design! Start at the beginning and finish at the end. Straight line. No sidesteps. No circling back. No changed minds. Smooth sailing start to finish.
It's Not Quite that Simple
Writing specifications is straightforward. Specifications are highly structured documents. Putting the project data in the right location is fairly easy. Gathering the right data at the right time is becoming critical for project success.
Yes, just like design, specifications are iterative, and rarely linear. Take two steps forward, one sideways, one back, then forward again. Sound familiar? If you are part of a design team, you know this is typical. After starting, the path through design is unpredictable, until nearing completion - and then it may be a matter of your definition of completion. Is completion "issue for bid," "issue for construction," or "substantial completion?"
Traditional Design Phases
Architects talk about projects by design phase. Schedules still reflect milestones for each phase. I wish I could remember a project that actually followed traditional design phases- allowing the design team to complete and the owner to sign off each phase before proceeding with the next. Construction management, GMP, fast track, and design assist project delivery methods all blurred those phase lines long ago.
What are those design phases that we cannot let go:
SD - Start Designing (Schematic Design)
DD - Develop Design (Design Development)
CD - Continue Designing (Construction Documents)
Bid - Better Idea for Design (Bid and Negotiation)
CA - Critique Architect's Design (Construction Administration)
You see I have my own design-centric names for each phase. Though tongue-in-cheek, the names aptly describe what is likely to happen during each phase.
Speaking of tradition, it was not that long ago when specifications were written after the drawings were complete. That's right complete. The design team finished the drawings before handing them to the specifier. Today, the specifications may be developed ahead of the drawings - trying to capture the design intent to allow contractors to accurately price a project before the drawings are complete.
Traditional specification work flows are gone as well. No longer can we expect design to stop at the end of a phase and allow specifications to follow the drawings. The entire project and all documents must flow and simply meet at completion. But meeting is not enough. The documents must be well coordinated, too. Otherwise a liability exposure for the design team and a financial exposure for the owner may lurk in the detail - just waiting discovery, and at the worst possible moment.
Developing a Continuum
Today and for the future, we must find a way to make our specification process fluid and adaptable to the evolving design without having to stop and recreate any completed work. To adapt to the new conditions, we must abandon traditional thinking and traditional use of existing tools.
Specifications are not typewritten documents anymore. Nor can they be simple word processing documents produced with an electronic keyboard, monitor, and printer replacing the reliable Remmington and IBM Selectric typewriters. Today specifiers must tap the capabilities made possible by computing rather than trading manual for electronic processes.
With today's technology, it is not necessary to discard any document, once created. Information can be assembled and added as the information becomes available - mirroring the iterative design process.
Specifications are never original works. Yet they are often treated as though they are. We begin with a master document and permanently edit it to suit a particular project. But then conditions change. That text that was deleted from the master is now needed. Or the original version of the master is now preferable to the edits previously made. Traditional production methods do not allow a simple recovery.
Building Data Iteratively, Collaboratively
The process starts with a simple specification list or table of contents. Specifiers create the list of section numbers and titles needed for the project. As project data is collected and questions developed new data are generated and exchanged to refine the information.
But working from a master specification list, we are able to contract the list at the beginning to show minimal information and expand the list as data becomes available. Because it is a master we simply select what applies and expand again to add project specific notes as needed. When a design team response is needed, another expansion add a place to collect their input. Each step builds a record, a composite road map and coordination tool for creating the final specifications.
Outline specifications should never be a set of separate documents - and certainly not the traditional throw-away documents delivered at the end of DD phase. Outline specifications are a valuable collection of the initial design decisions. Once recorded, specifiers should reuse, never recreate.
Working from master construction specifications documents, we create outline specifications as a limited view of the master document. None of the underlying data are lost by traditional word processing deletion. Instead the data is simply not displayed, but remains available for future use when needed for the construction specifications. Collapse the master document data, build the data as the design progresses, and display data only when appropriate and only when needed - outline spec, first draft and final construction spec.
Bring on Automation
Any task done more than once is a candidate for automation. It seems simple enough, but most people working with computers are barely scratching the surface of the computing capabilities and potential automation. In many cases, it's like giving a formula 1 race car to an Amish farmer. His horse can't pull it any faster than it can pull the wagon. Automating specifications is not really about saving time - although that is a great side benefit. Automating specifications is about maintaining quality.
Automation allows repeatable, predictable document creation, editing, checking, and publication. It allows our multiple Conspectus specifiers to make identical decisions from basic project facts to begin the specifications editing process. Automation allow us to easily custom build and modify specification editing decision trees based on real-life experience and construction administration phase feed back. Self created automation allows the distinct benefit of documenting the rationale for the automated decisions - something that is sorely missed when relying on a commercial master specification system.
More Than Typing
So, there is more to specifications than simply typing, especially to accommodate today's project delivery methods. Recreating data is a complete waste of time and prone to errors. As a penalty, there ought to be a LEED point deduction for any team using inefficient design documentation processes.
You may not think of your design production process as being a sustainable strategy, but inefficiency may well lead to an unsustainable business.