Bridging Documents and Prescriptive Requirements (Feb '24 Bonus Content Episode)

Sometimes, our chats with podcast guests go long, dive into some deep stuff or – every so often – get a little weird. The topics we discuss are also multifaceted and can only go so far in a single episode, so we’re introducing a new way to bring you some of the better content that ends up on the cutting room floor. 

Listen now to the newest Design-Build Delivers Podcast Bonus Content on your favorite podcast app. In February’s episode, A Bridge Too Far?: Contextualizing DBIA’s New Position Statement on Bridging Documents and Prescriptive Requirements, we talked to Shailendra Patel (Virginia Department of Transportation) and Bill Kent (Mortenson) about our newly released position statement on performance based requirements over bridging documents. There was more to the conversation, though. In this Bonus Content, we talked about the controversy about bridging versus performance based requirements, a little on the Spearin doctrine and why DBIA entered the chat.

Access all our free design-build resources and learn more about Design-Build Done Right® at dbia.org.

DBIA members are shaping the future, one successful collaboration at a time.

Transcript

SPEAKERS

Bill Kent, Erin Looney, Shailendra Patel

Erin Looney  00:09

Welcome to the second of many Design-Build Delivers Podcast Bonus Content minisodes. In February, we talked to Shailendra Patel and Bill Kent about our newly released position statement on performance based requirements over bridging documents. I learned a lot about bridging from Shailendra and Bill, and I hope you did too. 

Erin Looney  00:26

But there was a lot more to that conversation. We also got into some of the controversy about bridging versus performance based requirements, a little on the Spearin doctrine and why DBIA has entered the chat. I am Erin Looney, and this is the Design-Build Delivers Podcast Bonus Content, brought to you by US CAD. 

Erin Looney  00:45

Construction projects are complex, no matter the delivery method. So it's no surprise that there's some disagreement in the AEC industry about prescriptive requirements. And there are some areas of the AEC industry, when I was doing my research, that were arguing exactly for the opposite of what our position statement says. We will not call them out by name because their position is just as valid. But talk to us about why that conversation still exists and why there isn't a simple answer. 

Bill Kent  01:16

A lot of the – Owners who have not done any design-build or given up what they perceive as control of the design to a design-builder, there's this inner belief that if they don't specify exactly what they want, they won't get what they want. And that, that is pretty steadfast, and a lot of, a lot of minds,  mindsets. And it's really it's a learning curve for Owners. And there's – I remember hearing one story from an Owner talking at one of our DBIA conferences that the first time she did design-build, she didn't really trust the process too much. So she want– she was very prescriptive, because she wanted, she wanted to tell people what she wanted. But as she – the more and more she did design-build and every design-build job she did after that first one, she got less and less prescriptive based and more performance based because she learned to trust the process. And some Owners will hear from consultants that, "no you and I need to talk and then I'll let them know what they should do." And that's, if you don't trust design-builder, you haven't done design-build, but you have that trusting relationship with say an architect, that may sound like a logical way to do it, until you've learned how things can be improved in the other direction.

Shailendra Patel  02:25

It's an interesting dilemma, right? Because like Bill said, Owner has expectation of how their project is going to be turned out. And performance requirement opens it up for different interpretation of how to achieve the same goal. So traditionally, what has been expected. And when you see something that is not, people start to think in the manner that like next time, I'm going to spell out exactly what I want. Right? So going back to Owners wants control, but Owners also don't want to get surprised. However, I think what we have found that those dialogues, when you're putting your requirements together by having somebody facilitate that dialogue really helps everybody to think what could be, right? What could be provided to you, in reference to what you are saying. So we are very, very focused on when we write the requirement, we actually work with our team and say, "think about what you don't want, and focus on what you don't want and leave all of the flexibility to just alternative solutions for those things." So performance requirement is one way to achieve that. 

Shailendra Patel  03:42

And and it's very hard thing to do for engineers, because we have trained ourselves for years and years to spell out what we want, right? To undo that, it takes a lot of efforts. And I generally use this example that you have to really, as an engineer, it's very hard because you always continue to work on your design and then come to – come to a final solution, 100% plan, then you know exactly how it's gonna look like. Now take that out of equation, you have a conceptual plan. And now you're asking engineer to define, verbalize what end product would look like. Right? It's a very difficult task. So the natural tendency is somebody to say, "Okay, I want this, this, this and this." But you take it back and say, "no." Without saying this, this and this, how can you achieve the goal? It's a very difficult task for any engineer. So that's where the prescriptive requirement continues to come into play. But it requires a specific effort to work with them and say, "Okay, let's now talk about what you don't want and let's focus on how can you leave the door open for building better mousetrap?" Right? So that's that's the flexibility means to me and I think it has helped us a lot. 

Shailendra Patel  04:59

One other minor point in at least transportation industry, we do not have a lot of performance specification, which is a different area – requirement, I focus more on requirements, but also sometimes specification and requirement gets confused. And so I really want to emphasize the requirement can be developed. Performance specification is harder because it's more detail how you're going to accept something. How does it meet the performance requirements? It's very easy for, let's say, building to have HVAC systems, how is going to perform? What is the cooling? What is the hot – heat? Of course, it's not my area of expertise. So I'm using this as general example. But how do you accept the project, which is a concrete pavement? And you know, traditional way of doing testing is just do the test. And the test results will tell you whether concrete is good or not good, right? So there is some, some, some areas where performance requirement can work. But at the end of the day, when you accept the project, we are required to do certain things to accept the project because at the end of the day, FHWA has to agree that, "hey, we have a project that has been delivered and meets all the specification." We're not there for performance specification.

Erin Looney  06:26

My father was an engineer, mechanical engineer. Yeah, I hear and see exactly what you're saying about saying to an engineer, there's a tiny bit of wiggle room and they go, "No, there's not please no, there's not." Yes. So how then does DBIA's position statement here fit into this discourse? How, where do we sit in that conversation?

Bill Kent  06:49

There's a lot of things that go into the reason why an Owner should go to performance based and one of them is risk. And this is where things get a little bit skewed every once in a while as Owners feel like they're eliminating their risk by specifying exactly what they want. But in reality, they're absorbing more risk. As the Owner of that design, they absorb the Spearin doctrine, it's a legal doctrine out there that says if an Owner provides a design, the Owner warrants the sufficiency of that design. And they warrant that that design is sufficient for the performance they're looking for. So when an Owner tells you, you must do something exactly like this, and you do it, and it doesn't achieve the performance requirements they were looking for, that's – the Owner is now at risk for that because they've told you how to do it. That's one of the great risk transfers in design-build delivery, where the design-builder takes the responsibility for the design. If all the Owner gives us as a performance requirement, and we create a design, and we build that design, and it doesn't achieve their performance requirement, we know that's our responsibility because we had all the responsibility for design. Spearin now applies to the design-builder. So really, Owners who think they're eliminating risk by being more prescriptive, they actually are absorbing more risks, because they're now responsible for the adequacy of the design they're mandating. So it's a big transfer of risk type equation.

Erin Looney  08:01

At first glance, hearing that I'm like, nice, nice turn of phrase to get there. But it does make sense. What are your thoughts on this?

Shailendra Patel  08:07

I agree with Bill, because more prescriptive you are, you're pretty much telling them how to do it what to do, right? And if it doesn't work, the the risk transfers back to the, to the department owner. So it's a it's a very important aspect to understand when you're prescribing something and you're directing. In other words, you're directing them what to do. That's what happens in design/bid/build. We've been doing this forever, right? We've been – we've been creating the plans, 100% plan. Spearin Doctrine come into play because now you're warranting that these plans, this is what we want you to build. And this is how it's going to turn out. I mean, we pretty much took all the liability that design-build allows us to transfer to design-builder the appropriate risk transfer. You are taking that back. And I think that's where Owner needs to understand that there is a fine line between having the performance requirements, prescriptive requirements, and how you really transfer – this risk transfer occurs between Owner and design-builder.

Bill Kent  09:15

And I will say because some folks who might say bridging documents are the right way to go may think that we're trying to eliminate the need for that service. And we're really not because creating a good – we'll call it criteria documents, which would be a performance based communication during the RFP is what the Owner's expectations, our needs are for the project. So it's criteria documents, there's an art to writing those. And they have to be universally acceptable and understandable. So everybody's, everybody's shooting for the same goal. And as Shailendra mentioned previously, there has to be a way to to verify that performance has been achieved. Because if you don't have that how would you ever know that you've achieved your contract requirements? So there is an art and there is still a place for consultants to help write, Owners write those criteria documents. The trick is is not just keep going and keep going and keep going until you start getting to be prescriptive on how to do things. So there's there's a fine line between that criteria and those bridging documents we've been talking about.

Erin Looney  10:13

Fine lines indeed Shailendra and Bill's grounded perspectives on a complicated topic hopefully has thickened some of those fine lines for you. And you can download the position statement on bridging documents free in the DBIA bookstore at store.dbia.org. And if you want to hear the rest of the conversation, you can check out the February 2024 episode of the Design-Build Delivers Podcast, A Bridge Too Far?: Contextualizing DBIA's New Position Statement on Bridging Documents and Prescriptive Requirements on your podcast app of choice. 

Erin Looney  10:42

And get ready for the March episode featuring Mike Meredith and Vince Campanella, as well as a couple special guests for a discussion of the 2023 State Statute Report, DBIA's model legislation and some recent state level legislation victories. Thanks again to Bill Kent and Shailendra Patel, our producer extraordinaire Fred Yi, all of you for listening and of course our Design-Build Delivers Podcast sponsor US CAD, visit uscad.com/dbia.