AMENDMENT - REQUEST FOR PROPOSAL (RFP)

Transcription

1 AMENDMENT - REQUEST FOR PROPOSAL (RFP) Amendment No. 002 RFP No COMPANY NAME AND ADDRESS (To be completed by Proposer) Project No. Issued By The hour and date specified for receipt of proposals is: [ ] Not extended [ ] Extended to at. Date Time The RFP is amended as follows: Date Amendment Issued 03/22/2018 METROPOLITAN TRANSIT AUTHORITY Procurement Division 1900 Main Street Houston, Texas P. O. Box Houston, Texas Exhibit XI.1 SCOPE OF SERVICES, Paragraph C.2 Task 2: Implementation/Deployment is removed and replaced with the attached version. Except as provided herein, all instructions and provisions of the RFP, as heretofore changed, remain unchanged and in full force and effect. Proposers must acknowledge receipt of the amendment prior to the hour and date specified for proposal delivery, by one of the following methods: 1. By acknowledging receipt of this amendment on the Proposal form; 2. By signing and returning one (1) copy of this amendment with your Proposal; 3. By separate letter acknowledging receipt. FAILURE TO ACKNOWLEDGE RECEIPT MAY CAUSE FOR PROPOSAL REJECTION BY METRO. PROPOSER (Authorized Representative) BY NAME: SIGNATURE: TITLE: DATE: BY NAME: Alan Scanio SIGNATURE: //Signed// TITLE: Sup. Contract Spc. METROPOLITAN TRANSIT AUTHORITY (Authorized Representative) 1

2 2. Task 2: Implementation/Deployment The Contractor shall provide a multi-phased deployment approach. The following capabilities must be available in the Solution and be available for METRO to deploy in its timeline. The following phases/tasks must be adhered to and specified phase deliverables produced by the Contractor as part of delivering a fully functional and tested mobile ticketing application: a. Task 2.1: Project Initiation The Contractor must meet with METRO project management and business area stakeholders for project planning, including review of proposed schedule, roles and responsibilities, conduct complete review of functionality to be delivered, and other project activities. Project Organization Project Schedule (Draft) System Implementation Plan (Draft) Project Resource Plan (Draft) Risk Management Plan (Draft) Project Kick Off Meeting (joint project team - Contractor and METRO) b. Task 2.2: Design The Contractor shall gather technical requirements and provide a detailed design, beginning with on-site assessment and discussions with affected METRO departments. It will include but not limited to the following activities: Determine how the hardware (if any) and systems will be installed, Determine application presentation and user interaction including layouts and screenshots Determine how the solution will be managed on the back end Determine interactions with other systems (Trip planners, etc.). On-site Assessment; documentation of findings System Detailed Design System Implementation and Resource Plan (Final) Risk Management Plan (Final) Application Branding (to METRO specifications) Final Project Schedule c. Task 2.3: Development The Contractor shall develop and install all applications within a test environment so configuration and testing of the required functionality can be started. The engineering of validation hardware must be completed and a prototype available for testing. The Contractor must do the initial set-up and configuration, to allow testing and any required change if needed. The Contractor must prepare and plan the rollout of the system, which includes training all IT, maintenance, fare inspectors, administrators and operational staff who will have a role in the support. Mobile ticketing application Validation API Test Environment Inspection API Test Procedure/Plan including use cases; test scripts Training Plan (Draft) Maintenance & Support Responsibility Matrix (Draft) 2

