Attachment A Forms RFP 71685 - Nebraska Department of ...



Attachment A

Option A: Basic Transit Scheduling Software

Request for Qualification Number R207-20

Bidders are required to complete all forms provided in this attachment if bidding on

Option A: Basic Transit Scheduling Software

Forms A.1, A.2, A.3, and A.4 are to be included as part of the Technical Proposal.

Forms A.5, A.6, A.7, and A.8 are to be submitted as the Cost Proposal.

Form A.1: Corporate Overview Matrix

Form A.2: Project Requirements Matrix

Form A.3: Technical Requirements Matrix

Form A.4: Optional Capabilities Matrix

Form A.5: Cost Proposal Summary

Form A.6: Cost Proposal Details

Form A.7 Optional Capabilities Cost Details

Form A.8: Hourly Labor Rates

Representative Small Transit Agency for Computation of Cost Proposal for Basic Solution

To facilitate equitable cost comparisons between different offerings, all Bidders submitting proposals for the Basic Transit Scheduling System must base their cost proposals on a representative small-sized transit agency profile that is similar to the agencies in Nebraska most likely to acquire such a system. Additionally, Bidders are required, through use of the cost forms, to structure their prices so that an actual transit agency could easily determine how their own cost could vary from the representative cost proposal based on differences in such factors as number of vehicles, trips served, or number of scheduling and dispatch staff.

Details of the representative small-sized transit agency profile for the basic system are as follows:

• Max number of scheduling and dispatch staff working at same time = 2

• Number of vehicles operated = 5

• Number of trips served per year = 5,000

Form A.1

Corporate Overview Matrix (COM) for Basic Transit Scheduling System

Request for Qualification Number R207-20

Bidders proposing on the Basic Transit Scheduling System are instructed to complete the Corporate Overview Matrix (COM) as part of their technical proposal submittal. Within the COM, Bidders are required to provide information describing their firm and its capabilities and experience in providing scheduling software for small- and medium-sized transit agencies. The responses within the COM will be included as part of the technical scores for each submittal. Note that Bidders that wish to submit proposals on both the basic and the advanced systems will need to fill out a separate copy of the COM for each of the two (2) options.

Please attach additional pages as needed for Bidder Response sections.

How to complete the COM:

|COM Column Description |Bidder Responsibility |

|CO # |The unique identifier for the Corporate Overview element as assigned by NDOT. This column is dictated by this RFQ |

| |and must not be modified by the bidding Bidder. |

|Corporate Overview Element |The brief statement describing the information about the Bidder firm that is being requested. This column is |

| |dictated by the RFQ and must not be modified by the bidding Bidder. |

|Response |Bidders should provide a response that fully, yet concisely, describes the requested information for the Corporate |

| |Overview element. If instructed to do so, this information may be provided as separate pages. |

Corporate Overview Matrix (COM) Attach additional pages as needed.

|CO # |CORPORATE OVERVIEW ELEMENT |

|Contractor Identification and Information |

|CO.1 |The Contractor should provide the full company or corporate name, address of the company's headquarters, entity organization (corporation, partnership, proprietorship), state in which the Contractor is |

| |incorporated or otherwise organized to do business, year in which the Contractor first organized to do business and whether the name and form of organization has changed since first organized. |

|Response: |

| |

| |

| |

|Financial Statements |

|CO.2 |The Contractor should provide financial statements applicable to the firm. If publicly held, the Contractor should provide a copy of the corporation's most recent audited financial reports and |

| |statements, and the name, address, and telephone number of the fiscally responsible representative of the Contractor’s financial or banking organization. |

| | |

| |If the Contractor is not a publicly held corporation, either the reports and statements required of a publicly held corporation, or a description of the organization, including size, longevity, client |

| |base, areas of specialization and expertise, and any other pertinent information, should be submitted in such a manner that proposal evaluators may reasonably formulate a determination about the |

| |stability and financial strength of the organization. Additionally, a non-publicly held firm should provide a banking reference. |

| | |

| |The Contractor must disclose any and all judgments, pending or expected litigation, or other real or potential financial reversals, which might materially affect the viability or stability of the |

| |organization, or state that no such condition is known to exist. |

|Response: |

| |

| |

| |

|Change of Ownership |

|CO.3 |If any change in ownership or control of the company is anticipated during the twelve (12) months following the proposal due date, the Contractor should describe the circumstances of such change and |

| |indicate when the change will likely occur. Any change of ownership to an awarded Contractor(s) will require notification to the State. |

|Response: |

| |

| |

| |

|Office Location |

|CO.4 |The Contractor’s office location responsible for performance pursuant to an award of a contract based on this solicitation should be identified. |

|Response: |

| |

| |

| |

|Relationship with the State |

|CO.5 |The Contractor should describe any dealings with the State over the previous three (3) years. If the organization, its predecessor, or any Party named in the Contractor’s proposal response has |

| |contracted with the State, the Contractor should identify the contract number(s) and/or any other information available to identify such contract(s). If no such contracts exist, so declare. |

|Response: |

| |

| |

| |

|Contractor’s Employee Relations to State |

|CO.6 |If any Party named in the Contractor's proposal response is or was an employee of the State within the past twelve (12) months, identify the individual(s) by name, State agency with whom employed, job |

| |title or position held with the State, and separation date. If no such relationship exists or has existed, so declare. |

| | |

| |If any employee of any agency of the State of Nebraska is employed by the Contractor or is a subcontractor to the Contractor, as of the due date for proposal submission, identify all such persons by |

| |name, position held with the Contractor, and position held with the State (including job title and agency). Describe the responsibilities of such persons within the proposing organization. If, after |

| |review of this information by the State, it is determined that a conflict of interest exists or may exist, the Contractor may be disqualified from further consideration in this proposal. If no such |

| |relationship exists, so declare. |

|Response: |

| |

| |

| |

|Contractor Performance |

|CO.7 |If the Contractor or any proposed subcontractor has had a contract terminated for default during the past three (3) years, all such instances must be described as required below. Termination for default|

| |is defined as a notice to stop performance delivery due to the Contractor's non-performance or poor performance, and the issue was either not litigated due to inaction on the part of the Contractor or |

| |litigated and such litigation determined the Contractor to be in default. |

| | |

| |It is mandatory that the Contractor submit full details of all termination for default experienced during the past three (3) years, including the other Party's name, address, and telephone number. The |

| |response to this section must present the Contractor’s position on the matter. The State will evaluate the facts and will score the Contractor’s proposal accordingly. If no such termination for default|

| |has been experienced by the Contractor in the past three (3) years, so declare. |

| | |

