I.                 Scope Of Services                            4

II.             Proposal Submittal Requirements     11

III.             Evaluation Process and Criteria       15

IV.              Conflict of Interest                           16

V.                  Participation by Other Agencies       16

 

APPENDICES

Appendix A:      Cost Proposal

Appendix B:      Professional Service Agreement – MODEL CONTRACT NOT FOR EXECUTION Appendix C:                        Special Conditions Disadvantaged Business Enterprises (DBE) Commitment Appendix D:                        Bid Protest Procedures

Appendix E:      CERTIFICATION – Debarment - Primary Participant Appendix F:      CERTIFICATION – Debarment - Lower-Tier Participant Appendix G:      CERTIFICATION – Lobbying (Prime and Subcontractor) Appendix H:      CERTIFICATION – Drug-free Workplace (Prime) Appendix I:       Affidavit for Prompt Payment (Prime)

Appendix J:       Affidavit of Minimum Wage (Prime)

Appendix K:          Disclosure of Ownership (Prime Consultant & Subcontractor) Appendix L:                   Brief History of Your Company (Prime)

Appendix M:                      Non-Disclosure Statement (Prime Consultant & Subcontractor) Appendix N:                     FOIA Notice and Declaration Form (Prime)

Appendix O:      Vendor References Form (Submit with Technical Proposal) Appendix P:      Vendor Profile (Submit with Financial Background) Appendix Q:      Insurance Requirements

Appendix R:                     Table of Exceptions (Submit with Technical Proposal) Appendix S                      CTA’s COVID-19 Vaccination Policy For Vendors Appendix T:                     CTA IT Security Assessment Questionnaire Appendix U:                     CTA Data Security Rider


I.    Background Information

 

The Chicago Transit Authority (CTA) operates the nation’s second largest public transportation system. On an average weekday, 1.6 million rides are taken on CTA. The CTA is a regional transit system that serves 35 suburbs, in addition to the City of Chicago, and provides 81 percent of the public transit trips in the six-county Chicago metropolitan area either with direct service or connecting service to Metra and Pace.

 

CTA has 1,864 buses that operate 129 routes and 1,536 route miles. Buses make about 19,237 trips a day and serve 10,768 bus stops.

 

On the rapid transit system, CTA’s 1,492 rail cars operate eight routes and 224.1 miles of track. CTA trains make about 2,318 trips each day and serve 145 stations.

 

Chicago is one of the few cities in the world that has rail service to two major airports. CTA’s Blue Line ‘L’ can take customers to O’Hare International Airport. Orange Line trains, which operate clockwise on the Loop ‘L’ structure, travel to Midway Airport.

 

CTA also provides around-the-clock service on certain routes. During late night and early morning hours, major rail lines and some of CTA’s bus routes offer “Night Owl” service, much of it with connecting schedules and routing.

 

Additional information about the CTA and its services are available at www.transitchicago.com.

 

 

II.  Introduction

 

The CTA is soliciting proposals from qualified contractors to host and maintain a web-based, comprehensive hazard management software system (the “Application”). The solicitation includes assistance with the implementation of the Application, which in turn includes configuration, testing training, and documentation.

 

The CTA’s goal is to support its transition to and implementation of a transit-oriented Safety Management System (SMS). The SMS encompasses the overarching safety policy for the CTA, accounts for its safety risk management and assurance functions, and is the framework for safety promotion activities. Data pertaining to system hazards, the risk associated with those hazards, and efforts to mitigate or eliminate their consequences, lie at the heart of the SMS.

 

Qualified contractors (“Proposers”) are invited to submit a proposal (“Proposal”) to the CTA. A Proposer is expected to provide a detailed description of its recommended solution to the CTA’s needs, including software product, installation, implementation, integration options, hosting, training, maintenance, and resources to be provided by the Contractor, as well as responsibilities it proposes for the CTA throughout the project, such as training and testing.

 

 

III.  CTA’s Technology Environment

 

•      Client Server applications should use Server 2016/2019 or latest for the network operating system whenever possible.

•      Client computers should utilize Microsoft Windows 10 as client application architecture.