3 d. Task 2.4: Integration Testing The Contractor shall integrate and test the Solution with METRO s assistance to ensure all required functionality is available and working as described in this document. Testing will not be accepted until all functional requirements of the newly implemented mobile ticketing application system have been fully tested and approved by METRO s project team. The Contractor shall provide a test procedure document with test scripts for review and acceptance by METRO, with the appropriate updates and/or revisions based on previous phase implementation findings. Test Procedure/Plan including use cases; test scripts; acceptance test criteria (Final) Test Results, with Test Failure Log & Remediation Plan Training Plan (Final) Maintenance & Support Responsibility Matrix (Final) e. Task 2.5: Training, Marketing and Outreach The Contractor shall develop the training materials, marketing approach and customer outreach. The Contractor shall, with METRO s assistance, develop training materials that will provide a basis to help instruct METRO customers in the easiest and most efficient way to use the system. The Contractor shall develop a Marketing and Outreach plan with recommendations for a successful launch of mobile ticketing based on their expertise. However, the Vendor shall not lead or customer outreach effort. The Contractor shall provide high quality images for use in marketing materials, informational copy explaining how to use the system, and assist with motion graphics and other marketing materials needed to educate and promote the solution including branding of the application. Marketing & Customer Outreach Plan User Training Plan and Documentation f. Task 2.6: Deployment Deployment may commence only after all testing issues and errors have been corrected to METRO requirements. The Contractor shall install the hardware and software in the live environment and conduct training so that all pupils are knowledgeable and understand their role in managing the system. If the Contractor s Solution required hardware to be installed on METRO s vehicles, then the Contractor shall provide and install a first article of all onboard vehicle equipment of each vehicle type (e.g. Bus, Rail METROLift Van, etc.) METRO will oversee in conjunction with the Contractor the installation of these first articles. After METRO inspection and approval of the first article of each different vehicle type, the Contractor shall proceed with installation based on the approved methodology and under METRO s quality assurance procedures. Deployment of all application software systems Delivery of all Documentation (Final) Integration of Trip Planning System Go Live Schedule and Transition Plan Security Certification Audit Training Conducted Acceptable First Articles provided 3

4 g. Task 2.7: Limited Rollout METRO will conduct a live test of the Solution with a limited and controlled number of users. This limited testing will last at least 30 days, during which METRO will report to the Contractor any anomalies and performance issues. Issues determined by METRO to require resolution prior to go-live must receive immediate attention and resolution from the Contractor. Issues determined by METRO to be less critical may be resolved on a schedule mutually agreed upon by METRO and the Contractor. The Contractor shall provide the following deliverables during this task: Limited Test Results & Test Failure Log Remediation Plan h. Task 2.8: System Acceptance The monitoring period will end after final acceptance and sign-off by METRO. Activation of Warranty & Maintenance processes and services Review of Lessons Learned Session i. Task 2.9: Go-Live The Contractor shall monitor the Solution for the first 30 days of live revenue service, and respond to issues so they are quickly resolved. METRO may at its sole discretion extend this monitoring period until all issues are resolved. The Contractor shall provide the following deliverables during this task: Final Action Items & Issues Log showing all items have been closed Revised (final) copies of all required documentation 4

5 QUESTIONS AND ANSWERS Project Name: Mobile Ticketing Application Date: Solicitation #: Amendment #: 002 Contract Administrator: Alan Scanio Q39 A39 SCHEDULE QUESTIONS Is the budget of phase 2 items to be included in this proposal submission? There are no phases to this project- any reference to different phases during the pre-proposal meeting was inadvertent. Q40 What is the timeline for implementation of phase 1? What is the timeline for phase 2? A40 There are no phases to this project- any reference to different phases during the pre-proposal meeting was inadvertent. TECHNICAL QUESTIONS Q41 A41 Q42 A42 Q43 A43 Q44 A44 Q45 A45 Q46 A46 Page [6] Section 2 I.3. Under Qualifications/Experience of Firm/Past Performance, how does METRO intend to insure that integration to an AFC back-end has/can be accomplished? The AFC back-end requirements are currently being developed. One of the requirements is integration to the mobile application via API. The mobile vendor is responsible for developing the API and working with the AFC vendor to ensure integration to both systems is successful. Page 20 Section VIII.9.a. Can reasonable transfer language or license usage be offered? Language for transfer and licensing will be agreed upon by both METRO and the awarded vendor s legal departments. Page 20 Section VIII.9.d If a proven solution that has been tested with other operators and reduces the cost of the project because the solution is reused how does Metro intend to handle proprietary solutions? All proposals are welcome; however, a proven solution that is configurable to METRO requirements may gain advantage in evaluation over one that is custom created. Page 33 Section XI.1.A How does METRO intend to handle proprietary APIs and software? All APIs are proprietary, in a sense. The requirement is for the mobile vendor to provide an open API that will allow other vendors to share data between systems. Page 33 Section XI.1.B.1.A. Please confirm if the station and bus validators support: 1. Real time communication with the back office/cloud, with location information. 2. NFC 3. Bar/Q codes 4. Are PCI certified Requirements for validators is currently being defined. However, it is anticipated that all the above forms of communication and compliance will be required. Page 40 Section XI.1.C.2.f. Please define the integration to the trip planner. Integration of trip planner includes at a minimum the ability to launch or deep link to the METRO trip planner application from the mobile ticket app. 5

6 Q47 A47 Q48 A48 Q49 A49 Q50 A50 Q51 A51 Q52 A52 Q53 A53 Q54 A54 Q55 A55 Q56 A56 Q57 A57 Q58 A58 Page 40 Section XI.1.C.2.g. Please define the threshold for system acceptance. System acceptance criteria will be defined and agreed upon between METRO and the application developer during the design and blueprinting phase. Page 41 Section XI.1.D. Please can Metro clarify its requirements of the solution for the Retailers and Cash Management functionality? At minimum, the vendor shall allow customers to purchase fares using cash at a retail location by providing a bar code for verification of purchase. Once the automated fare collection system has been developed, further integration may be required to interact with the back-end. Page 42 Section XI.1.D.1. Please define the ADA requirements for mobile devices, in particular the visually impaired. Please consult the government website for further information on current ADA information and technical requirements. Page 42 Section XI.1.D.1. Please confirm there is no requirement for the mobile solution to load tickets/passes/value to the current or new AFC media. There is no requirement to pass value to the current AFC; however, the new AFC will require data integration to the account-based back-end. Page 42 Section XI.1.D.2. Please define what the current hand held inspection units. Please see Page 37 of the RFP under 3) Integrated Services / Inspection. Page 42 Section XI.1.D.2. Please define the interfaces to: trip planning, schedules and service alerts systems. Interfaces to trip planner, schedules and service alerts includes at a minimum the ability to launch or deep link to the METRO trip planner application and mobile website from the mobile ticket app. Page 43 Section XI.1.D.2 Please confirm if the AFC system stores the fare rules & values and the mobile solution integrates to it; or the mobile solution calculates the fare based on its own fare rules. Once the AFC system is implemented, it becomes an account-based system: the mobile ticketing becomes a mobile frontend for fares and patrons of the new AFC. All rules will come from the AFC integration of APIs, whether for Sale, Validation or Control. At that time, the mobile ticketing won t calculate any fare or usage rule anymore, using those APIs to execute any action linked to patrons or tickets. Page 43 Section XI.1.D.2 Please confirm a change in rider category shall be configured in the mobile solution by a Metro operator or received from the AFC system. Yes, the backend data drives what fares are available for patrons. Patrons do not select what discounts they are eligible for. Patrons are not required to carry proof of eligibility for a discount fare (except METROLift). Page 43 Section XI.1.D.2 Please define the limits to or range of the contractors responsibility after system acceptance to block fraud. Passengers are always trying to find new ways to beat the system. The vendor is liable of any fraudulent activity by patrons or security breach. All parties should maintain proper insurance coverage to protect themselves. Page 43 Section XI.1.D.2. Please define the interface requirements for the METRO financial systems. Will it be an automated data push? In addition to a robust querying and reporting real-time data access, the solution must provide automated access to data, for METRO financial system. The preferred solution would be secured data access allowing METRO interface services to pull the data needed, on schedule. Other less desirable solutions will still be considered. Page 43 Section XI.1.D.2. Please clarify this requirement: Must provide a card processing Contractor to process credit card transactions. It is anticipated that the Contractor will not store or process credit card information, but will partner with a card processing entity to handle credit transactions while securing those transactions using tokens. Is the current Q-Card based system an account based system[?] Does it need to be integrated with the new mobile ticketing software? If integration is required, are you planning to upgrade it in order to integrate with the new mobile ticketing app? The current system is card-based, but allows the card to be registered if the customer desires in order to capture balances in the back-end. It is not anticipated that the current QCard will be integrated into the mobile ticketing app. 6

7 Q59 A59 Q60 A60 Q61 A61 Q62 A62 Q63 A63 Q64 A64 Q65 A65 Q66 A66 Q67 For the trip planner setup, will METRO be able to provide the GTFS and GTFS real time data feeds for all of the modes of transit (bus, rail etc) GTFS-RT feeds are currently available on METRO s website. If a rider s trip uses multiple services, is the customer expected to purchase one ticket that covers the entire journey (including multiple modes such as rail/bus)? Each service and mode is handled independently based on fare zone and fare policy. Is it possible to provide any specifics on reporting/analytics needs you may have? Please see the RFP and Requirements Matrix for specific requirements. The vendor is expected to provide reports for METRO and its partners including but not limited to invoice management, customer account queries and activities, fraud detection, sales information and statistics. Vendor should provide fullyfunctional Reporting Tool/Solution, including direct, unfiltered and secure access to our data, for querying and automated extracts For the validator hardware, are you requiring validators for all vehicle modes (including rail, bus?) Yes. Is METRO desiring to own the hardware validators? Is the budget for the hardware to be included in this proposal? Yes, METRO will ultimately own the equipment. However, hardware is not included as part of this proposal, unless it is proposed by the vendor. Validators are not budgeted at this time. Do you anticipate the drivers to have a smart phone or tablet for the onboard ticket validation? No. Do you have WI FI access on your buses and rail? Not at this time. Is this mobile ticketing solution to address the needs of para transit as well as fixed route passengers? Initially, only fixed route is in scope. How many fixed route buses will be equipped with the hardware validators? A67 Entire fleet, Q68 A68 Q69 A69 How many paratransit vehicles will be equipped with the hardware validators? Not in scope at this time. How many web portals do you need for web-based customer and special group portals? Several Web Portals should be provided at minimum: - Patron Web Portal - Sponsor Web Portal - METRO Support Web Portal - Administrator Web Portal The Reporting & Querying tool could be a web based secured access reporting solution, but this part of the solution is not mandatory as a web portal. 7

