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!