National Academies Press: OpenBook

AVL Systems for Bus Transit: Update (2008)

Chapter: Appendix C - Systems Engineering Process

« Previous: Appendix B - Overview of Current Bus AVL Systems
Page 101
Suggested Citation:"Appendix C - Systems Engineering Process." National Academies of Sciences, Engineering, and Medicine. 2008. AVL Systems for Bus Transit: Update. Washington, DC: The National Academies Press. doi: 10.17226/22019.
×
Page 101
Page 102
Suggested Citation:"Appendix C - Systems Engineering Process." National Academies of Sciences, Engineering, and Medicine. 2008. AVL Systems for Bus Transit: Update. Washington, DC: The National Academies Press. doi: 10.17226/22019.
×
Page 102
Page 103
Suggested Citation:"Appendix C - Systems Engineering Process." National Academies of Sciences, Engineering, and Medicine. 2008. AVL Systems for Bus Transit: Update. Washington, DC: The National Academies Press. doi: 10.17226/22019.
×
Page 103
Page 104
Suggested Citation:"Appendix C - Systems Engineering Process." National Academies of Sciences, Engineering, and Medicine. 2008. AVL Systems for Bus Transit: Update. Washington, DC: The National Academies Press. doi: 10.17226/22019.
×
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.

101 This section offers an overall approach to selecting and ac- quiring advanced technology systems, sometimes referred to as the “systems” approach. Its advantages include: • Being fundamentally driven by the needs of the organi- zation, rather than by the pursuit of technology for the sake of novelty or change as an end in itself; • Supporting systems integrator selection and project ac- ceptance on the basis of demonstrating agreed functional and performance requirements; and • Establishing a “feedback loop,” where at the conclusion of technology implementation the process can begin anew of reassessing whether further needs remain to be addressed with technologies available at that time. NEEDS AND TECHNOLOGY ASSESSMENT The process should begin with a fundamental assessment in which the agency identifies the need to improve certain parts of its service effectiveness or its underlying business processes. The foundation for Intelligent Transportation Sys- tems program development should be that implementing ad- vanced technology could help address those business needs. Another important step is to develop a consensus within the agency on the relative priority of these needs, which will be used to help establish the overall sequence of projects and implementation schedule. In parallel with the needs assessment, the agency should review available and proven technologies that could be effec- tively used to enhance transit operations. There are numerous reference sources to use as a starting point [e.g., the Advanced Public Transportation Systems state-of-the-art report (C1)]. However, the technology landscape is constantly evolving, including not just the available technologies, but also their current capabilities, how they can be used for transit, and the extent of the experience with their use in revenue service. It is important that agencies acquire a current technology assess- ment. In addition to identifying potentially useful proven technologies and how to apply these technologies to transit, the technology assessment should also identify the general benefits and costs and organizational impacts (e.g., staffing, training, and organization structure). Agencies now realize that it is important to build a knowl- edge base for which technologies have been proven in service and what needs these technologies have been able to address for transit agencies. Many agencies have involved an experi- enced consultant beginning at this stage in the process, because they have both the direct experience with the actual functional capabilities of the proven and commercially available auto- matic vehicle location (AVL) systems and the understanding of how other agencies have used these systems. Another use- ful tool at this stage is a peer review, conducting discussions and site visits with similar agencies that have already deployed or are in the process of deploying an AVL system. PROJECTS DEFINITION AND IMPLEMENTATION PLAN Agencies can identify high-priority needs for which proven technology solutions exist. They can define a set of technology deployment projects that address these needs. It is important to structure these projects into a transit technology implementa- tion plan, providing the order in which agencies will deploy the projects and the anticipated timing of the deployments. In addition to a bus AVL system, the plan could include a variety of other transit technology projects. One important factor in defining the project sequence should be the relative priority of the needs that the projects are addressing (i.e., it would be logical to first pursue those pro- jects that address the highest priority needs). However, other considerations need to be taken into account. • In some cases, certain projects might need to be in place to form part of the infrastructure that supports pursuing another project. For example, an AVL system project might address needs considered of higher priority than the needs being addressed by a fixed-route scheduling software project. However, the agency may need to de- ploy scheduling software first because it forms part of the infrastructure needed for the AVL deployment. • A certain project that addresses a high-priority need might require the use of a technology that is deemed rel- atively immature or that is undergoing extremely rapid change. The agency may want to delay deployment until the technology is more stable. One important factor for agencies to consider in planning the expected timing of the deployments is the expected avail- ability of capital and operating funding. In some cases, con- strained funding could suggest that some of the projects that address lower priority needs should not be included in the im- plementation plan (although having identified the purpose for and anticipated benefits from further investments may assist the agency in pursuing the additional funding needed to incor- porate additional projects into the implementation plan). Also, the timing of future expected funding available may constrain the pace at which project implementation is planned. APPENDIX C Systems Engineering Process

