Design needs to stop before the Construction Documents phase begins. New scope1 shouldn’t be added by Owners after Schematic Design. Changes to building systems2 shouldn’t be made by Architects after Design Development. The only “designing” that should happen during the Construction Documents phase is the refinement of things already decided upon.
But don’t stop designing until all those decisions have been made! Until all major building systems have been selected, the Design Development phase shouldn’t be over.
As an outside specifications consultant, at the end of Design Development, I ought to be able to take my 100% Design Development Outline Spec, review it side-by-side with the Architect’s 100% Design Development Drawings, discuss any conflicts and gaps and unknowns with the Architect, produce a final Table of Contents for the Project Manual, and run with the Construction Documents specifications, asking a few questions along the way. I shouldn’t have to be adding or deleting spec sections in the middle of CD’s, or worse, in an Addendum.
These thoughts are from my point of view, the specification consultant’s point of view, but I am not just thinking of myself. If everyone on the Project Team (Owner, Contractor if there’s a Contractor on board before bidding, Architect, Consultants) subscribes to this idea, and helps to enforce it in his own company, and holds the other members of the team to it, we’ll have much better Construction Documents, much smoother construction phases, and fewer unknown costs for everyone involved.
Implementing this requires some careful communication among the Project Team. Architects need to take the lead on this, and need to explicitly explain to Owners their expectations about timelines for Owners’ decision-making. Architects need to explain up-front that they will require extensions of schedules and additional architectural fees if Owners make changes to scope or changes to systems after the appropriate time for scope changes or systems modifications. (If these untimely changes happen, Architects then need to insist that the schedule extension and fee addition requirements be followed-through on.) Architects need to realize that since it makes sense to charge the Owner more money for this sort of untimely decision-making, it makes sense to ban this sort of ill-timed design from their own practices. (This is often a company culture thing – attitudes about this come from the top. So, principals, if you want your projects to be profitable, you need to communicate your expectations that your project managers will not make design changes during the Construction Documents phase. You also need to keep yourself from making design changes during the Construction Documents phase!)
This post is adapted from the comment I posted on David Stutzman’s “Architectural Design Phases” post on the Conspectus blog, http://www.conspectusinc.com/blog/2011/12/architectural-design-phases.html . David’s post, and some comments on the post, also provided me with some additional ideas.
- “Scope” is “scope of work,” which defines the extent of the project.
- “Building systems” are the assemblies that make up the building. Window systems include storefront, curtainwall, etc. Exterior wall systems include brick veneer with steel stud backup, metal panel rainscreen, single wythe CMU, etc. Roof systems include single-ply membrane roofing, asphalt shingles, metal roofing panels, etc.
Denver must have moved from the surface of the earth to the perfect world above since I was last there!
Most architects know no time limits on design – it usually continues well into the construction phase. Sometimes is not necessarily within their control – things happen – someone misses a code requirement – an interface doesn’t work and requires a different assembly choice – some materials require an unknown long delivery time, etc., etc.
Interior Design – another world in terms of design timeline – new materials almost always come to light during CD’s – more realistically at the end of CD’s.
I don’t think I can remember a project where some sections were not added or subtracted during CD’s.
You can describe the perfect project timeline where every project team member gets the right information they need by the time they need it and that information never changes later. Doesn’t happen in the real world because all the project team members are not perfect. They forget things. Their early analysis is not always right. They have other project time pressures that keep them from giving enough attention to this project. Some people are more experienced and capable and better team members than others. Etc., etc.
I don’t think you are going to change this by any penalty system.
I think the way to try to alleviate the problem is to try to build the best project team you can. You try to recruit good team members. Then it is comunication, communication, communication. Every team member needs to be aware of the needs of the other team members and to communicate his/her needs to other team members. You want a real team spirit where the project needs are very high on people’s agenda, where people are willing to go the extra mile to help others on the team when something goes astray no matter where the fault for the problem lies. Everyone wants a sucessful project. Those of us with some experience can look back on a project(s) like this where the team really worked well together, overcame obstacles, and produced a great project. We can also remember other projects where some team members failed others resulting in all sorts of problems.
If you are consitently a good team member as partially described above, you will be selected for more project teams. People remember who they had good experience and results with and they will go back to them. They will not select people with whom they have had bad experiences. Good team members will tend to be selected to work together on future teams.
True, all true, Bob.
But some teams START OUT WITH the idea that they can keep changing, keep designing, keep modifying scope, keep selecting assemblies (thanks for the comment below). Some teams honestly start out with the idea that they were given a deadline, but it doesn’t mean much, they can issue documents at the deadline and fix things in Addenda. They count on it, they plan on it. SO, interns at these firms don’t even know what the ideal is – they don’t know what they’re shooting for.
If we don’t shoot for complete, coordinated Construction Documents sets BY THE TIME DOCS GO OUT TO BID AND IN FOR PERMIT, we’ll never even get close to complete and coordinated by the time pricing and permitting are complete.
If the expectations that are set are the IDEAL, the results will be much better than when there are no clear expectations, or the expectations that are set are less-than-ideal (“we’ll work that out in the field!” “we’ll pick that up in an addendum!”)
Picking things up in addenda or in the field are for the UNEXPECTED changes. Not for the planned changes. And Denver, while I think it’s perfect in many ways, is quite imperfect in the area of construction documentation, and many people seem to PLAN to finish designing in an addendum, or through ASI’s and Change Orders during construction.
The time schedule needs to be set out at an early project team meeting. Milestones or submissions need to be defined as to requirements and inclusions/exclusions. Team members need to communicate their needs to meet the agreed upon milestones/time schedule with a time schedule for required information/documents from other team members. The project team should agree upon and commit to the project plan including schedule, required information, and documentation. This may be the “ideal” or not dependent upon the project situation/requirements.
For example, Dave Stutzman’s client’s demands for 100% specs at 50% DD drawings are certainly not ideal – they are putting the cart (specifications) before the horse (drawings). In that situation the team has to come up with a plan to try and do that (glad I don’t face that with my clients). One of the questions that should be addressed by the team is what information does the specification consultant need by when to produce the 100% specifications? Who is going to provide that information in what form?
What I am saying is that the plan for a particular project may or may not be “ideal,” but the project plan must be agreed upon and committed to by the team members at the beginning. I would agree that a good starting point for the project plan is the “ideal.” The plan can also include what is not allowed in terms of revisions after certain milestones. The important thing is to have a agreed upon defined project plan, maintain good communication, monitor compliance with the plan, and make agreed upon modifications to the plan when necessary.
I would recommend that you use CSI recommended terminology where possible.
Instead of “building systems,” I would suggest that you use terminology out of UniFormat where what you are referring to is called functional elements, or systems and assemblies. Systems usually refers to operating systems such as various types of equipment or mechnical or electrical systems. Assemblies refers to the functional elements made up of more static components into any assembly such as an exterior wall assembly.
Thank you, Bob. I will do this in the future. I really, really, appreciate your comments.
I would also say that Dave Stutzman’s blog relates very closely to a discussion he started on CSI LinkedIn: http://www.linkedin.com/groupItem?view=&gid=706547&type=member&item=81966914&qid=7e5902a4-bd23-4775-bc2d-d2911eafd6d1&trk=group_most_popular-0-b-ttl&goback=%2Egmp_706547.
That discussion is really about the problems when clients require full specifications at 50% DD Drawings for early GMP contracts. That situation obviously creates problems later during CD’s. There is extensive discussion of the topic at CSI LinkedIn.
Liz, thank you for mentioning our blog in your posting. I am thrilled to see discussion spilling over to others. It is so important that everyone in the process be aware of their agreements and deliver what is required. That would help solve some of the late design change problems many face.
I am reminded of a quote from Kepple Small, one of my architecture professors, “Architecture is never done. You just run out of time, patience, or money.” Sometimes I think that the “money” aspect is no longer considered a factor, allowing design to continue until the keys are handed to the owner.
I really enjoy following your blog. Keep up the great postings.