For the 2019/2020 Thornton Tomasetti annual report, we convened a group of specialists in January 2020 to discuss the challenges of ingenuity in AEC — whether it’s in short supply, how it works, and how to cultivate it. While the discussion predated the novel coronavirus outbreak, some of the themes bear relevance as we all look for ingenious ways to manage and accelerate our industry’s recovery. Here is an unabridged version of their discussion.
PHIL If we define ingenuity as the creative application of innovation, does the AEC industry have an ingenuity shortage?
DOMINIQUE In AEC we underinvest in technology and innovation, spending about half as much on technology as other industries. This leads to a lack of ingenuity. Our designs are innovative, but our processes or delivery are less so.
MARYANNE The development industry aids and abets this lack of ingenuity. Developers operate within a rigid framework that is defined by capital constraints, the political environment, process constraints and risk profile. We are therefore loath to innovate, mainly because the risk is so great. We're not an industry looking to do things differently. We may think we are, but we are probably one of the last frontiers where a disruption needs to take place in everything, from the process of designing to building a building. Developers don't have R&D lines in their budgets, and I think it's a missed opportunity. When we started with sustainability, it was a running joke that the most sustainable building in New York was one in Times Square because it had a recycling depository near the freight elevators. Sustainability only became such a big part of our business because people wanted to live in healthy buildings, and consumers were demanding it, so we changed because we had no choice. There are many of us who know that change is afoot and know that to maintain a healthy world-class city, we as the community that builds and creates the built environment need to innovate. In New York, it's generational. This is a dynasty business in this town. I'm excited to be in the business today because there's a lot of room for improvement, and I think a lot of innovation is going to come from outside the industry, and from the technical disciplines. When we can sit with the folks who execute our vision, they show us things that are mind-blowing. We have to sign on and be prepared to fund it.
PHIL What are the hurdles to innovation?
MARYANNE It’s about the money. When we wanted to do a modular building in Brooklyn, an idea we were passionate about, I needed to sell the idea to capital partners and lenders. An idea like modular construction – innovative for Brooklyn! – can be generated by the development community, but to make it a reality, there are a lot of other people you need to persuade.
PHIL That's true across the supply chain. Developers need bankers. Architects needs an insurance company. Contractors need a bonding agent. It’s high coefficient for all of us. Is that a main constraint, or is it our thin margins, or something else?
MARYANNE Developers can still make money without innovating, so there is no imperative. When the market demands innovation – like the surging interest in sustainability – we'll make the change because it's for survival, but we tend to follow rather than lead. A developer can still eke out some success with a series of forgettable buildings that are not contributing to the community and the built environment in any ingenious way.
RAY In construction, the drastic demand fluctuation at the local and regional levels makes it difficult for contractors to invest in anything, especially R&D. And fixed-price contracts that force them to bid competitively, don't allow them to new things. Combine that with the fact that we have 50 times as many lawyers per capita as Japan does.
PHIL Is there a locus of innovation? What's the source?
RAY Real innovation is coming from the people who employ all the labor and all the equipment – the specialty trade contractors, like plumbing and electrical. But they can innovate only within their own lane. And if there is an innovation that requires the next lane to make a change – if the mechanical people want to do something that requires a different structure, or different plumbing, or a different something else – then everyone needs to agree to evolve. You also need some repetition so you can learn how to do it. A big problem is not having the same team members from one project to the next, because we often select people by competitive bid.
There are several companies doing what I'd call an Industry 4.0 modularization. One is a company in Montreal, BONE Structure, which has a steel pressed sheet metal frame that other people make for them. They design the modules, and they design the software that allows architects to work around their modules, so there's quite a bit of flexibility. They recently started a California subsidiary.
Project Frog is a small company that has created a kit-of-parts software that allows architects to design around their modular frameworks. They do schools and medical office buildings.
Katerra is the opposite of Industry 4.0. It's totally vertically integrated. In a huge downturn, what happens to all that invested capital and their loans? If you bring the ideas of semiconductor or aircraft manufacturing to this industry, you also need to understand political constraints and labor-union constraints.
Other than these examples, there is a slow diffusion of automation across the industry, which is starting to pay dividends. You pay subcontractors net 30 days, and you can take 5 percent out of the cost of building right there, and so you've got to automate the lien releases. You've got to automate the bank's construction-loan payment processes. All those things are starting to happen. Technology has paved the path, and now people are finding more creative ways to drive on it. I bet that if somebody studied labor productivity in the industry right now, the curves would be starting to bend up.
PHIL Twelve years ago Chuck Eastman1 published a paper that said off-site productivity was rising rapidly, but on-site productivity was diminishing and wiping out the gains of off-site productivity. The argument is that buildings are becoming more complex and more heavily regulated. It takes longer to do procurement. It only gets harder to build a building. Who is doing it right?
RAY The Googles, Facebooks and Apples care about their carbon footprints, and they're focused on offices that are healthy for their workers. They're competing for talent and have to build premium workplaces. Google, for example, is interested in trying alternative cements that are low in embedded carbon, as well as new window walls and different air-conditioning systems.
MARYANNE Companies like that will drive innovation, as huge consumers of space. They'll drive the development community to a certain place, because they're willing to pay for it.
PHIL Despite their interest in creating an optimal workplace and being leaders in carbon footprint reduction, the Googles, Apples and Facebooks of the world don’t show as much interest in process innovation. Some of those iconic facilities they've been building were delivered as a straight construction-management at-risk jobs. It's all lowest-cost procurement, with zero innovation on the process side.
DOMINIQUE It's hard to drive innovation when you don't have everybody lined up behind a clearly defined outcome. When everybody agrees on what success looks like – in terms of building performance, operational cost, quality of the space, financial outcomes, etc. – then it's easier for people to innovate toward those goals. Integrated project delivery (IPD) allows everybody to align their goals and derisk innovation. The people for whom this is valuable are owner-occupiers, who aren't going to flip their buildings. That’s why Google cares about life-cycle costs.
MARYANNE The Sidewalk Toronto project – a development of the eastern waterfront, backed by Google’s Alphabet – is a case in point. Sidewalk Labs has a clear mandate that the project be profitable. The press has covered it as the Google Canada HQ move, but it’s more than that. It's about the future of the built environment, and whether you need zoning if you have technology. If you have buildings where you could have a nightclub next to a church, and through technology, the sound is regulated, then you’re innovating. The movement of people, places and things on that street would be conducive to both of those uses, so you wouldn’t need a zoning regulation because your buildings would self-monitor. These are really interesting ideas, and I applaud what they're doing. It underscores the importance of the government in creating an environment friendly to innovation.
PHIL Do the tech companies have the required attention span for real process innovation in building? From my 20 years in tech, I found the attention span there extremely short.
DOMINIQUE It is a real issue. In the tech business, the product life cycle is six to 18 months. But if you’re designing a building and trying to understand whether the results panned out, then you need a four-year horizon. I’m not sure the tech sector has that patience.
RAY This is where the government can play an effective role. The General Services Administration required building-information models. Originally the building-information models weren't worth anything, but they were at least getting people to start doing it, although they were used originally mostly for marketing – these beautiful 3D walk-throughs to wow clients. Then they became useful – the old stack of blueprints is now the BIM – and the government had a major role in enabling that. Even small architectural studios that wanted to do government projects had to do BIM.
PHIL Ray, you mentioned the productivity curve. Whether or not it’s bending up, we still lag behind many industries. Would focusing on productivity be an organizing principle to get us to begin innovating? Would it interest you, MaryAnne, if you could build your buildings for 35 percent less?
MARYANNE I went down that rabbit hole at 461 Dean Street in Brooklyn, part of the Pacific Park megaproject. We knew we had scale, so it was time for us to figure out the most efficient way to put a building together. Chasing 15 to 20 percent in cost savings came down to modular construction. We put 65 percent of the process in a factory a mile and a half from the site, where every floor was built on the ground, and it was safe and protected from weather. We found ourselves in an R&D mode as a public real-estate company, which was difficult. We ended up putting $10 million into this idea. We also wanted to prove that we weren't sacrificing the built form either. So we asked the architect, SHoP, to design both a conventional and a modular building so we could see the differences between those two structures. When we talked to people about the why of it, it became clear that we could build a modular building that could be constructable and meet New York City building code. But could we save money and get it through the building trades? If we could say that the first of 20 buildings works, that would prove the concept. It might not save big, but we could do a better job of convincing others to stand behind us.
Everyone said the unions would kill the deal, that they would never agree to assemble a building in a completely different way because those inefficiencies, people argued, are the fundamental underpinnings of the construction business.
So we went to the head of the Building and Construction Trades Council of Greater New York and said the Building Department believes this can be done. We've designed the building. We think if we can remove all these inefficiencies in the process, the building will stand up and feel just like a conventionally built residential building. After 18 months of negotiation with the trades, we got an agreement. To [Council President] Gary LaBarbera's credit, he recognized that change was afoot and that the building trades needed to innovate or they would be left out in the cold. Our pitch to him was: "You can be part of what goes on in the factory and be part of what goes on on-site. But what you pay a worker in the factory has to be completely different than what you pay a worker on-site." The hourly factory rate is almost 40 percent less than the on-site rate. The number of buildings built in the city by the unions was half what it was five years ago, so there was a reason for them to come to the table. But it took 18 months of convincing construction trades that taking $35 at a factory would build a new kind of worker, a new kind of wage rate, a place for the future generation of construction trades to go in the unions where they could earn a year-round, predictable wage safely. In addition, it could attract women from single-parent households. "Easier to go to the same place every day" versus "this job is in Staten Island, then another in Queens," and so on. Think about what it means for the composition of the workforce.
We wound up with a partner who didn’t understand how to build prefab. It was a really good idea with a poor partner pairing and a mountain of litigation. In the end, we finished the building, which is still the tallest modular building in the world, with half of it affordable, and half driving some of the highest residential rents in Brooklyn. Many people think, "This is a really funky building in Brooklyn that was built differently. It's cool. I want to live here." It was highly successful financially, even though our process faced many hurdles. I’m still a huge believer. It was one step in the right direction.
RAY We don’t have an ingenuity problem. We have a distribution of ingenuity problem. Modular is not new. The Germans did this with concrete in the 1940s. Skanska does it quite well in Chicago and, of course, in Sweden. Modulous, in the U.K., actually doesn't make anything. They outsource all the manufacturing; they just manage the supply chain.
PHIL There are lots of good ideas out there. Autodesk did the first pure IPD project in the U.S. 11 years ago. Yet there are probably less than 1,000 IPD jobs in the U,S. right now. What inhibits diffusion of innovation?
We don’t have an ingenuity problem. We have a distribution of ingenuity problem.
MARYANNE At the risk of sounding like a socialist, I think that the government has a big part in contending with these problems. Some of the most productive times in government are during downturns, when the private sector is on the sidelines or there’s a lack of capital. Leadership and boldness in governing, and coming up with programs and policies, can smooth out the cycles; the government becomes a consumer when other consumers might fall away.
PHIL In the U.S., the government makes almost no R&D investment in construction. In the U.K., construction is treated as a national economic asset. They have a strategy, government leadership, make investments and set standards.
RAY Still, the U.S. market is changing, however slowly. Bureau of Labor Statistics data shows that for the last 50 years, about 3 percent more work per year has moved off-site. It's not modules; its prewired lighting coming in, and a prehung doors coming in, or a curtain wall, so you're not putting windows into frames and caulking them on-site. That is happening within each of the trades. What’s happening now is more substantial off-site fabrication. In addition, architects' drawings have had less and less detail over the years, so that subcontractors do the shop drawings. No one does working drawings for mechanical systems anymore, for example.
DOMINIQUE Yet the architectural drawing sets are getting thicker. Maybe the mechanical sets aren't, but certainly the architectural ones are.
PHIL This raises a bigger process question. Does our linear way of working – concept, design, procurement, construction, closeout and litigation (no kidding!) – make sense anymore?
DOMINIQUE That’s interesting to think about in terms of the bidding phase. How do you carve out bidding as a phase? We're pricing things continually, every step of the way, looking for potential value engineering based on that constant cost information. There is a continuing, iterative push-pull between design and pricing. If we try to design and then price, we want to do it early enough that we’re on the right track and avoid big surprises later. It means we have to be more agile, running in loops rather than in a straight line.
MARYANNE As a client, I need that process for a couple of reasons. One, what we think we want in schematics really needs to evolve. You sometimes can't get to certain finish details if you don't know what the guts of the building are. Two, the pricing at certain milestones is important to me. I want to know where I am so I don't get a surprise at 50 percent design development or at construction documents. And third, I can't get the money unless I have 80 percent CDs. I need some point where the music stops and I say to my bank, "This is how much it's going to cost." And I say to my contractor, "We're doing a GMP right now, and you're going to lock these down." I would be open to another process, but to me, that process is like my insurance policy, to make sure that I don't have a pool on the roof and a garage in the basement that I can't afford.
PHIL The software industry has migrated from linear, waterfall development to agile development — a series of short sprints. You don’t try to know exactly where you're going, and you’re not sure how you're going to get there. Should we be experimenting with this? Or is “agile” the same as just iterating a design every two weeks?
DOMINIQUE It sounds the same. I think if you're meeting with clients regularly you get that feedback. The part that's new is that we're not just looking at building form, but trying to have the structural engineer at the table from the outset. And we’re considering the carbon impact analysis. We're running a fast, iterative life-cycle analysis on a DD-level drawing. So we're bringing in more knowledge to the process and trying to iterate faster. The technology to do this was just not available even three years ago.
RAY I did a detailed case study of Salesforce.com, which went from waterfall to something called Shinkansen (the Japanese bullet train), where the train's leaving the station, and whatever's done is on, to finally full agile, and they rolled out full agile in a few weeks with 300 developers. But before they did that, they had to modularize the data architecture and the design of their software so it was not one giant, monolithic piece of code. You can modularize things when you've had a lot of experience with them, and have a deep understanding of each module’s requirements and interfaces. Each team would get a one-line story they were after: “the bank wants to validate a credit card” or “a client wants to check her team’s monthly sales quota.” Then you can let each team do a sprint. You can’t have novices in sprint teams. They've got to be experts, and they're all responsible to their fellow team members, and they're all really good at what they do.
PHIL In agile, as Ray described, subteams are working on pieces. And you break the problem into its component pieces, and everybody works on their piece. But at a predetermined time, the code all merges into one stream, and then it branches back out again. So instead of doing what we do with a building design, where the circles get bigger and bigger, 'cause you're accumulating more information, it's more like this:
RAY The product is a large, complex piece of software – so complex that it's impossible to accurately plan out how long it will take to finish. There are two big structural differences between designing a building and designing a piece of software. Number 1: a piece of software is a relatively binary thing. Either it works or it doesn't work. Number 2: the relationship between all the chunks is not as important as it is in a building. There is a relationship between all the pieces, but if a given piece of the interface doesn't work, or a piece of data architecture doesn't work, the whole thing doesn't really collapse. But if the structural system on a building doesn't work, you have no building.
PHIL The analogy between software development and what Ray's discussing is like when I was running the Autodesk Revit team. We had a software-testing regression laboratory with 1,000 computers, and every night the entire code base would be run in parallel on 1,000 machines. It was as if I had an office of 1,000 architects and engineers, and every night after I go home, they would check all my work.
The principle of regression is one that should be introduced in design, because something Ray's sprint team does may break something that Dominique's team did. And you don’t know that until you've tested it in an automated way. Today, we can do this clash detection only with geometry – if Ray moves a column and it bumps into Dominique's door. But if Ray changes the air distribution in such a way that the acoustics have been modified, you may never find that out until the first concert is held.
DOMINIQUE There are conversations that don’t happen often enough, such as “Hey, we added two more inches of insulation” or, to the engineer, “We forgot to tell you that you can lower the tonnage.” We all need more back-and-forth to understand the wider repercussions of certain choices. It might be helpful if we had a method of managing more of that intelligence in the BIM process.
RAY The closest thing to that is the big-room concept, where you put all of the specialty contractor senior people, the architects and the engineers. It’s central to the way IPD works.
PHIL In IPD, you generally need to have the deciders in the room. Are you going to delegate decision-making to someone who's willing to stay in the room? For example, Deborah Berke Partners won an IPD job at Brown University. Deborah's office is in New York. They're going to build a big room in Providence. How's that going to work? You're going to take one of your partners and move them to Providence? Do you delegate that authority? And then there's the other criticism, which is, "I don't want to do all my thinking in the big room."
MARYANNE Can't you come in for milestones, though? Can't you do like "every X moment, we're going to get those people in the room"?
PHIL It gets kind of messy, but the biggest issue is, "When do I have time to think without you in the room?" No offense, but sometimes I don't want to think out loud with you – the client – in the room. I value your input, but I need freedom to noodle.
MARYANNE Honestly, I really don't want to watch that process. I want you to come to me with some of your good thinking afterward.
RAY Software developers have scrum teams, a kind of hierarchy. The scrum master of the scrum meets with all the other scrum masters. They call it a "scrum of scrums." And that's where they look at interface issues between the teams. And that's periodic, such as weekly. The scrum teams stand up every day and tell each other what they're working on, and then they work for a day, and then, at the end of the week, they try to build their module. Every two weeks, they build the whole thing. And if your piece breaks the build, you wear a T-shirt that says, "I broke the build," which is the ultimate shame for a software person. And you have to wear that T-shirt for a month. There is great power in shaming!
PHIL To pick up a thread on the IPD question . . . we’ve been dancing around the elephant in the room, which is the question of risk. We’ve mentioned several risks: the risk of leaving your lane; the reservation of the banks or investors; the unwillingness of architects to use analytical tools because they don't want to take responsibility for the outputs. Is risk a problem or a value proposition?
MARYANNE The business I’m in is the lower form of life. You guys are the noble part of the profession, but not where the money is. Your margins are thin, so you're derisking as you need to. The risks I want to take are not necessarily in the work you do. So how do you deal with the risk and strip it out so you can get a better result or contend with it or reward it? I'm not sure you guys would want to be rewarded if it meant "I'm going to pay you 10 times more than your contract if you produce a certain result, but if you don't, and it's below the minimum we all agreed to, you're going to lose half your fee." It's hard for you guys to make that bargain when your margins are thin.
DOMINIQUE We can take upside but not the downside. So much of project profitability depends on costs that architects don’t often have a lot of control over. There’s a perception that architects drive project costs, but we’ve seen variances as high as 100 percent between bids on the exact same design. I don’t think most people want to take a risk-reward relationship on something that they don't have more control over – or at least transparency to the numbers. We’d be happy to take that risk if there were transparency and a shared idea of what success looks like, in terms of quality of design.
PHIL Very few architects of my generation have skin in the game in place of a straight fee.
RAY With IPD, the architect does have upside. There's a profit pool that gets distributed to the architect and all the engineers, based on whatever incentives are jointly agreed to. It is paid only jointly to the entire team. There is no profit pool paid to the architect.
PHIL Its rough justice. So on an IPD job, you may not have control over the cost, but if there's a profit pool related to meeting the construction budget, and the construction budget is not met, and you had nothing to do with it, you still lose your profit. But it keeps you collaborating then.
Our Autodesk IPD project was only $15 million, but we did a 55,000-square-foot TI (tenant improvements) fit-out and upgraded an empty developer shell of a building to LEED Platinum. We designed it, built it, permitted it, and occupied it in eight and a half months. We took a big pile of money, set it aside and said to the team, "If you meet my budget, you get this amount of money. If you meet my schedule, you get this amount of money." And everybody made a ton of money. Those incentives had everything to do with the success.
You would not believe how in lockstep those guys were. Contractors were making design recommendations in the field, and architects in the field were directing the subcontractors' labor force. Everybody indemnified everybody else. No lawsuits, except for gross negligence. This IPD project succeeded, in large part, because I said as the owner: "This job is going to be completely open-book, no profit, and I get to look at all of your books. So I know what your overhead multipliers are. I know what your labor rates are. Everybody's got to do everything open-book, zero profit.” All the profit was based on achieving the four goals I needed to have happen. They were not at risk of losing money, but they were at extreme risk of not making any money if they weren't successful.
MARYANNE Who was the captain?
PHIL There was no captain. As an IPD job, it was a team. The architects led up to the transition into more construction-related activities, and then the contractor led. That's just how an IPD job is supposed to work. People who work on these jobs never want to go back to another fixed-price, lump-sum job. A fundamental principle of IPD is that everybody cross-indemnifies. Would you ever do that?
MARYANNE I would absolutely do it, because I’m now independent. In certain constructs, I could never do that because I've got too many naysayers in the room.
RAY To make IPD work, you need a client who will designate someone to make binding decisions. When a major tech firm tried doing without that, and one of the senior people decided to change direction halfway through the project, the whole thing turned upside down.
PHIL Making IPD stick is hard because everybody understands it intellectually but getting people to behave that way, particularly really experienced, successful people, is a challenge. When I was the owner on our IPD job, I had to resist the temptation to say, “Dammit – I’m the client! Do what I say.” That is counterproductive in the IPD realm.
RAY I visited one of Sutter Health's IPD projects in California. I walked the job, just to get a feel for it, and I heard two foremen shouting at each other. One said, "You're digging a trench. Just dig it wider so I can put my electrical conduit in there." The guy said: "I don't dig trenches for electricians. Dig your own bleeping trench." You’ve got to change that kind of behavior, and it’s hard to do.
PHIL When you ask engineers about ingenuity and innovation, they often think the solution is to be more efficient and free up resources to do more interesting things. Do you buy that argument?
We all need to get out of our silos and do more information exchange. In general, interactions with architects, and the level of play in the architectural sector, is so much better than 10 years ago.
RAY Working more efficiently doesn't mean you're doing the right thing. And so I think it's really important to keep on balancing efficiency versus effectiveness. And that's hopefully what you get when you have these multidisciplinary teams, and when the client is represented by someone who's actually going to operate the building, not just get the cheapest capital cost and then flip the building.
DOMINIQUE We define success at the outset of a project. Then we push the boundaries of what we can achieve in long-term operational efficiency, but also process efficiency. If you're checking along the way against that benchmark, then I think the argument makes sense. The catch is, even if technology is helping you work more efficiently, you might not necessarily fill your time with more valuable, creative activities.
We use the 4DX process2 to protect time for higher-value efforts. This process recognizes that 80 percent of what you do is the everyday, tactical, must-get-done work and only 20 percent is higher level strategic work. The process provides a framework to protect that 20 percent.
MARYANNE For us, all this automation produces a more sophisticated client experience, and the conversations are about efficiency, delivery and innovation in ways that we weren't talking about 10 years ago.
There is an 80:20 rule: 80 percent of the time you’re working in the business, and 20 percent of the time, on the business. We all do this, but only within our own silos. When I visit Thornton Tomasetti, Tom Scarangello says, "I want to show you some of the things we're working on." I sit through a session with Tom, and I realize he's got an idea incubator, and I can take all that information and see how it can change my world. The point is, we all need to get out of our silos and do more information exchange. In general, interactions with architects, and the level of play in the architectural sector, is so much better than 10 years ago.
PHIL The industry lacks common platforms. The only way it does anything together is when clients convene some kind of forum. Academics, software providers, architects, engineers – we're constantly talking amongst ourselves. It's an echo chamber.
MARYANNE The federal government convened a forum for embassies. They brought in people from different industries, and we would sit around and talk about the U.S. embassy in Lebanon. I was on it for two years. It gave me hope that my federal government was thinking, "We don't want to just hire a fancy architect. We want to understand the best way to build this building." These forums are too few and far between.
We developers will change because we have to. We're not necessarily going to be on the forefront. You'll be dragging us toward it, but if we don't change it's going to be a problem. We can’t continue to do things the way we've been doing them.
Younger developers are changing the complexion of our community. There are no women-owned true development companies that are not dynasty driven. If I can hire 65 percent women and bring architects into the world of development – and they actually make good developers – we can change the DNA. Women multitask to survive; we look at the world differently. So if you change the composition of the development community you can change the result.
1. Charles M. Eastman and Rafael Sacks, "Relative Productivity in the AEC Industries in the United States for On-Site and Off-Site Activities," Journal of Construction Engineering and Management, July 2008.
2. Chris McChesney, Sean Covey and Jim Huling, The Four Disciplines of Execution, (New York: Free Press: 2012).