| |If at any time during the past three (3) years, the Contractor has had a contract terminated for convenience, non-performance, non-allocation of funds, or any other reason, describe fully all |

| |circumstances surrounding such termination, including the name and address of the other contracting Party. |

|Response: |

| |

| |

| |

|Summary of Contractor’s Corporate Experience |

|CO.8 |The Contractor should provide a summary matrix listing the Contractor’s previous projects similar to this solicitation in size, scope, and complexity. The State will use no more than three (3) narrative|

| |project descriptions submitted by the Contractor during its evaluation of the proposal. |

| | |

| |The Contractor should address the following: |

| | |

| |Provide narrative descriptions to highlight the similarities between the Contractor’s experience and this solicitation. These descriptions should include: |

| | |

| |The time period of the project; |

| |The scheduled and actual completion dates; |

| |The Contractor’s responsibilities; |

| |For reference purposes, a customer name (including the name of a contact person, a current telephone number, a facsimile number, and e-mail address); and |

| |Each project description should identify whether the work was performed as the prime Contractor or as a subcontractor. If a Contractor performed as the prime Contractor, the description should provide |

| |the originally scheduled completion date and budget, as well as the actual (or currently planned) completion date and actual (or currently planned) budget. |

| | |

| |Contractor and subcontractor(s) experience should be listed separately. Narrative descriptions submitted for subcontractors should be specifically identified as subcontractor projects. |

| | |

| |If the work was performed as a sub bidder, the narrative description should identify the same information as requested for the Bidder above. In addition, sub bidders should identify what share of |

| |contract costs, project responsibilities, and time period were performed as a sub bidder. |

|Response: |

| |

| |

| |

|Summary of Contractor’s Proposed Personnel/Management Approach |

|CO.9 |The Contractor should present a detailed description of its proposed approach to the management of the project. |

| | |

| |The Contractor should identify the specific professionals who will be involved in any contract resulting from this solicitation. The names and titles of the team proposed should be identified in full, |

| |with a description of the team leadership, interface and support functions, and reporting relationships. The primary work assigned to each person should also be identified. |

| | |

| |The Contractor should provide resumes for all personnel proposed by the Contractor to work on any projects stemming from this solicitation. The State will consider the resumes as a key indicator of the |

| |Contractor’s understanding of the skill mixes required to carry out the requirements of the solicitation in addition to assessing the experience of specific individuals. |

| | |

| |Resumes should not be longer than three (3) pages. Resumes should include, at a minimum, academic background and degrees, professional certifications, understanding of the process, and at least three |

| |(3) references (name, address, and telephone number) who can attest to the competence and skill level of the individual. Any changes in proposed personnel shall only be implemented after written |

| |approval from the State. |

|Response: |

| |

| |

| |

|Subcontractors |

|CO.10 |If the Contractor intends to subcontract any part of its performance hereunder, the Contractor should provide: |

| | |

| |name, address, and telephone number of the subcontractor(s); |

| |specific tasks for each subcontractor(s); |

| |percentage of performance hours intended for each subcontract; and |

| |total percentage of subcontractor(s) performance hours. |

|Response: |

| |

| |

| |

Form A.2

Project Requirements Matrix (PRM) for Basic Transit Scheduling System

Request for Qualification Number R207-20

Bidders proposing on the Basic Transit Scheduling System are instructed to complete a Project Requirements Matrix (PRM) as part of their technical proposal submittal. Within the PRM, Bidders are required to describe their proposed approaches to meeting the requirements associated with planning, implementing, and maintaining and supporting their basic scheduling solution on behalf of a Nebraska transit agency. The responses provided within the PRM will serve as a template for the scope of work for any subsequent engagement in which a Nebraska transit agency contracts with a prequalified Bidder for the provision of a basic scheduling system under the terms of this solicitation.

All items identified in the PRM are required, and Bidders must affirm that they are able to address each of the enumerated requirements. Bidders that cannot comply with one or more of the project requirements may be disqualified from further consideration. Additionally, responses provided within the PRM will be scored as part of the evaluation of each Bidder’s submission, and Bidders are therefore encouraged to provide detailed discussions of their proposed approaches within the response section for each item in order to inform the scoring.

How to complete the PRM:

|PRM Column Description |Bidder Responsibility |

|PR # |The unique identifier for the project requirement as assigned by NDOT. This column is dictated by this RFQ and must |

| |not be modified by the Bidder. |

|Requirement Description |The statement of the requirement to which the Bidder must respond. This column is dictated by the RFQ and must not |

| |be modified by the Bidder. |

|Resp. |Bidders must indicate whether or not they are able to address each project requirement. Bidders that are unable to |

|(Response Code) |meet one or more requirements may be disqualified. |

| |Y |

| |Yes, the Bidder can address this requirement. |

| | |

| |N |

| |No, the Bidder is unable to address this requirement. |

| | |

|Response |Bidders should describe their general approach for meeting this requirement when contracting with a Transit Agency |

| |in Nebraska after being pre-qualified under this solicitation. Bidders may also identify factors that could vary by |

| |Transit Agency, and how the approach could be modified as needed to address such variations. The descriptions |

| |provided in the Bidder response will be scored as part of the proposal evaluation process. |

Project Requirements Matrix (PRM) Attach additional pages as needed.

|PR # Requirement Description |

|PR.1. Project Planning and Design Phase |Resp. |

|System Deployment Document |

|PR.1.1 |The Contractor shall prepare a System Deployment Document tailored for the specific Transit Agency and acceptable to the purchasing Transit Agency’s project manager. The document shall|Y/N |

| |clarify the process for incorporating the Transit Agency’s business rule and client database into the software system. It will specify an implementation schedule, what is needed from | |

| |the Transit Agency, what the Contractor will provide, and the timelines associated with all tasks. The System Deployment Document will include a transition plan (if replacing existing | |

| |software) that addresses data migration and service continuity. The System Deployment Document shall also identify and track, within a Requirements Response Matrix, where and how all | |

| |technical requirements are supported by the proposed system. The purchasing Transit Agency project manager shall approve this document and approach prior to beginning system | |

| |deployment. | |

|Response: |

| |

| |

| |

|System Acceptance Test Plan |

|PR.1.2 |The Contractor shall develop an Acceptance Test Plan to demonstrate compliance with all project and system functional requirements based on the incorporation of the purchasing Transit |Y/N |

| |Agency’s business rules and other tailoring such as the GIS map for the area. The acceptance test is not intended to be unnecessarily detailed but should demonstrate the functionality | |

| |and compliance with all system and project requirements in a straightforward way. | |

|Response: |

| |

| |

| |

|System Maintenance and Support Plan |

|PR.1.3 |The Contractor shall provide a System Maintenance and Support plan describing the activities, procedures, and responsibilities associated with the subsequent system maintenance and |Y/N |

| |support phase. This plan shall include a description of how and when the Transit Agency staff can receive support on use of the system (e.g. via 24/7 phone support, or via email), | |

| |expected frequency and procedures for system updates, a Service Level Agreement (SLA) that includes such factors as minimum system uptime and response timeframes for issues of varying | |

| |levels of severity, and a description of warranty support for any system hardware components. Please briefly describe key elements of the maintenance and support plan (additional | |

| |details may be provided in the comments section for requirements for the system maintenance and support phase below). The project manager for the purchasing Transit Agency shall also | |

| |approve this document prior to beginning system deployment. | |

|Bidder response: |

| |

| |

| |

|PR.2. System Implementation Phase |Resp. |

|System Configuration and Deployment |

|PR.2.1 |In alignment with the approved System Deployment Document, the project schedule, and approval from the Transit Agency, the Contractor may commence with the deployment and configuration|Y/N |

| |of the system with applicable hosting services, data migration, hardware acquisition and installation as applicable, user and customer configuration, and any other support systems. The| |

| |Contractor shall deploy the system in a way that minimizes any service disruption to the Transit Agency personnel and operations. | |

|Response: |

| |

| |

| |

|System Documentation |

|PR.2.2 |The Contractor shall provide all applicable system documentation to the Transit Agency, including both technical documentation and user guides for users and the Transit Agency |Y/N |

| |administrators. Documentation shall be made available in electronic form and as a printed and bound document if desired by the purchasing Transit Agency. | |

|Response: |

| |

| |

| |

|Initial and Follow-up On-site System Training |

|PR.2.3 |The Contractor shall provide initial on-site system training for Transit Agency users and administrators, along with follow-up on-site training approximately 60 to 90 days following |Y/N |

| |successful system deployment and acceptance testing. For the initial training, a trainer is required to be on-site during the installation period and when the system is deployed, | |

| |defined as when the system relies solely on the software purchased through this RFQ. The Contractor shall provide all training materials to the Transit Agency in electronic form, and | |

| |as a printed and bound document if desired by the Transit Agency. Users and administrators should demonstrate proficiency in the use and administration of the system prior to beginning| |

| |the acceptance test step. The purpose of the follow-up on-site training is to refresh users on system functionality presented in the initial training as well as to address any | |

| |questions that have arisen in the intervening period. Please describe the training program with an outline of topics covered, estimate the hours of training for both initial and | |

| |follow-up sessions, and describe the training materials. | |

|Response: |

| |

| |

| |

|Acceptance Testing |

|PR.2.4 |Concurrent with system deployment, delivery of system documentation, and completion of initial training, the Contractor shall schedule system acceptance testing. Testing shall be |Y/N |

| |conducted in the presence of representatives from the Contractor, the Transit Agency, and NDOT (at NDOT’s discretion). The test shall follow the approved Acceptance Test Plan created | |

| |during the Project Planning and Design phase and shall verify that all project and system functional requirements are successfully met and acceptable by the purchasing Transit Agency | |

| |and NDOT. Once a successfully completed test plan is signed by all three (3) parties, the Contractor is eligible for payment for the System Implementation Phase tasks and commences | |

| |with the System Maintenance and Support phase. | |

|Response: |

| |

| |

| |

|PR.3. System Maintenance and Support Phase |Resp. |

|Hosting |

|PR.3.1 |The Contractor shall provide external hosting for the scheduling system, either at its own facilities or via a third party. (Please see additional related requirements in the TRM |Y/N |

| |below). | |

|Response: |

| |

| |

| |

|Maintenance and Warranty |

|PR.3.2 |The Contractor will maintain the system according to the Maintenance and Support plan such that it meets the specified Service Level Agreement. For any hardware components furnished by|Y/N |

| |the Contractor, the Contractor will provide a warranty that includes repairing or replacing any defective equipment over the life of the contract. | |

|Response: |

| |

| |

| |

|Upgrades |

|PR.3.3 |When major software upgrades occur, the Contractor will need to provide additional support and training, potentially via webinar, to ensure that end users know about the changes and |Y/N |

| |are able to maintain a fully functioning system. Please describe the typical frequency of upgrades as well as the procedures you follow to ensure a smooth transition and that all users| |

| |are aware of any significant changes or new features in the system. | |

|Response: |

| |

| |

| |

|On-going Annual Training |

|PR.3.4 |On-site refresher training is required on an annual basis. For the initial year, the annual training should be scheduled for roughly six (6) months after the system is successfully |Y/N |

| |deployed (this will be the third training, following the initial on-site training at system deployment as well as the follow-up training at 60 to 90 days after deployment). In | |

| |subsequent years, the annual training can occur at any time that would be mutually convenient for the purchasing Transit Agency and the Contractor. Objectives of the annual training | |

| |sessions include providing a refresher for existing functionality as well as demonstrating any upgrades to the system that require changes in how activities are performed. Contractors | |

| |should describe their proposed approach to annual on-site training, including the number of hours that will be involved in each session as well as an outline of topics to be covered. | |

|Response: |

| |

| |

| |

|Customer Support |

|PR.3.5 |Contractors shall provide customer support to assist agencies in using the system and to address technical issues that may arise. Please describe how customer support is provided |Y/N |

| |(telephone, online, in person), any limits on the amount of support available, and response times for dealing with issues of varying levels of severity. Identify what constitutes a | |

| |critical call and the service level that will be provided for critical calls, including the time for initial call back and time for resolution. Finally, describe the location of the | |

| |office that will serve contracts in Nebraska. | |

|Response: |

| |

| |

| |

Form A.3

Technical Requirements Matrix (TRM) for Basic Transit Scheduling System

Request for Qualification Number R207-20

Bidders proposing on the Basic Transit Scheduling system are instructed to complete a Technical Requirements Matrix (TRM) as part of their technical proposal submittal. Within the TRM, Bidders are required to describe in detail how their proposed solution meets the specification outlined within each requirement. All responses should be entered within the corresponding columns and rows within the TRM.

The TRM is used to document and track the scheduling system requirements from the proposal through implementation to testing to verify that all requirements have been completely fulfilled. The Bidder will be responsible for maintaining the contractually agreed upon set of baseline requirements. The requirements and Bidder’s responses described in the TRM will form a basis for subsequent testing and validation that all requirements have been met.