•      Microsoft Office 365 is the standard for common office applications.

•      Microsoft Edge is the standard CTA browser.


IV.  Scope of Services

 

 

A.    Overview

 

CTA requires a robust hazard collection, ranking, and tracking system for safety hazards identified agency wide. It must support the CTA’s Safety Management System for establishing and tracking corrective actions and mitigations for the potential consequences of those hazards.

 

Safety risks may be associated with physical conditions, behaviors or processes affecting CTA employees, customers, contractors, or the general public. Hazards may be found in any CTA work environment (vehicles, offices, shops, etc.), and may be identified by any of a wide variety of CTA personnel in the course of their duties, as well as reported to those personnel by other staff, customers, or the public. In order that the consequences of hazards be identified, rated, ranked, and addressed timely, the CTA requires a web-based solution that includes a practical and cost-effective approach to distributed data-entry by many users at many locations, including via mobile devices (the scope does not include the provision of mobile devices).

 

Safety department staff, and certain other personnel within the agency, perform specific additional safety duties—inspections, observations, job hazard analyses, and (in the case of the safety department) incident investigations and industrial hygiene activities. The CTA wants to track the volume and effectiveness of these safety duties—regardless of whether the activity results in a hazard being identified. The Application will be the repository of data from these activities.

 

In addition, Safety department staff and other qualified agency personnel are responsible for performing a risk assessment—rating any hazards that arise from their own safety duties, or that have been identified and entered into the Application by others. Likewise, Safety department staff and certain other CTA Departments, including Infrastructure, Rail Operations and Bus Operations, will be responsible for performing and recording the results of root cause analysis, and monitoring root cause trends. Therefore, the CTA wants its system to permit a workflow wherein hazards identified by users are then rated, ranked and tracked by fewer users with specific permissions.

 

Using the Application, the CTA wants to associate one or more corrective actions to any given hazard, and one or more hazards to any given corrective action. Where applicable, the CTA wants to be able to trace a hazard or corrective action to the inspection, observation, job hazard analysis, or investigation from which it arose. The CTA requires notifications within the software system to system users or email notifications to parties that are not users (such as to assign corrective action responsibilities).

 

In order to support the safety risk management, assurance, and promotion activities key to the CTA’s SMS, the Application must provide the CTA with dashboard views and reports, including the ability to save report preferences and distribute batch reports. Report elements must be able to be isolated, selected, and manipulated in the system, and users must be able to export data in a format useful for offline analysis.

 

Federal requirements governing transit safety management are ongoing and in a constant state of revision. The CTA therefore requires an Application that is highly configurable, meaning that front-end form field names, field choice lists and checklists can be changed by the CTA to reflect the logic and vernacular that will come with these industry-wide changes. For this reason, a Proposer’s experience implementing Application for transit clients in particular, and experience accurately estimating project costs for clients similar to CTA, is especially beneficial to CTA.

 

The CTA’s overall goal is to implement a robust Application, which will acknowledge and incorporate a variety of corporate business practices and existing sources of safety-related data. To this end, the CTA will want to share a self-assessment of these practices and data sources with the selected contractor, so


that the selected Contractor can knowledgably advise in the initial configuration of the system, including advice about user permissions and workflows.

 

The CTA requests a document repository and cataloging of SDS (Safety Data Sheets). The application should accept the current SDS information in a data dump from the SharePoint site. The document repository for SDS will be able to search by name or item number and be able to print requested printed reports.

 

Note: The Scope of Services does not contemplate software system integration; this statement refers to the CTA’s desire for the software to reflect and support business process and management integration. CTA does anticipate wanting to import certain information periodically, such as updated files containing the organizational hierarchy, or contact information for users that would receive notifications from the system.

 

B.     System Features

 

1.       Hazard identification, rating, and tracking. The system must:

a.       Provide a cost-effective means of collecting hazards from several thousand personnel entering data at more than 30 discrete physical locations.

b.       Account for hazards and deficiencies that are physical, behavioral, or process/management in nature.

c.       Account for a hierarchy of ‘locations’ and allow configuration of those locations, e.g.,

