Research Project Management System RFI No. 6-P124-I--05530-00.pdf

Page

U. S. Department of Energy laboratory managed by UChicago Argonne, LLC

TO ALL PROSPECTIVE OFFERORS:

Subject: Request For Information (RFI) No. 6-P124-I--05530-00 – Research Project Management System

UChicago Argonne, LLC, operator of Argonne National Laboratory, under a prime contract with the U.S.

Department of Energy (DOE), is performing a market survey to evaluate obtaining products or services which are the subject of this Request for Information (RFI). Therefore, you are invited to submit a response to this Request for Information to include marketing materials, price lists, informal proposals, and any other relevant information you deem appropriate to address your ability to provide the supplies or services. This Request for Information is for informational purposes only and will not necessarily result in a solicitation or award of a contract.

Responses may include proprietary information. Offers should indicate on the fore page, and all subsequent pages of their response to this RFI, those sections, paragraphs, or areas which they consider to be proprietary or otherwise considered confidential. Argonne assumes no liability for disclosure or use of unmarked data and may use or disclose such data for any purpose.

Argonne National Laboratory is a multi-program science and technology laboratory managed for the Department of Energy. Scientists and engineers at Argonne conduct basic and applied research and development to create scientific knowledge and technological solutions that strengthen the nation's leadership in key areas of science, increase the availability of clean, abundant energy, restore and protect the environment, and contribute to national security.

Argonne manages a complex portfolio of research projects involving multiple stakeholders, including principal investigators, division leaders, financial partners, and subcontractors. The Laboratory's research management lifecycle encompasses work acceptance, risk evaluation, oversight, and subcontracting processes that are critical to ensuring successful project execution while maintaining compliance with federal regulations and institutional policies.

Argonne's current work acceptance processes are fragmented across multiple systems and lack standardization, resulting in inconsistent risk evaluation, inefficient oversight mechanisms, and suboptimal subcontracting decisions. The Laboratory requires a comprehensive solution to streamline work acceptance workflows, enhance risk assessment capabilities, and improve oversight throughout the research management lifecycle.

The current process involves manual workflows, disparate systems, and lacks real-time visibility into project status, risk factors, and compliance requirements. This results in delayed project approvals, inconsistent application of risk evaluation criteria, and difficulty in tracking and managing subcontracting activities across the Laboratory's diverse research portfolio.

Argonne is exploring commercial-off-the-shelf (COTS) and custom solutions for a Research Project Management System (RPMS). The RPMS will be a comprehensive, integrated platform that standardizes and automates work acceptance workflows, enhances risk evaluation processes, and provides robust oversight capabilities for research project management.

The system must support configurable workflows that accommodate different project types, funding sources, risk levels, and compliance requirements. It should integrate seamlessly with Argonne's existing enterprise systems and provide real-time dashboards, analytics, and reporting capabilities to support decision-making at all organizational levels.

The RPLMS must ensure compliance with federal regulations, DOE requirements, and institutional policies while providing transparency and accountability throughout the work acceptance and project oversight lifecycle.

Responses should include a detailed description that addresses the following topics:

Workflow and Management

• Work Acceptance Workflow Management: Configurable workflows for different project types, funding sources, and risk categories

• Role-Based Access Control: Granular permissions for principal investigators, division leaders, financial partners, and administrators

• Template and Checklist Management: Dynamic templates and checklists for work acceptance and risk evaluation processes

• Approval Routing and Escalation: Automated routing based on project characteristics, risk levels, and organizational hierarchy

• Real-Time Project Tracking: Dashboard views of project status, milestones, and key performance indicators

• Subcontract Management: Integration with procurement systems and subcontractor performance tracking

• Notification and Communication: Automated notifications, reminders, and communication workflows

• Document Management: Integration with existing document repositories and version control systems

Reporting, Analytics and Tracking

• Risk Assessment and Evaluation: Automated risk scoring, customizable risk criteria, and risk mitigation tracking

• Audit Trail and Documentation: Comprehensive logging and document management capabilities

• Standard and Ad Hoc Reporting: Pre-built reports and custom report builder functionality

