RFI.docx.pdf

Request for Information (RFI) National Oceanic and Atmospheric Administration (NOAA)

Office of Marine and Aviation Operations (OMAO) Portfolio Acquisition Executive (PAE) Platforms

Ship Acquisition Engineering & Correspondence Management System

North American Industry Classification Code (NAICS Code):

Product Service Code: DA10 - IT and Telecom - Business Application/Application Development Software As A Service NAICS Code: 541512 - Computer Systems Design Services

Place of Performance:

USA

1 Disclaimer

This announcement constitutes a Request for Information (RFI) only, as defined in Revolutionary Federal Acquisition Regulation (FAR) Overhaul (RFO) 15.101(c), for the purpose of determining market capability of sources or obtaining information. It does not constitute a Request for Proposals (RFP), a Request for Quotation (RFQ), or an indication that the Government will contract for any of the items and/or services discussed in this notice. Any formal solicitation that may subsequently be issued will be announced separately through the Government-wide Point of Entry (GPA) SAM.gov. Submission of a response to this RFI is entirely voluntary. The voluntary submission of a response to this RFI shall not obligate NOAA to pay or entitle the submitter of information to claim any direct or indirect costs or charges or any other remuneration whatsoever.

All information received will be safeguarded from unauthorized disclosure. Please do not submit any classified information. Please ensure to mark any proprietary information.

2 Purpose

The Portfolio Acquisition Executive Platforms (PAE) - Platforms of NOAA is seeking a digital solution to manage the "Owner’s Representative" functions for concurrent major ship and systems acquisitions. PAE Platforms requires an "Owner’s Representative" portal to manage the formal exchange of technical data, coordinate multi-tier review workflows, and maintain a permanent record of correspondence between the Shipyard and the Government. NOAA is specifically looking for systems that employ automation to increase efficiency and reduce the administrative burden.

3 Introduction The National Oceanic and Atmospheric Administration (NOAA), Office of Marine and Aviation Operations (OMAO), is the operational arm of NOAA responsible for delivering specialized sea and air platforms to meet the nation’s environmental and scientific data needs. To ensure the effective recapitalization of these assets, OMAO has established the Portfolio Acquisition Executive (PAE) Platforms to provide centralized oversight for the acquisition of ships, aircraft, and supporting infrastructure. Within this portfolio, PAE Platforms, the Ship Division manages the design, construction, and delivery of NOAA’s next-generation research and survey vessels.

Headquartered in Silver Spring, MD, PAE Platforms manages these complex vessel programs through a rigorous "Owner’s Representative" oversight model. This requires high-fidelity technical data

1 | Page management and formal communication workflows to ensure that all new vessels meet the operational standards required to serve NOAA’s multi-mission objectives.

4 Background

The following is provided as context as to what would be required by the program to work with PAE Platforms’ current contract structure, and systems.

NOAA uses Google Drive and its desktop app for the retention of data as well as most systems which are part of the Google Workspace. The filetypes that the system would need to accept include Microsoft Office (i.e. Excel, Outlook, Powerpoint, Project, Visio, Word), Adobe PDF, AutoDesk products (Autocad, Autocad LT, Inventor, and Navisworks), and ShipConstructor. It can be expected that Government users (estimated less than 50) would have access to the native applications necessary to view files on their computers and Common Access Cards (CACs). When we use the term “Government” here, we are including contractors representing the Government.

The system will need to support multiple simultaneous acquisitions of major ship acquisition programs.

In previous ship programs, the timelines for DI (data item) submittals (e.g. General Arrangement Drawing) have been based on dates relative to contract award or other milestones specified in the contract. Some DI’s have multiple scheduled submittals, for instance one at 2 months after contract award and a second at 10 months after contract award. Revisions of each DI are tracked in two ways.

The first is through a revisions letter which is increased sequentially for each revision of the DI. The second is through an issue number and revision number which is tracking compliance with the contract.

A DI, for instance, may have any number of required submittal dates in the Contract and the Contractor needs to indicate by an issue number which submittal date the submittal is intended to be provided for.

For instance, the first submittal date would be issue 0001 and the first revision of that issue would be assigned a number R0. The contract lists the names and a unique ID of the DI’s required by the contract (around 100 data items for each program) and the time allotted for Government review of the submittal of each DI. The Government may Reject/Accept or Disapprove/Approve the DI submission (which choice the Government has is based on the Contract). If a DI is “Rejected” or “Disapproved” there is generally a earlier requirement for submittal of the next revision by the Contractor, within a time period specified in the contract which would have the same issue number but the revision number (R01, R02, …) would be increased incrementally..

