National Academies Press: OpenBook

Leveraging ITS Data for Transit Market Research: A Practitioner's Guidebook (2008)

Chapter: Chapter 4 - Data Management, Reporting, and Staffing Considerations

« Previous: Chapter 3 - ITS Data Applications in Market Research
Page 28
Suggested Citation:"Chapter 4 - Data Management, Reporting, and Staffing Considerations." National Academies of Sciences, Engineering, and Medicine. 2008. Leveraging ITS Data for Transit Market Research: A Practitioner's Guidebook. Washington, DC: The National Academies Press. doi: 10.17226/13917.
×
Page 28
Page 29
Suggested Citation:"Chapter 4 - Data Management, Reporting, and Staffing Considerations." National Academies of Sciences, Engineering, and Medicine. 2008. Leveraging ITS Data for Transit Market Research: A Practitioner's Guidebook. Washington, DC: The National Academies Press. doi: 10.17226/13917.
×
Page 29
Page 30
Suggested Citation:"Chapter 4 - Data Management, Reporting, and Staffing Considerations." National Academies of Sciences, Engineering, and Medicine. 2008. Leveraging ITS Data for Transit Market Research: A Practitioner's Guidebook. Washington, DC: The National Academies Press. doi: 10.17226/13917.
×
Page 30
Page 31
Suggested Citation:"Chapter 4 - Data Management, Reporting, and Staffing Considerations." National Academies of Sciences, Engineering, and Medicine. 2008. Leveraging ITS Data for Transit Market Research: A Practitioner's Guidebook. Washington, DC: The National Academies Press. doi: 10.17226/13917.
×
Page 31
Page 32
Suggested Citation:"Chapter 4 - Data Management, Reporting, and Staffing Considerations." National Academies of Sciences, Engineering, and Medicine. 2008. Leveraging ITS Data for Transit Market Research: A Practitioner's Guidebook. Washington, DC: The National Academies Press. doi: 10.17226/13917.
×
Page 32
Page 33
Suggested Citation:"Chapter 4 - Data Management, Reporting, and Staffing Considerations." National Academies of Sciences, Engineering, and Medicine. 2008. Leveraging ITS Data for Transit Market Research: A Practitioner's Guidebook. Washington, DC: The National Academies Press. doi: 10.17226/13917.
×
Page 33
Page 34
Suggested Citation:"Chapter 4 - Data Management, Reporting, and Staffing Considerations." National Academies of Sciences, Engineering, and Medicine. 2008. Leveraging ITS Data for Transit Market Research: A Practitioner's Guidebook. Washington, DC: The National Academies Press. doi: 10.17226/13917.
×
Page 34
Page 35
Suggested Citation:"Chapter 4 - Data Management, Reporting, and Staffing Considerations." National Academies of Sciences, Engineering, and Medicine. 2008. Leveraging ITS Data for Transit Market Research: A Practitioner's Guidebook. Washington, DC: The National Academies Press. doi: 10.17226/13917.
×
Page 35
Page 36
Suggested Citation:"Chapter 4 - Data Management, Reporting, and Staffing Considerations." National Academies of Sciences, Engineering, and Medicine. 2008. Leveraging ITS Data for Transit Market Research: A Practitioner's Guidebook. Washington, DC: The National Academies Press. doi: 10.17226/13917.
×
Page 36
Page 37
Suggested Citation:"Chapter 4 - Data Management, Reporting, and Staffing Considerations." National Academies of Sciences, Engineering, and Medicine. 2008. Leveraging ITS Data for Transit Market Research: A Practitioner's Guidebook. Washington, DC: The National Academies Press. doi: 10.17226/13917.
×
Page 37
Page 38
Suggested Citation:"Chapter 4 - Data Management, Reporting, and Staffing Considerations." National Academies of Sciences, Engineering, and Medicine. 2008. Leveraging ITS Data for Transit Market Research: A Practitioner's Guidebook. Washington, DC: The National Academies Press. doi: 10.17226/13917.
×
Page 38
Page 39
Suggested Citation:"Chapter 4 - Data Management, Reporting, and Staffing Considerations." National Academies of Sciences, Engineering, and Medicine. 2008. Leveraging ITS Data for Transit Market Research: A Practitioner's Guidebook. Washington, DC: The National Academies Press. doi: 10.17226/13917.
×
Page 39
Page 40
Suggested Citation:"Chapter 4 - Data Management, Reporting, and Staffing Considerations." National Academies of Sciences, Engineering, and Medicine. 2008. Leveraging ITS Data for Transit Market Research: A Practitioner's Guidebook. Washington, DC: The National Academies Press. doi: 10.17226/13917.
×
Page 40
Page 41
Suggested Citation:"Chapter 4 - Data Management, Reporting, and Staffing Considerations." National Academies of Sciences, Engineering, and Medicine. 2008. Leveraging ITS Data for Transit Market Research: A Practitioner's Guidebook. Washington, DC: The National Academies Press. doi: 10.17226/13917.
×
Page 41
Page 42
Suggested Citation:"Chapter 4 - Data Management, Reporting, and Staffing Considerations." National Academies of Sciences, Engineering, and Medicine. 2008. Leveraging ITS Data for Transit Market Research: A Practitioner's Guidebook. Washington, DC: The National Academies Press. doi: 10.17226/13917.
×
Page 42

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.

