biddoc.pdf

REQUEST FOR PROPOSALS

ENTERPRISE RESOURCE PLANNING

REPLACEMENT PROJECT

OTX-26-ERP-1-RFP

September 4, 2026

Request for Proposals September 4, 2026 Contract No. OTX-26-ERP-1-RFP

E-470 PUBLIC HIGHWAY AUTHORITY

ENTERPRISE RESOURCE PLANNING REPLACEMENT PROJECT

1. INVITATION TO PROPOSE.

A. Invitation.

1. The E-470 Public Highway Authority (the “Authority”) hereby invites and solicits Proposals for the Enterprise Resource Planning Replacement Project as described below, to be received by the Authority until 3:00 p.m. Mountain Time on Friday, September 30, 2026. Proposals will not be publicly opened and read.

2. A pre-Proposal meeting will be held at 11:00 A.M. on Thursday, September

10, 2026, via Microsoft Teams. The link has been provided below. Attendance at the pre- Proposal meeting is strongly recommended for all Proposers.

Microsoft Teams meeting

Join: https://teams.microsoft.com/meet/216221401995250?p=wSezCsfS52aRvt5hXY

Meeting ID: 216 221 401 995 250

Passcode: gW33RA7X

3. Proposal requirements and Proposal packages are available on the Rocky Mountain e-Purchasing site (“BidNet”) at www.bidnetdirect.com. Proposals must be submitted in full, with all required documents and should be titled “(Vendor Name) OTX- 26-ERP-1-RFP – Enterprise Resource Planning Replacement Project.” The Authority uses the Submission Form Structure within BidNet, which requires Proposers to submit each item individually based on the form structure required in BidNet on or before the submission deadline of Friday, September 30, 2026 at 3:00 PM MT. All questions, submitted pursuant to Paragraph 11.C., Interpretations, of this Request for Proposals, must be submitted by Friday, September 18, 2026 at 5:00 P.M. in Bid Net (www.bidnetdirect.com).

4. Any administrative questions regarding Proposal procedures should be directed to: Don Huff, Procurement Administrator, procurement@e-470.com.

5. Questions relating to the Request for Proposals (“RFP”) should be submitted via Bidnet.

B. Project Description.

https://nam11.safelinks.protection.outlook.com/ap/t-59584e83/?url=https%3A%2F%2Fteams.microsoft.com%2Fmeet%2F216221401995250%3Fp%3DwSezCsfS52aRvt5hXY&data=05%7C02%7Cdhuff%40e-470.com%7Cce75ebecd51849bf29d508df0529cb26%7C0dec83f08d0a4036bdaa08866d76cf19%7C0%7C0%7C639235349243133490%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=7mafYQAaoaGOgsMsnRMVAOhfCHz344idf%2BsP0YZR8zk%3D&reserved=0 http://www.bidnetdirect.com/ mailto:procurement@e-470.com

1. E-470 Public Highway Authority

The Authority is a 47-mile community-owned tollway around the eastern edge of Denver.

The Authority’s Board of Directors consists of eight voting member jurisdictions: Adams, Arapahoe and Douglas counties and the municipalities of Aurora, Brighton, Commerce City, Thornton and Parker. Affiliate, non-voting members include: Arvada, Greeley and Lone Tree, City and County of Broomfield and Weld County. Ex-officio members of the board are: Colorado Department of Transportation (CDOT), Denver Regional Council of Governments (DRCOG) and the Regional Transportation District (RTD).

The Authority provides for the operation and maintenance of the 47-mile tollway. The Authority’s 2026 annual operating budget is $99.6M and capital budget is $126.3M, with a fiscal year beginning on January 1. The Authority employs approximately 100 full-time equivalent employees, which is increasing to approximately 110 over the next year.

2. Project Scope

The project scope involves the selection, configuration, implementation, training, deployment, and post-production support of a replacement Enterprise Resource Planning (“ERP”) solution for the Authority, and coordination with Authority staff, Government Finance Officers Association (“GFOA”) consultants, process improvement teams, and other stakeholders, all as described in the Contract as detailed in the Scope of Work set forth in Attachment A to this RFP (the “Project”). The Project location is at the Authority’s offices in Arapahoe County, Colorado, with implementation activities to be performed onsite, remotely, or in a hybrid manner as approved by the Authority. Currently, the Authority has temporary offices in Douglas County, Colorado, and some implementation activities may be held at that site.

The Project is intended to replace and modernize core business applications supporting finance, budget, procurement, capital assets, vendor billing, treasury, human resources, time entry, reporting, interfaces, data conversion, implementation services, and related organizational change management activities. The Proposer shall demonstrate experience implementing integrated ERP software for public sector organizations and shall describe how the proposed solution supports leading practices, process standardization, reporting, internal controls, and long-term system sustainability. The Authority expects the selected Proposer to provide software, implementation services, project management, system design, configuration, testing, deployment, training, knowledge transfer, and post-production support in accordance with the final negotiated statement of work.