5 Desired Capabilities The following are the key Desired Capabilities. At this stage of being an RFI, it is asked to be clear whether the Desired Capabilities can be met with your system or in combination with another system so that the Desired Capabilities could potentially be de-scoped when converted to actual requirements in an RFP so as to allow the use of commercially available software.

PAE Platforms encourages vendors to identify any Desired Capabilities in this section that deviate significantly from standard Commercial Off-The-Shelf (COTS) functionality. If a desired capability—would require custom coding rather than standard configuration, please describe:

a) Your recommended 'best practice' alternative that achieves the same administrative reduction.

b) Any trade-offs in data integrity or manual effort associated with this alternative.

Coding of any type, by the Government, is not preferred.

2 | Page

Automation of functions which reduces user workload is a desired feature. Additionally, user control of the automation of the functions of the platform.

5.1 Document Management - Google Workspace Integration

1) [Google Drive compatibility] Preference for systems that use Google Drive as the primary document store. Mandatory capability to export all files to Google Drive and mandatory capability of exporting the full metadata pertaining to each file—including the comment-originator mapping, approval logs, and timestamps—to Google Drive/Sheets for long-term archiving.

a) Is the integration with Google Drive a "sync" (copy) or "native" (the file lives only in Google

Drive)?

b) If PAE Platforms decides to leave your platform in 5 years, describe the exact "Export" process to ensure all threaded comment history and image snips remain usable in searchable and organizable, filterable file (i.e. Google Sheets, MS Excel, Smartsheet, etc.).

c) When a file is synced or moved to Google Drive, is the metadata (DI Number, Revision, Approval Status) written to the Google Drive File Description or a sidecar Google Sheet, or is it only searchable within your platform?

d) If 'Native' Google Drive storage impacts system performance or file-locking capabilities, vendors are encouraged to propose a 'Hybrid-Sync' architecture. In this scenario, please describe the maximum delay (latency) between a file being approved in your system and its arrival in the PAE Platforms Google Drive archive.

e) State the system’s capability to include file metadata and folder hierarchy in the import/export process.

f) Once a submittal is approved, can the system automatically "move" the finalized file and the associated comment log to a specific long-term archive folder in Google Drive?

2) The system shall be able to archive and/or create a disaster recovery site (on-premise and/or in the cloud) which can be automatically synced and maintained.

3) [immediate access] The system must allow reviewers to open documents directly from the portal into their local desktop applications (Adobe Acrobat, AutoCAD, etc.) for review and markup.

a) Describe or show how files such as multi sheet AutoCAD files would be opened from the data repository by the Government reviewers. It can be assumed that anyone who will need access to the files would have the software installed on their computer.

4) [large file sizes] Preference to support larger file sizes such as videos of model testing and Navisworks files which tend to be larger.

a) Please indicate if there are limits to file size uploads for the system.

5) [flexible operating system] The system must be electronic system flexible (i.e. operating systems – MS Windows, Linux, Unix, Android, iOS) – with users having the ability to download files from any device with system as long as they have internet connectivity.

6) [clear latest submittal] The system shall make it clear to the Government what the latest revision of any DI is and allow the Government user to open prior versions. If this is provided with a form of version control with rollback history, please advise.

7) Features preventing duplication and fragmentation.

8) [strong search engine] The system shall have SERP (search engine results page, such as Google

Search) features to allow for searching text within submitted documents (i.e. pdf files, MS Excel files [.xlsx, .xls, etc.], Autocad files [.dwg], MS Word files [.docx, doc, etc.], MS Powerpoint files [.pptx, ppt, etc.], etc.); metadata (i.e. tags, index, OCR, etc.) of the submitted documents, folders, or other method of storage organization; data related to submitted document(s) (i.e. comments, responses, counter-comments, etc.).

9) [export capability] Desire to be compatible with other programs.

3 | Page

a) If PAE Platforms transitions to an Enterprise Resource Planning (ERP) system like Oracle or SAP, how does your system facilitate the bulk transfer of data? Does your export process maintain the link between the document and its 'Audit Trail' so that the history remains intact in the new system?

5.2 Submittal Management

1) Formal Intake: A secure portal for Shipyards to formally upload Data Items (DIs) with automatic version control (e.g. Rev 0, 1, 2, etc.).

a) How does the system distinguish between a 'New Revision' (Rev 1) and a 'Resubmission' of an existing revision that was rejected for typos?