8 Q70 A70 Are you looking for any point of sale equipment for in-house sales? If so what types of equipment are needed? Are you looking for a mobile app as well as a mobile friendly desktop version or only a mobile app? We are looking for a Mobile Application (to create/manage an account, then buy/use the tickets) and a Web Portal (to create/manage an account, then buy the tickets) for Patrons or Sponsors. The Web Portal should be mobile friendly but it does not allow to use the tickets, and can have administrative functions not available for Mobile App (like receipts, past activity, additional help and videos, etc ) Q71 A71 The Mobile Application should be self-sufficient for all customer uses, so no customer should be mandated to use the Web Portal to use the solution. During the pre-proposal conference there was mention of the hardware validators only being needed in phase 2. If so what is the scope of phase 1? Could you please provide a prioritization of the scope of features in the matrix provided? Initial deployment of the Mobile Solution will be via visual validation. At some later time, automated validation could be introduced into the system (the methodology [barcode, NFC ] has not been determined yet). That second step could likely be linked to the new AFCS Q72 Should the mobile app support iphone 4? A72 Q73 A73 Due to the discontinuation of TLS1.0 security protocols, older phones (iphone 4 included) that utilize such discontinued security protocols are not part of the required phone support. During the life of this system, other security protocols could be discontinued or become mandatory. Restricting the list of supported phones to newer (and more secure) models: the list of supported phone OS will change over time, as new OS become available or older OS become insecure. What is the annual volume of transactions ($ value, number of tickets sold) that is currently processed through your mobile ticketing app currently in place? Please see the Items and Prices section of the RFP for quantities to be used in this solicitation. Q74 A74 Q75 A75 Q76 A76 Q77 A77 Q78 A78 Q79 A79 What % of your ridership currently uses the mobile ticketing app? Approximately 2% currently. What is the annual ridership for your fixed route and paratransit bus services? Please refer to METRO s website for information regarding ridership. If you are requiring mobile ticketing for paratransit, do you have existing para transit software it needs to integrate with? Not at this time. What is the technology on which the Q-Card based system is built (platform, database, software etc)? Will it have an API provided to integrate with its data or is the vendor required to build that API? No requirement to integrate with the current Q-Card system. Please provide access to the existing Ride Sponsor Web Portal so we can better understand what tools Ride Sponsors have to manage their accounts. Please use the RFP as your guide for required functionality. METRO will not share access to current systems. Section XI, Exhibit A, Article C.2 appears to be missing the task requiring the transition of customers from the current moovel mobile ticketing service to the new service, as discussed during the pre-proposal meeting. Please clarify. Correct. It is anticipated that a data conversion from the current mobile application to the new system will take place. 8

9 Q80 A80 Q81 A81 Q82 A82 Q83 A83 Section IX, Exhibit A, Article D.5, please confirm that the specific branding, etc. referred to in bullet 2 is for the digital ticket displayed on the mobile device. Yes. Branding refers to a unique ticket display for each partner, in order to minimize confusion and fraud. Section IX, Exhibit A, Article D.5, please provide an example or use case description for the requirement in bullet 4 ("Provide a single payment for all fare media requested"). For multimodal or multiagency regional tickets, a single payment is required (but it can be split between different payment methods): the patron should not have to buy each segment of the trip in a different transaction, multiplying charges and fees, to pay each provider of a trip segment independently. What is the software and database technology used to build the current mobile ticketing app that is in place? Since user and account data are to be migrated out of this system into the new mobile ticketing system, some specifics on the technology used would be appreciated. Data extracts will be provided, if needed: the migration of existing patrons and tickets is just a proposed way of handling the transition between the current solution and the proposed solution. Creative solution will be considered. Page 40 Section XI.1.C.2.h. Please define the word issue. Metro acceptance of the system is defined that all requirements have been meet and demonstrate in the field. Issues are any problems encountered in the Live environment that affects the successful use of a functional requirement that was defined and agreed upon during design. 9