28 Effective use of ITS data to support and leverage transit mar- ket research depends on the development and maintenance of a diverse supporting infrastructure. Key elements of this infra- structure include an information system for archiving ITS data; enterprise-level applications, the most important of which in the context of this Guidebook is GIS; processes for screening and validating ITS data to ensure its integrity; software tools that support reporting and analysis; and human resources with the skills to maintain the infrastructure and, through analysis of ITS data, inform strategic decisions in marketing and other agency functions. This chapter addresses these infrastructure elements, which collectively separate ITS technologies from de- cisionmaking. When this infrastructure is properly developed and supported, the potential of ITS data to support research, inform decisions, and benefit customers can be realized. When the infrastructure includes gaps, inconsistencies, or incompat- ibilities, the potential benefits can be entirely lost. The presentation in this chapter draws on information re- covered in the 2005 survey of properties that had deployed or were planning to deploy the technologies covered in this Guidebook. It also draws on the experiences of the three case study properties, which collectively have succeeded in bridg- ing the technology-decisionmaking gap. Finally, the chapter draws on the literature related to each of the infrastructure elements. Enterprise Database Architecture Supporting the Use of ITS Data ITS technologies have the potential to provide substantial information to support and leverage transit market research. Among the transit agencies surveyed in 2005, the potential to provide information for market research was often reported to be blunted by problems with managing ITS data in a manner that allows marketing and others within the organization to readily use the data. Many of the properties surveyed did not have the capability to validate, organize, retrieve, share, and analyze the ITS data collected. Marketing was found to often rely on the “trickle down” of information collected by others. Thus, the frequently compromised capability to manage ITS data across the organization represents a crucial roadblock for market researchers seeking access to data. This section is intended to provide an overview and direction with respect to developing the enterprise or organizationwide tools and archi- tecture for managing ITS data. Current Data Practices At many of the properties surveyed, the collection of ITS data is done on a departmental or project specific basis. This information is used for specific applications and is not stored in a manner that allows others, such as marketing, to easily retrieve or share the information. While information can the- oretically be shared, it usually requires technical expertise and a level of effort that marketing typically does not have. There are a number of factors contributing to this problem, includ- ing the following: • Lack of budget • Lack of information technology (IT) tools, such as databases • Problems integrating proprietary ITS systems • Lack of expertise and technical support • Systems that are not capable of organizationwide data sharing • Poor or undeveloped relationships and communication between IT departments and other departments • Business practices and structures that have not adapted to the emerging ITS environment and lack direction To varying degrees, all the transit agencies surveyed in 2005 were dealing with one or more of these constraints. Most of the problems carry over from those identified in an earlier sur- vey of larger transit properties (Boldt 2000), which foresaw difficulties in accommodating expanding deployment of ITS C H A P T E R 4 Data Management, Reporting, and Staffing Considerations

technologies within the prevailing IT environment. Address- ing these constraints will require planning, time, effort, and resources as each organization evolves its IT function. The fol- lowing outline of a data architecture and strategy is intended to provide an overall direction for properties that are facing these problems. Enterprise Data Management This section provides general direction and guidelines for organizing ITS and other data to be used by practitioners. It defines an enterprise or an organizationwide approach. The guidelines follow general data management principles and provide a suggested architecture that has been discussed in the transit literature. Among the Guidebook’s case studies, Tri Met serves as a good example of a transit organization that has developed an enterprise data management architecture. A first step in enterprise data management is to develop a database design. The database design is a detailed plan for or- ganizing and structuring data maintained across the organi- zation. This is also called a database schema, with depictions of how the data are diagramed and charted. There are several reasons for developing a database design. Database designs facilitate organizing, storing, retrieving, and sharing the information across the organization. Basically, the database design shows how the whole organization will use, share, and sustain data over time when incorporated into database software. In order for a computer system to receive information from ITS or other systems, and process data in a consistent manner, the data that it receives from one or more places must be defined. The data must be defined such that the computer system knows what a data field means, in what for- mat the data is stored, and where it should store results. This is the purpose of a data model; it defines the organization of the information such that systems can understand what data resides therein, where it resides, how it is stored and how the data are related. Data models not only allow data sharing, they allow computer systems to work together. Fundamentally, the data model definition and how well the data model is defined will determine how well a computer system operates and how well it can share data with other systems and business do- mains. It is essential to define a well functioning database in order to write applications to address business problems. If a data model is not well defined, efforts to computerize prob- lem solving or to implement business improvements will likely be difficult and expensive, if not impossible. The process of defining a data model passes through three stages: • Conceptual definition • Logical model • Physical data model Conceptual definition consists of diagramming the data and relationships among the data to be stored. It is a starting point for organizing the data. A logical data model finalizes entities, fields, and relationships as tables, columns, relationships, and constraints. Given a logical data model, a physical database model can be created in a commercial database software product, such as Oracle or Sequel Server. Fortunately, in defining a data model, there are commer- cially available data modeling methodologies, computerized tools (e.g., computer-aided software engineering [CASE] tools), and an experienced skill set to facilitate the develop- ment. Even with commercial off-the-shelf (COTS) software products, designing a data model can take significant time. Depending on which methodology and tool(s) are chosen, starting at the very beginning involves first defining a con- ceptual model, then a logical model, followed by a physical model. However, given the industry examples, rarely does the process of defining an enterprise data model start from scratch with the conceptual model. Much work has already been performed in defining “starting point” models that can be used as inputs to defining an enterprise transit GIS-ITS- enterprise data model. Examples of these starting points are listed as follows: • GIS vendors publish industry standard models defined by consortiums. For example, ESRI public models include land, transportation, and address models (ESRI 2007). • Most IT organizations will have staff expertise and CASE tools to assist in developing data models. Since the process of designing an enterprise data model does not have to re-invent the wheel, a transit agency can benefit from what has been defined and proven in previous efforts. A typical approach in using existing models is one where the data maintained and used by an organization’s current and future processes (as foreseen or as defined in a “to-be” model) are compared with the starting point model(s). Gaps in what is defined in one or more of the start- ing point models are addressed as needed to define the target data model. This process is called “gap analysis.” Other inputs to the gap analysis process are the data requirements for existing or planned computerized systems. The enterprise data model design and system integration process must have a clear definition of the extent, or scope, of the data and systems that will initially be contributing and using data from the enterprise data model. In addition, the process needs to consider the data requirements of other busi- ness areas that will be included in the future. If a well-defined and bounded scope is not established, the data modeling process would stretch out indefinitely. It is best to start an enterprise data and system integration process/project involving a limited set of business areas in 29

