FTA-TRI-11-02.3
“Lessons Learned” Evaluation of
Intelligent Transportation Systems (ITS)
Implementation at
Santee Wateree Regional Transportation Authority
June 2002
Final Report
OFFICE OF RESEARCH, DEMONSTRATION, AND
INNOVATION
NOTICE
This document is
disseminated under the sponsorship of the U.S. Department of Transportation in
the interest of information exchange. The United States Government assumes no
liability for its contents or use thereof.
The United States
Government does not endorse products of manufacturers. Trade or manufacturers’ names appear herein
solely because they are considered essential to the objective of this report.
|
REPORT DOCUMENTATION PAGE |
Form
Approved OMB No.
0704-0188 |
|
|
Public reporting burden for this
collection of information is estimated to average 1 hour per response,
including the time for reviewing instructions, searching existing data
sources, gathering and maintaining the data needed, and completing and
reviewing the collection of information.
Send comments regarding this burden estimate or any other aspect of
this collection of information, including suggestions for reducing this
burden, to Washington Headquarters Services, Directorate for Information Operations
and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA
22202-4302, and to the Office of Management and Budget, Paperwork Reduction
Project (0704-0188), Washington, DC 20503. |
||
|
1. AGENCY USE ONLY (Leave blank) |
2. REPORT DATE June 2002 |
3. REPORT TYPE AND DATES COVERED September 2000 to March 2002 |
|
4. TITLE AND SUBTITLE “Lessons Learned” Evaluation of Intelligent Transportation
Systems (ITS) Implementation at Santee Wateree Regional Transportation
Authority |
5. FUNDING NUMBERS |
|
6. AUTHOR(S) Ted J. Rieck1 and Mark Carter2 |
|
|
7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) Science Applications International Corporation 10260 Campus Point Drive San Diego, CA 92121 TranSystems Corporation 2400 Pershing Road, Suite 400 Kansas City, MO 64108 |
8. PERFORMING ORGANIZATION REPORT NUMBER |
|
9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) U.S. Department of Transportation Federal Transit Administration, TRI-10 Office of Mobility Innovation 400 Seventh Street, SW Washington, DC
20590 |
10. SPONSORING/MONITORING AGENCY REPORT
NUMBER FTA-TR-11-02.3 |
|
11. SUPPLEMENTARY NOTES 1TranSystems Corporation 2SAIC |
|
|
12a. DISTRIBUTION/AVAILABILITY STATEMENT Available From: National Technical Information Service/NTIS, Springfield, Virginia, 22161. Phone 703.605.6000, Fax 703.605.6900 [orders@ntis.fedworld.gov] |
12b. DISTRIBUTION CODE |
|
13. ABSTRACT (Maximum 200 words) The purpose of this
“lessons learned” is to document the experience with Intelligent
Transportation Systems (ITS) implementation at the Santee Wateree Regional
Transportation authority (SWRTA). SWRTA is a public transportation provider
serving rural central South Carolina as well as the City of Sumter. This
“lessons learned” documents the challenges faced by SWRTA in implementing ITS
technologies. The case study attempts to provide useful lessons to other
transit systems as they consider similar ventures. Among these lessons are:
the need for comprehensive technology planning, strong and committed project
management, employee “buy-in” and development, and budgeting sufficient
implementation time with contingencies. |
|
|
14. SUBJECT TERMS Intelligent Transportation Systems, Public Transit,
Computer-Aided Dispatch and Scheduling, Rural Public Transportation,
Paratransit |
15. NUMBER OF PAGES 49 |
||
|
16. PRICE CODE |
|||
|
17. SECURITY CLASSIFICATION OF REPORT Unclassified |
18. SECURITY CLASSIFICATION OF THIS PAGE Unclassified |
19. SECURITY CLASSIFICATION OF ABSTRACT Unclassified |
20. LIMITATION OF ABSTRACT |
NSN
7540-01-280-5500 Standard
Form 298 (Rev. 2-89)
Prescribed by ANSI Std.
239-18298-102
“Lessons Learned” Evaluation of
Intelligent Transportation Systems (ITS)
Implementation at
Santee Wateree Regional Transportation
Authority
June 2002
Notice
This document is disseminated under the sponsorship
of the Department of Transportation in the interest of information exchange.
The United States Government assumes no liability
for its contents or use thereof.
METRIC/ENGLISH CONVERSION FACTORS
|
ENGLISH
TO METRIC |
METRIC
TO ENGLISH |
|||||||||||
|
LENGTH (APPROXIMATE) |
LENGTH
(APPROXIMATE) |
|||||||||||
|
1 inch (in) |
= |
2.5 centimeters (cm) |
1 millimeter
(mm) |
= |
0.04 inch (in) |
|||||||
|
1 foot (ft) |
= |
30 centimeters (cm) |
1 centimeter
(cm) |
= |
0.4 inch (in) |
|||||||
|
1 yard (yd) |
= |
0.9 meter (m) |
1 meter (m) |
= |
3.3 feet (ft) |
|||||||
|
1 mile (mi) |
= |
1.6 kilometers (km) |
1 meter (m) |
= |
1.1 yards (yd) |
|||||||
|
|
|
|
1 kilometer
(km) |
= |
0.6 mile (mi) |
|||||||
|
AREA (APPROXIMATE) |
AREA (APPROXIMATE) |
|||||||||||
|
1 square
inch (sq in, in2) |
= |
6.5 square centimeters (cm2) |
1 square
centimeter (cm2) |
= |
0.16 square inch (sq in, in2) |
|||||||
|
1 square
foot (sq ft, ft2) |
= |
0.09 square meter (m2) |
1 square
meter (m2) |
= |
1.2 square yards (sq yd, yd2) |
|||||||
|
1 square
yard (sq yd, yd2) |
= |
0.8 square meter (m2) |
1 square
kilometer (km2) |
= |
0.4 square mile (sq mi, mi2) |
|||||||
|
1 square
mile (sq mi, mi2) |
= |
2.6 square kilometers (km2) |
10,000
square meters (m2) |
= |
1 hectare (ha) = 2.5 acres |
|||||||
|
1 acre = 0.4
hectare (he) |
= |
4,000 square meters (m2) |
|
|
|
|||||||
|
MASS - WEIGHT
(APPROXIMATE) |
MASS - WEIGHT
(APPROXIMATE) |
|||||||||||
|
1 ounce (oz) |
= |
28 grams (gm) |
1 gram (gm) |
= |
0.036 ounce (oz) |
|||||||
|
1 pound (lb) |
= |
0.45 kilogram (kg) |
1 kilogram
(kg) |
= |
2.2 pounds (lb) |
|||||||
|
1 short ton
= 2,000 pounds (lb) |
= |
0.9 tonne (t) |
1 tonne (t) |
= = |
1,000 kilograms (kg) 1.1 short tons |
|||||||
|
VOLUME (APPROXIMATE) |
VOLUME (APPROXIMATE) |
|||||||||||
|
1 teaspoon
(tsp) |
= |
5 milliliters (ml) |
1 milliliter
(ml) |
= |
0.03 fluid ounce (fl oz) |
|||||||
|
1 tablespoon
(tbsp) |
= |
15 milliliters (ml) |
1 liter (l) |
= |
2.1 pints (pt) |
|||||||
|
1 fluid
ounce (fl oz) |
= |
30 milliliters (ml) |
1 liter (l) |
= |
1.06 quarts (qt) |
|||||||
|
1 cup (c) |
= |
0.24 liter (l) |
1 liter (l) |
= |
0.26 gallon (gal) |
|||||||
|
1 pint (pt) |
= |
0.47 liter (l) |
|
|
|
|||||||
|
1 quart (qt) |
= |
0.96 liter (l) |
|
|
|
|||||||
|
1 gallon
(gal) |
= |
3.8 liters (l) |
|
|
|
|||||||
|
1 cubic foot
(cu ft, ft3) |
= |
0.03 cubic meter (m3) |
1 cubic
meter (m3) |
= |
36 cubic feet (cu ft, ft3) |
|||||||
|
1 cubic yard
(cu yd, yd3) |
= |
0.76 cubic meter (m3) |
1 cubic
meter (m3) |
= |
1.3 cubic yards (cu yd, yd3) |
|||||||
|
TEMPERATURE (EXACT) |
TEMPERATURE (EXACT) |
|||||||||||
|
[(x-32)(5/9)]
°F |
= |
y °C |
[(9/5) y +
32] °C |
= |
x °F |
|||||||
 |
 |