The TRM must indicate whether and how the Bidder is able to comply with each requirement. It is not essential that Bidders meet all requirements, though each requirement not met will lead to a reduction in the Bidder’s score. In cases where the Bidder’s offering does not currently meet a requirement but the Bidder plans to implement necessary customizations or enhancements in order to comply with the requirement, the Bidder should describe its approach to making the necessary changes. It is not sufficient for the Bidder to simply state that it intends to meet a requirements of the RFQ without providing additional description, and NDOT will consider any such response to a requirement in this RFQ to be non-responsive. The narrative should provide NDOT with sufficient information to compare and contrast the Bidder’s technical solution with other Bidders’ solutions.

The Bidder must ensure that the original requirement identifier and requirement description are maintained in the TRM as provided by NDOT. Failure to maintain these elements may be grounds for disqualification.

How to complete the TRM:

|TRM Column Description |Bidder Responsibility |

|TR # |The unique identifier for the technical requirement as assigned by NDOT. This column is dictated by this RFQ and |

| |must not be modified by the Bidder. |

|Requirement Description |The statement of the requirement to which the Bidder must respond. This column is dictated by the RFQ and must not |

| |be modified by the Bidder. |

|Resp. |Each of the items from the Technical Requirements Matrix of this RFQ require a response of Y (Yes), C (Custom) or N |

|(Response Code) |(No). Below is a brief explanation of each. |

| |Y |

| |Yes, the system in its current release meets the requirement without manipulation or addition of functions, fields, |

| |tables, or forms to the system. |

| | |

| |C |

| |Yes, the system will be able to meet the requirement, with some customization required but at no additional cost. |

| | |

| |N |

| |No, the software does not or cannot meet the requirement. |

| | |

|Response |Provide a short description for each requirement that is compliant as well as an explanation of any modifications |

| |that will be required to meet the requirement and a description of how the modification will be accomplished. In |

| |cases where the requirement description has posed specific questions to the Bidder, please be sure that your |

| |responses address the questions asked. A restatement of the requirement is not considered a substantive response. |

Technical Requirements Matrix (TRM) Attach additional pages as needed.

|TR # Technical Requirement Description |

|TR.1 |User Accounts, Permissions, and Tracking |Resp. |

|User Accounts |

|TR.1.1 |The system includes user accounts. To access the system, a registered user enters credentials (user name and password) associated with their user account. |Y/C/N |

|Response: |

| |

| |

| |

|Role Based Permissions |

|TR.1.2 |Each user can be associated with one or more user roles. Access to data and functionality within the system is based on the permissions associated with the user’s role or roles. At |Y/C/N |

| |minimum, the system provides expanded access to administrative users in comparison to other system users. Please describe standard user roles that are available in your system, and | |

| |whether it is possible for agencies to create their own customized user roles if needed. | |

|Response: |

| |

| |

| |

|User Management Console |

|TR.1.3 |The system includes functionality that allows administrative users to manage user accounts for other system users. This includes adding a new user, editing the information for an |Y/C/N |

| |existing user (such as changing user role, or updating user password), or deleting an existing user who no longer works at the purchasing Transit Agency. | |

|Response: |

| |

| |

| |

|User Self-Management |

|TR.1.4 |The system allows a logged in user to update their own information, such as changing their password. |Y/C/N |

|Response: |

| |

| |

| |

|Audit Trail Functionality |

|TR.1.5 |System keeps a log of date, time, entry, and user associated with any entry or changes to data for customers, drivers, vehicles, trips, and runs. |Y/C/N |

|Response: |

| |

| |

| |

|TR.2. Customer Information Resp. |

|Customer Data Records |

|TR.2.1 |System supports creating, editing, or deleting customer records. |Y/C/N |

|Response: |

| |

| |

| |

|General Customer Data |

|TR.2.2 |System supports editing of general information about customers, such as name, address, phone, email, gender, date of birth, emergency contact, language spoken, and caregiver data. |Y/C/N |

|Response: |

| |

| |

| |

|Customer Transportation Data |

|TR.2.3 |System supports editing information about customer transportation characteristics, such as required accommodations, mobility aids, attendants or companions, disability status, |Y/C/N |

| |eligibility for different funding programs, subscription number, Medicare number, and Medicaid number. | |

|Response: |

| |

| |

| |

|Customer Documentation |

|TR.2.4 |System supports upload and storage of documents that can be associated with a customer record (such as a scan of an eligibility application form). |Y/C/N |

|Response: |

| |

| |

| |

|Customer Trip Data |

|TR.2.5 |System stores information about trips that a customer has previously taken, or is scheduled to take in the future. (See subsequent requirements related to trip data for more details). |Y/C/N |

|Response: |

| |

| |

| |

|TR.3. Driver Information |Resp. |

|Driver Data Records |

|TR.3.1 |System supports creating, editing, or deleting of driver records. |Y/C/N |

|Response: |

| |

| |

| |

|General Driver Data |

|TR.3.2 |System supports editing of general information about drivers, such as name, address, phone, email, gender, date of birth, and emergency contact. |Y/C/N |

|Response: |

| |

| |

| |

|Driver Availability Data |

|TR.3.3 |System supports editing and tracking information about the days and times that drivers are available to drive or unavailable to drive. |Y/C/N |

|Response: |

| |

| |

| |

|Driver Qualification Data |

|TR.3.4 |System supports editing and tracking information about qualifications that drivers are expected to maintain (such as annual safety training, or valid driver’s license) and when the |Y/C/N |

| |qualifications need to be renewed. | |

|Response: |

| |

| |

| |

|Driver Documentation |

|TR.3.5 |System supports uploading and storing documents that can be associated with a driver record (such as a scan of the driver’s current driver license). |Y/C/N |

|Response: |

| |

| |

| |

|Driver Run Data |

|TR.3.6 |System stores information about runs that a driver has previously driven or is scheduled to drive in the future. (See subsequent requirements related to run data for more details). |Y/C/N |

|Response: |

| |

| |

| |

|TR.4. Vehicle Information |Resp. |

|Vehicle Data Records |

|TR.4.1 |System supports creating, editing, or deleting of vehicle records. |Y/C/N |

|Response: |

| |

| |

| |

|General Vehicle Data |

|TR.4.2 |System supports editing of general information about a vehicle such as make, model, year, VIN, and current odometer reading. |Y/C/N |

|Response: |

| |

| |

| |

|Vehicle Mobility Configuration Data |

|TR.4.3 |System supports creating different possible mobility configurations (combinations of seats, tie down spaces, etc.) that are possible, and then associating the mobility configurations |Y/C/N |

| |with different vehicles or vehicle types. For example, a certain type of van could potentially be configured with three seats and one tie-down space, or alternatively with two seats and | |

