National Academies Press: OpenBook

Guidelines for Implementing Managed Lanes (2016)

Chapter: Chapter 5 - Implementation and Deployment

« Previous: Chapter 4 - Traffic Control Devices
Page 95
Suggested Citation:"Chapter 5 - Implementation and Deployment." National Academies of Sciences, Engineering, and Medicine. 2016. Guidelines for Implementing Managed Lanes. Washington, DC: The National Academies Press. doi: 10.17226/23660.
×
Page 95
Page 96
Suggested Citation:"Chapter 5 - Implementation and Deployment." National Academies of Sciences, Engineering, and Medicine. 2016. Guidelines for Implementing Managed Lanes. Washington, DC: The National Academies Press. doi: 10.17226/23660.
×
Page 96
Page 97
Suggested Citation:"Chapter 5 - Implementation and Deployment." National Academies of Sciences, Engineering, and Medicine. 2016. Guidelines for Implementing Managed Lanes. Washington, DC: The National Academies Press. doi: 10.17226/23660.
×
Page 97
Page 98
Suggested Citation:"Chapter 5 - Implementation and Deployment." National Academies of Sciences, Engineering, and Medicine. 2016. Guidelines for Implementing Managed Lanes. Washington, DC: The National Academies Press. doi: 10.17226/23660.
×
Page 98
Page 99
Suggested Citation:"Chapter 5 - Implementation and Deployment." National Academies of Sciences, Engineering, and Medicine. 2016. Guidelines for Implementing Managed Lanes. Washington, DC: The National Academies Press. doi: 10.17226/23660.
×
Page 99
Page 100
Suggested Citation:"Chapter 5 - Implementation and Deployment." National Academies of Sciences, Engineering, and Medicine. 2016. Guidelines for Implementing Managed Lanes. Washington, DC: The National Academies Press. doi: 10.17226/23660.
×
Page 100
Page 101
Suggested Citation:"Chapter 5 - Implementation and Deployment." National Academies of Sciences, Engineering, and Medicine. 2016. Guidelines for Implementing Managed Lanes. Washington, DC: The National Academies Press. doi: 10.17226/23660.
×
Page 101
Page 102
Suggested Citation:"Chapter 5 - Implementation and Deployment." National Academies of Sciences, Engineering, and Medicine. 2016. Guidelines for Implementing Managed Lanes. Washington, DC: The National Academies Press. doi: 10.17226/23660.
×
Page 102
Page 103
Suggested Citation:"Chapter 5 - Implementation and Deployment." National Academies of Sciences, Engineering, and Medicine. 2016. Guidelines for Implementing Managed Lanes. Washington, DC: The National Academies Press. doi: 10.17226/23660.
×
Page 103
Page 104
Suggested Citation:"Chapter 5 - Implementation and Deployment." National Academies of Sciences, Engineering, and Medicine. 2016. Guidelines for Implementing Managed Lanes. Washington, DC: The National Academies Press. doi: 10.17226/23660.
×
Page 104

Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

95 Implementation and Deployment While the beginning of project implementation may occur once planning is underway, this chapter defines implemen- tation and deployment as beginning once the project plan and environmental document are approved. Implementing a managed lane project requires a rigorous dialogue between staff involved in design, operations, and construction. Increas- ingly, toll collection and active traffic management systems integration requires installation and construction services from a diverse array of specialists who may be unfamiliar to traditional roadway contractors. System-level planning and coordination is key to maximizing efficiencies and ensuring integration between systems where needed. This chapter out- lines the various steps toward implementing and, ultimately, opening a managed lane facility. Design Review Within the context of project implementation, the con- cept of design review incorporates principles identified in the systems engineering process. Designing and constructing managed lanes involves multiple disciplines, including soft- ware development, high-sensitivity electronic equipment and technology, as well as civil and structural engineering. The design review process ensures that the specifications for these systems are incorporated, reflect the common requirements of established systems such as the National Intelligent Trans- portation Systems (ITS) Architecture (a common framework for planning, defining, and integrating ITS deployments), and identify appropriate interdependencies. Furthermore, the design review process highlights issues or concerns before committing to deployment, with the allowance for changes to each subsystem. Importance of Design Review The development of a managed lane project involves com- plex systems installed by disconnected entities. For example, pavement and bridge structures in managed lanes may be constructed by the civil contractor, but the installation of toll collection equipment is the responsibility of the toll collec- tion systems integrator. Often, these functions come together at points of demarcation in the field between the integrator and the contractor responsible for overall lane construction. For example, the contractor installs power to a common access utility panel, and then the integrator is responsible for pulling power from this utility panel to the toll collection equipment in the field. Similarly, the contractor is responsible for placing the systems utility cabinet on a concrete pad with a number of appropriate conduits, and then the integrator is respon- sible for pulling wire and making appropriate connections within the cabinet to the toll collection equipment. As such, it is useful within the design review process to highlight these points of demarcation and to identify any gaps or overlaps in separate contracts regarding the responsibility and fulfillment of these dependencies. It is essential that the requirements of the systems be reflected in the final design specifications because these specifications remain the only consolidated document from which the managed lane systems are constructed. The Priced Managed Lane Guide, in particular, notes “priced managed lanes often require complex design solutions and the need to consider exceptions to design standards, because they are often built in constrained highway corridors with right-of-way constraints and require the installation of ETC equipment and enforce- ment locations” (2). As with most components of systems engineering, identifying challenges, risks, shortcomings, and issues early in implementation is critical to cost containment, making the design review process valuable and effective. Configuration Management for Design Review Within the realm of ITS, for which toll collection and managed lane systems are highly correlated, the U.S. DOT C h a p t e r 5