2. DEFINITIONS.

For purposes of this Request for Proposals the following terms are assigned the following meanings unless the context otherwise requires:

“Contract” shall mean a contract in substantially the form attached hereto as Attachment B to this RFP, including all attachments and exhibits thereto, including the Proposal from the selected Proposer. The anticipated term of this contract is for seven (7) years, plus three

(3) optional one (1) year extensions.

“Firm” shall mean any legal entity submitting a proposal in response to this RFP, whether individually or as part of a joint Proposal.

“Functional Requirements” shall mean the requirements identified in Attachment 2.1- Functional Requirements.

“Proposer” means the prime Contractor acting for itself and those individuals, partnerships, firms, or corporations comprising the Proposer’s team by subcontract or other agreement.

“Proposal” means the complete response of the Proposer to this Request for Proposals, including, but not limited to any statement of qualifications, technical proposal and price proposal, and supporting documentation.

“Short-Listed Proposer” shall mean a top-scoring proposal from the Written Proposal Evaluation stage identified in 5.C.4.

All capitalized terms used herein and not defined herein shall have the meanings ascribed to them as provided in the Contract.

Unless the context shall otherwise clearly require, all words used herein in the singular form shall extend to and include the plural and all words used in the plural form shall extend to and include the singular. All words used in any gender shall extend to and include all genders.

3. PROJECT.

A. Current System.

The Authority currently utilizes an ERP system (Great Plains) to manage its general ledger, asset tracking, PO Requisitions and purchase orders, treasury, customer billing, and financial reporting processes. The Authority uses NeoGov for some human capital management functions.

Payroll services have been outsourced to ADP. The Authority also uses other third-party solutions for specific needs, as well as relying on a multitude of Excel spreadsheets maintained across almost all departments to track various financial and personnel information.

The current systems allow the Authority to process its required business transactions but not always in the most efficient manner. Manual, and often duplicative, entry still occurs and is not only time-consuming but also increases the likelihood of errors. Business users desire more functionality and reliability than what is currently available. The Authority would like to explore and assess the functionality of modern ERP solutions and, more importantly, improve overall business processes and underlying system integrations. As such, the Authority made the strategic decision to assess the full ERP market before investing in a long-term ERP solution.

B. Project preparation

GFOA was selected by the Authority to guide it through the ERP selection process. GFOA is a professional membership organization representing over 35,000 public sector professionals across the United States and Canada. GFOA has no ties to any specific ERP technology.

As part of the scoping activities for this project, GFOA and the Authority worked together to review existing business processes. The Authority was divided into Process Improvement Teams (PITs) by functional area. Each PIT crew met with GFOA to identify gaps in current processes when compared to best practices and modern ERP functionality. The PIT crews will remain intact during selection and implementation.

Areas for improvement have been documented into a plan (the “Action Plan”). The Action Plan describes changes that range from changing existing practices without regard to technology to preparing for change when technology is available. Many Action Plan items and related readiness activities will be addressed in advance of implementation. Some improvement items may be technology dependent, and the Authority will rely on collaboration with and expertise of the selected Proposer to complete these activities.

C. Project Governance

The Authority’s ERP project is managed by the IT Department, with Josh Burke serving as Project Manager for the preparation of this RFP and throughout selection and implementation.

A Steering Committee has been established to provide guidance regarding Project scope, funding, and business processes and Authority policies impacted by the Project. The Project is supported by multiple PIT crews, with each PIT crew consisting of Authority stakeholders representing various stages of a functional process.

Governance Structure

Role Description Duties Project Sponsor (Authority Director)

Project advocate.

Resolves conflict within the Steering Committee or on the project and is the final decision-maker during Steering Committee impasses.

• Holds formal authority for approvals, including budget, scope, and vendor selection.

• Serve as an escalation point for unresolved issues from the Steering Committee.

• Secure necessary resources and remove obstacles that could impede the project.

• Provide high-level strategic direction for the project.

• Advocates for the Project to the Executive Team, Authority Commission, and department staff.

• Support change management across the organization.

Steering Committee (5 senior leaders for the Authority)

Provides ongoing leadership to the Project.

• Act as Project champions and make the project an organizational priority.

• Provide strategic guidance, overall direction, and prioritization for Project execution.

• Review and recommend scope changes, budgets, and cross-module decisions.

• Resolve issues and policy conflicts.

• Support change management across the organization.

Program Manager Coordinates day-to-day activities and serves as the primary point of contact for the

• Executes day-to-day Project tasks including scheduling and facilitating meetings, documentation, vendor coordination, and communications.

Authority’s vendor partners

• Tracks milestones, deliverables, and budget under the guidance of the Project Executive.

• Work closely with GFOA Consultant, manage the contract and serve as liaison to the Consultant.

• Works closely with the Project Sponsor and Steering Committee to coordinate resources to meet the project goals and objectives.