• Compliance Monitoring: Automated compliance checking and alert systems

• Performance Analytics: Trend analysis, benchmarking, and predictive analytics capabilities

• Executive Dashboards: High-level views for leadership decision-making

• Data Visualization: Interactive charts, graphs, and performance metrics

Implementation and Operations

• Training Module Integration: Built-in training delivery, tracking, and certification management

• User Onboarding and Support: Self-service capabilities and integrated help systems

• Mobile Accessibility: Mobile-responsive design and native mobile applications

• Cloud Deployment Options: Public, private, and hybrid cloud capabilities

• FedRAMP Certification: Current certification status and compliance details

• Data Security and Privacy: Encryption, access controls, and data protection measures

• Scalability and Performance: Ability to handle Laboratory's current and projected user base and transaction volumes

• Enterprise System Integration: APIs and connectors for existing Laboratory systems (financial, HR, procurement)

• Implementation Methodology: Project approach, timeline, and resource requirements

• Change Management Support: Training, communication, and adoption strategies

• Ongoing Support and Maintenance: Support models, service level agreements, and upgrade processes

• Customization Capabilities: Ability to modify workflows, forms, and business rules

• Licensing Model and Options: Subscription, perpetual, and usage-based pricing models

• Cost Estimate: Total cost of ownership including implementation, licensing, maintenance, and support

• Reference Customers: Similar organizations using the solution, particularly in research or government environments

Full requirements are included in Appendix A

Offerors which have provided a response may be invited for an online presentation to provide further explanation of their solution and capabilities. The online presentation shall be limited to a period of ninety (90) minutes, with forty-five (45) minutes for the vendor presentation and forty-five (45) minutes for Argonne questions and discussion. Any presentations are expected to be held within two (2) months of the RFI due date.

RFI Questions Due: All questions regarding this RFI must be submitted via email on or before November 5, 2025.

RFI Responses Due: Final responses to this RFI are due by November 26, 2025, at 5:00 PM Central Time.

Submission Contact: All questions and responses should be submitted electronically to Jack Patton at jpatton@anl.gov.

Reference Number: The RFI Number 6-P124-I--05530-00 must be referenced in the subject line of all email transmittals related to this RFI.

Responses should not exceed 50 pages (excluding appendices) and should be submitted in PDF format. Include company information, solution overview, technical specifications, implementation approach, and commercial terms as outlined in the required capabilities section above.

Based on the analysis of the RFI responses, Argonne may, at its sole discretion, choose to issue a formal solicitation (such as a Request for Proposal), further refine its requirements, or pursue other alternatives. There is no guarantee that a formal solicitation will be issued as a result of this RFI, and this RFI does not commit the Laboratory to procure any products or services.

mailto:jpatton@anl.gov

APPENDIX A: DETAILED REQUIREMENTS

1. PROJECT REQUIREMENTS

# Name Statement Of Requirement

Acceptance Criteria Documentation

1 Form Data Entry System provides the ability to define and capture form-based information including the creation of new form types, and the import of data fields from other systems or documents (see document read req). Forms can use conditional branching adding or hiding additional fields based on responses.

The system is able to demonstrate the creation and management of forms and their associated instance data

2 Document

Information Extraction

The system provides the capability to read in information from documents including parsing out key pieces of information from text such as requirements, financial information, work scope, etc. The documents may be form-based or prose/unstructured and thus the system may make use of a language model or similar for processing and extraction.

Given both a form-based and unstructured document, the system is capable of extracting the key pieces of information from it

3 Missing information prompts based on forms and workflow stages

The system is capable of identifying missing information which is required by a particular process step or form and alert the user to provide the missing information. This check is also performed whenever the lifecycle stage changes in order to alert the user to provide additional information needed for that particular lifecycle stage

Forms indicate required fields When forms are auto-filled from extracted documents, missing information is highlighted When lifecycle stages change, users are alerted via some notification mechanism that information is missing and needed

4 Information provenance marking