i.      cost center and ‘roll-up’ organization (e.g., rail maintenance), as well as

ii.      property address and physical location within an address (e.g., battery storage room).

d.       Collect standard information about hazards and allow configuration of details (e.g., terminology for type of hazard).

e.       Allow users to upload photos or other files and associate them to a hazard. Users must be able to perform this function from a mobile device.

f.         Allow user permissions and workflow to be set so that most users can register the presence of a hazard, and a subset of users, identified by type or by user, are permitted to rate and rank hazards, associate them with corrective actions, notify others in the workflow, analyze, and/or report.

g.       Provide dashboard views and standard reports that can be set or configured by individual users and for certain user types. Allow users to create and run reports at will and allow for distribution of automatically run batch reports.

 

2.       Corrective action identification and tracking. The Application must:

a.       Provide a means to establish corrective actions and link any given corrective action to one or more hazards.

b.       Track the status of corrective actions and share progress in the form of reports and notifications to specific staff, regardless of whether the individual is a named user of the application.

 

3.       Safety activities from which hazards and corrective actions flow.

a.       Inspections. The system must:

i.      Contain inspection checklists, with configurable field names and field choices that allow the CTA to collect data from safety inspections. As with corrective actions, this should include the ability to assign responsibilities and make notifications to system users or certain other CTA Departments, including Infrastructure, Rail Operations and Bus Operations, via email.

ii.      Allow users to create reports and dashboard views to analyze inspection findings (for instance by type, by location, by inspector, etc.).

iii.       Allow CTA to associate hazards identified during an inspection with that inspection. The associated hazard must be available to be reported on or


tracked independent of the investigation as part of the hazard identification, ranking, and tracking functionality.

 

b.       Observations. The system must:

i.      Contain observation checklists, with configurable field names and field choices, that allow the CTA to collect data from safety observations and create reports and dashboard views to analyze findings (for instance by observation type, finding type, organization of person observed or by observer).

ii.      Allow certain users to assign responsibilities, review periods, and notifications to system users or others via email.

iii.       Allow CTA to associate hazards identified in the course of an observation with that observation. The associated hazard must be available to be reported on or tracked independent of the observation, as part of the hazard identification, ranking, and tracking functionality.

 

c.       Job Hazard Analyses. The system must:

i.      Contain checklists, with configurable field names and field choices, for conducting and logging job hazard analyses. This should include the ability to assign responsibilities, review periods, and notifications to system users or others via email.

ii.      Allow CTA to associate hazards identified in the course of job hazard analysis with that analysis. The associated hazard must be available to be reported on or tracked independent of the analysis as part of the hazard identification, ranking, and tracking functionality.

 

d.       Investigations. The system must:

