HomeMy WebLinkAbout26 - Instructions - Permits, Licenses, & Code Enforcement (PLCE) Software and Implementation Services (2)
/
Request for Proposals (RFP)
Permits, Licenses, & Code Enforcement (PLCE) Software and Implementation Services
***Section V. Word Attachments***
City of Bozeman
Bozeman, MT
City of Bozeman
PO Box 1230
Bozeman, MT 59771-1230
CLOSING DATE: May 18th, 2026 at 3:00 PM MT
ATTACHMENTS
RESPONDENT INFORMATION
Attachment 1.1 – Signature Page
Each Firm shall complete the Signature Page.
I acknowledge that I have read and understand the RFP documents.
I hereby certify that the information submitted by the Firm in response to this RFP, including pricing and other information, is true and accurate.
I hereby certify that the Firm is independent of the City of Bozeman and is unaware of any potential conflicts of interest if it were selected to perform the requested work.
I hereby certify that I am authorized to bind the Firm in a contract.
The undersigned Firm having examined this RFP and having full knowledge of the condition under which the work described herein must be performed, hereby proposes that the Respondent
will fulfill the obligations contained herein in accordance with all instructions, terms, conditions, and scope of requested services set forth; and that the Respondent will furnish
all required products/services and pay all incidental costs in strict conformity with these documents, for the stated prices as proposed.
Submitting Firm:
Click to enter text.Primary Firm☐
Address:Click to enter text.City:
Click to enter text.State:
Click to enter text.Zip:Click to enter text.SAM.gov UEI Number:Click to enter text.Authorized Representative:Click to enter text.Title:Click to enter text.Click to enter
date.SignatureDate
Primary Contact for Firm
Name:Click to enter text.Title:Click to enter text.
Email:Click to enter text.Phone:Click to enter text.
Attachment 1.2 – Nondiscrimination and Equal Pay Affirmation
Each Firm hereby affirms it will not discriminate on the basis of race, color, religion, creed, sex, age, marital status, national origin, or because of actual or perceived sexual orientation,
gender identity or disability and acknowledges and understands the eventual contract will contain a provision prohibiting discrimination as described above and this prohibition on discrimination
shall apply to the hiring and treatments or proposer’s employees and to all subcontracts.
The Respondent hereby affirms it will abide by the Equal Pay Act of 1963 and Section 39-3-104, MCA (the Montana Equal Pay Act).
Click to enter date.Signature of Respondent’s Authorized OfficialDate
Click to enter text.Click to enter text.Name of Person Signing (Print)Title of Person Signing (Print)
Attachment 1.3 – Respondent Statement
By submitting a response, the Respondent acknowledges that all Firms associated with the Respondent have acquainted themselves with the terms, scope, and requirements of the project
based on the information contained in this RFP and any addendums. Any failure by the Respondent to acquaint themselves with available information will not relieve them from the responsibility
for estimating properly the difficulty or cost of successfully performing the work available. The City is not responsible for any conclusions or interpretations made by the Respondent
on the basis of the information made available by the City.
Proposals that do not acknowledge addendums may be rejected.
The following addendums are acknowledged by the Respondent and reflected in our response.
Addendum
Initials
Click or tap here to enter text.Click or tap here to enter text.Authorized Agent NameTitle
Click to enter a date.Authorized Agent SignatureDate
Attachment 1.4 – Software Background
Complete one form for each software provider included in the proposal.
Product Information
Software product name (commercial name):
Legal owner/licensor of software (if different):
Software History
Date of first commercial release:
Current major version number:
Year current core architecture was introduced:
Frequency of major releases: (e.g., annual, quarterly)
Identify any predecessor products or re‑platforming events:
Current Version
Top five (5) functional enhancements introduced in the current version:
1
2
3
4
5
Key functional, architectural, or platform changes over the last three (3) years that materially impact customers:
1
2
3
4
5
Identify the most significant functional or technical limitation of the current software relevant to this RFP or experienced by similar clients:
Third-Party Products
List any third-party products embedded in the software: (Product name, purpose, can be removed or substituted?)
Third-party products recommended but not embedded: (Product name, purpose, required/optional, additional costs)
Attachment 1.5 – Professional Services Background
Complete one form for each Firm responsible for implementation delivery included in the proposal.
Respondent Background
☐ Primary FirmLegal company name:
Corporate headquarters location:
Offices supporting PLCE delivery (by region):
Estimated percent of PLCE delivery resources located in North America / offshore:
Firm HistoryYear Firm established (under current legal structure):
Previous Firm names, mergers, or acquisitions in last 10 years:
Previous names and successor Firms:
Current and Recent Projects
List up to five (5) current or recent projects that provided relevant experience:
1
2
3
4
5
Firm’s primary target market for PLCE implementation services (e.g., industry, organization size, complexity):
Describe how this project aligns with that target market:
Identify three (3) key lessons learned from recent PLCE implementations and describe how each will be specifically applied to this project:
1
2
3
Size
Number of PLCE implementation projects completed in the past five (5) years:
Number of PLCE implementations currently in progress:
Consulting Team
Total size of PLCE consulting practice: (exclude non-PLCE consultants)
Average annual attrition rate (# of leaves / average # of employees) of PLCE consultants:
Proposed project team size:
Average PLCE implementation experience of proposed team members:
Average tenure with Firm for proposed consulting team:
Attachment 1.6 – Reference Form
Please provide at least three (3) references for past projects that include products and services similar to those proposed for this RFP and of comparable organizations. Each firm should
provide one set of references. Please provide at least one reference based in Montana if possible.
NOTE: Responses stating that references will be provided at a later time shall be deemed non-responsive.
Firm Name: Click or tap here to enter text.
References ☐ Primary FirmName of product:
Name of client:
Client’s employee count:
Client’s annual operating budget:
Contact name:
Contact title:
Contact email:
Contact phone:
Project Scope (check boxes for which implementation was conducted)
☐Customer /Property File☐
Customer Portal☐Permitting☐Licensing☐Code Enforcement☐Deployment
☐On-premise☐Private Cloud☐
SaaSImplementation duration:Planned Go-Live Date:Actual Go-Live Date:Describe Roll on Project:Project Challenges:Major Accomplishments:
FUNCTIONAL REQUIREMENTS
Attachment 2.1 – Functional Requirements
(See Excel Attachment V.2.1– Functional Requirements)
The Functional Requirements describe the software scope of the overall project and the requirements for each functional area. Responses to the Functional Requirements shall identify
the scope of system configuration that will be accepted by the City as part of the project.
The Functional Requirements are a material component of the proposal evaluation and will allow the City to determine if a Respondent can adequately support the City in meeting its project
goals identified in II.4.0. Respondents should accurately reflect the ability of the proposed solution to meet a specific requirement. The inability to provide some requirements or
excluding some requirements from scope may affect scoring but will NOT eliminate the Respondent from contention. However, failure to accurately portray a software’s capability may result
in disqualification. If Respondents are unsure or unclear on the description of a specific requirement, please send a question or request for clarification by the deadline noted in
I.4.0. The requirements responses submitted will become part of the agreement.
For the avoidance of doubt, all affirmative responses to the Functional Requirements shall be designed, configured, and implemented unless a satisfactory workaround or other mutually
agreed solution is determined, or if any requirements are descoped by mutual consent. Failure to do so may result in the City seeking remedial action.
Respondents should indicate their responses to the City’s functional requirements. The Instructions tab on the spreadsheet provides guidance on completing the attachment.
TECHNOLOGY AND SYSTEM CAPABILITIES
Attachment 3.1 – Reporting
(See Excel Attachment V.3.1 - Reporting)
The City has identified critical reports important to the organization. This represents the reports currently run by the City, and the City acknowledges that not all these reports may
be needed, required, or available in a new system. For each report identified in Attachment 3.1, Respondents shall indicate whether the report or information provided in the report
can be provided and describe the method by which it would be delivered. All reports for which a Respondent indicates an affirmative response are expected to be available, tested, and
accessible to City users at go‑live and included in the fixed fee price proposal. Instructions for completing the responses to the functional requirements are included in the attachment.
Attachment 3.2 – Interfaces
(See Excel Attachment V.3.2 - Interfaces)
For each interface identified in Attachment V.3.2, Respondents shall indicate whether the interface can be supported and describe the proposed integration approach. Any interface for
which a Respondent provides an affirmative (“Yes”) response shall be considered in scope and included in the fixed fee price proposal.
If additional interfaces are proposed, please add them and indicate how they will be implemented. The interface plan proposed by the Respondent shall be included in the fixed fee price
proposal. The City acknowledges that additional interfaces not included in the attachment may require a change order and an additional fee.
The Instructions tab on the spreadsheet provides guidance on completing the attachment.
Attachment 3.3 – Solution Information
Please respond to the questions and statements below regarding general solution information. Responses should describe capabilities available in the current generally available version
of the proposed system. Please provide responses as concisely as possible.
General
Proposed solution type.
Choose an item.
Authentication
Does the solution support Single Sign‑On (SSO)? If yes, identify supported standards (e.g., SAML 2.0, OpenID Connect, OAuth 2.0):
Does the solution support LDAP or Active Directory integration?
Does the solution support Multi‑Factor Authentication (MFA)? If yes, describe supported MFA methods (e.g., SMS, authenticator app, etc.):
Can MFA be enforced by role or user group?
Data Center & Hosting
Describe the hosting model:
Identify the primary responsibility for infrastructure management: (Vendor / Third party / Customer)
List primary and secondary data center locations (region/country):
Will the data for this project be located within the continental United States?
Identify any third‑party providers used for PaaS or IaaS (e.g., AWS, Azure, GCP) and describe the Respondent’s contractual relationship with these providers:
List each proposed environment (e.g., Production, Test, UAT, Training) and its purpose. Are environments logically or physically segregated?
Describe how the system scales to support growth in users, transactions, and data volume:
List data center audit certifications held (e.g., SOC 1/2 Type II, ISO 27001):
Data & Privacy
Describe the Information Security Management System (ISMS) governing the solution:
Is the solution ISO 27001 certified?
Identify ownership of all customer‑ provided and customer‑generated data:
Describe how the software provider may use customer data (if at all):
Describe supported mechanisms for exporting customer data upon request or contract termination, including exportable formats:
Specify any fees, timelines, or limitations associated with data extraction:
Describe incident response processes for data breaches:
Customer responsibilities during a breach event (if any):
What is your process when someone subpoenas or requests our data from you as a vendor?
Security
Describe how user roles and access permissions are defined and maintained:
Describe support for the Principle of Least Privilege (PoLP):
Describe login and session management across system modules:
Describe encryption standards used for data at rest and data in transit:
How is City data kept separate and secure from other customers, including any PII (Personally Identifiable Information) that may be gathered?
Describe the system’s PCI compliance for credit card transactions:
How is application‑level encryption supported for sensitive fields?
Describe how user security changes are requested, approved, and audited:
Describe system health and availability monitoring mechanisms:
Describe alerting and escalation processes for security and availability events:
System Support & Maintenance
Describe procedures for handling system outages and user‑reported issues:
Describe escalation paths for unresolved critical incidents:
Describe how customers are notified of incidents and outages:
Frequency of status updates during incidents:
Updates & Roadmap
Describe the frequency of software releases (major and minor):
Advance notice period provided before production updates:
Are updates mandatory or optional?
Are customers able to defer updates? If so, for how long?
Customer testing window prior to mandatory updates:
Describe the process for submitting, prioritizing, and tracking customer‑requested enhancements:
Integrations
Identify supported payment gateways and describe PCI DSS compliance posture and responsibilities between Respondent and City:
Describe how GIS data is consumed (parcel ID, address, impervious area, frontage, service eligibility) and frequency and method of GIS synchronization:
Attachment 3.4 – System-Wide Software Capabilities
Please respond to the questions and statements below regarding general system capabilities. Responses should describe capabilities available in the current generally available version
of the proposed system. Please provide responses as concisely as possible.
Accessibility
Describe the system’s compatibility with desktop browsers, tablets, and mobile devices:
Are all core system functions accessible via mobile devices, or are some functions limited to desktop? If not, which ones?
Describe compliance with accessibility standards (e.g., WCAG 2.1 Level AA, Section 508):
Attachments & Document Management
Describe the system’s ability to attach documents to business transactions:
Describe the system’s ability to search for attachments within the application:
Describe any OCR capabilities regarding attachments, including invoices:
Describe the system’s ability to integrate with a third-party document management system to support attachments to business transactions:
Describe retention, archival, and purge capabilities for attached documents:
Audit
Describe transaction‑level auditing capabilities, including which events can be tracked:
Describe the ability to configure audit logging by transaction type, user role, or data element:
Describe how audit logs are secured, retained, and protected from alteration:
Describe how the system tracks security changes (e.g., role changes, permission updates):
Describe reporting and alerting capabilities based on audit activity:
Customer Portal
Describe customer self‑service features (permit application, document submission, application tracking, license application, code enforce complaints, code enforcement case tracking,
printing approved permits and licenses, requesting inspections, etc.):
Describe multi-account and multi-property login support:
Describe supported customer notification channels (e.g., SMS, email, push, etc.):
Data
Describe the system’s flexibility to add data fields to records and transactions, including any impacts on reporting and updates:
Describe how the system supports future-dated and back-dated changes:
Describe data validation rules and controls to ensure data quality:
Describe data retention, archival, and purging capabilities:
Transactions
Describe how the system supports templates to enter routine, recurring, or frequent transactions:
Describe the ability to save transactions in draft status for later editing and posting.
Describe the system’s ability to add notes / comments to transactions (e.g., applicant file, inspections, code enforcement cases):
Workflow
Describe how workflow rules are defined and configured:
Describe how users are notified of required actions:
Describe the system’s ability to support communications within the system to reduce emails:
Describe the user’s ability to view workflow status, history, and pending actions:
Describe the system’s ability to support alternate / temporary designated approvers:
Describe escalation rules and notifications when an approver does not respond:
Attachment 3.5 – Proposed Service Level Agreement
Please complete the following table identifying proposed service level guarantees. For each service, please indicate the metric used to measure the service quality, the proposed requirement
(target for service), and the proposed remedy/penalty if guarantee is not met.
Proposed Service Level Guarantees
Service
Metric
Requirement/ Guarantee
Remedy if Not Met
System Availability (Unscheduled Downtime)
System Response (Performance)
Issue Response Time
Issue Resolution Time
Recovery Point Objective (RPO)
Recovery Time Objective (RTO)
System Data Restore
Implementation of System Patches
Notification of Security Breach
Please list other proposed service levels
Proposed Service Level Guarantees
Define the metric used to calculate availability contained within the contract SLA:
How is performance against service levels reported to the City?
Please describe how the City will be able to monitor system performance through system performance reports, including:
System Availability/Uptime
Response Time/Performance
Throughput/Transaction Rate
System Logs (Startup time, error logs, users access)
Cyber Liability
In the event of a cyber-incident, please define liability for the City and vendor including any proposed mitigation services provided by vendor
IMPLEMENTATION
Attachment 4.1 – Work Effort
(See Excel Attachment 4.1 – Work Effort)
Respondents should complete the attachment regarding the level of effort for both the Respondent and the City for the project. The Instructions tab on the spreadsheet provides guidance
on completing the attachment.
Attachment 4.2 – Deliverables Expectations
(See Excel Attachment V.4.2– Deliverables Expectations)
Respondents should complete the attachment regarding deliverables expectations for the project. Please note there are two tabs to complete. The Instructions tab on the spreadsheet provides
guidance on completing the attachment.
The deliverables noted in the Deliverable Summary tab will be included in the SOW and will inform the milestones that trigger payments.
Attachment 4.3 – Data Conversions
(See Excel Attachment V.4.3 – Data Conversions)
Respondents should complete the attachment regarding data conversions for the project. If additional interfaces are proposed, please add them. The Instructions tab on the spreadsheet
provides guidance on completing the attachment.
Attachment 4.4 – Project Management Expectations
(See Excel Attachment V.4.4- Project Management Expectations)
Respondents should complete the attachment regarding project management for the project. The Instructions tab on the spreadsheet provides guidance on completing the attachment.
Attachment 4.5 – Challenges to Solve
The City has identified a set of key challenges related to its current environment. Respondents are requested to review each identified challenge and describe how their proposed solution
and implementation approach would address the challenge. Responses should be specific to the City’s stated challenges and should reflect the Respondent’s understanding of municipal
PLCE environments and best practices.
Customer/Property File / Customer Portal
Challenge
GIS Integration: The City maintains geospatial data that will be used by systems across the organization. Multiple business processes rely on this data, and it is critical that information
remains accurate, consistent, and aligned across systems.
The City seeks Respondents’ recommendations on how their PLCE solution can successfully integrate with the City’s GIS, ERP, and Utility Billing systems to support shared data elements
and business workflows while minimizing duplicative data entry and reducing the risk of data becoming misaligned across systems. Respondents should describe how their solution would
support effective data synchronization, clearly defined system‑of‑record responsibilities, and ongoing data integrity between the PLCE, ERP, UB and GIS environments.
Response
Challenge
Addressing: The City manages addresses and road center lines in spatial data layers that are part of the City’s GIS system. The City’s Addressing spatial data layer is the authoritative
record of official addresses within the City. Through consistent address assignments, the City supports public safety and emergency response (e.g., NG9-1-1 services); facilitates mail
and other delivery services; guides development and growth in a systematic way; and maintains logical address references for residents, businesses, and government services. When creating
an address, the City utilizes multiple systems that require manual and repetitive data entry. Addresses are assigned based on the front or main entrance to the addressable structure.
Address creation and assignments are needed as part of annexation and development applications. Residential, commercial, industrial, and significant accessory buildings must have addresses.
Secondary structures may be addressed when required for safety or services. Multi-unit structures must use logical unit numbering.
The City intends to continue to use the GIS system as the address system of record, but is interested to understand how the proposed PLCE system can interface with the GIS to incorporate
the creation of addresses and street names using PLCE workflows and incorporating updated address information into the PLCE system.
In addition, the PLCE system should provide a real time link to interface data to the GIS for display and map printing, and should be able to leverage GIS centric data as needed.
Response
Challenge
Records Retention: Please explain the reporting and document retrieval system or processes of the PLCE, including data and information that is in the PLCE as well as plan sets and other
attachments.
Response
Challenge
Lot Consolidation and Segregation: Permit and license applications can be made for properties/ parcels immediately upon lot consolidation or segregation. Please explain how the PLCE
manages lot consolidations and segregations. Discuss the impacts of lot consolidation and segregations on historical data and information (such as applications and issued permits, licenses,
and code enforcement cases). How do lot consolidations and segregations affect applications? Can an application be made prior to an address being assigned to the newly configured lot
/ parcel?
Response
Permitting
Challenge
Connecting Related Permits / Applications Under One Umbrella: A critical function for the City is ensuring the permit applications are properly associated. The City needs the ability
to relate and track permits across the full lifecycle of development activity. For example, a development may begin with a planning approval, followed by parcel subdivision, and later
result in multiple individual building permits issued over several years. Or linking Development Review approvals to site specific building applications, ensuring there is proper Planning
approval in place prior to receiving building permit applications.
The City wants to clearly understand and visualize how current permits are connected to prior approvals, even when those permits span different permit types, departments, parcels, and
timeframes. The City seeks recommendations on how it can link and track related permits over time, including multiple downstream permits issued years later.
Response
Challenge
Address Validation: The PLCE must be able to properly find or validate the correct address or geolocation either inside or outside the City limits. Addresses can change over time due
to annexation or redevelopment, tracking correct address/parcel information for specified areas will be important for long term tracking of land use entitlements and authorizations.
Response
Challenge
Workload / Workflow Management: When permit applications are received, the City would like the PLCE system to be flexible enough to easily modify necessary reviews / reviewer steps.
In addition, the system should have the capability to manage review assignments based on existing workload, staff expertise, etc. To help monitor and manage, the PLCE system should
include dashboards for staff and managers to track application / review status, outstanding and completed tasks as well as statutory review deadlines. In addition, the PLCE should be
able to prioritize minor quick review tasks for simple permits as defined by the City.
Response
Challenge
Pavement Degradation Fees and Street Restoration Requirements: Permits for excavation in paved streets or alleys shall be subject to a pavement degradation fee along with street restoration
requirements. Newly constructed streets, reconstructed streets, or streets that have been repaved shall be considered protected streets for a period of five (5) years following construction
and shall be subject to an additional pavement degradation fee surcharge. The City would like the PLCE system to incorporate the City’s fee structure for pavement degradation fees and
track to completion payment of degradation fees and completion of street restoration requirements.
Response
Challenge
Lane Mitigation Fees: Closures for lane closure of any travel-way, sidewalk or shared use path, bike lane, parking lane, driving lane, or alley are subject to a lane mitigation fee
as established by City. Fees are calculated on number of days identified in the permit application. Days beyond that, without prior approval, are subject to overage fees. The City would
like the PLCE system to incorporate the City’s fee structure for lane mitigation fees
Response
Challenge
Bond / Warranty Management: At the conclusion of the work period impacting contributed public and private infrastructure, the City holds performance bonds for a period of two (2) years
from the date the Permit is issued, or for a period of one (1) year following acceptance of completion of the work by the City. The City currently holds financial guarantees in Community
Development, including bonds, letter of credit or cash to ensure performance by specified due dates. The City would like to understand how PLCE systems will manage this process (tracking
amounts, providing reminders, monitoring due dates, etc.) to ensure that proper inspections are conducted in a timely manner and found deficiencies can be addressed within the bond
period.
Response
Challenge
Public Notification and Transparency: At various phases of the permit application process, the City publishes key application information on the City Website. Please discuss how the
PLCE would interface with the webhost, Laserfiche, and GIS to simplify or automate that process.
Response
Licenses
Challenge
Fire Inspections. Commercial spaces require fire-specific inspections for health and life safety at certain intervals (1, 2, or 3 years, depending on the risk profile). However, certain
businesses are licensed by the State of Montana and not the City, so it becomes difficult to track those businesses for Fire to be made aware of the business initially, as well as to
monitor for periodic inspections. The City seeks recommendations on how to track businesses operating in the City, including maintaining accurate and up-to-date contact information,
and integrate them with the Fire Department’s inspection software (First Due).
Response
Code Enforcement
Challenge
Property Owner Identification: In order to properly investigate and provide notification relating to Code Enforcement complaints, it is important to have proper owner information. Owner
information can change at the County level without immediate notification to City staff or systems. The City would like to understand how the PLCE system can identify the current property
owner, and then also notify the current property owner of violation notices.
Response
Challenge
Integration with Public Safety Suite Professional: Misdemeanor code violations may require evidence that is used in court against violators, including body camera footage. Because Public
Safety Suite Professional is used to gather evidence and prosecute cases, the City is looking for the most efficient way to integrate a new code enforcement system with the requirements
of using Public Safety Suite Professional for misdemeanor cases, while eliminating as much duplicative work as possible.
Response
Attachment 4.6 – Key Contract Terms
The City anticipates negotiating a final contract with the Selected Vendor following award. To support an efficient contracting process, Respondents shall respond to each of the following
key contract terms and identify Respondent’s ability to comply with them as the City will require materially similar language in the final contract. If the Respondent cannot comply
with the following terms, the Respondent must indicate why. Failure to disclose exceptions may be grounds for disqualification.
The City understands it may have to negotiate contracts with multiple Firms the comprise the Selected Vendor. Each Firm should complete the respective table below.
To be completed by each Firm providing implementation services:
Contract / Proposal Requirement
Response
Key Personnel – The City requires assurances as to the continuity, qualifications, and performance of vendor staffing assigned to the project. Respondents shall make Key Personnel available
(Project Manager & Functional Leads) during the Discovery process to interview all proposed Key Personnel.
Except in the event of resignation, termination of employment, illness, or other circumstances beyond the Vendor’s reasonable control, Key Personnel may not be removed or replaced without
the City’s prior written approval. In the event that a Key Person is no longer available due to such circumstances, the Vendor shall promptly notify the City and propose a replacement
resource with qualifications and experience equal to or greater than those of the individual being replaced, subject to the City’s approval and at no additional cost to the City.
In addition, the City reserves the right to request the replacement of any Key Personnel whose performance, conduct, or qualifications are determined by the City, acting in good faith,
to be inappropriate or not well suited for the successful completion of the project. Upon such request, the Vendor shall propose a suitable replacement resource with qualifications
and experience equal to or greater than those of the individual being replaced, subject to the City’s approval and at no additional cost to the City.
System Configuration Limits – The Selected Vendor shall deliver the project in accordance with the City’s defined business process objectives and Functional Requirements. The Vendor
may not limit project scope due to configuration constraints except as described in the Fixed Fee Pricing Based on Milestones below. Any identified system limitations must be disclosed
during proposal evaluation or discovery and resolved within the agreed‑upon scope.
Use of Deliverables and Milestones – The City will require use of Deliverables and Milestones during implementation. A Deliverable is a tangible work product, documentation, configuration,
or other artifact produced that the City can use, rely upon, or reference after completion. Deliverables are subject to formal review and require written acceptance by the City in accordance
with the acceptance process to be defined in the SOW, and in no event shall Deliverables be deemed accepted. A Milestone represents a defined phase or sub-phase of the project and is
composed of one or more Deliverables and/or required project activities. A Milestone shall be considered achieved only upon completion and City acceptance of all required Deliverables
and completion of any associated required activities identified for that Milestone.
Fixed Fee Pricing Based on Milestones –
Implementation services shall be provided on a fixed-fee, milestone-based basis. Fixed fees shall include all labor, hours, effort, and resources necessary to complete the agreed-upon
scope and acceptance criteria. The Selected Vendor assumes responsibility for delivering agreed-upon outcomes within the fixed fee, except for limited categories of services, which
may be performed within a bounded cap (included in the fixed fee) or pre-approved not-to-exceed limits.
The following activities may be subject to a bounded cap, strictly subject to City approval and not-to-exceed limits: a) Report formatting, layout, or cosmetic changes requested by the
City after functional acceptance of report content; b) Additional training sessions, delayed training, or re-training requested by the City beyond the agreed training plan and schedule;
c) Configuration of additional workflow permutations or approval paths not identified in the agreed design documents or baseline scenarios; d) Other City-directed changes where scope
variability is outside the Vendor’s reasonable control.
All services performed under approved bounded exceptions shall be tracked separately from fixed-fee activities. The Selected Vendor shall maintain detailed records of hours expended
by resource, role, activity, and date, and shall update and share exception service burn-down reports with the City no less frequently than bi-weekly, or more frequently upon request.
The City shall have visibility into the remaining balance of approved exception effort. Further, the Selected Vendor shall notify the City in writing when consumption of any approved
bounded exception reaches seventy-five percent (75%) of the approved not-to-exceed limit. No services in excess of the approved limit may be performed without additional written authorization
from the City.
Respondents shall identify any implementation activities they anticipate may be proposed as bounded exceptions. For each anticipated exception, Respondents shall provide the following:
a) Description of the activity or service;
b) Rationale for why the activity is not appropriate for fixed-fee pricing;
c) Recommended controls or acceptance criteria to minimize variability.
Fixed Fee Pricing Based on Milestones –
Implementation services shall be provided on a fixed-fee, milestone-based basis. Fixed fees shall include all labor, hours, effort, and resources necessary to complete the agreed-upon
scope and acceptance criteria. The Selected Vendor assumes responsibility for delivering agreed-upon outcomes within the fixed fee, except for limited categories of services, which
may be performed within a bounded cap (included in the fixed fee) or pre-approved not-to-exceed limits.
The following activities may be subject to a bounded cap, strictly subject to City approval and not-to-exceed limits: a) Report formatting, layout, or cosmetic changes requested by the
City after functional acceptance of report content; b) Additional training sessions, delayed training, or re-training requested by the City beyond the agreed training plan and schedule;
c) Configuration of additional workflow permutations or approval paths not identified in the agreed design documents or baseline scenarios; d) Other City-directed changes where scope
variability is outside the Vendor’s reasonable control.
All services performed under approved bounded exceptions shall be tracked separately from fixed-fee activities. The Selected Vendor shall maintain detailed records of hours expended
by resource, role, activity, and date, and shall update and share exception service burn-down reports with the City no less frequently than bi-weekly, or more frequently upon request.
The City shall have visibility into the remaining balance of approved exception effort. Further, the Selected Vendor shall notify the City in writing when consumption of any approved
bounded exception reaches seventy-five percent (75%) of the approved not-to-exceed limit. No services in excess of the approved limit may be performed without additional written authorization
from the City.
Respondents shall identify any implementation activities they anticipate may be proposed as bounded exceptions. For each anticipated exception, Respondents shall provide the following:
a) Description of the activity or service;
b) Rationale for why the activity is not appropriate for fixed-fee pricing;
c) Recommended controls or acceptance criteria to minimize variability.
Final Acceptance – Final acceptance shall occur following go‑live and completion of a post‑implementation validation period of not less than ninety (90) days, during which the City will
verify that all SOW requirements and project criteria have been met. Final milestone payment shall be contingent upon written Final Acceptance by the City and shall represent no less
than ten percent (10%) of total implementation fees for the applicable phase.
If the City determines that there is an outstanding project requirement or configuration defect, the City will notify the Selected Vendor in writing. The Selected Vendor will resolve
all outstanding issues or provide a mutually agreeable plan for future resolution at no additional cost. Upon resolution, the City may repeat testing for provided resolution with a
period not to exceed fifteen (15) days.
Warranty – The Selected Vendor shall warrant that all services will be performed in a professional and workmanlike manner by qualified personnel and that all deliverables, including
configurations and work products, will conform to the agreed‑upon scope, specifications, and vendor responses to Functional Requirements set forth in the Statement of Work. The warranty
period shall extend for no less than forty-five (45) days following Final Acceptance. Warranty remedies shall include, at no additional cost to the City, correction of defects and reperformance
of non‑conforming services.
Hold Harmless – Selected Vendor shall hold harmless, defend, and indemnify City and its officers, employees, agents, and volunteers, from and against any and all liability, loss, damage,
expense, and costs (including without limitation costs and fees of litigation) of every nature arising out of or in connection with Selected Vendor’s performance, including but not
limited to claims related to intellectual property infringement, data security breaches, or violations of applicable laws, except to the extent caused by the sole negligence or willful
misconduct of the City.
To be completed by each Firm providing software services:
Contract / Proposal Requirement
Response
Service Level Agreements – The Selected Vendor shall meet or exceed the availability, performance, and support service levels set forth in Attachment V.3.5. Service levels shall be
contractually binding and applicable to all production environments.
Service Level Agreement Remedy – The Selected Vendor shall provide remedies for failure to meet agreed service levels, which may include service credits, fee refunds, or other remedies.
Repeated failures to meet service levels may constitute a material breach of the Agreement.
Hold Harmless – Selected Vendor shall hold harmless, defend, and indemnify City and its officers, employees, agents, and volunteers, from and against any and all liability, loss, damage,
expense, and costs (including without limitation costs and fees of litigation) of every nature arising out of or in connection with Selected Vendor’s performance, including but not
limited to claims related to intellectual property infringement, data security breaches, or violations of applicable laws, except to the extent caused by the sole negligence or willful
misconduct of the City.
To be completed by each Firm:
The City has included its standard SaaS Agreement (Appendix B) for review. Respondents are asked to review this draft agreement and identify any key exceptions, concerns, or provisions
that would require modification in order to sign a contract with the City. A full redline is not required at this stage; however, Respondents should clearly outline (including section
number references) the material terms they would be unable to accept or would propose to revise. Add additional rows as necessary.
Firm:
Section #:
Agreement Exception or Concern:
PRICING
Attachment 5.1 – Price Proposal
(See Separate Excel Spreadsheet)