10 PROCUREMENT QUESTIONS Q84 A84 Q85 A85 Q86 A86 Q87 A87 Q88 A88 Q89 A89 Q90 A90 Q91 A91 Q92 A92 Q93 A93 Q94 A94 Page [vi] Section 2 I.1. Under Compliance with and Exceeding the Scope of Services, will a vendor be able to offer an alternative proposal? Yes, however all exceptions must be reviewed during the proposal evaluation process. If your alternative proposal is for a different product altogether, you may also submit an unsolicited proposal for us to evaluate. It is difficult to precisely answer this question without knowing what the alternative proposal is. Page 18 Section VIII.1. Please confirm that the contract can be delayed indefinitely each year until funds become available. For example, the life of the six year contract it can be put on indefinite hold five times? METRO budgets on an annual cycle. The AVAILABILITY OF FUNDS FOR THE NEXT FISCAL YEAR clause only notifies Proposers and Contractors of this fact, and that there is a remote possibility of termination of the Contract due to lack of funds. Page 21 Section XI.2.B. A change in price due to scope change should go through review with the contractor. Does METRO intend to negotiate with the vendor? Yes, see paragraph F of the same Article. Page 21 Section XI.2.C. We are requesting 45 days for larger scoped change orders. The 30-day deadline is only to provide a proposal for adjustment, not to negotiate and resolve the issue. We believe 30 days is sufficient to submit a proposal. Page 21 Section XI.2.E. We are requesting 30 days notification window and consideration for changes caused by Metro that are not exposed or realized until after the notification window has elapsed. We believe 15 days is sufficient time to notify METRO of a change. Page 25 Section XI.16.A This clause should be limited to the life of the contract or end warranty, whichever occurs last. You are asking if the RESPONSIBILITY OF THE CONTRACTOR Article survives the Contract. It does not. Page 26 Section XI.20.A. Please state the notice period of termination. There is no notice period in the TERMINATION FOR CONVENIENCE Article. Page 26 Section XI.21.D. Termination for events outside the control of the contractor is covered by section 11, the Force Majeure clause. Please confirm which clause supersedes. We do not believe these clauses conflict, therefore there is no order of precedence issue to resolve. Page 41 Section XI.1.C.5. Will the additional work be order as a change to this contract or a new contract will be generated. There should be no need for a Contract Modification or a new contract. We anticipate that these additional services will be billed under the existing Contract s line item 6.3. Section XI, 1 Exhibit A Scope of Services, Article C, Item 2. It appears the numbering is off for the tasks listed, Task 2.6 and Task 2.7 are both called f. Please confirm this is a typo and Task 2.6 is f and the rest of the tasks should be g, h, and i. Thank you, and you are correct. This is an error, please see the Amendment correcting this. Section II, 1 Offer/Acceptance/Award Signature page (p. 2) and Section I, 4 Summary of Proposal Forms to be Submitted. The Offer/Acceptance/Award Signature page is included in the list of forms to be included with the proposal. However, the form instructions on the form state it is To be completed and signed by proposer/contractor at the conclusion of negotiations of the contract. Please clarify if this form is to be submitted after negotiations or with the proposal. Please submit with your initial proposal. 10

11 Q95 A95 Q96 A96 Section I, 4 Summary of Proposal Forms to be Submitted. Please clarify which of the forms should be included in the Technical Proposal, and which should be included in the Pricing Proposal. We only require that you do not include pricing information in your technical proposal. If there is no pricing information on a form, it may go in either the technical or the price proposal. This comes up most often with our small business forms, but there is no subcontracting goal assigned to this procurement. Section I, 2 Instructions to Proposers, Article E Conflicts Disclosure. If this form is required to be included with the proposal, where should it be located within the proposal? The we link in that Article has more information, but this form should be sent directly to: Cydonii Fairfax Executive Vice President and General Counsel Metropolitan Transit Authority 1900 Main St. Houston, TX Note: Please register in our SAP system to ensure you receive notification of any changes throughout this procurement. Instructions are available here: 11