b) Does the system rename the file physically on the Google Drive, or does it only change the

'Display Name' within your application portal?

2) [Automated Data Validation] The system must force the Shipyard to provide all required metadata (DI

Number, Title, Revision Letter, Date, Issue Number, Revision Number) upon upload, preventing "incomplete" submissions.

a) If a Shipyard uploads a DI that doesn't match our pre-approved 'Master DI List,' can the system automatically block the upload, or does it just flag it for manual review?

b) Describe the user experience for a Shipyard worker who forgets a required field. Does the system highlight the error before the file starts uploading, or only after the transfer is complete?

c) How does the system ensure the Shipyard provides correct and complete metadata during upload?

Can the system reject a submittal that doesn't meet PAE Platforms’ file-naming or metadata standards?

3) [Automated Folder/File Naming]: The system must automatically name and file documents in Google Drive based on PAE Platforms’ naming conventions, removing manual filing tasks.

4) [timestamp] The system shall time stamp and log various events. State the individual actions, events, changes, etc that the system is capable of capturing and if the selection of those events can be tailored by an Admin.

a) State any method(s), format(s) and/or standard(s) used to time stamp and log activities in the system (ie ISO/IEC 18014).

5.3 Workflow Management - Hierarchical Workflow

1) [Sequential Tier Approval Chain] The system must support an internal routing process, where SME’s and Engineering Leads are assigned to each DI:

a) Subject Matter Experts (SMEs): Initial technical review and comment generation.

b) Engineering Leads: Consolidation and technical back-check.

c) Ship Design Manager (SDM): Strategic technical alignment.

d) Program Manager (PM): Final authorization and formal release.

e) Does the system support Parallel SME Review within the first tier? Specifically, can multiple

SMEs provide comments simultaneously, and can the Engineering Lead then 'reconcile' those comments into a single unified position?

f) How is it marked that users have completed their Review of the DI?

2) [Formal Release Gate] To ensure a unified government position, no comments shall be visible or transmitted to the Shipyard until the PM has formally approved. All comments for a specific DI must be bundled and sent as a single formal response.

a) Describe how the 'Formal Release Gate' works. Does the system provide a 'Drafting' state where comments are only visible to the Government, and a 'Released' state where they are locked and transmitted to the Shipyard? Can th

3) [Bounce] Escalation & "Bounce" Capability: A reviewer at a higher tier (e.g., the SDM or PM) must have the ability to manually by-pass a lower tier reviewer (i.e. pull a review up to their level if prior

4 | Page reviewers have not indicated completion, helping ensure program schedule is maintained. Each bounced deliverable shall be have an indication of the bounced status and of the users that were bounced.

a) Explain the 'Admin Override' or 'Bounce' capability. If a PM pulls a review forward because an

SME is on leave, does the system automatically log that the SME stage was 'Bypassed by PM [Name]' for audit purposes? Can the PM also 'Reject' a submittal back down to the Engineering Lead for rework? Can the PM preview the entire bundled package as the Shipyard will see it before hitting 'Send'?"

4) [Comment Lineage & Backtracking] The system must maintain a "digital thread." Any final issued comment must be traceable to the initial SME commentator, including original and subsequent comment language with corresponding timestamps. It must be possible to see who was a reviewer and lead reviewer of each revision of each DI.

a) How is comment history stored? If an Engineering Lead edits an SME's original technical comment for tone or clarity, does the system preserve a side-by-side history of the original SME text and the final PM-approved text? Is this history exportable in your 'Long-term Archive' (referenced in Section 1.1.b)?

b) Demonstrate how the system maintains the "who, what, and when" for a single comment as it moves through the SME-to-PM approval chain.

c) When we export the 'final response' to the Shipyard, can we generate an internal-only version that includes the names of every SME who contributed to each specific comment line item?

5) [dropdown for comment status] Each posted comment must depict comment status with a pre-set status menu (i.e. Open, Closed, RFV, ECP). The pre-set status menu shall be amendable.

6) [automated routing] The system must support "If/Then" logic. It should be able to route a DI based on its metadata (e.g., DI Type, Department, or Priority)

7) The system shall integrate the documents with the corresponding workflow(s).

8) [simple approval chain modification] The system must provide a graphical, drag-and-drop interface for administrators to build and modify approval chains without software programming.

a) Please provide a screenshot or video demo of your workflow configuration screen. How long does it take an administrative user to add a new 'Review Tier' to an existing process?

b) When a workflow is modified (e.g., adding a second SDM), does the system maintain a version history of the workflow itself? Can we see what the approval chain looked like for a DI approved six months ago versus one approved today?