96 has encouraged the concept of configuration management for the design review process. According to the Electronics Industries Alliance/American National Standards Institute’s publication on configuration management as a national stan- dard, “Configuration management, applied over the life cycle of a system, provides visibility and control of its performance, functional, and physical attributes. Configuration management verifies that a system performs as intended, and is identified and documented in sufficient detail to support its projected life cycle” (ANSI/EIA 649-B-2011). Within this concept, the sponsor agency has primary respon- sibility for tracking individual configuration items within the design plans, controlling changes from the design to accom- modate field realities, and accounting for configuration items so that multiple disciplines have current access to applicable components of the design (102). The configuration management process, as referenced, is designed to enhance the understanding of those disciplines affil- iated with the interconnected systems (ANSI/EIA 649-B-2011). The outcome of the design review process is to advance the facility designs through increasing levels of detail, with con- fidence that critical points of overlap and dependency have been resolved. For managed lanes and affiliated ITS and toll collection systems, the design review is completed separately for conceptual, preliminary, and final design. The final design typically involves advanced levels of testing to ensure the sys- tem will function properly before the toll collection systems integrator procures equipment and completes the development. As such, the design review is a positive affirmative process—the system design, by default, is not deemed ready for deployment until the review affirms the readiness of the system. The design review will permit agency and contractor staff within each review function the opportunity to propose a design change in order to enhance the effectiveness and delivery of the managed lanes system. Often, changes will be proposed to reduce costs, meet scheduling requirements, or fulfill base requirements of interconnected systems. However, changes may also be proposed to reflect new technologies or procedures that have been developed since the initial design and offer an opportunity for the implementing agency to enhance the longevity and efficiency of the system. Regardless, when a proposed change is offered, it should be accompanied by an assessment of overall impact to the system as a whole— including costs, scheduling, and other effects upon connected systems. Scheduling, Installation, Testing, and System Acceptance Within the context of project implementation, there are four key phases critical for success of the project: scheduling, installation, testing, and system acceptance. • The project schedule defines the time frame for comple- tion of the project and achievement of milestones, and it is used to monitor progress and denote changes that occur during design and construction. The project schedule iden- tifies tasks, links the tasks in logical sequence, and allows for close coordination of various contractors throughout different phases of the project. The schedule defines key milestones and provides a plan through which resources can be assigned. Additionally, the schedule is used for track- ing progress on individual tasks and identifying schedule risks. Installation is the culmination of the development and design phases. • Installation requires close coordination between various contractors and a focus on safety for the team and for the traveling public. • Testing for system implementation typically includes a series of tests to verify that project requirements are met. Testing occurs at various points in the deployment pro- cess, including environmental analysis, factory acceptance, inspections, installation, integration, and final acceptance. • The key point of delivery is the final system acceptance. At final system acceptance, coming at the conclusion of the implementation stage and when the project enters revenue service and operations, the installer has provided as-built configuration documentation and drawings, training plans, licenses, and maintenance manuals. Final system acceptance typically occurs between 2 and 6 months after the system opens to revenue service, as minor adjustments to the sys- tem to respond to field service need to be worked out and officially accepted. The installation and testing phases of a project start after final design and continue through to the operations and mainte- nance phases of the project. The flow of installation and testing is shown in the systems engineering V diagram (see Figure 88) from the FHWA Systems Engineering for Intelligent Transporta- tion Systems handbook (103). Scheduling The critical path method of scheduling allows for effec- tive management of the overall project and helps protect the project against schedule and budgetary slippage. For the schedule to be used effectively to manage a project, the sched- ule must be kept current with accurate status updates. Man- aging multiple schedules presents challenges because key milestones between various contractors and subcontractors are not always linked, and a slip in one contract does not nec- essarily show the impact to the other schedules. Field work often requires that changes be made in the schedule due to unexpected field conditions, weather delays, tasks taking longer than scheduled, or required rework. As such, schedule