order to prove the model and the integration methods prior to rolling the enterprise data model and associated system in- tegration into other areas of the organization. In other words, “start small and smart.” For example, an initial scope for an enterprise data model and system integration project could be defined as one that includes a subset of ITS data systems, GIS, and the use of ITS and GIS data by marketing personnel. In addition, the scope would include the impact of the enter- prise definition on other business units currently using ITS systems and GIS, such as Operations. Database Design and GIS Data Typically GIS data are also stored in an enterprise or relational database management system (RDBMS). GIS information, which is spatial in nature and robust in size, requires special consideration as a major aspect of the data- base design. In the GIS arena, physical entities are defined as objects with attributes, relationships, constraints, and be- haviors. Most GIS objects have spatial characteristics: geometries (points, lines, or polygons) and network topol- ogy. The network topology defines what object is connected to what other objects, as in a street network. In a street network, for example, the GIS database and spatial data manager knows that Main Street intersects with 1st Avenue at a specific location. A GIS supports the application of geometric functions (e.g., union, intersection of spatial ob- jects). For example, a GIS can determine the spatial rela- tionships of boundary objects, such as how many stops are contained within a particular zone. Enterprise data that are typically stored within a GIS in- clude the objects and their corresponding data plus a “land base” that provides a base map, which serves as a foundation on which transit-specific information can be overlain. Exam- ples of data typically found in a land base include • Streets and a street network; • Aerial photography; • Elevation contours; • Buildings; • Boundary data: zoning, blocks, states, county, tax, zip codes, lots, parcels; and • Census boundary information and census data. Combining ITS information and GIS information in the same database allows the ITS data to be related and analyzed by location. It should be noted that location values are de- fined in a specific coordinate system. If two or more systems contributing data to an enterprise database contain location coordinate values defined in different coordinate systems or projections, the differences can be reconciled with coordinate transformations or on-the-fly projections. An object in an enterprise data model may have attributes that are defined in multiple systems. In order to relate all pieces of information about a specific object/entity from multiple sys- tems, a common identifier is critical. A common identifier uniquely identifies one occurrence of an object from every other occurrence. The identifier may be made up of one or more fields in a database. For example, a stop location has an identifier that distinguishes it from all other stop locations. Given the spatial and object-oriented nature of GIS and ITS data, integration of the two offers a great opportunity for analysis. In addition, other external databases can be linked to an enterprise database for graphic display or analyses (e.g., census data, demographic datasets, or address data). Marketing may also have other data sources, currently used solely for their purposes, that have a “locational” characteris- tic that can be integrated with ITS and GIS data and provide the capability for analyses. The broad capabilities available with GIS spatial analysis tools and the data supplied by ITS technologies are ideal for application in the marketing arena. Some of the geographic and/or graphic analysis capabilities that a GIS can provide are • Thematic presentation, • Spatial overlays, • Proximity analysis, • Point density visualization, • Customer location, • Event or incident analysis, • Market segments or characteristics, and • Direct mail marketing. Using the Database The actual data model is structured within commercial RDBMS. The RDBMS serves as a repository for the data, as an analytical tool for retrieving information, and as a mech- anism for exchanging data between systems. Several of the ITS systems produce information in the for- mat of a RDBMS. This allows data, after validation or post- processing, to be transported into the RDBMS for storage and analysis. GIS systems use the RDBMS as a storage and re- trieval mechanism for data as well. In itself, the RDBMS can serve as a powerful standalone tool for retrieving ITS infor- mation and analyzing marketing data. When combined with GIS, it is a very powerful tool that can map the data as well. The main drawback with using these powerful tools are they are not “casual user” friendly and typically take considerable technical training or trained staff to manipulate the data. Most of the transit agencies interviewed in the course of selecting the case study properties for this Guidebook were hiring or culti- vating their own staff to orchestrate both RDBMS and GIS in an attempt to “get at the data.” Other agencies were relying on 30

their IT staff to facilitate analysis of the data. The key challenge is how to be able to put this information in the hands of casual users, like marketing staff, without expecting them to become expert users or continually relying on a few expert users to pro- duce the desired information. The way to address this critical challenge is to develop applications for both the RDBMS and the GIS that provide menu driven applications to allow casual users to use the sys- tems in a more “push button” environment. This approach will require working with IT or having technical resources set up this capability. A key objective should be to allow more peo- ple within the organization to access and analyze ITS data. Presently, the fact that these systems are expert systems has been a major constraint in getting the ITS and other data out to the people who can use it in the organization. ITS data will never realize its full potential if it cannot be used effectively by more people. At present, much of the market research potential of ITS data has been constrained, but could be lever- aged significantly by making the data readily available within a data management architecture that facilitates additional users. Architectures Supporting Data Integration Once the data have been organized and stored in a database, an architecture that will automatically provide for the inte- gration of data between various ITS and other systems can be defined. A database architecture, like a data warehouse, can provide for automated data collection, storage, archiving, and retrieval. This prevents the need for manual loading of all the information and ensures that current data are available. While this architecture takes some expertise and effort to set up, it will pay dividends to the users and also ensure a more sus- tainable system, costing less in the long run and saving the time and effort of continually loading data. The intent of this section is to provide an overview of data- base architectures that support enterprise data. It will present examples of the most common types of data transactions and how they are set up in relation to data architectures, such as data warehouses and data marts. Several database manage- ment terms will be used throughout this section. Defining the terms up front, as well as in context, may be helpful. Various definitions exist for these terms. However, for the purposes of this section, the following definitions are used: • Data Mart—a database that is most likely a departmental database that was designed to support a particular business function. Usually, each department or business unit is con- sidered the “owner” of its data mart, and they provide for maintenance of the data. This enables each department to use, manipulate and develop their data, without altering in- formation inside other data marts or the data warehouse. • Data Warehouse—a collection of individual databases across departments and business functions, specifically structured for organizationwide access to the data. The term “enterprise database” is analogous to data warehouse. • Data Repository—a common term and, for the purposes of this section, no distinction is made between a data ware- house and a data repository. • Federated Database—a federated database is much like a data warehouse except that the implementation of the fed- erated database integrates multiple autonomous databases into what looks like a single database. A federated database implementation provides a front end interface that stores or retrieves required data from all source data marts using a single query. While this is an option and has advantages for some organizations, it is not discussed here as a main- stream option for transit agencies due to the level of tech- nology required for construction and sustainability. The definition is included because it is discussed in the transit literature. Using ITS, GIS, and marketing data sources, proprietary databases and Relational Database Management Technology as examples, an enterprise database or a data warehouse can be set up designed from components such as the following: • Proprietary database(s) implemented as a set of files or defined within RDBMS BLOB for System A. BLOB (binary large object) is another storage mechanism for files with in the RDBMS. • Open database implemented within RDBMS for System B, which is an ITS system. • System C, which is a RDBMS ITS system, produces copious amounts of time-based data, which is stored in a database. • A GIS spatial database implemented in RDBMS with a spa- tial database manager “on top of” RDBMS (e.g., ESRI’s SDE [spatial database engine] or Oracle Spatial technology). • External datasets supplied in relational tables or flat files with known record definitions. This could be census data, addressing data, or customer data. • Systems that are considered to maintain and house confi- dential data or secured data in their databases (data marts) in proprietary or open database technology. Since System A has a proprietary database, data from System A will need to be exported or requested from System A in order to feed an enterprise database. In this case, there would be du- plicate data—data stored in the proprietary data mart and in the data warehouse. In cases like this, as well as others, clear data ownership needs to be defined amongst the enterprise user base. If more than one system needs to be able to update attributes or define new entities, then a complex data update process needs to be defined. Since many of the ITS systems are proprietary and 31