| |two tie-down spaces. | |

|Response: |

| |

| |

| |

|Vehicle Certification Data |

|TR.4.4 |System supports creating different certifications that a vehicle must maintain, such as annual safety inspection or registration. System tracks both previously completed certifications |Y/C/N |

| |as well as upcoming certifications. | |

|Response: |

| |

| |

| |

|Vehicle Preventative Maintenance Data |

|TR.4.5 |System supports creating different standard preventative maintenance profiles that can be specified for different vehicles or vehicle types. System tracks previously completed |Y/C/N |

| |preventative maintenance as well as upcoming preventative maintenance requirements. | |

|Response: |

| |

| |

| |

|Vehicle History |

|TR.4.6 |System supports logging of additional vehicle history events, such as vehicle purchase, crashes, non-preventative maintenance, and so forth. |Y/C/N |

|Response: |

| |

| |

| |

|Vehicle Documents |

|TR.4.7 |System supports uploading and storing documents that can be associated with a vehicle record (such as the bill of scale, or scanned vehicle maintenance receipts). |Y/C/N |

|Response: |

| |

| |

| |

|Vehicle Run Data |

|TR.4.8 |System can store information about runs that have been performed using the vehicle, or that have been scheduled with the vehicle in the future. (See subsequent requirements related to |Y/C/N |

| |run data for more details). | |

|Response: |

| |

| |

| |

|TR.5. Trips |Resp. |

|Trip Data Records |

|TR.5.1 |System supports creating, editing, and deleting of trip records. |Y/C/N |

|Response: |

| |

| |

| |

|General Trip Data |

|TR.5.2 |System supports editing general information about trips that have been entered in the system, such as customer, origin, scheduled pickup time, actual pickup time, destination, scheduled |Y/C/N |

| |drop off time, actual drop off time, trip purpose, outcome, funding source, and fare paid or donation provided. | |

|Response: |

| |

| |

| |

|Trip Timestamp Data |

|TR.5.3 |System supports entry or capture of timestamps associated with milestone events for a trip (e.g., when pickup was planned vs. when pickup actually occurred). |Y/C/N |

|Response: |

| |

| |

| |

|Trip Outcomes |

|TR.5.4 |System supports entry or editing of trip outcomes, including canceled, denial, refusal, turndown, no show, and completed. |Y/C/N |

|Response: |

| |

| |

| |

|Trips with Individual Customers |

|TR.5.5 |System supports scheduling of trips involving individual customers. System supports tracking information about a caregiver or companions who may accompany an individual customer. |Y/C/N |

|Response: |

| |

| |

| |

|Trips with Multiple Customers |

|TR.5.6 |System supports scheduling of trips involving multiple customers traveling from the same origin to the same destination. |Y/C/N |

|Response: |

| |

| |

| |

|Subscription Trip Templates |

|TR.5.7 |System supports creating, editing, and deleting of subscription trip templates. These describe repeat trips that recur on a specified basis, such as every Monday at 11 am. |Y/C/N |

|Response: |

| |

| |

| |

|TR.6. Runs |Resp. |

|Run Data Records |

|TR.6.1 |System supports creating, editing, and deleting of run records. |Y/C/N |

|Response: |

| |

| |

| |

|General Run Data |

|TR.6.2 |System supports editing general information about runs that have been entered in the system, such as driver of run, vehicle used for run, odometer readings at beginning and end of run, |Y/C/N |

| |start time and end time of run, and series of trips scheduled for the run. | |

|Response: |

| |

| |

| |

|Recurring Run Templates |

|TR.6.3 |System supports creating, editing, and deleting of recurring run templates. These describe runs that recur on a specified basis, such as every Monday and every Friday from 9 am to 5 pm. |Y/C/N |

|Response: |

| |

| |

| |

|TR.7. Scheduling and Dispatch |Resp. |

|Call-n-Ride Service |

|TR.7.1 |System supports specification and scheduling of “call-n-ride” or “dial-a-ride” type of service, as implied by many of the preceding requirements. In such service, vehicles can pick up |Y/C/N |

| |and drop off passengers anywhere within a geographically defined service area. Correspondingly, the route and series of stops that the vehicle makes will often be very different from one| |

| |day to the next, depending on the set of trips that need to be served and how those trips are allocated to different vehicles in the fleet. | |

|Response: |

| |

| |

| |

|Advanced Scheduling |

|TR.7.2 |System supports advanced scheduling of trips. |Y/C/N |

|Response: |

| |

| |

| |

|Same-Day Scheduling |

|TR.7.3 |System supports scheduling of trips onto same day runs, including runs that may already be underway (assuming that the run has sufficient slack capacity to accommodate the trip). |Y/C/N |

|Response: |

| |

| |

| |

|Manual Trip Scheduling and Tracking |

|TR.7.4 |System allows staff to manually schedule trips, including entering new trip requests, adding a trip to a run, modifying the sequence of trip pickups and drop offs on a run, removing a |Y/C/N |

| |trip from a run, and updating information about trip outcomes, such as whether the trip was completed and actual pickup and drop off times. | |

|Response: |

| |

| |

| |

|Manual Run Entry and Tracking |

|TR.7.5 |System allows staff to manually enter and update information about runs such as driver, vehicle, start and end times, trips served, and beginning and ending odometer reading. |Y/C/N |

|Response: |

| |

| |

| |

|Manual Scheduling Aids |

|TR.7.6 |System provides tools to help schedulers determine feasible and efficient trip and run schedules. Possible examples include keeping track of vehicle occupancy (and making sure falls |Y/C/N |

| |within capacity) or highlighting cases in which the estimated time of arrival is much later than the scheduled arrival time. Please describe manual scheduling aids provided by your | |

| |system. | |

|Response: |

| |

| |

| |

|Automatic Instantiation of Subscription Trips |

|TR.7.7 |System can generate new subscription trips automatically for the specified days and times associated with subscription trip templates. |Y/C/N |

|Response: |

| |

| |

| |

|Automatic Instantiation of Recurring Runs |

|TR.7.8 |System can generate new recurring runs automatically for the specified days and times associated with recurring run templates. |Y/C/N |

|Response: |

| |

| |

| |

|Default Scheduling for Subscription Trips and Recurring Runs |

|TR.7.9 |System allows staff to indicate that a subscription trip should be added to a recurring run by default; schedulers can subsequently alter this assignment if needed. |Y/C/N |

|Response: |

| |

| |

| |

|Schedule Optimization Algorithms |

|TR.7.10 |System provides algorithms that can assign trips to runs and sequence trips within runs in order to build feasible and efficient schedules. |Y/C/N |