i.      Contain configurable field names and field choices for safety department investigators to collect data about incident investigations. In addition to employee injuries and bus vehicle accidents, these include incidents on the rail system that would require specific technical field names and values (such as the type of track or identifier for a switch.

ii.      Allow CTA to configure fields to store information about notifications made to external agencies.

iii.       Allow the CTA to perform and record the results of root cause analysis, and to conduct trend analysis related to root cause.

iv.      Allow the CTA to associate corrective actions to investigation findings.

v.      Allow the safety department to track the status of an investigation itself, as well as the status of corrective actions associated with investigations findings.

vi.      Allow CTA to associate hazards identified in the course of an investigation with that investigation. The associated hazard must be available to be reported on or tracked independent of the investigation, as part of the hazard identification, ranking, and tracking functionality.

 

e.       Industrial Hygiene Activities. The system must:

i.      Allow the industrial hygienist to configure field names and field choices to collect data related to sampling regimes and results.

ii.      Provide reports and dashboard views that allow the CTA to analyze industrial hygiene activities, such as by subject location, type of sampling, or test result values.

iii.       Allow the industrial hygienist to schedule activities and provide notifications to system users or to others via email.


4.       User Description:

 

User Type

Count

Safety Department – data entry and manipulation

40

Safety Department – view; report running

40 above + 20

Safety Department – project manager/admin level

2

Technology – project manager; admin/DBA level

1

Distributed data entry – basic hazard reporting; non-

named users

10,000+

Other Departments – data entry; view; report running

30-50

 

 

C.     Customer Service and Implementation

 

The Contractor must assist the CTA with the implementation of the chosen Application, so that the product is configured and integrated to reflect CTA’s business processes, the emerging structure and terminology of transit-oriented SMS approaches, and federal regulation of transit safety. The project plan submitted in response to this RFP must thoroughly describe an implementation plan that includes recommended hours, steps, and milestones involved in working with project managers from the CTA’s Safety and Technology departments and a small CTA implementation team.

 

While the CTA specifies a configurable and flexible software solution, it also recognizes the possibility of learning from the product and services offered by the Proposer, and the potential opportunity to optimize its hazard management regime by revising certain business processes. Proposers are invited to explain how their product, services, or client experiences prepare them to provide superior customer service relative to integrating the software into CTA’s business.

 

D.     Hardware

 

The Proposer must define any hardware required to properly run the Application and to meet the CTA’s performance criteria. The Contractor shall provide all required system hardware and infrastructure. The environment must consist of two separate hardware suites for test environment and production environment. The Contractor will work with designated CTA staff to ensure the hardware for each environment is set up and configured. The vendor will provide their system specification and required supporting environment including hardware and software from CTA.

 

E.     System Performance

 

The Application must meet the minimum required performance as listed below:

 

•      The application must handle large volumes of data and interface with other systems utilizing the CTA network without degrading the system response or performance. The proposed application will be used 24 hours, 7 days a week, and 365 days a year.

•      The application must acknowledge all user requests within one second and provide results within 5 seconds. A longer response time should be indicated via a percentage status bar or change in UI appearance.

•      The application must support and provide dynamic failover capabilities of application data and functionality. The Contractor is expected to assist CTA in defining, configuring, and establishing the infrastructure and failover mechanism for the system.


F.     System Architecture

1)       Data Security:

The Application is required to secure information and systems against the full spectrum of threats, use multiple, overlapping protection approaches, and address the people, technology, and operational aspects of information systems. The vendor will provide the answers to CTA cyber security questionnaire. Attributes to secure system data should include:

a.       Application level security to integrate, interface, and co-exist with the OS level security, database level security, and network security that is in use at CTA.

b.       Comprehensive security mechanisms to safeguard access to the applications and integrated database.

c.       Comprehensive auditing capability to trace activity to an individual user level – record updates, deletion, creation, and edits.

d.       Control access privileges to software functionality, data attributes, and software screens and prevent unauthorized use of data.

 

2)       Reporting Services:

The system must have standard reporting capabilities with the option for customization. The Application is required to generate and export pre-determined reports in a variety of formats, run queries on demand, export query results as .xml or .xls Excel files or other common industry formats, and save queries for future use. The software must have the ability to interface data with various systems and services within the CTA such as TOPS, MIMS, Infor, Clever Cad, SCADA and work with Performance Management, AWS and RedShift platforms. The reporting tool must have the ability to select and/or configure output columns, filter, group, graph, and/or sort the results, or drill down to required granularity by input parameters.

 

3)       Terminology:

The User Interface screens, controls, and reports must use language and terminology acceptable to CTA, and have the ability to customize the software screen, all captions, messages, and reports to meet CTA industry and business specific terminology wherever requested.

 

G.     Ownership

 

The database and the data contained in the Application are owned by the CTA. Any access to the actual data for updates will be provided on authorization from the CTA. [DF1] The Contractor shall not reveal any confidential or non-confidential information without prior authorization from CTA.

 

H.       Project Management

 

1)       General Requirements

The Proposer must demonstrate the planned project management processes including, but not limited to, project requirements, schedule, cost, resources, issue management, testing plans, training plans, risk management, communication management, quality management, contract management, and administration.

 

2)       Communications

The Contractor shall be responsible for ensuring all project milestones and dates are met. The Contractor must develop a realistic schedule, a comprehensive work plan, and a project management and communications approach.

 