• Coordinates with Authority staff to ensure cross-functional participation and captures input for steering committee decisions.

• Manages Project communications, status reporting, and risk tracking.

• Provides updates to the Project Sponsor, Steering Committee, and regular communication Authority-wide.

• Coordinates and implements the project communication plan, ensuring consistent updates to departments and stakeholders.

• During the implementation phase of the project, this role will be the primary coordinator and communicator internal and external to the project

Technical Lead Coordinates technical internal resources throughout the project.

• Executes day-to-day Project tasks including scheduling and facilitating meetings, documentation, vendor coordination, and communications.

• Works closely with the Program Manager to coordinate resources to meet the project goals and objectives.

• During implementation phase of the Project, this role will be the Authority’s lead for the technical implementation, including involvement with Finance and HR processes and systems.

• Promotes and ensures process and technical consistency throughout PIT Crews, processes and sub-processes.

• Serves as backup for Program Manager when needed

GFOA Consultant(s) Serves as the ERP program advisor to the Authority

• Provide general guidance on ERP selection practices;

• Provide guidance on best practices in public sector;

• Support and guide the Authority’s procurement department through scoping, solicitation, selection, and contracts for the future ERP solution;

• Work with Program Manager and Technical Lead to coordinate meetings and Authority resources, resolve issues, and maintain Project plan, schedule, and budget.

Process Improvement Teams & Leads

PIT crew members have a general understanding of their functional process.

Leads provide functional expertise, coordinate stakeholders, and coordinate tasks and assignments.

• Have a level of expertise in Authority business process areas and related systems.

• Participate in process mapping of current Authority business processes and systems.

• Identify potential areas of improvement and assist with the development of future state process and system improvements, with consideration of the entire organization and not just a specific department or division.

• Make recommendations and assist in the development of procedures and guidelines to implement best practice business processes.

• Serve as Project champions within their department.

• Coordinate with SMEs (defined below) on PIT Crew to review deliverables and provide feedback.

• May participate in the Evaluation Team.

Subject Matter Experts Subject Matter Experts (SMEs) have deep knowledge of a particular process or sub-process within a functional area.

• Individuals from across the organization who are heavy day-to-day users of business process area(s);

• Provide input on current processes and policy related to their department or function;

• Assist in developing and validating requirements of new processes and/or systems.

• May participate in software demonstration and vendor selection.

4. CONTENTS OF PROPOSAL.

A. Statement of Qualifications.

1. The Authority will determine whether a Proposer is qualified to perform the services required in this Request for Proposals based on the Proposer’s experience and capabilities. The Proposer shall provide the necessary experienced personnel, facilities and resources to support the services and activities required by this Request for Proposals.

2. The Proposer shall furnish a description of the legal entity and documentation regarding formation of the entity or entities (corporation, joint venture, partnership, or other association) proposed to perform the services required under this Request for Proposals. If an Association or joint venture, the Proposer must state which entity is primarily responsible for the Work, and further identify the prime Firm, software provider, implementation partner, subcontractors, and the role of each participant. The Proposer must be authorized to do business in the State of Colorado and comply with all applicable laws and regulations of the State of Colorado. The Proposer shall provide complete documentation of proper incorporation, registration, licensing, certification, etc.

as required for the entity to legally perform the services required.

3. The Proposer shall provide a written narrative which describes the

Proposer’s previous project experience as discussed below. The narrative shall describe the Proposer’s experience during the past five (5) years in performing the variety of Work required for this Project, quality of the work performed, significant successes, awards earned and improvements accomplished. The Proposer shall briefly describe the circumstances surrounding any work completed which had any special or unique requirements. For this Project, the narrative shall also describe the Proposer’s experience implementing ERP solutions for public sector entities, including comparable implementation size, scope, complexity, modules implemented, project duration, project outcomes, and lessons learned.

4. The Proposer shall complete Attachment 1.6 with three (3) professional references and the remainder of the information requested on Attachment 1.6. The Proposer shall be deemed to grant approval to the Authority to contact all persons and entities whose identities are provided and ask questions deemed relevant by the Authority.

B. Financial Statement.

1. The Proposer shall provide a narrative which describes the Proposer’s business structure and financial viability. The Proposer and each joint venture and Association member, if any, shall provide its two most current financial statements (the latest one not more than 12 months old). The financial statement shall be audited by an independent certified public accountant. The financial statement shall include, but not be limited to, an Opinion of the Certified Public Accountant on the statement(s), a Balance Sheet, an Income Statement, a Statement of Cash Flows, Notes to Financial Statement(s), a Statement of Direct (Operational) Costs and a Statement of Indirect (General and Administrative) Costs and other financial information necessary for the Authority to determine financial adequacy of the Proposer. For software-as-a-service or hosted solutions, the Proposer shall also provide information sufficient for the Authority to evaluate financial viability, software product maturity, hosting responsibility, service continuity, data security, cybersecurity insurance, and long-term support capacity.

C. Price Proposal.