Other important considerations that agencies should con- sider in planning the timing for implementing the project sequence include the following: • Each project requires a sequence of design, procurement, implementation, and testing activities, and it is important to incorporate realistic timeframes for this sequence into the implementation plan. • Introducing the new technologies can have various orga- nizational impacts to which agency staff will need to adapt. Some agencies choose to deploy a new project after a time period during which staff can adapt to the impacts of the prior project. Agencies can include ex- plicit timeframes for staff training and adjustment in the sequence of activities for each project. Following the implementation plan sequence, the agency can pursue the deployment of individual projects. The initial step for agency staff with each project is to secure both pro- curement approval from their agency and any external funding sources to be used for the procurement. It is essential at this point that the agency recruit a “champion” from senior man- agement, if such a person has not been involved in the transit technology development program from the outset, to spear- head the effort to secure agency approval of the implementa- tion plan. For example, at Capital Metro in Austin, Texas, the project champion for the current AVL system implementation is the head of Operations, the department that will be the pri- mary user and beneficiary of the system. The project champion would take a lead role in securing a consensus with other members of agency senior management, for the projects, deployment sequence, and the general time- line. The benefit/cost justification for the individual projects is usually a key feature in validating the implementation plan. Another important role for the project champion is to lead the effort to secure agency investment in staff resources (e.g., re- training and hiring) needed to achieve the benefits available from the projects. PROCUREMENT OF INDIVIDUAL PROJECTS Transit agencies require a competitive procurement process. A Request for Proposals (RFP) process is usually preferable for systems procurements, because agencies need to consider many factors other than price in selecting a systems integrator that will provide the best value solution. A key element in an effective RFP-based procurement is incorporating a thorough specification with functional/ performance requirements. This in essence means that the specification defines what the system will be able to do rather than how the system will accomplish these functions. A functional/performance specification is important to preserve maximum competition in the procurement process, because there is a limited pool of qualified vendors for these systems 102 that have differentiated their products by using distinct prod- uct designs. A strong functional/performance specification has the characteristic of using requirements that are specific enough. When a proposer has offered to comply, the re- quirement wording should enable performing acceptance testing to verify that the implemented system has addressed the requirement. However, the specification should avoid whenever possi- ble prescribing how the system will operate (as opposed to what the system will be able to do). Because a functional re- quirement can be accomplished in multiple ways, a specifi- cation that requires a specific design may be calling for a design that some or possibly even all of the vendors do not use in their proven product (when one or more of the commer- cially available designs might have addressed the functional- ity performance that the agency needs). Another critical diffi- culty with a prescriptive specification is that although the required design may well represent the state of the practice while the specification was being prepared, by the time the pro- curement has been completed and the implementation is un- derway there may be newer and superior approaches proven and available from the selected systems integrator (technology evolves rapidly). Some agencies have also used a Request for Information (RFI) as a useful initial step before issuing an RFP. An ideal time for an RFI is after the agency prepares the draft func- tional specifications. Potential vendors are invited to com- ment on the specifications, and if the responses made clear that a certain capability the agency needs might unduly limit the number of competitive vendors, the agency might opt to delete that requirement from the specification or change it to an option. Similar “pre-RFP” consultation with vendors can be used during the technology assessment activity mentioned earlier, as useful feedback for drafting the specifications. For example, TriMet in Portland, Oregon, made use of RFI ven- dor consultations before issuing the RFP in its procurement process. The “pre-RFP” consultation stage is often coupled with site visits to other agencies that have recently imple- mented an AVL system and are considered comparable (e.g., fleet size and modes). There is an inherent challenge in finalizing specifications using input from potential vendors (e.g., RFI feedback, ven- dor presentations, and discussions at trade shows). Vendors have an underlying interest in attempting to influence the specifications to include requirements that they believe they will be better able to address than their competitors. In other words, it is in the interest of the potential vendors to if possi- ble influence the process to limit the range of competition in the eventual procurement. This is entirely the opposite of the interests of the agency. It can help agencies to have the as- sistance of an experienced consultant, because they are aware of the actual functional capabilities of the various vendor sys- tems through having worked with other agencies on recent deployments.

