Continuing our series on automation, I sat down (virtually) in September 2021 with two more industry experts in digital design: Michael Bolduc, P.E., a Senior Project Manager at Simpson Gumpertz & Heger, and Dr. Kristopher Dane, Vice President and Director of Digital Design at Thornton Tomasetti. Both serve on the SEI Digital Design Committee. Below are highlights from our discussion.
The two of you wrote an excellent article in STRUCTURE magazine called Communicating in a BIM World (March 2021). The article alludes to the increasing pressure on structural designers to respond to major architectural changes or coordination issues late in the process. Do you foresee this pressure resulting in more “studio integration,” i.e., engineers and architects working for the same company, or perhaps under a design-build/integrated project delivery (IPD) arrangement?
Dane: I doubt that an acquisition that makes a multidiscipline shop will resolve the kinds of issues that we outlined in the article. The challenges are due to the nature of the design process; how the different disciplines approach their work. For example, structural engineers will still need to build lateral and gravity models separate from the BIM. We need time to do the work and bring it back to our partners. Being under one roof may ease communications because it is easier to wander over to your architectural colleague’s desk and have a chat. But as a consulting engineer, especially with the prevalence of virtual meetings, I think those conversations are just as easy for us as in a multidiscipline shop.
Regardless of the firm organization, the technology puts us under pressure to emphasize our communication skills. We need to articulate what is driving our design, what will be important early on, and communicate that to our clients in a way that resonates with them. Technology may also be part of the solution. If we can automate some bits of our design and figure out where artificial intelligence (AI) fits in, we will have more time to communicate with design partners and clients. If we’re leveraging automation and AI well, we will assess options quickly and will not need as much time between conversation and structural resolution. Those answers will also be given with more confidence because they are based on previous work.
On the second part of your question about design-build or IPD type arrangements, I think any contractual arrangement that helps bring the design team closer to the builders and helps incentivize collective and collaborative behavior is the right answer. This is not a technical problem, but getting the incentives and risk management correct is important to enable the technology.
Bolduc: I think the solution really is in the technology. The tech allows us to automate responses, automate some of those preliminary studies and get a sense of things. It helps provide that feel that engineers have had for years, i.e., a senior engineer can look at a beam size and know it is too small. How do you know? I just know because I’ve seen a lot before.
You can start to teach your staff, whether it is AI or conventional software, by checking those things with immediate feedback. The software is coming along to the point where it does not take three days to run a whole building anymore. They can run almost instantaneously, so you have this instant feedback, and we can almost start to offer shared structural models where the architect can ask, “what happens when such and such happens?” They can start doing some push-and-pull stuff and get feedback from the software.
We can then incorporate and guide them on what that feedback really means and whether it is viable. But you know, if you stretch something and use the color coding – red, yellow, green – and they start stretching, start seeing red? Hey, that is not good. I’m going too far, or I need to thicken something up. I think that technology can simplify some of these structural engineering tasks, especially in the early stage, so that architects understand the ramifications of their concepts.
Another resonating passage from your article goes: “…as daily work processes become more model-driven and less time is spent looking at the drawings, the potential to miss critical details that are not modeled is introduced.” Do you worry that it will lead to structural failures?
Dane: Look at the classic examples like the Hyatt Regency Kansas City; mistakes are often in the details. I think it is important that we leverage technology to reduce the cognitive load on our designers so that they can spend more time thinking about the detailing and about macro issues like the load path and client intent. We should strive to spend less time shuffling paperwork.
Bolduc: Tech can help solve the mundane tedious tasks. If you can take away those mundane tasks, you’ve just freed up 20% of young engineers’ time to focus on the details. Focus on how it actually is going to get built, focusing on its complexities that might have gotten pushed too late in the game, like that “easy” button in the Staples commercials. Take away the easy stuff, and now they can focus on the things that require an actual brain to think through. Engineers can then get back to engineering, not just redlining.
Dane: If we were sitting here with somebody nearing the end of their career, they might say, “I’m nervous about the technology. The kids these days spend too much time with the models, and I am not sure AI can replace engineering judgment.” But we don’t think twice about letting Excel do the math for us; we trust SAP and RAM. So as we start to create interoperability tools and design with AI, we all must understand the value of the tools and how they work. In addition, for AI tools, we will need to understand the limits of the underlying data sets and the risks involved. Eventually, though, we’ll get to a point where we are comfortable having AI as part of our toolset.
Bolduc: It’s the “trust but verify.” I’m not saying we go and check individual members by hand anymore because that has been vetted and trusted for long enough. Did we say, “OK, we can now trust this?” We do not need to verify anymore. We did that process of verifying to prove the tool works. And until you have used that tool, tens, dozens, hundreds of times, you are constantly worried because, as engineers, we are responsible for public safety. This is what we did for the last 100-foot span. Now it is 150 feet, so double-check and make sure it’s right.
In the article, you had a great phrase recommending that we “proactively open lines of communication within the design team when sharing models and reviewing changes.” Could you illustrate how you’ve seen that work or not work?
Bolduc: I go into a litany with every architect I work with, even if I worked with them before. Remind them: Here’s my workflow. Here’s how I operate as an engineer. I understand your workflow; you jump in right away, start designing, and then the drawings come out of it. Next, I explain how our checks happen outside of that model that you see.
I explain to them: there will be times when I go silent on the model, or the model stays stagnant for a few weeks at a time. But, you know what I’m doing, I am engineering, and I am verifying what is shown in those drawings, or I’m about to update all those placeholder sizes that I gave you early on, and I explain the process. So, I think that is the big thing – really explaining our workflow early in the project. And then, later in the process, you can remind them that we talked about this.
I explain that “I will keep you apprised as we go, but you will see me just come and go, and you will see things change and not change for periods of time.”
Dane: Establishing norms and expectations is important. The structural engineering workflow is different enough that it’s worth explaining every time. As Mike mentioned, we do our design outside Revit, but we can put placeholders in the model to keep the design coordination moving and support model coordination. So, for example, on a typical project where we are modeling elements to Level of Development 300, we’re not going to model steel connections. Still, if we have a structural frame that is being featured or some tight coordination issue, we can model gusset plates in those areas.
In other words, if there are ways we can do a little extra modeling to help ease design or constructability concerns, then, of course, we are going to do that. I want to be a trusted partner. For projects that have a lot of constructability or speed of construction concerns, services like Thornton Tomasetti’s Advanced Project Delivery, where a full fabrication model is developed, may address those concerns.
Finally, discuss communication norms for the team at the kickoff. Align on primary communication platforms (email, Microsoft Teams, phone calls, text messages), expected response time, model and drawing exchange frequency, design lockdown dates, and critical path items. Those can be slightly awkward conversations, but in a kickoff with the other disciplines in the room, I find that everybody has those concerns once the conversation is started. If we don’t sort it out at the start, issues may snowball as the project progresses. So establishing group norms is never wasted time.■
The author would like to thank Michael and Kristopher for sharing their experiences and insights. It is fascinating to see the common themes on how we as engineers might more effectively communicate with clients and collaborators in this era of evolving technology.