1. The Proposer shall submit a Price Proposal that provides the Authority with an offer to perform the Work for the Project for which this Request for Proposals is issued.

The Price Proposal shall include all software licensing or subscription costs, implementation services, project management, integrations, conversions, training, travel, hosting, support, maintenance, optional services, third-party products, and any other costs necessary to deliver the proposed solution. The Price Proposal shall distinguish one-time implementation costs from recurring costs and shall identify any assumptions, exclusions, optional costs, escalation factors, renewal terms, and milestone-based payment assumptions.

2. A Price Proposal will be considered irregular and may be rejected if it shows omissions, alterations of form, additions not called for, conditional or unauthorized alternate bids, irregularities of any kind, or if the unit prices are obviously unbalanced, either in excess of or below the reasonable cost analysis values.

3. Proposers shall submit a Price Proposal using the format provided in

Attachment 5.1 – Price Proposal to reflect the total price of software, services, and any other associated fees. To ensure proper evaluation:

i. All pricing must be submitted as fixed fee by milestone. Costs listed as “to-be-determined” or “estimated” will not be evaluated. All costs and prices shall be quoted in U.S. dollars.

ii. Proposers should include all software modules and state any limitations on module use. If no limitations are listed, the Authority will consider that pricing is based on full enterprise-wide access for the Authority.

iii. The Price Proposal must identify major milestones as part of the Project and the associated costs to be invoiced upon completion of each milestone. Please provide a schedule of all payments necessary to complete the proposed scope.

Additional details may be provided to further explain deliverable or task costs.

iv. Proposers must submit implementation costs as fully loaded rates that include all necessary travel or other expenses.

v. Proposers shall include any assumptions made about the Price Proposal and provide clarity on what actions would cause an executed contract to be delivered at a price higher than that in the Price Proposal.

4. To support the development of accurate and competitive fixed‑fee pricing, the Authority has provided a set of key data metrics in Attachment C to assist Proposers in understanding the relative volume, scale, and complexity of the Authority’s current environment and anticipated implementation effort. Proposers shall consider the information in Attachment C in their fixed fee Price Proposal.

D. Functional Requirements

1. The Functional Requirements describe the software scope of the overall

Project and the requirements for each functional area. Each proposal shall contain responses to the Functional Requirements that shall identify the scope of system configuration that is being proposed for the Project.

2. The Functional Requirements are a material component of the Proposal evaluation and will allow the Authority to determine if a Proposer can adequately support the Authority in meeting its Project goals identified in the Scope of Work attached to this RFP as Attachment A. Proposers 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 Proposer from contention. However, failure to accurately portray a software’s capability may result in disqualification. If Proposers are unsure or unclear on the description of a specific requirement, please send a question or request for clarification by the deadline noted in Section 1.

3. Please see Attachment 2.1– Functional Requirements. Instructions for completing the responses to the functional requirements are included in the attachment.

E. Technology and System Capabilities

1. The Proposer shall provide a Technical Proposal which shall demonstrate the Proposer’s understanding of the Work required by the Project for which this Request for Proposals is issued and shall discuss how this Work will be completed. The Technical Proposal shall define the responsibility and accountability for the functions provided by specific key personnel within the organization and their time commitments to the Project.

The Technical Proposal shall specifically address the Authority’s ERP functional requirements, technology and system capabilities, reporting capabilities, interface approach, conversion approach, implementation methodology, training approach, organizational change management approach, service level commitments, and post-production support. The Technical Proposal shall identify the proposed solution architecture, including whether the solution is software-as-a-service, hosted, on-premises, or hybrid; the responsibilities of the Authority and Proposer; information security controls;

disaster recovery approach; uptime commitments; and data ownership provisions. The Technical Proposal shall address each major process area in scope, including accounting, budget, grantee management, procure-to-pay, capital assets, vendor billing, treasury, human resources, time entry, reporting, interfaces, data conversion, implementation, and project management.

2. Proposers shall provide a narrative description of the proposed ERP solution’s technology architecture and system capabilities, including any technical requirements necessary to operate, secure, and support the system. This section should describe the solution at a level sufficient for the Authority to understand the overall technological approach, operational implications, and long‑term sustainability of the system. Proposers must clearly describe how their proposed solution meets the Authority’s requirements and supports reliable, secure, and efficient operations in a public‑sector environment.

3. In addition to completing the relevant attachments, Proposers should address areas including but not limited to:

i. Hosting and deployment model, including specific hosting services, deployment options (e.g., cloud‑based, SaaS), and any assumptions regarding environment management.

ii. Technology infrastructure, including system architecture, supported platforms, database type, and technical dependencies.

iii. Application and data security, including security controls, compliance standards, and data protection measures

iv. User setup, authentication, and access management, including role‑based access, authentication methods, and user administration processes

v. System workflows and transactions, including how business processes are supported, configured, and controlled within the system

vi. Audit and logging capabilities, including system auditing, transaction tracking, and monitoring features

