8-RFP 546288.docx
DOCX document 123 KB Posted
- Attached to
- Community Engagement Platform
- Solicitation number
- 546288
- Issued by
- Wayne County, Detroit City, Michigan
About this file
This is a Request for Proposals (RFP) issued by the City of Detroit Office of Contracting and Procurement on behalf of the Department of Innovation and Technology for a Community Engagement Platform, which is a cloud-based mass communications system. The City seeks a qualified contractor to provide a public-facing online portal enabling citizens and city employees to manage mass communications via email and text message, with capabilities including user subscription management, scheduled and ad-hoc message sending, branded and custom templates, unlimited email sends with bounce management, and a minimum of 5,000,000 SMS/text messages per year. The system must include 24/7 monitoring and support, data migration services, delivery and engagement reporting, web-hosted training sessions, and comprehensive documentation. The pre-proposal conference is scheduled for June 5, 2026, at 1:00 p.m. EST via Microsoft Teams, with questions due by June 12, 2026, at noon EST and proposals due June 22, 2026, at 4:00 p.m. EST through the EUNA Bonfire Supplier Portal. The contract term is five years with two optional one-year renewals, contingent on Detroit City Council approval.
The evaluation will occur in one phase with technical proposals reviewed before cost proposals, using criteria including product quality and ability to meet functional and security requirements (40 points), project approach and work plan (30 points), vendor experience and staff capabilities (15 points), and pricing (15 points). Respondents must demonstrate a minimum of three years of experience providing similar services for comparable projects. Detroit Equalization Credits will be applied post-evaluation for qualifying businesses. The City anticipates one award and reserves the right to request oral presentations or demonstrations, negotiate with top-ranked respondents, reject any proposals, or cancel the RFP. All proposals must be submitted through the EUNA Bonfire portal; faxed or mailed proposals will not be accepted. Pricing terms are based on a firm cost proposal with payment under the City of Detroit Prompt Payment Ordinance, and no work may commence until the contractor receives both a City Council-approved Contract Purchase Agreement (CPA) and a Standard Purchase Order (SPO).
View the file
Other files
| File | Type | Posted |
|---|---|---|
| 1-Attachment D-1 Required Forms Affidavits (1).pdf | ||
| 5-Attachment A - Respondent Questionnaire.docx | DOCX document | |
| 6-Attachment B - EUNA Respondent Proposal Introduction and Solution Approach.docx | DOCX document | |
| 2-Attachment D-2 Conditions of Award (1).pdf | ||
| 7-Cloud Service Provider Security Checklist 2025.xlsx | XLSX spreadsheet | |
| 3-Attachment E- City of Detroit Technology Contract.docx | DOCX document | |
| 4-Attachment F - IT Project Requirement Matrix.xlsx | XLSX spreadsheet | |
| 9-EUNA Equalization Credit Statement.pdf |
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
CITY OF DETROIT
OFFICE OF CONTRACTING AND PROCUREMENT
REQUEST FOR PROPOSALS
RFP NO. 546288
Community Engagement Platform
Buyer: Latrece Yelder
| EVENT / ACTIVITY |
| DUE DATE / TIME |
| ADVERTISEMENT DATE |
| (Date) |
05/22/2026
PRE-PROPOSAL
CONFERENCE
(Date) 6/5/2026 @ 1:00 pm EST Location: Microsoft Teams
Bid 546288 Pre-Bid Conference | Meeting-Join | Microsoft Teams
| QUESTIONS DUE |
| (Date) 6/12/2026 @ noon |
All questions must be submitted online in the Supplier Portal as indicated in Section 3.3 of this RFP.
| ANSWERS DISTRIBUTED |
| 48-72 hours |
| PROPOSAL DUE DATE * |
| (Date) 6/22/2026 @ (Time) 4:00 pm EST |
In the Supplier Portal as specified in Section 4.5 of this RFP.
* Respondents must register in EUNA Bonfire to download bid documents and submit bids. The City cannot guarantee the accuracy of any bid documents obtained from outside of EUNA, and bids submitted outside of EUNA Bonfire will not be accepted. Detailed resources about registering and bidding, including video tutorials and live, virtual office hours, are available at www.detroitmi.gov/suppliersupport.
Questions about the specifics of this RFP must be asked within the EUNA Bonfire Messages interface for the bid on or before the date and time indicated above. Questions asked via phone, email, and/or other means will not be answered.
Proposals must be uploaded in EUNA Bonfire on or prior to the date and time indicated above. Late and/or emailed proposals will not be accepted.
TABLE OF CONTENTS
| Section 1. Project Summary and Background | 3 | |
| 1.1. | PROJECT REQUEST | 3 |
| 1.2. | BACKGROUND/DESCRIPTION OF ENVIRONMENT | 3 |
| 1.3. | AWARD CLAUSE INCLUDING RENEWAL OPTIONS | 3 |
| Section 2. Statement of Work | 4 | |
| 2.1. | SERVICES TO BE PERFORMED | 4 |
| 2.2. | OPERATIONAL INFORMATION | 4 |
| 2.3. | TECHNICAL INFORMATION | 4 |
| 2.4. | PAYMENT & PERFORMANCE BOND (Construction) | 5 |
| Section 3. Proposal Evaluation and Selection Process | 6 | |
| 3.1. | MINIMUM QUALIFICATIONS | 6 |
| 3.2. | ADHERENCE TO TERMS OF PROPOSALS | 6 |
| 3.3. | QUESTION DEADLINE | 6 |
| 3.4. | EVALUATION CRITERIA | 6 |
| 3.5. | EVALUATION PROCEDURE | 7 |
| 3.6. | ORAL PRESENTATION/DEMONSTRATION | 7 |
| 3.7. | REJECTIONS, MODIFICATIONS, CANCELLATIONS | 7 |
| 3.8. | PROTESTS | 7 |
| Section 4. Required Proposal Content and Submission Process | 9 | |
| 4.1. | ACCURACY AND COMPLETENESS OF INFORMATION | 9 |
| 4.2. | REQUIRED PROPOSAL CONTENT AND FORMAT | 9 |
| 4.3. | REQUIRED COST PROPOSAL | 9 |
| 4.4. | ECONOMY OF PREPARATION | 10 |
| 4.5. | SUBMITTAL INSTRUCTIONS | 10 |
| Section 5. General Conditions and Requirements for RFP | 11 | |
| 5.1. | CONTRACT APPROVAL | 11 |
| 5.2. | PAYMENT | 11 |
| 5.3. | INVOICES | 11 |
| 5.4. | ASSIGNMENT | 12 |
| 5.5. | MODIFICATION OF SERVICES AFTER CONTRACT APPROVAL | 12 |
| 5.6. | NEWS RELEASE | 12 |
| 5.7. | MISCELLANEOUS | 12 |
| 5.8. | OFFICE OF INSPECTOR GENERAL | 13 |
| RFP Attachments List | 14 |
Section 1. Project Summary and Background
PROJECT REQUEST
The City of Detroit Office of Contracting and Procurement (OCP) on behalf of Department of Innovation and Technology requests proposals from qualified Respondents to render certain technical or professional services ("Services") as set forth in this RFP to provide a Mass Communication Platform.
BACKGROUND/DESCRIPTION OF ENVIRONMENT
The City of Detroit Department of Innovation and Technology is seeking a Contractor to provide a public facing on-line portal for citizens and city employees that includes a cloud-based Mass Communications Platform. The System will provide the ability for staff to manage users and reporting tools. Provide customer and technical support (24 hours and emergency), bug fixes, software updates and a robust API for data migration and connectivity. The platform must allow the public to sign up to receive mass communications from the City of Detroit via email and/or text message. The platform will allow email and/or text message subscribers to subscribe to multiple mailing lists via an online portal. The platform will allow the scheduling of communications as well as the ability to send email and/or text message communications to citizens on an ad-hoc basis. The platform will allow Administrators to use branded templates as well as create custom templates for sending communications through the system. The platform will provide unlimited email sends with delivery and management of all bounces. The platform must be accessible from any secure location via the Internet. Provide a subscription network for citizens to subscribe to public mailing lists through the network. Allow users to subscribe and unsubscribe to mailing lists via an online portal. Provide text messages from a shared short code within the United States.
AWARD CLAUSE INCLUDING RENEWAL OPTIONS
If a contract is awarded as a result of this RFP, it will be a City of Detroit IT Contract (Attachment E). The term of the contract will be for Five (5) years with the option for two (2) one-year renewals. Any renewal option exercised under this contract is effective only after the approval of the Detroit City Council and signed by the Chief Procurement Officer. The City anticipates one award as a result of the RFP.
Section 2. Statement of Work
1.
2.
1.
2.1. SCOPE OF WORK- TECHNICAL INFORMATION, DATA SECURITY AND
COMPLIANCE
REQUIRED
· Cloud-based platform mass communications platform with subscribe and unsubscribe capabilities.
· User interfaces for Subscribers and Administrators
· Provide unlimited email sends with delivery and management of all bounces.
· Support to upload and migrate existing email lists.
· Provide delivery and engagement reports on communications sent through the system.
· Access to participate in the mass communication network.
· Ability to send mass notifications to multiple devices.
· 24/7 system monitoring, email and phone support during business hours, auto response to inbound messages from end users, and emergency support
· Text-to-subscribe functionality.
· Provide up to 4 web-hosted training sessions annually.
· Access to a complete archive of all data created by the client.
· Message template and integration development
· Minimum of 5,000,000 SMS/text messages per year
· New version release schedule, to include how the release would be accomplished at the user level and into a cloud-based data center.
· Backup and recovery procedures
· Documentation to include operations, technical manuals, online help, and training materials.
OPTIONAL
· Dynamic targeting for campaign sends by zip code
· Link conversion tracking for event and form submissions
· AI writing tools to improve open/click rates
· Accessibility checking tools to ensure compliance with ADA guidelines
· Creative control over subscription network pages
Proposers must describe their proposed solution and related functionality to capture and track all steps of the described processes including but not limited to data migration, data validation, data storage, data security, auditing capabilities, reporting, interfaces, and system requirements at the desktop and network level. Every proposal shall include the following sub-sections:
The substance of this Section of the Proposer’s response will be incorporated into the final contract, as part of Exhibit A “Scope of Services”.
A. Software Requirements
Proposer shall provide a detailed description of the product(s) and product versions being proposed. The response to this section shall detail the system features and capabilities and indicate if these are native to the software or if integration with a 3rd party software is required or recommended.
Include the following:
1. Cloud-based mass communications platform with subscribe and unsubscribe capabilities.
2. User interfaces for Subscribers and Administrators
3. Provide unlimited email sends with delivery and management of all bounces.
4. Support to upload and migrate existing email lists.
5. Provide delivery and engagement reports on communications sent through the system.
6. Access to participate in the mass communication network.
7. Ability to send mass notifications to multiple devices.
8. 24/7 system monitoring, email and phone support during business hours, auto response to inbound messages from end users, and emergency support
9. Text-to-subscribe functionality.
10. Provide up to 4 web-hosted training sessions annually.
11. Access to a complete archive of all data created by the client.
12. Message template and integration development
13. Minimum of 5,000,000 SMS/text messages per year
14. New version release schedule, to include how the release would be accomplished at the user level and into a cloud-based data center.
15. Backup and recovery procedures
16. Documentation to include operations, technical manuals, online help, and training materials.
All proposals must include the following information:
Proposed Solution
Cloud-based Mass Communications Platform with subscribe and unsubscribe capabilities
User interfaces for Subscribers and Administrators
Provide unlimited email sends with delivery and management of all bounces
Support to upload and migrate existing email lists
Provide delivery and engagement reports on communications sent through the system.
Access to participate in the mass communication network
Ability to send mass notifications to multiple devices
24/7 system monitoring, email and phone support during business hours, auto response to inbound messages from end users, and emergency support
Text-to-subscribe functionality
Provide up to 2 web-hosted training sessions annually
Access to a complete archive of all data created by the client
Message template and integration development
Up to 5,000,000 SMS/text messages per year
New version release schedule, to include how the release would be accomplished at the user level and into a cloud-based data center.
Backup and recovery procedures
Documentation to include operations, technical manuals, online help, and training materials.
B. Hosting and Platform Requirements
The Proposer must give an overview of all platform requirements associated with the proposal. If Proposer determines any of the following requirements to be inapplicable, Proposer shall state so and shall also state the basis for determining each such requirement to be inapplicable. Proposer must describe the following:
i. System Environments – The Proposer shall state all environments (e.g., production, development, and test) included in the proposal. If such environments are limited in functionality, scope or otherwise, the proposal shall describe such limits.
ii. Shared Components of the System - The Proposer shall clearly state and describe all shared components of the System (e.g., network segments, back-up tapes, etc.). The Proposer shall assume responsibility that any System components not identified as shared components are provided by the Proposer as System components dedicated for the City’s use only.
iii. Data Storage Limits and Overages – The Proposer shall clearly state all email message limits associated with the System. Where exceeding such email message limits would cause the City to incur additional cost, the Proposer shall state such costs in its clearly marked pricing proposal.
iv. Data Transfer Limits and Overages – The Proposer shall clearly state all text/SMS limits associated with the System. Where exceeding such text/SMS limits would cause the City of Detroit to incur additional cost, the Proposer shall state such costs in its clearly marked pricing proposal.
Solution
System environments
Shared components
Email Message limits
Text/SMS Message limits
C. Cloud Solutions
The Proposer shall clearly state and describe:
i. Its proposed service model (e.g., SaaS, PaaS, IaaS).
ii. Its proposed Cloud deployment model (e.g., Private Cloud, Public Cloud, Community Cloud or Hybrid Cloud);
iii. Whether it relies upon any third parties in the provisioning of its Cloud deployment model.
iv. Whether the Proposer offers any other Cloud deployment.
v. How another of Proposer’s Cloud deployment models might impact the City’s data security and any compliance obligations.
vi. How another of Proposer’s Cloud deployment models might impact pricing, but the Proposer shall state such costs in a clearly marked pricing proposal.
Proposed service model
Proposed cloud deployment model
3rd party provisioning
Rationale for cloud deployment solutions
Other cloud deployment solutions
Data security and compliance considerations
D. Network
The Proposer shall give an overview of all network and bandwidth requirements associated with the proposal. If Proposer determines any of the following requirements to be inapplicable, Proposer shall state so and shall also state the basis for determining each such requirement to be inapplicable; Proposer shall describe the following:
i. Normal Bandwidth Requirements – The Proposer shall include a reasonable estimate of minimum bandwidth required for concurrent application access and data access for “normal” daily operational use for cloud, hybrid and/or on-premise systems. Proposer shall also provide its definition of “normal daily operational use.”
ii. Peak Bandwidth Requirements – The Proposer shall include a reasonable estimate of peak volume/times for each retrieval and uploading transactions for cloud, hybrid and/or on premise systems
iii. Typical Impact – The Proposer shall include a reasonable estimate of the typical impact expected on the network post implementation.
iv. Other Network Requirements – The Proposer should describe the optimal physical network infrastructure required for an on premise solution to effectively mitigate latency and data speed issues. If proposing a cloud-based or hybrid hosting solution, please describe the physical network infrastructure, connectivity testing and performance assurance. Network architecture diagrams must be included with details regarding the management of remote systems.
If any assumptions are made to support the answers, clearly state those as part of the response.
Normal bandwidth requirements
Peak bandwidth requirements
Typical impact
Other network requirements
E. Data Extract, Transform, and Load
The proposal shall give an overview of all data migration, conversion, and transformation requirements associated with the System. If Proposer determines any of the following requirements to be inapplicable, Proposer shall state so and shall also state the basis for determining each such requirement to be inapplicable. Proposer shall describe the following:
i. Data Extract – The Proposer shall include the cost of extracting the data from the source System as part of their price proposal. The Proposer will explain the process to convert the data into a single format for the transformation processing and any tools that will be used. If the performance of this task will cause the City to incur additional cost, the Proposer shall state such costs in its separate pricing proposal.
ii. Data Transform – The Proposer shall include the cost of transforming the data from the source system to the proposed system as part of their price proposal. The Proposer will explain the transformation type required to meet the business and technical needs of the target database and the tools that will be used. If the performance of this task will cause the City to incur additional cost, the Proposer shall state such costs in its clearly marked pricing proposal.
iii. Data Load – The Proposer shall include the cost of loading the data to the proposed system as part of their price proposal. The Proposer will explain the load process and tools. If the performance of this task will cause the City to incur additional cost, the Proposer shall state such costs in its clearly marked pricing proposal.
Data extract
Data transform
Data load
F. Data Ownership, Access and Retention
If awarded, all City data shall be and remain the sole and exclusive property of the City. The selected Proposer will treat City data as Confidential Information. The selected Proposer will be provided a license to the City data hereunder for the sole and exclusive purpose of performing its obligations under the Standard Contract, including a limited non-exclusive, non-transferable license to transmit, process, and display the City data only to the extent necessary in the provisioning of the services and not for the storage or recording of the City. The selected Proposer will be prohibited from disclosing City data to any third party without specific written approval from the City. The selected Proposer will have no property interest in, and may assert no lien on or right to withhold data from the City.
Proposer is expected to acknowledge and accept, or state any objections to, the City’s data use and ownership.
Proposer shall also provide a statement of its data protection practices and its responsibilities to protect and prevent the use or sale of data to/or by external entities. The Proposer’s full data protection policy shall be included as an attachment to its proposal.
Furthermore, the proposal shall state that the Proposer will meet the following data-related System requirements:
i. At all times, the City shall be able to receive data, associated metadata, and reasonably granular subsets thereof, as well as any associated files or attachments, from the System in a useable, encrypted format.
ii. Upon termination of the contract and at the City’s written request, the Proposer shall destroy City data, including back-ups and copies thereof, according to the National Institute of Standards and Technology (NIST) standards or as otherwise directed by the City.
iii. The System shall have the ability to retain City data in a manner that is searchable and capable of compliance with records retention laws and best practices.
iv. At no time may Proposer suspend or terminate City’s access to City data or the System for breach of contract or term or condition relating to the System without giving the City reasonable notice and opportunity to cure according to the City’s dispute resolution process.
G. Licensing and additional Terms and Conditions
Proposer shall describe the following:
i. Licenses The Proposer shall also succinctly state:
| a. . The duration of the software licenses, if any (e.g., perpetual) | |
| b. The City’s rights under the license (e.g., use, disclosure, sale, etc.) | |
| c. Other license restrictions. | |
| d. Any terms and conditions within the license that contradict or conflict |
with the provisions of the Standard Contract.
ii. Additional Terms and Conditions – The Proposer shall agree to the terms and conditions in the City’s Contract (attached as Appendix A), as well as any special conditions to which the City and the Proposer agree, will supersede any terms and conditions proposed by the Proposer or third parties. If the proposal would require the City to agree to any of the following, Proposer shall include complete copies of same:
a. Acceptable use policies;
b. Privacy policies;
c. Other terms and conditions.
H. Intellectual Property
In addition to any other rights granted to the City under the Standard Contract or by operation of law, the Proposer must grant the City a perpetual, royalty free license to all materials prepared pursuant to the contract or in anticipation of the contract, including but not limited to the data, data schemas, studies, briefs, drawings, maps, models, photographs, files, records, computer printouts, estimates, memoranda, computations, papers, supplies, notes, recordings, and videotapes, whether such materials are reduced to writing, magnetically or optically stored, or kept in some other form, for unlimited use by the City for any lawful purpose.
I. Support and Maintenance
The proposal shall individually address each the following requirements and provide sufficient detail on how it meets the following requirements:
i. Multi-tiered support – The proposal shall provide multiple tiers of support and shall state whether the City is assumed to provide the lowest level, Tier 1, support. Define the tier support level and the criteria for each.
ii. Severity levels – The proposal shall provide support and maintenance response proportionate to varying levels of incident severity. Define the severity levels and define the response criteria.
iii. Multiple contact method – The proposal should provide for multiple methods of reporting an incident to the Proposer. Define the methods to initiate support for each tier.
iv. First-tier support scripts – If the Proposer assumes that the City will provide Tier 1 support, the Proposer shall deliver sufficient scripts and training to the City help desk staff and/or departmental technicians to adequately function as Tier 1 support. Define the script format, training requirements and if the provider is able to provide training.
Multi-tiered support
Severity levels
Multiple contact method
First-tier support scripts
The proposal shall individually address the following service level agreements (SLAs) for support and maintenance services, whether such SLAs are offered, any additional cost for such SLAs, and detail on such:
i. Proposer’s Help Desk Availability SLAs – Help desk availability refers to the required time frames during which certain Services provided by the help desk must be available to end-users, and response to automatically generated help desk incidents must be achieved.
ii. Proposer’s Response Time SLAs – Response time is the number of seconds it takes an end-user to connect with Proposer’s contact center live representative. Proposer will provide toll-free telephone lines in adequate quantity to handle call volume; automatic call distribution system (“ACD”) system(s) to record call date, time and duration information; and electronic interfaces to all systems for monitoring and reporting.
iii. Proposer’s Incident Resolution SLAs – Incident resolution is the time elapsed from the initiation of the help desk Incident until Service is restored.
iv. Proposer’s End-User Account Administration SLAs – Routine functions, such as setting up end-user IDs, changing End-User authorization tables, changing account codes and similar functions, which are handled by Proposer.
v. Proposer’s Client Satisfaction SLAs – Measures the level of end-user satisfaction in relation to help desk services.
For each SLA, the Proposer shall state:
i. Details on what written reports Proposer will provide to the City to demonstrate compliance with the SLAs in addition to the reports specified.
ii. Detail on any levels of SLAs, whether by severity or other classification.
iii. Detail on offered service level credits, fee reductions, and/or earn backs.
Help desk availability SLAs
Response time SLAs
Incident resolutions SLAs
End-user account administration SLAs
Client satisfaction SLAs
J. Data Security and Compliance
The proposal shall give an overview of the System’s software, hardware, and other controls supporting the System’s data security and the City’s evolution to a Zero Trust Environment. The Proposer shall provide sufficient details on its data security and privacy controls (using the City of Detroit Cloud Service Provider Security Checklist set forth in Section 10 below and details for any compliance certifications and/or accreditations.
The Proposer shall also provide a reasonably detailed explanation as to how the proposal will protect the System and City’s data within each of the following additional data security categories (NOTE: the City recognizes that reasonable descriptions of each security attribute below will vary in length, some attributes requiring little explanation, others not). If Proposer determines any of the following requirements to be inapplicable, Proposer shall state so and shall also state the basis for determining each such requirement to be inapplicable:
i. Password configurations (e.g., complexity, aging, etc.);
ii. Authentication configurations (e.g., active directory, encrypted data exchange, hash, etc.);
iii. Encryption configurations (e.g., symmetrical AES-256, asymmetrical RSA 2048, etc.) for both data at rest and data in motion;
iv. Logging/Auditing review capabilities (e.g., verbose user tracking and reporting, etc.);
v. Physical security (e.g., 24-hour security, alarms, restricted access, etc.);
vi. Personnel security (e.g., extensive background checks, annual recheck, etc.)
vii. Web Application configurations (e.g., SQL injection protection, buffer overflow, etc.);
viii. Network transmission security (LAN and VPN);
ix. Data that is to be transmitted off-site must be encrypted end to end.
Password: complexity, aging, presentation
Authentication
Encryption
Logging & Auditing
Physical Security
Personnel Security
Web application configuration
Network transmission security
Data encryption
K. Development and Configuration Practices
Proposer shall describe its application development methodology and how its methodology adheres to applicable best practices and standards regarding both data security and data privacy. Proposer shall state how it will tender its deliverables in a manner that reasonably protects the security, confidentiality and privacy of City data and any individuals who may be considered data subjects as to the City, Contract deliverables, or City’s data. Specifically the Proposer shall state whether it conforms to the following:
| i. | Microsoft Secure Coding Guidelines for the .NET Framework; |
| ii. | CERT Secure Coding Standards; |
| iii. | OWASP Secure Coding Principles; |
| iv. | Privacy by design principles; and |
v. Federal Trade Commission’s Fair Information Practice Principles. On-Premise Cloud Hybrid Hosting
Description
Development & Configuration Practices
L. Business Continuity and Recovery
The proposal shall individually address each the following requirements and provide sufficient detail on whether and how it meets the following requirements.
i. Proposers shall have an automated backup and recovery capability for the system and application, including incremental and full back up capabilities. Additionally, system backups shall be accomplished without taking the application out of service and without degradation of performance or disruption to City operations.
ii. Proposers shall be able to provide the service from at least two geographically diverse data centers that do not share common threats (e.g. the data centers cannot be in the same earthquake zone, likely hurricane path, same flood zone, etc.). The data centers shall at a minimum meet Tier III standards for redundancy of power, telecommunications, HVAC, security, fire suppression and building integrity.
iii. Proposers shall specify whether, in the event of a technology or other failure at the primary processing center, the alternate system will meet the following tiers, for which the City’s use should be identical regardless of which location is processing the City’s work:
| Category |
| Alternate system characteristics |
| High availability |
| Continuous operation without interruption or degradation in service. |
| Standard availability |
| Available for City of Detroit use within 48 hours with no degradation in service. |
| Non-Critical Availability |
| Available for City of Detroit use within 96 hours with no degradation in service. |
i. Proposers shall implement crisis management, business continuity and disaster recovery plans, subject to City approval, which the City will not reasonably withhold. These plans shall outline how the Proposer will support the City’s recovery at the alternate site, including backup staff required to implement the plan in an emergency if the Proposer’s primary staff is unavailable. Such plans shall also include a minimum of annual testing in coordination with the City.
ii. Proposers shall specify the System’s proven, maximum tolerable length of time that a computer, system, network, or application can be down after a failure or disaster occurs or its recovery time objective (“RTO”) and the amount of data at risk, as determined by the amount of time between data protection events, and as it reflects the amount of data that potentially could be lost during a disaster recovery point objective, (“RPO”) in case the primary site becomes unavailable. The selection of the RTO and RPO will be agreed upon objectives between the Proposer and the City.
iii. Proposers shall specify whether the System will meet the following availability tiers, which tier, and shall specifically describe how the System meets such tier:
| Category |
| Availability |
| RTO |
| Characteristics and RPO |
| High Availability |
| 99.982% |
| Intra-day |
| Typically involves data replication to a hot-site for each transaction or at short intervals, like 15 minutes. |
| Standard Availability |
| 99.741% |
| 24 to 48 hours |
| Nightly imaging to cloud / data center. System reestablished at time of disaster from cloud / data center. May lose up to one day of data. |
| Non-Critical Availability |
| 99.671% |
| 48 to 56 hours |
| Nightly imaging to cloud / data center. System reestablished at time of disaster from cloud / data center. May lose up to one day of data. |
Description
Automated backup* recovery
Data centers
Availability
Business continuity and disaster recovery plans
RTO (Recovery Time Objective) and RPO (Recovery Point Objective)
Availability tiers
2.2. PROPOSED PROJECT APPROACH AND IMPLEMENTATION
METHODOLOGY
A. Although a detailed approach format is included in the following sections, Proposers are expected to propose a ‘industry - best practice’ methodology and solution, and are encouraged to provide innovative ideas to meet the needs of the City in a timely manner. The proposed project plan shall adhere to an industry project delivery methodology. Proposers shall provide a detailed project plan and methodology that clearly demonstrates how their team will initiate, reengineer and automate the processes described in this RFP. Proposals shall include a detailed work breakdown structure that conveys how work will be performed and communicated in an organization of similar size and complexity. The City requires a managed implementation that accomplishes tangible deliverables by a date agreed to within a joint project task list and timeline. The proposed approach and methodology shall include, but should not be limited to, the following sections.
B. Overview of the Implementation Methodology. The Proposer must agree to comply with the City’s project delivery methodology for tracking progress and documents for the duration of the project. In addition, the Proposer will submit weekly status reports to the City. These reports will include:
| i. | Work accomplished each week from the task list and timeline. | |
| ii. | Updated GANTT charts. | |
| iii. Tasks for the next week from the task list and timeline. | ||
| iv. List of deliverables for the current week and next week. |
v. Status of risks or issues that affect delivery in accordance with the Provider
| vi. Task list and timeline. |
| vii. Invoice requests and payment schedules |
| viii. Other items relevant to project delivery. |
Proposers should provide an implementation methodology and include:
| i. | Brief description of the project delivery methodology. |
| ii. | Project phases. |
| iii. Team roles. | |
| iv. Milestones for each phase and deliverables. | |
| v. | Quality delivery plans. |
| vi. Test Policies and Processes. | |
| vii. Change Management Processes. | |
| viii. Training methodology. | |
| ix. Customer care processes and procedures. | |
| x. | Requirements traceability procedures. |
C. Project Task List and Timeline. Proposers should provide a task list and timeline down to the resource level. This should include:
i. Phases, in accordance with the implementation methodology.
ii. Milestones
iii. Governance
iv. Tasks
v. Assumptions, and
vi. Dependencies with the City delivery team.
The selected Proposer is responsible for accurately estimating effort and presenting a comprehensive plan reflecting careful assessment of the requirements in this RFP document and related attachments.
D. Requirements Validation and System Design. Proposers should provide a detailed description of its approach to validating business and technical requirements, in order to design a system solution and related architecture that adheres to industry best practices and the current the City’s technology environment. The City expects this section to include at a minimum:
| i. | Business requirements validation checklist. |
| ii. Technical requirements validation checklist. | |
| iii. System design validation checklist. | |
| iv. The City responsibilities. |
E. System Implementation and Configuration. Proposers shall provide a detailed description of the proposed build and release approach. Describe the level of effort and timeline based on the expected configuration and customization work. The City expects this section to include at minimum:
| i. Proposed environments. |
| ii. Software configuration at the desktop. |
| iii. System architecture. |
| iv. System design. |
| v. List of deliverables to the City. |
| vi. List of deliverables from the City required by the Provider. |
| Implementation and Configuration |
| Solution |
Environments
Software configuration
System architecture
System design
Deliverables
City of Detroit project deliverables
F. Quality Planning, Assurance and Control. Proposers shall provide a detailed description of the proposed quality methodology adhering to best practices and clearly identifying control tasks and testing. The City expects this section to include at minimum:
i. Provider quality policy.
ii. Provider test policy.
iii. Provider test plans.
iv. Provider testing procedures.
v. Provider test levels and types.
Proposer shall conduct unit and integration testing prior to delivering the System to the City for User Acceptance Testing (UAT). The test cases and test results from unit and integration testing will be provided as a stage gate for the City approval to start UAT. The test cases and test results shall be mapped back directly to requirements identified by the City using a traceability matrix.
| Requirement |
| Test case |
| Test results |
| List requirement |
| List steps for each test case |
| List results |
G. Knowledge Transfer, Training and Transition. The City requires and expects the selected Proposer to provide training for all Board staff, plus certain staff of the Office of the Chief Financial Officer. Therefore, all Proposers are required to describe the recommended knowledge transfer, training and transition processes. Describe the City’s responsibilities. This plan should include at minimum:
i. Knowledge transfer plan: location, format, and total hours, number of employees trained.
ii. End user training plan: location, format, total hours, number of employees trained
iii. Application administrator training plan: location, format, total hours, number of employees trained
iv. Transition plans from old to new system.
v. Support provided during roll-out of the new system: location, format, and total hours, number of employees trained
vi. The City responsibilities during each milestone during knowledge transfer, training, and transition.
Provide the response in this format:
| Knowledge Transfer, Training, and Transition |
| Solution |
Knowledge transfer plan
End user training plan
Application administrator training plan
Transition plan from old to new system
Support provided during roll-out
City of Detroit responsibilities
H. Contract Performance Review and Acceptance. Proposers should describe all expected contract performance metrics and steps to transfer all assets to the City. This close out plan should include at a minimum:
i. List of deliverables.
ii. Acceptance criteria for all deliverables: who will be submitting, timeframe for acceptance from submission and any default acceptance timelines.
| Performance, Review, and Acceptance |
| Solution |
List of documentation
Acceptance criteria
2.3. CLOUD SERVICE PROVIDER CHECKLIST
Proposers must provide the following information:
| Issues |
| Status/Comment |
Adhere to The City Data Security, Data Privacy, Identity Management, Data Deletion, Physical Security, Business Continuity, Backup Encryption, Incident Management and FTI Deletion (if Federal Tax Information is held) Policies
Clear understanding of responsibilities for applications running on cloud infrastructure. City list, Provider list
The provider must show diagram (and possible past examples) of their governance and notification processes for their services, as required by The City
Describe how the provider will guarantee legal and regulatory compliance with government and sectorial (industry specific) laws and regulations
Describe Established Patch Deployment
Describe the mechanism in place to provide reports to the City of Detroit for both normal and exceptional behavior relating to security and privacy operations
Cloud providers security and privacy controls to follow one of the following set of best practices:
o NIST Series o ISO/IEC Series o COBIT o ITIL
Provide SSAE 16 Compliance Documentation
Describe process for Account Management
Describe details of monitoring and how it will be reported
Describe the issuance of encrypted Login Credentials
Describe how a data inventory of City of Detroit Data Assists will be kept.
Will the City of Detroit receive a description of all responsible parties and their roles
Guarantee Encryption of all PII and other data deemed confidential (part of data inventory)
Describe Key Management Program
Describe Malware Program
Process for Separation of data belonging to different consumers in a multi‐tenant environment
Statement guaranteeing Adherence to all Privacy laws governing the physical areas of data storage
Willing to participate in a Risk Assessment and Privacy Impact Assessment covering the storage of PII
Network traffic must be screened and firewall protected Network must have intrusion detection & prevention in place
Network must have detailed logging and documented notification
Process used to separation of network traffic in a shared multi‐tenant provider environment
Dedicate VLANs with dedicated virtual firewall
Describe how the City of Detroit network access separated from provider network access
Are the City of Detroit VMs are on a dedicated hypervisor
Will Providers servers only communicate with The City of Detroit logical disk units
Will online storage and backup media scrubbed when retired or replaced
Service Provider is required that all security terms must also pass down to any peer cloud service providers
Documented exit process and obtain approval by the City of Detroit
OPERATIONAL INFORMATION
Awarded Contractor(s) will work closely with City agency staff.
The Respondent is expected to provide service in accordance with the terms of the executed contract and under the rules, regulations, and supervision of the City.
TECHNICAL INFORMATION
City Data Standards The City is committed to centralizing and warehousing Data for the purpose of improving service delivery and enabling cross departmental analytics. The System must enable Data access, Data interoperability, warehousing of resulting Data, and adherence to City data standards which the City has provided to the Contractor for review.
Specifically, the System requires:
· We require access to all System data for automated data warehousing purposes, provided through at least one of the following machine-readable methods:
· Preferred: Direct database access, or access to a reporting database (ODBC-compatible)
· Alternative: API access providing data in one or more of the following formats: JSON, CSV, or XML
· Full documentation of APIs (including field names and objects) and the database schema used by the application.
· Ability for City to programmatically update data within the System as needed via API
· Any location-based data or platform utilizes the City’s base units geocoder, Base Units Database, and/or address Data standards as applicable.
· The ability for the City to use and govern Data as it deems necessary-- centralizing it, porting it into other systems, and using it for additional and future organizational needs.
· Data collected, transferred and stored meet minimum standards to ensure confidentiality, integrity and availability.
· Data to meet compliance rules / regulations in order to ensure the sensitive digital assets are guarded against loss, theft and misuse. These rules come in a number of forms including applicable industry compliance / standards (i.e. HIPAA, PII, PCI-DSS, NIST, ISO), state or federal-level laws or even supra-national regulations.
· The System must have the capacity to store field-level metadata and display it in the user interface when appropriate
· API is able to provide Data in a JSON format.
· Data system or data exports integrate easily with ESRI products including feature services.
· Systems or platforms that support data exchanges (pushes and pulls) that can happen dynamically.
Section 3. Proposal Evaluation and Selection Process
2.
MINIMUM QUALIFICATIONS
Proposals will only be accepted from those firms demonstrating a minimum of three (3) years of experience providing the services requested in the RFP for projects of similar scope and size.
ADHERENCE TO TERMS OF PROPOSALS
A proposal once accepted by the City of Detroit may become a binding contractual obligation of the Respondent. The failure of a successful Respondent to accept this obligation and to adhere to the terms of the Respondent’s proposal may result in rejection of the proposal and the cancellation of any provisional award to the respondent. Respondents are not permitted to take advantage of any errors or omissions in specifications since full instructions will be given should they be discovered before bid submission date.
QUESTION DEADLINE
All questions regarding the RFP shall be submitted through the Supplier Portal no later than the time and date specified in the solicitation. In the interest of transparency, only written questions will be accepted. Answers to questions will be posted within the Supplier Portal. The City of Detroit does not guarantee a response to questions submitted after the question deadline.
Should a Respondent be in doubt as to the true meaning of any portion of this RFP or find any patent ambiguity, inconsistency, or omission herein, the Respondent must make a written request for an official interpretation or correction in accordance with the instructions for submitting questions as specified in this RFP.
Respondents are advised that no oral interpretation, information or instruction by an officer or employee of the City of Detroit shall be binding upon the City of Detroit.
Respondents requesting changes to the RFPs terms and conditions, specifications, quantities, etc.; or if clarifications are needed, must make the request in writing by the stated bid submission deadline. .
EVALUATION CRITERIA
Phase One Criteria not to exceed 100 points, Technical Proposals will be evaluated before Cost Proposals are reviewed.
| Proposal Evaluation Criteria |
| Possible Points |
| 1. Quality of the product, including its ability to meet the City of Detroit’s functional, technical and security requirements |
| 40 |
| 2. Project Approach and Work Plan, including the proposed delivery model, training program, maintenance and support offerings, and ability to meet the City’s objectives described in this RFP. |
| 30 |
| 3. The vendor’s experience and staff capabilities including references and experience with similar implementations for comparable agencies |
| 15 |
| 4. Pricing |
| 15 |
| Total Points Possible |
| 100 |
Detroit Equalization Credits according to the following table shall be applied after the technical and price evaluation. (Please see Equalization Credit Statement for more information)
| Detroit Equalization Credits – Prime Contractor |
| Possible Points |
| Detroit Headquartered Business |
| 5 |
| Detroit Based Business |
| 2 |
| Detroit Resident Business |
| 5 |
| Construction Workforce Investment Business (Construction over $1M) |
| 3 |
| Construction Workforce Development Business |
| 3 |
| Detroit Small Business |
| 1 |
| Detroit Micro Business Concern |
| 2 |
| Joint Venture |
| 2 |
| Mentor Venture |
| 1 |
EVALUATION PROCEDURE
Following the receipt of proposals, a City designated Evaluation Committee will evaluate each response. All PROPOSALS, which meet the required format of this RFP, will be evaluated. Any proposals determined to be non-responsive to the specifications or other requirements of the RFP, including instructions governing submission and format, will be disqualified unless the City determines, in its sole discretion, that non-compliance is not substantial or that an alternative proposed by the Respondent is acceptable.
The City may also at its discretion request oral presentations, make site visits at Respondent’s facility and may request a demonstration of Respondent’s operations. If scheduled, a final determination will be made after the oral presentations and/or demonstrations are complete.
The City may also at its sole discretion, elect to rank order the qualified proposals, and negotiate with some limited number of the highest scored qualified respondents. A final determination would include the cumulative inputs of this evaluation procedure. All decisions reached by the Evaluation Committee will be by consensus.
Any of the additional data specs and standards described in Section 2.3 that are met will be factored positively into the overall score.
ORAL PRESENTATION/DEMONSTRATION
The City reserves the right, at its own discretion, to request oral presentations regarding proposals submitted in response to the RFP. Failure to make an oral presentation will be grounds for rejection of your proposal. Respondents will be notified by the Office of Contracting and Procurement of the date, time and location for oral presentations.
REJECTIONS, MODIFICATIONS, CANCELLATIONS
The City of Detroit expressly reserves the right to:
1) accept or reject, in whole or in part, any and all proposals received;
2) waive any non-conformity;
3) re-advertise for proposals;
4) withhold the award for any reason the City determines;
5) cancel and/or postpone the request for proposals, in part or in its entirety, and/or,
6) take any other appropriate action that is in the best interest of the City.
This RFP does not commit the City of Detroit to award a contract, to pay any cost incurred in the preparation of a proposal under this request, or to procure or contract for services.
PROTESTS
Protests can be filed with the Office of Procurement. Interested parties aggrieved by a solicitation or the award of any resulting contract may file written notice of protest to the following:
City of Detroit Chief Procurement Officer 2 Woodward Avenue, Suite 1008 Detroit, MI 48226 “Procurement Protest”
At a minimum, such protests shall include:
1) name of protestor.
2) solicitation/contract number and description; and
3) statement of grounds for protest (reference specific text in the solicitation, bid or contract document that is at issue).
An actual or prospective bidder or offeror whose direct economic interest would be affected by the award of a contract or the failure to award a contract has the right to protest any aspect of the solicitation, evaluation, or selection process of a City of Detroit procurement.
A protest by a prospective bidder which challenges the terms of the solicitation itself must be received by the City no later than 4:00 p.m. EST of the business day prior to the date scheduled for the bid closure. Failure to meet this deadline shall result in a protester waiving its ability to challenge the terms of the solicitation.
A protest by a bidder which challenges a contract award must be received no later than 4:00 p.m. EST five (5) business days after the award of a City procurement. Failure to meet this deadline shall result in a protester waiving its ability to challenge the contract award.
All protests must be submitted in writing and received by the required timeframe.
The Chief Procurement Officer (CPO) or as delegated, the Deputy CPO, has the sole authority to respond to, decide and act upon supplier protests.
The decision of the Chief Procurement Officer and/or the Department Director are final and is not subject to appeal.
Section 4. Required Proposal Content and Submission Process 3.
ACCURACY AND COMPLETENESS OF INFORMATION
All information pertaining to the prospective respondent’s approach in meeting the requirements of the RFP shall be organized and presented in the prospective respondent’s proposal. The instructions contained in this RFP must be strictly followed.
Accuracy and completeness are essential. Omissions and ambiguous or equivocal statements will be viewed unfavorably and may be considered in the evaluation. Since all or a portion of the successful proposal may be incorporated into any ensuing contract, all prospective respondents are further cautioned not to make any claims or statements that cannot be subsequently included in a legally binding agreement.
REQUIRED PROPOSAL CONTENT AND FORMAT
To be considered responsive, each proposal must, at a minimum, respond to the following RFP sections in their entirety, responses must be uploaded in the Supplier Portal along with the Affidavit of Disclosure Interests Form and Non- Collusion Affidavit found under requirements section of the of RFP#546288:
Required Response Item
| 1. |
| Attachment A – Respondent Questionnaire |
Respondent shall provide their Organization Experience, per the requirements provided in Attachment A.
| 2. |
| Attachment B – Proposal Introduction and Solution / Approach |
Respondent shall provide their Proposal Introduction and Solution / Approach and Capacity/Staffing, per the requirements provided in Attachment B.
| 3. |
| Attachment C – Pricing |
Respondent shall provide their Pricing proposal, per the requirements provided in Attachment C.
| 4. |
| Attachment D1 – Forms, Affidavits and Documents – Bid Requirements |
Respondent shall provide their completed Certificate of Authority, Non-Collusion Affidavit, and Affidavit of Disclosure of Interests, along with your organization’s financial statements (Balance Sheets, Income Statements and Statement of Cash Flows) for the previous three (3) years.
Please do not submit your tax returns. in Attachment D1.
| 5. |
| Attachment D2 – Conditions of Award |
Respondent will be required to provide their completed Forms, Affidavits, Insurance and Documents, if they are selected as the award winner provided in Attachment D.
| 6. |
| Attachment E – IT Contract |
Respondent shall provide their agreement to the Model Professional Services Contract or note any exceptions provided in Attachment E.
| 7. |
| Attachment F – Requirement Matrix |
| 8. |
| AI Factsheet – Please complete the AI Factsheet using the link below. |
https://app.smartsheet.com/b/form/ce9622cae7d0401092739f338b1d6b98
REQUIRED COST PROPOSAL
Respondents are requested to make a firm cost proposal to the City of Detroit, through the completion of Attachment C. If a contract is entered into as a result of this RFP, it will be a contract for fees as related to providing all requested services, with a price not to exceed the total price quoted…
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .