Exhibit_3_-_Complexity_Guidelines.xlsx
XLSX spreadsheet 14 KB Posted
- Attached to
- Enterprise Asset Management - Software & Implementation State and local contract opportunity
- Solicitation number
- RFP 26-0007
- Issued by
- Maricopa County, Phoenix City, Arizona
About this file
Exhibit 3 is a complexity guidelines document for the City of Phoenix's Enterprise Asset Management software and implementation procurement. The guidelines establish a four-tier complexity classification system—Simple, Moderate, Complex, and Very Complex—applicable to multiple functional areas including configurations, user-defined fields, reports, interfaces, extensions/enhancements, workflows, forms, and conversions. Each category provides specific criteria and examples to assess the scope and difficulty level of implementation tasks. For configurations, complexity ranges from standalone tables to dependencies that drive external application processing logic. User-defined fields are evaluated based on their purpose, from simple display and reporting functions to complex validation requirements supporting external application processing. Reports are classified by modification scope, from minimal changes to existing reports to combinations of external application and EAM data. Interfaces are assessed on transaction volume, error reporting capabilities, restart functionality, file handling, and data translation requirements, ranging from single transactions with simple error reporting to multi-system updates with cross-transactional data dependencies. Extensions and enhancements are rated by availability of user exits, code modification requirements, and programming complexity. Workflows, forms, and conversions are evaluated on the number of steps, attributes, controls, and dependencies required for implementation.
The guidelines establish objective measurement criteria to support procurement evaluation and vendor proposal assessment for the Enterprise Asset Management implementation. These complexity benchmarks enable the City of Phoenix to categorize and scope work effort for the five-year EAM software and implementation project commencing May or July 2026. By standardizing complexity definitions across functional and technical domains, the guidelines facilitate consistent evaluation of vendor capabilities, implementation methodologies, and pricing proposals across the 675 total possible evaluation points distributed among System Capabilities, Experience and Qualifications, and Method of Approach categories. The document serves as a technical reference tool for both the procurement team and vendors to ensure clear understanding of project requirements and implementation expectations.
View the file
Other files for this state and local contract opportunity
Show all 50
Enterprise Asset Management - Software & Implementation has more files on GovTribe.
On GovTribe
Work with this file on GovTribe
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Exhibit 3 Exhibit 3. COMPLEXITY GUIDELINES
| Simple | Moderate | Complex | Very Complex | ||
| Configurations | · Simple configuration table that stands-alone. | · Multiple configuration tables with table inter-dependencies. | • | Multiple configuration tables with complex table inter-dependencies. | |
| • | Table dependencies that drive EAM and/or FSM processing logic. | • | Multiple configuration tables with complex table inter-dependencies. | ||
| • | Table dependencies that drive external application processing or logic. |
| Simple | Moderate | Complex | Very Complex | ||
| User Defined Fields | • | Used for simple displaying and/or reporting. | |||
| • | Simple formatting (e.g., date). | ||||
| • | Little to no entry validation required. | • | Used for driving a moderate level of processing logic. | ||
| • | Entry validation required. | • | Used for driving a complex level of processing logic in EAM and/or FSM. | ||
| • | Complex entry validation required that may include logical data combinations. | • | Used for driving a complex level of processing logic in EAM and/or FSM. | ||
| • | Complex entry validation required. | ||||
| • | Includes use in external application processing or logic. |
| Simple | Moderate | Complex | Very Complex | ||
| Reports | • | Minimal modifications to an existing report. | |||
| • | Simple custom new report. | • | Modifications to an existing report with new additional fields and alignment or formatting changes. | ||
| • | Stand-alone report that requires joins of multiple tables. | • | Custom report with multiple trigger events. | ||
| • | Report that requires complex joins of multiple tables. | ||||
| • | Complex data selection, detail levels, and sorting options. | · Combination of external application and EAM data for report generation. |
| Simple | Moderate | Complex | Very Complex | ||
| Interfaces | • | Single transaction to be posted in EAM. | |||
| • | Simple error reporting. | ||||
| • | No restart functionality required. | ||||
| • | One output file created. | ||||
| • | Little or no translations. | ||||
| • | Data read from a few tables. | ||||
| • | Simple batch processing. | ||||
| • | One file to one EAM transaction. | • | A few EAM transactions with minimal flow decisions. | ||
| • | Moderate level of error reporting. | ||||
| • | Moderate restart functionality. | ||||
| • | Moderate number of tables accessed. | ||||
| • | One or more output files created. | ||||
| • | Multiple field/table translations. | ||||
| • | Multiple files and/or formats to one or more EAM transactions. | • | Many EAM transactions and/or complex data conditions. | ||
| • | Complex error, control, and audit reporting required. | ||||
| • | Significant restart functionality. | ||||
| • | Several output files are created. | ||||
| • | Complex processing. | ||||
| • | Requires user exits. | ||||
| • | Significant data translation required. | ||||
| • | Interfaces multiple files to one or more EAM transactions. | • | Significant business logic and decision points. | ||
| • | Complex data translation required. | ||||
| • | End-to-end restart functionality. | ||||
| • | Interface will include updates in multiple systems. | ||||
| • | Cross-transactional data dependencies. |
| Simple | Moderate | Complex | Very Complex | ||
| Extensions / Enhancements | • | User exit is available and is frequently used on similar implementations. | |||
| • | Requires simple effort to understand functionality. | • | User exit is available, but not frequently used. | ||
| • | Requires moderate effort to understand functionality. | ||||
| • | Moderate code changes required. | • | New user exit(s) required. | ||
| • | Significant research is required to design the enhancement. | ||||
| • | Significant code changes required. | • | Requires existing base code to be modified. | ||
| • | Involves complex programming with multiple screens and sub-screens. | ||||
| • | Composed of multiple complex objects. |
| Simple | Moderate | Complex | Very Complex | ||
| Workflows | • | Few changes to an existing business object. | |||
| • | Simple business object code. | ||||
| • | Simple attributes. | ||||
| • | Standard tasks available in workflow template. | • | Moderate number of steps to be created. | ||
| • | Moderate number of attributes to implement. | ||||
| • | Uses standard available module calls. | ||||
| • | Requires creation of minimal roles with custom functions. | ||||
| • | Minor event triggering for workflow handling. | • | Requires functionality like charts, maps, wizards, etc. | ||
| • | Built some simple Custom Controls to accommodate client’s requirements. | ||||
| • | Includes dynamic editing of table data and updates the system of record. | ||||
| • | Includes display of some popup dialog on select or hover on a chart or map. | ||||
| • | Includes navigation between the pages with multiple parameters. | ||||
| • | Requires use of a third-party APIs to achieve certain type of charts and controls. | ||||
| • | Requires new windows with complex formatting. | ||||
| • | New functionality/ business logic or multiple subroutines. | • | Converts a table/chart to PDF and downloads. | ||
| • | Usage of cookies or variants for session/data storage and its usage across the pages. | ||||
| • | Accesses data from some external sources. | ||||
| • | New functionality/ business logic or multiple subroutines. | ||||
| • | Composed of multiple objects. |
| Simple | Moderate | Complex | Very Complex | ||
| Forms | • | Uses simple controls (e.g., lists, tables, grid, etc.). | |||
| • | Navigation between pages with minimal parameters. | ||||
| • | Simple binding to the UI controls. | ||||
| • | Simple layout or layout changes. | ||||
| • | One main window with only a few elements. | ||||
| • | Minor changes to an existing program. | • | Uses a few dialogs and popups to display additional information. | ||
| • | Requires functionality like search, sort, filters, validations for input fields, etc. | ||||
| • | Requires a formatter to convert data in the user readable format. | ||||
| • | Complex layout with multiple windows. | ||||
| • | May require new windows with some format changes. | • | Requires functionality like charts, maps, wizards, etc. | ||
| • | Built some simple Custom Controls to accommodate client’s requirements. | ||||
| • | Includes dynamic editing of table data and updates the system of record. | ||||
| • | Includes display of some popup dialog on select or hover on a chart or map. | ||||
| • | Includes navigation between the pages with multiple parameters. | ||||
| • | Requires use of a third-party APIs to achieve certain type of charts and controls. | ||||
| • | Requires new windows with complex formatting. | ||||
| • | New functionality/ business logic or multiple subroutines. | • | Converts a table/chart to PDF and downloads. | ||
| • | Usage of cookies or variants for session/data storage and its usage across the pages. | ||||
| • | Accesses data from some external sources. | ||||
| • | New functionality/ business logic or multiple subroutines. | ||||
| • | Composed of multiple objects. |
| Simple | Moderate | Complex | Very Complex | ||
| Conversions | • | One one-to-one data with limited data variations. | |||
| • | Limited field/data translations. | ||||
| • | Basic validation and error processing. | ||||
| • | Simple record counts for balancing. | ||||
| • | Requires no data clean-up. | ||||
| • | Small data volume. | ||||
| • | Restart mechanism needs minimal effort. | ||||
| • | None to simple dependencies on other converted data. | • | Limited variations of data formatting. | ||
| • | Limited conditional constructs. | ||||
| • | Some table/field translations. | ||||
| • | Summary control reports required for balancing. | ||||
| • | Requires some data clean-up. | ||||
| • | Moderate number of records to be converted. | ||||
| • | Minimal dependencies on other converted data. | • | Many files to one or more transactions. | ||
| • | Sequencing based on data conditions. | ||||
| • | Complex validations and error processing. | ||||
| • | Requires detailed control calculations and reports for balancing. | ||||
| • | Requires extensive data clean-up. | ||||
| • | Requires error logs. | ||||
| • | Significant number of records to be converted. | ||||
| • | Complex restart mechanism required. | ||||
| • | Multiple dependencies on other converted data. | • | Complex file structures. | ||
| • | Composed of multiple objects. | ||||
| • | High number of records to be converted. | ||||
| • | Significant performance requirements during conversion cut over. | ||||
| • | Complex dependencies on other converted data. |
Forms
File details come from the government source that posted it. Updated .