The Contractor must work with the CTA’s project manager at regular project meetings and must document project status reports, risk mitigation plans, open and closed issues, accomplishments, milestones, quality control, and meeting notes. The Contractor shall also coordinate and work with a change management team for approvals in baseline changes of scope, cost, schedule, and quality.


3)       Project Management Tools

The Contractor is required to use project management tools and technology aligned or compatible with those used by the CTA (Microsoft Office, Project Management, Visio and SharePoint). The tools used must be licensed, compatible, and versioned similar to the ones used by the CTA. Ideally, the Contractor should provide an online management tool to record project findings – risks, issues, concerns, change management, and bugs - and generate extensive reports. Both parties should use the same tool to record and monitor project progress. The Contractor will be responsible for maintaining the system throughout the project cycle. Post project implementation of data will be owned by the CTA.

 

4)       Testing

The Contractor must create and execute a test plan including end to end processes testing scenario that verifies all the requirements of the RFP. Success and failure criteria are to be established before the testing occurs. Both the test plan and the success criteria will be subject to CTA approval. Upon test completion, the Contractor shall provide the CTA with a report of all results. Final decision on test pass/fail rests with the CTA project manager.

 

Testing should cover:

a.       System Testing: The Contractor must ensure all the components of the systems are working properly and meet business and technical requirements. System testing must also include interfaces, performance, all reports, notifications, and imports/exports with other systems.

System testing shall be conducted on production systems with artificial data; and

b.       User Acceptance Test (UAT): CTA users test CTA business processes with the usability of the application and its reports.

 

5)       End User Training

The Contractor is required to provide a training plan executed at CTA’s location [DF2] or at a location approved by the CTA. The Contractor is required to train the CTA staff in groups, using the “Train the Trainer” format. The training shall be provided in phases to the project staff and testing staff at the start of user acceptance testing and provided again to the trainers identified by the CTA post system acceptance. The Contractor will be required to develop all training materials and coordinate with the CTA (Training and Workforce Development) to finalize the training materials.

 

6)       Deployment

The Contractor is responsible for the final implementation and installation of the system and must ensure that it contains all necessary data inputs, ancillary data, configuration settings, and required initial data transfers, cutover activities and post Go-Live support plans. The Contractor is responsible for deployment of the final system, following approval testing and acceptance by CTA. The Contractor should recommend a deployment schedule[DF3] .

 

I.    Project Schedule

 

The Application solution should be tested, fully functional, and in operation within six months after the contract Notice-to-Proceed. Opportunities to condense the timeframe further should be outlined in the Proposal. Proposers should also list specific risks (and mitigation tactics) that arise from the schedule constraints. Final approval of the project schedule will be at the sole discretion of the CTA. Proposers must provide a milestone deliverables schedule for the system implementation, including proposed earned value of professional services at each milestone. The CTA will review and approve the requirements modifications and implementation plan. Upon acceptance of each milestone, the Contractor will be authorized to submit invoices for payment.


J.       Warranty

 

A one-year warranty is required for each component of the system including any hardware, software, firmware, services, or other services provided after the go-live launch date. Should the manufacturer’s standard warranty coverage exceed this minimum requirement, said manufacturer’s standard warranty shall apply. The “Go-Live” launch date is defined as the date the system is in deployment after acceptance of the last department implemented and integrated into the system.

 

 

K.     Maintenance and Technical Support

 

The Contractor is required to provide ongoing maintenance and technical support to CTA throughout the term of the contract. The Contractor’s support shall consist of a variety of technical and administrative areas including, but not limited to, installing and configuring the product, installing and configuring product updates, providing corrections to identified defects, troubleshooting the system, reviewing the generated log, tracing files, and providing solutions for continuous improvements.

 

The Service Level Requirements are as follows:

 

1)       Support Mode

Support staff must be available to CTA in a timely fashion via email, phone, or online to provide technical support and assistance to user concerns. The availability of support staff and technical support staff shall be 24 hours a day, 7 days a week, 365 days a year.

 

2)       Issue Response Time

a.       Response time in case of system downtime should be no longer than 2 hours.