If information in the system comes from another source (such as another system of record) the user interface displays the system of record for that information via some mechanism (e.g. can be a tooltip, or behind a details screen, but should be present somewhere). Fields which come from particular forms should have their form noted (e.g.

this field comes from ANL-1266)

A user can view the sources of data elements within the system

5 Workflow with stage and approval details.

The system provides a robust workflow capability with approvals and displays, in a digestible way, the details about the current state of an entity including where in an approval chain/process the item is, who/what it is waiting on, and what the next step is, including if there is a dependency on an approval from some other related entity. Workflow supports conditional branching.

Users can start ad-hoc workflow steps if needed.

Workflow approvals can be delegated based on specific criteria (and may require their own approval)

A user can examine the current state of an entity and see as much detail as possible about the current state of its workflow including where in the overall process it is, what if anything is needed / waiting to move forward, and if it is waiting on an approval item, who (role, user) is responsible for that approval item

6 Fields in the system support relations and hyperlinks

Entity data fields in the system can be linked to other data fields in the system; for example, if a particular data field comes from a form, I should also be able to link to the form itself. If the data comes from an external source, the source of that system is noted and, ideally, linked.

Given a particular entity, a user can easily cross-reference related information by following links/references in the entity

7 System supports common and consistent master data

Common shared data such as drop-downs, selections, etc can be shared across entities and managed

8 Workflow stages support the concept of 'final submit' after which point, rolling back requires a resubmit of the information

Workflow engine has the capability to allow some data elements to be modified at any time, and others requiring a re-submit of information / restart (cancel) of workflow and approvals.

Changed fields which are linked should update on their linked records provided those wouldn't trigger a re-submit action (if so, the action wouldn't be allowed)

9 System provides a robust integration API for the use of system data in other downstream systems and processes

System provides a robust integration API for the use of system data in other downstream systems and processes including entity data, fields, forms, reports, etc.

10 Reporting and Dashboards

System provides a robust reporting and dashboard capability and/or the ability to integrate with business intelligence systems such as PowerBI.

Lifecycle stages, entities and their fields are all reportable. See documentation for examples of reports Dashboards can be created which cover:

- User tasks with status and pending actions

- Award and funding dates

- Award burndown

- Assignments, timelines, and funcing attributes

- Other dashboards based on data fields in system, and support 'drill-down' and filtering

Reports include examples such as: % entities in various stages, %needing additional information / waiting, # approved entities / fiscal year, etc

11 Information is searchable System provides a search capability (and/or the ability to integrate with an enterprise search provider such as Coveo) which can search across entities and their data fields.

System provides full text search with results limited to access rights Search results can be exported Search results can be filtered

Given some search term, all entities and related documents (forms, data fields) are displayed which are relevant to that search term

12 System understands roles and user attributes

System provides the ability to pull from enterprise role management via integration or AD to populate groups used in system functionality such as workflow, approvals, permissions, etc.

Given a particular role, the user is added to that role based on some group membership and is allowed to perform actions based on the permissions associated with that role. User is restricted from performing actions in roles that the user is not part of

This would include automatically (nice to have) determining initial membership of research enablement group or approvers, potentially including S&T information.

13 System provides a capability to notify users

System can create and send notifications regarding needed information, process steps, approvals needed, etc.;