support their own data structures, data will need to be dupli- cated and organized in a format for enterprise use. In the case of ITS System B, its data mart is already in an open database platform (e.g., Oracle). If properly defined and of the necessary quality to support the enterprise database, System B’s data may be logically defined as part of the enter- prise database without duplicating the data. This approach works for ITS systems that are proprietary, but offer the abil- ity to report out data to RDBMS. In the case of ITS System C, massive amounts of data are produced and used by department(s). The data in System C may not necessarily be directly defined as part of the enterprise database, even if it resides in RDBMS. The enterprise organi- zation may not require the retrieval of the specific data stored in System C. To support the enterprise, data from System C’s data mart may need to be processed or summarized and then exported to the enterprise database for use by other units, such as marketing. One example would be AVL data. Typically mar- keting would not want all the AVL data because of the database size and its organization for operations. In this case, marketing would get summaries of the information they do want versus sorting through reams of data to pick out what they want. In an enterprise GIS implementation, and depending on the GIS technology, GIS data can be stored in an enterprise database, such as Oracle. However, to satisfy business requirements of a GIS (e.g., versioned data, spatially indexed data) and to perform GIS analyses on the spatial data, a spatial database manager must store and retrieve the data owned by GIS. Other databases (e.g., event data from mobile data recorders) can be linked to the GIS so that it can be analyzed with spatial functions. External datasets residing in Oracle or other enterprise database technologies can be integrated into the enterprise system much like System B’s data. Census or addressing data are examples. Data contained in confidential systems (e.g., customer billing data) or in systems needing secure access (e.g., finan- cial or accounting of fare revenues) will need to be extracted or requested from those systems and stored in accessible tables in the enterprise database. This way the whole database of the confidential system is not being used or entered in any way. Using these components, the enterprise database would consist of the inclusion of some system’s data marts, data ex- tracted from other system’s data marts, RDBMS resident data from some systems, and spatial data from GIS. The resulting enterprise database can be defined as the enterprise data ware- house, the combination of many different databases across an entire enterprise. Figure 4-1 depicts the methods for populat- ing the data warehouse using these examples. Access to the Data in the Warehouse Data can be written to, read from, or updated in the data warehouse using various methodologies. Systems can inte- grate with the data warehouse using various methods. 32 Enterprise Data Warehouse (e.g., Oracle) Enterprise Data Warehouse (e.g., Oracle)SystemA System B (ITS) System C (ITS) Pre- process Load Process Spatial Data Manager GIS Data Mart Customer Data Mart Confidential Information e.g., Census Data System’s B’s Data Mart System C’s Oracle Data Mart System C’s Data System B’s Data System A’s Data Census Data Subset of Customer Data GIS Data System A’s Data Mart Proprietary A process in System A extracts data and exports it for loading into the warehouse A subset of System B’s data is available as part of the warehouse A subset of the GIS data mart is data available as part of the warehouse System C extracts data from its large data mart and processes it (summarize, reduce, etc.) for storage in the data warehouse Files from External Sources CS (Customer System) GIS Figure 4-1. Population of the data warehouse.

Data Oriented Integration Techniques • File transfer • Extract, transform, and load (ETL) • Data replication Software or Service Oriented Integration Techniques • Web services • Remote procedure call integration/application program- ming interface (RPC/API) File transfers are simple data exchanges where a file from the source data mart is directly consumed by the target data- base/data warehouse, or the source system writes a file in a specific format for the target database/system to consume. In some cases, the source file is copied and placed in another location for the target system to use. The ETL method uses data extraction from the source data mart, processing of the data to transform it into the format expected by the target system, and then loading the resulting data into the target database. Data replication involves a more sophisticated source and target database management system. The data in the source system can be replicated for use in a target system. Updates to the data can be made in both systems. Changes originating in one system will be synchronized in the other. Web services can be written which access the data in the warehouse as needed by web users. The web interface and web services are designed such that the data organization and required access are hidden from the web user. Web services logically unify disparate data sources where necessary. RPC/API integration involves one system that supplies in- formation via a call from another system. RPCs and APIs de- fine how external applications can call a system and specify what information it wants returned from the system. RPCs and APIs are often provided by a commercial application and can be provided by custom applications. Each integration methodology has advantages and disad- vantages. In practice, multiple methods will often be used to interact with the data warehouse or with specific source/ target systems that participate in the warehouse. Figure 4-2 depicts various data access methods using the data warehouse as a central repository. Implementing Enterprise Data Management and Integration This section describes a strategy and a process for data management and integration that will result in more and bet- ter data being available for marketing and other functions within the organization. Following this strategy would bene- fit most of the transit organizations interviewed and would 33 Enterprise Data Warehouse (e.g., Oracle) Marketing Systems Census Data GIS Web Server Web Services MS Access (Department Application) Replication Processes Transform Replicated GIS Data Mart Marketing Analyses ET L ET L ETL Remote GIS Desktop / Mobile Application GIS Data Mart World Wide Web ODBC (API) ODBC (API) Spatial Data Manager GIS System A’s Data Subset of Customer Data System B’s Data System C’s Data GIS Data Figure 4-2. Data access and integration.