97 dependencies should be known at the beginning of the project, such that slippages in one schedule automatically propagate to all dependent subsystems. Installation Prior to the start of field installation, a detailed installation plan is required. The installation plan specifies the sequence and schedule for the installation of the entire system. The installation plan typically includes a detailed schedule of activi- ties, specific safety requirements, and contact information for staff. A description of possible phasing of deployment is also included in the installation plan. The installation must comply with applicable standards and building codes. For a successful installation, the toll system integrator must understand the unique characteristics of the job site. These range from environmental considerations, traffic-related main- tenance, specific work hours, and overall project safety require- ments. When incorporating a toll system, there is usually a defined turnover process from the civil contractor to the toll system integrator to be able to install toll collection equip- ment. For the turnover process to be smooth, the implement- ing agency must have clearly defined milestones, including inspections, tests, and minimum requirements. Ideally, the civil infrastructure work on the facility would be completed prior to the transfer to the integrator, but more frequently, incremental turnover of sites requires careful coordination. Often finishing work such as striping, closing out punch list items, and removing barriers may not be done until after the turnover of the site to the integrator. Testing Since installation of tolling functions is substantively differ- ent from civil construction, the testing plan becomes the critical step in the integration process, and thus deserves extra atten- tion. Testing is used to verify that the contract requirements are met. Typically, a requirements trace matrix is developed early in the project to ensure that user needs and concepts are addressed by a set of project requirements. The requirements are then used throughout the design and development phase to ensure that the system will meet the defined requirements. The system integrator develops test plans and procedures and then completes applicable tests to demonstrate that all fur- nished and installed equipment, materials, subsystems, and sys- tems function in the manner intended, and that they are in full compliance of performance standards, functional requirements, relevant industry standards, statutory regulations, and relevant codes of practice. The testing program ensures that the system functions according to the requirements and contract perfor- mance standards. The system integrator develops and con- ducts a comprehensive testing program, which includes testing major components and interfaces with related systems. These tests should be conducted as the system is developed, deployed, and operated to ensure compliance with the system and equip- ment functional requirements and performance standards. To minimize risks, the system integrator tests the performance of the system at each phase of system development, deployment, and operation. For every test, the procedures define the entry criteria, pass/fail criteria, and resolution process. Tests should be conducted by the test department or quality assurance depart- ment and not the project engineers or developers. Source: Iteris Inc. (103), Figure 7. This material is based upon work by the Federal Highway Administration. Any opinions, findings, conclusions, or recommendations, and translations thereof, expressed in the FHWA publication are those of that publication’s author(s) and do not necessarily reflect the views of the Federal Highway Administration. Figure 88. Systems engineering process V diagram.

98 Typical stages of testing are as follows: • Test plan: Plan that identifies test modules, functionality, scheduling, durations, equipment, facilities, software bug and deficiency resolution, and staff required for each stage of testing. Scheduling of each test stage should also be reflected in the project schedule. • Unit/device test: A stand-alone test to verify that individual components meet the requirements of the project. Burn-in tests are often conducted as stand-alone tests for hardware sufficiency. • Factory acceptance test: Subsystem verification test to demonstrate that the system components function per the design in an off-site environment in advance of field installation. • System-to-system interfaces tests: Separate tests to demon- strate the functionality and performance of any system-to- system interfaces. • Installation test: Testing performed for each installation to verify that the equipment has been installed and con- figured correctly. An installation checklist will be used to verify installation, and the installation test will verify basic functionality of the equipment. • Commissioning test/system verification and deployment: Testing to demonstrate that the entire system, equipment, and facilities are ready for commencement of operations. Testing includes hardware, software, and equipment. Test- ing demonstrates aspects of system operations and services from transactions through account reconciliation. • System acceptance testing: Final system validation test- ing to demonstrate that the system is fully meeting con- tract requirements, as well as performance requirements in operations, including a minimum number of days of actual operational testing following resolution of deficiencies (defined in the following paragraph). • Annual system performance testing: Testing to demon- strate ongoing system reliability, service, and performance levels. As part of ongoing operations, annual system per- formance testing is often scheduled to begin on the anni- versary date of opening for revenue collection. A deficiency is defined as a failed test result or missing func- tionality when compared with the system design or functions of the system. Once resolutions to deficiencies have been identified, appropriate testing is needed to confirm that the deficiency has been corrected and that no new bugs were intro- duced into the system. Deficiencies can be considered for any situation that causes the following: • Cessation of operations for any major service or operation or that results in the loss of revenue, inability to display toll rates to drivers, inability to process transactions, or inability to operate the facility. • Impedance of operations, but not such that it causes major services or operations to cease or results in a loss of revenue. • Hindrance to operations that is minor or administrative in nature and does not result in a loss of revenue or traffic performance. System Acceptance Final acceptance concludes the design and deployment phase of the project, often after the project enters the operational phase and required phasing, adjustments, and other tasks are completed before turnover. Final acceptance is deemed to have occurred when the following conditions have been met: • Successful completion and approval of the system accep- tance test. • Delivery by the system integrator and approval of all deliverables, including as-built documentation/drawings. • Satisfactory completion and approval of required activities and implementation items. • Verification of requirements identified in the system require- ments document. • Satisfactory fulfillment of the system integrator’s other contractual obligations. Toll Collection System Development, Deployment, and Phasing Considerations Toll collection system design includes the selection of off- the-shelf hardware such as cameras and computer servers and the development of custom software for the managed lane systems and the back office. The toll collection system vendor is also responsible for the integration of hardware, software, and subsystems to meet the contract requirements. The deployment of the managed lanes project is influenced by many factors, such as physical facility availability, staffing constraints, system development, legislation, funding, mar- keting, and stakeholder coordination. Often, a combination of factors results in the need for the project to open on a spe- cific date or under a specific set of conditions. The earlier the final opening date is agreed upon, the easier it is to develop a deployment schedule and determine any possible phasing that is needed. During this phase of the project, the system becomes more tangible to the traveling public; signs and gantries are installed and the final pavement striping is completed. The toll collec- tion system is installed, with cameras, antennas, and pricing signs being the most visible features. This is the final phase to fine-tune the system, complete staff training, test the per- formance of the integrated system, and plan for the ribbon- cutting ceremony.

