Building a Highly Collaborative Team

I've been learning about "lean construction" since around 2006. I sat in a presentation at the CSI convention given by Greg Howell, co-founder of the Lean Construction Institute. I was intrigued by the idea of building a collaborative team of design and construction professionals working together to create a building of higher value and higher quality, rather than one that is built faster and at the lowest cost. I quickly recognized that it would be some time before I could work in such an environment. At the time, the lean construction trend seemed to be isolated to the West Coast of the United States and I practice architecture on the East Coast. Moreover, most of the work I do is with public universities and the procurement laws of many states in our region preclude the creation of such a team during the design phases. Procurement laws, and the risk tolerance of most of our clients, trend toward traditional design-bid-build or some form of construction manager at risk delivery methods.

 

Fast forward six years and I found myself involved in a project that is trying to create a team with some of the tenants of lean construction. Our firm is part of a team working on a very large biomedical research building that is utilizing the design-assist delivery method for some of the major trades. For those who may be unfamiliar with design-assist, the idea is that trade contractors are brought to the project early in design to the assist the designers in various aspects of the design, including material and equipment selections and coordination among trades. The assistance continues through  the documentation phases and construction phase so they run more smoothly to deliver a building of higher quality and at lower costs. The theory behind the design-assist method is very sound and seeks to build a collaborative team that works together to provide the client with the best possible project given the funds available.

 

Theory and practice can differ widely. We are about 24 months into a nearly five year project and the practice of design-assist has not lived up to its promise at the onset of the project. I’ve been chronicling some of the project on the Baltimore CSI Chapter’s blog, Felt Tips. As I prepared several postings about various aspects of the project, I realized that a longer and more interaction presentation could be made which might be beneficial to all in our industry. I was focusing the blog postings on the “collaboration sessions” that the construction manager organizes quarterly but that was only a small part of the work that the team was undertaking. I began to realize that things were being said “in the room” during those sessions that weren’t being translated to outside of the room in our day to day interactions on the project.

 

I submitted an abstract to CONSTRUCT for a presentation titled “Building a Highly Collaborative Team.” My abstract was selected and I will be presenting this presentation as Session T14 on Tuesday September 9, 2014 at 1:30 PM. The title is taken directly from the title of the collaboration sessions on this project. When I initially submitted the abstract, I intentionally picked that name because I thought that is what our team was doing: building ourselves into a highly collaborative team. As time has gone on, the title is becoming tongue in cheek because we are not, in fact, a highly collaborative team because of the behaviors some of our members are undertaking. I hope you find the abstract and this blog enticing enough to cause you to attend my session!

 

While preparing for the presentation, I thought about the team and its members and began to realize that the behaviors we are undertaking are not always intentionally done so and if I can point them out to a larger audience, we could greatly benefit as an industry. To start, let's talk more about the project. I’ve given some clues above about it but I do not want to give too much information because our collaboration sessions have been confidential and I do not want to mention the client, project or team members by name. The project is a large, biomedical research facility at a public university. It is in excess of 400,000 GSF in size and has a construction budget in excess of $200M. There are currently three schools within the university involved in the design along with other stakeholders as you would expect: university project management groups, various review architects and engineers as well as operations and maintenance personnel. The A/E team is made up of three architecture firms, a laboratory planning firm, five engineering firms, and seven more specialty consulting firms. The construction manager now has a team of seven people working full time along with four design-assist contractors and is now procuring many other parts of the work, bringing in about a dozen other trade contractors, with more coming on in the coming months. Management of this team is a massive undertaking.

 

Idealistically, each of these parties brings something different to the table. The owners want the largest building possible with no additional financial outlay and a facilty that requires zero maintenance. The designers want to build the most beautiful building possible to assist with their own marketing efforts. The builders want to build the building as quickly as possible with no quality requirements and an unlimited checkbook for any changes they want to make. Obviously, I’m joking a bit about each of these statements, but with so many differing parties, building a collaborative team is of critical importance. Through the team building process of the last 18 months, I’ve learned two things that I will expand upon here.

 

Top Down Collaboration Does Not Work. With a team this large and diverse, these collaboration sessions could only accommodate the “project manager” level position in each firm. Even then, there were typically 20 to 25 people in each session. Each project manager then has three to five, if not more, people working with them to produce the work of their firm. From the owner's side, there were typically four to five individuals at the project manager and director level in attendance. In the initial session, one project executive said that this collaboration model must rely on “top down collaboration” meaning each person who attends the sessions is responsible for ensuring that those working with them understand the principles set forth so that the collaboration works. What I’ve found is very different. In some instances, those managers in attendance are not interested in being collaborative, so the top down model doesn’t work as there is no trickle down. But in other cases, the culture of the firm does not allow for true collaboration, so the workers outside of the sessions are unable to truly collaborate. In either situation, the “top down” theory falls apart.

 

When Faced with Adversity, Teams Either Come Together or Fall Apart. This is sort of an obvious notion, but is actually very complicated. I can illustrate this in one example: the possibly unforeseen condition. I use the word “possibly” because there can be disagreement among the team members as to whether or not the condition is truly unforeseen. When a situation arises and the team chooses to come together, several things can occur. A meeting can be held with all relevant players where the situation is reviewed and brainstorming occurs for potential solutions. No one points fingers or worries about getting paid for their efforts. First and foremost, the situation must be resolved so the project can move forward. At the end of brainstorming, a direction is decided through the consensus and the players act accordingly. This coming together can occur whether or not there is agreement on the condition being foreseen or unforeseen.

 

The above scenario happened and I left the meeting happy with the outcomes. The team agreed on the outcome which was shouldered by two firms and the work quickly began as discussed. However, shortly after that meeting, as the schedule delays and costs became more apparent, players came together not collectively but by ones and twos and the team began to fall apart. Site visits were held with only certain players present to review the conditions. Two of the contractors active on site began to worry about schedule and cost and so the CM began to work outside of the framework of the project team to mitigate those concerns. The owner was contacted independent of the design team and then the design team was expected to react based on innuendo and rumor, not hard facts. Time slipped away based on lack of communication and clarity.

 

As I post this blog, the situation above has not reached its conclusion. To date, there is at least a three week delay in the project. I became aware of the situation about one month ago. Activity on resolving the situation did not reach a fever pitch until a meeting was held 16 days later. Yes, 16 days later on a situation that was holding up the progress of a $220M project! There are a number of reasons for this delay, many of which I’ll cover in more detail in my presentation, Session T14 on Tuesday September 9, 2014 at 1:30 PM. There are also many more real world situations that have come out of this project and others I've worked on. I hope to see you all at my session and at CONSTRUCT 2014 in beautiful downtown Baltimore! There are many, many learning opportunities on topics that are intimately relevant to your work every day. Come see us!