A design that exists only as sketches, or in an architect's head, can't be built. Between a design an owner loves and a house that can actually be constructed lies a large body of information: drawings, specifications, engineering and details. It's the least visible stage of a project, and the one owners most often underestimate.
Four readers, four questions
The information a design produces has to work for several different people at once, and each of them is asking something different of it:
- The reviewer
- Does it comply with the rules that apply?
- The estimator
- What will it take, in materials, labor and time?
- The builder
- How is it actually put together, and in what order?
- The owner
- Is this what we meant?
A set of drawings that answers one of these readers well and the others poorly isn't finished. Much of the discipline of documentation is making one body of information answer all four.
What the information includes
- Drawings
- Plans, sections, elevations and details, showing what is built and how its parts meet.
- Specifications
- The written side: which materials and products, to what standard, and how they are to be installed.
- Engineering
- The work of consultants, such as structural, mechanical, electrical and civil, which has to fit with the architecture and with each other.
Coordination is where the pieces are tested
Each consultant is responsible for a different part of the project. The difficulty is that all of those parts have to occupy the same house. A duct has to pass a beam. A window can't sit where the structure needs to carry load. A stair has to clear the framing above it. Each of these is easy to resolve while it's a line on a drawing and expensive to resolve once it's built.
A conflict found on paper is a conversation. Found in the field, it's a change order.
That's the same principle described in what it means to build the project digitally before building it physically: decisions are cheapest to change while they're still information. Coordination is the work of finding those conflicts, and settling them, before anything is purchased or built.
Complete enough to price
How complete the information is also determines how reliable a price can be. Where details are unresolved, a builder has to make assumptions, carry allowances and add contingency to protect against what they can't yet see. The more fully the design is resolved, the less guessing is built into the number. That's what makes the progressive testing of cost described in the project budget article more reliable as a project develops.
The information doesn't simply get handed over
In many projects, this information is produced by one party and handed to another to price and build, and questions that arise afterward have to cross that gap. When architecture and construction are carried by one team, as described in Architecture + Design-Build, the people who produced the information remain directly connected to the people relying on it in the field. That continuity reduces the distance between design intent and construction decisions.
Even when they aren't, the architect's role often continues through construction, answering questions and reviewing work against the design intent. The scope varies by project and is worth understanding at the outset.
Questions to ask about documentation
- What will the documents include at each stage of the design?
- How will the consultants' work be coordinated, and how will conflicts be found?
- How complete will the information be when the project is priced?
- Who answers questions during construction, and how?
These work alongside the groundwork described in what an architect does before drawing the design. That work establishes the conditions. This work turns a resolved design into something that can be priced, approved and built.