vii. Application support services, including service desk support, escalation procedures, and support hours.

viii. System reliability and availability, including service level commitments and monitoring practices

ix. Scheduled maintenance and notifications, including maintenance windows, upgrade processes, and user communications

x. Hosting service exit strategy, including data portability, transition support, and termination considerations

xi. Backup and data retention, including backup frequency, retention policies, and recovery procedures

xii. Disaster recovery and business continuity, including recovery objectives, failover capabilities, and testing practices

4. Proposers must also complete Attachment 3.3 – Solution Information, Attachment 3.4 – System-Wide Software Capabilities, and Attachment 3.5 – Proposed Service Level Agreement.

F. Reporting

1. Reporting is a key component of Authority management, and the Authority will rate favorably systems that have an intuitive, no- or low-code report design, as well as systems that provide tools for standard public sector reports (e.g., ACFR financial statements, budget to actuals, trial balance, etc.). The Authority also wishes to create customized reports and dashboards using vendor-available tools or other third-party solutions like SQL or Power Query. Proposers shall describe their overall approach to delivering reporting and analytics capabilities within the proposed ERP solution, including capabilities for dashboards, source data drilldown, and report sharing and exporting.

2. Proposers should describe how reporting requirements are analyzed, designed, configured, tested, and validated as part of the implementation. This description should include how standard reports, dashboards, and ad hoc or self service reporting capabilities are provided, and how users are enabled to access and analyze data without reliance on vendor intervention or custom development, where feasible.

3. The Authority has identified critical reports important to the organization.

For each report identified in Attachment 3.1, Proposers shall indicate whether the report can be provided and describe the method by which it would be delivered. All reports for which a Proposer indicates an affirmative response are expected to be available, tested, and accessible to Authority 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.

4. Proposers shall provide training, user manuals, and documentation that clearly describe the structure of underlying tables, relationships, and data elements used for reporting. This documentation should enable Authority staff to create, modify, and maintain custom reports and dashboards using SQL or Power Query, without reliance on vendor intervention.

G. Interfaces

1. Proposers shall describe their overall approach to designing, developing, testing, deploying, and supporting interfaces between the proposed ERP solution and third‑party systems. The Authority recognizes that Proposers may utilize different architectures, tools, and methodologies, but Proposers must demonstrate a structured, proven approach suitable for public‑sector ERP implementation.

2. Submitted Proposals shall also describe the Proposer’s design standards, development lifecycle, testing protocols, and deployment practices, including how interfaces are validated to ensure accurate, secure, and reliable data exchange, as well as the tools, platforms, or middleware used to develop and manage interfaces.

3. Additionally, the Proposal should describe the respective roles and responsibilities of the Proposer, the Authority, and any third‑party vendors involved in interface development, as well as how interfaces are conducted. Proposals should describe the documentation to be provided for interfaces and the approach to knowledge transfer to Authority staff to support ongoing maintenance and troubleshooting following go live.

4. For each interface identified in Attachment 3.2, Proposers shall indicate whether the interface can be supported and describe the proposed integration approach.

Any interface for which a Proposer provides an affirmative (“Yes”) response shall be considered in scope and included in the fixed fee price proposal.

5. If additional interfaces are proposed, please add them and indicate how they will be implemented. The interface plan proposed by the Proposer shall be included in the fixed fee price proposal. The Authority acknowledges that additional interfaces not included in the attachment may require a change order and an additional fee.

H. Implementation Team and Approach

1. Implementation Team

The Proposer shall provide organizational charts which show the entire proposed organizational structure, including the relationship of the corporate and/or division organization. A description of the Proposer’s internal lines of responsibility, and the interface relationships with the Authority, on-site contractors and any subcontractors shall be shown.

The Proposer shall submit a management and staffing plan for the Contract which shall include an organization chart naming key personnel and identifying all proposed contractors and subcontractors, if any. The plan shall completely describe the staffing and management approach, resources and staffing to be utilized and shall specifically address continuity of services. The plan shall provide tasks, a time schedule for performance of these tasks and procedures for evaluating tasks performance. This plan shall discuss how proper coordination and exchange of information will be accomplished. The Proposer shall provide resumes and experience summaries of key personnel assigned to the Authority.

The Proposer shall provide a chart showing the availability of the key personnel including current assignments and assignment termination dates and percentage of their time assigned to this Project. Those personnel identified in the Proposal shall be available in accordance with the proposer’s staffing plan. Any changes in the personnel may be cause for disqualification. The management and staffing plan shall identify the proposed project executive, project manager, functional leads, technical leads, conversion leads, integration leads, training leads, change management leads, support resources, and any subcontracted resources assigned to the Project. The plan shall include a proposed implementation work plan, major milestones, sequencing assumptions, dependencies, Authority resource expectations, governance approach, issue escalation approach, risk management approach, testing strategy, and transition-to-support strategy.

