SP_Attachment-1_GMM Solution Requirements_Final.xlsx
XLSX spreadsheet 46 KB Posted
- Solicitation number
- S-DASOBO-00008713
- Issued by
- Marion County, Oregon
About this file
This document is a Request for Special Procurement for a Grant Management Modernization (GMM) solution by the Oregon Office of Emergency Management (OEM). The GMM solution must be configured to meet federal and state grant requirements for all OEM-administered grant programs, including but not limited to application intake, eligibility, duplication verification, and closeout. The system must have capabilities such as advanced search, predictive analytics, user management, bulk data import/export, and integration with external systems like DocuSign. The solution must meet Oregon's ADA, 504, and 508 compliance standards and have a 97.48% or greater WCAG 'AA' accessibility rating. OEM is seeking a vendor-supported, cloud-hosted solution with a modern technology stack, strong security controls, and high availability. The contract will be awarded to the responsive and responsible proposer whose offer is most advantageous to the state, with pricing, technical capability, and past performance being the key evaluation factors.
The pricing terms and funding details are not provided in this document. It indicates that OEM expects to administer various FEMA grant programs such as Public Assistance, Hazard Mitigation Assistance, and Homeland Security Grant Program, among others. The solution must be able to manage the full grant lifecycle, including compliance tracking, payment processing, and robust reporting capabilities to meet FEMA requirements.
View the file
Other files
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
Data Fields Category Subcategory tc={48C19015-BA49-4AF0-89FA-9E851C932900}: [Threaded comment]
Your version of Excel allows you to read this threaded comment; however, any edits to it will get removed if the file is opened in a newer version of Excel. Learn more: https://go.microsoft.com/fwlink/?linkid=870924
Comment:
| Modify to reflect OEM grant programs | Meets Requirements? | ||
| Applicant Portal | Accessibility | Yes | |
| Application Management | Appeals | No | |
| Communications | Applications | ||
| Finance | Awards | ||
| General | Application Details | ||
| Programs | Closeout | ||
| Reporting | Communications | ||
| System | Compliance | ||
| Technical | Construction | ||
| Contracting & Bid Work | |||
| Data Integrity / Validations | |||
| Data Protection | |||
| Documents | |||
| System | |||
| Eligibility | |||
| General | |||
| Intake | |||
| Inspection | |||
| Integrations | |||
| Notifications | |||
| Payments | |||
| Performance | |||
| Reporting | |||
| Record Retention | |||
| Registration | |||
| Security | |||
| User Help | |||
| User Interface | |||
| Workflow |
Modify to reflect OEM grant programs
Requirements REQUEST FOR SPECIAL PROCUREMENT No. REQ-DASOBO-00034069
SP_ATTACHMENT-1
Grant Management Modernization Requirements
| Software Provider Name: | ||||||
| SaaS Solution Name: | ||||||
| Req # | Category | Subcategory | Priority | Requirement | Solution Meets Requirements (Select One) | Explain |
| 1 | System | General | FEMA Requirement | System must be configured according to the federal and state grant requirements for all ODEM administered grant programs including but not limited to: application intake, eligibility, duplication, verification of eligibility, and closeout. | ||
| 1.1.10 | System | General | Must have | The application must contain an advanced search feature, to enable OEM users the ability to search for contacts, vendors, applications, or any data collection field, etc. | ||
| 1.1.10 | System | General | Must have | System must analyze and process data entered by user to provide customized application opportunities based on user responses to pre-application screening questionnaire | ||
| 1.1.11 | System | General | Must have | System must allow for changes and flexibility for future improvements, as program requirements and grant funding needs change. | ||
| 1.1.11 | System | General | Must have | System must have customer relationship management capabilities to eliminate the need to re-enter customer information multiple times. | ||
| 1.1.12 | System | General | Nice to have | System must use predictive analytics to provide insight to OEM staff on potential new applicants, contact groupings, segments, units, etc. | ||
| 1.1.13 | System | General | Must have | System must be able to manage the following users and processes: |
-applicants and application management -subrecipients and subrecipient award -requests for information -requests for payment
| 1.1.14 | System | General | Nice to have | System must track emergency incident response equipment and allow methods for requests for new equipment and decommissioning of obsolete equipment. |
| 1.1.2 | System | General | Must have | System must have the option to apply rounding rules based on financial amounts, with the choice to calculate grants to the whole dollar or decimals. |
| 1.1.3 | System | General | Must have | System must track the date and time of data field changes, via a timestamp, and have a history tab available for users to verify data changes. |
| 1.1.4 | System | General | Nice to have | System shall allow for random selection of specified percentage of subgrouping of records for marking and inclusion in audits. |
| 1.1.5 | System | General | Must have | System must support bulk data import and validation of data. System must support bulk data exports. |
| 1.1.6 | System | General | Must have | System must be able to use a multi-threaded process for handling all steps after the intake and eligibility steps |
| 1.1.7 | System | General | Must have | System must be able to perform the following: tracking, disbursements, audits, compliance, and reporting. More specific requirements surrounding these processes are included via exhibit, where relevant |
| 1.1.8 | System | General | FEMA Requirement | System must be able to update tracking and reporting based on FEMA reporting requirements including data needed for FEMA portal submission. System must support the addition of program areas, including new applications and new workflows. |
| 1.1.9 | System | General | Must have | System must conform and be branded with OEM logos. |
| 1.2.1 | System | Accessibility | Must have | System must be implemented and configured to Oregon ADA standards and must be user-friendly to navigate. |
| 1.2.2 | System | Accessibility | Must have | System must meet 504 and 508 compliance requirements |
| 1.2.3 | System | Accessibility | Must have | System must be able to accommodate mobile and desktop uses as well as Microsoft Edge, Google Chrome, Firefox browsers, Apple Safari, and other commonly used browsers. |
| 1.2.4 | System | Accessibility | Must have | Web accessibility 'WCAG' rating of 97.48% or greater |
| 1.2.5 | System | Accessibility | Must have | Web accessibility 'AA' rating of 100% |
| 1.2.6 | System | Accessibility | Must have | Web accessibility 'A' rating of 100% |
| 1.3.1 | System | Communications | Must have | System must import names and contact information ("contacts") from excel workbooks and csv file types. |
| 1.4.1 | System | Notifications | Must have | System must be able to send outgoing emails and SMS messages to potential applicants using targeted, custom messaging. These potential applicants could be based on previous contacts, contacts found within a targeted geographic area, contacts in a particular market segment, etc. |
| 1.4.2 | System | Notifications | Must have | System must keep historical records of all notifications sent out at at pre-applicant and sub-recipient level |
| 1.4.3 | System | Notifications | Must have | System must generate notifications for upcoming deadlines, overdue notices, application status changes, revision & extension status changes, site monitoring due dates, Request for Payment status changes, and any other item OEM deems critical |
| 1.4.4 | System | Notifications | Must have | System must allow communications to be edited before sent, saving any edits to a final version on the record. |
| 1.5.1 | System | Record Retention | Must have | System must archive all document and field records as they are removed, to ensure that tracking and auditability of all fields is retained. No modifications to audit records shall be permitted within the system. |
| 1.5.2 | System | Record Retention | Must have | System must contain a lock feature on the applicant file, where based on security rights, only elevated permissions can modify the application post-lock (e.g. when applicant submits incorrect document). |
| 1.5.3 | System | Record Retention | Must have | System must allow exporting the entire applicant file, including application data and all scanned documents, at any stage of the application process, in a PDF format. |
| 1.5.4 | System | Record Retention | Must have | System must have configurable retention periods for data and saved files |
| 1.6.1 | System | User Help | Must have | System must have online help functionality accessible by users, and must be updateable with common issues and FAQ results. |
| 2.1.1 | Applicant Portal | General | Must have | The external application portal must be able to be deactivated, or reactivated, by approved OEM staff |
| 2.1.2 | Applicant Portal | General | Must have | Portal must have ability to be branded with OEM branding |
| 2.1.3 | Applicant Portal | General | Nice to have | Both internal and external users shall have a dashboard upon logging in that shows customized views of assigned grants and any outstanding action items |
| 2.1.4 | Applicant Portal | General | Nice to have | System shall be able to survey subrecipients on customer service, organzational processes, and/or training requests. |
| 2.2.1 | Applicant Portal | Accessibility | Must have | System must present the application portal in multiple user languages that the applicant can select for accessibility |
tc={3422F1A2-3EB4-4000-B2BE-D4F597C8F425}: [Threaded comment]
Your version of Excel allows you to read this threaded comment; however, any edits to it will get removed if the file is opened in a newer version of Excel. Learn more: https://go.microsoft.com/fwlink/?linkid=870924
Comment:
Evaluate by IDEA?
| 2.2.2 | Applicant Portal | Accessibility | Must have | System must allow a filtering of applications and exporting of application list, types, and other attributes, with filtered details, to Microsoft Excel, ARC GIS, or other as identified by OEM. |
| 2.3.1 | Applicant Portal | Documents | Must have | The portal must save documents and attachments (PDF, .docx, .xlsx, jpeg, and any other commonly used file types) uploaded by both external customers, OEM staff, and vendor users to the application application record. The system will use AI components to verify the validity of regulated forms of identification. |
| 2.4.1 | Applicant Portal | Applications | Must have | Portal must have an external-facing landing page for end users and perform three key functions: initiate a new request for assistance (application form), alter previous submissions for assistance when prompted, respond to requests for information and provide a means for the applicant to view application status. |
| 2.4.10 | Applicant Portal | Applications | Must have | The application must create unique records and use unique keys for both customer and application. System must include a cross-checking function to flag potential duplicate applications when the same applicant applies more than once or different members of the same entity submit different applications |
| 2.4.11 | Applicant Portal | Applications | Must have | Applicants must have the option to view a list of all open grant opportunities for which they might be eligible upon logging into the system via a dashboard or home screen |
| 2.4.12 | Applicant Portal | Applications | Must have | Application form fields must be adjustable, as they vary from program to program and may require changes from year to year. |
| 2.4.2 | Applicant Portal | Applications | Must have | Application form fields must contain word processing features and must be compatible with copying and pasting narrative from Microsoft Word or other, similar word processing programs |
| 2.4.3 | Applicant Portal | Applications | Must have | Portal must have auto-save feature in which applicants can ensure that their work is being saved after a pre-determined number of minutes. |
| 2.4.4 | Applicant Portal | Applications | Must have | The application must provide an attestation of truth statement, to be customized by OEM, with a place for the applicant to e-sign and date. |
| 2.4.5 | Applicant Portal | Applications | Must have | System must have the ability to identify applicants who are ineligible at any step in the process if new information is received that impacts eligibility |
| 2.4.6 | Applicant Portal | Applications | Must have | Portal must be able to allow an applicant to initiate but not finish an application by saving, and creating a password, then verifying their applicant email address before logging in again. The applicant will use this created login, username and password, to login to the application portal and view their application status and respond to questions posed by program analysts. |
| 2.4.7 | Applicant Portal | Applications | Must have | System must allow for record changes, record deletion, assignment of application applications, approval or denial of applications, lock records populate data from importing data, and allow for applications to be saved and completed at a later point in time. |
| 2.4.8 | Applicant Portal | Applications | FEMA Requirement | System must collect a variety of data attributes, including but not limited to: |
legal entity name, Unique Entity Identifier (UEI), primary address, mailing address, primary email address, secondary email address, mobile phone numbers, secondary phone number, proof of FEMA approved and adpoted Natural Hazard Mitigation Plan (NHMP), location of proposed project, lat/long of proposed project.
| 2.4.9 | Applicant Portal | Applications | Must have | The portal must be customizable for data fields, as needed by OEM staff and program analysts. Certain fields will not be visible to external applicants, and instead only show some fields to internal staff based on security rights. |
| 2.5.1 | Applicant Portal | Communications | Must have | System must have the following methods of communication available for program analysts and OEM staff to use: (1) email messages and (2) outgoing text messages (with an applicant opting-in) and ability to track other communication methods if OEM determines necessary such as in-person contact and phone call |
| 2.6.1 | Applicant Portal | Notifications | Must have | System must send automated messages out to the Applicant via SMS text messages and email messages notifying all application progress and status changes. |
| 2.6.2 | Applicant Portal | Notifications | Must have | System must allow users to send manual messages out to Applicants with custom language, differing from application configured language. These messages must have the option of attachments. |
| 2.7.1 | Applicant Portal | Integrations | Must have | System must be able to ingest large datasets and apply the data to the corresponding and correct applicant record. This data will be used to help calculate benefits, and the system must allow for the generation of awards taking into account all the data ingested from other sources. Some or all of this may be automated depending on business requirements. |
| 2.7.2 | Applicant Portal | Integrations | Must have | System must integrate with DocuSign capabilities to capture applicant signatures, when prompted by a program analyst or any supervisory staff. |
| 2.8.1 | Applicant Portal | Data Integrity / Validations | Must have | The application must perform automated quality checks and data validation on required fields (e.g. dates, email addresses, etc.) and document and verify that no duplication of application applications be allowed. System must prompt for data re-entry when data does not match required format or data type. |
| 2.8.2 | Applicant Portal | Data Integrity / Validations | Must have | Each form page must have data integrity in all fields via use of data types and include referential comparisons to pre-existing applications submitted to ensure that no duplication or fraud occurs; this will include verification checks found in other requirements |
| 2.8.3 | Applicant Portal | Data Integrity / Validations | Must have | System must automatically detect any non-required fields (e.g. blank) and unsubmitted documents and attachments as well as scan for corrupted attachments, and prompt the applicant for follow-up via email and place a notification for them in their portal home screen |
| 2.8.4 | Applicant Portal | Data Integrity / Validations | Must have | System must verify the fields found in the new application form using the following methods (quality check): |
o Flag potential duplicate applications, either when the same applicant applies more than once or different members of the same household submit different applications o Email Address -- must verify that email is in existence and that it is presented in correct exchange format including @domain.com o State, Local, Tribal Government or Private Non Profit with Unique Entity Identifier (UEI) o Primary project location address must be verified for existence using reliable data source (e.g. Bing Map or comparable SOR using a workflow connector)
| 2.8.5 | Applicant Portal | Data Integrity / Validations | Must have | The system must have the ability to require mandatory fields and provide warnings & hard stops when attempts are made to submit the application without all mandatory fields completed. If any data integrity issues occur, the system must flag the error for applicant to retry entry while they are still in the application |
| 2.8.6 | Applicant Portal | Data Integrity / Validations | Must have | If duplication or fraud is found during a logical quality check of the application a workflow shall route application to a duplicate queue and mark the application status of 'inactive' and routed to a 'Duplicate’ application management queue. |
| 2.8.7 | Applicant Portal | Data Integrity / Validations | Must have | If no fraud or duplication is found in via a quality check, the application must be assigned a unique identifier ('App ID'), identifiable with the grant funding program ID in it, and routed to the 'Unassigned' Queue. |
| 2.8.8 | Applicant Portal | Data Integrity / Validations | Must have | If partial information is collected on the form, and the application is less than complete, system must route application based on remaining fields to 'Intake' queue and assign an application status of 'Eligibility Review'. |
| 2.9.1 | Applicant Portal | Record Retention | Must have | System must retain all historical records from: (1) email messages and (2) outgoing text messages (with an applicant opting-in) and any other communication method OEM determines necessary |
| 3.1.1 | Application Management | Integrations | Must have | System must be able to receive uploads from other data sources into applicant record - tied into record with some automation. (Csv, manual). |
| 3.10.1 | Application Management | Documents | Must have | System must allow the tracking of forms and attach all responses to the application. System must include a program analyst checklist and action item view and include a signoff for quality check review. |
| 3.10.2 | Application Management | Documents | Must have | System must contain the ability to create, automatically generate, and send a formal eligibility letter to the applicant once all verifications have been completed by the program analyst and system criterion have been met. |
| 3.10.3 | Application Management | Documents | Must have | System must create and automatically generate and send documents via email including but not limited to: formal progress letters, inspection notices, and event changes, to the applicant once all verifications have been completed by the program analyst. These documents must be formatted both as an editable Word document and as a PDF and include OEM logo and branding. |
| 3.11.1 | Application Management | Awards | Must have | System must contain an approval process that is automated with actions for applicants to accept, appeal, or refuse. The process must contain notifications to the applicant to prompt action within a certain period of days, as defined by OEM. If no action is taken by applicants, the system must route the application to an inactive queue and add a field for justification notes. |
| 3.13.1 | Application Management | Application Details | Must have | System must allow for categorization and prioritization of applications based on identifying fields in the application record including urgency as defined by agency policy |
| 3.13.10 | Application Management | Application Details | Must have | Each application record will have an assignment feature, where a single program analyst can be assigned to its management |
| 3.13.2 | Application Management | Application Details | Must have | System must use user lists populated by OEM staff for assignment and permissions as well as management of personnel records that can be assigned application records. |
| 3.13.3 | Application Management | Application Details | Must have | Once an application is complete, the application record will become an application, that shall be assigned to internal or external staff as a method of work allocation. |
| 3.13.4 | Application Management | Application Details | Must have | The application record based on applicant forms must be managed via ‘queues’ indicating the application status and tasks for each stage of the business process. The titles and logic of the workflow routing is subject to change based on design session results. |
| 3.13.5 | Application Management | Application Details | Must have | Application records must be editable and have application notes and tasks added along with additional information, which will be used only for internal use (external parties will not view). |
| 3.13.6 | Application Management | Application Details | Must have | System must contain multiple application management queues used by OEM program analysts where application records can be routed and notated within, by both external and internal users. Each application will be managed by OEM staff- internal or contract, and will have multiple stages, preapplication, review, delection, funding and closure of the application. As an application progresses through stages, the system shall move the application throughout different application management queues. |
| 3.13.7 | Application Management | Application Details | Must have | Based on the applicants’ geographic locations a program analyst assignment must be placed upon the application, and the program analyst's name must remain identified on the application and placed within the program analyst's personal list/queue of assigned applications. |
| 3.13.8 | Application Management | Application Details | Must have | System must have the following statuses available, and the ability to add more in the future: Duplicate, Inactive, Admin Hold, Ineligible, Unassigned, Intake, Eligibility Review, Monitoring, Award and Closeout. |
| 3.13.9 | Application Management | Application Details | Must have | The application management queues will be titled 'Intake', 'Under Review', and 'Archive'; the system must allow additional application management queues to be created in the future. |
| 3.14.1 | Application Management | Inspection | Must have | System must allow for inspection record data entry and document uploads from external systems for site-specific inspections. The inspection phase must have workflow logic to review for completeness and remediation plan. |
| 3.15.1 | Application Management | Closeout | Must have | System must force a complete review of the entire application or applicant record before changing status to closeout. |
| 3.16.1 | Application Management | Auditing | Must have | Applications must have complete audit trails in which all documents and field records are maintained including use of version control; nothing can be removed but can be archived according to rules specified by OEM |
| 3.2.1 | Application Management | General | Must have | Applicant portal must contain dynamic forms that adjust in real-time as they are filled out, based on criteria defined by agency. All policy thresholds and questions must be updatable if grant requirements change. |
| 3.2.2 | Application Management | General | Must have | System must allow data entry in later application steps and respective queues (multi-threaded data entry), in the following steps: |
- Jurisdiction UEI Number (Duplication and Verification of Eligibility)
- Inspections and Onsite Monitoring
- Programmatic monitoring
- Award
- Payments
- Requests for Reimbursement
- Closeout
| 3.3.1 | Application Management | Security | Must have | System must have the option to assign different roles and responsibilities including specific staff to certain awards |
| 3.4.1 | Application Management | Workflow | Must have | System must include a program analyst checklist and action item views for questions to ask and data to confirm, if needed. |
| 3.4.2 | Application Management | Workflow | Must have | System must provide automation to process applications , workflows (completed application leads to next process),etc. |
| 3.4.3 | Application Management | Workflow | Must have | Program analysts must have ability to manually review all applications for eligibility and compare against program requirements that are visible in the application. The program analyst must complete a manual review of the application before the application can change statuses and mark checklist items complete. |
| 3.4.4 | Application Management | Workflow | Nice to have | System must integrate with financial tracking component to provide a view into grant funding availability and allow program analysts to soft allocate funding limits against the overall funding amount for each program. Whilst in the application review phases, the system must show remaining program funding amounts and alert users when approaching limits. |
| 3.4.5 | Application Management | Workflow | Must have | System must replicate the process and outcomes of the FEMA Application Review Tool, using automation to reduce administrative burden to program analysts. |
| 3.5.1 | Application Management | Communications | Must have | System must provide a tracking methodology for OEM staff to record all communications with customers regarding their application and grant funding status (application application status). |
| 3.5.2 | Application Management | Communications | Must have | The application portal must allow program analysts to request actions of the applicant and allow applicants to send messages to their program analysts, and otherwise perform collaborative work with the program analyst to advance the application. |
| 3.6.1 | Application Management | Notifications | Must have | System must send the assigned program analyst notifications of any change made to the application by any account that is not the program analyst. |
| 3.6.2 | Application Management | Notifications | Must have | System must send automated messages out to the Applicant via SMS text messages and email messages notifying all application progress and status changes. |
| 3.6.3 | Application Management | Notifications | Must have | System must allow staff to subscribe for notification of changes to any records in the solution. |
| 3.8.1 | Application Management | System | Must have | System must collect details for the following items in this application stage: |
[TBD]
OEM expects additional details including fields or examples to be shared during design phase.
| 3.9.2 | Application Management | Eligibility | Must have | System must contain verification checks, including verification logic using another system of record that has a reputable GIS dataset (Google Maps, Smarty Streets, etc.), for confirmation of damage and property verification in relation to where wildfire occurred. |
| 5.1.1 | Finance | General | Must have | System must contain comprehensive General Ledger coding, and the coding must scale depending on additional projects and programs that OEM needs to track in the system in the future |
| 5.1.2 | Finance | General | Must have | System must provide a method for OEM staff to complete long-term strategic and annual budget planning for grants management. All grant money transactions must be displayed as debit and credit entries to maintain financial records. OEM staff will create, maintain, deploy, and generate financial statements and batch files for reporting needs and disbursement releases. |
| 5.1.3 | Finance | General | Must have | System must aggregate amount of committed dollars to track against each program's budget |
| 5.1.4 | Finance | General | Must have | System must project spenddown by quarter or other timeframes specified by OEM for subgrantees to show where they're at against the spenddown target, and allow the management of many grantees with multiple funding sources. System must also manage reallocation of funds when needed and ensure funds are all spent within the allowability period. |
| 5.2.1 | Finance | Awards | Must have | System must have structure to allow for various award components with different budget limitations including setting up of budget categories with budget limitations to the detail level with drop down menus |
| 5.3.1 | Finance | Compliance | FEMA Requirement | System must act as a grant management system and confirm that all contract and grant requirements are fulfilled based on FEMA and program requirements |
| 5.4.1 | Finance | Payments | Must have | System must accept and store request for reimbursement that will be approved by program analysts (quality checking the work) and sent to finance for release of funds (payment will occur outside the System, but payment information will be stored and sent from the System). |
| 5.4.2 | Finance | Payments | Must have | The payment records and entries must contain statuses such as submitted, reviewed, approved, paid, and contain the ability to create more statuses as needed. |
| 5.4.3 | Finance | Payments | Must have | All financial reporting will be tracked at the account code level, filter by program title, by recipient / subrecipient, and generate an exportable batch report that pulls in all approved invoices for payment |
| 5.4.4 | Finance | Payments | Must have | System must import the batch report back into the System when it was paid and update the status of the records to prevent any duplication of payments |
| 6.1.1 | Programs | Compliance | Must have | System must have a compliance mechanism including tracking for each program to ensure requirements are met. Detailed requirements will be available for each program at a later date. |
| 6.1.2 | Programs | Compliance | Must have | System must have manual and automated quality control processes and allow inspections to ensure compliance with standards set by OEM and FEMA |
| 6.1.3 | Programs | Compliance | Must have | System must be able to administer grant programs and loan programs including but not limited to: grant awards, loan generation, loan tracking, payments, payment disbursements, interest, payoffs, statements, loan agreements, promissory notes, lien filings and tracking, reconveyances, tracking and recording of forgiveness, all dates of related to payments, all amounts, including Approved, Disbursed, Pending, Repaid, Recycled, and Forgiven types. The system must accept file uploads and attach files to the application and loan records. |
| 6.1.4 | Programs | Compliance | Must have | System must be able to manage and track penalties for subrecipients who are out of compliance with grant agreements |
| 6.2.10 | Programs | System | Must have | The system must have ability to manage grants and related projects, including documentation of the following: |
| - | Grant/award amount & contract # | ||||
| o | Ability to attach executed grant agreement & amendments | ||||
| o | Award amount fields, including: Total budget including budget categories to track and process distributions against | ||||
| • | Ability to attach approved (and amended) budgets | ||||
| o | Performance measures, including but not limited to: | ||||
| • | Methodology to track resilience performance metrics, as defined by OEM and FEMA. | ||||
| o | Monitoring plan | ||||
| - | Project Status | ||||
| - | Key dates, including: | ||||
| o | Date of Grant execution | ||||
| o | Date Project substantially complete | ||||
| o | Date Project closed/terminated | ||||
| - | Tracking of all payments to subrecipient (date & amount), including: | ||||
| o | Authorization & approval process workflow | ||||
| o | Ability to attach invoices & requests for reimbursement | ||||
| o | Ability to attach weekly payroll details for Labor Standards, Davis-Bacon compliance, Section 3 Review | ||||
| o | Ability to attach additional backup files and documents for programs | ||||
| 6.2.7 | Programs | System | Must have | System must allow for entries of expenses from applicants. All entries shall be classified via categories such as eligible, ineligible, and to be determined, and each entry shall contain a notes field, amount, payee, payor, and picklists for expense type, with the ability to add more by OEM. Additionally, the system must calculate subtotals by expense categories for tracking. | |
| 6.2.8 | Programs | System | Must have | System must provide a grant agreement for applicants to attest to to be defined by OEM, that must be signed before moving onto the next phase in the business process. | |
| 6.2.9 | Programs | System | Must have | The system must have ability to track application approval process, including documentation of the following: |
| - | Region (i.e., which county) | ||||
| - | subrecipient name (will be organizations, not individuals) | ||||
| - | subrecipient contact information (individual Point of Contact, phone, email, mailing address, EIN) | ||||
| - | Risk Assessment | ||||
| o | Attach checklist & backup documents | ||||
| o | Preliminary rating | ||||
| o | Adjustments/follow-up risk mitigation steps | ||||
| o | Compliance plan | ||||
| - | Project description data and justification, including: | ||||
| o | Project selection process, including attached record of Selection Committee approval and attached record of public hearing | ||||
| o | Project description (Could be a fillable form or an attachment) | ||||
| o | Project and recipient eligibility review check-list, including ability to attach multiple files | ||||
| 6.5.5 | Programs | Reporting | Must have | In addition to general reporting requirements, the following reporting capabilities are required for grants: |
-Report of Compliance issues, by project -% of funds expended, by project -Project Status, by project -List of attachments, by project
| 7.1.1 | Reporting | General | Must have | System must use categorization and application details to generate dashboards and views, based on security permission levels. All reporting dashboards and views will aggregate reporting on the population of files in the system and drilldown to specific reporting need. |
| 7.1.10 | Reporting | General | FEMA Requirement | System must comply with FEMA reporting requirements for all programs administered by OEM, including but not limited to: Public Assistance, Hazard Mitigation Assistance, Emergency Performance Grant Program, Homeland Security Grant Program, Priviate Non Profit Grant Program, and other FEMA programs identified. |
| 7.1.2 | Reporting | General | Must have | System must create response, reminder, and notification of an entity that wishes to appeal a decision. Appeals should be tracked for deadlines and able to accept supporting documentation. |
| 7.1.3 | Reporting | General | Must have | System must have ability to report at both an aggregate level and at a detailed, drilled down level |
| 7.1.4 | Reporting | General | Must have | System must allow printing and exporting of reports in a variety of formats including Excel, CSV, and PDF so the data can be shared. |
| 7.1.5 | Reporting | General | Must have | System must be extremely adaptable to reporting needs, allowing for ad hoc generation of any report to lift up and analyze a specific data reporting need. The known reporting needs currently includes aging reports, for how long an application takes at specific stages, and award calculations, averaging by type. Additional requirements will be defined later in the project. |
| 7.1.6 | Reporting | General | Must have | System must allow for customized forms among grant programs, which may include, but is not limited to, grant applications, monitoring reports, progress reports, financial reports, and training requests. |
| 7.1.7 | Reporting | General | Must have | System must have the ability to populate a report which includes the information required for staff to easily complete Federal Financial Accountability & Transparency Act (FFATA) Reports. |
| 7.1.8 | Reporting | General | Nice to have | In-system budgeting processes shall include: Clear year-to-date balances for all budget categories and subcategories as well as grant budget total for viewing by subgrantees and staff |
| 7.1.9 | Reporting | General | Nice to have | System shall allow for YTD expenditures to be tracked by categories, grant types, counties served, demographics, and any other information OEM deems as necessary |
| 8.1.1 | Technical | Data Integrity / Validations | Must have | The system must contain a unique identifier that is consistent with identifiers found in the state financial system. All records from the application and payment details must tie back to the system unique identifier. |
| 8.2.1 | Technical | General | Must have | System must be fully vendor supported and contain a modern technology stack, maintained with current IT technologies |
| 8.2.2 | Technical | General | Must have | System must have a separate test environment for users to test system and changes prior to going live. The test environment must remain consistent with the production environment. |
| 8.2.3 | Technical | General | Nice to have | System's back-end database nomenclature shall have consistent names with the application front-end and shall contain referential logic that is well-named and easy to understand |
| 8.2.4 | Technical | General | Must have | System must have ability to print all individual letters, notices, files, and documents in user-friendly, editable Word, Excel, CSV, and PDF formats |
| 8.2.5 | Technical | General | Nice to have | System shall either provide or support web analytics for monitoring external portal/web services including traffic and error reporting. |
| 8.2.6 | Technical | General | Must have | System must allow for advanced configurations to be made by authorized users, including label changes, template alterations, workflow updates, report format (including color scheme, labels, and data formatting), error message phrasing, etc. |
| 8.2.7 | Technical | General | Must have | System must have auto-save feature in which users can ensure that their work is being saved after a pre-determined number of minutes. |
| 8.2.8 | Technical | General | Must have | System must perform automated quality checks and data validation on required fields (e.g. dates, email addresses, etc.) and documents and verify that all formats are consistent. System must prompt for data re-entry when data does not match required format or data type. |
| 8.2.9 | Technical | General | Must have | System must support a disaster recovery plan, where a recovery point objective of 15 minutes and a recovery time objective of 2 hours can be achieved. |
| 8.3.1 | Technical | Security | Must have | System must contain a complex password structure, including special characters, and enforce a mandatory password change every quarter and comply with all requirements in the Statewide Standards: https://www.oregon.gov/eis/cyber-security-services/Pages/default.aspx |
| 8.3.2 | Technical | Security | Must have | System must: 1.) contain a timeout feature to lock out inactive sessions, forcing users to re-authenticate. 2.) System must provide a warning notification that the system is about to timeout so that users do not lose unsaved work. 3.) The system must not allow for more than 15 minutes of inactivity, and force logout after 30 minutes. 4.) System must comply with all Statewide Standards: https://www.oregon.gov/eis/cyber-security-services/Pages/default.aspx |
| 8.4.1 | Technical | Integrations | Must have | System must verify all mailing and physical addresses against the external sources (e.g., Bing Maps) |
| 8.4.2 | Technical | Integrations | Must have | System must integrate with DocuSign or other signature capture software. System must send documents requiring e-signatures when prompted, and when signed, shall allow for the saving of all completed documents to the application record. |
| 8.4.3 | Technical | Integrations | Must have | System must be able to accept files from multiple sources to develop an initial dataset and de-duplicate it with the ability to use the dataset to allow applicants who register to apply for assistance |
| 8.4.4 | Technical | Integrations | Must have | System must have ability to generate batch files for printing letters and documents in a format required by DAS Publishing & Distribution |
| 8.4.5 | Technical | Integrations | Must have | System must generate editable Word, Excel, CSV, and PDF documents when prompted, PDFs must use of Adobe PDF Generator or comparable OEM compatible system. |
| 8.4.6 | Technical | Integrations | Must have | System must act as document storage for all required documentation, generated letters, notices, added attachments, and electronically signed documents. |
| 8.5.1 | Technical | Security | Must have | System must be hosted by vendor |
| 8.5.10 | Technical | Security | Must have | All system data must be stored in the cloud. |
| 8.5.11 | Technical | Security | Must have | System application must be accessed via https URLs with TLS 1.2 or later. |
| 8.5.12 | Technical | Security | Must have | System must have an uptime of 99.5% at all times. |
| 8.5.13 | Technical | Security | Must have | System must have a geographically redundant environment with rapid recovery and no downtime (100% uptime) during supported business hours specified by OEM. System must comply with DAS backup and recovery policies. |
| 8.5.14 | Technical | Security | Must have | System must perform and handle at least 3,000 concurrent users and sessions at a time with the ability to adjust this volume as OEM identifies the need. |
| 8.5.15 | Technical | Security | Must have | System must provide multi-factor authentication ability for all licensed or continuous users of the system (not external applicants, customers). |
| 8.5.16 | Technical | Security | Must have | System must provide self-service password recovery options for internal and external users. |
| 8.5.17 | Technical | Security | Must have | System must use modern authentication (such as OAuth or SAML) protocols and practices. |
| 8.5.2 | Technical | Security | Must have | System must have a comprehensive security model, with each entity, subentity, and data field as different permissions to provision granular access. Granular access shall be provisioned to both internal and external individuals and groups at the application page level and when reporting and viewing data. Access will be provisioned via security roles or groups; permissions and security levels will be finalized closer to the testing phase, in accordance with CIO guidance, but the system must provide defined access levels for: admins, developer, subject matter expert, supervisor, program analyst, and any other role OEM deems necessary. |
| 8.5.3 | Technical | Security | Must have | System must securely transmit, store, and process confidential data including personally identifiable information. Data must be encrypted during transmission and storage, following compliance of AES 256 and TLS 1.2 or newer. |
| 8.5.4 | Technical | Security | Must have | System must meet or exceed the State of Oregon’s security standards based on the current version of NIST SP 800-53 for moderate and high impact systems, or identified equivalent industry security standard. Oregon Statewide Information and Cyber Security Standards can be found at: https://www.oregon.gov/das/OSCIO/Pages/SecurityGuidance.aspx |
| 8.5.5 | Technical | Security | Must have | System must comply with SOC 2 Type II and FedRAMP requirements. An annual assessment must validate that all of the following criteria are met and achieved continually, under SOC2 Type II and FedRAMP, including but not limited to: 1. Security, 2. Availability, 3. Processing Integrity, 4. Confidentiality, and 5. Privacy. |
| 8.5.6 | Technical | Security | Must have | System must mask sensitive data and only show fields to authorized users. |
| 8.5.7 | Technical | Security | Must have | System must keep all data, including backups and log files stored in the United States. |
| 8.5.8 | Technical | Security | Must have | System must allow for creating new security roles based off copying other roles, via copying permissions. |
| 8.5.9 | Technical | Security | Must have | System must display warning banner with language developed by OEM when users are accessing confidential data that indicates activities may be tracked. |
| 8.6.1 | Technical | Performance | Must have | System must support report execution that does not negatively impact other system functionality |
| 8.6.2 | Technical | Performance | Must have | System must support a growing database which does not negatively impact system performance. Negative system performance includes: 1.) lagging page loads, of no more than five seconds or 2.) slow saving of updated data, requiring more that 10 seconds to save successfully or 3.) reports, attachments, and notifications, requiring more than thirty seconds to load, compile, and send. System must not place limit on data storage or growth. |
| 8.6.3 | Technical | Performance | Nice to have | System shall send automated system performance notifications to one or more specified email addresses |
| 8.7.1 | Technical | User Interface | Nice to have | System shall minimize the number of unique screens, clicks, and keystrokes |
Evaluate by IDEA?
&"-,Bold"CDBG-DR System of Record Requirements
File details come from the government source that posted it. Updated .