Friday, August 26, 2016

Be a Part of the Solution, Not a Part of the Problem

I use this line frequently with my children: be a part of the solution, not a part of the problem. The lesson is to solve problems, not point fingers. Think about this: when pointing your index finger at someone else, your other three fingers are pointing back at you. The other lesson of this message, though not overt, is to communicate to solve problems. Learn from your own shortcomings and work to correct them.

I attended a meeting this week with a client who we designed a building for but they were unable to secure funding for construction once the documents were complete. The project sat for 2-1/2 years and now about 80% of the funding is available, so we are being asked to re-program the building to eliminate about 20% of the square footage. In the room at the meeting were 20 people, some of whom were involved in the original design and some of whom were not.

There was much discussion of what should happen but no offering up of solutions. There was a lot of "cloud talk" with little substance. I find this a lot with design and construction projects: people around the table that either do not understand the design and construction processes or understand a very limited swath of the process. How do we overcome this? Communicate, educate and collaborate.

Nearly every problem in life can be solved by clearly, openly and honestly communicating. We all have sensibilities and needs that we bring to our work and to the projects we are involved in. Guard that those aren't turned into hidden agendas. Trust and communication break down when someone feels they have been wronged or not treated fairly. Be timely in how you communicate with your teammates and always be open and honest. More often than not, that honesty will be reciprocated. 

Since many clients will build maybe one or two buildings in their lifetimes, we should first and foremost educate our clients about the process, the pitfalls and the opportunities for success. There is a trust factor built in here: your clients will only be educated if they trust you and allow themselves to learn. Part of that trust is rooted in believability. Your explanation of process must sound believable and should not include phrases like "this is how it is done" or "because we have always done it that way." Trust is best built when all questions are answered and concerns are eased.   

We are stronger as a group than we are as individuals, so collaborating and utilizing everyone's skills and strengths to the fullest helps ensure success of the group. Collaboration is not easy; it is like any othe relationship: it takes time to develop and it is built on trust. Honesty, confidentiality and accountability are the paving stones that collaboration is built on. Transparency is the glue that holds the collaboration together. 

I'm sure many of you try to practice these things in your dealings in our industry. Writing a blog focused to members of our industry may be a bit like preaching to the choir: if you are out looking for help, you are probably already a part of the solution! Hopefully, this blog gives you some vocabulary to use. 

Tuesday, August 23, 2016

Mockups: What's the Big Deal?


On several recent projects in our office, we've had some atypical mockups: discrete pieces of laboratory casework, full room mockups and performance-tested mockups. Even on projects with the more typical aesthetic mockups, there seems to be differing opinions of the purpose, process and approach to making mockups useful and successful. 

Like with all items in construction, the requirements for mockups start in one or two places. The project manual should include the requirements for mockups in Division 01 and in certain technical sections while drawings may also be provided to indicate the extent of the larger mockups required. 

Our firm's project manuals include requirements for mockups in Section 01 40 00 Quality Requirements. Our typical Section 01 40 00 defines mockups this way:

"Mockups:  Full size physical assemblies that are constructed on-site.  Mockups are constructed to verify selections made under sample submittals; to demonstrate aesthetic effects and, where indicated, qualities of materials and execution; to review coordination, testing, or operation; to show interface between dissimilar materials; and to demonstrate compliance with specified installation tolerances.  Mockups are not Samples.  Unless otherwise indicated, approved mockups establish the standard by which the Work will be judged."

I particularly like the sentence "Mockups are not Samples." Our Section 01 40 00 does not contain a definition of "samples" but I think that definition is generally understood: small pieces of the actual material, thickness, color and finish that will be used in the work. While the mockup definition includes the notion of creating an assembly, it is not an assembly of samples, as noted in the sentence referenced above. A measure of each material, in the exact size, thickness, color and finish specified must be used to create the mockup, but not a series of easily and readily available samples. 

The other ideas put forth in the mockup definition that are important are the purposes of the mockup. Note the plural term "purposes." A mockup can used to set the quality, demonstrate the aesthetics and review coordination, testing and operation of the materials. These are all important and legitimate uses for the mockup. I think the commonly misunderstood idea is "to review coordination, testing, or operation."  