Proposers shall also complete Attachment 4.1 – Work Effort. Follow the instructions on the first tab of the attachment to complete the Proposer Staffing and Client Staffing tabs. For each row, please indicate the Phase, Resource Type, Role, and number of hours per month the resource is expected to be utilized.

2. Implementation Approach

Proposers shall describe their overall approach to implementing the proposed ERP solution, including the methodology, structure, and governance used to deliver a successful public‑sector ERP implementation, including considerations for the implementation scope.

The Authority expects and Proposers should describe their experience with an implementation to follow a deliverable‑based approach, with clearly defined deliverables, acceptance criteria, and review cycles, with all major deliverables subject to Authority review and formal acceptance. Additionally, the Authority expects Proposers to incorporate appropriate stage gates or phase checkpoints, including readiness assessments, to validate that agreed‑upon objectives, deliverables, and acceptance criteria have been met before proceeding to subsequent phases or milestones.

Proposers shall describe how their proposed implementation approach accounts for

Authority resource availability and constraints, including staffing capacity, competing priorities, and the operational realities of a public‑sector environment. Proposers should identify the types and level of Authority resources required throughout the implementation.

Proposers shall also identify anticipated implementation risks, as the Authority is particularly interested in understanding how Proposers proactively identify and manage risks and adjust project plans as conditions change.

The implementation approach should also provide a proposed project timeline and any key considerations that could impact that timeline, as well as describe the Proposer’s approach to on-site vs remote implementation activities and events.

Proposers should also complete Attachment 4.2 – Deliverables Expectations, Attachment 4.4 – Project Management Expectations, Attachment 4.5 – Challenges to Solve, and Attachment 4.6 – Key Contract Terms.

3. Data Conversions

Proposers should describe their overall approach to data conversion from the

Authority’s existing systems into the proposed ERP solution. The narrative should describe how data conversion activities are planned, executed, tested, and validated throughout the implementation. Proposers should address how data is identified, extracted, mapped, transformed, and loaded into the proposed system, and clearly explain the Authority’s role in providing data extracts, data cleansing, data validation, or data governance decisions.

In addition to converting data into the new ERP, the Authority would also like to understand the Proposer’s experience and approach to managing existing system data that is not being converted (e.g., data warehouse, etc.).

Proposers shall complete responses to the conversion requirements in Attachment

4.3 – Data Conversions. If the Proposer proposes additional items to be converted, please add them to the attachment. Instructions for completing the responses to the functional requirements are included in the attachment. The conversions the Proposer determines to be in scope shall be included in the fixed fee price proposal.

I. Proposal Submission Requirements.

1. Proposals by corporations must be executed in the corporate name by a corporate officer, accompanied by evidence of authority to sign, and the corporate seal must be affixed and the signatures attested by the secretary or an assistant secretary. The corporate address and state of incorporation shall be shown below the signature.

2. Proposals by partnerships must be executed in the partnership name and signed by a partner accompanied by evidence of authority to sign and whose title must appear under the signature, and the official address of the partnership must be shown below the signature.

3. Proposals by sole proprietorships and joint ventures shall be signed by each proprietor or by each Firm or participant in the joint venture or by an authorized agent of each participant or Firm. In the case of a joint venture where two or more entities or Firms are submitting a joint Proposal, all participating entities or Firms must sign the joint Proposal. The joint Proposal shall further identify the primary point of contact taking the lead role in the RFP process and which entity or Firm will be responsible for the overall implementation of all partners included in the joint Proposal.

4. The names of all persons signing Proposals must also be legibly printed or typed below the signature. A Proposal by a person who affixes to his signature the word “president,” “secretary,” “agent,” or other designation without disclosing his principal may be held to be the Proposal of the individual signing. Evidence of the authority of the person signing shall be furnished.

5. The Proposal shall contain an acknowledgment of receipt of all addenda, the numbers of which shall be inserted on the Proposal.

6. No alterations in Proposals, or in the printed forms therein, by erasures, interpolation, or otherwise will be acceptable unless each such alteration is signed or initialed by the Proposer; if initialed, the Authority may require the Proposer to identify any alteration so initialed. No alteration in any Proposal shall be made after the time designated for the receipt of Proposals.

7. The address to which communications regarding the Proposal are to be directed must be shown, as well as contact information for legal counsel for the Proposer, as applicable.

8. Each Proposal must include all information and documents required by this

Request for Proposals. Failure to furnish all required information and documents may result in the rejection of the Proposal.

9. For this Project, each Proposal must include the required ERP response attachments, functional requirements responses, technology and system capability responses, implementation approach responses, pricing forms, service level responses, exceptions to the Contract or software-as-a-service agreement, and any other attachments required by the Authority in BidNet.

10. Attachments shall not be altered. Alterations to attachments or a failure to follow the guidelines below may result in the proposal being deemed non-responsive.

i. Proposers shall not change the format or structure of attachments and shall only provide information where indicated.

ii. Proposers shall not change the file name of any attachment but may append the file name to include the Proposers name (e.g., FileName_CompanyABC).

iii. Microsoft Excel attachments should be submitted as Excel files.

11. Proposers should use the following checklist to ensure all submittals and attachments are included in the Proposal. Proposers must organize and present their Proposal materials in the same order as presented in the Submittal Checklist below and include page numbers. A failure to include all components or exceeding the maximum page limit may result in the Proposal being deemed non-responsive. Attachments are excluded from the page limit, but please note that any attachment that allows narrative response should be answered as concisely as possible. See below for a table listing the required attachments for each Proposal.

Submittal Checklist Response Section Relevant Attachment Section 1 – Proposer Information Title Page Table of Contents Executive Summary Proposer Team Attachment 1.1 – Signature Page

Attachment 1.2 – Nondiscrimination and Equal Pay Affirmation

Attachment 1.3 – Proposer Statement Attachment 1.4 – Software Background Attachment 1.5 – Professional Services Background Attachment 1.6 – Reference Form Section 2 – Functional Requirements Functional Requirements Attachment 2.1 – Functional Requirements Section 3 – Technology & System Capabilities Reporting Attachment 3.1 – Reporting Interfaces Attachment 3.2 – Interfaces Technology & Capabilities Attachment 3.3 – Solution Information

Attachment 3.4 – System-Wide Software Capabilities Attachment 3.5 – Proposed Service Level Agreement Section 4 – Implementation Approach Implementation Team Attachment 4.1 – Work effort Implementation Approach Attachment 4.2 – Deliverables Expectations Attachment 4.4 – Project Management Expectations Attachment 4.5 – Challenges to Solve Attachment 4.6– Key Contract Terms Data Conversions Attachment 4.3 – Data Conversions Section 5 – Pricing Price Proposal Attachment 5.1 – Price Proposal

12. The Proposal narrative shall not exceed 50 pages. In addition, Proposers shall include the required attachments, which shall not exceed 25 pages in total when submitted in Microsoft Word format. Microsoft Excel attachments are required, as applicable, and are excluded from these page limitations.

13. The Proposal should include a title page with the RFP name, name of the

Proposer, address, contact information and date.

14. The Proposal shall include an Executive Summary which should be limited to a brief narrative summarizing the Proposal and within the page limit, including why the Proposer is best suited to complete the project for the Authority while helping it achieve its project goals.

15. Proposals shall be submitted via BidNet, in accordance with section 1.A.3.

16. Proposals shall be submitted to the designated location prior to the time and date for receipt of Proposals indicated herein, or the modified time and date indicated by addendum. Proposals received after the time and date for receipt of Proposals may be returned unopened. Proposer shall assume full responsibility for timely delivery at the location designated for the receipt of Proposals.

17. Oral, telephone, telegraph, facsimile, or physical Proposals are invalid and will be rejected

18. No Proposer may submit more than one Proposal for each portion of the proposed Work. Multiple Proposals under different names will not be accepted from one Proposal.

5. NOTIFICATIONS, REQUIREMENTS AND CONDITIONS.

A. Proposer Notification.

1. Proposers are hereby notified that the Authority’s contracts are not subject to any of the formal processes, procedures, or legal requirements of the Construction Bidding for Public Projects Act, Sections 24-92-101, et seq., Colorado Revised Statutes.

2. Certain of the Authority’s contracts are subject to the Keep Jobs in Colorado

Act of 2013, part 1 of article 17 of title 8, Colorado Revised Statutes, in which case the Authority will consider preferences for employment of Colorado labor as required by the Keep Jobs in Colorado Act of 2013.

3. Evaluation of Proposals and, if the Authority so chooses, selection of a successful Proposer shall be performed in a manner which the Authority determines, in its sole discretion, to be in the Authority’s or public interest.

4. The Authority may evaluate Proposals through one or more stages, including compliance review, written proposal review, software demonstrations, implementation interviews, discovery sessions, reference checks, pricing review, best-and-final clarification, and contract negotiations.

5. Evaluation may include, without limitation, responsiveness to functional requirements, technical and system capabilities, implementation approach, project team qualifications, public sector ERP experience, software demonstrations, discovery results, service levels, pricing, contractual exceptions, and overall value to the Authority.

6. If requested by the Authority, Short-Listed Proposers shall participate in scripted software demonstrations, and implementation interviews at no cost to the Authority.

7. Proposers shall have no right to any administrative, legal, or other protest, appeal, or challenge of any matter or grievance in connection with the solicitation or award of any contracts, including the evaluation of Proposals and selection of a successful Proposer. In submitting a Proposal, each Proposer acknowledges that it shall bear all costs associated with the preparation and submission of such Proposal and that it shall under no circumstances have any right to recover the costs of such Proposal preparation from the Authority or any other costs, expenses, or damages in the event such Proposal is not accepted by the Authority.

