Collaboration Part 7 - Change, Change, Change

by Marvin Kemp, AIA, CSI, CDT

We've had two collaboration meetings since my last blog posting on the collaboration effort I'm participating in. To recap, our firm is involved in a very large, biomedical research building project at a local public university. The delivery method is CM-at-risk with design-assist for major trades. Looking back through this blog, you can read about the entire process. It all started here.

The most recent collaboration session was last week. Each of the past two meetings also contained a social event. Following our formal meeting, the group went to a local bowling alley for drinks, food and duck pin bowling. If you're unfamiliar with this sport, check out this Wikipedia article. Both times not everyone went bowling, but the group that did had a great time and got to know each other a bit better. I think the social events will become a regular part of our collaboration time together, though duck pin bowling may get old and something else will need to be tried. 

As the title of this posts states, the team continues to change and change. Since my last collaboration post, these are the personnel changes the team has encountered:

• PA for the architect of record retired
• Assistant PM for the AOR has been reassigned to a different project, but has been brought back because two of her replacements have left the firm
• Sr. PM for the CM has been reassigned to a different division of the firm and moved cross-country
• Project Executive for the mechanical design-assist contractor has moved to a different division inside the company
• Project Engineer for the mechanical design-assist contractor started her maternity leave
• Owner's team and CM have accepted new participants due to project phasing

Sometimes it's hard to keep track of who's in and who's out!

But that leads me to this thought: change is inevitable and how we react to it as a team is important. In my last foray into our collaboration process, seen here, I ended with this parting shot: "Recognizing that a majority of this team is in denial gives me a positive feeling. Hopefully, across the coming weeks, the team can move from denial to anger, to guilt, to sadness and finally acceptance that we have a problem and we need to fix it." This was in reference to our facilitator's analogy between team dynamics of change and the work On Death and Dying by Elisabeth Kubler-Ross and her 5 stages of grief.

The quarterly surveys we take gives some indication that a majority of the team may be in the anger stage and potentially heading to guilt. If you recall, we fill out a blind, 13-question survey on all the firms on the team using a 7-point scale. The purpose is to gauge each firm's responsiveness, honesty and willingness to work together. Its meant to survey our feelings at a point in time that we can compare against previous surveys to glean some insight into the team dynamic.

This month was the fourth time this survey has been filled out. The number of respondents is up to 78% which is not great, but is better than it has been. The average scores still hover in the 4 to 5 point range and the owner continues to have the lowest average score. This quarter, it was 4.05, down from 4.47 in the last quarter.

While I still find the data to be suspect, for many reasons, I have new appreciation for it as we now have four sets to review. Across the board, the scores for each firm went down. There are two reasons for this. First, we have new team members filling out the survey for the first or maybe second time. Many of these new respondents are field personnel who are having a very different experience than the office staff or the design or owner's team members. I think these new respondents also are not afraid to grade their teammates down, whereas some of the design team members have had trepidation in doing so. 

But, the primary reason, I believe, the scores are consistently lower is in the analogy to the 5 stages of grief. I don't  believe this project is progressing the way that anyone feels it should or hoped that it would. We are being barraged with changes, second-guessing decisions and generally not being allowed by our client to do the work we were hired as professionals to do. While the office staff and design team have been involved in this project for several years, the new field staff have not. I think much of that is related to anger at the situation which has manifested itself in lower marks on these surveys. 

I think this may have been a wake up call to the project managers in the room. For me, my personnel has not changed since Day 1 of the project. But these design-assist contractors are bringing their field staff in and maybe need to spend some more time understanding what they are dealing with. The "short answer" portion of the survey was interesting in that it exposed a very serious problem that the CM has to deal with: their general superintendent. 

I have had very little interaction with the superintendent. As I explained in the collaboration meeting, he's come to me with some portions of the design that he wants changed and tried to couch it as a "problem" for the construction team or longevity of the building. This isn't my first rodeo so in every instance I was able to explain why we did it that way and even throw part of it back on him: "if you're concerned about it, set up a meeting and we can discuss it." Of course, the meetings were never scheduled. He knew he couldn't railroad me and he walked away. 