allow greater leveraging of ITS data. Developing an enterprise data strategy requires resources, planning, time and expertise on the front end, but will result in overall savings over time by providing a sustainable system that allows more people to access better data without forcing practitioners to become expert users or hiring more technology staff to support daily efforts. Ideally, the departments within a transit organization would work with their IT department to enlist the expertise needed to construct an enterprise data strategy. The overall goal in presenting an overview of enterprise data manage- ment has been to sketch a set of general guidelines and to out- line the tasks and issues involved. End user departments will need to assist in specifying the relevant data and uses for that data. Typically, success requires a joint effort of users and IT professionals. ITS Data Validation To ensure accuracy and integrity, ITS data recovered from on-board systems must be validated before being forwarded to the enterprise data system. An essential task in this process involves matching vehicles’ AVL data records to their sched- ules and the base map of stops and time points associated with assigned work. Selected event data recorded at locations other than those represented in the base map must also be assigned to base map locations. Examples of such events include instances where a vehicle drops off or picks up passengers be- tween scheduled stops, records for temporary re-routes, the record of a vehicle’s maximum speed between stops, or a non- stop event record reported by a mobile data terminal or elec- tronic registering farebox. Data are also screened to identify extreme values, which may indicate a malfunctioning unit. Records with extreme values are retained, but flagged to indi- cate that the data are suspect and may be unusable. Validation of passenger loads and boarding and alighting count data from APCs is especially important, given the need for accuracy of these data in meeting external and internal re- porting needs. For passenger loads, a procedure must be in place to “zero out” the totals at defined service junctures, rang- ing from the conclusion of a vehicle’s daily assigned work to the completion of each trip. A routine must then be implemented to proportionately adjust boarding and alighting data to be consistent with the passenger load zeroing adjustment (Furth et al. 2006). It is worthwhile to verify the accuracy of the actual boarding and alighting counts recorded by APCs, in the system accept- ance process and periodically thereafter. Some properties test accuracy by comparing APC counts against those recorded by ride checkers. The maintained assumption that ride checker counts are error-free is a strong one, however. An alternative to reliance on ride checker counts was used by Kimpel et al. (2003), who compared boarding and alighting counts recorded by TriMet’s APCs against counts recorded by on-board cam- eras directed at vehicles’ doors. Given verification of the accuracy of APCs, this system can then be used to assess the accuracy of other on-board systems. For example, the CTA intends to check transaction summaries recorded by its smart card, magnetic card, and electronic registering fareboxes against corresponding APC counts. Operator-keyed data from electronic registering fareboxes and mobile data terminals are probably subject to the great- est amount of error among on-board systems in terms of doc- umenting the actual incidence of represented events. The transit literature does not report attempts to validate event data, although analysts at the case study properties noted that they were wary of interpretations where event data are treated as “ground truth.” There are several possible ways of assessing the validity of operator-keyed event data. One would be to assign “silent shoppers” to a sample of trips to record selected events, and then compare the manually recorded data against the operator- keyed data. Another approach that would likely improve va- lidity would be to develop a data screening process to identify instances where multiple specific events are keyed at the same time or location, recognizing that in some cases (e.g., fare eva- sions) multiple events can be valid. However, the operator training process probably offers the best opportunity for en- suring the validity of event data. In this setting, it can be em- phasized that recording events is not simply a part of the job; rather, it is providing information that can often be used to improve the conditions of operators’ assignments, including their safety and security. In the customer service area, ITS data can be applied beyond its common use in validating customer complaints. For example, actual arrival time data from AVL can be com- pared to arrival times predicted by real time arrival software to assess the accuracy and reliability of the predictions (Crout 2007). Such analysis can also contribute to determining how far out arrive time predictions can be accurately and reliably made. Reporting and Analysis Tools Reporting and analysis tools drawing on archived ITS data can be grouped into three categories: those developed by the ITS vendor, those developed in-house, and those developed by a third party software vendor. ITS vendor developed reporting software is available for ticket vending machines, electronic registering fareboxes, and AVL and APC systems. The software for ticket vending ma- chines and fareboxes report transactions data, as described in Chapter 2 of the Guidebook. Farebox software can also report operator-keyed events for systems that include this function- 34

ality. Furth et al. (2006) conclude that farebox reporting soft- ware is very inflexible, and that properties desiring to use farebox data to monitor ridership have to first export data from the farebox system to a database developed in-house in order to structure reports. Vendor developed performance reporting software for AVL-APC systems is a fairly recent addition to the transit in- dustry. This software is in use among properties of varying size, but appears to be especially welcomed by smaller prop- erties with limited IT resources. Previously, vendor-provided AVL reporting software was limited to data “playback” rou- tines that were useful for investigating incidents and customer complaints, but had very limited capability to support offline performance reporting and analysis. More generally, the development of reporting software by ITS vendors reflects a change in their role in the technology life cycle. As Furth et al. (2006: 71) observed, in the initial phase of advanced technology deployment in the industry, technology vendors viewed their principal role as being providers of hardware, and “their job ended when they handed the transit agency the data.” Whether the data could be rationalized and transformed into desired reports was an issue that was usually left to the transit property to resolve. Consequently, in the 1990s era of ITS deployment, many properties struggled to produce useful performance reports (Casey 2000). The most important of the vendor-developed reporting packages covers data from AVL and APC systems. An exam- ple summarizing weekday service delivery performance on the Denver Regional Transportation District’s South Broad- way route in October 2005 is shown in Figure 4-3. The report provides information that operations managers usually track in assessing service delivery, including on-time performance, boardings per mile and hour of revenue service, and actual average speed compared to schedule speed. Passenger activ- ity is also reported by service period, and data are sorted to identify to most heavily used stops. Sorting by performance category (boardings per revenue hour in this example) can produce rankings among scheduled trips. Finally, perform- ance for selected trips is reported. Vendor-developed reporting software is very useful for communicating performance information at the managerial levels of the organization. Its data querying capabilities be- yond this important function, however, are limited. Thus, some properties have developed more flexible performance reporting systems in-house. It should be noted that in-house reporting systems were often originally developed out of necessity and were mostly confined to larger properties where staff with the necessary advanced database querying skills were in place. The main advantage of the reporting systems developed in- house is that they can be structured to produce performance indicators of specific interest to the agency. Moreover, as in- terests in specific aspects of performance evolve, the report- ing system can be readily modified to evolve in tandem. Generally, the data queries programmed within in-house reporting systems can be structured to address virtually any question represented in the space-time-customer dimensions of the ITS database. TriMet’s experience with its in-house reporting system is approaching the 10-year mark. The system is considered to be among the most comprehensive in the transit industry (Furth et al. 2006), and its periodic performance reports include indicators that have been designed to correspond to service delivery attributes that the agency’s satisfaction sur- veys have found to be important to customers. An example is shown in Table 4-1. TriMet surveys found that reliability issues were the second most important source of dissatisfaction among bus riders (after frequency of service issues). Table 4-1 provides informa- tion on three alternative reliability measures. The first, on-time performance, is the transit industry’s traditional measure of reliability. The second, headway adherence, reports the per- centage of trips that maintain an actual headway that is within 50% of the scheduled headway. This proxy measures the spac- ing or regularity of service. The third reliability proxy, excess wait, measures the additional time a typical rider would spend waiting for a bus given the actual headway deviations docu- mented in the AVL data. The three measures of reliability often correspond, but not always. For example, the Route 64-Marquam Hill achieves high marks for on-time performance and headway adher- ence, but fares much worse on the excess wait measure. The same is true for the Route 51-Vista. It could be argued that the excess wait measure best represents a rider’s view of reli- ability. However, the choice of indicator could just as well be informed empirically by relating the variation of each indica- tor over the routes in the system to the route variation in sur- veyed satisfaction. In this case, the “best” customer-oriented measure would be the one that most closely corresponds to riders’ reported satisfaction. Reporting and analysis software developed by third party vendors range from fairly elementary packages that docu- ment Web and automated telephone system activity to more advanced packages that support statistical and spatial analy- sis of data extracted from an enterprise database. Data recov- ered by Web and automated telephone system monitoring software are described in Chapter 2 of the Guidebook. In their most elementary applications, statistical software packages allow researchers to logically summarize ITS data and report patterns and trends. More advanced applications involve estimation of systematic relationships among ITS data elements within user-defined contexts. An important feature of a statistical software package is its ability to easily 35

extract data from an agency’s ITS database. At TriMet, re- searchers in the operations division use statistical analysis software (SAS) for advanced analysis of ITS data. The main advantage of this package is that its programming features allow analysts to directly query the Oracle data tables in the agency’s enterprise data system and create data records that can then be easily imported for statistical analysis. Another advantage of this software package is its extensive graphing capability, which supports more effective communication of trends and patterns. An example report from TriMet illustrating SAS graphing features is shown in Figure 4-4. This report is produced for 36 Figure 4-3. Summary route performance report from vendor-developed software.