8. In addition to the basis for rejection set forth in this Request for Proposals, the Authority reserves the right to reject any or all Proposals, to waive any and all informalities or technicalities, or to advertise for new Proposals if the Authority determines, in its sole discretion, that such actions are desired.

B. Examination of Contract and Proposal Documents.

1. Before submitting a Proposal, each Proposer must (a) examine all Proposal documents and the Contract thoroughly; (b) familiarize itself with federal, state, and local laws, ordinances, rules, and regulations that may in any manner affect cost, progress, or performance of the proposed Work; and (c) study and carefully correlate Proposal’s observations with the Contract and Proposal documents.

2. The submission of a Proposal will constitute an incontrovertible representation by the Proposer that he has complied with each requirement of this Request for Proposals and that the Contract is sufficient in scope and detail to indicate and convey understanding of all terms and conditions for performance of the proposed Work.

3. If a Proposer discovers an error or omission in the Proposal documents or the Contract, the Proposer shall immediately notify the Authority and if the Authority agrees that an error or omission has been made, it may make any necessary revisions.

C. Interpretations.

1. All questions about the meaning or intent of the Contract or this Request for

Proposals prior to Proposal submittal are to be submitted on BidNet. If you have issues with uploading your questions, please contact BidNet at 1-800-835-4603, for all technical and customer support. Any Bidder/Proposer submitting questions shall be responsible for ensuring that the questions are delivered no later than Thursday, August 20, 2026, as identified in Section 1. A., Invitation to Propose, of this Request for Proposals. Any replies that the Authority elects to make will be made through the issuance of written addenda.

Questions received after the cutoff date for receipt of questions will not be answered. Only questions answered by written addenda will be deemed to interpret the Contract or this Request for Proposals. Oral and other interpretation or clarifications will be without interpretive effect. Addenda will be posted to BidNet or e-mailed to all parties recorded by the Authority as having received this Request for Proposals. No addenda will be issued after the proposed date of final addenda, except an addendum, if necessary, postponing the date for receipt of Proposals or withdrawing the request for Proposals.

i. BidNet limits the characters available to input for the Authority to respond to each question. For this reason, multiple questions may not be submitted as a single question, as the Authority is unable to respond to multiple questions in the space provided. Because of this limitation, multiple questions per entry will not be answered. A multi-part question containing an initial question and a follow-up is the exception to this rule.

2. The Authority may cancel this RFP or make any change to the RFP and/or

Contract Documents at any time, and any change to the RFP or the Contract Documents made prior to the opening of Proposals will be issued by the Authority by addendum.

D. Basis for Rejection. Proposals will be considered irregular and may be rejected for any of the following reasons:

i. If the Proposal is not signed.

ii. If there are unauthorized additions, conditional or alternate Proposals, or irregularities of any kind which may tend to make the Proposal incomplete, indefinite, or ambiguous.

iii. If the Proposal fails to acknowledge in the Proposal the receipt of all addenda current on the date of opening of Proposals.

iv. If the contractor submitting the Proposal is affiliated with another contractor that has submitted a Proposal on the same public project.

v. If the Proposer has been asked in writing to show why it should not be found in default on an Authority contract.

vi. If the Proposal is in any way nonconforming, nonresponsive, or conditional.

vii. Any other reason which the Authority, in its sole discretion, deems to be in its best interests.

E. Modification and Withdrawal of Proposals.

1. Withdrawal of Proposals prior to Proposal Submittal Deadline. Proposals submitted early (prior to the deadline established for submittal of Proposals) may be withdrawn by a potential Proposer prior to the Proposal submittal deadline.

Withdrawal shall be effected by a Proposer, or its authorized representative submitting a written withdrawal request signed by Proposer or its authorized representative, via email to procurement@e470.com.

2. Withdrawal and Modification of Proposals following Proposal Submittal Deadline.

i. Authority Identified Proposal Mistakes/Irregularities. If the Authority reviews a Proposal and believes a mistake has been made by a Proposer, the Authority may seek confirmation of the Proposal’s amount and content from the Proposer. If the Proposer fails to provide confirmation, in writing, within forty-eight (48) hours of the Authority’s request, the Proposal may be rejected by the Authority as non-conforming or deficient.

ii. Proposal Alleged Mistakes. Mistakes alleged by Proposers following the Proposal submittal deadline, and prior to Contract award, shall be alleged by the Proposer’s filing of a written “mistake statement.” The mistake statement shall describe in detail the nature of the mistake, potential consequences flowing therefrom, and shall suggest corrective action. The Authority will review a mistake statement and, in its sole discretion, may grant or deny the requested relief in the best interest of the Authority.

The filing of a mistake statement does not in any way guaranty that the opportunity to correct the mistake will be granted by the Authority.

mailto:procurement@e470.com

3. Except as expressly authorized by this Section, Proposals may not be withdrawn once they have been submitted to the Authority.

6. AWARD AND EXECUTION OF CONTRACT.

A. After the Proposals are opened, they will be evaluated by the Authority.

B. An Evaluation Committee has been…