DRAFT_NTD PROGRAM SUPPORT_SOW.docx

Federal Transit Administration (FTA)

National Transit Database Program Support

Draft Statement of Work (SOW)

United States (U.S.) Department of Transportation (DOT) Federal Transit Administration (FTA) 1200 New Jersey Avenue, SE Washington, D.C. 20590

Table of Contents

1. Introduction and Background Introduction to this Request for Information

FTA’s National Transit Database (NTD) was created to help meet the needs of individual public transportation systems, all levels of government, and the public for information on which to base public transportation service planning. It is the Nation’s primary repository of public transportation data. The NTD collects financial data, operating statistics, safety events, and asset conditions from American transit systems. FTA uses NTD data to apportion funding to urbanized and rural areas in the United States, to inform decision makers at all levels of government, and for research purposes.

FTA intends to procure program support services for the NTD. FTA is publishing this Request for Information (RFI) to obtain capabilities packages from potential, interested parties. Capabilities packages must contain specific, detailed information regarding the company’s existing experience in relation to contract line item numbers (CLINs) shown in Section III below. An existing contractor (the incumbent) currently performs the work described in this RFI.

NTD Program

NTD support services consist of three primary functions:

· Data Collection

· Validation

· Data Products

Data Collection The NTD program requires technical assistance to facilitate data collection. The NTD is a longitudinal survey—it collects data for the same operators year after year.[footnoteRef:2] However, each agency may have different users who report this data. This makes data collection and validation challenging since these users change often, and FTA’s requirements to report this data involve complex NTD classifications and terminology.[footnoteRef:3] Therefore the NTD program provides significant technical assistance and training to its client users each year. [2: For the purposes of this RFI, FTA refers to organizations that report to the NTD as “transit agencies” for simplicity and ease of reading. However, not all organizations that report to the NTD are “agencies.” For instance, some organizations may be private companies or divisions of a government agency.] [3: A full description of the different geographic, agencies that report to the NTD (reporters) is listed in the NTD’s annual reporting manual, which can be found here: https://www.transit.dot.gov/ntd/2020-ntd-reporting-policy-manual.]

Validation The NTD program validates the submitted data. Validation is a critical program component, in part because of the billions of dollars of Congressional funding that rely on NTD data each year. Data is validated at two different points: (1) in real time when a user initially enters the data on the NTD website; and (2) using NTD’s Branch Environment database (described further below).

Data Products The NTD program uses validated data to produce apportionment and other data products. There are approximately 15 apportionment data products and two portable document format (PDF) data products (CLIN 0005) produced on an annual basis.[footnoteRef:4] There are also approximately 20 special analysis data products produced at various times during the year (CLIN 0010). [4: NTD data products listed on the following NTD Data webpage are not covered in this RFI: https://www.transit.dot.gov/ntd/ntd-data. FTA will ensure that future contractors will have access to data related to these data products throughout the year through the Branch database before it is published online. ]

General Information

1. NTD Data: From Data Collection to Data Product

The NTD data process begins when transit agency staff input data into the NTD reporting website.[footnoteRef:5] This website uses the Appian cloud computing enterprise software application. The website prompts a transit agency user to complete and submit NTD forms. FTA publishes a user guide that describes how users can enter all of their data.[footnoteRef:6] Once submitted, FTA validates the data before publishing the data in different data products. [5: https://www.transit.dot.gov/ntd/national-transit-reporting-tool] [6: https://www.transit.dot.gov/sites/fta.dot.gov/files/2020-09/2020%20NTD%20Annual%20Reporting%20User%20Guide.pdf ]

1. Information Technology (IT) and Data-Related Processes

The NTD program primarily relies on two databases: (1) Appian database (‘Appian’), and (2) Branch Environment database (‘Branch’).[footnoteRef:7] [7: There are actually multiple databases in Appian. However, for simplicity for this RFI, all Appian databases are referred to as a single database as they largely contain the same data.]

Appian Database The Appian Cloud is a platform-as-a-service (PaaS) solution that collects and houses NTD data using a MySQL database. Appian houses NTD’s transactional database for data collection and serves as the NTD system of record. Appian serves as the ‘front end’ to the NTD. After a user submits NTD data, FTA moves the collected data through a pipeline of extract transform and load processes. These processes create copies of Appian database data in the Branch Environment database.

Branch Environment Database The Branch Environment (‘Branch’) is an on-premise database housed at the Department of Transportation (DOT). Its purpose is to perform data validation and data production. It is a separate database from ‘Appian.’

Branch houses a copy of NTD data and other database objects. FTA’s Office of Administration (TAD) owns and is responsible to make Branch accessible from an IT security perspective. FTA grants the incumbent permission to manage individual database schemas to perform data validation and data production as needed. These permissions include:

· Creating database objects

· Managing processes such as stored procedures

· Creating, executing, and updating queries

· Accessing draft data collected but not yet published in publicly facing data products

All data, database objects, code, and related documentation are owned by FTA. Branch is currently a MySQL database, but FTA may transition it to a different database type in the next year.

IT Roles and Responsibilities Two FTA offices have IT-related roles and responsibilities. First, TAD is primarily responsible for the NTD’s Appian day-to-day functionality. TAD is responsible for ensuring that the NTD Appian site is live, active, and readily available for users to submit their data. TAD is also responsible for all development and enhancements for the Appian database. The incumbent is responsible for ensuring that the captured data is accurate.

The second FTA office is the Office of Budget and Policy (TBP). With respect to NTD IT services, TBP’s role is that of a client. TBP staff and its incumbent oversee the programmatic aspects of the NTD, including all business requirements, data collection, validation, and data products. TAD and TBP hold re-occurring coordination meetings.

Many issues involve shared responsibility between TAD, TBP, and their contractors. For instance, if a user encounters an error, and the incumbent detects the error, the incumbent is responsible for creating a TAD support ticket. TAD is responsible for identifying a root cause and fixing the issue. The incumbent helps TAD prioritize all of the detected errors.

TBP and the incumbent interact with the Branch database, and TAD provides software and support to connect to Branch at no cost to the incumbent. TBP and the incumbent execute all queries on the Branch Environment. TBP and TAD also provide access to Branch so that the incumbent is able to access draft data that supports future published data products. Additional documentation about the roles and responsibilities of TAD, TBP, and its contractors is available upon request.

General Data Collection: Reporter Type

NTD data are collected with three levels of detail: (1) NTD Identification number (NTDID); (2) mode; and (3) type of service or ‘TOS.’ Data collection requires all three of these levels of detail to be associated with every data point. However, different ‘reporter types’ submit different amounts of data. For instance, ‘full reporters’ fill in the most forms and fields, while ‘reduced reporters’ fill out fewer forms and fields.

FTA uses reporter type to capture relevant levels of detail applicable to different types of operations. There are ten different reporter types:

· Full Reporter

· Reduced Reporter

· Separate Service

· Build Reporter

· Planning Reporter

· State Reporter

· Rural Reporter

· Tribal Reporters

· Reduced Asset Reporter

· Group Plan Sponsor

In total, approximately 3,000 transit agencies report to the NTD.[footnoteRef:8] Detailed descriptions of each reporter type are described below and are shown in Table 1.[footnoteRef:9] [8: There are five reporting modules: (1) Urban, (2) Rural, (3) Tribe, (4) Asset, and (5) Safety and Security (S&S). The first three of the modules represent aggregations related to where the transit agency is providing service. For instance, ‘Urban’ represents Urbanized Areas, rural represents rural areas (areas outside Urbanized Areas with more than 50,000 persons); and tribes (in federally recognized tribal areas). The fourth and fifth (‘Asset’ and ‘S&S’) relate to groups of forms that a reporter must complete. ‘Module’ terminology is inconsistent in this regard (mixing geography and batches of reports) due to historical reasons and precedent. FTA is considering improving the alignment of module and reporter type in the future to fix these inconsistencies. ] [9: Note, some reporter types are defined using technical transit terms, such as ‘fixed guideway’ or ‘high intensity busway.’ These terms are defined in the NTD Annual Policy Guide. https://www.transit.dot.gov/sites/fta.dot.gov/files/2020-10/2020%20NTD%20Reporting%20Policy%20Manual_1.pdf.]

1. Full Reporters A full reporter is a transit agency that receives or benefits from congressional 49 U.S.C. §5307 funding and operates either: (1) a fixed guideway mode, (2) bus service on a high occupancy vehicle (HOV) lane, or (3) does not request to be classified as a reduced reporter. In total, there are approximately 500 Full Reporters.

1. Reduced Reporters A reduced reporter receives or benefits from §5307 funding and operates 30 vehicles or less across all modes and types of service and does not operate fixed guideway or high intensity busway. These NTD reporters are typically small transit operators, but unlike rural reporters, they offer at least some service in a Census Bureau Urbanized Area (UZA). There are approximately 450 reduced reporters.

1. Separate Service Reporters A separate service reporter receives or benefits from §5307 funding, does not directly operate service, and instead provides funding for modes that are reported by another transit agency. As recipients or beneficiaries of §5307 funding they are required to report to the NTD, but since they do not operate transit service, they only complete a minimal NTD report. There are very few of these transit agencies (approximately 10).

1. Build Reporter A build reporter receives or benefits from §5307 funding, does not directly operate or contract out service, and is building or rehabilitating transit infrastructure. One difference between build reporters and full urban reporters is that no service is consumed or offered (as the system is being built). However, financial information is still required to be reported similar to full reporters. There are very few of these transit agencies (approximately 10).

1. Planning Reporter A planning reporter receives or benefits from §5307 funding, does not directly operate or contract out service, and spends §5307 funding on planning activities. One difference between planning reporters and build reporters is that a service is being planned but is not yet being built. There are very few of these transit agencies (approximately 10).

1. State Reporters State reporters are those states (including Puerto Rico, Guam, the Northern Marianas, and American Samoa) that receive §5311 funding. They provide FTA funding to rural transit operators as subrecipients within their state and are required to report to the NTD on behalf of those subrecipients. Reporting forms for rural subrecipients are very similar to those for reduced reporters. The NTD system refers to these subrecipients alternatively as rural reporters, but their data is not reported to the NTD distinctly from state reporters.[footnoteRef:10] Because the state reporters report their data on their behalf, rural reporters are not listed separately in this section. [10: Reporting forms for rural subrecipients are very similar to those for reduced reporters. For instance, they fill out a single RR-20 form. Rural reporters also do not operate service entirely or partially in a UZA; however, occasionally their service may pass through UZAs. Rather, rural reporters operate service in rural areas (non-UZAs). There are approximately 1,250 rural reporters, but the state reporters generally act on their behalf to enter the data into the NTD system. Thus, these 1,250 rural reporters have individualized data but almost none actually interact with the Appian NTD data collection website as the state reporters are responsible for entering their data on their behalf.]

1. Tribal Reporters Tribal reporters operate public transportation in a tribal area and receive or benefit from §5311 funding under FTA’s Tribal Transit Program. Reporting forms for tribal reporters are the same as those of reduced reporters (described above). There are approximately 150 tribal reporters.

1. Reduced Asset Reporters Reduced asset reporters receive or benefit from FTA funding other than §5307 or §5311 funding, and owns, manages, or operates capital assets used in providing public transportation services. The NTD collects asset data from these agencies and not service data. There are approximately 600 reduced (asset-only) reporters

1. Group Plan Sponsor Group plan sponsors sponsor a transit asset management (TAM) group plan and receive or benefit from FTA funding other than §5307 or §5311 funding and do not fit into one of the other existing reporter categories. Group Plan sponsors function similar to states in that they report on behalf of other operators. However, a group plan sponsor only reports data related to assets, they do not report other forms. There are approximately 20 group plan sponsors

General Data Collection: Forms

FTA collects NTD data according to category of ‘form.’ The NTD program uses one or two letters to identify each of the eleven categories of forms:[footnoteRef:11] [11: Screenshots of samples of reporting forms can be found here: https://www.transit.dot.gov/ntd/ntd-reporting-system-forms and here https://www.transit.dot.gov/sites/fta.dot.gov/files/2020-09/2020%20NTD%20Annual%20Reporting%20User%20Guide.pdf.]

· P Forms – Profile Forms

· B Forms – Basic Forms

· F Forms – Financial Forms

· A Forms – Asset Forms

· S Forms – Service Forms

· R Forms – Resource Forms

· RR Forms – Reduced Reporting Forms

· FFA Forms – Federal Funding Allocation Forms

· D Forms – Declaration Forms

· MR Forms – Monthly Reporting Forms

· S&S Forms – Safety & Security Forms

Certain forms are only filled out once. For example, the P Forms are specific to a single NTDID. However, most forms, have to be filled out for each mode and TOS operated by the NTDID. Forms also vary in complexity as some require users to complete more data fields than others. The average NTD form has 56 fields, with a range of 2 to 227 fields on the shortest and longest forms, respectively.[footnoteRef:12] The following is a brief narrative summary of each form category: [12: For more differences between different forms within the same category of form, see FTA’s Annual Reporting User Guide. https://www.transit.dot.gov/sites/fta.dot.gov/files/2020-09/2020%20NTD%20Annual%20Reporting%20User%20Guide.pdf ]

1. Profile Forms (P Forms) The purpose of the NTD’s profile forms is to ask for basic information to complete the reporter profile. Collected data include agency name, doing business as (DBA), address etc. The forms also ask for the different modes, users, and other system profile information that will determine how many related forms will need to be completed. In total, there are four P-forms (P-10, P-20, P-30, and P-40). The information on these forms changes infrequently.

Basic Forms (B-Forms) The purpose of the NTD’s two basic forms (B-10 and B-30) serve to collect information related to the service the transit agency provides, including basic organizational and service area information. For instance, FTA collects general information such as service area overlap with UZAs. Additional information includes contractual relationships and separate assets. However, a transit agency covering multiple UZAs or with multiple contractual relationships would have substantially more fields to complete.

Financial Forms (F Forms) The purpose of the NTD’s financial forms is to capture financial data in a uniform manner using the NTD’s accounting system—the Uniform System of Accounts (USOA). The USOA specifies the manner in which transit agencies report financial and operating information reporting to the NTD by the transit industry, with the goal of collecting the full cost of providing public transportation.[footnoteRef:13] In total, there are five financial forms (F-10, F-20, F-30, F-40, and F-60). [13: The following is a link to the USOA: https://www.transit.dot.gov/sites/fta.dot.gov/files/docs/ntd/56681/uniform-system-accounts-usoa-effective-fy18_0.pdf.]

The F-10 form (source of funds), F-40 form (adjustments to operating expenses), and F-60 form (balance sheet) are filled out once by each NTDID. The F-20 form (capital expenses) and F-30 form (operating expenses) are filled out once for each mode and TOS.

Asset Forms (A Forms) There are six asset forms (A-10, A-15, A-20, A-30, A-35, and A-90). The purpose of these forms is to collect data related to transit assets to better understand the Nation’s asset inventory and their conditions. The information collected include transit asset management (TAM) performance measure targets, facilities inventory, revenue vehicle inventory, service vehicle inventory.

Service Forms (S Forms) There is only one service form (S-10). The purpose of this form is to collect service supplied and service consumed. The form is completed for each mode and TOS.

Resource Forms (R Forms) There are two resource forms (R-10 and R-20). The purpose of these forms is to collect how many employees the transit agency employs and maintenance related information.

Reduced Reporting Forms (RR Forms) There is only one reduced reporting form. The purpose of this form is to capture a simplified consolidated form for small transit agencies covering, financial, service, safety, and other data. Some examples of the data collected are sources of data (similar to the ‘F’ or Financial Forms) and service data (similar to the ‘S’ or Service Forms).

Federal Funding Allocation Forms (FFA Forms) There is only one Federal Funding Allocation form (the FFA-10). The purpose of this form is to allow the transit agency to allocate its numerical data metrics across UZAs served (consistent with the UZAs that the reporter described on the B Forms). This form is critical as it affects how FTA apportions money.

Declaration Forms (D Forms) There is only one declaration form (D-10). The purpose of this form is to ensure that the reporter’s Chief Executive Officer (CEO) certifies the validity of the data submitted to the NTD. For instance, typically a staff member of a transit agency may enter all the data. However, the NTD requires a high-level executive sign off on the validity of the data for purposes of accuracy and completeness using this form.

Monthly Forms (MR Forms) There is only one monthly form (MR-20). The purpose of this form is to gather current service supplied (e.g., vehicle revenue miles) and service consumed (e.g., ridership) data. Monthly data is refreshed more frequently than annual data and provides a snapshot into a more current look at the state of transit in the country.

Safety and Security Forms (S&S Forms) There are four S&S forms (S&S-20, S&S-30, S&S-40, and S&S-50). The purpose of these forms is to gather safety and security data. This data supports multiple data users, including FTA’s safety office (TSO) and its State Safety Oversight Reporting tool (SSOR).

National Transit Database - Request for Information (RFI)DRAFT

A summary table of the number of forms by category are shown in Table 1 below by NTD reporter type to highlight that different types of forms different reporter types must fill out.

Table 1: NTD Reporter Type and Form Summary Matrix

Reporter Type

The numbers above indicate the number of forms under each form category a given reporter type must complete. For instance, a full reporter is required to complete 4 P-Forms, 2 B-Forms etc.

* Note rural reporter reports are filed by the state on behalf of the rural reporters.

National Transit Database - Request for Information (RFI)

General Data Validation The incumbent performs validation across all CLINs. Validation consists of examining the completeness and accuracy of the data submitted to the NTD. The purpose of validation is to ensure that the data is complete, accurate, and is consistent with the definitions and standards established in the NTD policy manuals and Uniform System of Accounts.[footnoteRef:14] Invalid data is regularly submitted to the NTD for a number of reasons including: [14: See e.g., https://www.transit.dot.gov/ntd/2020-ntd-reporting-policy-manual.]

· Typographical / data entry errors

· Incorrect assembly of the data from the agency’s record keeping systems by the individual responsible for submitting the data to the NTD

· The agency’s underlying record keeping systems not keeping the data in accordance with NTD definitions and standards

Many of the NTD’s validation checks rely upon checking that the submitted value falls within in an expected range. FTA has a number of ways of defining the expected range:

· Comparing the submitted data with data submitted for an earlier time period. For example, it’s unusual for transit operations to change by more than 20% from one time period to the next, outside of unusual circumstances, such as a global pandemic;

· Comparing the submitted data for one field with data submitted for another field in the same report (for example, if vehicle revenue miles increase by 10%, FTA would expect vehicle revenue hours to also increase by about 10%); and

· Comparing the data to industry benchmarks. For example, dividing vehicle revenue miles by vehicle revenue hours calculates average speed. It would be nearly impossible for average speed to exceed a typical speed limit.

FTA’s validation checks can be thought of as producing two types of errors:

· Type 1 errors occur when the validation rule activates an alert. For example, a user submits data that activates an alert (or ‘check’). The system then requires the user to provide a written explanation that was entered correctly despite the alert. There is a subset of Type 1 errors that occur because the data in the prior time period was incorrect, thus producing an unusual percent change. FTA is not concerned about this subset of Type 1 errors but does wish the main line of Type 1 errors.

· Type 2 errors occur when a validation check does not fire, even though the data was either entered incorrectly, or else does not meet NTD definitions and standards. Type 2 errors are hard to measure, by definition. However, Type 2 errors can be identified retrospectively – for example, when the subset Type 1 errors described above occur. One example of a Type 2 error would be where a transit agency reported 0 for February and March ridership even though service restarted in March. A validation check for March would not catch this as it was consistent with the prior month, but in reality, ridership should not have been 0.

FTA seeks continuous improvement in its validation procedures to minimize both Type 1 and Type 2 errors. In total across all CLINs, the incumbent indirectly or directly manages approximately 1500 business validation rules. The incumbent indirectly manages 1100 of the 1500 business rules as these rules operate in the Appian production environment. The incumbent is responsible for maintaining general documentation about the business logic and submitting requests to TAD to update, fix, or change these rules. The incumbent also directly manages 400 of 1500 validation rules, including documentation and SQL code. One reason the 400 and 1100 are separated is that the incumbent manages the 400 with more control and customization. For instance, there may be certain new fields that require new, custom, speedy validation that cannot wait to be pushed to in-system validation.

The NTD program also assures valid data submissions through audit requirements. Specifically, the NTD requires each agency to periodically submit sufficient documentation that their NTD data is audited. A full description of audit-related documentation is listed in the NTD’s Annual Policy Manual.[footnoteRef:15] The incumbent reviews the submitted auditor’s statement for completeness and corrective actions related to negative findings. [15: See https://www.transit.dot.gov/sites/fta.dot.gov/files/2020-10/2020%20NTD%20Reporting%20Policy%20Manual_1.pdf.]

Part 1: Contract Line Item Number (CLIN) Requirements FTA anticipates that a future solicitation will contain a proposed statement of work that aligns with CLINs 0001 through 0013 CLINs and deliverables for these CLINs in Appendix C (Deliverables Matrix).

1. CLIN 0001 - TECHNICAL ASSISTANCE (EXISTING CLIN, FIRM FIXED PRICE)

The incumbent provides technical assistance to transit agencies to resolve escalated Tier 1 customer service tickets. These escalated tickets are referred to as ‘Tier 2’ tickets in this RFI. FTA’s Office of Administration (TAD) operates a help desk to intake, categorize, escalate, and resolve Tier 1 stakeholder tickets from 8am to 8pm Eastern. Tier 1 tickets are general issues not specific to technical NTD information.[footnoteRef:16] For instance, a Tier 1 ticket could be a user that is locked-out or needs help finding a certain NTD website. On the other hand, Tier 2 tickets require NTD knowledge to answer technical questions. Intake for Tier 1 and Tier 2 tickets, and resolution for Tier 1 tickets are handled by TAD. TAD categorizes a ticket from Tier 1 to Tier 2 but does not resolve Tier 2 tickets. The incumbent receives, manages, and resolves Tier 2 tickets. [16: Currently FTA has an NTD Help Desk team with its own incoming phone line. FTA is in the process of consolidating the phone line along with other FTA phone numbers. This RFI is written to reflect the end result of this process (expected by Winter 2021), where the NTD program no longer requires its own phone number. There is also an NTD help email address: NTDhelp@dot.gov. FTA will clarify roles and responsibilities for intake and management of incoming emails to this address in the RFP.]

The incumbent’s responsibility is to provide technical assistance to the individual or entity that submitted the ticket—typically transit agencies. To do so, the incumbent tracks and update these tickets using the JIRA software package by Atlassian. FTA uses this software for bug tracking, issue tracking, and project management. Licenses and access will be provided by FTA at no cost.

To resolve Tier 2 tickets, the incumbent makes outgoing calls and emails to follow-up with the Tier 2 ticket customer to ensure that their question or issue is addressed. The incumbent makes an initial response during business hours typically on the same or the following business day that TAD receives the initial call or email. Initial responses are always made within two business hours. FTA expects 33% of tickets to be resolved within 1 business day and 90% within 4 business days.

Email addresses are supplied by FTA, and the incumbent is required to use DOT e-mail addresses when engaged in government business with persons outside the agency. However, the incumbent uses their own phone numbers to make outbound phone calls to handle Tier 2 tickets.

The incumbent is responsible for designing a staffing plan to answer Tier 2 tickets in a reasonable amount of time. This includes tagging tickets in JIRA to appropriately triage and resolve tickets as quickly as practicable.[footnoteRef:17] [17: For instance, the incumbent prioritizing time-sensitive questions and questions with funding implications.]

1. Manage Tier 2 JIRA Tickets A future contractor will be expected manage and resolve approximately 1000 Tier 2 NTD JIRA tickets per year.[footnoteRef:18] These tickets are otherwise known as NTD Service Desk tickets or (‘NTDSDs’). This includes all aspects of work, from coding the initial inquiry in JIRA through resolving the issue and sending the customer an acknowledgement that their question has been resolved. Requests range from simple to complex. Complex requests are typically referred to FTA staff for an official decision, and so may take longer to resolve. The incumbent is responsible for deleting duplicates and prioritizing Tier 2 tickets.[footnoteRef:19] [18: This RFI refers to Tier 1 and Tier 2 tickets according to NTD program terminology and described herein. Other FTA offices (e.g., TAD) use different terminology to refer to what the different tiers mean.] [19: While not final, FTA is considering adopting a JIRA categorization framework that delineates Tier 2 tickets along the following lines:

(1) The question can be definitively answered by referencing the existing NTD Policy Manual—https://www.transit.dot.gov/sites/fta.dot.gov/files/2020-10/2020%20NTD%20Reporting%20Policy%20Manual_1.pdf

(2) The question can likely be answered by referencing the existing Policy Manual, but there is some ambiguity that requires confirmation from FTA staff, or

(3) the question raises a novel issue that requires FTA to make a policy decision. These decisions often set new precedents for use in subsequent Tier 2 tickets.]

Of the 1000 Tier 2 Tickets, 800 are complex, which cannot be easily categorized. The following are some examples of complex requests that cannot be easily categorized:

· Whether a given agency’s transit service qualifies as ‘public transportation’;

· Interpretations of policy terms in novel issues such as whether unusually configured large transit facilities count as a single facility or two;

· Answering questions about how to complete audit documentation;

· Approved methods for counting vehicle revenue miles; and

· Handling NTD exceptions (described further below).

FTA has a number of NTD exceptions, such as a transit agency request for FTA to approve an exception for policy reasons. Exceptions includes variations in data collection methodology for a variety of reasons. Exceptions are related to CLIN 0002 (Validation), but occasionally questions come in through other channels. For instance, Appian is the primary means of communication for CLIN 0002 but CLIN 0001 often involves related questions.

Of the 1000 Tier 2 tickets, 200 are less complex. Unlike complex requests, these simpler requests can be categorized, and most fall into one of the following categories:

Data Collection Guidance FTA receives approximately 100 requests for general data collection. These inquiries consist of questions regarding different types of forms and individual form fields. Some of these questions come in direct from the NTD reporters or FTA staff. For instance, an FTA regional staff member may ask the incumbent to help answer hypothetical questions, such as:

“A current transit agency is considering acquiring a new bus that would be used for both Demand Response and Fixed-Route service. How should the agency report this data to the NTD?”

The incumbent is responsible for maintaining staff knowledgeable to answer similar questions on the same-day the question is received. If answering the question is not possible on the same day, the incumbent provides an assessment of time required to research and answer the question. Although related, this work is in addition to the incumbent’s communication responsibilities described in CLIN 0002.

Data Product Guidance FTA receives approximately 50 requests for data product guidance per year. These inquiries consist of answering questions regarding where to find various data points across all of the NTD’s data products.

New User Management The incumbent is required to collect and process data from new reporters (‘New ID’ requests). There are approximately 30 of these new reporter requests in a given year. These transit agencies are new to the NTD system and do not yet have an NTDID. New ID requests consist of a letter from the new NTD reporter, user manager designation, and sufficient agency information. The data collection process must be done in a way that can be tracked in a data file that can be easily merged with other NTD data.

Automatic Passenger Counter (APC) Requests The incumbent also answers requests Automatic Passenger Counter (APC) certification questions. In the past, FTA received 1 to 20 requests for new APC certification annually. Processing these applications involves reviewing the application for consistency with NTD reporting requirements. In most cases, the approval process will require requesting additional information from the applicant on the exact nature of the service provided and relationships with other parties in providing the service to determine the actual “operator” of the service.

Updating NTD Frequently Asked Questions Website The contractor will be responsible for updating FTA’s NTD Frequently Asked Questions (FAQ) website content. This includes updating the FAQ, summarizing how the changes positively affect the user experience, and describing how the updates allow users to answer their own Tier 2 questions more easily. The current NTD FAQ website is here: https://www.transit.dot.gov/ntd/ntd-reporting-frequently-asked-questions.

Monthly Status Report The incumbent produces a monthly status report to FTA. Specifically, the incumbent keeps written documentation summarizing data in a manner that answers changing business questions. Example questions include ‘how many Tier 2 tickets [customer inquiries] were answered in a given time period,’ ‘how long each inquiry took to close,’ and ‘how many inquiries were received by category.’ In addition, on an as-needed basis, the contractor will report out the results within FTA and any observed trends. This support could also include writing observations or recommendations for improvements to reduce the number of incoming tickets.

CLIN 0002: ANNUAL MODULE (EXISTING CLIN, FIRM FIXED PRICE)

The Annual Module CLIN is the majority of work for this contract. The tasks associated with this CLIN are: (1) data collection, (2) validation, (3) PDF data products, and (4) other support, (4) potential additions to this CLIN.

1. Data Collection.

The incumbent is responsible for managing all aspects of collecting NTD’s annual data.[footnoteRef:20] The reports are due by end of the agency’s fiscal year. NTD reporters use FTA’s Appian website to enter their annual data. Nevertheless, the incumbent’s correspondence and tracking associated with this task are performed both within and outside of Appian. The incumbent’s staff process lists of validation check alerts, asking transit agencies to explain each anomaly, tracking the back-and-forth communication, and adding final notes to a the ‘Validation Log.’ [20: Note, the exception is that FTA’s IT office is responsible for operation, maintenance, and enhancements of the NTD Production database (Appian), and the incumbent is not responsible for this work. See Section II.B for a description of FTA’s Information Technology.]

Validation Log The Validation Log is a Microsoft Excel spreadsheet and a core component of the Annual Module (CLIN 0002). The Appian system has Microsoft Excel export functionality, and the incumbent uses this functionality to build and export copies of the Validation Log for processing and recordkeeping. The Appian system automatically populates the majority of records in the Validation Log. Specifically, Appian records which of the 1100 of its in-system validation business rules an agency triggered when they submitted their data. However, in the vast majority of cases, only a small fraction of rules appears in any given Validation Log. Validation Log’s typically have around 50 rows but can range from 0 to 200.

As a semi-automated process, the incumbent supplements the Validation Log with the results from the additional 400 Branch environment trigger results. The automated portion of this process is first. The incumbent uses nightly database stored procedures to produce results in a similar file format to the Validation Log. The incumbent’s staff use these files to transcribe the results into Appian so that Appian contains a full record of validation rule results. For instance, if a given agency had 50 of the 1100 validation ‘in-system’ rules trigger, 18 of the 400 Branch validation rules might have also triggered, for a total of 68 records in the final Validation Log. After the extra 18 validation rules have been entered into Appian, the incumbent then exports the Validation Log for its staff to complete.

To complete the Validation Log, the incumbent communicates with each agency to make corrections or document explanations. Corrections account for errors while explanations occur when the agency’s submitted data was anomalous but correct.

Work Plan FTA expects the workload shown in Table 2 to validate reported data. For instance, an NTD reporter with a fiscal year end date of June 30 has an NTD report due date of October 31 of the same year. The incumbent is expected to develop and execute a written work plan, so that these reporters are fully validated (‘closed-out’) by March 15. Approximately 60% of all NTD reporters follow a fiscal year and final closeout schedule consistent with that timeline. Those agencies with a September and December FY end date are also shown below. Currently, FTA has a set of escalating consequences for non-responsive agencies. As part of meeting the schedule below, FTA may ask the incumbent to communicate its intent or deactivate non-responsive agencies from the NTD.

Table 2: When Annual Reports are Due[footnoteRef:21] [21: Note, the dates described in this table are subject to change and will be further clarified in the RFP. ]

(1800 of 3000)

(600 of 3000)

(600 of 3000)

Validation FTA uses validation processes for each NTD reporter to ensure data submissions are complete, timely and accurate. The incumbent performs general validation as described in Section II.E above as well as the following:

i. Update the Validation Manual. There are several different documents that the incumbent uses, shares with FTA, and disseminates to its staff to ‘close out’ agencies. The most important items are the Validation Manual itself, data field sampling procedures, letter templates, and standard operating procedures. FTA does not publish the full Validation Manual, but an example excerpt was most recently published in 2016.[footnoteRef:22] [22: See https://cms7.fta.dot.gov/sites/fta.dot.gov/files/docs/RY%2016%20NTD%20Validation%20Module%20Guide.pdf ]

ii. Exceptions. The incumbent processes approximately 1000 requests for variances or exceptions from NTD reporting standards and requirements per year. For instance, one transit agency may request reporting relief if their ridership counter equipment broke.

iii. Policy Question Summaries. The incumbent creates narrative descriptions, analysis, and recommendations for FTA to review and resolve policy issues for relevant questions from reporting agencies. In total, the incumbent logs approximately 50 complex policy questions per year that require FTA decisions or input. FTA is responsible for the software system that supports the incumbent’s staff inputting, tracking, and resolving these issues.

iv. Process and Route NTD Reporter Data Report ‘Packages’ for Close-Out. The incumbent’s staff process approximately 1200 closeout report ‘packages’ for the 3000 NTD annual reports.[footnoteRef:23] This work involves shepherding the reports from when agencies first submit the data through various stages of revision. Aspects of this process include developing and executing a work plan, managing caseload assignments to its staff, and performing Appian IT user management functions. Additional related tasks include validation correspondence. For instance, the incumbent sends widely distributed emails if the Appian system is down or FTA makes an immediate policy change. The incumbent creates and uses validation checklists for different reporter types. This includes urban, rural, and tribal-specific validation checklist items, including specific validation review tasks specific to each form type. [23: There are only 1200 ‘closeout reports’ in Appian for the 3000 transit agency annual reports because many annual reports may be aggregated or nested within a closeout report. The largest group of these nested reports are rural reporters, where 1250 rural reports are nested within the 54 state reporters (including Puerto Rico, American Samoa, Guam, and the Northern Mariana Islands).]

v. Closeout Letters. The incumbent drafts approximately 1200 closeout letters in Microsoft Word—closeout referring to the final review and acceptance of a reporter’s NTD data. For FTA grantees that are required to report to the NTD, the close-out letter acts as their “receipt” to document compliance with the reporting requirements. It contains general language (boiler plate) and specific provisions. The boiler plate language is applicable to all or certain groups of agencies. Agency-specific provisions vary.[footnoteRef:24] Letters are created in Microsoft Word and sent to agencies via Appian. Although there are approximately 1200 closeout letters, half or less require customization. [24: Examples include data questions that were not able to be resolved during the validation process, the close-out letter provides official documentation of what deficiencies must be corrected for the next report year. The close-out letter also contains official program announcements and reporting reminders. FTA reviews each close-out letter for grammatical correctness and use of plain language. ]

vi. Validation Research and Development (R&D). The incumbent will perform validation research and development. This includes SQL diagrams and SQL code. This work would be analyzing Type 1 and Type 2 errors. Type 1 and Type 2 errors in the NTD are described in Section II.E (above). For instance, FTA is interested in developing a ‘risk-based’ sampling approach to validation. As part of its R&D work, the incumbent might be expected to develop risk-based approach to help manage the level of scrutiny FTA gives to different annual NTD packages. The most complex agencies or those agencies with different service types might warrant more scrutiny in validation than others. This R&D work must be documented and submitted to FTA.

Other Support.

The incumbent performs one-time research or analysis on a variety of topics for FTA staff for this CLIN. The most common purpose is answering data validation questions or explaining anomalies. FTA requests one-time research or analysis support approximately three-times-per week, with a same-day deadline or as soon as practicable.

Potential New Additions to this CLIN FTA is considering adding the following deliverables to this CLIN. The incumbent does not currently perform this work, but FTA is interested in gauging market interest in the following:

· Annual Validation Improvement Summary Report. Although not currently in the incumbent’s scope, FTA is interested in adding an annual validation improvement summary report as a deliverable. A prospective contractor would submit a 2-to-3-page annual module automation summary, highlighting proposed ways to improve the mix of human labor and automation to minimize validation issues and improve the customer experience.

CLIN 0003: MONTHLY MODULE COLLECTION, AND VALIDATION (EXISTING CLIN, FIRM FIXED PRICE)

The NTD program collects monthly module data from approximately the 500 full reporters through the MR-20 form (see Table 1 above). However, because these reporters have on average four modes/types of service, there are a total of approximately 2000 modes/types of service to process under this CLIN.[footnoteRef:25] The data consists of ridership, revenue miles, revenue hours, and vehicles operating during maximum service (VOMS). [25: Note these are separate from the safety module reports (Form S&S-50). The safety module is also submitted monthly but is independent of the monthly module for reporting purposes.]

1. Data Collection.

Data collection involves all aspects of collecting NTD’s monthly module data. The reports are due by the end of the following month. For instance, data for March 1 through March 30 is due by April 30. NTD reporters use FTA’s Appian website to log in and submit the monthly module form(s). However, the incumbent’s correspondence and tracking associated with this task may be performed outside of Appian using email. At this time, the monthly module consists of the MR-20 Form with four fields per mode/type of service.

The incumbent ensures timely, accurate, full monthly module data collection—85% on-time data collection to the extent practicable. This includes development and execution of an appropriate written work plan.

Recent data shows that the incumbent achieved a late report frequency of no more than 14% of data fields using a combination of:[footnoteRef:26] [26: FTA will consider comparable substitute processes if proposed, tested, and approved in writing by FTA.]

· Late Notices – After the due date has passed, the incumbent uses SQL scripts and the Branch database to create a list that identifies which agency modes/types of service (TOS) have not submitted timely data. The incumbent then sends notices to the delinquent reporters by email; and

· Likely-to-be-Late Notices – The incumbent sends reminders to those likely to be late on an ad hoc basis. The assessment of which agencies are likely to be late is based on best professional judgment and multiple factors.