Google Translate

September 2012

September 27, 2012

In various discussions about integrated project delivery (IPD) here in the US I'm often asked "what sort of projects are best suited for IPD?" I consider these queries to be a derivative of a similar question of maybe eight years ago, to wit "what sort of projects are suitable for BIM?" And I guess the correlation isn't unexpected since IPD as a concept emerged from the process implications and potential of BIM, and in early days (say the mid 2000s) the two ideas were often co-mingled and even confused.

But now that the technological process (BIM) has been conceptually parsed from the delivery process (IPD) have the answers to these questions changed? In the case of BIM itself, I believe that we're way past the "what sort of projects suit" because the technology has matured, adoption widened, and I see projects from house additions to campus complexes being modeled successfully. The project type question for IPD, however, is a little more nuanced because of a very important factor--and it's not project type--the client.

A fundamental precept of IPD (or any "integrated delivery" approach) is deep collaboration between the designers, the builders *and* the owner. In the case of clients where success is deeply dependent on such collaboration, such as complex programmatic projects like hospitals, institutional buildings, research labs, or concert halls, an IPD approach is consistent with good design and construction practice. The more the client is connected to every important decision the happier he or she is likely to be, and the more informed the architects, engineers and contractors who carry out that vision.

But what about developers, those commercial clients who might comprise (according to the latest AIA survey) as much as 28% of all projects (including hotel, retail, commercial and multi-family housing)? In theory, no problem: IPD is based on collaborative decision-making (check), outcome-based compensation (well, maybe), advanced use of BIM technology for transparent decision-making (umm, perhaps not so much) and reduction of risk through cross-indemnification of the parties so they can work in the best interest of the project (uh oh). Let's look quickly at each issue.

A "strong" IPD project is based on consensus-based decision-making, meaning that the primary players (designer, builder and client at minimum with others included as needed) must agree on every decision that any deems important, and only those decisions can move forward. This suggests that the more normative "propose/dispose" model that we use traditionally with clients (do you like this scheme? do you like this space? do you like this price?) gives way to total agreement or no agreement. This means more detailed involvement in the project as it unfolds, bigger time commitments by the client to be deeply ingrained into the project process, and perhaps most importantly, jointly responsible for each of these decisions. That closeness also closes off subsequent opportunities to hold other parties exclusively responsible for those decisions. Many developers may not endorse the loss of such an enforcement mechanism. For more on this issue, see “everyone “promises not to sue” below.

Strong IPD also means compensating the project team for accomplishing objectives that are defined at the outset and are in the interest of the project, and paying those profits jointly to the members of the project team. Less paperwork and invoicing (a good thing for the client) but more importantly, perfect alignment of interests of all the parties and the project itself, so, as John Tocci says "Everyone works for the project." And since many development projects are driven by well-established outcomes (meeting budget and schedules, or sustainability goals) this one seems like it would work well. And perhaps there's an even more interesting oppotunity to get to even better alignment--if one such coutcome was the financial performance of the project in rental rates or rent/square foot, there would be even stronger incentive for quality work amongst the players, and a continued relationship beyond substantial completion that's more interesting than just the statute of limitations on a potential lawsuit.

Right now, I suspect the average developer client is disinterested in the use of BIM on projects, inasmuch as they don't dictate any of the tools that their teams might deploy to finish a project. It's all about the schedule and the budget in most cases. But as BIM empowers dynamic analysis of projects in ways that can allow developers to see, almost in real time, the cost, energy, occupant flow (and resulting revenue) of jobs as they unfold, perhaps interest will increase. And those that operate their buildings after completion will surely engage in BIM-based facilities management as those solutions mature.

But speaking of which...many IPD projects attempt to create a "safe zone" for everyone's participation and ideas by providing cross-indemnification (legalese for "everyone promises not to sue everyone else") in the agreement. The thinking here is that everyone, including the owner, is therefore free to take responsibility in the joint decision-making model--and include their best ideas irrespective of role--if they are not spending all their time making sure they don't get sued. John also says that he can spend as much as 30% of his time on a typical CM-at-Risk project (many of which he does for developers) in "exculpatory" activity that only makes sure that he has documented or challenged everything that might create potential liability for his firm. That's money that the owner pays, but sees no value from whatsoever. The question, of course, is whether a developer is willing to relinquish this particular Sword of Damocles held over the team in case the project goes truly south. It is likely only the most progressive who will be willing to experiment with such an approach to recapture the resulting value. Of course, architects, statistically, probably benefit most from such provisions, since the vast majority of their claims come from clients and contractors.