b.       A high priority issue should be assigned to technical staff within 2 hours with a turnaround time of 24 hours to identify a solution.

c.       A medium priority issue should be assigned to technical staff within 24 hours with a turnaround time of 72 hours to identify a solution.

d.       A low priority issue must have a turnaround time of 5 days to identify a solution.

e.       CTA will determine the level of priority for each issue and may consider the advice of the Contractor in making this determination.

 

3)       Software Management

Any corrections, fixes, upgrades, or enhancement to the software should include, at a minimum, user training when applicable and release documentation which must cover what was changed, what was fixed, scheduled time, test cases, and configuration changes.

 

4)       Service Management

The CTA shall receive monthly reports on the number of support calls taken, categorized by issue priority and the turnaround time taken for identification and closure of the issue. In addition, a dedicated Service Manager should be identified as a single point of contact to deliver monthly service reports, review service improvement actions, review service progress, and address any issues or requests for service changes.

 

5)       Continuous Improvement

After Go-Live, the Contractor must provide 60 days on an annual basis for the continuous improvement of services for the remainder of the term of the contract, including any option years. The time will be used for software customization[DF4] , user training on CTA premises, custom reports, or other needs authorized by the CTA. Any days not utilized in any year will be rolled forward into subsequent year(s) for the term of the contract, including any option years. Improvements made to the software for other clients should be provided to the CTA for consideration and approval before such improvements are included in the CTA software package. All such additions included into CTA’s software package shall be at no additional cost to CTA.


6)       Business Continuity and Disaster Recovery Plans:

The vendor will provide business continuity plans in case of system failure during operation time. The vendor will provide disaster recovery plans in case of system collapse and/or system hacking.[DF5] 

 

7)       Data Governance and Management:

Data will be managed on application platform by vendor. All data will be available to CTA upon request. Vendor will keep the data for 3 years in their database. The vendor will archive the data every year and provide the stored data to CTA.[DF6] [DF7] 

 

L.     Service Level Agreement

 

The Proposer must include within its Proposal the service levels to which it will perform, the methodology used to measure and report against service levels, and the remedy the Proposer will provide the CTA should such service levels not be satisfied.[DF8] 

 

Suggested SLAs for uptime of application/software are as follows:

•      99.99% uptime over 24x7x365 basis

•      No individual unscheduled downtime shall exceed 10 minutes

•      Monthly unscheduled downtime shall not exceed 15 minutes

 

M.         Transition Management

 

Transition management is defined as all activities that facilitate the transition to the Application from CTA’s existing formats for identifying, ranking, and tracking hazards, corrective actions, and associated safety activities. The transition management activities must enable CTA users to accept the new system, processes, system definitions, and hardware through training and roadshows. A plan for the Proposer’s transition management activities, including CTA responsibilities, must be included in the Proposal. Proposers should further provide recommendations of best practices to the CTA on solutions to effectively manage the transition.

 

 

V.          Proposal Submittal Requirements - A complete proposal must, at a minimum, consist of the following:

 

A.                  Format

 

Proposal packages are to be delivered through Electronic Submission to the Bid Office’s E- Procurement Platform https://transitchicago.bonfirehub.com/portal/?tab=openOpportunities

 

Submittals shall be prepared on standard size paper (8 ½'' x 11''). The proposal will contain sufficient detail to enable the CTA to evaluate it according to the criteria outlined in Section VI, Evaluation Process and Criteria. The CTA may request additional written information and/or oral presentations.

 

Each proposal is to consist of five parts, each to be submitted separately, as follows:

 

Part 1 - Technical Proposal (1 – electronic copy)

Include Table of Exception and Vendor Reference Form (Appendices O & R)

 

Part 2 - Cost Proposal (1 – electronic copy)

 

Part 3 – DBE Proposal (1 – electronic copy)

 

Part 4 - Financial Background (1- electronic copy) Include Vendor Profile Forms (Appendix P)


Part 5 – CTA Certifications, Forms and Disclosures

