1-RFP Worksheet FINAL.xlsx
XLSX spreadsheet 138 KB Posted
- Attached to
- Enterprise Asset Management System (EAMS) and Permitting, Licensing, and Case Management System (PLCMS)
- Solicitation number
- WVC 26-02
- Issued by
- Salt Lake County, Utah
About this file
This is a Technology Capability Evaluation Workbook for West Valley City, Utah's Request for Proposal (RFP) seeking an integrated Enterprise Asset Management System (EAMS) and Permitting, Licensing, and Case Management System (PLCMS). The RFP was issued on March 12, 2026, with proposals due on April 12, 2026, at 5:00 p.m. MDT. The City's evaluation period is anticipated to conclude by end of May or June 2026, followed by contract negotiation and preparation. City Council is scheduled to present RFP recommendations on June 23, 2026, with contract award anticipated in July 2026, notice of award in August 2026, and full implementation by January 2028. The workbook contains detailed functional requirements across twelve modules: Permitting, Portal Citizen Engagement, Asset Registry, Reliability Management, Work Management, Warehouse & Inventory Management, Capital Planning, Employee-Contractor Management, Reporting & Dashboards, Mobile Environment, GIS Interface, and Technical Administration & Security, totaling hundreds of specific capabilities that proposers must evaluate and respond to for each listed requirement.
Evaluation criteria are weighted as follows: Cost (40%), Functional Fit to Requirements (30%), Implementation & Support (10%), Vendor Experience & References (10%), and Reporting & Analytics Capabilities (10%). For each capability, proposers must indicate support level using standardized options: Standard (Std) for core functionality, Future (Fut) for capabilities available within 6-12 months, Third Party Solution (3rd) for integrated third-party systems, Code Customization (Cus) for custom modifications, or Not Supported (NS). Capability priorities are classified as Critical (essential for operations), Desired (strongly preferred), Desired W/ Critical (essential only if related critical capability is implemented), or Optional. Proposers must clearly identify required modules, add-ons, configurations, custom development, or third-party products needed to support each capability and include all components in their cost proposals. The workbook is designed to systematically evaluate how well proposed solutions meet West Valley City's comprehensive asset management and permitting needs across all organizational functions.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| 2-WVC RFP AMS and PLL (1).pdf |
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Instructions TECHNOLOGY CAPABILITY EVALUATION WORKBOOK Enterprise Asset Management and Permit/License/Case Solution West Valley City, Utah RFP: #####
| HOW TO COMPLETE THIS WORKBOOK: |
| This workbook is designed to help West Valley City evaluate how well proposed solutions support the City’s asset and maintenance management needs. Proposers must complete all applicable fields for each listed capability. Responses should reflect the solution being offered at the time of submission. |
For every item, Proposers must indicate the level at which the capability is supported and identify any modules, integrations, or configurations required. Responses should be clear, specific, and concise.
Failure to provide a response where required may be interpreted as the capability not being available.
| WORKSHEET COLUMNS: | |
| Columns A-B | These columns describe the operational and functional capabilities West Valley City is seeking in an asset and maintenance management platform. Some entries include illustrative examples to clarify intent. Examples are provided for context only and do not limit how the capability may be delivered or applied. |
Column C For each capability, select one option from the drop-down list that best describes how the proposed solution addresses the City’s need.
Certain security and administrative items may require a yes/no response rather than the selections below.
| Standard | ||
| (Std) | Feature/Function is included in the proposed solution and is considered part of the "core" functionality and/or vendor developed and supported modules for the proposed system solution. This is intended to address functionality of currently available software. | |
| Future | ||
| (Fut) | Feature/Function will be available in an upcoming software release within 6 to 12 months of this submittal. Indicate the planned release version as well as the time the release will be commercially available. This is intended for new products, modules, or functionality. |
| 3rd Party Solution | ||
| (3rd) | Feature/Function is not included as part of the "core" functionality and/or vendor developed and supported modules for the proposed system solution. However, this feature could be provided with integration with a third-party system, free or otherwise. Indicate name of the software in the Comment field. | |
| Code Customization | ||
| (Cus) | Feature/Function is not included in the current software release and is not planned to be a part of a future software release. However, this feature could be provided with custom modifications. | |
| Not Supported | ||
| (NS) | Feature/Function cannot be provided. |
Column D Proposers should clearly identify any application modules, licensed add-ons, configurations, custom development, or third-party products or services required to support each capability. All components referenced in responses must be reflected in the cost proposal.
Column E Add comments, as necessary, to further explain how proposed solution meets the requirements. If proposed solution can only partially meet requirement, provide detail in the comments.
Column F This column indicates the relative importance of each capability to West Valley City, ranging from capabilities that are essential to those that are optional. Priority levels reflect whether a capability is critical to meeting the City’s operational needs, strongly preferred, desired but not necessary, or optional and included for additional value.
| Critical | A required capability that is essential for the City to meet operational needs. Solutions that do not support this capability may not be considered. |
| Desired | A capability that is strongly preferred and would significantly improve operations, but is not strictly required for the system to function. |
| Desired W/ Critical | A capability that is not required on its own but becomes essential if the related critical capability is implemented. It enhances or completes the functionality of a critical feature. |
Timeline & Criteria
| TIMELINE | ||
| Date | Time | Milestone |
| Thursday, March 12, 2026 | Issue RFP | |
| Sunday, April 12, 2026 | 5:00 pm MDT | Proposal Due Date |
| Thursday, May 14, 2026 | Anticipated End of City Evaluation Period | |
| End of May- June 2026 | Contract Negotiation and Preparation | |
| Tuesday, June 23, 2026 | Present RFP Recommendations to City Council | |
| July 2026 | City Council Award of Contract | |
| July 2026 | Anticipated Notice of Award | |
| August 2026 | Anticipated Start of Implementation | |
| January 2028 | Anticipated Full Implementation |
| CRITERIA | |
| Criteria | Weight |
| Cost | 40% |
| Functional Fit to Requirements | 30% |
| Implementation & Support | 10% |
| Vendor Experience & References | 10% |
| Reporting & Analytics Capabilities | 10% |
TOC
| TABLE OF CONTENTS | ||
| Tab # | Functional Area | # of Requirements |
| 1 | Permitting | |
| 2 | Portal Citizen Engagement | |
| 3 | Asset Registry | |
| 4 | Reliability Management | |
| 5 | Work Management | |
| 6 | Warehouse & Inventory Management | |
| 7 | Capital Planning | |
| 8 | Employee-Contractor Management | |
| 9 | Reporting & Dashboards | |
| 10 | Mobile Environment | |
| 11 | GIS Interface | |
| 12 | Technical, Administration & Security | |
| Note: In some cases, similar functional requirements have been listed for each individual asset group/category or asset type(s) to ensure understanding of the proposed solution’s capabilities. |
Permitting
#1 PERMITTING
| ID | Functional Requirement | Software Capability | Module(s) Used to Support Requirement | Vendor Comment | West Valley Expectation |
| 1.1 Permit configuration and core data | |||||
| 1.1.1 | Ability to configure unlimited permit, license, and case types. | Critical | |||
| 1.1.2 | Ability to track a unique record ID and type for each permit, license, or case. | Critical | |||
| 1.1.3 | Ability to track record location by site address, XY coordinates, and parcel/parcel number. | Critical | |||
| 1.1.4 | Ability to associate multiple people and organizations to a record, including names, roles, addresses, phone numbers, and email addresses. | Critical | |||
| 1.1.5 | Ability to store notes and comments at the record/case level with user, date, and time stamps. | Critical | |||
| 1.1.6 | Ability to store record details using multiple data formats (for example, text, date, currency, integer, boolean, pick‑lists). | Critical | |||
| 1.1.7 | Ability to add user‑defined fields to records to meet department‑specific needs. | Critical | |||
| 1.1.8 | Ability to attach and manage electronic documents and files (for example, plans, images, emails, PDFs, Office documents) at the record/case level. | Critical | |||
| 1.1.9 | Ability to view attachments in program without requiring download | Critical | |||
| 1.1.10 | Ability to link related permits, licenses, applications, and enforcement cases to each other. | Critical | |||
| 1.1.11 | Ability to link permits, licenses, and cases to GIS parcel and property features and XY coordinates. | Critical | |||
| 1.1.12 | Ability to manage recurring licenses and permits with defined renewal cycles and rules. | Critical | |||
| 1.1.13 | Ability to manage right‑of‑way permits from application through inspection and closeout. | Critical | |||
| 1.1.14 | Ability to configure permit, license, and case types with reusable templates (for example, default fees, default inspections, default conditions, standard notifications). | Critical | |||
| 1.1.15 | Ability to configure and manage permit and license conditions (for example, standard and ad‑hoc conditions) and track satisfaction/clearance of conditions. | Critical | |||
| 1.1.16 | Ability to configure and manage flags associated with permits, licenses, applications, cases, etc. | Critical | |||
| 1.1.17 | Ability to flag/lock a case/parcel based on severity/conditions | Critical | |||
| 1.1.18 | Abilty to create and print documents (Permit, Fee Schedule, Inspection Reports, etc.) specific and related to a case/project | Critical | |||
| 1.1.19 | Ability to store/access application questionaire responses (DATA GROUP) | Critical | |||
| 1.1.20 | Ability to configure/store/access specific project/case information. (DATA GROUP) | Critical | |||
| 1.2 Fees and payments | |||||
| 1.2.1 | Ability to configure and calculate multiple types of fees (for example, flat fees, rate‑based fees, custom fees) by permit, license, and application type. | Critical | |||
| 1.2.2 | Ability to calculate and apply late fees based on configurable business rules. | Critical | |||
| 1.2.3 | Ability to track multiple tender/payment types for fees. | Critical | |||
| 1.2.4 | Ability to estimate fees at any time during the application process and before issuance. | Critical | |||
| 1.2.5 | Ability for estimated fees to be visible to City staff. | Critical | |||
| 1.2.6 | Ability for estimated fees to be visible to applicants based on staff‑configured authorization. | Critical | |||
| 1.2.7 | Ability to track historical fees and payments across recurring and related record types. | Critical | |||
| 1.2.8 | Ability to track and calculate refundable fees (bonds) | Critical | |||
| 1.2.9 | Ability to track payments on a payment plan | Desired | |||
| 1.3 Workflow, tasks, and notifications | |||||
| 1.3.1 | Ability to configure automated workflows and processes for permits, licenses, and cases. | Critical | |||
| 1.3.2 | Ability to define and manage tasks and task groups (workflows) associated with permits, licenses, and cases. | Critical | |||
| 1.3.3 | Ability to configure workflows that route tasks across multiple departments, divisions, and City staff. | Critical | |||
| 1.3.4 | Ability to control workflow steps for concurrent and sequential work (for example, allow parallel reviews or enforce strict step order). | Critical | |||
| 1.3.5 | Ability to assign a specific employee to a case, task type, area, etc. | Critical | |||
| 1.3.6 | Ability to assign more than one employee to a single task | Desired | |||
| 1.3.7 | Abilty to assign/change a case type after case created and change automated workflow | Critical | |||
| 1.3.8 | Ability to assign/change a name for a case | Critical | |||
| 1.3.9 | Ability to configure automated notifications for staff and external applicants/users based on workflow events (for example, assignment, status changes, upcoming deadlines). | Critical | |||
| 1.3.10 | Ability to manage permit and license applications from submission through review, approval, issuance, renewal, and completion. | Critical | |||
| 1.3.11 | Ability to manage/change/override completed tasks | Critical | |||
| 1.3.12 | Ability to enforce configurable business rules for completeness checks before permit or license issuance (for example, required inspections completed, fees paid, conditions met). | Critical | |||
| 1.3.13 | Ability to manage plan review and submission processes or interface with a City third‑party plan review solution. | Desired W/ Critical | |||
| 1.4 Inspections and enforcement | |||||
| 1.4.1 | Ability to configure inspection types and inspection checklists, including configurable result codes. | Critical | |||
| 1.4.2 | Ability to schedule inspections in the office based on inspector availability, trade/discipline, and geographic area. | Critical | |||
| 1.4.3 | Ability to track inspection outcomes, corrections, photos, comments, and detailed findings. | Critical | |||
| 1.4.4 | Ability to track multiple violations on a case, including violation type, date, status, and resolution. | Critical | |||
| 1.4.5 | Ability to track enforcement actions associated with violations, including action type, responsible staff, and outcome. | Critical | |||
| 1.4.6 | Ability to manage code enforcement cases from initial complaint through investigation, notices, enforcement actions, and resolution. | Critical | |||
| 1.4.7 | Ability to monitor compliance with permit, license, and enforcement requirements, including key dates, conditions, and milestones. | Critical | |||
| 1.4.8 | Ability to use artificial intelligence to assist with inspections (for example, recognizing issues, suggesting codes, or flagging inconsistencies) where supported. | Critical | |||
| 1.4.9 | Ability to schedule recurring monthly and annual inspections. | Critical | |||
| 1.4.10 | Ability to create custom inspection checklists that support attachments per checklist item. | Critical | |||
| 1.5 Mobile, GIS, and calendar integration | |||||
| 1.5.1 | Mobile solution that supports field inspections, including offline/online operation as applicable. | Critical | |||
| 1.5.2 | Mobile solution that supports broader platform capabilities (for example, viewing records, capturing photos, entering notes) in the field. | Critical | |||
| 1.5.3 | GIS integration that supports parcel mapping, visualization of record locations (permits, licenses, cases, etc.) and attributes (type, date, status, etc.), and inspection routing. | Critical | |||
| 1.5.4 | One‑way integration with Microsoft Outlook calendars to schedule and update inspections (Program writes to Outlook). | Critical | |||
| 1.5.5 | Two‑way integration with Microsoft Outlook calendars to schedule and update inspections (Program writes to Outlook, Outlook updates Program). | Desired | |||
| 1.5.6 | Ability for staff to access permitting and case data in real time in both office and field environments. | Critical | |||
| 1.6 Reporting and analytics | |||||
| 1.6.1 | Ability to create reports based on any information in the system using natural language or large‑language‑model‑assisted report generation, where available. | Critical | |||
| 1.6.2 | Ability to filter report content by permit type, location, status, date range, assigned staff, and other attributes. | Critical | |||
| 1.7 Document management and records | |||||
| 1.7.1 | Ability to attach and manage documents and attachments at the record, task, and correction levels (for example, photos, letters, notices, plans). | Critical | |||
| 1.7.2 | Ability to add detailed notes at the case/record, task, and correction levels. | Critical | |||
| 1.7.3 | Ability to add pictures and supporting documentation at the case/record, task, and correction levels. | Critical | |||
| 1.7.4 | Ability to integrate with Enterprise Document Management Systems or natively store engineering design and construction drawings and associate them with permits, licenses, and related assets. | Critical | |||
| 1.8 Miscellaneous | |||||
| 1.8.1 | Ability to capture and track time spent by staff on permitting and enforcement activities for workload and cost analysis. | Desired | |||
| 1.8.2 | Ability to support batch actions on selected records (for example, bulk status changes, bulk notifications, or mass renewals where allowed). | Desired | |||
| 1.8.3 | Ability to restrict access to elements of a case by public/employees/etc. | Critical |
Portal Citizen Engagement
#2 PORTAL CITIZENS ENGAGEMENT
| ID | Functional Requirement | Software Capability | Module(s) Used to Support Requirement | Vendor Comment | West Valley Expectation |
| 2.1 General portal capabilities | |||||
| 2.1.1 | Ability to provide a citizen and contractor portal available 24/7 for online access to services. | Critical | |||
| 2.1.2 | Ability for users to register and manage their own portal accounts, including profile information and contact details. | Critical | |||
| 2.1.3 | Ability for applicant/user to reset access password | Critical | |||
| 2.1.4 | Ability for multiple users to access/view/edit an individual case/project/application | Critical | |||
| 2.1.5 | Ability to configure portal content, layout, and navigation without vendor development. | Critical | |||
| 2.1.6 | Ability to customize portal appearance to meet City branding standards (for example, logo, colors, typography). | Critical | |||
| 2.1.7 | Ability to configure which services, forms, and information are visible in the portal by user role and case/permit type. | Critical | |||
| 2.1.8 | Ability to restrict application submittal without completing configurable conditions. | Critical | |||
| 2.2 Online applications and submissions | |||||
| 2.2.1 | Ability for users to apply online for permits, licenses, and applications exposed to the portal. | Critical | |||
| 2.2.2 | Ability for users to submit supporting documents (for example, plans, photos, letters) as part of an online application. | Critical | |||
| 2.2.3 | Ability for users to save an in‑progress application and return later to complete and submit it. | Critical | |||
| 2.2.4 | Ability to perform real‑time validation of submitted information (for example, required fields, address validation, basic format checks) before acceptance. | Critical | |||
| 2.2.5 | Ability to use AI assistance to guide users through application forms, improve accuracy, and clearly communicate required information and supporting documentation. | Desired | |||
| 2.3 Fees and online payments | |||||
| 2.3.1 | Ability for users to view fee estimates and calculated fees associated with their applications and permits in the portal. | Critical | |||
| 2.3.2 | Ability for users to pay fees and submit payments electronically for applicable records. | Critical | |||
| 2.3.3 | Ability to utilize the City’s existing payment processing software / merchant account for online payments. | Desired | |||
| 2.3.4 | Ability for portal payments to update fee and payment records in the core permitting system in real time. | Critical | |||
| 2.4 Status tracking and communication | |||||
| 2.4.1 | Ability for users to view real‑time status of their applications, permits, and licenses in the portal. | Critical | |||
| 2.4.2 | Ability to schedule inspections in portal according to Inspector schedule availability and Inspector discipline/trade/qualifications/certifications | Critical | |||
| 2.4.3 | Ability for users to view upcoming inspections, plan review milestones, and other key events for their records. | Critical | |||
| 2.4.4 | Ability to provide users with an activity timeline showing key status changes (for example, “Submitted”, “Under Review”, “Additional Information Required”, “Approved”). | Critical | |||
| 2.4.5 | Ability to configure automated email notifications to portal users for status changes, approvals, rejections, scheduled inspections, and required actions. | Critical | |||
| 2.4.6 | Ability to send configured notifications (for example, email, SMS where supported) to internal staff based on portal submissions and updates. | Critical | |||
| 2.5 Documents and outputs | |||||
| 2.5.1 | Ability for users to view and download approved permits, licenses, and other official documents from the portal. | Critical | |||
| 2.5.2 | Ability for users to print or download relevant reports or documents such as permits, licenses, receipts, review letters, and inspection results. | Critical | |||
| 2.5.3 | Ability to expose select attached documents (for example, approved plans, correspondence) to portal users based on configurable security and privacy rules. | Critical | |||
| 2.6 Account security and access | |||||
| 2.6.1 | Ability to secure the portal with modern browser‑based authentication and encryption (for example, TLS 1.2 or newer). | Critical | |||
| 2.6.2 | Ability to support captcha or similar tools to reduce automated or fraudulent submissions. | Critical | |||
| 2.6.3 | Ability to support role‑based portal access (for example, citizen, contractor, business licensee) with configurable permissions. | Critical | |||
| 2.7 Miscellaneous | |||||
| 2.7.1 | Ability to provide a responsive portal interface that automatically optimizes display for desktops, tablets, and mobile devices. | Critical | |||
| 2.7.2 | Ability for portal users to submit questions or service requests related to their applications and receive responses through the portal. | Desired | |||
| 2.7.3 | Ability to support multilingual content in the portal (for example, configurable labels and instructions in multiple languages). | Critical | |||
| 2.7.4 | Ability to provide accessibility‑compliant portal pages (for example, WCAG 2.1 AA or equivalent) for users with disabilities. | Critical | |||
| 2.7.5 | Ability to provide configurable FAQs, help text, and context‑sensitive guidance within portal pages without vendor development. | Critical |
Asset Registry
#3 ASSEST REGISTRY
| ID | Functional Requirement | Software Capability | Module(s) Used to Support Requirement | Vendor Comment | West Valley Expectation |
| 3.1 General asset record structure | |||||
| 3.1.1 | Ability to assign a user‑defined unique ID to all assets, supporting alphanumeric characters and special characters such as dashes or hyphens, with configurable maximum length and allowed characters. | Critical | |||
| 3.1.2 | Ability for authorized users to change or update an asset’s unique ID and retain all associated records and history. | Desired W/ Critical | |||
| 3.1.3 | Ability to import a list of assets and associated attribute information from common file formats (for example, XLS/XLSX, CSV). | Desired | |||
| 3.1.4 | Ability to search and filter asset records using single or multiple attributes (for example, pipes by age, diameter, and location; equipment by type, installation date, and location). | Critical | |||
| 3.1.5 | Ability to assign assets to different groups, departments, or divisions to support management by organizational unit. | Critical | |||
| 3.1.6 | Ability to store multiple components for an asset and manage parent–child relationships and hierarchies. | Critical | |||
| 3.1.7 | Ability to access related information for an asset, including attributes, inspections, work orders, service requests, and attached documents, from a single asset view. | Critical | |||
| 3.1.8 | Ability to define user‑configured fields on asset records to store additional attribute information (for example, confined space required, troubled area flags, special requirements). | Critical | |||
| 3.1.9 | Availability of standard system, pre‑configured asset forms for common asset types (for example, sewer mains, water mains, stormwater structures, buildings, fleet). | Desired | |||
| 3.1.10 | Ability to modify standard system asset forms/screens (for example, add/remove/relabel fields) to align with City data standards. | Critical | |||
| 3.1.11 | Ability to assign a priority or criticality rating to an asset or location (for example, critical, non‑critical). | Desired | |||
| 3.1.12 | Ability to store notes/comments on an asset record with automatic date, time, and user stamps. | Critical | |||
| 3.1.13 | Ability to store user‑defined threshold values (minimum/maximum) for selected asset attributes to support monitoring and alerts. | Desired | |||
| 3.2 Documents and drawings | |||||
| 3.2.1 | Ability to add, link, and attach electronic documents, images, and videos to asset records, including common office, image, CAD, and PDF file formats. | Critical | |||
| 3.2.2 | Ability to store, retrieve, and open one or more linked or attached documents, photographs, and videos for any asset record from the asset screen. | Critical | |||
| 3.2.3 | Ability to integrate with Enterprise Document Management Systems or natively store engineering design and construction drawings, including project name, designer, inspector, related assets, project costs, and construction/installation dates per asset. | Desired | |||
| 3.3 Asset creation, cloning, and lifecycle | |||||
| 3.3.1 | Ability to create new asset records using an existing asset record as a template, with the option to carry over selected attributes (for example, three pumps of the same model). | Desired | |||
| 3.3.2 | Ability to track rehabilitation projects associated with any asset type. | Desired | |||
| 3.3.3 | Ability to calculate and store an asset decay or deterioration curve by storing the calculation methodology and allowing scheduled updates of lifecycle position. | Desired | |||
| 3.3.4 | Ability to track asset status (for example, Active, In Service, Inactive, Abandoned, Retired, Sold) and history of status changes. | Desired | |||
| 3.4 Warranty tracking | |||||
| 3.4.1 | Ability to store information describing one or more warranties for assets (for example, equipment, roofs), including terms, effective dates, and expiration dates. | Desired W/ Critical | |||
| 3.4.2 | Ability to generate notifications or warnings when a work order is created for an asset with an active warranty. | Desired | |||
| 3.4.3 | Ability to generate a list of assets with warranty end dates approaching, based on a user‑defined timeframe. | Desired | |||
| 3.4.4 | Ability to restrict or warn users when attempting to postpone maintenance activities on assets under warranty, based on configurable rules. | Desired | |||
| 3.5 Linear and network infrastructure assets | |||||
| 3.5.1 | Ability to store and manage assets and attributes for streets and transportation infrastructure (for example, streets, street lights, street signs, pavement). | Critical | |||
| 3.5.2 | Ability to store and manage stormwater system assets and attributes, including structures, conduits, detention basins, valves, discharge points, pump/lift stations, and drywells. | Critical | |||
| 3.5.3 | Ability to track and document stormwater Best Management Practices (BMPs), including each BMP site and associated assets. | Desired | |||
| 3.5.4 | Ability to view the relationship of a selected asset to other connected assets (for example, select a manhole, valve, or hydrant and see connected pipes and services—and vice versa). | Desired | |||
| 3.5.5 | Ability to relate multiple service connections to a single address and track the status of each connection (for example, Active, Inactive, Abandoned). | Critical | |||
| 3.6 Fleet and distributed assets | |||||
| 3.6.1 | Ability to store and manage asset records, including attributes, for fleet assets that can be assigned to work orders and employees (for example, dump trucks, crew trucks, backhoes). | Critical | |||
| 3.6.2 | Ability to store and manage asset records, including attributes, for distributed assets and specialty tools that can be assigned to work orders and employees (for example, pipe saws, portable pumps, mobile generators). | Desired | |||
| 3.6.3 | Ability to track the status of vehicle and equipment assets (for example, Active, In Service, Inactive, Sold). | Critical | |||
| 3.6.4 | Ability to link barcodes, QR codes, or RFID tags to asset records to support identification and scanning in the field and warehouse. | Desired | |||
| 3.7 Building and facility assets | |||||
| 3.7.1 | Ability to store and manage asset records and attributes for buildings and facilities, including key components such as roofs, HVAC, mechanical/electrical/plumbing systems, rooms, floors, doors, windows, and furnishings. | Critical | |||
| 3.7.2 | Ability to associate multiple rooms and floors with a building or facility asset record. | Critical | |||
| 3.7.3 | Ability to group assets into multi‑level hierarchies (for example, campus → site → building → floor → room → equipment). | Critical | |||
| 3.7.4 | Ability to enter equipment at any defined level in the facility hierarchy and search for that equipment at higher levels. | Critical | |||
| 3.7.5 | Ability to view hierarchical relationships between facility, equipment, and component assets from an interactive view. | Critical | |||
| 3.7.6 | Ability to roll up and analyze asset data by site, location, building, or facility. | Critical | |||
| 3.7.7 | Ability to track rehabilitation projects associated with sites, locations, or buildings and relate them to impacted assets. | Desired W/ Critical | |||
| 3.8 Miscellaneous | |||||
| 3.8.1 | Ability to support asset versioning or effective‑dating of key attributes (for example, material, size, criticality) and maintain historical values for analysis. | Desired | |||
| 3.8.2 | Ability to maintain standardized asset classification and taxonomy (for example, asset class, type, subtype) across all asset groups, with centralized configuration. | Desired | |||
| 3.8.3 | Ability to support geospatial storage of point, line, and polygon geometries for assets and synchronize key attributes with the City’s GIS where integrated. | Critical | |||
| 3.8.4 | Ability to flag assets as “candidate for replacement” or “candidate for rehabilitation” and link them to capital planning and project records. | Desired W/ Critical | |||
| 3.8.5 | Ability to bulk update selected attributes for a set of assets (for example, update criticality, maintenance responsibility, or owner for a group of records) under appropriate security controls. | Desired |
Reliability Management
#4 RELIABILTY MANAGEMENT
| ID | Functional Requirement | Software Capability | Module(s) Used to Support Requirement | Vendor Comment | West Valley Expectation |
| 4.1 General inspection and condition tracking | |||||
| 4.1.1 | Allows recording and storage of multiple inspections and tests per asset or piece of equipment, with fields for inspection date, inspector, and inspection type. | Critical | |||
| 4.1.2 | Ability to attach, link, and view checklists or specific instructions for any type of inspection, test, or repair. | Critical | |||
| 4.1.3 | Ability to maintain, track, and document remaining useful life for an asset or facility. | Desired | |||
| 4.1.4 | Ability to maintain, track, and document condition for an asset or facility, using configurable condition rating scales. | Critical | |||
| 4.1.5 | Ability to maintain, track, and document criticality for an asset or facility. | Critical | |||
| 4.1.6 | Ability to maintain, track, and document potential risk for an asset or facility, including risk scores where configured. | Desired | |||
| 4.1.7 | Ability to create custom inspection forms/screens or modify pre‑configured forms based on City templates for asset types and specific purposes. | Critical | |||
| 4.1.8 | Availability of standard system, pre‑configured testing and inspection forms/screens based on typical data collected for supported modules. | Desired | |||
| 4.1.9 | Ability to add, attach, or link electronic documents, photos/images, and videos to any inspection record. | Critical | |||
| 4.1.10 | Ability to automatically generate a follow‑up work order when an inspection result falls outside a user‑defined threshold. | Critical | |||
| 4.1.11 | Ability to generate notifications based on inspection results or documented asset condition. | Desired | |||
| 4.1.12 | Ability to capture an XY coordinate (point location) from GIS and store it as the inspection location. | Critical | |||
| 4.2 Collection system and wastewater inspections | |||||
| 4.2.1 | Ability to capture and track typical and user‑defined inspection information for sewer collection system assets, including pipes, laterals, pumps, buildings, manholes/structures, and lift stations (for example, CCTV, lamping, smoke testing, dye testing, vacuum tests, air tests). | Needs Review - Proposed Deletion | |||
| 4.2.2 | Ability for inspection records to store and import National Association of Sewer Service Companies (NASSCO) PACP, MACP, and LACP inspection collection formats. | Needs Review - Proposed Deletion | |||
| 4.2.3 | Ability to capture and track typical information related to sanitary sewer overflows (SSOs) for regulatory reporting, including location, asset ID, dates/times, estimated flow, cause, cleanup activities, and notifications. | Needs Review - Proposed Deletion | |||
| 4.2.4 | Ability to link SSO records to associated pipes, structures, or addresses, and link related work orders, service requests, or customer complaints. | Needs Review - Proposed Deletion | |||
| 4.2.5 | Ability to document agencies involved in SSO reporting. | Needs Review - Proposed Deletion | |||
| 4.3 Stormwater inspections | |||||
| 4.3.1 | Ability to capture and track typical and user‑defined inspection information for storm water assets, including pipes, pumps, , pump stations, storage facilities. | Desired | |||
| 4.3.2 | Ability to attach or link photos and videos to individual observations from a CCTV inspection. | Critical | |||
| 4.3.3 | Ability to import CCTV inspection results from standard PACP software such as Cues GraniteNet and Panoramo. | Critical | |||
| 4.3.4 | Ability to capture and track typical and user‑defined inspection information for stormwater system assets, including structures, conduits, detention basins, valves, discharge points, and drywells. | Critical | |||
| 4.3.5 | Ability to track and document tests conducted on stormwater BMP assets. | Critical | |||
| 4.4 Illicit discharges and environmental compliance | |||||
| 4.4.1 | Ability to capture and track typical information related to illicit discharge incidents, including location, asset ID, description of discharge, violator, and investigator. | Critical | |||
| 4.4.2 | Ability to link illicit discharge incident records to associated structures or addresses. | Critical | |||
| 4.4.3 | Ability to link work orders, service requests, or customer complaints to documented illicit discharge incidents. | Critical | |||
| 4.4.4 | Ability to document agencies involved in reporting illicit discharge incidents. | Critical | |||
| 4.4.5 | Ability to document and track investigation information, sampling results, remediation actions, and agency notifications related to illicit discharges. | Critical | |||
| 4.4.6 | Ability to capture and track enforcement actions related to illicit discharges. | Critical | |||
| 4.5 Other asset‑type inspections | |||||
| 4.5.1 | Ability to capture and track typical and user‑defined inspection information related to irrigation systems (for example, pipes, controllers, valves). | Critical | |||
| 4.5.2 | Ability to capture and track typical and user‑defined inspection information related to buildings and facilities (for example, building envelope, roofs, structural components). | Critical | |||
| 4.5.3 | Ability to capture and track typical and user‑defined inspection information related to fleet assets (for example, trucks, backhoes, cranes, mobile generators). | Critical | |||
| 4.6 Readings, condition updates, and risk‑based scheduling | |||||
| 4.6.1 | Ability to track asset readings such as vibration, amps, meter readings, gauges, odometer readings, and calculate differences between previous and new readings. | Critical | |||
| 4.6.2 | Ability to automatically or manually update current and historical asset attributes based on inspection and condition assessment data. | Critical | |||
| 4.6.3 | Ability to track and determine next inspection dates based on remaining life, asset criticality, and potential risk. | Desired W/ Critical | |||
| 4.7 Preventive maintenance (PM) setup | |||||
| 4.7.1 | Ability to create PM templates and schedules for any asset stored in the EAMS (for example, linear assets, equipment, vehicles) and indicate PM template status (for example, Active, Inactive). | Desired | |||
| 4.7.2 | Ability to assign individual assets or groups of assets (same or different asset types) to a PM template. | Desired | |||
| 4.7.3 | Ability to add and remove assets assigned to a PM template. | Desired | |||
| 4.7.4 | Ability to schedule PM tasks using standardized frequency types (for example, days, weeks, calendar months, specific dates, quarters, calendar years including leap years). | Desired | |||
| 4.7.5 | Ability for the system to auto‑generate PM work orders based on scheduled frequency (for example, elapsed time, seasonal or cycle‑based PMs). | Desired | |||
| 4.7.6 | Ability to schedule PM tasks based on equipment runtime or other meter readings. | Desired | |||
| 4.7.7 | Ability to schedule PM tasks based on specified events (for example, after a defined type of failure or inspection result). | Desired | |||
| 4.7.8 | Ability to “nest” PM tasks so that higher‑level PMs (for example, monthly, quarterly, annual) supersede lower‑level PMs (for example, weekly) during overlapping periods, preventing duplicate work orders. | Desired | |||
| 4.7.9 | Ability to attach and view checklists, safety procedures, maintenance instructions, repair procedures, quality assurance instructions, and comments/notes on PM templates. | Desired | |||
| 4.7.10 | Ability to generate unscheduled (corrective) work orders from PM templates. | Desired | |||
| 4.7.11 | Ability to notify supervisors, crews, or employees of upcoming PM work orders. | Desired | |||
| 4.7.12 | Ability to include estimated labor hours and anticipated materials/parts for PM tasks. | Desired | |||
| 4.7.13 | Ability to view and track PM schedules by asset, equipment, facility, and by work task. | Desired | |||
| 4.7.14 | Ability to integrate PM tasks with recorded failure modes to support reliability‑centered maintenance analysis. | Desired | |||
| 4.8 Miscellaneous | |||||
| 4.8.1 | Ability to calculate and report key reliability metrics such as mean time between failures (MTBF), mean time to repair (MTTR), and availability by asset or asset class. | Desired | |||
| 4.8.2 | Ability to rank assets by risk using configurable risk matrices that combine condition, criticality, and likelihood of failure to support maintenance and capital planning decisions. | Desired | |||
| 4.8.3 | Ability to generate optimized inspection and PM schedules based on risk, criticality, or regulatory requirements. | Desired | |||
| 4.8.4 | Ability to flag assets with recurring failures or chronic defects and recommend review of maintenance strategy. | Desired | |||
| 4.8.5 | Ability to export reliability and condition data for use in external asset‑management or capital‑planning models. | Desired |
Work Management
#5 WORK MANAGEMENT
| ID | Functional Requirement | Software Capability | Module(s) Used to Support Requirement | Vendor Comment | West Valley Expectation |
| 5.1 Service and work requests | |||||
| 5.1.1 | Ability to record detailed information related to a service or work request, including problem description and requested action. | Critical | |||
| 5.1.2 | Ability to view whether an open service/work request or work order already exists for the same asset, facility, building, or address. | Critical | |||
| 5.1.3 | Ability to develop prompts or guided questions to capture consistent information for specific problems or issues. | Critical | |||
| 5.1.4 | Ability to track multiple contacts with customers for the same service/work request (for example, an outage affecting multiple customers). | Desired W/ Critical | |||
| 5.1.5 | Ability for service/work requests to be initiated from GIS or the EAMS at a specific address or location without an asset. | Critical | |||
| 5.1.6 | Ability for service/work requests to be initiated from GIS for a selected asset (for example, select an asset on the map and initiate a request). | Critical | |||
| 5.1.7 | Ability for service/work requests to be initiated from the EAMS from an asset record (for example, open an asset and initiate a request). | Critical | |||
| 5.1.8 | Ability to customize a list of problem codes to be selected and recorded on service/work requests. | Critical | |||
| 5.1.9 | Ability to add, attach, or link documents, photos/images, and videos to a service/work request. | Critical | |||
| 5.1.10 | Ability to view service/work request history for an asset, facility, address, or customer. | Critical | |||
| 5.1.11 | Ability to generate automatic notifications when a new service/work request is created for an asset or location with an existing open request. | Critical | |||
| 5.1.12 | Ability to provide an online, web‑based interface for citizen self‑service that integrates with the system (for example, online submission of service requests). | Critical | |||
| 5.1.13 | Ability to track the status of a service/work request throughout the workflow, with automatic date and time stamps for each status change. | Critical | |||
| 5.1.14 | Ability for the system to automatically update a service/work request status when a work order is generated from that request (for example, to “Assigned to Work Order”). | Critical | |||
| 5.2 Work order generation | |||||
| 5.2.1 | Ability to create a work order from a service/work request and carry over relevant information (for example, address, asset, problem) to avoid duplicate data entry. | Critical | |||
| 5.2.2 | Ability to automatically generate a unique work order number. | Critical | |||
| 5.2.3 | Ability for work orders to be initiated from GIS for a selected asset. | Critical | |||
| 5.2.4 | Ability for work orders to be initiated from the EAMS from an asset record. | Critical | |||
| 5.2.5 | Ability for work orders to be created from GIS or the EAMS for a specific address or location without an asset. | Critical | |||
| 5.2.6 | Ability to add multiple assets of the same asset type to a single work order (for example, hydrant flushing or fire extinguisher inspections). | Critical | |||
| 5.2.7 | Ability to add multiple assets of different asset types to a single work order (for example, stormwater inspections for inlets, nodes, and manholes). | Critical | |||
| 5.2.8 | Ability to automatically assign a work order based on geographic area or treatment plant process (for example, quarter‑section map, WTP/WWTP process). | Critical | |||
| 5.2.9 | Ability to generate automatic notifications when a work order is created for an asset or location with an existing open work order. | Critical | |||
| 5.2.10 | Ability to define work tasks that represent maintenance activities for assets, facilities, locations, and indirect time (for example, meetings, training, shop time). | Critical | |||
| 5.2.11 | Ability to add estimated labor hours, required parts/materials, and vehicle/equipment resources to work tasks. | Critical | |||
| 5.2.12 | Ability to add multiple work tasks to a work order and list tasks in a user‑defined order. | Critical | |||
| 5.2.13 | Ability to generate child work orders from a parent work order to break work into manageable units. | Critical | |||
| 5.2.14 | Ability to define a list of problems to be selected and recorded on work orders. | Critical | |||
| 5.2.15 | Ability to define a list of failure codes/causes to be selected and recorded on work orders. | Critical | |||
| 5.2.16 | Ability to add a barcode or QR code to a work order to support scanning in the field or warehouse. | Desired | |||
| 5.2.17 | Ability for work orders to be automatically generated based on user‑defined set‑point readings or threshold values (for example, meter triggers). | Desired | |||
| 5.2.18 | Ability to create and use work order templates (partially pre‑populated work orders) for quick, consistent generation of common work. | Critical | |||
| 5.2.19 | Ability to attach or link documents to individual work tasks so that related documents automatically display on the work order when the task is used. | Critical | |||
| 5.2.20 | Ability to manage and track utility locates as a work type within the work order system. | Critical | |||
| 5.3 Work order tracking and history | |||||
| 5.3.1 | Ability to manage and track work order status through the workflow (for example, Planning, Approved, Waiting on Parts, Planned, Scheduled), with automatic date/time stamps for each change. | Critical | |||
| 5.3.2 | Ability to track and display the relationship between service/work requests and associated work orders. | Critical | |||
| 5.3.3 | Ability to track work orders by address, in addition to asset and location. | Critical | |||
| 5.3.4 | Ability to limit permissions to complete, close, or cancel work orders based on security roles. | Critical | |||
| 5.3.5 | Ability to assign prioritization to specific work tasks and to work orders overall. | Critical | |||
| 5.3.6 | Ability to prioritize and/or group work orders based on type of work, priority, or other attributes. | Critical | |||
| 5.3.7 | Ability to set and adjust work order priority during the lifecycle of the work order. | Critical | |||
| 5.3.8 | Ability to define a routing order for multiple assets on a work order (for example, optimal field route). | Desired | |||
| 5.3.9 | Ability to define a routing order for multiple tasks on a work order, including tasks assigned to multiple trades. | Desired | |||
| 5.3.10 | Ability to select and view work orders using user‑defined criteria (for example, main task, assigned person or crew, date assigned, status, location, priority) at any point in the workflow. | Critical | |||
| 5.3.11 | Ability to mark tasks as complete for each asset listed on a work order individually (for example, each valve or fire extinguisher inspected). | Critical | |||
| 5.3.12 | Ability to retain complete work history for physical assets that may move between locations. | Critical | |||
| 5.3.13 | Ability to retain work history for rotating assets (for example, motors moved between pumps) and track work performed at each installation location. | Desired W/ Critical | |||
| 5.3.14 | Ability to retrieve work history for active assets. | Critical | |||
| 5.3.15 | Ability to retrieve work history for retired, abandoned, or removed assets. | Desired | |||
| 5.3.16 | Ability to track work performed by contractors and by City staff to support internal and external invoicing. | Critical | |||
| 5.3.17 | Ability to automatically notify staff of work assigned to them or within their area (for example, via dashboards, email, or text message). | Critical | |||
| 5.3.18 | Ability to automatically notify staff or supervisors when a work order is completed or requires approval prior to completion. | Critical | |||
| 5.3.19 | Ability to automatically send notifications to customers when requested work has been completed. | Critical | |||
| 5.3.20 | Ability to automatically close an associated service/work request when its work order is closed. | Critical | |||
| 5.3.21 | Ability to support a “check‑out” system for tools and equipment used on work orders. | Desired | |||
| 5.4 Work planning and scheduling | |||||
| 5.4.1 | Ability to use assigned dates and start dates on work orders to support look‑ahead scheduling of work (for example, assigning work a week in advance). | Critical | |||
| 5.4.2 | Ability to view availability of labor hours by resource within a defined time period to support scheduling. | Desired | |||
| 5.4.3 | Ability to identify overscheduled resources based on assigned work versus available capacity. | Desired | |||
| 5.4.4 | Ability to view work orders in a calendar view by day, week, or month based on assignment date for planning and scheduling. | Desired | |||
| 5.4.5 | Ability to view estimated hours associated with work tasks/work orders in a calendar view to support workload balancing. | Desired | |||
| 5.4.6 | Ability to view work orders by group, crew, or employee in a calendar view for scheduling within a defined time period. | Desired | |||
| 5.4.7 | Ability to change start and end dates on a work order directly from the calendar view to adjust schedules. | Desired | |||
| 5.4.8 | Ability to synchronize or visualize work order schedules within Microsoft Outlook or equivalent calendar tools. | Desired | |||
| 5.5 Miscellaneous | |||||
| 5.5.1 | Ability to support crew‑based work assignment (for example, define crews, assign work orders to crews, and track crew performance and utilization). | Critical | |||
| 5.5.2 | Ability to capture and track actual labor, materials, equipment usage, and contractor costs at the work‑task level and roll up to the work order and asset. | Desired W/ Critical | |||
| 5.5.3 | Ability to support service level agreements (SLAs) for response and completion times by work type or priority, and monitor compliance. | Desired | |||
| 5.5.4 | Ability to support mobile work management, including creating, updating, and closing work orders in the field with offline/online synchronization (aligned with the Mobile Environment tab). | Critical | |||
| 5.5.5 | Access to database to create custom views and feature services to be used in outside mapping applications. | Desired |
Warehouse & Inventory Mangement
#6 WAREHOUSE AND INVENTORY MANAGEMENT REQUIRMENTS
| ID | Functional Requirement | Software Capability | Module(s) Used to Support Requirement | Vendor Comment | West Valley Expectation |
| 6.1 General inventory management | |||||
| 6.1.1 | Ability to maintain stock quantities for inventory items, automatically adjusting quantities based on usage and receipts. | Critical | |||
| 6.1.2 | Ability to process parts and materials received, including full and partial receipts, and add quantities received to available stock. | Critical | |||
| 6.1.3 | Ability to set and maintain minimum quantity levels and reorder levels for each stock item. | Critical | |||
| 6.1.4 | Ability to establish and manage multiple warehouse locations (for example, buildings, warehouses, yards, mobile warehouses such as trucks). | Critical | |||
| 6.1.5 | Ability to track part locations and on‑hand quantities by warehouse, area, aisle, section, shelf, and bin. | Desired | |||
| 6.1.6 | Ability to manually update quantities of stock items with appropriate security controls. | Critical | |||
| 6.1.7 | Ability to support system‑assigned part IDs as well as City‑defined part numbers and descriptions. | Critical | |||
| 6.1.8 | Ability to attach, link, and view documents associated with part records (for example, specifications, MSDS, manuals, photos). | Critical | |||
| 6.1.9 | Ability to generate notifications when an inventory item approaches or falls below a specified level (for example, minimum or safety stock). | Critical | |||
| 6.1.10 | Ability to track returned parts and materials and credit the associated asset, work order, or project. | Desired | |||
| 6.1.11 | Ability to transfer stock from one warehouse to another, maintaining appropriate audit trails. | Critical | |||
| 6.1.12 | Ability to tie inventory items to different funds and accounts for costing and financial tracking. | Critical | |||
| 6.1.13 | Ability to maintain a full audit trail for inventory transactions (for example, issues, receipts, adjustments, transfers) with user, date, and time. | Critical | |||
| 6.1.14 | Ability to store and track notes/comments on inventory transactions. | Critical | |||
| 6.1.15 | Ability to support LIFO, FIFO, and average unit price (AUP) costing methods for inventory valuation. | Critical | |||
| 6.1.16 | Ability to charge parts issued back to departments, work orders, or projects for cost allocation. | Critical | |||
| 6.1.17 | Ability to search and filter on data fields stored on part records (for example, part number, description, vendor, warehouse, bin). | Critical | |||
| 6.1.18 | Ability to track parts purchased with purchasing cards (P‑cards). | Critical | |||
| 6.1.19 | Ability for designated inventory staff to manually adjust minimum/maximum levels (for example, based on turnover analysis), with approval workflow if required. | Critical | |||
| 6.1.20 | Ability for all authorized staff to view quantities of parts and materials across warehouses for planning purposes and directly from work orders. | Critical | |||
| 6.1.21 | Ability to send funding and account information from inventory issues to the City’s finance/ERP system to bill departments and divisions for stores transactions. | Desired | |||
| 6.1.22 | Ability to calculate and display average unit price based on the last several (for example, three) purchases. | Desired | |||
| 6.1.23 | Ability to adjust minimum/maximum counts to account for vendor lead time, based on current consumption rates, and notify warehouse staff for review and approval. | Desired | |||
| 6.1.24 | Ability to perform cycle counts at varying levels of detail (for example, specific item, bin, shelf, section, or row) without freezing the entire warehouse. | Desired | |||
| 6.1.25 | Ability to support reservations for parts (for example, items on shelf but committed to specific work orders or stores tickets, reflected in available balance). | Desired | |||
| 6.1.26 | Ability to store and track expiration dates of parts and consumables. | Critical | |||
| 6.1.27 | Ability to track rental equipment and related attributes, including rental cost, rental period, and supplier. | Desired | |||
| 6.1.28 | Ability to track back‑ordered parts and materials, including expected delivery dates. | Desired | |||
| 6.1.29 | Ability to mark parts as obsolete and track parts that are no longer used or stocked, while preserving history. | Desired | |||
| 6.2 Barcoding, QR, and RFID | |||||
| 6.2.1 | Ability to utilize barcodes, QR codes, and RFID tags for tracking inventory items, including storeroom locations and bins. | Critical | |||
| 6.2.2 | Ability to print or generate labels for aisles, shelves, bins, and parts to support scanning. | Critical | |||
| 6.2.3 | Ability to look up and transact parts (issue, receive, transfer) by scanning barcodes, QR codes, or RFID tags. | Critical | |||
| 6.3 Purchasing management | |||||
| 6.3.1 | Ability to store supplier/vendor information, including addresses, phone numbers, contact names, and tax rates, or capture this data from the City’s master vendor database via the ERP system. | Desired | |||
| 6.3.2 | Ability to link each part to one or more suppliers/vendors. | Desired | |||
| 6.3.3 | Ability to support different units of measure for ordering versus issuing (for example, purchase by pallet, issue by each). | Desired | |||
| 6.3.4 | Ability to store and update pricing information for parts, materials, and equipment. | Critical | |||
| 6.3.5 | Ability to automatically generate purchase requests when minimum levels or reorder points are reached. | Desired | |||
| 6.4 Receiving management |
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .