Knowledge Resources

The procurement, initial deployment and ongoing operation of the Puget Sound RFC program presented the partner agencies with new hardware and software technology and the need to address risks associated with them.

More detailed insights regarding the risks associated with a fare card technology include the following:

• Select an off-the-shelf technology (hardware and software) that is already proven, if appropriate to the region's needs.

Modifying or customizing fare card technology entails greater risks. A modified or customized system has the advantage of closely meeting the specified needs of the regional partnership, along with the disadvantage of needing more development and testing to be sure it does what it is supposed to do. In the case of the Puget Sound system, only the on-board Driver Display Unit (DDU) was significantly customized to accommodate emerging smart bus initiatives. Customized software may need to be developed in order to accommodate the partners’ existing legacy systems with which a new fare card system must be integrated. These risks usually cannot be avoided, though in the case of Puget Sound not all the partner agencies had legacy integration issues.

• Establish a sufficiently large performance security requirement with the system RFP to assure that only financially secure firms are likely to respond.

Performance security can be satisfied in several ways, including a bond, retainage and letters of credit. A large performance security requirement increases the likelihood that some firms with new technologies may be excluded from further consideration, and competition may be limited, as it was in the Puget Sound case by both the performance security requirement and by a demanding payment schedule.

• Select a vendor with established electronic fare card systems deployed elsewhere that also meet most of the requirements of the project.

This will help avoid the risks of adopting unproven technologies.

• Establish an Intellectual Property escrow to protect against the risk of vendor default, and contractually require the vendor to deposit its proprietary source code, build documentation, and periodically update them.

• Require a conservative payment schedule that allows for major milestone payments at limited points in the contract, each associated with a significant and satisfactory completion of work.

• Require extensive and comprehensive insurance coverage from the vendor.

The Puget Sound RFC partner agencies decided to procure an “off-the-shelf” fare card system, selectively modified to accommodate technology specifications from their core business needs. The agencies felt strongly that their business needs should determine the system’s features and capabilities. They preferred to accept the risks associated with some system modifications rather than trying to adapt their business processes to an already developed but possibly mismatched system.

The RFC project’s Request for Proposals (RFP) required responders to post a $10 million performance guarantee and meet a restricted and demanding milestone payment schedule. This was done to ensure that only well-established, financially robust firms would reply. The partner agencies recognized that their procurement approach might exclude less-established vendors even if they were viable and had interesting, innovative technology, but accepted this in order to reduce the risk of selecting a financially unstable vendor. It turned out that the restricted milestone payment schedule was more troublesome for proposers than the performance security.

Three firms responded to the RFP. One was initially deemed non-responsive. The partner agencies conducted an extensive process of proposal review and revision and two Best and Final Offers (BAFOs). An Apparent Successful Proposer was identified and the agencies concluded negotiations with this vendor. The selected vendor had already developed and deployed (in other locations) most of the hardware and some of the software components that would be used in the Puget Sound RFC system. Because of this prior experience, the RFC partner agencies avoided much of the risk associated with unproven technologies, and benefited from the earlier system development efforts.

Much of the new software was developed for the RFC system to implement the agencies’ business rules and to interface with their network and other onboard systems. Most or all of this software would have had to be developed in some form even if an off-the-shelf system had been chosen; the associated development risks can thus be considered unavoidable.

The greatest technology risk and concern has been that the vendor might default on the contract, leaving the partners with a "black box" software system that they would be unable to continue to develop. The vendor, on the other hand, considered its system source code to be proprietary.

This risk was managed via a software escrow agreement. The vendor contract required the vendor to deposit the system source code and associated documentation with a software escrow company, and to update and refresh these files at each milestone payment until Full System Acceptance. During the operating phase, the escrow must be updated with each system upgrade. Under the terms of the contract with the escrow company, the agencies could periodically ask the company to verify that the source code compiles correctly, and that its functionality matches that of the currently deployed system. The contract also stipulates that, if the vendor defaults, the escrowed code would be released to the partner agencies, and they would have the option to purchase the software outright at the term of the ten-year operating contract.

This escrow arrangement is somewhat complex (as it involves a three-party agreement) and can be costly, contingent upon the frequency of full build and verification services. However, it was felt to be the most satisfactory way for both the partner agencies and the vendor to manage the risks associated with the RFC system software.