Attachment A_Mandatory and Desirables B-50780.xlsx
XLSX spreadsheet 298 KB Posted
- Attached to
- Aeronautics Program Management System(APMS) RFP
- Solicitation number
- 26-494DOT-FINAD-B-50780
- Issued by
- Illinois
About this file
This document is a mandatory and desirable qualifications attachment (Attachment A) for the Illinois Department of Transportation's (IDOT) Aeronautics Program Management System (APMS) RFP, which seeks to replace the agency's current databases and processes with a new software solution. The RFP requires vendors to respond to 25 mandatory requirements without evidence (which require only an "Agree/Met" checkbox), 20 mandatory requirements with evidence (requiring substantiating documentation), and 84 desirable requirements with varying point values ranging from 10 to 150 points. The mandatory requirements without evidence address core system functionality including user access administration, multi-level role configuration, code key management, application validations, project dashboards, notification capabilities, document management, eForms configuration, Windows Operating System and web browser compatibility, Illinois Information Technology Accessibility Act (IITAA) compliance, internet accessibility, historical data search, workflow engine functionality, comprehensive audit features, data conversion from legacy systems, access to test/QA/production environments, OKTA integration for identity management, API and data integration capabilities, data dictionary provision, vendor testing protocols, user acceptance testing support, system rollout planning, performance testing, and mandatory reporting capabilities as specified in Attachment C.
The mandatory requirements with evidence focus on SLA (Service Level Agreement) compliance across eight sections covering support management, service availability, incident response, service maintenance, data management, information security, and service reliability, requiring vendors to provide documentation on 24/7/365 monitoring, Tier 2 support procedures, defect handling protocols, monthly performance reporting, root cause analysis procedures, severity level response and resolution times, 99.9% uptime availability agreements, credit percentages for unmet uptime, incident categories and responses, security patch application processes, data management policies, security audit procedures, PII protections, disaster recovery testing, and business continuity plans. The desirable requirements encompass advanced administrative functionality, audit capabilities, airport management features including FAA Airport Data and Information Portal (ADIP) integration, application usability and configurability features, company profile and experience documentation, data conversion methodologies, grant management functions, implementation deliverables and project management approaches, infrastructure capabilities, pilot and aircraft registration and online payment processing, project finance and line item management, program/project management features, security and user management enhancements, implementation team skills and experience requirements, training services, and workflow functionality including DocuSign integration and task tracking.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| c2d-vendor-answer-sheet-v-26-2.pdf | ||
| RFP APMS B-50780 Updated~1.docx | DOCX document | |
| vendor ipg-active-registered-vendor-disclosure forms-b B-50780.docx | DOCX document | |
| Attachment G Context Level Diagram B-50780.xlsx | XLSX spreadsheet | |
| vendor-disclosure-forms-a B-50780.docx | DOCX document | |
| Attachment D Demo Script B-50780.docx | DOCX document | |
| BEP Utilization Plan~8.pdf | ||
| Attachment C Mandatory Reports Matrix B-50780.xlsx | XLSX spreadsheet | |
| Attachment B Pricing B-50780~1.xlsx | XLSX spreadsheet | |
| Attachment F Service Level Agreement B-50780.docx | DOCX document | |
| Vendor Q.A.26-494DOT-FINAD-B-50780.xlsx | XLSX spreadsheet | |
| Attachment E Customer Reference Questionnaire B-50780.docx | DOCX document | |
| information-and-technology-request-for-proposal-offer B-50780.pdf | ||
| c2d-vendor-guidance B-50780.pdf | ||
| BEP_WaiverRequest_Review~3.pdf |
Show all 15
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
Response Code Descriptions
| Aeronautics Program Management System RFP | ||
| Response Code Descriptions | ||
| Response Code for ‘Indicator' | Response | Description |
| Y | Yes | Requirement will be met by proposed software; proposed software is operational in production use at other clients; can be demonstrated in base software. |
| N | No | Requirement is not available or will not be met by proposed software. |
| C1 | Customization 1 | Requirement will be met by customizing existing software or through the use of software tools provided in base product at no cost to the agency. |
| Note the following information in the narrative column next to this response: | ||
| - Description of customization/configuration required | ||
| - Estimated level of complexity (small, medium, large) | ||
| - Estimated duration of effort | ||
| C2 | Customization 2 | Requirement will be met by customizing existing software for an additional cost to the agency. |
| Note the following information in the narrative column next to this response: | ||
| - Description of customization/configuration required | ||
| - Estimated level of complexity (small, medium, large) | ||
| - Estimated duration of effort | ||
| - Estimated associated costs (must be included in RFP pricing details) | ||
| P | Planned | Requirement will not be met/provided, but is planned for a future release. Please specify target date for future release. |
| D | In Development | Requirement will be met by proposed software that is currently in development, in beta, or planned for release in the next 6 months. Please specify planned release date. |
| 3 | Supplied by Third Party | Requirement will be met by third-party software included in proposed solution. Please specify third party software and integration requirement being proposed. |
Mandatory without Evidence
| Attachment A - Mandatory and Desirable Qualifications |
| Mandatory Requirements without Evidence: |
Please read each item below carefully and check “Agree” indicating acceptance for each requirement. An Offeror that does not check “Agree” will be disqualified and the rest of the proposal will not be scored. These Mandatory Requirements shall be included in any contract resulting from this solicitation.
| Mandatory Requirements | |||
| ID | Category | Requirement Detail | Agree/Met |
| 1 | Administration | The application must allow system administrators to inactivate user access upon termination of employment or based on other user-defined criteria. | |
| 2 | Administration | IDOT Administrators must be able to configure/modify multiple levels of user access (roles). Users are limited to viewing/editing/reporting only data relevant to their assigned role. | |
| 3 | Administration | The solution must provide the ability for IDOT Administrators to maintain code keys and code values. | |
| 4 | Application | The system must be designed with validations, errors, and warnings to improve the user experience. | |
| 5 | Application | The solution must include project dashboards/home pages for users per agency specifications. | |
| 6 | Application | The system must be capable of sending notifications to users. | |
| 7 | Application | The solution must have the ability to manage/store/link to documents. | |
| 8 | Application | The solution must utilize eForms to be configured based upon IDOT specifications. | |
| 9 | Application | The application must function on a Microsoft Windows Operating System (Windows 10 and higher) and should be accessible through modern web browser technologies available in the general marketplace. | |
| 10 | Application | All screens of the application must be in accordance with the Illinois Information Technology Accessibility Act (IITAA) (http://www.dhs.state.il.us/page.aspx?item=32765) | |
| 11 | Application | The application must be accessible over the Internet. | |
| 12 | Application | The application must provide the ability to search historical data. | |
| 13 | Application | The solution must include a workflow engine/process which will route workflows based on roles within the solution. | |
| 14 | Audit | The application must provide audit features for all transactions in the solution, including but not limited to, all historical changes, i.e. created by, last modified by, last modified date, change details, etc. | |
| 15 | Audit | The application must prevent deletion or alteration of audit records, except as part of a system administered archival process. | |
| 16 | Data Conversion | The offeror must be able to convert data from legacy systems. |
| 17 | Infrastructure | The Agency must have access to the following environments: Test, QA, and Production when initially testing the SaaS and when testing new functionality or bug fixes. The specifications of the test/QA environment(s) should match production for testing purposes. |
| 18 | Interface/Integration | The solution must integrate with the State of Illinois's standard for external identity management -- OKTA -- across all modules of the solution. This integrated password management will adhere to State of Illinois security policies such as minimum password length, password complexity, changing of password timeframe, etc. |
| 19 | Interface/Integration | The application must have the ability to push/pull data to/from multiple internal and external sources (i.e. API, web services, data marts, other applications, etc.) for real-time analysis and reporting. |
Approved methods include REST API or web service secured with TLS1.2+, or data transfer into MS SQL Server databases over a secure connection encrypted with TLS1.2+.
IDOT uses Microsoft Azure SQL Server databases, and any solutions provided under this requirement must be compatible with these technologies (data pushed into IDOT databases).
| 20 | Project Deliverables | The vendor must provide the department with a data dictionary which clearly describes the location, structure, meaning and usage of all data elements within the vendor's database. |
| 21 | Project Deliverables | The vendor must conduct thorough testing, including but not limited to, unit, integration, and regression before releasing any code to the department's test environment. Documentation of vendor testing must be provided at the department's request. |
| 22 | Project Deliverables | The vendor must allow the department dedicated time and support to conduct user acceptance testing (UAT) at each project milestone, phase, deliverable, or sprint. The duration of the UAT period should be in proportion to the functionality being delivered. |
| 23 | Project Deliverables | The vendor must provide a system rollout plan to coordinate parallel processing and go-live activities. The plan should include a check-list or calendar with daily/weekly tasks required to ensure a smooth cutover as well as agreed upon criteria for go-live (no critical defects, etc.). |
| 24 | Project Deliverables | The vendor must conduct performance testing prior to go-live/cutover to ensure response times, load speeds, and transaction processing speeds are acceptable to the department based on the number of expected concurrent users. |
| 25 | Reporting / Dashboard | The system must include the reports specified in Attachment C - Mandatory Reporting Matrix. |
Mandatory with Evidence
| Attachment A - Mandatory and Desirable Qualifications |
| Mandatory Requirements with Evidence: |
Please check “Met” to each of the mandatory requirements for the proposed solution. An Offeror that does not provide substantiating evidence for each requirement will be disqualified and the rest of the proposal will not be scored. These Mandatory Requirements shall be included in any contract resulting from this solicitation. Please provide substantiating evidence in your Proposed Technical Solution. Use the column on the right to provide an answer and/or indicate the section and page number where your evidence/response to each item may be found. The State will evaluate Offeror’s evidence/response to verify the mandatory requirement is met.
| Mandatory Requirements | |||||
| ID | Category | Requirement Detail | Agree/Met | Vendor Response | IT Selection Committee Members Reviewed and Approve |
| 1 | Project Deliverables | Provide documentation demonstrating what is included in the warranty by the vendor to ensure the solution is free from defects after the implementation is complete. | |||
| 2 | Section 1 SLA | For Section 1 (Support Management) of the Department’s Service Level Agreement (Attachment F) describe how the application is monitored 24/7/365 . | |||
| 3 | Section 1 SLA | For Section 1 (Support Management) of the Department’s Service Level Agreement (Attachment F) describe how critical requests are handled via the “service desk” Tier 2 support. | |||
| 4 | Section 1 SLA | For Section 1 (Support Management) of the Department’s Service Level Agreement (Attachment F) describe what is the policy/procedure for the service desk in regard to defect handling and escalation procedures. | |||
| 5 | Section 1 SLA | For Section 1 (Support Management) of the Department’s Service Level Agreement (Attachment F) describe how a Monthly Service Support SLA Performance Report is provided. | |||
| 6 | Section 1 SLA | For Section 1 (Support Management) of the Department’s Service Level Agreement (Attachment F) describe how a Root Cause Analysis is provided for the highest Severity Level outages and bugs. | |||
| 7 | Section 1 SLA | For Section 1 (Support Management) of the Department’s Service Level Agreement (Attachment F) provide a table which identifies Severity Level, initial response time from Agency alert of issue or outage, how to communicate the issue or outage (call vs. e-mail vs. use of vendor product), and resolution times. Please use Table 5 in Section 1.4 in Attachment F as example. | |||
| 8 | Section 2 SLA | For Section 2 (Service Availability) of the Department's Service Level Agreement (Attachment F) describe how will the analytical dashboard view or equivalent reports for the monthly service availability SLA performance will be provided. | |||
| 9 | Section 2 SLA | For Section 2 (Service Availability) of the Department's Service Level Agreement (Attachment F) provide agreement to the Service Level Objectives/Service Qualitative Objectives of 99.9% as defined in Section 2.4 in Attachment F. | |||
| 10 | Section 2 SLA | For Section 2 (Service Availability) of the Department's Service Level Agreement (Attachment F) describe the credit percentage for services to the Agency if the Uptime Availability is not met. See Section 2.6 on Attachment F for further detail. | |||
| 11 | Section 3 SLA | For Section 3 (Incident Response) of the Department's Service Level Agreement (Attachment F) identify the types of actions which will be taken in the event of service interruptions. Define the categories of incidents and how the providers will respond to each (ITIL incident types may serve as basis for this information). See more description in Section 3.1 on Attachment F. | |||
| 12 | Section 3 SLA | For Section 3 (Incident Response) of the Department's Service Level Agreement (Attachment F) describe what systems/applications are in place to manage/monitor for incidents. | |||
| 13 | Section 3 SLA | For Section 3 (Incident Response) of the Department's Service Level Agreement (Attachment F) provide agreement to notify the Agency within 24 hours of any information breach or other security incident which impacts the State’s data. | |||
| 14 | Section 5 SLA | For Section 5 (Service Maintenance) of the Department's Service Level Agreement (Attachment F) describe the processes in place for applying critical security patches, maintenance patches, and release management procedures including who applies the patches and when they are applied. | |||
| 15 | Section 6 SLA | For Section 6 (Data Management) of the Department's Service Level Agreement (Attachment F) describe data management policies and practices for: 1) data storage, 2) data access, 3) data retention, 4) data ownership, and 5) data disposal. | |||
| 16 | Section 6 SLA | For Section 6 (Data Management) of the Department's Service Level Agreement (Attachment F) provide agreement to the Roles and Responsibilities defined in Section 6.2 and Section 6.3 on Attachment F. | |||
| 17 | Section 7 SLA | For Section 7 (Information Security) of the Department's Service Level Agreement (Attachment F) describe information security policies and practices for 1) access controls, 2) security audits, and 3) confidentiality requirements and protections for individual privacy and safeguards for Personally Identifiable Information (PII). | |||
| 18 | Section 7 SLA | For Section 7 (Information Security) of the Department's Service Level Agreement (Attachment F) provide agreement that all environments will be made available to the State security team to conduct periodic reviews (i.e vulnerability scans) during the contract period. | |||
| 19 | Section 8 SLA | For Section 8 (Service Reliability) of the Department's Service Level Agreement (Attachment F) describe disaster recovery policies and processes for 1) proof of annual disaster recovery testing and responses to any issues discovered. | |||
| 20 | Section 8 SLA | For Section 8 (Service Reliability) of the Department's Service Level Agreement (Attachment F) describe implementation plans for 1) emergency response, 2) backup operations, and 3) post disaster recovery activities which ensure the availability of critical information resources and continuity of operations in emergency situations. |
Desirables
| Aeronautics Program Management System RFP |
| Attachment A - Mandatory and Desirable Qualifications |
| Desirable Requirement Responsive Elements: |
Please explain if your organization meets or will meet each of the desirable elements within Attachment A using the appropriate response code from the “Response Code Description” tab of Attachment A. Use the Vendor Response column to provide a narrative of how the solution meets the requirement and/or indicate the section and page number of your proposal where your response to each item may be found. The Desirable Requirements and the Offeror’s responses shall be included in any contract resulting from this solicitation.
| Desirable Requirement Responsive Elements | |||||
| ID | Category | Requirement Detail | Response Code | Vendor Response | Max Score |
| 1 | Administrative Functionality | Describe how the solution offers administrative users the ability to determine which fields are visible and editable based on roles. | 50 | ||
| 2 | Administrative Functionality | Describe how the solution allows for administrative users to configure validation rules, without programming, applicable to all forms of data entry. Include the ability to customize messages for validation rules. (e.g. Validation rules can apply to validations within ranges, datatypes and required fields, etc.) | 50 | ||
| 3 | Administrative Functionality | Describe how the solution provides a method for Administrators to configure (create, modify and delete) interfaces with no coding required. | 50 | ||
| 4 | Audit Functionality | Describe how the application has the ability to export audit data. | 40 | ||
| 5 | Audit Functionality | Describe how the application provides archive and restoration processes for audit logs. | 40 | ||
| 6 | Audit Functionality | Describe how the Vendor will help facilitate State of Illinois Internal Auditors (or external auditors selected by the Agency) to audit the application processes, data, and documentation on a periodic basis. The audits will be coordinated between the Vendor and the Agency. | 35 | ||
| 7 | Audit Functionality | Describe how the solution includes auditable logs on all system edits, deletions, and additions. Log should include: |
a. The date and time an auditable event occurs.
b. The objects affected.
c. The identity and role of the actor responsible for the activity. In scenarios where an identity has multiple roles or multiple roles authorize the same activity, the role used for authorization should be indicated.
d. The outcome (success or failure) of the activity.
e. The audit history of a particular record (original data retained).
| f. The location (IP address) of where the activity is occurring. | 35 | |||
| 8 | Airport Management | Describe how the solution can integrate with FAA's Airport Data and Information Portal (ADIP) and can sync up with federal airport data submitted by the airport. | 31 | |
| 9 | Airport Management | Describe how the solution offers the ability to maintain airport information for public use airports including, but not limited to: |
- Airport category (code table)
| - Airport contacts | 30 | ||
| 10 | Airport Management | Describe how the solution offers the ability to create and maintain airport/RLA details and inventory per current FAA's 5010 inpection requirements. The inspection should include (but is not limited to) these fields: |
- General airport/RLA information
- Services and facilities
- Based aircraft and operations
- Runway information
- Clear approaches
- Runway conditions
- Lighting conditions
- Obstructions
- Fuel system conditions
| - Runway Marking | 25 | |||
| 11 | Airport Management | Describe how the solution has the ability to create and distribute airport/RLA Inspection reports as necessary. | 25 | |
| 12 | Application Usablity and Configurability | Describe how the application provides ability to query and filter key application data (active and historical) through keyword, tags and wildcards. | 15 | |
| 13 | Application Usablity and Configurability | Describe how the solution utilizes responsive web design where the interface dynamically adapts to the user's device (i.e different screen sizes, orientations, layouts, and platforms). | 15 | |
| 14 | Application Usablity and Configurability | Describe how the solution allows users to upload or import documents (in various formats) when required (i.e. invoices, pay items, etc.). | 15 | |
| 15 | Application Usablity and Configurability | Describe how the solution provides online help functionality for both system admins and end-users. The help should be customizable, built into every screen; and is indexed, searchable, and context sensitive. The online help should be updated to support any customizations made to the system. | 15 | |
| 16 | Application Usablity and Configurability | Describe how the solution has the ability to access all historical records without degraded system response times to users. | 15 | |
| 17 | Application Usablity and Configurability | If the application includes multiple modules, describe how the application will have a similar look and feel between modules and appear to be a uniform solution. | 15 | |
| 18 | Application Usablity and Configurability | Describe how the solution is designed for a profile-based user experience (Home page, role-oriented menus and reports, etc.). | 15 | |
| 19 | Application Usablity and Configurability | Describe how the solution has the ability to create ad-hoc reports on-demand with the ability to save and share those reports across users (including the ability to pick and choose specific data for each ad-hoc report). | 15 | |
| 20 | Application Usablity and Configurability | Describe how the system includes intuitive and easy to use reporting capabilities, including the ability to export reports into various agency specified formats (Excel, PDF, etc.). | 15 | |
| 21 | Application Usablity and Configurability | Describe how the solution provides users the ability to configure favorites, including but not limited to, reports, for quick access. | 15 | |
| 22 | Company Profile | Describe how Offeror will provide all requested client references information detailed in Section F.5 of the RFP. | 15 | |
| 23 | Company Profile | Describe their company profile and history, including but not limited to, the following: |
a. Company startup date, State of incorporation and number of years, company headquarters location, data center location, customer support (help desk) location(s)
b. Company organizational structure (management, implementation, product development, support, etc.), total employee head count and total contractor head count (if applicable)
c. Approach to support once the implementation is complete
d. Company philosophy, leadership vision, account and customer relationship management procedures
e. What makes the company and solution distinguishable from the competition
f. Include any relative published articles, awards, rankings, etc. about company and/or proposed solution
| g. Brief financial profile | 10 | ||
| 24 | Company Profile | Describe their experience in this software space (Aeronautic Project Management System) including but not limited to the following: |
a. Number of years of experience in this specific solution space
b. Date of very first software application release
c. The total number of software versions released to date for proposed solution
| d. Describe any implementation partners | 10 | ||
| 25 | Company Profile | Describe statistics on the vendor's client base, including: |
a. Number of clients who have installed and are currently using the proposed solution in production
b. Percentage of clients by sector (e.g. private, federal, state, county)
c. Percentage of clients by size (e.g. small, medium, large – provide description or scale of sizes)
d. Average life cycle for project implementation from start to finish for current client base
e. Percentage of clients on current release of proposed solution
| f. A description of any non-performing or canceled contracts | 10 | |||
| 26 | Data Conversion | Describe the vendor's approach, methodology, plan, and tools used in data conversion/migration activities to populate the proposed solution including data validation practices and criteria for acceptance/sign-off. It is assumed the vendor and IDOT will have the ability to validate and audit migrated data. | 150 | |
| 27 | Grant Management | Describe how the solution provides the ability to create and maintain grant data which should include (but not limited to) these fields: |
- Federal Grant (project) number
- Grant start date
- Grant end date
- Grant extension date
- Grant amount
- Federal/State/Local split type (ie 90/5/5, 100, 95)
| - Grant status | 30 | |||
| 28 | Grant Management | Describe how the solution provides the ability to associate a grant with projects and allocate an amount of the grant funds to each associated project. Total allocation cannot exceed the total grant amount. | 30 | |
| 29 | Grant Management | Describe how the solution allows users to assign a priority sequence (i.e. oldest first) for expenditure against grants, for each project. | 30 | |
| 30 | Grant Management | Describe how the solution, for each grant, will prevent or warn against expenditures with service date past the grant end date or extension date, if applicable. | 30 | |
| 31 | Grant Management | Describe how the solution prevents expenditures past the allocated project-grant amount. | 30 | |
| 32 | Implementation Deliverables | Describe how the vendor will provide a detailed project plan broken into phases/deliverables including project initiation (discovery, fit gap, and design), development (configuration and build), data conversion and interfaces, vendor and user acceptance testing, training, Department readiness, implementation/go-live, warranty, and support. The project plan should include all required Department project team resources (by role) including estimated time commitments (in percentage). The project plan should include milestones and deliverables with dates. The project plan should take into consideration availability of department subject matter experts and avoid department deliverables during their peak working times. | 21 | |
| 33 | Implementation Deliverables | Describe how the vendor will provide an implementation plan, including: |
a. The approach and project methodology used in Vendor’s implementations, both initial deployment and upgrades during implementation of solution
b. The steps required to implement the proposed solution, including acceptance criteria for each milestone/deliverable
c. The Department resources, skills, and personnel recommended for implementation
d. The vendor’s process, methodology, and frequency of software enhancements and upgrades (during the implementation and in support)
e. The type of system documentation provided to reflect the base system and department's customizations (provide examples)
| f. The vendor should include at least two case studies with critical path timelines of recent customer implementations. | 20 | |||
| 34 | Implementation Deliverables | Explain how a requirement traceability matrix (RTM) will track the department's requirements throughout the life-cycle of the project. | 20 | |
| 35 | Implementation Deliverables | Describe how the vendor will implement a change management process and/or tools used to request, gain approval, and track changes. | 20 | |
| 36 | Implementation Deliverables | Describe the type of secure platform the vendor and department can use during the project for communication, document sharing, defect reporting, etc. (i.e. Teams or SharePoint). | 15 | |
| 37 | Implementation Deliverables | Describe the risk and issue management process and/or tools used to report and track risks, issues, and problems reported by clients, including average time for resolution of an issue and escalation procedures. Include descriptions of the most common challenges encountered during implementation and how each has been resolved. | 15 | |
| 38 | Infrastructure | Describe how the vendor application can integrate real-time with external data sources (i.e. data marts, other applications). | 50 | |
| 39 | Infrastructure | Describe how the vendor will provide a high-level architecture model/diagram representative of the solution. This should include all the environments within the solution (production, QA, test, etc.). | 50 | |
| 40 | Infrastructure | Describe how application has the ability to host an expanded document storage solution. The offeror’s solution should accommodate for at least, but not limited to, ten (10) years of storage capabilities, which roughly correlates to 500 GB. | 50 | |
| 41 | Pilot / Aircraft Management | Describe how the pilots will be able to register online their Federal Airman Certificate with the State and provide the required information. | 11 | |
| 42 | Pilot / Aircraft Management | Describe how the aircraft owners will be able to register (online) their Federal Aircraft Certificate and provide the required information. | 10 | |
| 43 | Pilot / Aircraft Management | Describe how aircraft owners will be able to renew registration (online). | 10 | |
| 44 | Pilot / Aircraft Management | Describe how users will be able to print/reprint pilot and aircraft registration certificates. | 10 | |
| 45 | Pilot / Aircraft Management | Describe how pilots will be able to pay the pilot registration fee online. | 10 | |
| 46 | Pilot / Aircraft Management | Describe how aircraft owners will be able to pay the aircraft registration fee online. | 10 | |
| 47 | Pilot / Aircraft Management | Describe how aircraft owners will be able to pay the aircraft renewal fee online. | 10 | |
| 48 | Pilot / Aircraft Management | Describe how IDOT users will be able to enter registrations/renewals/payments received at the office. Pilot and Owner should utilize the same dataset. | 10 | |
| 49 | Pilot / Aircraft Management | Describe how IDOT users will be able to run a report for all registrations/renewals/payment for a specified timeframe. | 10 | |
| 50 | Pilot / Aircraft Management | Describe how IDOT users will be able to bulk print individual certificates or all certificates for a specified timeframe. | 10 | |
| 51 | Pilot / Aircraft Management | Describe how the solution will have the ability to securely process payments using NCR API platform, as approved by the Illinois Department of Transportation. | 10 | |
| 52 | Project Finance | Describe how the solution allows the users to query and display the following appropriation |
(and re-appropriations) data from the IDOT financial system :
- Fiscal Year
- Appropriation # from IDOT financial system (FOA)
- Description
- Appropriation Level (Federal/State/Local)
| - Appropriation Amount from IDOT financial system (FOA) | 25 | ||
| 53 | Project Finance | Describe how multiple budgets can be created and maintained by type and custom description: |
- two types (programmed budget, actual budget -- with adjustments)
| - description of budget | 25 | ||
| 54 | Project Finance | Describe how the solution provides the ability to create and maintain budget line information, such as: |
- Description: (grant # or other funding source)
| - Grant/fund Amount at Federal, State or Local level | 20 | ||
| 55 | Project Finance | Describe how the solution provides the ability to create payment objects and query/display payment data from IDOT financial system (FOA) which should include, but not limited to these items: |
- Associated Line Item
- Grant # (from list of project's grants)
- Split types of the Line Item and Grant should match, otherwise a warning should be issued
- Sequential Schedule # from IDOT financial system (FOA)
- Voucher Number, Date from IDOT financial system (FOA)
- List of Funds (State Appropriation) and dollar amounts for each fund allocated for payment/invoice
- Letter of Credit number - sytem generated per specified requirements.
- Requested payment amount
- Approved payment amount
| - Payment status from IDOT financial system (FOA) | 20 | |||
| 56 | Project Finance | Describe how the solution offers the ability for payments/invoices to be submitted in batch for reimbursement to FAA. | 20 | |
| 57 | Project Finance | Describe how the solution provides the ability to create credit object and query/display credit data from IDOT financial system (FOA) which should include but not limited to these items: |
- Associated Line Item
- Sequence number
- Date from IDOT financial system (FOA)
- Description
| - Fund and dollar amount from IDOT financial system (FOA) | 20 | ||
| 58 | Project Finance | Describe how the solution provides the ability to create receipt object and query/display receipt data from IDOT financial system (FOA) which should include but not limited to these items: |
- Associated Line Item
- Sequence number
- Date from IDOT financial system (FOA)
- Description
| - Fund and dollar amount from IDOT financial system (FOA) | 20 | |||
| 59 | Program / Project Management | Describe how internal (IDOT) users and external users (airport sponsors/consultants) can submit prospective programs for funding consideration. | 15 | |
| 60 | Program / Project Management | Describe how approved/finalized budget items (description and amount) can be converted to project items. | 15 | |
| 61 | Program / Project Management | Describe how the solution provides the ability to create and maintain project line items which should include (but not limited to) these fields: |
- Line Item #,
- Obligation # (from IDOT financial system (FOA))
- Project Line Category
- Federal Category for Outlay Report and Request for Reimbursement for Construction Programs (SF-271)
- Contract # (FOA)
- Vendor ID/Desc (FOA)
- Item Description
- Federal/State/Local split (ie 90/5/5, 100, 95)
- State adminstrative costs
| - Line Item Status (Active, Final, Closed) | 15 | |||
| 62 | Program / Project Management | Describe how the solution provides the ability to maintain a list of line item categories. These categories would also need to be cross-referenced via code table for federal reporting: Outlay Report and Request for Reimbursement for Construction Programs (SF-271). | 15 | |
| 63 | Program / Project Management | For Construction (category) Line Items, describe how the solution provides the ability to enter the following: |
- Contract Line Item Description
- Federal/State/Local obligation amounts
| - Federal state and local split percentages | 15 | |||
| 64 | Program / Project Management | Describe how the solution provides the ability to attach Engineering Amendments Line Items to existing non-construction Line Items. | 15 | |
| 65 | Program / Project Management | Describe how the solution allows the users to query/display Pay Items from IDOT's Construction Management system (CMMS); which should include, but not limited to these items: |
- Associated Construction line Item or change order
- CMMS reference ID
- Vendor ID
- Contract number
- Payment amount(s)
- Payment date(s)
| - Description | 10 | |||
| 66 | Program / Project Management | Describe how an external user could submit an invoice as a requested payment. | 10 | |
| 67 | Program / Project Management | Describe how the solution provides the ability to create and maintain project information, which should include (but not limited to) these fields: |
- Project Group
- Airport
- Description
- Project status
- Program year
- Appropriation
- Federal Status
- State Status
- Notes
- Program Letter and date
- Pre-design meeting date
- letting date/target date
- Award date
- Executed agency agreement date
| - NTP Date | 10 | |||
| 68 | Program / Project Management | Describe how the solution provides the ability for on-screen selection of each of the FAA ranking sytem, National Priority Rating (NPR) worksheet values, which should be used for the calculation and presentation of NPR value for the project. | 10 | |
| 69 | Program / Project Management | Describe how the solution offers the ability to maintain the following project information: |
- Priority Number
- Year Requested
- Project Title
- Project Description
- Project Element details
- Project Justification
- Estimated Cost (Federal, State, Local)
| - Attached required documentation | 10 | |||
| 70 | Program / Project Management | Describe how the solution offers the ability to designate contact information for each project including FAA contacts, IDOT Aeronautics Owners, and Airport Contacts. | 10 | |
| 71 | Security and User Management | Describe how the application will end a user session after a prescribed time period of inactivity or if that user has intitiated a separate session on different device or browser. | 40 | |
| 72 | Security and User Management | Describe the solution's authentication and application (security) management capabilities, including how role-based permissions are administered within the application. These permissions should include, but not be limited to: |
- Admin: Full access to all system functionalities and resources.
- Editor: Ability to create, edit, and delete content.
- Viewer: Ability to view content but not make changes.
| - Guest: Limited access, potentially only to view specific content. | 40 | |||
| 73 | Security and User Management | Describe how the application offers customizable access to specific fields, resources, and functionalities, ensuring that users only have access to what they need for their job duties. | 35 | |
| 74 | Security and User Management | Desribe how the application streamlines user management by grouping users with similar responsibilities into roles, rather than managing permissions individually. | 35 | |
| 75 | Skills and Experience - Implementation Team | Describe the skills and experience of the proposed implementation team who will be assigned to the department, including: |
a. Resumes/curriculum vitae for all
b. For each proposed team member, include their skills by role such as project management, business analysis, technical capabilities, training, interfaces, conversions, architecture, testing, quality assurance, technical writing, reporting.
c. For each proposed team member, include prior customer account experience within the last three (3) years similar to requested supplies and services
d. For each proposed team member, indicate if member is an employee or subcontractor
| e. Describe the actions vendor will take if an employee or contractor is unable to perform to the requirements outlined in the contract | 55 | ||
| 76 | Skills and Experience - Implementation Team | Describe the vendor's ability to meet the following implementation team requirements: |
- The team assigned to the department in Offeror’s proposal should be the same personnel who continue working on this solution.
- Member(s) of the implementation team should not be removed or replaced by the Offeror without written review and approval of a department representative.
| - If a member of the implementation team is removed or replaced, they should have equivalent skills and experience to the person being replaced. | 50 | |||
| 77 | Training Services | Describe how the vendor can provide System Administrator training, including all training materials and documentation. Please explain how the solution would offer online (in application) help as well as how the vendor would offer presentation materials, lecture notes, video tutorials and follow-up question and answer content. | 40 | |
| 78 | Training Services | Describe how the vendor can provide train-the-trainer (Power user) training. Please explain how the train-the-trainer solution would offer online (in application) help as well as how the vendor would offer presentation materials, lecture notes, video tutorials and frequently asked question (FAQ) content -- all with the purpose to enable IDOT trainers to facilitate the end user training process. | 35 | |
| 79 | Workflow | Describe how the solution includes workflow functionality to track progress through various business processes including a progress indicator displaying steps involved in the process and current status. | 25 | |
| 80 | Workflow | Describe how the solution provides the ability for key users to view, analyze and report on work across all system workflows and reassign steps as needed. | 25 | |
| 81 | Workflow | Describe how the solution provides the ability for administrative users to design workflows as a series of steps and conditions for routing tasks and associated data to user groups/user roles. | 25 | |
| 82 | Workflow | Describe how the solution provides the ability for workflows to include notifications to users or groups of users for workflow status or step completion based upon IDOT configuration with automatically generated links back into the system. | 25 | |
| 83 | Workflow | Describe how the solution provides the ability for workflows to include expected task duration / response due dates and reminder notifications. | 25 | |
| 84 | Workflow | Describe how the solution offers the ability to integrate with Docusign documents and provide real-time tracking of task, status and owner. | 25 |
Sheet1
| Scoring | Category M/D | count | |||||
| Airport Management | current | convert to | Section | Mand w/E | Desirables | ||
| Project Management | SLA | SLA | 2 | 0 | 0 | ||
| Project Line Items | Training Services | Training Services | 3 | 0 | 2 | ||
| Project Finances | Vendor Information | Company Profile & Experience | 4 | 0 | 0 | ||
| Grant Management | Skills and Experience - Implementation Team | 4 | 0 | 2 | |||
| Workflow | Project Deliverables | Project Deliverables | 3 | 0 | 0 | ||
| Aircraft/ Pilot Certification | Administration | Administration | 2 | 0 | 0 | ||
| Application | Application Configurability | 2 | 0 | 0 | |||
| Infrastructure | Project Deliverables | 0 | 0 | ||||
| Authentication and Application Management | Security | Authentication and Application Management | 2 | 0 | 0 | ||
| Application Configurability | Workflow | Workflow | 1 | 0 | 6 | ||
| Audit | administration | Project Management | Project Management | 1 | 0 | 0 | |
| Security | Authentication and Application Management | Grant Management | Grant Management | 1 | 0 | 5 | |
| Data Conversion/Migration | Project Finance | Project Finance | 1 | 0 | 7 | ||
| SLA | Project Line Items | Project Line Items | 1 | 0 | 0 | ||
| Testing | NA (see infrastructure) | Airport Management | Airport Management | 1 | 0 | 4 | |
| Pilot / Aircraft Management | Pilot / Aircraft Management | 1 | 0 | 11 | |||
| Project Deliverables | Reporting / Dashboard | Reporting / Dashboard | 0 | 0 | |||
| Training | Infrastructure | Infrastructure | 2 | 0 | 3 | ||
| Interface/Integration | Interface/Integration | 0 | 0 | ||||
| Data Conversion | Data Conversion | 2 | 0 | 1 | |||
| 0 | 41 | Reqts Count |
File details come from the government source that posted it. Updated .