103 isting software and networks being integrated with the new system. – This requirement for extensive internal coordination is often a significant challenge for a transit agency, be- cause the various business units are not often required to collaborate in this manner. Mechanisms to require and facilitate such collaboration sometimes do not exist or are rarely used. The involvement of a neutral third party, such as a consultant, can be useful. It is also essential that senior management communicate a vision for the end results intended from the technol- ogy implementation plan, coupled with clear direc- tion on collaborative procedures that are required. – The evident commitment of senior management to the project and the leadership of a project champion are important steps to convey that these information gathering and coordination activities are essential. The project champion will typically be a member of the senior management team at the agency and will not have sufficient availability to directly coordinate these activities. It is common for the agency to assign one or more agency staff with project manager re- sponsibility for AVL system implementation (with the backing of the project champion), coupled with consultant support. • There is a general need to hold the vendor accountable to implement a system that demonstrates the functional and performance capabilities that were committed to in the contract. – A preparatory design review process before system installation is advisable. The systems integrator uses this process to build a consensus with the agency about the system details. This process should include explicit discussion about how the installed system will address each requirement. – The agency and the systems integrator must agree in advance on the formal acceptance test procedures. These procedures serve to demonstrate each con- tract requirement and commonly involve multiple test stages and steps in the implementation process (e.g., pre-installation, installed in a small portion of the fleet, or at full fleet installation). Consultant as- sistance can be useful in helping the agency to verify that test procedures proposed by the systems inte- grator are complete and adequate and that the allo- cation of test procedures to the various testing stages is appropriate. EVALUATION Once the agency has accepted the contract implementation for an individual project, it is important that it evaluates the im- pact of the project. In the case of an AVL system it is best to do this evaluation long enough after the system has entered revenue service that its users have become accustomed enough to its use that they are more comfortable and have started to An agency evaluation committee needs to evaluate pro- posals relative to the evaluation criteria identified in the RFP. Based on the evaluation findings, the committee can identify those proposals in the competitive range for even more de- tailed evaluation. This further evaluation often involves clar- ification questions and interviews with proposers and, in some cases, site visits with other agencies that have recently imple- mented a similar system from the contending proposers. Often, the proposers are also asked to submit a Best and Final Offer. Consultant assistance can also be helpful at this stage. Agency staff may not have a comparable technical background to vendor staff, and consultant assistance can help eliminate any vendor advantage in the discussions. At the end of this process, the evaluation committee will need to reach consensus on the award recommendation; this recommendation typically needs to be translated into the formal selection of the proposal by the agency (e.g., by the Board). At the conclusion of this selection process, agency staff awards a contract that obligates the vendor to the price and other commitments made through the entire proposal process. Depending on the extent to which the agency has previ- ously undertaken systems procurements, there is some poten- tial for resistance from the agency procurement department to aspects of the process that are considered unconventional. These aspects can include those elements that differ from the conventional procurement approach used for items tradition- ally purchased by transit agencies (e.g., vehicles), such as a functional/performance specification, the role of non-price criteria in evaluation, and pre-award discussions with pro- posers and other transit agencies. Initial peer review can be ef- fective, because it allows procurement staff to learn of how their peers at agencies that have previously implemented the system now believe that these approaches are considered ef- fective and even essential for this type of procurement. IMPLEMENTATION MANAGEMENT The agency purchase process is far from completed when the contract is first awarded. Implementation management is a substantial undertaking that is critical to the long-term success of the project once it is brought into revenue service. Focus- ing on AVL systems in particular: • The agency will need extensive internal coordination between agency business units: – The systems integrator will need to gather significant input and configuration data for initial system imple- mentation. The gathering of the required input data will involve representatives from diverse parts of the agency, as will decisions about how to configure the system. – Extensive internal coordination will also be needed to support the logistics of the physical installations in facilities and vehicles, and the reconfiguration of ex-

learn how to best take advantage of the new capabilities avail- able. It is also useful that an independent entity from the agency leads the evaluation effort, such as was the case with evalua- tion of the TriMet AVL system in Portland, Oregon, and the potential uses for its data (led by researchers from Portland State University, as discussed in chapter two). The evaluation can have at least two distinct purposes: • Evaluation can provide evidence to the agency and ex- ternal funding sources about the benefits and costs it is experiencing. – If the project is living up to expectations, this pro- vides project sponsors with evidence of the value of the decisions and investments they made. This can help enhance the prospects of gaining future funding for additional projects (e.g., upcoming projects in the overall technology implementation plan). – If the project results are not yet living up to expecta- tions, it may be that the agency needs to take additional 104 steps to adapt (e.g., procedures or organizational structure) practices to best build on the established successes of the system and more fully leverage its potential. The evaluation findings could provide the motivation to investigate and implement such needed adaptation. • Evaluation can also help identify whether the resulting changes in agency needs warrant a reassessment of the needs and technology, and thus any evolution in the im- plementation plan. REFERENCE C1. Hwang, M., J. Kemp, E. Lerner-Lam, N. Neuerberg, and P. Okunieff, Advanced Public Transportation Systems: The State of the Art Update 2006, Federal Transit Ad- ministration, Washington, D.C., 2006 [Online]. Available: http://www.fta.dot.gov/documents/APTS_State_of_the_ Art.pdf [accessed June 11, 2007].

AVL Systems for Bus Transit: Update Get This Book
×
 AVL Systems for Bus Transit: Update
MyNAP members save 10% online.
Login or Register to save!
Download Free PDF

TRB’s Transit Cooperative Research Program (TCRP) Synthesis 73: AVL Systems for Bus Transit: Update explores the uses of computer-aided dispatch/automatic vehicle location (CAD/AVL) systems in fixed-route and demand-responsive services (bus AVL), as well as changes in agency practices related to the use of AVL systems.

READ FREE ONLINE

  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!