99 Development The development process for toll collection systems is simi- lar to the development of other large transportation systems. System engineering processes are used to guide the develop- ment from concept of operations, through design, installation, and testing, to final deployment (Figure 88). Some features of the toll collection system are universal to all projects; others are quite specialized for the individual project. As with any large design project, the risk is minimized by maximizing the use of proven designs and minimizing the development of new software. As an illustration of the various steps in the systems engineering process, Table 9 provides the typical methodology for software development of toll collection systems. For most managed lane systems, the vendor modifies an existing design instead of building up an entirely new sys- tem from scratch. This allows the vendor to compress the development schedule, reduce risk, and lower the overall cost of the system. The development phase is an iterative process with multiple internal peer reviews and unit tests occurring throughout development to optimize the system. Deployment After the system is developed, integrated, and tested, it is ready to be deployed on site. System deployment may take several weeks to several months to complete depending on the complexity of the system and the number of toll collection sites. A deployment plan is often required to ensure a smooth transition to operations. The plan needs to address staffing, training, scheduling, testing, contractor coordination, con- figuration management, and any required phasing. Deployment in the field is often complicated by other con- tractors working in the vicinity. The toll system integrator must cooperate fully with other contractors working on or near the facility; agencies can provide a framework for this coordination and cooperation through scheduling require- ments in the contracting phase. Coordination between mul- tiple contractors must include safety, scheduling of work, maintenance of traffic, and repair responsibility if anything is damaged during the construction. The work must be sched- uled without hindering or interfering with the progress or completion of work being performed by other contractors, entities, or agencies. Task Activities Review Scope of Work • Review business rules. • Review functional needs of project. • Discuss expectations with client. • Ensure compatibility with existing systems. Develop Requirements • List specified functional and performance requirements called out in scope of work. • List derived requirements from scope of work. • List any additional requirements from contract. Perform Gap Analysis • Review existing system against requirements to determine gaps. • Identify new functionality that is required. • Identify any changes that are needed to meet performance requirements. Complete Preliminary Design • Conduct initial high-level system design. • Determine quantity of equipment required. • Complete high-level architecture design. • Develop initial communication layout. • Produce software design. Complete Final Design • Finalize selection of hardware makes and models. • Finalize communication network. • Finalize power calculations and define utility requirements. • Develop interface control documents. • Conclude software design, including processes and redundancies required. Develop Software • Develop new software as required. • Modify existing software to meet contract requirements. • Complete unit test of code by all developers as they finish modules. • Maintain configuration management. Integrate System • Integrate new and upgraded software modules. • Integrate toll collection subsystems with selected hardware. Perform Tests • Test modules, subsystems, and fully integrated toll system. Deploy System • Perform on-site installation. • Test connectivity and continuity. • Configure and tune the system. • Test the system. Table 9. Primary tasks for the development of a toll collection system.

100 If the system is replacing an existing toll collection system, migrating data and transitioning to the new system need to be included in the deployment plan. Most toll collection systems use the deployment phase as an opportunity to have the system up and running for an extended period of time before going into revenue operations. Staff can be trained on the real system, sample reports can be run, and bugs can be identified and fixed prior to official testing. This phase also allows burn-in of the hardware so any defective items can be replaced prior to operation. Many issues surface when the sys- tem is operating in the real-world environment for an extended period of time. Once the system is fully deployed, tested, and accepted, it moves into the operations and maintenance phase. Phasing There are many different phasing considerations for deploy- ment of large, complex toll collection systems. Some consid- erations may be policy driven, like when the tolls are in effect and whether they begin as fixed or dynamic tolls. Sometimes the physical infrastructure availability requires the toll system to be installed and opened in phases, and the developer may be confronted with a less than fully robust operation. These considerations need design interaction with the rest of the development team so that the system can meet functional requirements through each successive opening. Considerations need to include: • Messages to the customer through successive changes as the project opens. • Strategies for pricing for the near term and longer term. • Rules for traffic safety and associated items posted on signs that may change as the project expands. • Protocols for enforcement. • Considerations for maintenance, such as access to field equipment. • Considerations for design of any interim operating con- ditions such as access and separation treatment. • Plans for future segments or corridors on the system, often addressed in a system-wide Concept of Operations. Some toll collection systems choose to open with a simpler system (e.g., a single toll zone employing an off-the-shelf tech- nology) and then add complexity (e.g., multiprotocol readers and zones) later as the need arises. Upgrades and Expansions Toll system technology is constantly changing and improv- ing. New camera technology is released every year that greatly improves the capture of license plate images, and computers are faster and have more memory. Due to the MAP-21 federal legislation and its requirement for national interoperability, more facilities are upgrading their systems to correctly read transponders issued from other states and local jurisdictions. The design life for most toll systems is stated to be a minimum of 10 years, but system technology upgrades and enhance- ments are typically done every few years to keep the systems working at optimum performance levels. Expansions to sys- tems are done as new facilities are opened for toll collection or existing corridors are extended. The initial design needs to be flexible in order to take into account the anticipated expansions and often short life cycles of equipment. During the operations and maintenance phase of a proj- ect, changes to the system range from small simple changes (e.g., altering the format of a report) to significant changes of entire modules (e.g., replacement of the violation enforce- ment system). The standard system engineering process is for upgrades and expansions to the system. Cost–benefit analysis is typically done to determine which updates provide the most benefit for the cost and to help determine the sequence of the upgrades. Design reviews are done and a transition plan may be needed to deploy the new feature. Revised standard oper- ating plans, training documents, maintenance manuals, and as-built plans are typically required for substantial changes. Testing is always needed for a new release of software or a hardware upgrade to ensure that the system meets the new requirements. Often, changes are done when an extension to the existing facility is added or a new corridor is being incorporated into the system. Changes are often required to accommodate the new facilities, and additional upgrades should be incorporated in the most efficient manner. Project Delivery Project delivery for managed lane systems inevitably involves procurement—from planning and design through civil con- struction and toll integration. In delivering projects, a variety of procurement options are available to agencies looking to implement managed lanes. Many contemporary approaches to procurement involve varying aspects of partnership with private-sector entities, including integrated design and con- struction as well as investment risk. In particular, public– private partnership (P3) and public–public arrangements have increasingly been utilized in managed lane projects, including various facets of design, delivery, financing/funding, operation, and maintenance. At its core, there are three separate and distinct work ele- ments to the deployment of any managed lanes project: (a) civil construction, (b) toll system integration, and (c) tolling opera- tions and maintenance. These three components can be separated or combined in various forms. For example, civil construction could occur

