Lesson

Anticipate, understand, address and manage the risks associated with fare card technologies and the vendor relationship.

Experience of seven partner public transportation agencies in the Central Puget Sound region of Washington in setting up a regional fare card program.


4/14/2006
Washington,United States


Background (Show)

Lesson Learned

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.


Lesson Comments

No comments posted to date

Comment on this Lesson

To comment on this lesson, fill in the information below and click on submit. An asterisk (*) indicates a required field. Your name and email address, if provided, will not be posted, but are to contact you, if needed to clarify your comments.



Source

Evaluation of the Central Puget Sound Regional Fare Coordination Project

Author: Cluett, Chris et. al.

Published By: Prepared by Battelle for the USDOT FHWA

Source Date: 4/14/2006

EDL Number: 14300

URL: http://ntl.bts.gov/lib//jpodocs/repts_te//14300.htm

Other Lessons From this Source

Lesson Contacts

Lesson Contact(s):

Chris Cluett
Battelle
206-528-3333
cluett@battelle.org


Agency Contact(s):

Candace Carlson
King County Metro, Washington
206-684-1562
candace.carlson
@metrokc.gov

Lesson Analyst:

Firoz Kabir
Noblis
202-863-2987
firoz.kabir@noblis.org


Rating

Average User Rating

2 (1 rating)

Rate this Lesson

(click stars to rate)



Notes

Lesson of the Month for April, 2006 !


Lesson ID: 2006-00226