|Response: |

| |

| |

| |

|Optimize Entire Schedule |

|TR.7.11 |Making use of the scheduling algorithms, the system can build an entire day’s schedule - assigning and sequencing all trips and runs - from scratch. |Y/C/N |

|Response: |

| |

| |

| |

|Optimize Changes to Schedule |

|TR.7.12 |Making use of the scheduling algorithms, the system can optimize partial changes to an existing schedule. Examples include finding a run on which to place a new trip request, or |Y/C/N |

| |canceling one run and rescheduling as many trips from that run as possible onto other runs. Please describe the options that are possible with your system to make partial changes to a | |

| |schedule via optimization algorithms. | |

|Response: |

| |

| |

| |

|Scheduling Parameters |

|TR.7.13 |System allows Transit Agencies to set up scheduling parameters that can be used by the scheduling algorithms to ensure that resulting schedules are feasible for the Transit Agency to |Y/C/N |

| |implement. Examples of scheduling parameters might include minimum arrival time buffer to help ensure on time performance even when the vehicle experiences minor delays, rules regarding | |

| |required break times (e.g. lunch break) for drivers in the middle of a run, or indicating that two particular customers should not be scheduled on the same run if possible. Please | |

| |describe the parameters that your system makes available for Transit Agencies to tailor the results of the schedule building optimization algorithms. | |

|Response: |

| |

| |

| |

| |

|Scheduling API |

|TR.7.14 |System provides an API that allows 3rd party applications to connect to the system, issue a request for scheduling a trip, and receive confirmation that the trip has been scheduled (or |Y/C/N |

| |alternatively a notice that the trip could not be scheduled, and why). | |

|Response: |

| |

| |

| |

|Validation of Trips |

|TR.7.15 |System includes functionality to validate trip records at the end of the day to reconcile between trips originally scheduled and trips actually delivered. Please describe the data that |Y/C/N |

| |is updated as well as the manual and automated portions of the validation process. | |

|Response: |

| |

| |

| |

|TR.8. Fare Payment |Resp. |

|Electronic Fare Payment |

|TR.8.1 |System supports one or more forms of electronic payment, such as a mobile payment app or prepaid fare cards that can be scanned and debited by driver. Please describe all options |Y/C/N |

| |supported by the system. | |

|Response: |

| |

| |

| |

|TR.9. Reporting |Resp. |

|Manifest |

|TR.9.1 |System can export a hard copy manifest to give to a driver. |Y/C/N |

|Response: |

| |

| |

| |

|Management Reports |

|TR.9.2 |System can generate additional reports to assist the Transit Agency in effectively managing and improving service. Reporting capabilities should include the following: |Y/C/N |

| |Fare revenue | |

| |Vehicle revenue miles | |

| |Vehicle revenue hours of service | |

| |Passenger boardings | |

| |Sponsored passenger boardings | |

| |Organization/contract paid fares | |

| |Flex/fixed route data for all of the above | |

| |Medicaid trips | |

| |Medicaid fares | |

| |No shows | |

| |Trip purpose | |

| |Customer information | |

| |Fuel information (dates, gallons, cost) | |

| |Passenger demographic information | |

| |Vehicle PM reminders | |

| |Vehicle maintenance records | |

| |Driver hours/timesheets | |

| |Client trip detail | |

| |Please enumerate the reports available in your system and describe how they meet the above reporting requirements. | |

|Response: |

| |

| |

| |

|Ad Hoc Queries |

|TR.9.3 |System allows Transit Agencies to define and execute ad hoc queries of data stored in the system and then export results to csv or Excel files. Please describe the mechanisms through |Y/C/N |

| |which Transit Agencies can specify ad hoc queries to execute. | |

|Response: |

| |

| |

| |

|Additional System Requirements |

|TR.10. Data Ownership |Resp. |

|Purchasing Transit Agency Data Ownership |

|TR.10.1 |Purchasing Transit Agency shall own all data stored in the system. |Y/C/N |

|Response: |

| |

| |

| |

|Final Data Export |

|TR.10.2 |At the end of the contract, the Contractor shall assist the purchasing Transit Agency by creating an export of all system data that can then be migrated into a different system. |Y/C/N |

|Response: |

| |

| |

| |

|TR.11. Hosting, Backup, and Security |Resp. |

|Web Hosted |

|TR.11.1 |The system shall be web hosted. Please describe whether the system is hosted at the Contractor’s own facility or via a 3rd party service such as AWS or Azure. |Y/C/N |

|Response: |

| |

| |

| |

|Fully Backed Up |

|TR.11.2 |The hosting arrangement will include a continuously updated backup of the database to allow for full restoration in the case of system failure. Please describe your procedures for system|Y/C/N |

| |backup. | |

|Response: |

| |

| |

| |

|HIPAA Compliant |

|TR.11.3 |The system shall be HIPAA compliant. Please indicate the date of your most recent audit to demonstrate compliance and indicate if you have signed any Business Associate agreements. |Y/C/N |

|Response: |

| |

| |

| |

Form A.4

Optional Capabilities Matrix (OCM) for Basic Transit Scheduling System

Request for Qualification Number R207-20

Bidders proposing on the Basic Transit Scheduling System are instructed to complete the Optional Capabilities Matrix (OCM) as part of their technical proposal submittal. This matrix includes functionality that is not required for the basic software solution but may nonetheless be of interest to some agencies as potential system upgrades. Bidders are required to indicate whether their system provides each capability described in the OCM and, if so, whether or not it entails additional cost. For any optional capabilities that are available at additional cost, Bidders should indicate corresponding cost information in Form A.7. Note that information provided by Bidders within the OCM, as well as in Form A.7, is not scored as part of the solicitation. Rather, for any Bidder that is prequalified based on this solicitation, information provided within the OCM and Form A.7 will be made available to transit agencies to help them formulate near- and longer-term technology acquisition plans.

How to complete the OCM:

|OCM Column Description |Bidder Responsibility |

|OC # |The unique identifier for the described optional capability as assigned by NDOT. This column is dictated by this RFQ|

| |and must not be modified by the Bidder. |

|Capability Description |The description of the optional capability to which the Bidder must respond. This column is dictated by the RFQ and |

| |must not be modified by the Bidder. |

|Resp. |Each of the capabilities listed within the OCM requires a response of F, C, or N, defined as follows: |

|(Response Code) |F |

| |This capability is available at no additional cost (i.e., free). |

| | |

| |C |

| |This capability is available, or can be made available with some customization, but entails additional cost. |

| | |

| |N |

| |The software does not or cannot meet the requirement. |

| | |

|Response |Provide a short description for each capability that is available in the system as well as an explanation of any |

| |modifications that may be required in order to support the capability. In cases where the capability description has|

| |posed specific questions to the Bidder, please be sure that your responses address the questions asked. |

Optional Capabilities Matrix (OCM) Attach additional pages as needed.

|OC # |Capability Description | |

|HIPAA Compliant |Resp. |

|Flex Route Scheduling |

|OC.1 |In addition to call-n-ride service, some Transit Agencies in Nebraska also operate “flex route” or “deviated fixed route” type of service. In this type of service, vehicles travel from|F/C/N |

| |an origin to a destination by following a defined route that includes a series of timed checkpoints points (e.g., the vehicle will pass by a particular intersection at along the route | |

| |at 11:15). Between the checkpoints, however, the vehicle can divert from the main route to pick up or drop off passengers who have scheduled their trips in advance or made direct | |

| |arrangements with the driver. Please indicate whether your system supports scheduling of flex route services and, if so, describe key features of this functionality, including how | |

| |customers interact with dispatchers or drivers to request deviations for pickup or drop-off. | |

|Response: |

| |

| |

| |

|Support for Trip Coordination or Brokerage |

|OC.2 |Please discuss functionality or APIs available in your system to support trip coordination or brokerage among service providers. This may include, for example, functions that allow a |F/C/N |

| |scheduler to request assistance on serving hard-to-schedule trips or entire vehicle runs from another provider (e.g. a taxi or a human service provider) and to enter information on | |

| |trips provided that is received from other providers. Please indicate whether coordination or brokerage functionality is only available for interactions between providers that also use| |

| |your system, or whether your system can interact (e.g., via API) with other systems from different software providers in support of coordination or brokerage. | |

|Response: |

| |

| |

| |

|SMS Customer Messages |

|OC.3 |Please indicate whether your system can provide trip reminder and update messages to customers via SMS texts. |F/C/N |

|Response: |

| |

| |

| |

|IVR Customer Communications |

|OC.4 |Please indicate whether your system can provide trip reminder and update messages to customers via IVR. |F/C/N |

|Response: |

| |

| |

| |

|Customer App |

|OC.5 |Please indicate whether your system includes a customer app - either web-based or native - that provides customers with functionality such as booking or canceling a trip or checking on|F/C/N |

| |the ETA for an upcoming trip. Also indicate whether the app has been designed to be accessible for customers with visual impairments, and describe the accessibility standards you have | |

| |followed and any accessibility audits that you have conducted. | |

|Response: |

| |

| |

| |

|CAD, AVL, and Driver App |

|OC.6 |Some Transit Agencies who choose the basic system may still be interested in including CAD and AVL functionality, enabled via in-vehicle devices and a driver app, either in the |F/C/N |

| |near-term or over the longer term. Please indicate whether your system includes CAD and AVL as an option and describe the functionality provided by the driver app as well as the CAD | |

| |display component. | |

|Response: |

| |

| |

| |

|In-Vehicle Devices and Cellular Data Plans |

|OC.7 |Some Transit Agencies may choose to purchase in-vehicle devices and cellular data service plans from wireless carriers. Others may prefer to purchase these items from a prequalified |F/C/N |

| |Contractor as an element of the scheduling system contract. Please indicate whether you can include in-vehicle devices (both initial purchase and ongoing warranty over the life of the | |

| |contract) and data plans as part of your offering. Please also indicate if you have any preferred or required brands, models, operating systems, or minimum specifications for | |

| |in-vehicle devices to perform well with your CAD/AVL system and driver app. | |

|Response: |

| |

| |

| |

|In-Vehicle Device Installation |

|OC.8 |Independent of whether a Transit Agency purchases in-vehicle devices from a wireless carrier or from a prequalified Contractor, the Transit Agency may also require services to securely|F/C/N |

| |mount the devices within the vehicles. Please indicate whether you are able to offer such services. If so, describe the type of mounting hardware that you would include and whether | |

| |there are any constraints with respect to the size of the device to be mounted (e.g. a smaller tablet vs. a larger tablet). | |

|Response: |

| |

| |

| |

|Funding Sources, Fare/Donation Structure, and Billing Function |

|OC.9 |Please describe whether and how your system supports configuration of funding sources that may be applied for different customers or trips. Also describe whether your system supports |F/C/N |

| |configurable fare structure or donation amounts that may be applied to different services or trips. Examples include flat fare, mileage-based fare, zone-based fare, and flat suggested | |

| |donation. Finally, please indicate if your system has the ability to generate reports or invoices based on services delivered, cost of trips, and fares collected. Describe the billing | |

| |functions that are part of the core system. For systems with multiple funding sources or bidders, describe the ability of the core system to generate invoices or reports for different| |

| |fund sources or bidders. | |

|Response: |

| |

| |

| |

|Advanced Optional Management Reports |

|OC.10 |Please indicate if your system supports these additional management reporting capabilities: |F/C/N |

| |Billing | |

| |Average trip distance | |

| |Average trip duration | |

| |New clients this month | |

| |Client balance | |

| |Client balance transaction history | |

| |Average vehicle speed | |

| |Driver performance | |

| |On time performance | |

|Response: |

| |

| |

| |

|FTA-Required Reports |

|OC.11 |Indicate if your system can output FTA-required reports such as National Transit Database (NTD) report. |F/C/N |

|Response: |

| |

| |

| |

|GTFS Flex Data Generation |

|OC.12 |Please indicate if or when your system will be able to generate GTFS Flex data to describe call-n-ride and flex route services so that they can be included in trip planning tools. |F/C/N |

|Response: |

| |

| |

| |

Form A.5

Cost Proposal Summary

Request for Qualification Number R207-20

To complete the cost proposal summary, please indicate summary costs for different items and different years in the table, noting that values should only be entered in white cells. Additionally, please indicate total costs by category (across years) and by year (across categories).The summary costs entered in table are to be based on detailed cost worksheets in Form A.6. As discussed at the beginning of Form A.6, elements of these cost categories may be based upon the characteristics of the representative small transit agency described at the beginning of Form A.

The payment schedule for a selected system deployment is tied to fixed lump sum payments for the completion and acceptance of related deliverables corresponding to cells in the table below. No invoice will be approved unless the associated deliverables have been approved.

Cost Proposal Summary

|Category |Startup |Year 1 |Year 2 |Year 3 |Year 4 |

|Unit Value |N/A |1 user |1 vehicle |10,000 trips | |

|Line Item Component Costs |

|Deployment Plan | | | | | |

|Unit Value |N/A |1 user |1 vehicle |10,000 trips | |