101 under a design–bid–build structure, design–build structure, or other delivery functions. Similarly, system integration and tolling operations and maintenance can also be combined into the civil delivery contract, resembling a P3 approach. Con- versely, the toll system elements (integration and operations/ maintenance) could be combined under one contract, followed by a separate design–build contract to construct the civil portions of the project. As revealed by practitioners in the course of study, con- sideration should be made for scheduling the procurement of toll system integration either before or concurrent with civil procurement. The primary advantage for releasing the tech- nical requirements for toll system integration in advance of the civil requirements is that the incorporation of toll system components can be better reflected in the overall civil con- struction schedule, as discussed previously. For example, in California, the toll system integration procurement precedes the civil procurement by a few months. Importance of Project Delivery Initial managed lane projects in the United States were procured by individual state or regional agencies to imple- ment a discrete facility on one corridor or corridor segment. With the exception of SR-91 in Orange County, California, and I-495 in Northern Virginia, the facilities in operation by the end of 2013 involved utilization of pre-existing HOV lanes, which is common for retrofit settings. Between 2013 and 2015, however, many more facilities were constructed in corridors lacking pre-existing HOV lanes, such as the North Tarrant Express, DFW Connector, and Loop 375 Express Lanes in Texas; US-36 and I-70 in Colorado; I-95 in Maryland; and I-595 in Fort Lauderdale. The HOV conversions permitted the implementing agency to procure only those deployment components required for converting the HOV lanes into variable priced managed lanes. This limited exposure to risk yielded a preference toward traditional procurement methods. However, over the last decade, two new models for delivering managed lanes, espe- cially those with new construction, emerged nationally. The first—the use of public–public arrangements to implement a priced managed lane that spans multiple public entities— creates opportunities to spread risk between agencies but also adds layers of decision-making complication. Some of these arrangements are informal; others became formalized through multi- and interagency agreements, or, in states such as California, joint powers authorities were created by public– public arrangements to facilitate implementation across multiple jurisdictional boundaries. The second model involves an increasing use of P3 to embark upon large, mega-scale projects (i.e., typically valued at $300 million or more) affecting a range of transportation improvements that could not be afforded through traditional procurement methods. This tendency toward P3 also exists on smaller projects. In 2011, Los Angeles County Metropolitan Transportation Authority employed the design–build–operate– maintain method for delivering the I-10 and I-110 express lanes in Los Angeles County, and, in 2013, the Colorado High Performance Transportation Enterprise used both a design–build contract and a design–build–finance–operate– maintain contract for delivering the US-36 managed lanes. Research from the Second Strategic Highway Research Pro- gram indicated that “the average construction value of over $1.6 billion . . . represents a marked departure from earlier P3 activity” (104). Project Delivery Options Project delivery was discussed briefly in Chapter 2 because agencies will begin to look at different options for delivering priced managed lanes from an early point. Delivery options within the implementation and deployment phase will dif- fer significantly, and planning-level decisions may warrant reconsideration as the project procurement begins, with dif- ferent delivery options for various components. For example, an agency may wish to use a traditional design–bid–build procurement for civil construction, but a design–build– operate–maintain delivery for toll systems. This delineation is addressed here. There are four primary project delivery options, ranging from traditional design–bid–build, through design–build (where design and construction services are grouped into a single, fixed-price procurement) and design–build–operate–maintain, to private-sector concessions (where a private investor/operator is responsible for financing, designing, constructing, operating, and maintaining new toll highway projects). As discussed pre- viously, these delivery options can span the various core tasks of civil construction, toll system integration, or toll system operations and maintenance. Following are descriptions of the four primary procure- ment options for managed lanes: • Design–Bid–Build (DBB). DBB is generally perceived as the standard procedure for procuring a highway project. In this process, the agency (either internally or through contracted staff) fully completes the design of a facility. Subsequent to completion of the design, the agency then awards a new construction and installation contract to one or more contractors. Upon completion, the agency has full responsibility for the operations and maintenance of the project. As the agency completes the design, it warrants the quality of the design documentation, and it is liable for remedy/mitigation if issues emerge that prevent the con- struction and installation contractors to complete their scope

102 of work. As a result, the agency assumes the risks of errors or omissions within the final design documentation (105). With existing HOV lanes being converted to priced managed lanes, design–bid–build has been sufficient for most agency projects where risk and schedule are lesser considerations. • Design–Build (DB). Whereas DBB uses separate contracts and procurements to develop a managed lane project, DB combines both design and construction functions into one fixed-fee contract (106). The contractor, which typically involves a joint venture for legal liability purposes, assumes the risk of design and construction for the contractual compensation. The agency, in turn, assumes the responsi- bility of providing definitive metrics by which the design and construction will be evaluated and accepted under the contract agreement. The responsibility of financing, oper- ating, and maintaining remains with the agency, but the contractor assumes risk for construction cost and schedule, making this a preferred method for complex projects. Whereas HOV conversions to priced managed lanes are well suited to DBB, DB is increasingly attractive for new lane construction. Recent projects using DB for managed lanes include US-36 in Colorado, I-35E in Minnesota, and I-405 in Washington. • Design–Build–Operate–Maintain (DBOM). DBOM extends the DB model to include an operations and maintenance component over the life of the contract. Although financ- ing remains in the purview of the public agency, the fixed- fee contract reduces the risk of maintaining the system over time. According to a Second Strategic Highway Research Pro- gram report on P3, “The advantage of DBOM procurements is that by combining these services, the private partner has an incentive to use cost-saving, life-cycle costing principles to align the design of the project with long-term mainte- nance activities” (104). As an example, the Los Angeles I-10 and I-110 express lanes were procured using a DBOM structure. • Design–Build–Finance–Operate–Maintain (DBFOM). DBFOM, often called a concession agreement, involves transferring the responsibility for design, construction, finance, operations, and maintenance of a managed lanes facility to a private-sector partner for a period of between 25 to 50 years. Typically, the agreement is written such that the private-sector partner has the right to collect revenue from tolls. Alternatively, the agency may elect to withhold the right to the toll revenue and instead make availabil- ity payments during the life of the concession agreement, whereby the concessionaire is compensated for design, construction, operations, and/or maintenance milestones or performance achievement. Availability payments may be used for toll facilities that may have a greater risk of revenue generation than fully private-sector concessions would allow (104, 107). In either case, future revenues raised by tolls and other project sources are dedicated toward the repayment of bonds and other affiliated costs, including loans from TIFIA or private activity bonds. The private partners, as a component of the concession, invest their own equity into the project. Upon financial close, the con- cessionaire then enters into a fixed-priced DB contract to construct the project and a separate operate–maintain con- tract to collect tolls and maintain the project, often with subsidiaries to the concessionaire. The 91 Express Lanes on SR-91 in Orange County, Cali- fornia, is an example of a project that was originally pro- cured by Caltrans as a DBFOM project. It was purchased from the California Private Transportation Corporation, the concessionaire for the project, by the Orange County Transportation Authority, a regional public agency, in 2004. Additional DBFOM projects operational in 2015 that involve revenue risk to the concessionaire include the I-635 LBJ Express Lanes in Dallas, Texas; the North Tarrant Express in Ft. Worth, Texas; the US-36 Express Lanes in Colorado; and the I-95 Express Lanes in Northern Virginia. In con- trast, the I-595 Express Lanes in Ft. Lauderdale, Florida do not involve revenue risk to the concessionaire because the Florida DOT has instead elected to use an availability payment structure. Pros/Cons of Delivery Options The advantages and disadvantages to each of the procure- ment methods identified in the previous section are shown in Table 10. They were adapted from the Construction Manage- ment Association of America’s An Owner’s Guide to Project Delivery Methods (108). Facility Marketing Customers of priced managed lanes will bring similar expectations to their use of the facility as they would for any service-for-cash transaction. Just as businesses have already figured out how to enhance customer experiences in ways that help their bottom lines and ensure happy customers, so too must transportation agencies implementing managed lanes. In essence, there are two phases to the outreach and market- ing plan for managed lanes. The first phase, the education phase, involves project information and concept education and occurs throughout the development and construction schedule. Stakehold- ers and the general public will want detailed information regarding the project, and the outreach program is the primary mechanism for this occurrence. The education phase is addressed more extensively in Chapter 2: Planning Considerations.

103 In the second phase, the sales phase, marketing of the managed lanes addresses how to be a customer of the facility. Marketing in this phase, which begins during construction and continues throughout the life of the project, involves two general themes: initial sales and repeat sales. Initial sales involve the acquisition of equipment and registration, as may be required, to be an eligible customer of the managed lanes, whereas repeat sales concerns marketing use of the facility to meet traffic management and revenue objectives. Importance of Marketing Public acceptance has become the primary issue determin- ing the success of a managed lane implementation (51). To affect acceptance, marketing must be viewed as a vital func- tion for informing the public about the benefits of priced managed lanes as well as how to make informed decisions on their use as a customer. Without a well-thought-out approach to public marketing of the service, the general public may view the pending implementation of a priced managed lane facility with suspicion or disdain because it is a deviation from what is known about transportation investment. Conversely, a properly executed marketing program can enable public support. Building a baseline of understanding and accep- tance through these efforts may facilitate broader support for facility and network expansion, as well as yield feedback on certain components that may prove to be unpopular or particularly well regarded. When the implementation agency enters the sales phase, marketing becomes a critical tool for encouraging corridor travelers to become regular users of the managed lanes and to meet any revenue objectives that may be essential to the project’s success. As described in the FHWA Priced Managed Lane Guide, “Carefully planned and exe- cuted public outreach will help the public to (a) understand how a proposed priced managed lanes facility would work, (b) evaluate the advantages it might offer, (c) accept and use the facility as a new travel option, and (d) encourage travelers to become customers” (2). Marketing Guidance in the Sales Phase Managed lanes may be successful in different ways—such as those measured by traffic operations metrics or revenue goals—but ultimately, the success will depend upon the agency’s ability to encourage drivers to use the facility and manage customer expectations. Since priced managed lane Procurement Pros Cons Design–Bid– Build Widely used in managed lanes delivery. Most common approach to small- scale and/or minimum-risk projects. Agency maintains control over all phases of deployment and operations. Longer schedule required. Constructability issues since cost and schedule impacts are not iterative with design. Liability for design. Requires full funding in place. Least-cost approach may yield higher life-cycle costs. Design–Build Shorter schedule required. Cost efficiencies due to design/construction iteration. Single point of responsibility for design and construction. Less control over design. Requires highly responsive decision making. Greater responsibility for agency to check milestone completion thoroughly. Less practical under joint power arrangements. Requires full funding in place. Design– Build– Operate– Maintain Same as design–build. Additional efficiencies gained in operational sufficiency. Lower anticipated life-cycle costs than DBB least-cost approach. Same as design–build. Requires ongoing responsive decision making. Design– Build– Finance– Operate– Maintain Same as design–build. Provides alternative revenue and funding sources. Fully transfers risk to private sector. No control over design. Requires high level of specificity in functional performance requirements. Proposal and review process is very expensive and time consuming for agency and concessionaire. Greater political risk. High level of expertise in financial and legal specialties is required. Source: Adapted from Construction Management Association of America (108). • • • • • • • • • • • • • • • • • • • • • • • • • • • • • Table 10. Pros and cons of project delivery options.

