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!