ReEngineering the Engineer: To Change or Not to Change? The Answer Usually Is to Change
Codes have changed significantly through the years. When I started engineering, the structural section of the North Carolina Building Code was just more than 100 pages and was basically the “one-stop shop” for all our structural engineering analysis and design criteria. There were material codes as well, but they were also similarly simple, and calculations were easy to follow.
Today, the structural portion of the International Building Code itself is about 200 pages, but it also references other design Codes as well as other material Codes. Each one has its own full complement of analysis, design requirements and commentaries, and they aren’t as easy to follow or as intuitive as the “good ol’ days.”
I’m confident all these changes have been for the better. But it’s easy to see our engineering life has gotten messier through the years, and the rate of change continues on an ever-increasing upward trend.
Unfortunately, change is one of the things some of us find difficult to accept, particularly when overloaded with the daily grind of running a business or consumed with the pressure of keeping up with projects. It’s easy to hang on to the way things have been done instead of embracing new changes. But as Codes continue to change, that can present some real challenges.
The biggest change for me personally was moving from the old design with actual loading and reduced member strengths (allowable stress design or ASD) to factored loading and actual member strengths (ultimate strength design or LRFD). Despite understanding that the factored approach was “better,” it was difficult to change many years of design experience overnight. Part of your experience comes from knowing when designs don’t “feel right,” and changing the magnitude of the values throws that feeling off.
But resistance to change has its drawbacks, and I was reminded of that a few months ago. I was talking with a general contractor friend, and our conversation digressed to an issue on one of his current projects. Somewhere during construction of this project, the EOR discovered a major problem on a high-rise project. By his description, something about the “load tables” provided to the steel fabricator were incorrect, and all the connections for the project had been incorrectly designed—in a bad way.
To make matters worse, shop drawings had been approved for most of the structure, some had already been fabricated and yes, some of it was already erected. There was a major amount of rework that had to be done, with a significant chunk of that performed in the field.
A Simple Check Box
Interoperability with analysis software and BIM has made it easy to get design information into BIM electronically. One piece of that process is transferring reactions from the analysis model into BIM. In the method we use, there’s a simple check box that determines whether service (ASD) or ultimate (LRFD) loads should be exported.
I’m a bit embarrassed to admit that for a while, the checked/unchecked status on that toggle button depended on who was running the project. Some of us wouldn’t let go of the old ASD way, and some of us only really knew the LRFD way. To follow through with that, we then had to make sure the sheet notes were correct—another layer of complexity that varied from engineer to engineer.
Think about that for a second: a single checked/unchecked status of a toggle button or a single word in our sheet notes—service vs. ultimate—affects everything on those plans as well as the entire chain of people downstream who use that information. LRFD loads from analysis but stating them as ASD on the sheet notes is super conservative. The other way around is super not conservative—I suspect that’s what happened in this case.
That’s the kind of stuff that keeps me up at night.
Look for ways your firm can standardize as many processes or procedures as possible but still provide some flexibility to the design.
Always Learn from Mistakes
So how can we learn from someone else’s mistake? Pick a way, any way (hopefully by putting some careful thought into it), and make it an office policy. Yes, it was difficult at first, especially for the old-timers, but it was necessary to make sure everyone was on the same page, and we weren’t getting our wires crossed between different engineers and projects. As engineers, we should always be looking for ways to minimize our risk, and establishing mandatory office policies is a great place to start.
Look for ways your firm can standardize as many processes or procedures as possible but still provide some flexibility to the design. Minimizing risk is part of what we do, and we owe it to the public to find ways to ensure we get it right.