RFP Requirements
Capital Planning Software RFP Requirements & Sample Scope of Work
A starting-point requirements list and sample scope of work for a capital planning software RFP — organized into functional, technical, integration, accessibility, security, and procurement requirement areas you can adapt for any asset class.
Quick answer. A capital planning software RFP should require cross-asset project prioritization, deterioration forecasting, multi-year scenario budgeting, integration with your existing EAM/GIS, defensible audit-ready outputs, WCAG 2.1 AA accessibility, a documented security posture, and a clear procurement path. Use the requirement areas below as adaptable scope-of-work language.
How to use these capital planning software RFP requirements
These are model requirements for a capital planning software RFP — a starting point you adapt to your agency, not a copy-paste contract. Each table below is one requirement area with sample language you can lift into your scope of work and scoring rubric. The requirements are asset-agnostic; add asset-specific sections (pavement, bridges, water, airport pavement, facilities) as supplements.
Anti-bias note for evaluators. These requirements are written to be vendor-neutral and standards-based. They map to the criteria in our how-to-evaluate guide so your scoring rubric and your scope of work stay aligned. Verify any vendor’s response against independent sources and a demonstration on your own data.
Functional requirements: what the capital planning software must do
Functional requirements define the core planning capabilities. These are what distinguish a true capital planning system from a work-order or budgeting tool, and they should carry the most weight in scoring.
| Requirement | Sample RFP language | Priority |
|---|---|---|
| Cross-asset prioritization | The system shall prioritize candidate capital projects across multiple asset classes within a single budget-constrained optimization, producing a ranked, fundable project list. | Must-have |
| Deterioration forecasting | The system shall forecast future asset condition using condition, age, environment, and failure-history inputs, and shall document the modeling approach and its validation. | Must-have |
| Scenario / what-if budgeting | The system shall model multiple funding scenarios (including constrained and unconstrained needs) and show projected network condition over a multi-year horizon for each. | Must-have |
| Multi-year CIP output | The system shall produce a defensible multi-year capital improvement plan covering at least three (preferably five or more) years, consistent with GFOA CIP best practice. | Must-have |
| Risk-based prioritization | The system shall support risk-based prioritization using probability and consequence of failure, consistent with risk-based asset-management practice (for example, MAP-21 §1106 for transportation assets). | Must-have |
| Explainability of rankings | The system shall explain why a given project ranked where it did, in terms suitable for a non-technical decision-maker. | Should-have |
GFOA recommends a capital improvement plan cover at least three, and preferably five or more, years. GFOA Multi-Year Capital Planning best practice. MAP-21 requires a risk-based transportation asset management plan for the National Highway System. FHWA asset management (MAP-21).
Technical and integration requirements
Technical requirements ensure the system fits your existing environment. The most important is integration: the planning layer should read condition from your existing EAM/GIS rather than force a rip-and-replace.
| Requirement | Sample RFP language | Priority |
|---|---|---|
| EAM / GIS integration | The system shall integrate with the agency's existing EAM, GIS, and pavement systems (for example, Esri or PAVER/MicroPAVER) as a source of asset and condition data, and shall describe the integration method and effort. | Must-have |
| Data import / export | The system shall support bulk import and export of asset, condition, and project data in open formats (for example, CSV, GeoJSON) and via API. | Must-have |
| Hosting & data residency | The vendor shall describe the hosting model, data-residency options, and whether U.S. data residency is available. | Must-have |
| Authentication | The system shall support single sign-on (for example, SAML/OIDC) and role-based access control. | Should-have |
| API access | The system shall expose a documented API for reading plans, projects, and scenarios. | Should-have |
| Scalability | The vendor shall describe how the system scales to the agency's asset inventory size and number of users. | Should-have |
Accessibility and security requirements (the procurement gates)
Accessibility and security are frequently pass/fail gates in public RFPs. Require truthful, evidenced status rather than claimed certifications. A vendor that overstates a certification it cannot document is a risk, not a shortcut.
| Requirement | Sample RFP language | Priority |
|---|---|---|
| Accessibility (WCAG) | The vendor shall document the product's conformance to WCAG 2.1 Level AA accessibility. | Must-have |
| Security posture | The vendor shall document its security program — including encryption, access controls, hosting, and data residency — and report the truthful, evidenced status of any attestations, with no overstated or unevidenced certifications. | Must-have |
| Data handling | The vendor shall describe how agency data is stored, encrypted, and retained. | Must-have |
| Reporting & compliance support | The system shall support audit-ready outputs and reporting relevant to the agency's obligations (for example, GASB 34 condition-based reporting where applicable). | Should-have |
| Business continuity | The vendor shall describe backup, recovery, and uptime commitments. | Should-have |
See InfraMind’s security and accessibility pages for our current, truthful status on each of these items.
Vendor, services, and procurement requirements
The remaining requirement areas cover the services the vendor delivers and the procurement path itself. Clear implementation and support requirements prevent a capable product from stalling after award.
| Requirement | Sample RFP language | Priority |
|---|---|---|
| Implementation & data migration | The vendor shall describe its implementation methodology, data-migration approach, and a proposed timeline with milestones and acceptance criteria. | Must-have |
| Training & adoption | The vendor shall provide role-based training for planners, finance, and leadership users. | Must-have |
| Support & SLAs | The vendor shall describe support channels, response-time commitments, and escalation. | Must-have |
| References | The vendor shall provide references from comparable public agencies where available. | Should-have |
| Procurement path | The vendor shall identify the contract path(s) by which the agency may procure — for example, a direct quote or a response to this solicitation. | Should-have |
| Pricing structure | The vendor shall provide pricing scoped to the agency's asset portfolio and user count, with a clear renewal structure. | Must-have |
Pair this with how to buy. Once your requirements are set, see how to buy for how InfraMind is procured directly — by quote or RFP response. To justify the purchase internally, use the business case for capital planning software.
Frequently asked questions
Want this scoped to your asset classes?
Send us the asset classes and systems in scope and we'll help you tailor these requirements — and show how InfraMind responds to each one — on a working demo.