Notifications can be based on teams and key dates in the record Notifications can be triggered based on SLAs (e.g. you haven't responded reminders)

The system can generate email or Teams notifications in addition to having a way to see pending notifications / needed actions in the application

14 Per-Field security System has the ability to show and hide fields on a data object based on the roles/permissions configured

Given particular sensitive fields, only designated roles can view those fields across the system.

15 System supports needed records retention requirements

System supports the tracking and disposal of organizational records

System allows record schedules to be implemented.

16 System has non-production environments for testing and development

Vendor/System provides additional dev or test environments and consistent methods to promote changes from test to production.

17 System supports self-service configuration

The creation of new workflows, forms, notifications, documents, and their corresponding branching logic should be configurable by system power-users (admins) without required engagement with the vendor.

Users are able to create and maintain needed forms, workflows, approvals, notifications, notification templates, etc.

18 User interface is intuitive and follows the identified processes

System requires minimal interaction (clicks) to achieve a goal, and includes inline help for form fields, etc.

19 Comments / Communication

Workflow steps and forms support the attaching of comments or additional documentation which are carried along the object.

Comment can be attached to a form and/or workflow step during approval.

Granted roles can see those comments when they approve

20 Version control, Data Integrity, and Audit

Objects in the system are version controlled with time and date stamps including uploads, form data, comments, etc.

User actions are logged and datestamped, document changes have audit logs

21 Document management capability

System provides document management capabilities such as version comparison, file attachments, revision control, support for multiple document types (PDF, DOC, XLS, etc)

22 Document management integrations

System supports integrations with Sharepoint and e-signature capabilities such as BoxSign or Docusign

2. SYSTEM REQUIREMENTS

# Name Statement Of Requirement Acceptance Criteria Documentation 1 Integration with enterprise identity via a standard protocol such as SAML2 or OAuth2/OIDC

Integration with enterprise user information is fundamental to ensuring the security of our systems. If the system is used by more than a small number of special purpose users, it must integrate into our SSO system

2 Internal software is developed according to best practices

The system should be developed following e.g. 12-factor methodology, and current software-engineering best practices. System should support data idempotence in operations where possible, transactions, assume transient availability of remote resources, have robust error-checking and error-handling, robust logging, and support concurrency via a best-practice model such as message passing or shared-data brokers if appropriate.

3 IPv6 Only Support

The system is IPv6 Native, and can function in an IPv6 only environment

4 Multi-Factor Authentication (MFA) Support

The system supports the use of multi-factor authentication (MFA) technology for the protection of information

5 Solution must be reviewed by Information Protection / CSPO and EA

To safeguard and protect the Laboratory's information, the implemented solution must be collaboratively reviewed by our Cyber office and EA prior to final approval and release to the enterprise

6 System conforms to laboratory security policies such as FedRAMP and others

System must meet Laboratory security requirements as identified in LMS-PROC-22, LMS-POL-46, LMS-POL-19, the CSPP, NIST, etc

7 System is SaaS/PaaS, is architecturally aligned with our environment, or is a standalone appliance

The system should either: a) Be a hosted product/software as a service with minimal infrastructure considerations,

b) be ANL hosted on a supported platform, or c) be delivered as a packaged appliance-like deployment with vendor-provided support

8 System provider / vendor for commercial /FOSS software should provide robust documentation

The documentation provided by the vendor or provider of the information system in the case of open source or commercial software should be robust and complete and facilitate the long-term stewardship and operations of the software

9 System provides a RESTful or equivalent API for integration

System should support current industry best practices for information system data interchange via web-services or an open binary protocol where appropriate. The use of persistence layer (e.g.

Database) shared access for integrations should be avoided. If a bulk-upload / batch integration is appropriate for the architecture, an ETL file integration is acceptable

10 System supports integration with enterprise information via Services and Events (ESB)

The system supports integration with enterprise information such as directory (people and group) information, financial, etc.

These integrations leverage our services/event bus architecture.

12 Security Assurance Requirements

Systems are verified for assurance against the requirements associated with a system. Requirements are documented and available.

The organization leverages methods such as audits, independent verification and reviews, including Cloud Evaluations, and following established software development processes.

Ongoing monitoring is performed to ensure continued alignment with required criteria.

Artifacts provide evidence that assurance processes were completed or excepted.

Logs or other forms of reports are provided from automated systems providing monitoring These artifacts and other documentation, especially requirements, exist and can be retrieved in a timely fashion for reference and review.

15 Security

Strength Requirements

The organization determines, documents, and enforces security strength (and corresponding levels of assurance) requirements appropriate to the information system or service, ensuring compliance with applicable federal laws, executive orders, directives, policies, regulations, standards, and guidelines.

This includes applying specific controls such as LMS-PROC-22 (Protection of Controlled Unclassified Information), LMS-PROC-75, LMS-PROC-

105, and the Privacy Act of 1984, tailored to the type of application—whether in-house, purchased, or cloud-based—to maintain the required level of security assurance.