Include completed Certification Regarding Debarment (Prime and Lower Tier), Lobbying Certifications, Drug Free Workplace Certification, Affidavit for Prompt Payment, Affidavit of Minimum Wage Payment, Disclosure of Ownership, History of Firms, Non-Disclosure Statements, and FOIA Notice and Declaration Form (Appendices E - N).

 

The cover letter must contain a commitment to provide the services described in this RFP. Each cover letter must include the name and address of your company, the requisition number, the project name (A web based hazard management software system, including hosting, maintenance and services for a period of three years two one-year options) with and the name, title, address and telephone number, e-mail address, and signature of a representative of the vendor who is authorized to negotiate a contract with the Authority and/or whom we may contact with questions regarding your response.

 

All Submittals become the property of the CTA and will not be returned. All costs incurred in the preparation and presentations of the proposal are the responsibility of the proposer. Issuance of this RFP does not commit CTA to pay any cost incurred in the preparation of this proposal. Proposers are advised to adhere to the submittal requirements. Failure to comply may be cause for rejection of the submission. CTA reserves the right to accept or reject any or all submittals or parts thereof, to extend the time for submission of proposals, to negotiate with any or all proposers, and to award a contract to the proposer whose initial proposal is most advantageous to CTA, without further discussion or negotiation.

 

Additional documents describing the firm should be submitted as separate items. The cover letter lists the due date and time when proposals must be returned.

 

B.                  Content

 

Part 1. TECHNICAL PROPOSAL - 1 Electronic Copy

 

The Technical Proposal is a technical document which details the firm’s understanding of the project purpose, the scope of work, technical work required, and necessary deliverables that must be submitted. The document should include, but is not limited to, the following:

 

1)       Cover Letter

A cover letter should be signed by an official of the firm who is authorized to bind the respondent contractually to the extent of the commitment sought by this RFP. The cover letter must contain a commitment to provide the services described with the personnel specified in the Proposal and DBE commitment.

 

2)       Executive Summary

The Executive Summary shall be limited to a brief narrative highlighting the firm’s Proposal. Please note that the executive summary must identify the primary Proposer including contact name, address, phone number and a valid email address. All subcontractors or partners must also be identified.

 

3)       Response to the Implementation Plan

Proposers shall submit a comprehensive implementation plan that details the Proposer’s implementation methodology and approach to meeting all items listed in Section III, Scope of Services described in this RFP.

 

4)       Response to Technical Requirements

The Proposer must include the proposed application architecture for a hosted solution. This section should be in narrative form using diagrams and schematics as appropriate. All


hardware and software used for the solution should be listed in the appropriate table in

Appendix A (Cost Proposal).

 

5)       Project Management

The Proposer must outline how it intends to manage the implementation. The following components should be addressed:

a.       General Requirements

The Proposer is required to demonstrate the project management processes planned.

b.       Communications

This section must include a communication approach for how the Proposer proposes to work with and update the CTA project manager. Please describe what information will be communicated, how often, and in what format.

c.       Project Management Tools

This section must include the tools the Proposer plans to use throughout the project.

d.       Testing

In order for this project to be successfully transitioned to the CTA, the program must be thoroughly tested, and end users trained. The Proposer should describe its testing plan, demonstrating how it meets the requirements laid out in the RFP. The test plan will be subject to the review and approval of the CTA.

e.       End User Training

The Proposer should describe its training plan, demonstrating how it meets the requirements laid out in the RFP. Cost for the training shall be included in Appendix A, Cost Proposal.

f.         Deployment

The Proposer should submit its recommended deployment plan.

 

6)       Project Plan

Proposals should include a detailed project plan including all tasks with start and end dates, dependencies, and resources (including CTA resources as applicable) necessary to meet CTA schedule constraints. Provide an illustration of the project in chart form, such as a Gantt chart. The Proposer must provide a milestone deliverables schedule. Opportunities to condense the time frame further should be outlined. Proposers should also list specific risks (and mitigation tactics) that arise from the schedule constraints.

 

7)       Qualifications and Experience

a.       Firm

Applicable firm qualifications must be presented in this section covering the Proposer’s experience on similar or related engagements including experience, if any, with transit or municipal accounts. Proposers must have at least five years’ experience providing similar hazard management software solutions. Proposers must provide three client references for similar projects completed within the last three years, using the attached Vendor References Form provided in Appendix O. Proposers must be licensed to do business in the State of Illinois, and show proof of license.

 

Describe the types of business, enterprise, and hazard management software systems available through your organization. Indicate whether services are provided locally/nationally or by a subsidiary organization.

 

Provide a summary of new and creative products which your firm has recently brought to your clients to improve their hazard management software system. Advise how the expandability of software and products may be positively adapted to CTA’s operations.

 

b.       Staffing

This section must contain the resumes for all personnel who will be involved in the engagement.  Proposers  must  identify  their  representatives,  including  the


representatives’ specialized with five years of experience and professional qualifications as they relate to this contract as described in Section IV. Scope of Services.

 

8)       Table of Exceptions (Appendix R)

The summary must state whether the Proposal does or does not fully comply with the requirements as defined in this RFP and shall provide a detailed list of any exceptions, whether to the RFP, the Model Contract, or other RFP requirements, including all exhibits and appendices. This list must be in table form and must identify the page, section number, provision, and the specific exception, non-conformance and/or substitute language proposed. Failure to identify any specific items of non-compliance will result in CTA assuming compliance. The CTA, at its sole discretion, may reject any exception.

 

Part 2 - COST PROPOSAL (Appendix A)

 

The Cost Proposal should contain complete details on pricing structure. The firm must recommend a milestone payment plan. Payment structure may consist of bundled and unbundled services throughout the configuration, implementation, roll out, and training aspects of the contract. A Cost Proposal form is included in Appendix A, which addresses costs associated with the work described herein. This form must be completed. In addition, proposers may propose an alternative pricing model for consideration.

 

A fully completed Cost Proposal must include the following items:

 

1.       Specify payment terms and describe exactly how the fee is determined. Indicate whether you provide your clients with a breakdown of the components of your service including a breakout of maintenance and user fees for each of the base three years and the two one- year contract options.

 

2.       The Cost Proposal must be valid for five (5) months from submission date.

 

3.       Competitiveness of Cost Proposal and price will be evaluated separately for overall reasonableness.

 

 

PART 3. DISADVANTAGED BUSINESS ENTERPRISE (DBE) INVOLVEMENT

 

This section shall contain the Proposer’s policy and approach to utilization of disadvantaged firms and the Proposer should complete Schedules B, C, and D as appropriate (Appendix C). The CTA encourages any team arrangements that will work to benefit this project. If such arrangements are made, the contractor must assume full responsibility for the work performed by all sub-contractors. All proposed DBE firms must be certified by the Illinois Unified Certification Program (IL UCP). This section is to be separately sealed from Technical and Price Proposals.

 

 

PART 4. FINANCIAL BACKGROUND

 

Documents supporting a firm’s financial stability and ability to perform the contract must be included as well. Proposers must provide audited financial statements for the past year and information pertaining to any past bankruptcy, contract defaults and violations of any regulatory acts. CTA will accept unaudited financial statements which must be accompanied by the most recent two years tax returns. This information will be used to determine vendor responsibility.

 

PART 5. CTA CERTIFICATIONS, FORMS AND DISCLOSURES

 

This section should contain firm’s completed disclosures, certifications, and forms, included in Appendices E – N.

 [DF1]@Fred Higgins DB and Schema we own, they license in perpetuity.  They own the data, we have free access until license expires.  They can export to XLSX or CSV anytime they like.

 [DF2]Need to include travel etc.

 [DF3]Phase module implementation and payment milestones.  Licensing due at start.  Implementation fees milestone based.

 [DF4]This is not a bespoke deployment

 [DF5]@Fred Higgins Finalize Relationship with Cloud IQ, have them provide language on these types of sections for RFP.

 [DF6]@Dick Federle @Steve Severson Think about this...

 [DF7]@Dick Federle look at PowerShell for export and or/snapshot of site collection backup

 [DF8]@Fred Higgins get Prem to chime in on this.