104 facilities are generally located in the median of existing free- ways, drivers’ choice is one of lane use, not route choice; that is, their decision is whether to use the general-purpose lanes or the managed lanes. To encourage use of the managed lanes, agencies must market their use, and many agencies with oper- ational managed lanes have engaged professional sales and marketing services in parallel with public outreach and edu- cation efforts. This approach is essential to project feasibility if the funding of the lanes is dependent upon toll revenue. Marketing during the sales phase should address common customer-oriented concerns such as how to open an account and obtain an active transponder, how to use the managed lanes, and reasons to use them for differing trip types. These are common issues that will continue over the life of the project. However, there are additional marketing requirements, depending upon the nature of the project. In some cases, the primary marketing effort should be oriented toward encour- aging drivers to use a new facility; in other cases, the mar- keting message may be on different ways to use an existing facility. The latter of these situations is particularly applicable for priced managed lanes that derive from previously existing HOV lanes. For newly constructed lanes that may be dependent upon revenue for the repayment of loans and bonds, the sales effort is designed to increase the number of potential users in order to maximize the traffic management aspect of managed lanes, provide customer satisfaction for use of the lanes, and main- tain a relationship with the customers. To ensure the facility is a success, planners should target the ideal number of users it will take to reach congestion management and/or revenue goals. Underlying these tactics is the need to subtly change the way the public perceives the role of pricing and thus their behavior. Marketing and communications efforts help lay the foundation for acceptance of pricing as it becomes a key method for funding and maintaining large infrastructure projects in the future (2). Two references provide a comprehensive listing of potential marketing activities, strategies, and actions for managed lanes operators. The FHWA Priced Managed Lane Guide devotes a chapter to developing a marketing plan during the sales phase (2). Additionally, the FHWA Office of Operations has created a HOT lanes marketing toolkit, available online only (49). The latter resource provides brochures, videos, and checklists that may be used by any implementing agency.

Next: Chapter 6 - Operations and Maintenance »
Guidelines for Implementing Managed Lanes Get This Book
×
MyNAP members save 10% online.
Login or Register to save!
Download Free PDF

TRB's National Cooperative Highway Research Program (NCHRP) Report 835: Guidelines for Implementing Managed Lanes provides guidance for transportation agencies interested in designing, implementing, operating, and maintaining managed lanes. Guidance includes ways to define initial objectives, outline the necessary decision-making process, and address safety concerns, through the process of detailed design configuration and operation.

The contractor’s final report, NCHRP Web-Only Document 224: Research Supporting the Development of Guidelines for Implementing Managed Lanes, includes detailed background material, gap analysis, design elements, safety performance parameters, and additional related information that emerged through the case studies.

  1. ×

    Welcome to OpenBook!

    You're looking at OpenBook, NAP.edu's online reading room since 1999. Based on feedback from you, our users, we've made some improvements that make it easier than ever to read thousands of publications on our website.

    Do you want to take a quick tour of the OpenBook's features?

    No Thanks Take a Tour »
  2. ×

    Show this book's table of contents, where you can jump to any chapter by name.

    « Back Next »
  3. ×

    ...or use these buttons to go back to the previous chapter or skip to the next one.

    « Back Next »
  4. ×

    Jump up to the previous page or down to the next one. Also, you can type in a page number and press Enter to go directly to that page in the book.

    « Back Next »
  5. ×

    To search the entire text of this book, type in your search term here and press Enter.

    « Back Next »
  6. ×

    Share a link to this book page on your preferred social network or via email.

    « Back Next »
  7. ×

    View our suggested citation for this chapter.

    « Back Next »
  8. ×

    Ready to take your reading offline? Click here to buy this book in print or download it as a free PDF, if available.

    « Back Next »
Stay Connected!