We currently have in construction the fourth residence hall renovation for a long time client. The four buildings are similar and have similar systems installed. For the four buildings, we have had three different construction managers and myriad different trade contractors. We have some clear wall framing details that incorporate the window details, fan coil unit and its piping, wall insulation and other items. These details have evolved based on knowledge gained in the early buildings. For the first two renovations, we directed an off-site mockup be built to help all trades understand the coordination needed as the client was seeking to minimize space lost within the room: even 1/2-inches are important. The off-site mockup was also critical because the first three renovations  featured summers only construction so the residence halls could be occupied during the school year. Coordination was critically important as the contractors had 11 weeks to mobilize, demolish, install new, punch out, final clean and demobilize. 

For this fourth renovation, the CM and trade contractors have 12 months. Unfortunately, the CM did not seem interested in the mockup at all. I was unable to convince him of the necessity or utility of it. It is a contract requirement, so he did it, but he did not seem interested in learning from it. I find that to be incredibly short sighted, but as I said, we do have very clear wall framing details. However, at a critical time in the construction schedule, he was directed to remove a significant portion of non-conforming work and replace it. If this had occurred in just the mockup room, it would not be a big deal. However, the trade contractor had installed this non-conforming work across 1-1/2 floors of a 5 floor building. 

This story is played out on project after project and I partially blame us as the architect. Here's how this particular mockup is described in Section 01 40 00: 

"Bedroom Mock Up: In one resident bedroom, install fan coil, exterior wall framing, high impact gypsum board, fan coil enclosure, fan coil control, insulation and vapor barrier."

While this is an apt description of the work result, we should have mentioned the purpose of the mockup and how the client would like to see the work in progress as well as the work result. While out of sequence work is problematic to the CM, is that less costly to he and the trade contractor than removing 1-1/2 floors of installed work?



As with most things, communication is the key. In addition to defining more than just the work result in our specifications, we should have asked that mockups be reviewed in a pre-installation conference and in the progress meetings (Section 01 31 00) and included in the overall construction schedule (Section 01 32 05). 

Another way early communication could have helped is with vapor barrier continuity. In the exterior wall particular detail, designed by an exterior envelope consultant after performing a dew point analysis on the first of the four buildings, the vapor barrier is formed by the facing material on a rigid insulation board adhered to the existing CMU walls. It was to be gapped 1/4-inch between boards and at the room perimeter and that gap filled with a sprayed foam insulation. Not all of that got communicated into the documents, though on the first two buildings with off-site mockups, that work was included based on comments on the mockup. 

So, how can an architect help manage the mockup appropriately? I think it starts with clear direction in the contract documents and better descriptions of what the purpose of the mockup is and how the review of the mockup is expected to proceed. In the bedroom mockup description above, adding a simple statement of "the architect and owner will review the mockup in progress at regular intervals" might have sufficed. Noting that there should be a pre-installation conference or discussion of mockups at progress meetings certainly would have helped.

More importantly than that, interpersonal communication would have made the situation better. The CM was on the project team from the design development phase. The balance of the team was performing their fourth project together and assumed everything was known to all parties. We, owner and architect, should have spent more time discussing the mockups with the CM and reviewing the expectations, especially when the CM experienced a project manager change and when a procurement situation delayed the start of construction. 

If the mockups are important to the owner or to the design professional, more care must be taken in communicating those requirements to the construction team than merely putting the requirements in Division 01 sections and remaining silent in other communications. If the project is design-bid-build, then the mockups should be discussed at the pre-bid meeting so that all bidders are made aware of the requirements and importance of the mockups. 

Conversely, if the mockups are not important or serve little or no purpose, then don't include them in the work. Expecting construction teams to schedule out of sequence work for little good to the project is counterproductive to the overall project goals. It could also foster a sense of being "handled" by an untrusting owner and an unforgiving architect. Worse, it could open the construction team up to expectations beyond the stated or specified goals of the mockup. 

On a recent laboratory project, an overzealous CM directed the laboratory casework bidders to "provide one of each piece of casework in the project" for a mockup. What ensued was a disjointed collection of items that served no relationship to each other or to the completed work. The owner was confused when reviewing the items as they were arranged in a manner that did not match the completed work and the owner nearly rejected the entire mockup. In my mind, this mockup served little purpose and only caused the construction team and design team to expend numerous hours trying to understand the purpose, direction given to the bidders and then educating the owner's team on the true purpose of the mockup. More communication upfront between CM, owner and architect could have helped this mockup come off better.