HomeMy WebLinkAbout26 - Instructions - Enterprise Resource Planning Software & Implement (9)
/
Request for Proposals (RFP)
Enterprise Resource Planning (ERP) Software and Implementation Services
City of Bozeman
Bozeman, MT
City of Bozeman
PO Box 1230
Bozeman, MT 59771-1230
ATTACHMENT FORMS (Word Format)
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 ERP delivery (by region):
Estimated percentage of ERP delivery resources located in US vs 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 ERP 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 ERP implementations and describe how each will be specifically applied to this project:
1
2
3
Size
Number of ERP implementation projects completed in the past five (5) years:
Number of ERP implementations currently in progress:
Consulting Team
Total size of ERP consulting practice: (excluding non-ERP consultants)
Average annual attrition rate (# of leaves / average # of employees) of ERP consultants:
Proposed project team size:
Average ERP 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)
Financials
☐General Ledger☐
Project / Grant Accounting☐Budgeting☐Purchasing☐Accounts Payable☐Solicitation Management☐Contract Management☐Asset Management☐Inventory☐Work Orders☐Accounts Receivable☐
Point of Sale☐Treasury☐Grants ManagementHuman Capital Management
☐Position Management☐
Recruitment☐Employee File / Management☐Scheduling (Basic)☐Time Entry☐Leave Management☐Payroll☐
Benefits Management☐Employee Reimbursement☐Risk Management ☐Learning Management☐
FMLA ManagementDeployment☐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 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.
Though this component is part of the Blind Review, please do include the Module / System name in the appropriate column. This will be redacted during the Blind Review but will be important
for the City to know as the evaluation process progresses.
TECHNOLOGY AND SYSTEM CAPABILITIES
Attachment 3.1 – Reporting
(See Excel Attachment 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 3.2 - Interfaces)
For each interface identified in Attachment 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:
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):
Describe how the system ensures that ACFR and Budget reports—both system generated and exported formats—meet accessibility standards:
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:
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 exporting, importing, and inputting templates to enter routine, recurring, or frequent transactions:
Describe the system’s ability to support the uploading of transactions / data from third-party systems, including supported formats and validation rules:
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., vendor file, POs):
Describe how corrections or reversals of posted transactions are handled:
Workflow
Describe how workflow rules are defined and configured, including role‑based, amount‑based, and attribute‑based (e.g., fund, department, union):
Describe support for multi‑level and parallel approvals:
Describe how workflow changes are governed:
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:
Describe reporting available for workflow bottlenecks and approval cycle times:
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 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 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 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
ERP environments and best practices.
Accounting
Challenge
Historical Data: The City understands that all of its accounting data and supporting documentation will not be converted as part of this project. However, it is interested in understanding
how Respondent’s suggest entities manage their historical data that is not converted, especially for data still subject to open records requests.
Response
Budget
Challenge
Biennium Budgeting: The City adopts a biennial budget in which Year 1 serves as the annual operating budget. Due to state law requirements to adopt an annual budget, the City must subsequently
adopt the Year 2 budget, including a reconciliation of Year 2 with the budget originally adopted in the prior biennium. The City is seeking Respondents’ recommendations on how their
solution can streamline and improve this process, including support for multi-year and annual budget adoption, reconciliation between budget cycles, and integration of the CIP and the
City’s three‑year staffing plan.
Response
Procure to Pay
Challenge
Aggregate Purchase Limits: The City must ensure that all purchasing activity complies with established competitive bidding thresholds and procurement policies. Under current processes,
departments may inadvertently or intentionally divide a larger purchase into multiple smaller requisitions or purchase orders (“purchase splitting”) to avoid triggering formal solicitation
requirements. The City seeks on how the system can prevent purchase splitting and ensure adherence to competitive bidding thresholds.
Response
Challenge
Public Notification: To support transparency and meet the requirements of State Law, the City posts contracts, purchase orders, and payment data to its public facing website. The City
seeks a Respondent to assist the City in achieving these transparency needs.
Response
Challenge
Contractor Receiving: The City allows contractors (non-employees) to order supplies on its behalf for certain services (e.g., janitorial) and receive them for City use. The City seeks
recommendations on how to allow contractors to use components of the purchasing functionality while maintaining appropriate workflow approvals.
Response
Challenge
Employee Reimbursement: The City seeks Respondent best practice recommendations for employee reimbursements (i.e., through payroll or AP), including travel reimbursements, claw back
of travel advances as needed, and other ad-hoc employee reimbursements.
Response
Challenge
Employee Purchase: The City allows employees to purchase personal IT equipment and wellness benefits through the City’s purchasing agreements. The City purchases the item, and the employee
reimburses the City, either through a single payroll deduction or a payment plan. The City seeks recommendations on the most efficient way to facilitate this repayment, particularly
when using a payment plan and automatic payroll deductions.
Response
Asset Management
Challenge
GIS Integration: The City maintains a centralized geospatial database that will serve as the system of record for all geospatial data 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 ERP solution can successfully integrate with the City’s GIS system 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 ERP and GIS environments.
Response
Challenge
Contributed Capital: As a growing City, infrastructure is often donated as part of the development process. The City has challenges managing contributed capital as it relates to additions,
valuations, and replacements. Respondents should describe their approach to managing contributed capital, especially as it relates to capital asset reporting.
Response
Customer Billing
Challenge
Special Assessments: The City bills special assessments to property owners within certain defined geographic areas (e.g., lighting districts or improvement districts). Assessments may
be calculated based on various property‑specific attributes (such as square footage or linear frontage) and are typically billed once or twice per year. The existing ERP and permitting
system (NaviLine) is the City’s primary source for parcel information including square footage. Property owners may make periodic payments over time or elect to pay the assessed amount
in a lump sum.
The City recognizes that management of special assessment billing may fall within either an ERP or a Utility Billing solution, depending on system capabilities and configuration. The
City is seeking Respondents’ recommendations on how their proposed solution would support the calculation, billing, payment tracking, and payoff of special assessments, including how
these processes would integrate with other City financial and customer billing functions, if applicable.
Response
Treasury
Challenge
Disparate Payment Systems: The City has multiple systems for payments. For example, payments of parking permit require the transaction to take place on a separate, dedicated register.
This results in a suboptimal customer experience as a customer at the treasury window would have to make two payments to pay for their parking permit and their utility bill. This can
also lead to reconciliation challenges.
The City is requesting vendor recommendations and best practices on how to streamline and consolidate the customer payment experience across all services, and how to reduce reconciliation
challenges through improved integration, standardized payment workflows, or unified payment platforms.
Response
Human Resources
Challenge
Staffing Plan: The City has a three-year staffing plan process and currently tracks staffing requests using a combination of forms and spreadsheets. The City is interested in solutions
for efficiently managing, tracking, and approving staffing requests over a multi-year period.
Response
Payroll
Challenge
Leave Tracking: The City currently relies on a manual process to track certain leave types, such as FMLA, Paid Parental Leave, Military Leave, and Personal Days. The City seeks solutions
for a more efficient, streamlined process for tracking specialized leave types that improve accuracy, reduces administrative burden, and enhances transparency between Human Resources,
employees, and supervisors.
Response
Implementation
Challenge
Procurement Change Management and Training: Effective change management will be essential to ensure long-term adoption of a modern ERP purchasing module. Currently, purchasing processes
vary significantly across the organization, and many departments operate with considerable flexibility in how purchases are initiated, approved, and tracked. System-supported controls
and standardized workflows are limited.
Implementing a modern ERP purchasing module will introduce more structured and transparent processes for requisitions, approvals, and procurement activities. These changes will represent
a significant shift for many staff and departments that are not accustomed to formalized procurement workflows or system-driven purchasing controls.
Successfully transitioning to these standardized practices will require thoughtful change management, communication, and training to help staff understand the purpose of the new processes,
adapt to revised roles and responsibilities, and use the system effectively. The City seeks vendor recommendations for an approach to change management and training that will support
organization-wide adoption of consistent purchasing best practices.
Response
Challenge
Timing with Utility Billing and Permitting: The City will be implementing an ERP system, a Utility Billing system, and a Permitting/Community Development system through separate competitive
procurements. While a single vendor may provide more than one of these solutions, it is likely that different vendors will be selected. Please describe your high‑level recommendations
for how the City should approach sequencing these implementations and coordinating integrations among them. In your response, highlight key considerations, dependencies, risks, and
any best‑practice strategies you believe the City should take into account based on your experience with multi‑system, multi‑vendor environments.
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 sixty (60) 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 one hundred twenty (120) 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 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)