However, the foremen who have to work with the superintendent every day put things in their short answer responses like "dishonesty," "unprofessional" and "back-stabbing." These were not taken lightly by our group and became a large part of the discussion in our collaboration session. The CM was represented by their regional VP and Sr. PM for this project. To their credit, both men said they were aware of the situation and had already taken the necessary steps to address it.

To date, the superintendent is still on the job, he was not terminated or reassigned. I have, however, noticed a change in his demeanor and in his professionalism. Perhaps that is the best change of all - a man was allowed to keep his job if he is able to change how he accomplishes that job. 

Symbiosis

by Marvin Kemp, AIA, CSI, CDT

 

My mother is a retired English teacher, so I strive to use exact language in all I do. I think this is part of what has caused me to be as active in the Construction Specifications Institute (CSI) as I am. Say what you mean and mean what you say is one of many mantras that flows through our organization. When considering a term or thought I hear in my daily business of architecture, I often look it up in the dictionary. Recently, I looked up the definition of “symbiosis.” In Biology, it means “a close, prolonged association between two or more species that may, but does not necessarily, benefit each member." 

 

This definition implies an association not necessarily of mutual selection. The biological definition of symbiosis can closely approximate the common construction delivery method of “design-bid-build” where the Owner picks the Architect and then may pick the Contractor. But, if the construction contract is competitively bid, the Owner may not pick the Contractor by name or reputation but by simply accepting the lowest bidder. Regardless, the Architect rarely picks the Contractor, so there is a “prolonged association” between the two but it “does not necessarily benefit each member.” 

 

A more apt definition of symbiosis for construction might be “a relationship of mutual benefit or dependence.” The success of any construction project relies on all three parties - Owner, Architect, Contractor – working together to reach a mutual goal. If any of these parties is obstructive or less than attentive, the work of the other two is magnified or the resulting project jeopardized. Occasionally, all three parties shirk their responsibilities. I call this the “trifecta:” a project with poor or incomplete documents, a bad or inattentive owner, a self-centered and uncaring contractor. Anyone who has spent a long period of time in our industry has experienced the “trifecta” in some form or another.  

 

In construction, the relationships of all three parties involved in the project are defined in the General Conditions of the Contract. There are three commonly used model construction contracts: the AIA Contracts, EJCDC Contracts and ConsensusDOCS. All three generally define the roles and responsibilities of each party in similar ways, though with slightly different slants, as would benefit the entities responsible for preparing the model contracts. These documents are typically prepared by attorneys and can be used somewhat as boiler plate for many different projects. They are, however, contractual obligations and can be cold and insensitive. The trick is to understand their nature but look beyond their coldness and realize there are people behind each role defined and each responsibility created. 

 

To truly create a symbiotic relationship, it is important to understand what each party brings to the table. One of the biggest benefits I have enjoyed by my membership in CSI is a broader understanding and even an empathy for what each person brings to his or her work and therefore to the project as a whole. 

 

The Owner brings the idea and the need for the project. Without that idea or need, the project would never get off the ground. The Owner also brings the money for the project. Ideas and needs are fine, but without financing, the project goes nowhere. It stands to reason then that the Owner also has the goals or the “big idea” and a desire to see that vision realized. This sounds like some sort of lofty or inspirational rationale, but it could be a financial goal. It’s not up to anyone else to judge the Owner’s goals or desires, but to simply understand them and try to reach them. 

 

The Architect is responsible for delivering the building design to the Owner. The Architect must gain an understanding of the client’s needs and desires and then work to develop a design that is both beautiful and functional to meet these needs and desires. In terms of the construction phase, the Architect has a pre-existing relationship with the Owner. These two entities worked together during the design phase, so they can occasionally have a leg up over the Contractor who comes in only during the construction phase. The Architect’s ultimate desire is to see his or her beautiful design come to fruition in a built form. It is nice to make a few bucks profit when the project is finished, but most architects just want to see their designs built. 

 

The Contractor brings knowledge and expertise in construction scheduling and building. They also bring man-power and material supplier connections. Overall, the Contractor takes a set of construction documents and physically builds them into reality. They want to make a few bucks and maybe a few more bucks if the opportunity arises. Believe it or not, Contractors normally enjoy seeing the design come to fruition almost as much as the architect does. It may not always seem that way, but I believe it to be true.  

 

Its important to understand that these ideas are NOT mutually exclusive. If the Owner has communicated to the Architect adequately, their goal or big vision will be documented appropriately and can be built. If the right amount of money is available, the vision will be realized. If the communication has been clear and the Architect has done their job, cost overruns are minimized. If the Architect has created a beautiful design and then adequately documented it, that design will be built. If they are efficient in their processes, they’ll even make a few bucks along. Conversely, if the Contractor takes care of their business, the schedule is managed, man-power and materials are available and they make money. 

 

My belief is that every project has the opportunity to end as the paragraph above describes: everyone is happy and made some money on the project. It is also my firm belief that this only occurs when a handful of simple ideas are followed. First, expectation must be managed. We are all human, we all make mistakes and we all are entitled to change our minds. I think this is most important for the owner to understand. As architects, we do not pretend to deliver perfect documents that will be built without incident or change order, but I have encountered clients who complain about even a small number of change orders on a project. Our industry's standard of care is 3-5% of the construction cost in errors and omissions change orders. I tell every client that if my change orders total over 2%, I'm more upset and frustrated than they are.  

 

Conversely, architects should offer that same measure of understanding to the contractors. They are humans who employ large numbers of humans to perform physical labor in risky areas in all weather conditions. I recently had a project where the first floor slab concrete finish was of fairly poor quality: light pocking, some skreed marks, some trowel marks, etc. That slab and the second floor slab were to receive a high performance coating, so the slab needed to be smooth to prevent telegraphing and failure of the coating. I did not get upset with the GC or concrete sub, but put together a field report noting my observations and concerns. I reviewed those observations and concerns verbally with the GC before submitting the field report. I was promised better results on the second floor. Sadly, in this example, that did not occur. The second floor was worse than the first! That's when I brought in the owner and coatings representative to assist, but my first move was to work with the contractor to solve the issue.

 

That leads me to the next simple idea: work together. As noted prior and codified in the model general conditions, all three parties are bound together in a symbiotic relationship. Understand that and embrace it! Use the owner-architect-contractor meetings to seek and resolve issues rather than just review work progress and outstanding RFI's and submittals. Become true partners with your owners and contractors in solving problems, eliminating conflict and making sure everyone is working efficiently and effectively. That might mean mentoring of the contractor's staff or educating the owner in certain ways, but I know that your projects will go more smoothly and produce better results in the end.



Collaboration Part 6: Denial is Not a River in Egypt

by Marvin Kemp, AIA, CSI, CDT