For more exact and or other conversion factors, see NIST Miscellaneous Publication 286, Units of Weights and Measures. Price $2.50 SD Catalog No. C13 10286 Updated 6/17/98
PREFACE
It is not the critic who counts; not the man who
points out how the strong man stumbles, or where the doer of deeds could have
done them better. The credit belongs to the man who is actually in the arena,
whose face is marred by dust and sweat and blood; who strives valiantly; who
errs, who comes short again and again, because there is no effort without error
and shortcoming; but who does actually strive to do the deeds; who knows great
enthusiasms, the great devotions; who spends himself in a worthy cause; who at
the best knows in the end the triumph of high achievement, and who at the
worst, if he fails, at least fails while daring greatly, so that his place
shall never be with those cold and timid souls who neither know victory nor
defeat.
Theodore Roosevelt,
The
Man in the Arena: Citizenship in a Republic, address delivered at the
Sorbonne,
Paris, April 23, 1910.
1. INTRODUCTION
The
purpose of this “lessons learned” report is to document the experience in
Intelligent Transportation Systems (ITS) implementation at the Santee Wateree
Regional Transportation Authority (SWRTA). This report will document the
challenges faced by SWRTA in implementing ITS technologies. The case study
attempts to provide useful lessons to other transit systems as they consider
similar ventures.
1.1 Background
SWRTA
is the public transportation provider for a mostly rural area of central South
Carolina. See Figure 1. SWRTA primarily serves a 2,500 square mile area
covering four counties. SWRTA also provides contracted Medicaid and work
support services in three other counties. It provides traditional paratransit services to persons with
disabilities as well as fixed route services in the City of Sumter. In an
effort to increase driver accountability and to generally improve the
efficiency of its operation, SWRTA sought to implement various ITS technologies.
These technologies were to be deployed in conjunction with flexroute service.
These included systems for computer-assisted dispatching and scheduling (CADS),
automatic vehicle location (AVL), mobile data terminals (MDTs) and geographic
information systems (GIS).
Figure 1: SWRTA Service Area
The
US Department of Transportation engaged the SAIC/TranSystems Team to
investigate SWRTA’s experience with advanced technology systems. The study
addressed the following objectives:
· Improvement
in the effectiveness and efficiency of transportation services provided in the
SWRTA area
· Improvement
in Customer Satisfaction through better service
· Demonstration
of the applicability of ITS technologies in the provision of flexroute services
to rural areas as well as other environments
· Development
of a mechanism for disseminating “lessons learned” in the use of ITS
technologies, and
· Development
of a mechanism for the industry-wide deployment of ITS technologies in
flexroute services.
For
reasons to be discussed below, the implementation of these technologies met
with significant problems. The goal of this case study is to help other rural
transit providers learn from the experiences of SWRTA.
1.2 Overview
of Situation
SWRTA
is a complex transportation operation. It operates both fixed route and
demand-responsive services. Fixed route operations are primarily within the
City of Sumter, though long-distance services to the Myrtle Beach tourist area
are also provided. Twenty-four vehicles are used to provide peak service on the
fixed route system with about 800 daily riders. In addition, demand-responsive
services are provided with a peak fleet of 54 vehicles. About 1,000 patrons use
this service each day.
A
share of SWRTA’s funding comes from Medicaid contracts it has with various
counties in its service area. According to the 1999 National Transit Database,
about 34 percent of its funds come to the agency from State and Federal
sources.
1.3 Organization
of Paper
This
paper presents the SWRTA experience in a case study format. First, basic facts
about the implementation of advanced technology are given. Second, issues about
that implementation are discussed followed by an analysis. Finally, conclusions or “lessons learned” are
drawn, and policy implications for the Federal Transit Administration (FTA) are
suggested.
This
paper is based on site visits and interviews with people involved in the
implementation, as well as a review of industry practice from both personal
interviews and literature review. The information used in this case study is
based not only on personal interviews with SWRTA staff, but also on information
obtained from people who observed the SWRTA experience from the sidelines. This included Santee-Lynches Regional
Council of Governments and State of South Carolina observers. Finally,
documentation concerning SWRTA’s efforts to implement advanced technology was
obtained and reviewed. This included a grant request, internal memorandum,
vendor proposals, and similar documents.
2. IMPLEMENTING ADVANCED
TECHNOLOGY
This
section provides an overview of the process undertaken by SWRTA to bring
advanced transit technology to rural, central South Carolina. First, a brief
chronology of events is presented. Second, the implementation by technology
type is discussed in more detail.
2.1 Chronology
of Events
In
general, the decision to acquire and implement advanced technology was
evolutionary. While a vision to move SWRTA “into the 21st Century” was clearly
the agency’s intent, the steps to reach that point were based on circumstances
and opportunity. In short, the agency acquired technology as the need for that
technology became apparent. There is no evidence that a “grand plan” or
strategy existed to determine needs and to fit technology to those needs in a
systematic way.
The
movement toward advanced technology started with the acquisition of geographic
information system (GIS) software. The GIS software revealed opportunities for
SWRTA to re-deploy its services. To support that re-deployment it was
determined that additional advanced technology, in the form of Computer Aided
Dispatching and Scheduling (CADS), was needed. This scheduling software was
acquired and implemented in a “piecemeal” fashion. The acquisition of automated vehicle location (AVL) and mobile
data terminal (MDT) systems were seen as adjuncts to the scheduling system. In
addition to this “piecemeal” approach, Y2K and other issues affected SWRTA’s
ability to successfully implement this system. In the end, for reasons to be discussed,
SWRTA was unable to implement the system.
Figure
2 illustrates the basic process in which SWRTA attempted to implement advanced
technology. As seen in the illustration, there were nine basic steps. These steps are described below.
Figure 2: Timeline of Advanced Technology
Implementation
Basic Flowchart of Events for ITS Implementation at
Santee Wateree Regional Transportation Authority
|
Step |
Description |
|
1. Vision for Technology |
1994: desire to move SWRTA into
21st Century. |
|
2. GIS Acquisition |
1996: grant available from South
Carolina Department of Transportation (SCDOT) to acquire GIS. In 1997, SWRTA
wins grant and acquires software. Also in 1997, SWRTA hired a GIS
coordinator. |
|
3. Flexroutes |
1998: based on GIS data and visit
to Putnam County, Florida, flexroute system designed and implemented for
Kershaw County. System was initially implemented using manual scheduling
methods. |
|
4. Partial Computer-assisted dispatching and scheduling (CADS) |
SWRTA management believed that the
operation of the flexroute system could be enhanced with CADS. Software was acquired to accomplish
matching patrons with flexroute services. During system training in the Fall
of 1998, it was discovered that the entire CADS package was needed for the
flexroute portion of the system to work properly. |
|
5. ITS Grant (MDT/AVL) |
Late 1998/ early 1999,
discretionary grant funding was made available to SWRTA. SWRTA decided to use
those funds to complete the implementation of the CADS system as well as to
acquire AVL and MDT systems. |
|
6. Acquisition of CADS System |
1999: researched various systems
via trade shows. Developed RFP to
acquire the services of a systems integrator who would bring together
hardware and software. Awarded contract to local firm in June 1999. |
|
7. Total CADS Implementation |
August 1999: implementation of the
scheduling system began. The system was to be “live” by January 2000. At the same time SWRTA obtains three new
service operating agreements while losing two existing agreements. In
September a technical project manager was hired to oversee the installation. |
|
8. CADS Problems |
October/November 1999, the
scheduling software vendor arrives to begin staff training. The hardware
portions of the system are unable to handle the software. At same time
turnover experienced among scheduling/dispatch staff, and data for scheduling
parameters discovered to be incomplete. The system goes “live” in January
2000 despite problems. |
|
9. CADS System Disconnected |
After continuing problems (e.g.,
the system “lost” data), by the Fall of 2000 the scheduling system was
disconnected and a less technical application (using Q&A) was
implemented. |
2.2 Geographic
Information System
SWRTA’s
first significant step toward implementing advanced technology was the
acquisition of Geographic Information (GIS) software. With the assistance of
the Santee-Lynches Regional Council of Governments (COG), SWRTA applied for and
won a grant from the South Carolina Department of Transportation (SCDOT). The
purpose of the grant program was to encourage inter-agency coordination.
SWRTA
hired a consulting firm to develop hardware and software specifications and
help install the GIS software. In addition, SWRTA hired a planner to manage and
operate the GIS.
The
agency acquired ArcView and ArcInfo brand software. The installation worked
well without any significant problems.
An
early task assigned to the GIS was to map demand response trips. Figure 3 shows
a plot of Medicaid clients in Lee County. Using the analysis created by the
GIS, SWRTA was able to develop a flexroute system. (See Figure 4.)
Figure 3: Sample GIS Plot of Demand Response Trips
Source: Presentation by Will
Davis, of SWRTA, Rural Advanced Technology and
Transportation Systems International Conference,
Branson, Missouri, August
2000.
Figure 4: SWRTA Flexroutes
Source: SWRTA public bus
schedule.
Just
prior to implementing a flexroute system, SWRTA staff toured the transit system
of Putnam County, Florida. Putnam County had a system of flexroutes that was
supported by CADS, Automatic Vehicle Locator (AVL) and Mobile Data Terminal
(MDT) systems.
2.3 Computer-Assisted
Dispatching and Scheduling
With
the implementation of the flexroute system some operational problems arose.
While the routes operated at some level of efficiency, SWRTA dispatch staff
sometimes had a difficult time in assigning riders to the services. For the
flexroutes to reach their full potential, it was important that as many demand
response patrons as possible be placed on the flexroutes. For reasons that are
somewhat unclear, the operating staff missed opportunities to make such
assignments.
One
possible reason is that the dispatch staff wanted to make sure the demand
response drivers had work. Assigning patrons to flexroutes would reduce the
work of demand response drivers. Since dispatchers were former drivers, some
sympathy for demand response drivers is one possible motive. Another reason may
be that the procedure for assigning to the flexroute was considerably different
from that for demand response and, therefore, more burdensome than the more
familiar demand response process. (This may indicate either a lack of training
or a lack of motivation on the part of dispatchers.) Finally, there was a
perception among some of the operating staff that many riders did not like the
flexroute service despite its lower fare versus the demand response
service. These factors and probably
others required too much supervision by SWRTA management.
To
encourage greater use of the flexroute system, part of an automated schedule or
CADS (computer-assisted dispatching and scheduling) package for such operations
was acquired. Initially the package acquired was thought by SWRTA to be
applicable for flexroute service on a “stand alone” basis. After the software
was acquired, it was discovered that a full scheduling system for both the
demand response and flexroute systems was needed. Shortly after that time,
SWRTA was able to secure discretionary grant funds that they elected to use to
purchase the balance of the scheduling package as well as to position
themselves to acquire AVL and MDTs.
2.3.1 Background
Issues
The
CADS system was purchased for the following reasons:
· To
improve the flexroute operation by making it easier for dispatch/scheduling
staff to assign patrons to the routes.
· To reduce
paperwork and simplify the reimbursement/billing process as well as to
integrate the agency’s financial reporting system.
· To
prepare for Y2K.
· To
increase driver accountability thereby making the overall operation more
efficient.
Improve Flexroute Operations
As
discussed earlier, it was believed by SWRTA management that the flexroutes were
not being used to their potential. A CADS system was seen as a way to
facilitate greater use of the flexroute system by making trip assignments administratively
easier.
Simplify Billing Process
Much
of SWRTA revenue is derived from Medicaid reimbursements. For each rider
carried by SWRTA making a Medicaid eligible trip, the host county would
reimburse the carrier on a per passenger mile basis. The clerical support
necessary to process the trip data for 1,000 daily riders was burdensome. It
was hoped that the scheduling system would generate reports to reduce paperwork
and simplify the billing process. Those reports were to be integrated with the new accounting system concurrently
implemented concurrent with the other systems.
Prepare for Y2K
SWRTA
management was informed that the preexisting computer system, including the
financial accounting module and Medicaid billing process, was not Y2K compliant.
There was a fear that the system would not function. The CADS is an important
source of information for the Medicaid billing process and, therefore, an
integral part of the accounting system. Successful implementation of CADS was a
vital step in bringing all systems into Y2K compliance.
Increase Driver Accountability
The
scheduling system had the potential to create greater accountability by
dictating driver route patterns. The scheduling system would delineate routes,
indicating the order of passenger pick-ups and drop-offs. The prior system
relied on the driver to establish a route pattern. Consequently, management
lacked awareness as to the driver’s position on his or her route. This
situation created a problem in managing “on-street” operations.
2.3.2 Acquisition
and Implementation
SWRTA
began the procurement process for the remaining elements of the CADS system in
1999. The strategy was to hire a “systems integrator” who would bring the
software and hardware elements together. In addition, the integrator would
oversee installation. This procurement process was preceded by SWRTA staff
researching various software products by visiting trade shows and attending one
vendor’s user group meeting. This research effort was also supplemented by
talks with users of scheduling software.
In
June 1999 two firms responded to the Request For Proposal (RFP). Both proposals
included the same scheduling system software, and both firms were local to South Carolina. In that
same month, the contract was awarded. The software was to be up and running
within six months – by January 1, 2000.
The
following events took place during implementation:
· In August
1999, the GIS planner was appointed to oversee some aspects of the software
implementation. The planner realizes that a computer “guru” is needed to help
manage the project.
· In
September 1999, a relatively inexperienced information technology specialist
was hired. By November 1999 this individual is given project management
responsibility for the implementation. The GIS planner was reassigned to assist
in the start-up of new services in another county.
· Initial
system training was to take place in August/September. This initial training
was to consist of a one-week “product” demonstration. “Real” SWRTA data would not
to be used. The training did not take place because the software vendor was not
ready.
· From
September to October, SWRTA staff began data entry which included client names
and addresses. Data could not be readily transferred since there was much duplication
of names and addresses. Of the 40,000 clients in the database, half were
believed to be repetitive. Other
problems with data entry included inadequate mapping information for the
portion of the software reliant on geocoded data.
· In
October initial vendor training on software. That training provided an overview
of the system. In November 1999, the scheduling software vendor arrives to
complete the training of personnel. The computer system crashes during training
in November 1999. The hardware was not able to handle the software. Its systems
integrator had assured SWRTA that the hardware conformed to the specifications
set by the software vendor. Later it was determined that the specifications
were minimal and did not account for any growth that had taken place since the
contract award.
· By early
2000, the software was up and running, albeit roughly. Schedules were not accurate with illogical
trip assignments. For example, a manifest for a driver in one county would
contain trips from yet another county. In addition, trips booked on the system
did not show up on driver manifests. Billing-related data entry of driver
manifests into the system did not go well. The software was unable to capture a
specific rider’s distance traveled (i.e., passenger miles). The distance that
passengers travel was a critical element in Medicaid billing for SWRTA. The
fact that the system was unable to produce the data in the form needed by SWRTA
was a significant failing.
· During
the first half of 2000, an in-house programmer wrote a Microsoft Access
application to supplement/replace the billing data entry portion of the
scheduling software. Later it is discovered that the program was critically
flawed.
· Due to
numerous problems, the scheduling software was disconnected in the Fall of
2000, and replaced with a program written in an “off the shelf’ database
management program.
2.4 Automated
Vehicle Location/Mobile Data Terminals
· The grant
that funded the CADS package was also to fund the acquisition of an automated
vehicle location system (AVL) and mobile data terminals (MDTs). Because of the
problems associated with the CADS system, the AVL/MDT portions of the grant
were put on “hold.” In addition to the funding issue, the communication system
of SWRTA was also under scrutiny.
· SWRTA
uses two-way radios in the rural portions of its service area. SWRTA saw that the weak link in adding
AVL/MDT would be the communications. At the time, SWRTA operated at a very low
frequency (40 – 70 MHz) over 2,500 square miles in its core four-county area.
Some radio vendors told SWRTA that data can be transmitted at these low
frequencies (1 voice, 2 data channels), but they had yet to test data transmission. Also, since the
service area was very rural they had several ”blind spots” where radio
communications did not exist. The big question for SWRTA was whether their
existing radio system supported advanced technologies. One weakness that was
identified was the lack of communication with the state DOT. SWRTA believed
that mutual benefits could be realized if there were partnering on
communication issues such as sharing towers.
Summary
of AVL/MDT status:
· Inoperable
CADS system with which to tie into the AVL/MDT technology.
· Inadequate
funding with which to deploy system
· Questionable
adequacy of communication system. SWRTA received conflicting advice as to
whether data transmission could work with their low-frequency radio system.
There was no independent verification that a low-frequency radio system would
serve SWRTA needs.
3. ISSUES IN IMPLEMENTING
ADVANCED TECHNOLOGY
From
Section 2, several issues emerge regarding the implementation of advanced
technology. These issues are the need for technology planning, preparing the
staff for advanced technology, and preparing the organization for advanced
technology. Section 3 describes the issues in detail, while Section 4 will
discuss SWRTA’s experience with these issues in light of an “idealized”
implementation approach.
3.1 Technology
Planning
There
are two issues associated with technology planning. The first is assessing the
technological needs of the organization. The second is developing an
implementation strategy that fulfills the vision produced through the
assessment.
3.1.1 Assessing
Needs
Before
acquiring advanced technology, an agency should perform a needs assessment.
Obviously, advanced technology should produce some benefit. Such benefits can be tangible or intangible.
Tangible benefits include improving cost efficiency, increasing productivity,
or reducing the time to process paperwork. Intangible benefits include
improving customer satisfaction, making the transit system more convenient, or
improving information available to system management. An accounting of these
benefits is crucial in deciding what technology is to be implemented. The key
elements in an assessment include:
· What are
the key challenges or problems facing the agency?
· Is there
a technological answer to help solve or meeting such challenges?
· Which
technology is applicable?
· How would
that technology be beneficial?
· What has
been the experience of other users of that technology in addressing similar
challenges?
· If the
technology were to be acquired, what staff would be directly and indirectly
affected?
· What
issues might the affected staff have with respect to the technology?
· What
hardware, software, and personnel issues are related to the given technology?
· Is there
sufficient support offered by vendors?
3.1.2 Implementation
Planning
Before
a given technology (or group of technologies) is acquired, the agency should
develop a written implementation plan. The plan would include key steps and
estimates of time and budget required at each step, as well as other resources
required to successfully implement the plan. Possible obstacles should be identified
along with solutions. These questions would be included in such a plan:
· Based on
the experience of others, how long does it take to implement this technology
once acquired?
· What are
the steps, in sequence, for bringing this technology on-line?
· What are
common problems that are encountered during implementation?
· What are
common strategies for implementation? Which is suited for the organization?
· What are
the experience and qualifications of the people leading/managing the
implementation?
· What are
the costs for implementation in terms of staff time and other resources?
· What kind
of staff training is required to ensure successful implementation?
· What are
the financial aspects of the implementation? Is the implementation cost
(including contingencies) in line with available resources?.
· What are
provisions for testing the new system before the old system is disconnected?
· What are
the indicators of a successful implementation?
3.2 Project
Management
Of
crucial concern is the project manager. This person must be the project
champion and should be committed to making the system work. He or she must also
possess, at least, a basic understanding of the technical aspects of the
project. More importantly, the project manager must also have good management
and political skills to bring all necessary people and resources together.
In
addition to the project manager, other key implementation players need to be on
board. This includes making sure that the necessary people to be involved are
identified and their roles explained. These questions are basic for the project
manager and team:
· Who will
be the project manager? Is this person technically skilled? If not, what
resources will be made available to this person to address technical issues?
Does the project manager have good management and political skills to marshal
the implementation resources?
· Does the
necessary staff have “buy in”? If not, what issues need to be resolved?
· What are
the immediate and on-going technical skills needed to accomplish implementation
and support this system once on line?
3.3 Employee
Development
Employee
development generally involves two factors. First, is the necessity to have a
degree of employee acceptance or “buy-in” of a given ITS project. Second, the training of employees so they
are able to competently utilize the given technology.
Depending
on the role of a given employee with the new technology, the degree of “buy-in”
or acceptance may be needed to ensure successful implementation and operation. In
the case of SWRTA, this includes the dispatchers and schedulers who ultimately
must make the CADS work. They need to be given a sense of ownership in the
technology and believe that the success of the technology is tied to their
success.
Employee
training on the new technology is another development factor. Even an
enthusiastic employee needs to know how to properly use the new system. One of the issues facing SWRTA was that the
system operation occurred with little or no training. Training on the system is
essential if the benefits of that system are to be realized.
3.4 Implementation
Time
The
time it takes to execute a new technology or system is almost invariably longer
than expected. Sufficient time plus contingency for problems should be built into
project implementation schedules. As part of implementation planning, it should
be determined where likely problem areas may exist and, possibly, how much time
may be needed to address them.
4. ANALYSIS OF IMPLEMENTATION ISSUES
The
following section first presents industry experience in acquiring and
implementing new technology, and second an idealized process for implementing
advanced technology. This process is derived from industry experience as well
as from selected industry literature. It is an attempt to provide a basis upon
which to critique the SWRTA experience.
4.1 Generalized
Industry Practice
This
report is not intended to provide a comprehensive review of the transit
industry’s practice in implementing advanced technology. Rather, the goal is to
find some pattern of practice that can be used as a basis to evaluate the SWRTA
experience. This section summarizes various sources of this information.
4.1.1 Technology
Plan for North Carolina Transit Systems
In
June 1999, the Institute for Transportation Research and Planning (ITRE) at
North Carolina State University documented the practices of transit systems in
implementing advanced technology. Technology Plan for North Carolina Transit
Systems, among other things, surveyed ten rural or small urban area transit
systems on the problems and benefits associated with ITS. The result of this
survey work was a list of priorities and strategies by which the North Carolina
Department of Transportation (NCDOT) would promote and fund the use of such technology
for transit systems in the state. Among the lessons learned by these ten
systems were:
· Build
support internally by justifying reasons for acquiring the technology
· Select a
proven product
· Emphasize
training (this includes basic computer training as well as training on the
given technology itself)
· Anticipate
delays by preparing contingency plans
· Seek
professional expertise
· Select a
systems integrator.
4.1.2 TCRP
18 – A Handbook for Acquiring Demand-Response Transit Software
In
1996, the Transportation Research Board (TRB) published A Handbook for
Acquiring Demand-Response Transit Software authored by Roy Lave and
others. As the title indicates, the
publication is intended to guide transit systems through the purchase and
implementation of CADS systems. While the handbook focused on the “nuts and
bolts” aspects of paratransit software, it did offer the following advice for
systems seeking to automate:
· Maximize
manual systems
· The
organization may have to change procedures to accept a new computer system.
· Document
in advance needs and expectations.
· Prepare
staff for a new system by involving them in the development of system
specifications.
· Largely
base system decision on analysis.
· Buy a
system with greater capacity than what is currently needed; anticipate growth.
· Identify
peers who have implemented similar systems and talk to them.
· Don’t
purchase system until it is seen working elsewhere.
· If full
CADS is acquired, evaluate adding complementary systems (e.g,, AVL, MDTs) and
make one vendor responsible for the entire system.
· Beware
that implementation takes time; be realistic about implementation schedules.
4.1.3 How
Effective Are Computer-assisted Scheduling and Dispatching Systems in
Paratransit? Results from a Sample of Operators
This
paper presented the results of a survey of 14 paratransit systems. Many of the
systems were classified as small or medium sized agencies with a median fleet
size of 30.5 vehicles and 37 paratransit operators. The purpose of the paper was
to report on the experience that these systems had in implementing and using
CADS systems.
Key
issues raised in the paper that are relevant to SWRTA were:
· Reducing
the workload of paratransit staff was the number one reason for acquiring a
CADS. Replacing obsolete hardware and improving on-street efficiency were tied
as the second-most picked reason for acquiring such a system.
· Over half
the agencies took more than 5 months to implement a system.
· In terms
of initially setting up a CADS, data entry was one of the top problem areas
operators had in implementing a system.
· Most
operators believed that a staff person dedicated as a system project manager
was key to successful implementation.
· Adequate
vendor-supplied training and support was seen as a typical deficiency during
the system start-up phase.
· Forty
percent of surveyed systems added either full time or part time personnel as a
result of implementing a new CADS.
4.1.4 Ottumwa
Transit Authority ITS Implementation.
As
part of this “lessons learned” study, the TranSystems Team made a site visit to
the Ottumwa, Iowa transit system. The Ottumwa Transit Authority (OTA) operates
in a 10-county area, approximately 5,000 square miles with a population of
140,000. OTA has a mixed fleet of 51 vehicles and only 11 of the vehicles are
housed at the Ottumwa facility. The remaining vehicles stay with the drivers
throughout the service area. About five years ago, OTA embarked on an ITS
implementation. The interest in ITS grew out of a desire to be able to operate
transit service more effectively in a very large, and very rural service area.
OTA received a $600,000 grant for a demonstration project. According to OTA’s
manager, the project has been the most difficult endeavor she has ever been
involved with.
The
ITS implementation consisted of:
· Communications
and automated vehicle location (AVL) system
· Computer
aided Dispatch (CAD)
· Geographic
Information System (GIS)
· Mobile
Data Terminals (MDT)
Reasons
for moving toward ITS:
· Optimize
routes
· Monitor
drivers
· Evaluate
opportunities for coordination
· Better
communicate with vehicles
· Facilitate
OTA’s billing process
Key
experiences:
· Pre-project
planning is important
· Many
options available for systems; choices complicated to evaluate
· Strong
communications background for system.
· Important
to have good project manager and access to peers and other knowledgeable
sources.
4.1.5 Cape Cod Advanced Public Transportation
System.
Cape
Cod Advanced Public Transportation System (CC—APTS) is an example of a well
thought-out implementation of advanced technology. The CC—APTS was intended to
address several issues facing the Cape Cod Regional Transit Authority (CCRTA).
These issues included access to jobs, integration of transportation modes,
traffic congestion issues, and air pollution from surrounding regions. These
issues caused CCRTA to seek out ITS as a way to promote greater efficiency
through coordination of services, provide improved customer information,
promote safety and security, and to attain a higher level of fixed route
service.
CCRTA,
in pursuing the implementation of its CC—APTS, brought together a number of
organizations through a strategic partnership. These included local, state and
federal entities as well as the Cape Cod Chamber of Commerce and the Cape Cod
Economic Development Council. The agency also sought help from local colleges.
Phase
I implementation (accomplished over a three year period) involved development
of GIS capabilities including hardware acquisition and design and testing for
data communication systems and AVL. Also included in this initial phase was an
upgrade to CCRTA’s paratransit scheduling software. Phase II (planned for
2000-2001) includes, among other things, acquisition of AVL and MDTs, as well
as the completion of the data communication system. Phase III (planned for
2001-2003) looks at additional advanced systems including electronic payment
systems.
4.1.6 CTAA
At
the Community Transportation Association of America’s (CTAA) annual meeting, a
panel discussion on problems with implementing automated scheduling was held.
One presentation was made regarding the experience of Hill Country Transit
District (HCTD) in central Texas.
HCTD
was asked to take over the operation of a small urban transit system operated
by one of the local cities. The City had purchased a CADS system and had
already scheduled installation and training. The installation and training was
to take place about two weeks following the assumption of the transit system by
HCTD.
The
following problems were experienced by HCTD:
· Equipment
and software installation took longer than expected, shortening the time
available for training.
· The
Mobile Data Terminals (MDTs) interfered with the communication systems of local
radio operators, requiring HCTD to limit the use of the terminals.
· Scheduling
system parameters were not realistic; the parameter inputs were made without
involvement of the dispatch staff.
· Various
software glitches were experienced, including those that caused the system to
“go down” as well as inexplicable rescheduling of booked trips.
HCTD
had these basic recommendations regarding CADS implementation:
· Establish
the need for a CADS. Justify the reasons and research the decision thoroughly.
· Bring in,
as necessary, expertise that is not biased to a particular system.
· Make sure
the staff is knowledgeable about the system and is prepared to implement it.
· Thoroughly
examine the technical requirements of the given system and make sure the system
is adaptable to the business needs of the transit organization.
4.1.7 Building
Professional Capacity in ITS--An Assessment of ITS Training and Education
Needs: The Transit Perspective
This
document was produced as part of a larger effort by the US Department of
Transportation entitled “Building Professional Capacity in Intelligent
Transportation Systems: Documentation and Analysis of Training and Education
Needs in Support of ITS Deployment.” This document reported on a survey of ITS
training needs of the transit industry. The survey consisted of personal
interviews conducted by the Volpe National Transportation Systems Center. The
survey reported on needed skills, types of training delivery methods, as well
as a policy discussion involving ITS educational needs.
Of
note for the “lessons learned” work are the top skills identified as
educational needs in the deployment of ITS technologies. In part, they are:
1. Understanding
technology options –
how to make the right choice with a broad basis of organization participation.
2. Cost/Benefit
Analysis – how to
weigh the benefits of a given system versus its costs.
3. Contract
Management skills—
recognizes that most agencies do not have, in-house, the requisite skills to
manage highly technical procurements.
4. Financing
– making sure that
all financial pieces are in place. The survey noted that grants drive projects.
Typically, operating and maintenance are costs not included in grants. Agencies
need to anticipate those excluded costs.
5. Developing
of a business plan –
recognized that ITS deployments were frequently “piecemeal” and that there was
a need to develop an overall business plan in such deployments.
4.1.8 FHWA’s Final Rule and FTA’s Policy for
Applying the National ITS
Architecture at the Regional Level
This
pamphlet was produced to provide an overview of the Final Rule/Policy regarding
the National ITS Architecture. On January 8, 2001, the U.S. Department of
Transportation published FHWA’s Final Rule on the National ITS Architecture. At
the same time, the FTA’s version of the rule (“policy”) was also published. The
Rule/Policy generally requires the development of a regional ITS architecture
prior to the implementation of ITS projects. It also requires that all ITS
projects be developed using systems engineering. A systems engineering
approach, as defined by the Rule/Policy thoroughly considers all aspects of a
project’s life cycle including “…planning, design, procurement, deployment,
operations, maintenance, expansion, and retirement of the system and
subsystems.” The systems engineering requirement is flexible in scope and
depth depending upon the complexity of the given project. In summary, a systems
engineering analysis needs to include the following elements:
· Indicate
the project’s relationship to the regional ITS architecture.
· The roles
and responsibilities of project stakeholders
· Requirements
definition
· Analysis
of Alternatives
· Procurement
Options
· Identify
ITS standards
· Identify
needed procedures and resources.
4.2 Ideal
Process
Table
1 describes the ideal process. Figure 5 summarizes this process. How this
process ties in with the Final Rule/Policy of the National ITS Architecture
(discussed in 4.1.9) is discussed later.
Table 1: Idealized Technology Implementation
Process
|
Step/Item |
Description |
|
Identify
Current/Near Term Problems |
Involves specific issues facing agency such as: · Simplify record
keeping · Increase service
productivity · “Where’s my bus” · Simplify reporting |
|
Identify Future
Vision |
Future of agency. Such as: · Use flexroutes · Expand services · Internet based
services (e.g., reservations, information, fare purchases) |
|
Technological
Assessment |
Compare needs (current and future) with
technological solutions (both in use and potential). Identify gaps in
technology. Are any of the technology gaps a project “killer”? |
|
Technology Plan |
|
|
Identify Needed Technology |
Determine application and hardware needs based on
the technological assessment. |
|
Technology Strategy and Goals |
Determine approach to acquiring technology.
Establish performance goals/expectations. Define “success.” |
|
Institutional Issues |
Determine how business aspects of the organization
may be affected by the new system. Can the technology system adapt to current
business practices? Will business practices need to be reconfigured to
maximize the benefits of the new technology? Is there Institution-wide
“buy-in” with the project? If not, are there budgetary, administrative or
maintenance issues? |
|
Organizational Players |
These questions should be asked of the people
directly or indirectly involved in the technology implementation and
operation: · To what extent should
people in key functional areas of the organization be involved in the design,
planning, implementation and operation of the given system? · Do those people have
the needed technological background to support the planning, implementation
and operation? · Is there someone who
has the skills to be the project manager? |
|
Budget and Financing |
An accurate budget forecast along with identified
funding are crucial elements to make sure the project can be accomplished
with the resources needed for a successful outcome. |
|
Timing/Phasing |
· How much time is
required for each step in the process? · What are the critical
elements that must come together for the timeline to work? · What factors could
interfere with those critical elements? · What contingencies are
available in the event the deadlines for those elements are missed? How would
that affect the over all timeline? |
|
Implementation |
· Develop Detailed
System Specifications · Develop Detailed
Project Time Line and Milestones · Establish Vendor
Selection Committee · Develop Vendor RFQ · Develop Selection
Committee Vendor Rating System · Send Out Vendor RFQ
and Select Vendor · Select Location for
Pilot Project · Acquire Pilot Hardware
and Software from Selected Vendor · Develop Pilot
Implementation Team · Develop
Software/Hardware Upgrade Policy · Develop System Routine
Maintenance Program · Review Pilot System
Feedback · Review Pilot System’s
Meeting of Project · Objectives, Goals and
Budget · Modify Pilot
Implementation Plan and Implement Recommendations · Re-evaluate Pilot
Project Metrics with Feedback Implemented · Repeat Testing on Pilot
Project as Necessary · Modify Project Timeline
if Necessary · Lock Down System -- No
More Changes · Develop Procedures for
System Upgrades and Enhancement · Document System
Training Procedures · Train Administrative,
Operation, and Maintenance Staffs · Begin Full System
Rollout · Monitor Full System
Against Baseline Metrics · Implement Incremental
Upgrades Consistent with Upgrade Policies · Measure Performance
Against Baseline Metrics with Upgrade In Place |
|
Assessment of
Results |
· Review results for
impact on current or near term problems. · Review results versus
Technological Assessment |
Figure 5: Idealized Implementation Process
4.2. Application
of the Ideal Process Under the Final Rule/Policy
The
ideal process previously illustrated in Figure 5 generally conforms to the
systems engineering requirement of the Final Rule/Policy. While SWRTA implementation
efforts predated the Final Rule/Policy, the use of the ideal process is
enhanced by its compliance with FTA/FHWA directives.
Table
2, after the next page, compares required systems engineering elements with the
ideal process.
As
seen in the table, the ideal process ties in well with virtually all of the
systems engineering elements. The technology planning step addresses many of
these engineering elements. Addressing the regional ITS architecture
relationship, while not contained in the technology planning step, can be
satisfied in one or more of the other process steps. It can be addressed as
part of problem identification, future vision, and/or the technological
assessment steps of the ideal process.
4.3 Critique
Table
3, at the end of this section, summarizes the critique of SWRTA process for
implementing advanced technology. The table compares the “idealized” process
with that followed by SWRTA. Comments are included with some of the
comparisons.
4.4 Critique
Summary
The
critique reveals the following:
· SWRTA
took piecemeal approach to implementing advanced technology.
· No
detailed needs assessment.
· No
assessment of the impacts of implementing advanced technology.
· Lack of
experienced project management
· Not
enough time to properly implement the system.
· Lack of
financial planning.
· No
contingency planning.
· Lack of
proper training.
· Not
enough staff “buy-in.”