Are Project Design Phases Relevant?

Specification & Product Discussions
1

AIA and EJCDC contracts define design phases as though contract documents are created and delivered in a linear fashion. Is it linear, anymore? Should there be a new framework?

We see construction starting before design is complete. Early work packages are issued to expedite the construction schedule while design continues - and in some cases tries to catch up. Are Schematic Design (SD), Design Development (DD), and Construction Documents (CD) just a point in time for a contract deliverable without relevance to the actual content delivered?

I have two examples to share. Both are hospital projects. One is a single building the other multiple buildings. Both are under construction.

I just completed revision 27 for the first project. That is one revision per month since the “start” of construction. I am told there are more revisions to come. For the second we laid out a plan with the architect to deliver the multiple buildings in different project phases. The plan was abandoned at the kickoff meeting. Now after 69 spec deliverables, I believe, but am not 100% certain, our work may be done.

Granted these are not small projects. But the example they provide is not unusual, regardless the project size. There are just more extreme. I picture design more as a vertical spiral passing through each design phase multiple times before “finishing.”

What do yo think?

2

I was part of AIA’s Contract Documents Committee for 11 years. I chaired the 2017 A201 General Conditions update Task Group and Co-Chaired the 2019 Construction Manager Family updates. Your questions were a real point of discussion for both sets of documents. We used to have a clear demarcation between design phase and construction, and now, it’s a long, large grey area not only when construction starts, but what constitutes “construction” as design work is released early to a contractor (for example, having a contractor/specialty subcontractor start their design and produce shop drawings based upon performance criteria- are those part of the “design” phase or are those now “construction” since the contractor is doing it?)

We’ve had the ability to kick design to the contractor for a long time through performance specifications. With the CM updates, we tried to address what we called “early release work,” basically fast tracking some portions of the work before a full cost agreement is reached.

The admitted problem that our industry faces is that the “phases” of the design team’s work, as traditionally defined, are deeply embedded in other portions of the industry, so even if we, or AIA, tried to rename and/or redefine those categories, there would be a long time mismatch to artifacts in public contracts and laws, etc.

Suggest that the best defense for consultants and designers is what is already in the agreements with the prime or owner: limit the number of changes to documents that you’ll do and accept under your basic agreement for services, and then any additional change becomes a compensated additional service. Whether you price that up front, actually attempt and/or succeed in collecting it, it places a clear limit and understanding on what you are and are not willing to do. (If you are using the AIA C401, Architect-Consultant Agreement, it would be:

§ 11.2 For Additional Services that may arise during the course of the Project, the Architect shall compensate the Consultant as follows:

(Insert amount of, or basis for, compensation.)

1 Like
3

Thank you for the reply Arlen. I agree that the clear demarcation between design phases is blurred for all the reasons you cite. I also agree that the industry is accustomed to the traditional design phases and making a change would be a monumental effort to complete.

My concern is less about the compensation and more about the documentation and ultimately the project quality.

The issue is to know what decisions are final and what documentation is reliable to proceed to construction. If the project delivery is well planned (the number of deliverables may be irrelevant), the team can manage the risks. If the delivery is haphazard (as it seemingly was for my example projects), the risks can be enormous, especially when changes impact work already put in place.

1 Like
4

I think both of you touch on a meaningful, but highly flawed, kernel of truth behind the traditional phase designations… universal assumption of what is “complete” in the design process part of project delivery.

I think all can agree what “complete” looks like for the actual construction (although many contractors will argue about their obligations at the very end so they can close out and finish getting paid). Extrapolating the phases of construction progress (some arbitrary system of 25-50-75-100, 30-60-90-100, or whatever percent breakdown) to track progress, and thus payment for the contractor, is evident by comparing a “zero state” to the “end state”. If 50% of what has been designed, documented, purchased, and installed is clearly visible (thus verifying claims by the GC and subs in their invoicing), the everyone should be able to have a common agreement/understanding of progress. However, one error that is commonly made, is that the “time” vector is a strict indicator of progress when every hates to admit the uncertainties (weather, labor, supply chain, calendar, pricing, cashflow, etc.) that will inevitably disrupt even the most well-meaning, conservative schedule.

But as @David_Stutzman pointed out, in a highly dynamic, reiterative, and decentralized process of design - from initial ideation through “finished” construction documentation - delimiting the design process into “percent complete” tied to some standard (which is often massaged for a firm’s or project’s purposed) phase is fraught with potential failures from the very beginning. I believe that even after hundreds of years and generations of practice, we are still no closer to an essential efficiency, and thus predictability, of the design process that enables consistent, repeatable results that adhere to any arbitrary standard devised. Besides the completion of content, time is yet again injected into the formula, thus ensuring all expectations are doomed to be disappointed.

Early in my career, I was always frustrated by the incongruities and inconsistencies of progress in the design and contract documentation on any number, types, and sizes of projects. Software, like CADD and then BIM, never really seemed to make an appreciable dent in solving the problem… many times even exacerbating it. When I pivoted to being part of AEC software development, I thought there might be an opportunity to help architects make things better… nope. And working in the standards world nearly exclusively for the last 10 years has proved nothing but the same… no meaningful, fundamental changes or progress.

At the same time, I saw how the legal profession had no such artifices… the client paid for time spent or risked losing legal representation and ability to “win” a legal dispute or properly construct contracts. But, then again, the concept of progress is different, isn’t it. There is a zero state and an end state, but just a lot of incremental work in-between. And in the medical world, progress is completely arbitrary and services are pay-as-delivered, sometimes even completely disconnected from an end state (sadly).

I guess we’ll never really find a meaningful answer/solution/standard as long as the design process and humans remain as messy as they are. Does this mean we’re just doomed to be inefficient in the process?

1 Like
5

Time is not normally a good measure to determine relative completeness. In construction that last 10% will take longer than any other 10%.

I must add that my design professor always said design is never done, designers just run out of time, patience, or money. As an architect and from my experience as specifier, I agree.

3 Likes