Documented and integrated into the Solution Development Life Cycle (SDLC) process. For in-house, purchased, and cloud applications, acceptance criteria involve ensuring that security strength requirements are met as part of the overall system development and acquisition processes, including compliance with relevant policies such as

LMS-PROC-22, LMS-

PROC-75, LMS-PROC-

105, and adherence to federal laws like the Privacy Act of 1984.

These criteria ensure that the system or service meets defined security functionality, assurance levels, and operational needs before being accepted for use.

16 Security-related

Implementation Requirements

Systems are developed in accordance with recommended and organization adopted security best practices such as

Implementing Strong Access Controls (Restricting Privileged Accounts to Authorized Personnel/Role- Based Access Control)

Using strong passwords for service accounts where needed (service accounts with passwords are not recommended, see token use below)

Using tokens (x509, JWT, etc) for service account access where possible

Using standardized authentication methods like

SAML 2.0

Implementing logging and telemetry for applications

This requirement is accepted only if the system enforces strong access controls by restricting privileged accounts to authorized personnel through role-based access control, uses strong passwords for service accounts where necessary while preferring token-based authentication methods such as x509 certificates or JWT tokens, supporting standardized authentication protocols like SAML 2.0, and implementing comprehensive logging and telemetry to monitor application events and system health in accordance with organizational security best practices.

Logging telemetry is available and monitored via (e.g. Splunk).

Application roles are centrally controlled wherever possible using central authorization (ie

ISAAC).

17 Security-Related

Documentation Requirements

The organization includes, explicitly or by reference in acquisition contracts, requirements for security-related documentation covering all phases of the system development life cycle. This documentation must, at a minimum describe any information management and information assurance concerns for the system including records management information and decommissioning/archive requirements. Additionally, this documentation must describe any notable information regarding secure configuration, installation, operation, effective use and maintenance of security functions, known vulnerabilities, user-accessible security features, methods for secure user interaction, and user responsibilities especially where this differs from the normal installation, configuration, routine operation, backup and recovery, logging, permissions, and decommissioning of a system.

These requirements explicitly or by reference in acquisition contracts and ensuring that documentation covers all phases of the system development life cycle. Specifically, acceptance criteria are part of the acquisition process (SA-04). This information exists and is easily accessible. The documentation must be provided minimally in electronic format and presented logically to cover common scenarios like installation, configuration, routine operation, backup and recovery, logging, permissions, and decommissioning.

Acceptance criteria ensure that the delivered system meets these documented security requirements and supports secure operation and maintenance.

Maintaining Configuration Management Plans to Track/Control Changes

Employing formal change management

18 Supply Chain and Provenance Requirements

All development activities must be conducted within secure environments where required, utilizing only official data centers to ensure controlled access and protection of sensitive information. Software sourced from overseas or developed by foreign national organizations must be approached with caution, incorporating rigorous integrity checks on operating systems and resident software to detect any unauthorized modifications.

Additionally, comprehensive supply chain risk management practices shall be implemented to prevent the introduction of malicious code throughout the software lifecycle.

Applications were developed:

In secure environments

Using official data centers

With only reviewed libraries and modules

With system integrity checks

With awareness of supply chain risk management practices

19 Applying Timely and Regular Patching of Operating Systems and Applications

Ensure that operating systems and applications are patched regularly and promptly to protect against vulnerabilities.

Use automated tools such as Microsoft Group Policy, Spacewalk, Casper, or similar solutions to manage patch deployment efficiently.

Automated patch management tools (e.g., Microsoft Group Policy, Spacewalk, Casper) are configured and actively used for patch deployment.

All critical security patches for operating systems and applications are applied within a defined timeframe (e.g., within 7 days of release).

Patch status reports are generated regularly to verify compliance with patching schedules.

Any failed or missed patches trigger alerts for immediate remediation.

Documentation exists outlining the patching process, schedule, responsible personnel, and escalation procedures.

Have systems up to date/applying patches based on severity levels

Disabling Unnecessary Services/Ports/Protocols