As I logged into blogger to do this post, I realized that I'm a couple of posts behind on the collaboration effort I'm engaged in on a large project. I wrote a 2-parter on the opening session (here and here) and a follow up called "We Were Not One and Done" on the 2nd effort. I seem to have not described the 3rd effort or at least not published it and then I missed the 4th (daughter's graduation) and 5th (CSI Convention) sessions. Tuesday was our 6th session and it offered some interesting insight into the work of our team.

The biggest take away from session 4 was the creation of an 11 question survey that the team will fill out quarterly. It contains questions about how the team is doing, who's working well, who is communicating well, the timeliness of team members, that sort of thing. Responses are given on a 7 point scale with 1 being "Not At All," 4 being "Average" and 7 being "To a Great Extent."

There are a couple of good things about the survey and a couple of not so good things about it. The survey is taken anonymously. The responder receives an email with link to a "Survey Monkey" on-line survey. Upon taking the survey, you identify yourself only by the organization you are associated with. That's the bad thing: I work for the associate architect but I'm lumped in with the architect of record. The client, with at least 5 different heads, has a single category but the CM and each design-assist contractor is listed separately. Guess who created the survey?

The survey was first taken prior to the 5th collaboration session. To my mind, the results were inconclusive as nearly every organization's aggregate score was somewhere around 5 on the 7 point scale, meaning all team members are performing "above average." To further the inconclusiveness of the data, only 13 of 25 people responded: 8 from the building team and only 3 from the A/E team and 2 from the Owner's team. Hardly a fair representation of team members.

The second round of the survey was probably less conclusive than the first round. Of 25 people who were invited to take the survey, only 10 did so - that's 40%. One of the design-assist contractors had no one respond, the architects had just one response (me) and the owner had 1 response of 5 invitees. We brainstormed ways to increase accountability and participation and we'll see how that goes on the next go around of the survey.

With the low participation, I can't really see much in the data itself. The high average score belongs to the concrete design-assist contractor at 5.6 and the low score again belongs to the Owner at 4.88. As with the first survey, most scores on individual questions fall in the range of 4 and 5 points on the 7 point scale.

Of concern and discussion in our meeting is the response to the question "Overall, how would you rate this organization's timeliness on matters relevant to the project?" The average score for the team on this item was 4.44 with the Owner receiving 3.55 on the low end and no team member scoring higher than 4.75 except the concrete design-assist contractor who scored 5.22. Throw out that score and the average drops to 4.34. Still "average" but not where the team wants to be. Some discussion was held regarding an owner-mandated software program and attempts were made to seek solutions. Several of us pointed to enhanced communication recently that has improved the inner workings of the team, but that occurred after most had filled out the survey.

The survey also has a "free response" category where participants can write in what is "going well," "not going well" and "can improve." The facilitator pointed to one response under "not going well" for further discussion. The comment was "For a project that has "design-assist" contractors, we are seeing a tremendous number of RFI's. In previous collaboration meetings, we agreed to pick up the telephone - that NEVER happens." This comment was authored by me and was intended to elicit a response from the team, hold everyone accountable and hopefully spur discussion. I succeeded.

When asked, I did own the comment but an interesting thing happened: the entire construction team denied that this situation actually exists. They to-the-man said they frequently call each other, call the engineers and call the CM. I pointed out that no one calls me and I get to process the RFI's. They all then denied that this is a problem because they only want to involve the architect when they deem the architect needs to be involved. I told them that is unacceptable: nearly every situation has architectural ramifications and the architect needs to be involved as I am the only one who has been involved in every meeting on the project from the beginning.

The ironic part of all of this denial came later in the meeting. The facilitator is interested in providing some sort of professional development in each meeting. In this meeting, he spoke on "change management." Not managing change orders on the job site, but in planning for and handling organizational changes that come about in everyone's lives. He drew an analogy between reactions to change and the 5 stages of grief first captured in the seminal work On Death and Dying by Elisabeth Kubler-Ross in 1969. If you're familiar with this work, you'll know that the first stage of grief, and to the facilitator, the first reaction to change is denial.

I filled out the survey a few days before what I would characterize as a "Come to Jesus" phone call between the CM's senior project manager, the architect of record's senior PA and myself. On that call, the CM expressed some concerns that he was hearing from his team and I expressed my frustrations with his team, their response to questions and how they are conducting their business. It was ultimately a productive call that has reaped benefits in the weeks since then.

I told the facilitator after the meeting that I wrote the comment after I gave a presentation at CSI Convention in September on this collaboration process. I came out of that presentation realizing that I could either continue to complain about the team and the process or do something about it. That comment, and another even MORE critical comment, came out of the desire to do something to make the team better. Recognizing that a majority of this team is in denial gives me a positive feeling. Hopefully, across the coming weeks, the team can move from denial to anger, to guilt, to sadness and finally acceptance that we have a problem and we need to fix it.

We Were Not One and Done

By Marvin Kemp, AIA, CSI, CDT

This is the third in a series of blogs that will recount/investigate a collaboration exercise undertaken by a large and diverse project team involved in a large and complicated biomedical research building. I intentionally do not mention the project, client or team members because their names are not germane to the discussion and because I did not ask their permission to use their names. 

As the title implies, we met again for our team collaboration session. This session was held six weeks after the original session and was shorter than the initial full day affair. The group met for just three hours in the afternoon. We had targeted to meet again in two months, but the moderator and the CM’s project manager looked at the project status and the calendar and decided to shorten the duration between meetings. This session was held on November 21, exactly one week before Thanksgiving and three working days before the design development cost estimates were due to the entire team. This appeared to be a critical juncture in the project, so we reconvened. 

Though this session had some of the same players as the initial, it was intended to be just the project manager level folks. We  were asked to grapple with the four problems that were identified by the larger group as being the most critical: 

• User Changes
• Coordination
• Decision Making/Communication
• Design-Assist Procurement/Funding Impact

The idea being that this PM group would discuss the problems, create solutions and measurements and then report to the full group on January 7, 2014. The lead moderator from the original workshop, was back but his assistant moderator was not. We had the senior PM from the construction manager, the main PM from the owner (but not his newly assigned assistant PM), the PM’s from the four design-assist contractors (concrete, glazing, electrical and HVAC/plumbing), the assistant PM from the architect of record and myself, the PM for the associate architect. We also had senior managers, if not PM’s, from the primary engineering firms. This time, we were joined by the Director of Operations from the school that will be the primary tenant of the building. I’m not sure why he was not at the original session, but it was good that he was included for this session because when we tackled “user changes,” he represents the user.

The moderator brought the Ops Director up to speed on what happened in the first session. The group then reviewed the four problems and discussed in what order they should be tackled. I offered that this group is not in a position to solve the "Design-Assist Procurement/Funding Impact" issue because none of us are with the university’s procurement department and none of us are state legislators, so our possible impacts on that issue are minimal if they exist at all. The idea that this university is new to the concept of design-assist and is somewhat distrustful of the process was expressed. After some discussion, we all agreed that the best way to show the university that design-assist works is to perform well as team.

When considering the procurement process as a whole, regardless of our individual role in it, our moderator cautioned us to not escalate emotion. Remember that the moderator is an employee of the CM but is also a psychologist. Several attendees expressed frustration with the procurement process. The design-assist contractors are under contract for “pre-construction” services only and have no contractual guarantee of being awarded the construction contract. The moderator said a real or perceived lack of trust exhibited by the university is not personal and should not be taken personally. All participants must control their frustration and be as calm and level headed as possible when dealing with the team.

With the expressed goal of discussing issues and creating measurements to gauge success, an order of discussion was presented that the group might use to reach that goal:

• Defining the problem should be first. The team must consider the current problem and what the teams aspires for the outcome to that problem to be.
• The team should next analyze how the team is currently performing and what might a Team Oriented Solution (T.O.S.) look like.
• Performance improvement will be considered next or what is the agreed upon solution to the problem.
• Patterned performance must be discussed and used to determine if the Aspirational Goal, as defined by the team, is actually achievable.

Considering these ideas in order might lead the team to the expected solutions to the four problems and how they might be measured to gauge team success. To be fair, the group did not expressly follow that order of discussion in this session. The team very quickly identified problems and analyzed current performance, but fell short in how to improve performance or discussion of aspirational goals.

To better focus the group and because the Ops Director had to leave early for another meeting, the group decided to tackle the problem of User Changes. Unfortunately, the process quickly broke down into a complaining session, which the moderator let continue for too long. Frustration was expressed with changes that cost the entire team in terms of design and engineering time. Some specific examples from this project were given that all agreed were troublesome. The moderator pointed out that if any individual is frustrated, then so are other members of the team. None of us are alone in the project so none of us are alone in our frustrations. It was noted that an aspirational goal could be doing cost reduction exercises without redesign of major systems and components which would cost the entire team more money with design and engineering effort.

It became apparent that the group was grappling with two different types of changes. All realize that minor changes happen at the end of large and complicated projects. This particular facility is intended to be used to recruit new faculty researchers, so once those faculty are on board, minor changes should be expected: electrical outlet moves, additional IT drops, etc.

The PM for the CM noted that the changes the team is currently encountering are semi-normal. Again, this is a very large and incredibly complicated building being built in a dense urban environment in an existing campus context. The myriad of players from the university side each come with their own thoughts, opinions and ideas on the best direction of the project. Change is inevitable in that environment, but the team must not get too frustrated and must deal with these changes as judiciously as possible. Finishing this blog post over four months after this meeting, I'm remembering that many of the frustrations and thoughts expressed came from the construction team, not the design team. While the design team was frustrated as well, I think designers are more used to these types of systemic changes during large projects with sophisticated clients.

It became apparent that the team was making a distinction between project requirements and actual changes. If the team does not meet a project requirement, a comment made during a submission review is generated that may cause a change to the documentation, but that is not a true change. The team merely missed a project requirement. There are some actual owner or user driven changes to the project that may cause the team to go in a completely different direction. Those are the types of changes that are most troublesome to those present.

It was suggested that a few items need to be defined by the team moving forward. The client should be given what they want and need, which is why this team was hired in the first place! This takes on a number of different ideas as there are university standards to meet as well as preferences on individuals who will work in, maintain and use the building. Sometimes these will conflict, but our job as professionals is to help the university work through those conflicting ideas reach the best solution.

While working to make sure the team gives the client what they want, we must all work to minimize costs and impacts to schedule. We are all under contract for a scope of work, schedule duration and fee or guaranteed maximum price. When the university asks for something that we believe the project cannot afford, we need to raise the flag for further discussion of that item. But above all, the team must be fair to all parties. Team members must avoid finger pointing and work together to reach the ultimate goal.

Ways to analyze the performance of the team against the coming changes was discussed, but the team wasn’t really focused on that yet. I suspect that focus will come only when faced with substantial changes, user directed or otherwise. We talked about ways to ensure that each of us works to match the design to the budget. We also discussed the sequencing of the fit-out of floors to maximize efficiency of the construction team and not the whim of the university. That means the construction team should work as efficiently as possible and not let the university dictate what floors are fit-out when, unless absolutely necessary. Some team members have worked on projects where a schedule for fit-out was stymied because the client was considering a particular tenant for a particular space. This team should stay the course for efficiency until that becomes an untenable solution.

Some metrics for issue tracking that are easily measurable were discussed and some durations agreed to. Suffice to say, that those in attendance agreed to quicker turn around times for issuance of change documentation, pricing and review and approval of pricing than is typical. The problem being, several members of the procurement team were absent and so the success of these metrics lies with folks who did not agree to these durations.

Finally, the next meeting was discussed. The idea of convening a smaller team to grapple with the issue of coordination was discussed. This would involve members of the A/E team and the MEP design-assist contractors but no decisions were reached. I think most realized this meeting was more venting than substance and with the holidays approaching, no one was willing to commit to a date. All  had January 7, 2014 as a hold on their calendars so it was decided that would remain as the next meeting. The agenda for that session would revolve around what happens during the DD pricing, reconciliation and value engineering/cost reduction exercises.

The Moderator gave a closing shot: give other teammates the benefit of the doubt. I think that’s something that most teams should do.

Mentoring Opportunity

This blog post comes to us from the School of Architecture and Planning at Morgan State University in Baltimore, MD. Professor Sanjit Roy is seeking professionals to help with his course "The Integrated Intelligent Detail." I've participated in this program in the past and find it to be a great way to meet the next generation of architects and be involved in their education. Please consider taking some time to help this fantastic students.

SCHOOL OF ARCHITECTURE AND PLANNING
MORGAN STATE UNIVERSITY
February 20, 2014

Whether you are a veteran mentor for "Architecture at Morgan", or brand new, I hope you will consider this opportunity to work with our graduate students of architecture.

Architecture at Morgan offers an innovative graduate-level course developed with the support of an NCARB grant known as: "ARCH.541: "The Integrated Intelligent Detail."

Would you be interested in mentoring a student in this course? The course runs from January to May, and the course requires students to investigate architectural detailing by working with a practicing architect as a mentor. The mentor contact with students involves three campus visits, and one or two meetings at your office.

This year the focus will be on the exterior envelope, including at least one fenestration detail. The participating mentor selects a project from their office with an interesting detail (built or proposed). The detail should present some challenges for alternative study by the student. Your student will create a BIM model of the detail, and then transform the detail using their research, design and BIM skills.

If you are able to serve a mentor you will work with 1-2 students guiding them as they develop a wall section/ detail for one of your current projects. You will be presenting the project t the students on either 25 Feb or 4 march, whichever date is convenient for you. Subsequently the students will meet with you at your office as they develop the details under your supervision.

The four on-campus dates that involve the mentors are:

1. Introduction of your architectural project to the class: on one of the following dates:

     a. Tuesday, February 25: 7:00 pm to 8:00 pm (one hour) OR

     b. Tuesday, March 4: 7:00 pm to 8:00 pm (one hour)

2. Tuesday, April 1: individual desk critique between 6:00 pm to 8:00 pm with your student mentee/s (allow about one hour)

3. Tuesday, April 22: individual desk critique between 6:00 pm to 8:00 pm with your student mentee/s (allow about one hour)

4. Tuesday, May 13: 6:30 pm to 8:30 pm FINAL REVIEW OF ALL STUDENT WORK (two hours) hosted at an Architecture office.

Thank you,

Sanjit Roy
Assistant Professor
School of Architecture & Planning
sanjit.roy@morgan.edu
443-228-8777

Ralph Liebing, RA, CSI, CDT

It is with great sadness that we announce the passing of Ralph Liebing, RA, CSI, CDT, an occasional contributor to this blog. Ralph's weekly per-SPEC-tives email newsletter was welcomed reading in my inbox each Wednesday morning.

Ralph died on February 9, 2014, leaving behind a wife, a daughter, a son and a granddaughter.

Tom Hellmann, AIA, Senior Vice President and Director of Architecture and Interior Design at Hixson Architecture, Engineering and Interiors said, "He was a great associate and even better man." Hear, hear. Ralph's intelligence, humor and home-spun wisdom will be missed by all who knew him. There is a giant hole in construction knowledge left by his passing.

Here is a link to his obituary and final arrangements. http://www.boltonandlunsford.com/obituaries

Submittals and The Client

by Ralph Liebing, RA, CSI, CDT
 
This post was borrowed from Ralph's weekly per-SPEC-tives email column. If you don't get this weekly writing on all things CSI and specifications, contact Ralph. I'm sure he'll be happy to add you to the distribution!
 

The title seems to indicate a rather strange and innocuous discussion. How many clients really care about submittals on their construction projects? Some will be quite interested; others will take little if any interest.

Many clients still see the submittal as the verification of what they will receive on their project—a “checks and balances” ensuring the true value received for dollar spent. Some see the submittal as the record of what is placed, for future reference, maintenance and replacement or trouble shooting. This of course, really is part and parcel of the Operating and Maintenance Manuals required on most projects.

Well, a big part of the answer may lie in the adverse impact of submittals when they disrupt the project schedule, and completion of the project. Yet there are other considerations. Some people has professed that submittals are useless, needless and obsolete. Is that true? Or is there a valid and proper place for submittals—properly requested, produced, processed, and utilized?

There is need to address several issues with the Owner, so there is full understanding of all circumstances surrounding submittals;

- Submittals will be requested ONLY to ensure that the Contractor[s] understand the requirements of the contract;

- Only a minimum number of submittals will be required;

- Requests will only be required for those submittals containing crucial information;

- The Contractor is responsible for the “means and methods of construction”  and is therefore the primary reviewer of submittals and their  compliance with the contract documents; erroneous, incomplete, and non-compliant submittals are to be returned to the preparer by the CONTRACTOR [all in accord with AIA A201, General Conditions of the Construction Contract];

- The Contractor is to review all submittals, check for errors, and stamp them with an approval stamp, PRIOR to submitting them to the design professionals [complies with A201];

- The design professionals ARE NOT responsible for an extensive review, not  for any information other than pointing out errors-- NOT correcting them [in accord with A201];

- Reviewed submittals will be returned in a prompt manner;

- Submittals sent to the design professionals without proper Contractor review and approval, will be DISCARDED/Returned with no further action [complies with A201];

- Any schedule disruption[s] attributable to faulty processing of submittals accrue to the Contractor [NOT the design professionals].

A conversation, with the client, on this topic is most important--and strongly urged and advised. It lays the groundwork for the procedures to be followed on the project that will ensure compliance with the project requirements and will give the full value of the work to the client. That context and conversation falls within the purview of the design professionals.

The Contractor may well have a very different “take” on submittals and the whole of the process. AIA Document A201, however, makes the submittals program and process quite clear and directed. It delineates the responsibilities of the various parties, and denotes a very specific progression of preparation, processing, review and approval—by several parties and with certain specific guidelines.

It is most important that the client be aware of these provisions so the work of the process will not be a surprise or an irritant to the client. Being made fully aware of the reason for, the background of, and the inner-working of the process is important, not so much in the minute details, as in the overall value and correct operation.

The submittals program is in place for good reason, and is time tested in the results it produces. Obviously, it is wrong to obviate or ignore this program for any reason or changed condition in a project. Of course, the client does have the right to pursue the project as seen fit-- hopefully this determination does not involve elimination of this clearly directed and helpful process.

Its value directly contributes not only to project success, but to value given to the client!