operations managers, with the tables containing weekly per- formance statistics and the graphs showing longer term pat- terns and trends. In this instance, previous statistical analysis had determined that the incidence of bus bunching in the sys- tem was strongly related to late pullouts from garages and late departures from route terminals following layovers. The trend improvements in late pullouts and departures shown in the figure suggest that the reports have served their purpose in focusing the attention of garage managers and field supervisors on the attendant problems. The transit industry’s use of GIS for spatial analysis of ITS data and for related mapping of service delivery and market phenomena is evolving. A 2003 survey found over 75% of re- sponding transit agencies employing GIS in a broad range of applications (Sutton 2004). Advances in the use of GIS in the transit industry parallel the emergence of the more general field, GIS for Transportation (GIS-T), that has developed advanced applications in transportation research, planning, and management (Thill 2000, Miller and Shaw 2001). According to Sutton (2004), there are three levels of GIS in- tegration within transit organizations, distinguished by the level of applications that must be supported: (1) specific project applications; (2) use as a departmental resource in support of established practices such as planning, scheduling, and real time bus operations; and (3) use as an enterprise system where GIS is incorporated into an agency’s information technology (IT) infrastructure. Over time, the trend in GIS architecture has evolved in the transit industry toward enterprise level systems, managed within the IT environment and coordinated with the management of an enterprise database. As explained earlier in this chapter, with a well-designed data model relating trans- portation features and attributes to ITS data tables, agencywide access to archived data for GIS applications is ensured. Institutional Issues The overall organizational structure and management phi- losophy have direct impacts on the ability of a transit agency to leverage ITS data for market research. An organization that is characterized by a lack of cross-divisional cooperation or is less open to change will need stronger leadership to create an environment where ITS data can be effectively integrated into agency functions. Similarly, if an agency has not yet made the shift to customer orientation using market research, the organizational structure will not be present to take full advan- tage of the benefits of ITS data. This section examines the in- stitutional issues surrounding successful ITS implementation with respect to leveraging ITS data for market research. Focus on the Customer The transit industry has seen a surge in the focus on cus- tomers, with many properties citing this as the reason behind ridership success in recent years. TCRP Report 111, “Elements 37 Route, Direction, Time of Day Daily Trips On Time Early Late Scheduled Headway Headway Adherence Excess Wait (min.) 8-NE 15th Ave - Outbound – PM Peak 14.0 45% 3% 52% 8:58 48% 3:27 4-Fessenden - Outbound - PM Peak 10.0 46% 4% 50% 12:37 49% 3:27 15-Belmont - Outbound - PM Peak 20.0 63% 2% 34% 6:14 49% 3:15 8-Jackson Park - Inbound - PM Peak 15.0 57% 1% 42% 8:19 47% 3:10 96-Tualatin/I-5 - Outbound - PM Peak 10.0 60% 0% 40% 10:57 67% 2:47 64-Marquam Hill/Tigard TC - Inbound - AM Peak 5.0 96% 0% 4% 19:50 90% 2:43 4-Division - Outbound - PM Peak 15.0 65% 6% 29% 7:58 54% 2:33 4-Division - Inbound - PM Peak 10.0 67% 4% 29% 12:43 59% 2:23 51-Vista - Inbound - AM Peak 8.4 89% 8% 2% 17:05 91% 2:11 20-Burnside/Stark - Outbound - PM Peak 7.0 66% 6% 27% 15:14 75% 2:07 17-Holgate - Outbound - PM Peak 11.0 59% 7% 33% 11:00 65% 2:07 94-Sherwood/Pacific Hwy Express - Outbound - PM Peak 14.0 73% 0% 26% 9:21 66% 2:05 72-Killingsworth/82nd Ave - Inbound - PM Peak 16.0 73% 7% 20% 7:42 50% 2:02 99-McLoughlin Express - Outbound - PM Peak 8.0 86% 0% 14% 17:09 84% 1:59 17-NW 21st Ave/St Helens Rd - Outbound - PM Peak 8.0 42% 3% 55% 15:00 75% 1:51 15-NW 23rd Ave - Outbound - Midday 31.0 53% 8% 39% 13:27 65% 1:48 4-Division - Inbound - AM Peak 15.0 89% 2% 9% 7:48 59% 1:43 32-Oatfield - Outbound - PM Peak 6.0 74% 4% 22% 24:34 88% 1:43 9-Powell - Outbound - PM Peak 14.0 62% 7% 32% 8:03 64% 1:42 12-Barbur Blvd - Outbound - Night 19.0 64% 3% 33% 20:08 81% 1:39 71-60th Ave/122nd Ave - Inbound - Midday 27.0 82% 5% 14% 16:18 76% 1:39 15-NW 23rd Ave - Outbound - PM Peak 8.0 48% 8% 44% 15:00 70% 1:38 4-Fessenden - Outbound - Night 23.0 71% 5% 24% 19:52 83% 1:34 72-Killingsworth/82nd Ave - Outbound - PM Peak 16.0 80% 5% 15% 7:43 58% 1:34 8-Jackson Park - Outbound - Midday 32.0 71% 3% 27% 13:11 80% 1:33 15-NW 23rd Ave - Outbound - AM Peak 22.0 72% 5% 24% 5:42 49% 1:33 Table 4-1. Headway adherence and excess wait time, spring 2007 (sorted by excess wait time).

Needed to Create High-Ridership Transit Systems” (Tran- Systems et al. 2007) summarizes the successful marketing ef- forts pursued by transit agencies. Yet the survey conducted for this Guidebook revealed that few agencies have market research programs that rigorously analyze customer needs and expecta- tions. Those with strong research programs are typically larger properties, such as New York City (MTA-NYCTA), Chicago (CTA), Washington, D.C. (WMATA), San Francisco (BART), and Portland (TriMet). For many properties, market research is confined to ridership counts and customer service activity ad- dressing complaints and suggestions. ITS data can leverage market research, but only when that function is fully developed. 38 Figure 4-4. Graphical presentation of service delivery information at TriMet.

