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.