9) [reviewer notifications] The system must make it clear to the Government employees what DI’s are currently in their queue for review and notify the reviewer of impending reviews.

a) Please show how users would be alerted and know what DI’s are currently in their queue and the date they need to have the review complete.

5.4 Review and Comment - Iterative Commenting & Visual Context

1) [logging comments] Tabular Review Tracking & Logging: A spreadsheet-style interface for comments, responses, counter-responses, etc., demonstrating association with a corresponding file in the workflow. NOTE: The comment, response, counter-responses, etc. shall be provided viewable (if opted to view in the same context of the comment) with time & date, original author, last person to amend the data, approver(s), status of comment, project, etc.

a) Please show the interface for logging comments, including snips.

2) [visual context] "Snip" Integration: Reviewers and Shipyard personnel must be able to paste image captures or "snips" of drawings directly into comment rows to provide visual context.

a) When a DI moves from Rev 0 to Rev 1, how are the "Open" comments from the previous revision displayed to the reviewer? Can the reviewer see the previous "snips" while reviewing the new file?

b) Describe the technical process for users to "paste" snips directly into the comment table. Is this an attachment or an embedded image?

5 | Page

3) [persistence of open comments] Persistence Across Revisions: Comment tables must be organized by DI; unresolved comments from Rev 0 must persist and remain visible in the Rev 1 table until officially closed.

a) How does the system handle a "partial approval" (e.g., 90% of comments on a Scantling Plan are closed, but 10% remain open)? Does the DI status update automatically?

4) [SY/Govt Correspondence] The "Dialogue" Loop: Structured fields to support a digital back-and-forth: Gov Comment -> Shipyard Response -> Gov Back-check/Disposition. The system must allow back and forth correspondence between the Government and the Contractor on each comment on each Submittal as official correspondence before the next revision is received.

a) Please show how the back and forth correspondence between the Government and the Contractor on a particular comment would be accomplished in your program. For instance, if the Government provided a comment, the Contractor disagreed with a comment, and the Government disagreed with the Contractors comment all before the next revision with possibly additional back and forths, how would this be handled by the system?

b) Are there limits to the back and forth communication between the Shipyard and the Contractor?

5) [categorization] The system must allow for the reviewer to assign a category to the comment, such as

“contract, design, administrative”

a) Can the system create custom dropdowns?

6) [comment closure] The system must allow for the Government to mark comments as ‘pending’, ‘closed’ or ‘open’ and record the date and name of person closing comments or re-opening comments.

7) [unique ID] Each initial comment shall be assigned a unique ID which does not change.

Correspondence related to the initial comment should fall under this unique ID.

5.5 Program Management and Reporting - Resource Management & Visibility

1) Workload Visualization: Real-time dashboards showing the review queue volume currently assigned to each individual Government Engineer (SMEs and Leads).

2) Resource Management & Allocation broken down per project(s), teams (i.e. electrical team, mechanical team, administrative team, structural team, etc.), and individuals.

3) Project Metrics: Dashboards showing the following:

● Schedule % Complete per project and per entire program

● Track schedule based on fixed and non-fixed deadlines

● Float time per project

a) Show a sample dashboard that displays "Shipyard Delinquency" (Data Items that were due but have not been submitted).

4) Dashboard showing number of Open/Closed Comments

a) Per DI

b) Per program

c) associated with critical path of corresponding project(s)

5) Configurable and Modifiable Visualizations (i.e. pie-charts, Gantt-charts, bar-charts, line graphs, etc.)

of resource management, scheduled metrics, trend analysis.

6) Automation & Administrative Reduction - Self-Generating Dashboards: Analytics and metrics must update in real-time based on workflow actions without manual data entry or manipulation by a Data Manager.

a) Can the system trigger an automated alert to the SDM if a submittal has exceeded a pre-defined

"Government Review Time" (e.g., 14 days)?

b) Describe how a manager can generate a report showing every comment originated by a specific

SME across all active ship programs.

c) Describe how the system eliminates the need for a human "Data Manager" to update status trackers or progress spreadsheets.

6 | Page

5.6 Access Control and Security

1) The system will need to be approved for use by NOAA IT.

a) Does the system include its own data storage? If so, is the physical data storage located within the United States?

b) Is the platform FedRAMP authorized or compliant with NIST 800-171/53 standards?

c) How is data encrypted at rest and in transit?

d) Describe user authentication options

e) Describe how the system maintains security for "Anywhere" access. Does the platform support

