Operator: Please standby. Ladies and gentlemen, welcome to the FHWA Use of Performance Requirements for Design and Construction and P3. At this time, all participants are in a listen-only mode. Later, we will conduct a question-and-answer session and I'll give you instructions at that time. Should you require assistance during the call please press star zero. I'd now like to turn the conference over to Jordan Wainer. Jordan, please go ahead.
Jordan Wainer: Thank you, Debbie. On behalf of the Federal Highway Administration Center for Innovative Finance Support I'd like to welcome everyone to today's webinar on the use of performance requirements for design and construction in P3s. My name is Jordan Wainer. I'm with the U.S. DOT's Volpe Center in Cambridge, Massachusetts. And today I'll be providing technical assistance. I will introduce Patrick DeCorla-Souza, the P3 project manager, momentarily. But before he begins I'd like to just point out a few key features of the webinar room. On the top left side of the screen you will find the audio call in information. Below the audio screen is a list of attendees. Below the list of attendees is a box titled materials for download where you may access a copy of today's presentation and a copy of the white paper. Then please select the file, click download files and follow the prompts on your screen. In the lower left corner of the chat box you can submit questions for presenters throughout the webinar. We will pause for questions throughout the webinar and we will also take questions over the phone after the presentation. If you experience any technical difficulties, please use the chat box to send a private message to me Jordan Wainer. The webinar is scheduled to run until 3:00 o'clock P.M. Eastern today. And we are recording today's webinar so that anyone unable to join us may review the material at a later time. Finally, before we get started there are few quick poll questions we'd like you to answer. The first is how many people are watching the webinar with you? The second, is what is your affiliation? And the third is, how familiar are you with the P3 concepts? We have a second set of info questions in just a second. I'll give you a minute to answer these. I apologize for the audio feedback. Hopefully, Patrick and Jag will not have any. Okay. I'm going to go to our next set of polls. The first is do you have experience using ATCs in the procurement of roadway projects? If yes, what triggers most of the ATC submittal? Check all that apply. The next question is, do you have experience using performance measures in the procurement of roadway projects? If so, check all that apply. Thank you everyone. I think I know why there's an echo. Either Jag or Patrick can you mute your computer speakers.
Patrick DeCorla-Souza: Yes, mine are muted.
Jag Mallela: Mine's muted too.
Jordan Wainer: Okay. Hopefully, the next person will be better. I apologize. I'll turn it over to Patrick now. Patrick.
Patrick DeCorla-Souza: All right. Thanks, Jordan and welcome everybody to today's webinar on use of performance requirements in design and construction for public/private partnerships. My name is Patrick DeCorla-Souza. I am the P3 program manager and I work half time for the Build America Bureau and the other half for Federal Highway Administration's Center for Innovative Finance Support. I just want to give you a very brief background on why we embarked on this research. There was a report in 2011 on use of key performance indicators in public/private partnerships. And when we say public/private partnerships we are really talking about long term contracts that include not just design and construction, but also operations and maintenance and additionally finance. And this report suggested, based on an international study, that there was more scope for using performance requirements in the design and construction phase of these P3 contracts. And, of course, within design build, also, the same type of performance requirements could be applied. So we commissioned this research effort to look into how performance requirements could be more widely used in the United States because they have implications for greater flexibility to concessionaires in developing designs and construction methods that include more innovation and therefore perhaps bring down the costs and perhaps improve quality. And so we are fortunate to have today the primary author of the paper which resulted, which is available on our website and also right here on your left-hand side for download. The primary author I'm pleased to welcome today and his name is Jagannath Mallela. And Jag is with WSP Parsons Brinckerhoff. And he is going to do the presentation for us. So with that, let me give over the podium to Jag.
Jag Mallela: Thank you, Patrick. I appreciate the introduction both to the paper and to myself. What we're going to cover today, as Patrick mentioned, is the subject of introducing innovation in the design and construction phase of P3 projects specifically because the performance requirement concept is more well understood and applied on the operations and maintenance side of P3 projects. And, therefore, for many reasons it is not as well applied in the design and construction phase. So that's what we're going to tackle as far as-- and before we do that we will kind of go over some of the questions that are listed here, or agenda items, why use performance requirements at all, overview of performance requirements, in general, because even the concept of performance requirements it requires a little bit of explanation. So we'll set the stage for that. And then I'll talk about how to write effective performance requirements. And the concept of alternative technical concepts or ATCs is well understood thanks to recent emphasis and increased usage of ATCs in all kinds of project delivery. How does that relate to performance requirements is something that we'll explore. And then we talked about implementation and considerations to move the practice to be more embracing of performance requirements. But before I dive in, I have to acknowledge many of my co-authors who contributed to various parts of this paper that Patrick mentioned, from which this presentation was drawn. Theresa Dickerson was my co-author on this along with Alistair Sawers both from WPS Parsons Brinckerhoff. Bryce Little was our legal advisor, on the legal side of it. And the work was performed under the direction of Susan Binder from Cambridge Systematics. And, of course, Patrick really helped in showing the product that was delivered was on point. So I do want to acknowledge all of them prior to jumping in. So tell me why performance requirements. And I think the main point on this slide, although it is text heavy, we'd like folks to walk away with is that P3, as we all understand, I'm not going into the definitions of this, but as we all understand P3 is an integrated method, project delivery method to deliver not only the facilities but assets. But also the services associated with it. You know, many times it is and/or, you know, assets and/or services. But in the context of what we are discussing here we are presenting the P3 models that are more in the design, build, finance, maintain or design, build finance, operate, maintain realm. So that's the basis of today's discussions and the context and backdrop for it. So it is an integrated delivery approach. It is perhaps arguably the only one where decisions at the time of procurement, the decisions up front in the early phases off the project actually effect how the project or the facility will function downstream because of the lifecycle perspective it brings. The P3 does bring into play a P3 partner, a private partner who is assigned the single responsibility for both the design build O&M phases. And certainly, within that model the sum is far greater than the parts in the sense that it's not a contact management of a design build service or an O&M service. It is about the decision making that permeates through that integration that allows better value for money that is mentioned here, things like cost certainty, potential cost utilization and potential for cost optimization. In terms of investment, you know, what investments should be made now versus what can we get for it later? And that integrated decision-making actually creates the argument that P3 could arguably be the only one, their life cycle decision-making is integrated across multiple phases. It's integrated into the delivery method. So it has great potential. So it allows for innovation to be brought in, in all of those phases across the project. So we realize that the opportunity that P3 potentially offers. Some of those opportunities are basically effective transfer of risks. The commonly used axiom that risk is better managed by the parties that are able to manage it the best, you know, certainly applies here. The majority of design build and O&M risks transfer to the P3 partner in this model, you know, the asset and operational risks and design build risks. But certainly, owners of the facilities have the ability to retain risk where it makes more sense for them to handle and manage. And they can do so by prescriptive requirements. The only caution that is we need to be aware of in this model is that the more restrictive the requirements, the more risk is retained on the owner's side and less chances for innovation. So hence the transfer of risk is an important aspect and performance requirements might be one way to do an incredible transfer of risk. The second opportunity for P3 is to realize its advantages and its potential for efficiency gain. The level of integration, as I said, is such that the sum total of what is delivered is greater than its parts, like the design part, the construction part, or the operations and maintenance part. In larger contract sizes, generally have more complex and require increased coordination that's potentially possible with the P3. And there are design build efficiencies to be gained. There is flexibility in making decisions across the lifecycle innovations that can be introduced to maximize the asset lifecycle and operational performance that the owners are most concerned about in terms of safety, mobility and community impact. So those are some of the P3 opportunities which are waiting to be realized. And the argument is that the performance requirements concept can actually help with that process to realize those opportunities and benefits. On the flip side, if those are not-- if performance requirements are not used and more prescriptive requirements are put in place, then you lose the opportunities for efficiency gain. And the risks are then shifted back to the owner. So this is just the flip side of the benefits slide I just showed you where you have fewer opportunities not available when you use prescriptive requirements. For example, in the case of design, if you have prescriptive design decisions and the fewer opportunities there are, if the decisions are already made and limited potential for innovation consequently. So here's an example of what we mean by prescriptive requirements. So in this case it's an example that has been designed where there is the requirement that's stated here that the P3 developer shall use one of the following pavement types, either hot mix asphalt pavement or a Portland concrete cement pavement. Where the pavement choices are given, you know, for asphalt pavement, you know, there is a specific choice in terms of the thickness that's preselected for you, the type of asphalt binder that needs to be used, the thickness of the base material that supports the pavement. And also, the specification says the acceptance of the pavement will be in accordance with the DOT specifications and standards. And similarly, on the right-hand side, you have a minimum pavement thickness provided, the joint spacing provided to you with no flexibility to change that, to meet the ultimate goal and objective of the project. So any changes from the above specified section requires an approval by the department. So this is an example of how the prescriptive requirement is created. And this is mandated then even the scope for innovation then reduces. So the question is, where is the scope for innovation along a project? This is a slide drawn from Dr. Gransberg's research where he has on the X-axis the time scale and the Y-axis the degree of influence. And across the top you have various phases of the project, the planning phase, the design phase, the construction phase and the operations and maintenance phase. So theoretically the influence, innovation influence decreases as time goes, as you march along from one phase to the other. So in setting up performance requirements the best opportunity is actually doing the project planning phase and to avoid the trap of setting too many requirements at that point in time. So not making too many decisions basically to assess the needs, evaluate the risks and define project goals. The owner has the most influence there. And then as it proceeds to design and construction phase that's your next best opportunity considering the RFP stage as well as the RFP process. You have more control over how to introduce and when to introduce innovation. So once that gets into a construction phase or O&M phase obviously the potential to introduce innovation decreases. So the business case therefore for performance requirements is essentially it's a tool to effectively transfer the risks between parties from the owner to the P3 partner, in a way that is critical and in a way that is manageable. And the second business case is to maximize the realization of efficiency gains by removing constraints innovation, encouraging lifecycle thinking and providing the continuity of decision-making across the phases. So performance requirements really enable really to bring out the value in a P3 to really-- for P3's promise to shine through. So Patrick at this point we can take come questions.
Patrick DeCorla-Souza: All right. I don't see any questions in the chat box. I guess, just a reminder to the audience, if you have any questions feel free to put them in the chat box and we'll be stopping every few minutes to see if there are any questions. So with that, Jag, why don't you move ahead to the next segment.
Jag Mallela: Okay. Thank you. So overview. This section will provide an overview of performance requirements, you know, what they are. And here is a four-part diagram here to define what they are. So performance requirements are basically start with stakeholder expectations. You know, essentially what are the expectations on how a facility should perform once it's constructed and it's in operation. So that's a really high level objective. And then aligning that objective with the functional objectives of the facility its performance requirements. And then ultimately translating into performance criteria. So a few definitions here. The essential functions define how well the facility needs to perform as well as the objectives for a successful delivery. It lays down the objective for a successful delivery of the facility. So essentially it tells you in words how well the facility should perform once it's built and it's in operation. Performance requirements defines what is needed to accomplish the objectives of the project. Essentially, it's a definition. It translates the stakeholder expectations and essential functions into a more concrete statement of objectives of the project. And then performance criteria, on the other hand, are values, are measures that demonstrate it's a big owner requirement, whether a specific owner's requirement has been met. So you translate the stakeholder expectation into the functional performance requirements-- the functional requirements and from there the performance requirements. And then that gets translated into performance criteria. And I have a few more examples where some of this will become more clearer as we go through this. So here is the hierarchy of performance. So you start on the left-hand side column, the stack of process. You know, you have essential functions. We talk about what they are in the previous slide that translates into a performance requirement which becomes a criteria, a set of criteria. And then you draw a performance specification out of that. And then eventually that gets translated into something that is built, something that's prescriptive. So an example of an essential function is the function is to provide a service for vehicle traffic. So a map example for that is where does that essential function get codified in the project documentation? It's usually in the project scope statement. So that is the scope of the project. So a performance requirement related to that is that the surface that's provided for vehicular traffic, be safe, smooth, durable and cost effective. In this case it's a pavement facility. And where does that get translated into the project documentation? The specific contract document where that lives is in the P3 agreement, the technical provision section. The associated performance criteria for that, for a safe, smooth and durable cost effective pavement could be and this is just an example, could maintain a smoothness value or in this case the international roughness index value of less than 160 inches per mile. And the contract document that codifies that is it's the P3 agreement evaluation plan. So that is the performance criteria for that particular pavement section which has a function to deliver a surface for vehicular traffic. The performance specification then that's drawn from that this is a construction specification. It says to meet that objective of an IRI of 160 inches per mile or less over the duration of the service of that pavement structure, you have to build it within IRI less than 65 inches per mile, using a tenth of a mile base length averages. And that gets into-- in this case, we are saying it gets into the P3 partner's plans and specifications. A lot of times, that may or may not be the case. It could be a prescriptive requirement by the agency. But you can see how the performance requirement is actually translated into something that's concrete. That control of where that should live, whether it should be into the P3 partners PS&E or whether it's a requirement in the RFP that's up for debate. So the more you put a directive or a prescriptive requirement, you know, the less control the P3 partner would have to deliver that performance requirement. The last one is the prescriptive specification. So in order to meet this safe, smooth, durable, cost effective pavement, we come up with some kind of a design for the pavement. We said, well, it has to be 10 inches of concrete with 550 psi flexible strength. You know, that's the ultimate facility that gets built and that should live in an ideal world and the idea is that it should live in the P3 contractor shop drawing. But a lot of times we all know that this not generally how it goes down either on the design build or even P3 project. We start with the end mind. In other words, we specified, the 10-inch concrete with a 550 flex strength as a prescriptive design requirement. That then essentially means that the owner has retained risk of the performance by providing that specification. As opposed to in the performance requirement driven process of mapping the stakeholder requirement down to the performance requirement and then the performance criteria and then the specification and then coming up with a structure. So we kind of flip the process if you have prescriptive. So whatever we would describe here may or may not meet the ultimate objective of having a pavement smooth pavement. But if that's mandated then you kill some part of the innovation. So that's just an example of that. So the current practice is around the performance requirements in various technical areas. I'm just giving you a general observation based on what we saw. There are some technical areas where an agency is more likely to be flexible in the design requirements. And generally, we have seen more flexibility in geometric design, in work zone management, ancillary asset, drainage or storm water management and landscaping and aesthetics where there is more control provided to a P3 partner to actually come up with a solution and based on a performance requirement. But in technical areas like pavements or bridges and other types of structure elements and materials you see that there's likely to be more prescriptive design detail provided by agencies. So this has been a general observation. And I think the exact reason for this is obviously it's varied reasons. Part of it is that the institutional mindset and accumulated knowledge of how an asset's performance within an agency's jurisdiction is too valuable for agencies to let go of the control in a P3 environment. And there are other overriding things like safety, public safety because the ultimate risk is that aspect of delivery and they will likely retain that. But being prescriptive, again, there is a balanced view to be taken on how much innovation you would want to accommodate and where you want that innovation to occur.
Patrick DeCorla-Souza: All right. I don't see questions. So Jag, you can move on to the next segment.
Jag Mallela: Okay. So how to effectively write performance requirements. So I think the first thing we have to acknowledge is it is difficult to write performance requirements that balance the risk, as I suggested earlier, about letting go of institutional knowledge while at the same time creating an atmosphere of co-innovation, particularly as it applies to design and construction. So there are some in the paper we have outlined some things that you should consider and I'll go over that briefly here. So writing a good performance requirement actually begins in the project scoping phase. In our view, as we mentioned earlier, as I mentioned the degree of influence curve you have the highest degree of influence to introduce innovation scoping things where you're assessing the user and stakeholder needs. And establishing the P3 goals that are on project delivery speed, operation and performance management. So begin with project scoping. We prepared a list of functional requirements, you know, what is it that the agency or the facility should serve? What are the must-haves? What are the exact needs of the facility? And what some of the constraints are around it? Preparing a list of that will actually help guide the writing of the performance requirement. And focusing on project delivery is a good thing. Most good specifications, actually requirements, and focus on delivery side of things, also service delivery. I think both are equally important in a P3. So on the project delivery side we are focused on the target cost, the quality of the facility and schedule outcomes which is important. And equally important is the post construction asset lifecycle and operational performance needs such as lifecycle costs and level of service target. So I think the point we want to make here is that when writing out the requirement the focus should be placed equally on the project delivery side as well as the service delivery side because service delivery outcomes depend heavily on project delivery. And there should be-- the expectation that the service delivery is independent, project delivery or the decisions made during project delivery. As I mentioned the examples I gave about the prescriptive design, it could be an interchange type that you are dealing with or a bridge or a pavement section, what have you, or a ramp. The idea is to deliver service, not just the facility. So the performance requirements aspects should consider both. So identifying performance requirement criteria. So there's a nice flow chart in the paper but here's an example of mapping user requirements or stakeholder requirements with essential functions, performance requirements, performance criteria and design decisions. You know, this is the continuum where we're going from the stakeholder requirements now, performance requirements and design decisions. So in setting the performance requirements the questions we are asking is what is needed to meet the essential functions of the project, of the P3 project? What are the needs? User needs, stakeholder needs? What are the operational goals of this facility? What are the performance management objectives during all of the phases of the projects? And what are the project delivery goals? So there are-- you're making a case for you're trying to answer the questions in terms of what is needed to meet the essential functions. Those are the requirements, essentially. And how they get met, how they achieve those, you know, are what is the performance criteria. So you're coming at it from the other side. And there are multiple technical solutions to meet the requirements through the user criteria. So there's no one way and every project is unique but the exercise is establishing the requirement and then setting criteria has to be a deliberate one and has to be done for each project. So how to achieve it should include a lifecycle perspective, end of term conditions, the hand back, who is bearing the risk of various decisions, the consequence of cost schedule and performance. And the enforcement versus links to the payments. So essentially the monitoring of the performance, you know, over time. So identifying the tie between the performance requirements and criteria is illustrated here and I do have some specific examples of that. So here is one example where we say the goal here, the user requirement is to improve mobility. So that's the user requirement. So the question is you start with what is the requirement? You ask what is needed? So my requirement for this facility is the user requirement is improving mobility. The essential function then from improved mobility is to reduce travel time. So that's the next step. So you map your requirement into the functional requirement which is reduce travel time. The performance requirement from there is to have adequate capacity to carry the vehicular traffic. And then have free turning movements to minimize congestion. So those are the two performance requirements. And then, you know, basically the criteria are the levels of service. The level of service you could establish for capacity, a level of service, LOSC or better, or you could establish the average design speed of greater than 60 MPH. In terms of movement, for the performance requirement of movement, you could have a goal to eliminate left turns or reduce deceleration. So those are your criteria. And then the design decisions after that could be the ways to achieve those criteria that could be based on number of lanes. It could be based on the horizontal cars with certain amounts of radius. It could be based on innovative interchanges and ramps. It could also include right only turn lanes. So as you can see once the requirement is met and that's assessed and is a valid requirement from the user side, and gets mapped to a functional requirement. And from there you set your performance requirement which is around capacity and free turning movement. And on the other end you ask how to achieve that. You know, what are the criteria and how do you achieve those through design decision. So that is the integration between establishing requirements and then driving design decisions. Jumping to a conclusion on the design decision will actually preempt this process and preempt some of the innovative strategies that might emerge on the design side. So here's another example of reducing costs. You know, if the user requirement, the ask is reduce whole lifecycle cost, if that's a requirement then the essential function is harder to achieve. You know, this requires a very integrated thinking across the various project phases from design to operation. The function is functionally and structurally adequate pavement. In this case, let's say it's a pavement. It can be a bridge. It can be any other facility type or ancillary asset. But in this case, let's say it's a pavement. So we want to have, the essential function is to have something that's functionally and structurally adequate. The performance ask or the performance requirement is to have an adequate pavement structure over the service life of this facility. And to, at all times, provide a smooth and safe riding surface. So then you establish your criteria around what is an adequate pavement structure. In this case, we are defining fatigue cracking as being one of the criteria. It could be anything else. It could be rotting. It could be some other types of tracking that you might encounter on pavement. But you set the criteria around that. so that's your technical requirement. And you basically say, we need to have fatigue cracking less than ten percent or rotting less than half an inch. For the smooth and safe riding surface, again, you're specifying an IRI as well as rotting as an objective. So you set your criteria. And then the design decision are then striving to meet those criteria. So you choose an appropriate thickness to meet the criteria. You choose a certain compassion level of asphalt, certain composition of the mix, certain type of day, certain type of drainage, certain type of subgrade, certain type of workmanship process and things of that nature. So again, the idea is you're flowing it from the user requirement all the way to a design decision. That's the integrated thinking that performance requirements can promote if the requirements are written well. Again, not-- if this process is preempted then perhaps you're taking on too much risk or you are not allowing innovation to happen. So again, some other considerations for writing good performance requirements, that they should be an optimal risk allocation between contracting parties, whole lifecycle perspective should be promoted through the uses of performance analysis of what's being designed and built. Need for the evaluating environmental commitments. And that essentially what we are saying is obviously the commitments the that agency makes have to be considered not-- to be careful about the NEPA process and to ensure that there's no cardinal change. But the bottom line is to evaluate it within if anything changes in terms of design exception or variance to make sure that none of that is violated. Enforcement through noncompliance points and disincentives can be encouraged to ensure that proper performance requirements are being met at every stage. And users of performance specifications relate construction quality with performance. Again, one weakness that we have observed in doing this research is the mapping between construction quality and performance requirements around quality and the actual performance outcomes. So there is a lot of confusing terminology out there and this table tries to clear that up by either the use of the words like performance specification, performance requirement, performance based specification, performance related specification. All of this is confusing. What we are talking about here is performance requirements that will help us enable the value-- realize the value of the P3 as a whole. Performance specifications on the other hand, they provide vital links between construction quality characteristics within the construction phase and the ultimate performance of the specific facility after it's post construction and after it's done, after it's built. So the performance specifications are a tool within the performance requirements tool box essentially. You know, on the left-hand side we have very prescriptive specifications. We could have a very prescriptive method based specification for construction quality assurance. And on the extreme right you have the performance related or performance based specifications which basically tried to specify these performance objectives of the post constructed facility without being very prescriptive about the means and methods used. So the performance specifications are applied within the construction realm and the SHRP2 RO7 project by Scott et al has actually done a great job of providing guidance around how to define performance specifications. And there's just the tool within the requirements toolbox. So how do you link construction quality to performance? So, again, coming back to our visual on how to map functional requirements to design criteria. Now, we're going from functional requirements to construction acceptance criteria. So this has now moved away from design phase to the construction phase. So, again, let's start back with the objective. The essential function is to provide pavement surface for vehicular traffic. The performance requirement is the same. The provider is safe, smooth and durable riding surface. The performance criteria in this case provided smooth riding surface let's say are maintain rotting at less than four-tenths of an inch over the life of the project. So those are all within the owner's domain. You know, they are typically defined in the requirement. So the requirement is to have a smooth surface, a safe surface and the criterion is to maintain is to maintain rotting. So if you maintain that then automatically you meet the requirement and hence the essential function. So performance based design-- the design decisions are made. Basically the design decision in this case is to select the bitumen pavement with a performance grade of 70-22. That's a specific type of asphalt to cater to the demand. And also during construction to limit air voids to seven percent. And to ensure that the pavement map has bitumen content of five percent asphalt. So that is within the P3 partner's domain to make those decisions. In an ideal world, they're allowed to make the decision. How is that linked to construction criteria, acceptance criteria? So you could map that in this example where then the criteria for construction acceptance then are to verify that the grade is 70-22 or better. So that can be done in the quality management plan. You could have contractor quality control checks as well as acceptance checks. And then you have your air void, you know, verify that they are within half a percent of the seven percent limit. And that your bitumen content is within a quarter percent of the five percent limit. So those are the construction acceptance criteria. That then will guarantee that the design will perform its intended function of serving-- of providing a safe, smooth and durable riding surface. So all of these decisions are actually taken in an integrated manner. So you can set requirements that advance the integrated thought process through design and construction decisions to meet the ultimate performance outcomes in this manner. So implementing specifications, the performance specifications it depends on the degree of readiness. In some areas, agencies are more mature, like in pavements and work zone management. And bridges and geotechnical there is inherent risk involved. We don't see as much performance specification developed in work there. And so, there is work ongoing in that area. There are some known challenges to specifying performance specifications. First of all, the understanding of factors that influence performance is a key one, the linkage between cause and effect. You know, what in construction can be measured that will guarantee future performance is something that has to be well understood. The robustness of future projections of performance based on construction data is still n nascent field. In some cases, it's more mature than the others. But that's, again, an area of active research. Standardization you know of this process, the repeatability and reproducibility of that mapping is something that has to be worked out and the availability of technology and skill both on the owner and the contractor side are things that are included as time goes on but not yet fully there. So the acceptance of this whole notion of performance specification requires the buy in by multiple stakeholders. And as I mentioned, again, the SHRP2 RO7 provides some great guidance on how to include performance specifications on all types of project delivery, projects including design better projects. So I think that would be a good start. But you can see how performance specifications can be forwarded into a performance requirement vision [ph?].
Patrick DeCorla-Souza: All right. I still don't see any questions. Oh, one just showed up. Hold on. So let's see Matt Z. asks how does the owner enforce things like rotting performance criteria after the contract has been closed?
Jag Mallela: So I think the key is in what we are trying to promote here is that the riding criterion, for example, if you go back to the slide I just showed, the riding criterion, maintaining writing of less than four-tenths of an inch is related to things that you can control in construction. So essentially if you know that the contractor has used the right type of binder, has contracted the right requirements and has provided adequate asphalt the idea is that the post construction performance will be guaranteed through those decisions. Now, post construction certainly in the O&M phase, typically there are requirements on frequent measurement of the service, of the facility, you know, how well it is doing in the service condition and riding could be measured and could be included as part of that. But the idea is that you don't need this in a performance requirement world where you tie all of the decisions together. So you make deliberate design decisions, material selection decisions and construction acceptance decisions to mitigate as much as possible surprises after the contract has closed.
Patrick DeCorla-Souza: All right. I don't see any more questions right now. So why don't we just do the next segment which is alternative technical concept then we'll wrap up. Okay. We are running short on time.
Jag Mallela: All right. Well, thanks, Patrick. So I think the next concept here is because we understand performance requirements are not easy to write hopefully the paper that we wrote gives you a good start. But in the interim, there are lots of things that are being done today that will support the idea of introducing design and construction innovation in P3 projects. And one of them is the alternative technical concepts here. The ATC can be used as an intermediate step to foster innovation. They're a contract tool to attract innovation and alternative ideas. And based on what we saw earlier in the polling, people are using them as alternative design concepts. So that is actually a great way to promote innovation and to encourage the use of ATCs mostly using that value selection. Certainly, very amenable for the P3 meaning the P3 project delivery approach can use ATCs and have-- and many P3s have used ATCs. They are proven and time tested. There's risk transfer that happens to the P3 partner. So there is a rare need for using ATCs when using the performance requirements. But the idea here is to promote innovation through the use of ATCs until such time that agencies are comfortable writing performance requirements. And obviously ATCs, the general rule of an ATC apply whether it's a P3 contact or design bid build contract. It must generate a cost schedule or lifecycle benefit. The deviation from the RFP requirements and agency standards are generally the subject of ATCs and the cardinal change doctrine applies that certain parts of the scope cannot be changed in terms of an ATC. So, again, interpreting equal or better clause is always the main deal in ATCs. ATCs are required to be equal or better to the agency's baseline design, or the baseline concept. So I think that applies. And it's probably the most critical part of the success of the ATC. So Patrick, you wanted me to…
Patrick DeCorla-Souza: Yeah, so why don't you must move on and very quickly go through this. Most, I just want to encourage folks to read the paper what we have in the next few slides are simply a summary of what's in the paper. We are going to go through this very fast in order to catch up.
Jag Mallela: Yeah, but really the consideration in the next few slides are how to implement performance requirements. So I think I'll hit the highlights so really you won't lose anything because of speed here. But the bottom line is in terms of implementation consideration performance requirements are changing the way agencies think today currently as we understand the state of play. So drafting performance requirements it requires change management and organizational change, some kind of a culture change is required to tune a mindset to getting into the performance requirements domain. It requires interdisciplinary teams that are traditionally not done. But in more P3s it is coming together to have interdisciplinary teams to draft those requirements. Link performance standards to the proposal evaluation criteria, determine methodology and frequency monitoring, you know, where and which part of the project days will we monitor the requirements. And consider future changes in service requirements and end-of-term considerations in drafting those requirements. So it is a difficult process to anticipate some of this. Allow sufficient time for drafting these requirements. Sometimes we are time constrained and that's a major concern but this requires some thought. And in some cases, agencies have used a procurement specialist and independent advisors to think through the linkages between the various siloes that are mentioned up there. So it does require organizational culture change in terms of new skills required and new perspectives to be brought on. There's a potential role of an independent engineer to share the benefits of duty of care. So there is a new role there being suggested in the paper. And it requires performance based decision-making to let go some of the control that is generally exerted in the design and construction phase to bring in some innovation. Long-term performance data is foundational because to understand performance and its linkages to design and construction decisions, in particular. There is officially a parallel study that is actually trying to get some answers in terms of long-term performance study that will probably be a subject of a webinar very soon that Patrick might mention. The asset management mindset is a critical part of performance requirement driven practices. And in terms of the best practices, there's capacity building and knowledge management involving multidisciplinary trains, robust contract administration and better enforcement mechanisms have actually paid dividends in agencies on projects that have used performance requirements. Legal perspectives is an angle that should not be ignored. You know, the Spearin Doctrine often cited on who is responsible for defects in the plan, design or specifications. This goes back to the risks transfer between the P3 partner and agencies, performance requirements are an effective way to transfer risk to the party that's best able to handle it. So the basic principles of the Spearin Doctrine apply performance requirements. There's a lot of legal cases around that in terms of how to draft a good performance requirement, focus not on words like design and performance but evaluate where you're outcome based or instructed in inviting the requirement. Differing site conditions is a challenge. The order of precedence in terms of dispute when a technical support is directly incorporated in the P3 agreement. Brand name or equal clause. You know, just because a requirement mentions a brand name doesn't make it prescriptive or directive. It can be treated as a performance requirement as long as there are reasonable number of vendors. So there are some legal challenges in the world of performance requirements. But the Spearin Doctrine is generally a good one to follow as far as spirit of what performance requirements actually means. So I think that was my last slide there, Patrick.
Patrick DeCorla-Souza: Yes. And there's one more question actually two questions. But let's take the second one first, how would an agency go about checking on whether the performance criteria were met?
Jag Mallela: So that is where the enforcement comes in. So there should be in the quality management plan, for example, in construction specification. So you would establish a plan to measure and monitor the outcome at each phase. So there is a design quality management plan that we recommend and also a construction quality management plan. So the plan should outline the enforcement points.
Patrick DeCorla-Souza: The second question is any idea on how much effort and time is needed to help design effective performance criteria?
Jag Mallela: That's a good question. And obviously, the answer is varied, but in my experience it's a process that involves the-- and I'm very familiar with the independent advisor model especially for agencies that are starting for the first time in the P3 realm. It starts in the project pre-procurement stage where they hire procurement specialists. It's a few months generally involved in drafting a set of performance requirements depending on the project complexity. But it is an involved effort.
Patrick DeCorla-Souza: All right. Thanks, Jag. And let's move on. I just want to wrap up here and invite folks to register for our next webinar which is next Thursday, February 16. And I also want to alert you to the wealth of information we have, additional papers, guides, primers, et cetera, all available on our website. And here's the contact information for Jag, my contact information here. Now, I guess, you know, getting the evaluation form up, if there are any questions for Jag over the phone, I see there is one right now in the chat box. Does the NEPA process need to outline the performance requirements? Jag, it said over the entire lifecycle of the infrastructure asset.
Jag Mallela: Does the NEPA process require it? No.
Patrick DeCorla-Souza: Yeah, does the NEPA process need to outline the performance requirements intended over the entire lifecycle of the infrastructure asset?
Jag Mallela: Not currently as I understand it. No, it does not have a requirement like that.
Patrick DeCorla-Souza: Okay. Thank you. All right. So I see we are at three o'clock and I just want to thank Jag for his presentation. I want to thank our operator, Debbie, and staff from the Volpe Center, Jordan Wainer. And, of course, all of you for your questions and attending this webinar. And I look forward to seeing you next Thursday. So with that, thank you and goodbye.
Operator: Ladies and gentlemen, thank you for your participation. This does conclude today's conference. You may now disconnect.