Thus, there is still a need for transit industry top manage- ment to become active supporters of market research, by requiring decisions to be made based on customer research, and by providing funding to conduct the needed research. This will require two levels of commitment: (1) funds to hire research firms that can provide project development, fielding, analysis, and/or report writing; and more important, (2) knowledgeable in-house staff that understand the transit business and specific project needs and oversee the activities of the consultant. By requiring customer understanding through market research, the transit industry can truly say it is customer oriented. The agencies will be able to take maxi- mum advantage of traditional and ITS data sources and greatly increase their success in building ridership. The case studies of CTA and TriMet (see Appendices A and C) document a level of commitment to the customer through an extensive market research program and demon- strate how ITS data can support and enhance the market research functions. Role of Senior Management Senior management involvement is critical to the success of integrating ITS with agency needs, ensuring that the resources and staff are there to support post-ITS deployment needs re- lated to data management and end use analysis in market research. A key issue is to ensure that individual divisional pri- orities do not come at the expense of other agency needs. Operations, Marketing, IT, Finance, and other divisions need to be included from the initial planning of the systems to ensure that they understand the data potential and are involved in the development of the ITS and data management systems. An in- terdivisional team needs to be established that includes all potential users of the system. Senior management support is needed to ensure that the team does not ignore non-operational needs in the interests of expediency or cost savings. Not only is senior management needed to ensure interdivi- sional teamwork, it is needed to support the budget require- ments of the system. To effectively plan a system that can be used by all departments within the agency will require devel- opment of an enterprise database system, an agency activity that requires resources. Senior management’s commitment is necessary to ensure that there are the resources to develop an enterprise database, provide the system requirements to store the vast amounts of data produced by ITS, and provide the on- going technical staff to develop and maintain the enterprise data system. A unique cross-competency exists with Madison Metro’s general manager, who was directly involved in ITS procure- ment for the state. This experience allowed him to more effec- tively market ITS as a direct investment in customer service and improved operations. With that mindset at the top of the organization, it is likely that the agency is not simply seeking to use the data for market research as an afterthought, but more as a primary reason for implementing ITS. Need for Interdepartmental Coordination Transit properties typically enter the ITS arena through the purchase of operational systems, usually an AVL system to support bus dispatch. Other systems, such as APCs, are fre- quently purchased as an add-on to AVL. Because these sys- tems are conceived in operations they are often specified, purchased, and deployed without involvement from the rest of the agency. This leads to a system that is isolated from other uses. Data are considered only in how they are needed for the originally intended task. The result is that data may be saved in a format that makes them of little use for marketers, or perhaps they are not saved at all. Madison Metro’s success represents a counter-example of the tendency to isolate ITS planning within operations. On fixed route bus service they have recently implemented AVL, APC, and magnetic stripe card systems on their fleet of 200 vehicles. The relatively flat organizational structure allowed the marketing department to be on a similar level as the tran- sit department, which is in charge of operations and plan- ning. Because the city and all its agencies are supported by the Information Service Unit, GIS has been integrated into tran- sit ITS and market research data. At the CTA, staff bolstered interdivisional cooperation with industry peer exchanges. They have interacted closely with TriMet and King County Metro through the U.S. DOT/FTA-sponsored Peer-to-Peer Development program (Gross et al., 2003). This program facilitates the sharing of best practices regarding transit use of ITS data and allowed CTA to learn from efforts at other transit districts, as well as share their own experiences. Few, if any, transit properties in the U.S. have developed a service delivery analysis and monitoring capability compara- ble to what TriMet has achieved with its archived AVL and APC data. These achievements are a consequence of the fore- thought given to the specification of the data recovery and archiving features of their AVL-APC systems, the high pene- tration of APC units in the fleet, and the efforts of highly skilled staff analysts. Also, despite their organizational sepa- ration, market research and operations collaborated exten- sively in designing customer-oriented service performance measures for evaluating service delivery. ITS Data Use and the Placement of Market Research Within the Institution IT and Market Research are typically located in different divisions or departments within the organization. As such, 39

market researchers are sometimes not included in the devel- opment of the data archiving architecture, and may not even know what data exist. Even when they become aware of the existence of ITS data, they may not have the skills to extract the data that could assist in market research activities. IT staff are typically assigned to tasks considered higher priority (e.g., operations support or financial systems) and provide market research support only as time is available. Two ap- proaches to mitigating these impacts are described. One approach is to create a data manager. The role of a data manager is to abstract and summarize data—making data available and legible for all users to understand and use. Potential users include the public, peer transit agencies, market researchers, and in-house groups. The need to find common ground for culling and presenting these data to the varied users makes decisionmaking capabilities and team- building skills desirable for data mangers, although these are not necessarily sought after in data-oriented positions. The data manager may want to create a collaborative process that ensures the needs of all users are met through ITS data collection—coordination with service planners, market re- searchers, analysts—to generate a comprehensive database that serves many needs. The CTA provides a successful alternative approach, using technically savvy staff within the market research area to pro- vide data support. When the case study was conducted, the CTA had been using ITS data for 3 years. Despite its large size, the CTA maintained an effective market research department with a staff comparable in numbers to smaller agencies. Dur- ing the initial deployment of smart cards, AVL, and APCs, the CTA created the Data Services unit, which was responsible for post processing, merging data from various systems, and de- veloping tools for data analysis. Recently, staff from data ser- vices was transferred to IT for the post-processing function, while several analysts remained in Data Services to conduct actual analysis. The effect of splitting these related job func- tions into separate departments is unclear, but CTA staff point to the data services unit as crucial in their success. They said it helped bridge the gap between the Management & Perfor- mance division (where IT resides) and market research staff. Opportunities for Properties That Outsource Market Research Activities ITS data analysis and market research are often viewed as activities that are only for larger districts, such as Portland and Chicago. Madison Metro provides an example of how a smaller agency with a lean staff can capitalize on the benefits of ITS for market research activities. Madison has been successful in drawing on its ITS data to improve timetables and to identify a priority list of bus stop im- provements and advertising opportunities based on stop-level passenger counts. In the 2 years since Madison implemented ITS on its buses, it has not yet fulfilled all the goals of the agency. Staff at Madison Metro seek to get a better under- standing of the university student population and their trip patterns when school is in session. This understanding would help the agency better cope with the tremendous change in ridership numbers when school is not in session. The rider- ship numbers also support the negotiation of pass program agreements. Another option that is especially applicable to small districts in university towns is to enlist the help of the educational in- stitution. Interns can be a way to capitalize on the intellectual resources of nearby universities, although it must be recog- nized that such programs will require agency staff time to support the program. The investment can have a secondary benefit, however, in providing a potential pool of transit-savvy employees after graduation. Improving the Use of ITS Data for Market Research Once ITS data are archived in a database, it is a challenge to integrate the data into operations and market research re- porting and decisionmaking. The CTA discusses other rea- sons for the ongoing success of its program. One is the series of “what’s new” brown bag seminars that allow data services staff to show agency staff new applications and uses of data. Similarly, these seminars provide an open forum for staff to make requests so that data services has a better understand- ing of what is needed for the future. Another positive aspect of Chicago’s ITS approach is the for- mal relationship with MIT and University of Illinois-Chicago, through which CTA employs master’s program interns. Those still in school are in the mindset to think critically about prob- lems and help develop innovative approaches to solving them. In the same spirit, thesis students are brought on for two sum- mers. In the first, they learn about the industry and agency while identifying an underlying problem and, in the second, they attempt to solve it in their thesis. This research develops innovative prototype applications of ITS data that can eventu- ally evolve into adopted practices. This helps bridge the gap between innovation and implementation. The program is also a good source for qualified full-time staff candidates. Staffing Issues Bridging the Gap Between Market Research and IT Two significant problems with ITS data are (1) the diffi- culty in integrating ITS data across different applications and (2) that ITS data are not easily exported to formats that can 40