|Line Item Component Costs |

|System Deployment, Integration | | | | | |

|Unit Value |N/A |1 user |1 vehicle |10,000 trips | |

|Line Item Component Costs |

|Licensing | | | | | |

|Unit Value |N/A |1 user |1 vehicle |10,000 trips | |

|Line Item Component Costs |

|Licensing | | | | | |

|Unit Value |N/A |1 user |1 vehicle |10,000 trips | |

|Line Item Component Costs |

|Licensing | | | | | |

|Unit Value |N/A |1 user |1 vehicle |10,000 trips | |

|Line Item Component Costs |

|Licensing | | | | | |

|Unit Value |N/A |1 user |1 vehicle |10,000 trips | |

|Line Item Component Costs |

|Licensing | | | | |

|Startup Cost | | | | |

|Year 1 Cost | | | | |

|Year 2 Cost | | | | |

|Year 3 Cost | | | | |

|Year 4 Cost | | | | |

|Year 5 Cost | | | | |

Trip Coordination/Brokerage Costs

|Period/Element |Base Cost |Per-User Cost |Per-Vehicle Cost |Per-Annual Trips Cost |

| | |(1 user) |(1 vehicle) |(10,000 trips) |

|Startup Cost | | | | |

|Year 1 Cost | | | | |

|Year 2 Cost | | | | |

|Year 3 Cost | | | | |

|Year 4 Cost | | | | |

|Year 5 Cost | | | | |

SMS Customer Messaging Costs

|Period/Element |Base Cost |Per-User Cost |Per-Vehicle Cost |Per-Annual Trips Cost |

| | |(1 user) |(1 vehicle) |(10,000 trips) |

|Startup Cost | | | | |

|Year 1 Cost | | | | |

|Year 2 Cost | | | | |

|Year 3 Cost | | | | |

|Year 4 Cost | | | | |

|Year 5 Cost | | | | |

IVR Customer Communication Costs

|Period/Element |Base Cost |Per-User Cost |Per-Vehicle Cost |Per-Annual Trips Cost |

| | |(1 user) |(1 vehicle) |(10,000 trips) |

|Startup Cost | | | | |

|Year 1 Cost | | | | |

|Year 2 Cost | | | | |

|Year 3 Cost | | | | |

|Year 4 Cost | | | | |

|Year 5 Cost | | | | |

Customer App Costs

|Period/Element |Base Cost |Per-User Cost |Per-Vehicle Cost |Per-Annual Trips Cost |

| | |(1 user) |(1 vehicle) |(10,000 trips) |

|Startup Cost | | | | |

|Year 1 Cost | | | | |

|Year 2 Cost | | | | |

|Year 3 Cost | | | | |

|Year 4 Cost | | | | |

|Year 5 Cost | | | | |

CAD, AVL, and Driver App Costs

|Period/Element |Base Cost |Per-User Cost |Per-Vehicle Cost |Per-Annual Trips Cost |

| | |(1 user) |(1 vehicle) |(10,000 trips) |

|Startup Cost | | | | |

|Year 1 Cost | | | | |

|Year 2 Cost | | | | |

|Year 3 Cost | | | | |

|Year 4 Cost | | | | |

|Year 5 Cost | | | | |

In-Vehicle Devices and Cellular Data Plans (Vendor Provided)

|Period/Element |Base Cost |Per-User Cost |Per-Vehicle Cost |Per-Annual Trips Cost |

| | |(1 user) |(1 vehicle) |(10,000 trips) |

|Startup Cost | | | | |

|Year 1 Cost | | | | |

|Year 2 Cost | | | | |

|Year 3 Cost | | | | |

|Year 4 Cost | | | | |

|Year 5 Cost | | | | |

In-Vehicle Device Installation

|Period/Element |Base Cost |Per-User Cost |Per-Vehicle Cost |Per-Annual Trips Cost |

| | |(1 user) |(1 vehicle) |(10,000 trips) |

|Startup Cost | | | | |

|Year 1 Cost | | | | |

|Year 2 Cost | | | | |

|Year 3 Cost | | | | |

|Year 4 Cost | | | | |

|Year 5 Cost | | | | |

Funding Sources, Fare/Donation Structure, and Billing Function Costs

|Period/Element |Base Cost |Per-User Cost |Per-Vehicle Cost |Per-Annual Trips Cost |

| | |(1 user) |(1 vehicle) |(10,000 trips) |

|Startup Cost | | | | |

|Year 1 Cost | | | | |

|Year 2 Cost | | | | |

|Year 3 Cost | | | | |

|Year 4 Cost | | | | |

|Year 5 Cost | | | | |

Advanced Optional Management Reports Costs

|Period/Element |Base Cost |Per-User Cost |Per-Vehicle Cost |Per-Annual Trips Cost |

| | |(1 user) |(1 vehicle) |(10,000 trips) |

|Startup Cost | | | | |

|Year 1 Cost | | | | |

|Year 2 Cost | | | | |

|Year 3 Cost | | | | |

|Year 4 Cost | | | | |

|Year 5 Cost | | | | |

FTA-Required Reporting Costs

|Period/Element |Base Cost |Per-User Cost |Per-Vehicle Cost |Per-Annual Trips Cost |

| | |(1 user) |(1 vehicle) |(10,000 trips) |

|Startup Cost | | | | |

|Year 1 Cost | | | | |

|Year 2 Cost | | | | |

|Year 3 Cost | | | | |

|Year 4 Cost | | | | |

|Year 5 Cost | | | | |

GTFS Flex Data Genertion Costs

|Period/Element |Base Cost |Per-User Cost |Per-Vehicle Cost |Per-Annual Trips Cost |

| | |(1 user) |(1 vehicle) |(10,000 trips) |

|Startup Cost | | | | |

|Year 1 Cost | | | | |

|Year 2 Cost | | | | |

|Year 3 Cost | | | | |

|Year 4 Cost | | | | |

|Year 5 Cost | | | | |

Form A.8

Fixed Hourly Rates

Request for Qualification Number R207-20

Some transit agencies may require additional services not described in the scope of work. Please provide time and material rate categories, and corresponding all-inclusive hourly rates, for all job categories that might be involved in add-on work. These rates shall remain fixed for the life of the contract, including any optional renewal periods.

|Job Title |All Inclusive Hourly Rate |

|Example: Project Manager |$ per hour |

| |$ per hour |

| |$ per hour |

| |$ per hour |

| |$ per hour |

| |$ per hour |

| |$ per hour |

| |$ per hour |

| |$ per hour |

| |$ per hour |

| |$ per hour |

| |$ per hour |

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download