Episode Transcript
[00:00:03] Speaker A: Hello and welcome to the Consulting Specifying Engineer podcast. I'm your host, Amara Roskas and in this episode we are talking about risk assessment. This CSE podcast is about to turn three years old and I'm excited to be here.
Let me introduce you to Cindy Kogel from Smith Group. She is our guest today. And thank you. Thank you for joining me, Cindy.
[00:00:28] Speaker B: Thanks Amara. Thanks for having me.
[00:00:31] Speaker A: Yeah, yeah. And there is a lot of discussion about project risk, so I thought I'd talk to an expert on the topic.
Cindy Kogel is a vice president and senior mechanical engineer with three decades of experience leading the planning and design for higher education and other institutional clients.
She provides technical leadership and strategic engineering oversight to deliver reliable, integrated and high performing building systems.
As a client advisor, she cares about how decisions are made, aligning them with academic priorities, funding constraints and long term capital plans.
So Cindy, this is kind of a big topic, so I'm going to start at the top.
Where do you see the biggest disconnect between how engineers think about risk and and how owners think about risk?
[00:01:25] Speaker B: That's a great question. I think the biggest disconnect is that engineers tend to define risk technically while owners experience risk operationally and financially. For example, engineers worry about things like undersizing code compliance or whether a system will technically work. Owners worry about whether the building will be uncomfortable, expensive to operate, difficult to maintain, or disruptive to their business.
What makes this tricky is that both groups think they're talking about the same thing, but they're actually not.
An engineer may feel that they've managed risk by designing a robust code compliant system, while the owner later feels exposed because the system is complex, it's fragile, or depends on skills that they don't have in house.
A lot of H Vac risk doesn't come from bad engineering per se. It comes from misaligned definitions of success that were never really reconciled early on in the project.
This. This misalignment can be particularly problematic for projects that are pursuing performance based goals around energy, carbon and water.
For example, I contributed to a Living Buildings Challenge certified project that was designed to achieve net zero energy and water.
The client was a nonprofit organization and they aimed to supplement their program funding by by hosting weddings on site.
And this was the use that introduced significantly different resource demands compared to their typical daily operations.
To address this, our team, we kind of effectively reverse engineered the building systems to determine how many events they they could accommodate while still keeping the required photovoltaic arrays, wind turbines and water storage systems within budget.
Through this process we were actually able to align kind of technical feasibility, operational needs, and financial constraints early in the design process.
[00:03:22] Speaker A: Okay, so every project has risks, it sounds like.
Are there cases where trying to avoid all risk can create greater project risk?
[00:03:33] Speaker B: Absolutely, and this is one of the least intuitive lessons engineers learn.
When engineers try to eliminate all risks, this results in oversizing over complexity and what we might call defensive design choices.
Each individual decision in and of itself feels prudent, but collectively they can create systems that are inefficient, hard to control, and difficult to operate.
For example, like adding layers of redundancy or safety factors without clearly understanding how they interact can increase failure modes rather than reduce them.
Oversized systems short cycle, they struggle with humidity, and they have poor part load efficiency. And when the system doesn't perform well, operators often override sequences just to try to keep things stable.
This issue is especially critical today as heat pumps are becoming the cornerstone of building electrification strategies.
So I think this is just something to really think about. On paper, when these systems are sized and designed to meet, say, 100% heating load at the absolute coldest historical temperature, they can survive the worst imaginable winter. But in reality, they're oversized the overwhelming majority of the year. They short cycle and they experience defrost instability.
The tenant comfort becomes erratic in shoulder seasons when the loads are low.
And in the end, the owner paid for a system that doesn't really meet their expectations.
So I think in practice, risk management's about trade offs and not necessarily elimination of all risk.
The goal isn't to design a system that can survive every hypothetical scenario. It's really to design one that performs reliably under realistic conditions, and that fails gracefully when assumptions change.
[00:05:29] Speaker A: Okay, okay, that makes sense. And you kind of touched on this, Cindy.
Sometimes engineers have to protect their clients from their own poor decisions. What does that look like when you're navigating those situations in real projects?
[00:05:46] Speaker B: Yeah. So this issue often shows up when an owner wants to reduce scope or cost in ways that ends up shifting risk downstream.
For example, example, you know, cutting commissioning, downsizing, controls, integration, doing partial work like say a lighting upgrade without rebalancing the H VAC system, or selecting unfamiliar technology without having the necessary operational support.
Protecting the client doesn't really mean saying no reflexively. It means explaining what the risk, what risk the decisions introduces.
Being clear about who owns that risk, and making sure the choice is deliberate, not accidental. One of the hardest parts of professional practice is recognizing when agreeing too quietly becomes enabling.
If an owner makes a decision after being fully Informed and that decision is documented.
That's very different from a decision made with out understanding the consequences.
In many cases, the engineer's real value isn't optimization, it's clarity.
[00:06:53] Speaker A: Right. Right.
So what are the H VAC design decisions that seem reasonable during design, but then create the greatest long term operational risk?
[00:07:07] Speaker B: So in the. In the previous Q and A, we just, we talked about how we protect clients from themselves, but sometimes we need to protect engineers from themselves.
The most common decisions that create the longest term risk are those that introduce complexity without the necessary operational capacity. So some examples include systems that require constant sensor calibration, distributed equipment that is labor intensive and suffers from access challenges, custom solutions that lack local contractor familiarity, sophisticated control sequences that not even the control subcontractor or commissioning agent knows how to fine tune, and designs that assume ideal maintenance staffing forever.
These decisions often look rational during design reviews because they're technically sound and they're well intentioned. But the risk emerges later when the building is turned over to the facilities team. That perhaps wasn't part of those initial discussions and decisions.
One of the quiet truths in H VAC design is that systems don't fail because they're wrong per se. They fail because they're misunderstood or unsupported.
[00:08:23] Speaker A: Okay, so I guess my next question is kind of about communications then.
Why is it so important to be explicit about design assumptions in the basis of design? And then what risks arise when those assumptions stay implicit?
[00:08:41] Speaker B: Sure. So you know every H vac system is built on assumptions about schedules, loads, control, sophistication, staffing, future use, etc.
The risk isn't having assumptions, the risk is pretending they don't exist or not being transparent about them in the first place. When assumptions stay implicit, they eventually resurface as disputes with with the engineer arguing we assumed reduced occupancy over the summer, or we assumed you'd have trained operators, or we assumed the space wouldn't change use.
It can also lead to owner dissatisfaction and loss of trust even when no standards were even violated.
Unspoken assumptions tend to fall on whoever comes next. So controls contractors make judgment calls, calls without context. Facility staff inherit systems and assume capabilities they don't have.
I think a strong basis of design doesn't just describe the system. It defines the boundary conditions under which that system is expected to perform. Well, I always say the basis of design must include the why behind the what.
From a professional risk standpoint, the BOD is one of the few documents that explains why the system looks the way it does. And when expectations Change, which they always do, the BOD becomes a reference point rather than a finger pointing exercise.
So on a recent laboratory building project where we didn't have complete information, they didn't have all the PIs in place yet, we ended up categorizing lab spaces based on infrastructure and support capabilities rather than by department or user.
And this included criteria such as vibration control, chemical storage, power density, service, distribution, ventilation, design levels, and air change rates. And by kind of approaching it this way, we were able to create a framework that could meet the day one requirements while remaining adaptable for future needs with minimal cost and disruption. And we kind of laid out a path that clearly defined and aligned expectations between the design team and the owner, knowing that things were going to change over time, but it gave them a framework in which to work.
[00:11:05] Speaker A: Okay, so it sounds like there are no, there's no room for assumptions.
[00:11:12] Speaker B: Well, there are assumptions, there's always going to be assumptions, but you have to document them and you have to be clear about them. So everyone. So you build consensus around what the assumptions are.
[00:11:23] Speaker A: Okay, okay. So when you're mentoring a junior level team member, what do younger engineers tend to underestimate when they first start leading H VAC projects?
[00:11:37] Speaker B: I think one of the biggest things younger engineers underestimate is how much leading a project has to do with shaping the conditions for success, not just making technical decisions early on. It's natural to think that leadership means, like, picking the right system, doing solid calculations, solving technical problems.
But with experience, you realize that a lot of the real risk is set much earlier. It's during scope definition, expectation setting, and fee development.
Younger engineers often see scope as something that already exists, when in reality it's actually something that's actively formed, sometimes clearly, sometimes accidentally.
If you don't participate in defining what's included, what's excluded, and what assumptions the design is based on, those gaps, they show up later as stress or rework or conflict.
On another note, fee. Fee gets underestimated in the same way. And it's easy to see it as a business constraint that kind of sits outside of the technical work.
But FEE directly affects how much time you have for coordination for qa, qc, for thinking through or testing scenarios, and even communicating with the owner. And when the fee is too tight, risk doesn't disappear, it just gets deferred.
I've seen a lot of projects where the engineering really wasn't the problem at all. The real issue was that the scope expanded quietly, expectations drifted, and there wasn't enough fear time to adjust.
And that Pressure eventually shows up as missed details, compromised reviews, or kind of a level of defensiveness instead of one of collaboration with experience. I think you start to see that being clear about scope and being realistic about fee isn't necessarily self protective. It's kind of project protective. It really allows good engineering to happen.
So leading a project is, I would say, as much about communication, alignment and setting boundaries as it is about technical excellence. And that's something most engineers don't fully appreciate until they. Until they live through a few difficult projects.
[00:13:57] Speaker A: Right, right. Okay. So in your day job, you manage risk carefully with. For yourself, for your clients, for building owners. But let me flip it for a moment.
What's a risk you've taken personally outside of work?
[00:14:14] Speaker B: Ooh, that's a good question.
One of the biggest personal risks I've taken was serving as a crew advisor on a Philmont trek. And for those who don't know, this is a backpacking expedition at Philmont Scout Ranch in New Mexico, where crews of scouts and adults hike through the rugged Sangre de Cristo Mountains.
Our crew, we covered about 60 miles in seven days, and we summited two peaks.
Our last summit was called the Tooth of Time. And this is not your average hike. It's a serious climb over steep, rocky terrain. And the last section involves large boulders and exposed cliffs and deep crevices where you're very aware of every step that you take.
By the way, did I mention I'm like 5 foot one?
What made this a real purpose, personal challenge for me is that I have to. I've had to adapt to living with, like, vestibular nerve damage, and this can affect my balance and spatial orientation.
So navigating kind of complex, uneven environments like the Tooth of Time required me to kind of draw on my resilience and adaptability skills. I knew that I couldn't move fast and I couldn't rely on instinct alone. I really had to, you know, move deliberately, step by step.
And on the way down, I literally did a crab walk down, down parts of it with my crew around me, kind of talking me through footing and direction.
So, you know, I kind of think, like, looking back on that experience, the risk wasn't about bravado or pushing limits blindly.
I feel like it was about being honest about, like, constraints for myself and, and planning for them and, and really kind of trusting the.
And that experience really stuck with me because it reminded me that taking a risk doesn't always mean charging, charging ahead, but it sometimes means just slowing down, asking for help and, and still choosing to show up and in a way like design is very similar to that for H Vac systems. I mean I always say, you know, it really takes a village and we need to kind of we need to be confident in our own skills. We need to know what we know, know what we don't know.
But we also need to lean on others and recognize that other people have different experiences that we do and that together we can solve the problem and find the best solution.
[00:16:49] Speaker A: How very motivational. Thank you so much Cindy. That's awesome.
[00:16:56] Speaker B: It was a pleasure, pleasure talking with you today Amara.
[00:17:01] Speaker A: Great. Well this is where we need to wrap things up. There have been a lot of questions about risk management within engineering.
So for more information on the topic visit consulting specifying engineer cscmag.com and don't forget to check in regularly for new podcast episodes.
Thanks for joining us and we'll be back again soon.
Bye Bye.