Multi-Factor Authentication (MFA) or integrate with Government Single Sign-On (SSO) and CAC/PIV card readers?

5.7 Legacy Data Migration

1) Could Metadata related to each DI submittal (such as submittal date, name of lead reviewer, name of

SME reviewers, comment logs, approval dates) be transferred from other systems?

2) Describe your comprehensive approach to migrating data out of legacy systems while maintaining full data integrity. Is there a specific protocol that the existing data would need to be in?

6 Other Information Sought

6.1 Industry Benchmarking & Proven Performance

1) Provide a list of the specific Government, Commercial, and Regulatory entities currently using your platform for ship acquisition oversight.

2) For the owners listed above, describe the typical configuration of their approval workflow. Does it match the SME-to-PM tiered structure required by PAE Platforms?

6.2 Pricing

1) Provide a Rough Order of Magnitude (ROM) for a Base Year plus 4 Option Years.

2) Assume a user base of 20–30 active Government and Contractor users. Does your licensing model charge per user, per program, or via an enterprise license?

3) Are there additional costs for "external" users (e.g., Shipyard personnel) to access the portal?

4) Would your company support data migration? If so, how are costs associated with data migration determined? If not, who would you recommend for data migration?

5) Whether the system requires training and/or support and how it is recommended to be implemented.

6.3 Demonstration

1) Please indicate whether a live demonstration (in-person or teleconference) of the functionalities listed in the RFI could be provided with a sample multi-sheet Autocad file (.dwg), a multi-sheet pdf file, a MS Excel file (.xlsx), and an Autodesk Navisworks file (.nwd).

2) Please indicate whether a demonstration version of the software could be made available for our internal testing purposes and whether there would be limitations in the demonstration version.

7 Response Requirements

Please provide responses to Contract Specialist Erik De Santis at erik.desantis@noaa.gov by December 4, 2026, 2pm EST.

Responses shall clearly mark any proprietary information that is contained within them. Responses shall not contain classified information. RFI responses should be submitted electronically in a pdf format to the point of contact in this notice.

7 | Page mailto:erik.desantis@noaa.gov

Please include the following with your response:

1. The RFI number stated herein.

2. The company name, location of home facility, CAGE code, and DUNS number, as well as the telephone number, and mail and e-mail addresses of a point of contact having authority and knowledge to discuss the submission.

3. Responses indicating whether the system would be able to meet the Desired Capabilities and various questions in Section 5 and responses to the questions in Section 6.

4. Any suggestions for changes to the current set of Desired Capabilities for future incorporation into an RFP.

5. Existing Government Contract Vehicles & Acquisition Channels Please indicate whether your software platform, hosting environment, and associated implementation/training services are currently available through any existing Federal Government contract vehicles or Government-Wide Acquisition Contracts (GWACs). For each applicable vehicle, provide:

1. Contract Vehicle Name:

○ GSA Multiple Award Schedule (MAS) (specify Special Item Numbers, e.g., SIN

511210 – Software Licenses, SIN 54151S – Information Technology Professional Services, SIN 518210C – Cloud and Cloud-Related IT Services)

○ NASA SEWP (Solutions for Enterprise-Wide Procurement) (specify prime contract holder name, SEWP Category/Group, and whether offered via direct prime or authorized reseller)

○ NIH NITAAC CIO-SP3 / CIO-SP4

○ GSA OASIS+ / OASIS Small Business

○ Department of Commerce / NOAA Enterprise Vehicles (e.g., NOAA ProTech domains, if applicable)

○ Any other Agency-specific BPA or IDIQ open to NOAA orders

2. Contract Number(s) & Expiration/Ordering Period Dates

3. Prime vs. Sub/Reseller Status: Indicate whether your firm is the Prime contract holder or if the solution is offered through an authorized federal reseller partner (e.g., Carahsoft, Mythics, ThunderCat, ImmixGroup).

4. Business Size & Socioeconomic Status: State your business size and any socioeconomic designations (e.g., Small Business, 8(a), WOSB, SDVOSB, HUBZone) under the relevant NAICS code for that vehicle.

NOTE: If necessary and required based on responses to this RFI, the Government reserves the right to schedule vendor meetings and have discussions between vendor personnel and NOAA representatives regarding the capabilities of the vendor supplies/services being suggested. All vendor meetings will be authorized, approved, and conducted by the Contracting Officer to ensure they do not create a potential exclusive situation that gives competitive advantage or otherwise disadvantages participants in any potential future competition.

8 | Page

7Response Requirements