[Sidebar: in many large development projects like the ones that I worked on when I was practicing, even our sizable $5 million insurance policy wouldn't make a serious dent in any real problem that unfolded on the job. The threat of litigation was as much an enforcement technique as a source of funds to resolve problems, and in any event getting access to those funds takes many years after a problem is identified by the time such matters are resolved. Not a very efficient system.]

Most if not all of today's IPD projects are being undertaken by recidivist clients--owners who build repeatedly and are looking for solutions to the repeated crises of construction. Developers surely fall into this category. But most of those projects are being constructed by long-time owners of their buildings, institutions like hospitals or universities. Many development projects are "turn-key" in that they are sold quickly after leasing and completion, although the tide may be turning on this concept in our current time of tough credit and longer leases. I suspect--without benefit of any evidence, of course--that there are some progressive developers out there, who are perhaps building green projects with long-term operational obligations, who might be willing to experiment with IPD. They'll be in the vanguard, and would certainly accelerate the trend toward less contentious, siloed delivery that might be more profitable, less risky, and more fun.

September 05, 2012

After my summer blog hiatus I return to the page as my next fleet of students arrive to begin their last year of graduate school. Thanks to the peculiarities of our academic calendar, my class will be both the first and final experiences of the term and the last collective experience they have as a class before Commencement. It’s a funny place for a professional practice course to occupy in the studio-centric world that is architectural education.

Those of you who are architects probably don’t remember Pro Practice as a high point of your schooling. Often taught by an “adjunct” faculty member (who works outside his or her teaching responsibilities and isn’t tenured, like yours truly) these courses are considered necessary medicine to get through the academic spanking machine that is an accredited, licensure-ready degree. War stories, dry recitations of AIA documents, balance sheets…as one of my students once asked (about another issue) “where’s the serendipity?” I have been preparing for the term with much the same question.

Our school will be evaluated this year by the Gods of Accreditation (the National Architectural Accreditation Board, or NAAB) and we’re busy making sure we’ve properly covered all the necessaries of the so-called Conditions, an exhaustive list of all the stuff we’re supposed to teach budding architects. The Conditions for my neighborhood of the curriculum (Practice) stipulate the following:

Architects need to manage, advocate, and act legally, ethically and critically for the good of the client, society and the public. This includes collaboration, business, and leadership skills. Student learning aspirations include:

- Knowing societal and professional responsibilities

- Comprehending the business of building

- Collaborating and negotiating with clients and consultants in the design process

So there are three big ideas here: a properly educated graduate must understand how the professional works with and affects society; understand the amorphous ecosystem of building and how we fit into it, and understand the business machinery that the architect deploys to get work done. A daunting task to be sure, and not just because we have to find a way to cram all this stuff into a curriculum already choc-a-block with theory, engineering, sustainability, computation, digital fabrication, and of course design studio. And notice the word “collaboration” is cleverly inserted into the equation as well.

Here’s how my syllabus purports to accomplish this daunting task, according to the course introduction:

The process by which an architectural design becomes a building requires the designer to control many variables beyond those purely aesthetic. While the practice of architecture was formally established in the United States in the late nineteenth century, the role and responsibilities of architects in the twenty-first century are rapidly evolving under the influence of broad building industry changes in sustainability, digital technology and integrated project delivery. Understanding architectural practice as the mechanism that realizes design--and project management as the leadership and control of the means that make projects happen--is as central to the successful design of a building as its form and character. Effective practitioners master both design and practice issues to assure their designs reach fruition in the varied contexts of profession, practice and the individual project.

But here’s the problem (or at least one of them). At the risk of a strained comparison, there are certain similarities in the production of buildings, the creation of software and the education of architects, the three realms that occupy my professional life. Each involves speculation about a future state, an assertion about how to prepare for that state, and a hope that all the intervening preparation will reach proper fruition many years later. From initial desire to certificate of occupancy, a choice to translate a work process into digital code that is a production-strength piece of software, or from freshman year to licensure—all of these sequences take many years. I worked on more than one project in my practice career that took more than a decade to complete. Autodesk made the Revit acquisition in 2002 and only now is BIM reaching the mainstream. NCARB just published a study that suggested that more that 50% of architects reach first licensure at age 32 (!), fourteen years after your average freshman starts out. And the average number of years between graduation and licensure is creeping up accordingly; folks who got licenses in 2010 took seven years after graduation to get there. These are long timelines that we’re talking about here.

So those of my students in the Class of 2013 who choose this route (which we assume is why they have invested so much blood and treasure in an architecture degree) can expect to have a license and truly “manage, advocate, and act legally, ethically and critically” sometime around 2020. And I guess that means I know exactly what they will be facing, and how they might best be prepared to do so. I wish…

But I do find myself wondering if the centroid of architectural education needs re-centering a bit, even if we can’t predict with perfect fidelity what the world of practice might look seven or so years from now when my students get licensed and are certified as “minimally competent” practitioners. Surely the essential skills of design (which they spend the majority of their calories honing) will be a basic platform for their careers, but what about the other stuff? Maybe there’s no time in architecture school to teach business skills, negotiation strategies, proper presentation techniques, clear writing, or even the basics of how to collaborate or lead teams. But I would note that across our campus at the School of Business, our future clients-in-training spend 50% of their two-year MBA curriculum (a year shorter than our program) learning these same skills. Is there any doubt why these relationships are so asymettrical? Perhaps the design studio becomes a fulcrum from which some of these ideas might emanate, rather than having them increasingly “shoe-horned” into the curricular suburbs of professional practice.

In a New York Times piece this weekend, Michael Graves argues that the demise of hand drawing, inflicted upon thecurrent generation by slavish devotion to the computer, is a root cause of the deterioration of our profession. As you might expect, I disagree with his logic, not about means but rather ends. Like the collection of necessary skills demanded by the Conditions, drawing is another instrument, just like the computer. But unlike the pencil, technology is changing both the means of representation in architecture and the relationship of the architect to the very process of building. I suspect that it is neither pencil nor BIM missing from the equation, but rather the ability to deploy both in the complex, collaborative, negotiated, measured and value-driven future of design and construction. Somehow, we have to teach that.