be analyzed in standard desktop software applications (e.g., spreadsheets). The inability to integrate data was cited as the top perceived barrier to using ITS data for transit market re- search in the industry survey conducted for the Guidebook. ITS has the ability to enhance service and improve con- nections across departments within and external to the transit agency. The ITS Joint Programs Office of the U.S. Depart- ment of Transportation writes in its report, Building Profes- sional Capacity in ITS: An Assessment of ITS Training and Education Needs: The Transit Experience, that ITS requires agencies to change their mission and approach to operations as advanced technology deployments become more inter- agency and systems-oriented. The report discusses internal barriers to effective use of ITS data, for example, being nar- rowly defined job functions and overall missions, as well as limited emphasis on funding for training and development. The report, released in 1999, recognized early on the difficul- ties of hiring and retaining qualified computer and systems engineers. A critical element of the evolution toward integration of market research and ITS data is having staff that can bridge the gap between research and information technology. The role of a data manager is someone who is comfortable using information technology to draw from a number of sources of data and who can use datasets for a variety of purposes. Given the need for increased access of market researchers to the en- terprise database, the role of market researcher should be ex- panded to include the functions of a data manager. From a staffing point of view, an ideal employee would be trained as a market researcher who is also capable of extracting data from proprietary sources for secondary analysis. A person who could satisfy these requirements would find several op- portunities in what has been referred to in literature as “data management.” IT and data management are related, but dis- tinct. While IT personnel maintain computer networks and database systems, a data manager is concerned specifically with the data from ITS sources. These two positions are often confused within the transit environment and by transit agency managers, causing agencies to be hesitant or unwill- ing to hire what is mistakenly believed to be a second person to fill a data management position. An institution must be willing to see the data manager as a viable addition to disseminate and target information based on new data, technology, and sources, and as a person able to create stronger internal and external networks. The role of a data manager should be defined and understood so that a re- lationship can be developed based on reasonable expectations rather than tasks outside the scope of a data manager’s job de- scription. Unfortunately, there is very often a lag between the time that ITS is deployed and the hiring of a data manager. A data manager is most effective when hired before data are defined or collected, which allows the data manager to facili- tate the identification of optimal types of data and data col- lection sources. Ideally, a data manager, in conjunction with the agency staff and other stakeholders, will define the goals and objectives of the ITS system. However, as a result of tech- nology often outpacing the ability for agencies to hire and uti- lize a data manager, more often the case is that data collection is already in process and the manager is hired later, giving this individual less opportunity to coordinate the different appli- cations. In these situations, a data manager is limited in his/her ability to extract meaningful trends and performance indicators from data that were defined before he/she was brought on. A transit agency attempting to better integrate a data man- ager into its institution should consider the role it wishes the manager to play, the opportunities it intends to provide, and the best way to integrate the manager into the agency. The importance of data management should not be overlooked, and the successful transit agency will see the hiring of a data manager as an investment in a more effective system in the future. Recruiting and Retaining IT Staff and Data Analysts Historically, it has been difficult for transit agencies to at- tract and retain IT staff. In Research Results Digest Number 45, “Identification of the Critical Workforce Development Issues in the Transit Industry,” (TCRP 2001) both marketing and IT professionals are cited as difficult to attract and retain in the industry. Because IT is a secondary accessory to the transit industry (that is, not a core skill such as engineering, mainte- nance, and operations), many do not view the transit indus- try as a good choice for a place to pursue a career in IT. Another challenge to attracting IT professionals is the per- ception that there is greater potential for growth and income in other industries, especially in the private sector. Some agencies have found the most effective means of re- taining quality IT staff is by employing a “grow our own” strategy. Houston Metro uses this strategy, as discussed in TCRP Report 77, “ Managing Transit’s Workforce in the New Millennium” (McGlothin Davis and Corporate Strategies 2002), with the concept being that a transit agency will pro- vide a fast-paced and exciting work environment that excels in providing new opportunities and job growth potential, focus- ing on retention and training rather than hiring specifically for a set of skills. The message that “employees will be involved in exciting work using up-to-date methods and resources” is re- inforced by ensuring that “promises of interesting work and the use of state-of-the-art technology are kept.” Additionally, offering regular in-service training will help to keep workers up-to-date and contribute to the feeling that the industry is progressing with technology. Other transit agencies have 41

echoed the concern over attracting the highest level of em- ployees for this profession, such as the Santa Clara Valley Transportation Authority, which stated in the same report that they strive to get the message out about having up-to-date technology and providing interesting work early in careers. Others have used salary incentives to attract high-level pro- fessionals, but this is limited in effectiveness for a potential employee who may have pre-conceived notions of the nature of the work being offered. Another successful effort highlighted in TCRP Report 77 is a program used by Metro-North Railroad called the “Integrated Approach to Recruiting, Training and Retaining Information Technology Professionals.” In this recruiting program, “avail- able positions were designed to be broader with more variety rather than a single task.” These positions also include a job- progression calendar that projects upward movement oppor- tunities and depicts the timeframes within which a good employee can expect to advance. Also, employees’ opportuni- ties to advance are not limited to managerial roles; they may instead become mentors and sources of technical knowledge for new hires. Benefits widely used in the private sector add to success, including flextime, dress-down day, and limited telecommuting. Among other rewards, top performers receive additional training. 42

Next: Chapter 5 - Lessons Learned, Issues, and Concerns »
Leveraging ITS Data for Transit Market Research: A Practitioner's Guidebook Get This Book
×
MyNAP members save 10% online.
Login or Register to save!
Download Free PDF

TRB's Transit Cooperative Research Program (TCRP) Report 126: Leveraging ITS Data for Transit Market Research: A Practitioner's Guidebook examines intelligent transportation systems (ITS) and Transit ITS technologies currently in use, explores their potential to provide market research data, and presents methods for collecting and analyzing these data. The guidebook also highlights three case studies that illustrate how ITS data have been used to improve market research practices.

  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!