47HAA024N0004 RFI PBS Project Management Information System (PMIS).pdf
PDF 414 KB Posted
- Solicitation number
- 47HAA024N0004
- Issued by
-
GSA Office of Administrative Services
About this file
This Request for Information (RFI) from the General Services Administration (GSA) Office of Administrative Services seeks information regarding Project Management Information System (PMIS) operations and maintenance support for the Public Buildings Service (PBS). The support services required include ongoing operations and maintenance of the Kahua PMIS currently implemented for PBS projects, including corrective maintenance, help desk support, optional enhancements, and technical infrastructure to support over 10,000 users and 25,000 projects across various programs. Responses to the RFI are due by January 12, 2024 to inform potential future acquisition of these services. The incumbent contractor currently provides the required support services on an agile development model through task orders awarded under an IDIQ contract.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| RFI 47HAA024N0004 - Questions and Answers- 01-09-2024.pdf |
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
General Services Administration Office of Administrative Service
Office of Internal Acquisition
Request for Information: 47HAA024N0004 for PBS Project Management Information System (PMIS)
Operations and Maintenance Support
In Support Of
Office of Public Buildings Information Technology Services
December 20, 2023
Disclaimer
This Request for Information (RFI) is for planning purposes only and is not a Request for Quote (RFQ), Request for Proposals (RFP), Invitation for Bids (IFB) or an obligation on the part of the Government to acquire any services. Responses to this RFI are not offers and can/will not be accepted by the Government to form a binding contract. The Government reserves the right to determine how it should proceed as a result of this notice. Furthermore, those who respond to this RFI should not anticipate feedback with regard to their submission. The Government will not pay any cost incurred in response to this RFI. All costs associated with responding to this RFI will be solely at the responding party’s expense. The information provided in this RFI is subject to change and is not binding on the Government. Failure to respond will not in any way prevent a potential offeror from participation in any future solicitations.
3.1 GENERAL
The General Services Administration (GSA) Office of the Chief Information Officer (OCIO), Public Building Information Technology Services (PB-ITS) as the Information Technology (IT) service provider for the GSA PBS is pursuing the acquisition of support for Kahua, as implemented currently for the Public Buildings Service (PBS), utilizing the Kahua Federal Network (KFN). The Contractor shall ensure that environments are provided and supported in the KFN to allow for development, test, training, and production business requirements. The implementation will support internal and external user access in compliance with all GSA business, IT, and security requirements. Operational maintenance of Kahua includes all necessary updates, corrective action of escaped defects or on behalf of user operations, security-related changes, security mitigation solutions, and support of future-contracted enhancements. The support of this application will include the incorporation of and ongoing maintenance of workflows presently existing as well as those developed by enhancements.
This Statement of Objectives (SOO) describes the goals that GSA expects to achieve including but not limited to:
● Provide licenses and technical infrastructure to support GSA’s use of Kahua’s Federal Network, including sufficient licenses for all modules included in GSA’s current and future Kahua implementation and for all users, internal and external, that are legitimate users of GSA’s implementation of Kahua Federal Network.
● Provide an intuitive, effective, easy to learn, and responsive end user experience to improve project team member productivity;
● Support an enterprise PMIS that is the system of record for all PBS projects;
● Promote electronic collaboration to facilitate effective project delivery practices;
● Promote PBS wide usage to improve project and program delivery;
● Provide appropriate security and privacy safeguards;
● Maintain FedRAMP and GSA Authorities to Operate (ATOs), including responses to all
POA&M items identified by the government’s security team;
● Provide a level of service that meets government and partner requirements;
● Provide end-user documentation in support of all Kahua applications in use by or available to GSA’s implementation of Kahua, including any new applications built as part of this contract
3.2 PURPOSE
GSA delivers effective and efficient government services for the American people.
As the landlord for the civilian federal government, the Public Buildings Service (PBS) acquires space on behalf of the federal government through new construction and leasing and acts as a caretaker for federal properties across the country. PBS owns or leases 9,624 assets, maintains an inventory of more than 376.9 million square feet of workspace for 1.1 million federal employees, and preserves more than 481 historic properties. PBS provides national leadership, policy direction, and standards in the areas of architecture, engineering, urban development, sustainable design, fine arts, historic preservation, construction services, and project management.
The Public Buildings Information Technology Service (PB-ITS) is a service within GSA IT that specifically supports GSA’s PBS. PB-ITS develops, deploys, and maintains IT solutions to support multiple PBS business lines in their mission to deliver effective and sustainable workplace solutions to Federal agencies at the best value. Best-value workplace solutions are, in part, achieved due to innovative and effective approaches to project execution, collaborative relationships between national and regional offices, and accurate and timely information made available to project teams and internal and external stakeholders.
Kahua is GSA’s project management system of record and is used to manage the agency’s design and construction projects through all phases of the project lifecycle from planning to substantial completion. GSA executes thousands of projects annually in Federally owned and Leased space and uses a variety of Kahua apps to aid in managing these projects including schedule management (milestones), document management (requests for information, Design Review, Submittals), and cost management (forecasts and expenses).
Kahua’s collaborative features allow a project to be accessed by all stakeholders thereby reducing the need for users to manage data in multiple project management tools. Kahua is used by all project stakeholders including internal users (GSA employees), customer agency users, and external contractors.
User Category Roles Kahua Activities
Internal Users Project managers, contracting officers, budget analysts, agency executives, planning managers, asset managers, subject matter experts, and property managers
Create projects, markup/red line documents, write status narratives, coordinate and track design review comments, view financial/contract data from official systems of record, edit milestones, manage the project team
External Contractors Construction managers, architects, engineers, construction managers, and commissioning agents.
Daily progress reporting, upload files, review drawings, provide comments, create punch lists, send requests for information, create submittals
External Customers Project managers, space management specialists, and planning managers
Review drawings, provide comments, upload files
Additionally, agency users manage projects in GSA-owned space using Kahua for tasks such as uploading files and writing status narratives.
GSA worked with Kahua to configure several of Kahua’s “out of the box” applications in accordance with GSA’s business processes. GSA also required Kahua to develop several apps that support the agency’s unique needs such as app for preparing congressional funding requests.
App usage is scalable for GSA’s different project types ranging from small repair and alteration projects to new land port of entry projects.
Kahua’s dashboards and reports allow users to quickly see project or program information. There are project fact sheets that show milestones and status, sustainability reports, and schedule reports that show milestones with estimated and actual dates. Kahua’s dashboards feature predefined or user-defined widgets that allow users to see at a glance such as the number of open design review comments or the number of completed submittals.
3.3 CURRENT ENVIRONMENT
3.3.1 System Interconnection
The Kahua Federal Network (KFN) leverages system-to-system integrations with a variety of service providers, including Autodesk for Government, Docusign for Government, GSA Google Drive and GSA Gmail. A potential future system-to-system integration with OpenSpace has been considered.
The KFN is also currently integrated with approximately a dozen GSA internal applications both in the cloud and on-premise, including REXUS, GREX, IRIS, BI, EDMS (Alfresco), FMIS, and HRDW. API integrations with GSA internal applications are orchestrated via GSA’s Mulesoft software. In addition, a GSA SFTP site is used to transfer documents and associated metadata between KFN and EDMS for files larger than the load balancer limitation for Mulesoft (200
MB).
The Contractor team is responsible for developing, testing, maintaining, and supporting Kahua specific development for these integrations, but is not responsible for the development in other applications to make this connection successful. The Contractor team is responsible for maintaining the Integration Suite application in Kahua and ensuring that automatic scheduling and manual runs of each integration occur as necessary. Manual runs are sometimes required when automatic scheduled runs fail or are turned off due to system requirements, or on an ad hoc as-needed basis.
3.3.2 Current Operation & Maintenance Support (O&M)
The incumbent contractor manages O&M activities via agile methodology, with tickets managed in GSA’s CDS Jira system. O&M activities are currently managed in two workstreams, managed in Jira as separate backlogs: (1) A variable-sized workstream for O&M activities as described below as corrective maintenance and support, defect support, desktop compatibility, infrastructure compatibility, adaptive maintenance and support, and preventative maintenance and support. The workstream size is determined on a sprint-by-sprint basis defined by open needs in the above maintenance categories and regulatory, contractual, or service-level agreement timelines. The incumbent contractor utilizes a three-week sprint schedule to manage this workstream. As of November 2023, the O&M workstream averaged approximately 15-20 user stories per sprint, and the O&M backlog contained approximately 30 user stories. (2) A set-sized workstream to address user stories and requirements defined as perfective maintenance below. The current contract delivers 75 story points per three-week sprint of perfective maintenance stories. The contractor team meets with the GSA team at least twice weekly to review progress on user stories in the sprint, review demonstrations of functionality developed during the sprint, and prioritize stories from the backlog. The contractor produces artifacts to document the progress of each sprint, including measures of sprint velocity, success or failure of specific development efforts and user stories, testing protocols and results, etc. As of November 2023, the Perfective Maintenance workstream averaged approximately 10-15 user stories per sprint, and the Perfective Maintenance backlog contained approximately 80 user stories.
Minor configuration changes are made in realtime, as allowed by the system. The incumbent contractor utilizes weekly releases to release minor application changes and configuration changes that require a release. Major application changes or platform changes are released in scheduled major releases approximately once every two months, as defined by Kahua’s major release schedule.
The following describes the type of work included in O&M:
Corrective maintenance and support: Involves repairing defects resulting from design errors, logic errors and coding errors. Defects result from data processing errors and system performance errors, escaping internal quality control and client acceptance testing, or reported through a help desk or other designated interface. Ongoing maintenance and support may include the administrative update of data by script, data load or similar updates consistent with the Content Management policy of the Government.
Defect Support - Corrective maintenance for all enhancements after their Government acceptance and deployment in the Production environment.
Desktop Compatibility - Ensure the application is operable using the GSA list of approved desktop software including testing the application to remain compatible with desktop operating systems and internet browsers including Microsoft Edge Chromium and Google Chrome.
Server (Infrastructure) Compatibility - Ensure the application is operable using the PB-ITS list of approved server software. Notify the Government of [hotfixes, patches] impacting the usability or impact to the application.
Adaptive maintenance and support: Adapt the application as a result of changes to the environment where the application operates. The PB-ITS environment includes three (3) nearly identical environments including PRODuction, INTegration, TEST. The environment change may result from a change in business rules or processes, technical configuration, user access, government policies, and software and hardware platforms.
Preventive maintenance and support: Involves activities aimed at increasing the system’s maintainability, such as improving the modular structure of the software systems and updating documentation. This maintenance includes the upgrade of components before they reach end-of-life , frameworks, versions to maintain the technical operation of the information system.
Perfective maintenance and support: Involves accommodating new or evolved user requirements. It generally includes functional or user interface enhancements to a component or service and activities that increase the system’s performance. Updates may include modifications to existing templates or reports. (Note: enhancements are considered those where there are significant structural change(s) or significantly new features are added requiring substantial work and are not included in this category of maintenance and support).
Examples of O&M User Stories
1. As a user in either WinUI Desktop or WinUI Web, I want to be able to create/modify/delete markups in Kahua PDF Viewer.
2. As a user, I want the following apps to be moved into the the Document Management category in the App Menu: File Manager, Design Review
3. As a Project Manager or Administrator, I need the ability to continue to edit Project fields when a Project is On Hold so that I do not have to Activate the project to make changes to it.
3.3.3 Current Optional Enhancement Support
An enhancement is a noteworthy and noticeable improvement to the application above and beyond what is considered normal maintenance. Enhancements have their associated funding that is approved separately from normal maintenance. Enhancements include the creation of a new module or other major changes to the functionality of the application.
Enhancements do not include normal changes in keeping up with modern, secure technology changes or bug fixes that are found in previously published code. Security-related changes would also not be included in enhancements such as updating to a newer version of encryption as it is a required change to keep the application up-to-date and compliant with security. Updating or upgrading existing inter-system connections would also not be considered an enhancement if there is a required change to the connection due to other applications making upgrades or modernizations as long as the functionality remains relatively unchanged.
Since deployment of Kahua at GSA, some of the optional enhancements provided by the incumbent contractor include:
● Building a new Kahua app for PBS’s Section 106 Historical Preservation program.
● Building viewer tools into the Kahua 3D model viewer based on GSA’s Common Data eXchange (CDX) specification.
GSA has a number of potential enhancements that may be required in the immediate future. For example:
● Building a new Kahua app for PBS’s Green Proving Ground program.
● Building a new integration between Kahua and GSA’s National Cost Management Tool
It is important to note that Enhancement Support is not guaranteed for a set time or number of enhancements; all enhancements will be subject to budget availability and GSA IT Governance approval.
3.3.4 Current Help Desk Support
The Incumbent currently provides Help Desk support, in collaboration with the System Administration Support and Training (SAS&T), GSA IT Service Desk, and GSA team of regional Kahua Program Managers (KPMs).
● In general, Tier 1 end user support is handled by the GSA IT Service Desk, SAS&T, and KPM personnel. These personnel escalate help desk tickets to the Incumbent contractor as required, and the Incumbent provides technical support as requested. The Incumbent provides Tier 2 and Tier 3 end user support as required.
● The Incumbent provides metrics and reports on user and system performance, helpdesk requests, and other GSA requirements in the form of reports, data extracts, and charts, as appropriate and as requested by GSA. Data is provided as laid out in the deliverable schedule on a weekly, monthly, or quarterly basis, depending on the metric.
● The incumbent provides scripts, support, training, and training materials to the GSA core team, GSA IT Service Desk, and SAS&T personnel as required. The Incumbent creates resources and training delivery methods to include user forums, web pages, online instructor-led training, in-person instruction, chat sessions, individual screen-sharing sessions, and other methods as required. These services encompass all functionality in use by GSA’s Kahua implementation, including platform functionality available to commercial clients as well as functionality specific to government clients and/or GSA exclusively.
● The Incumbent provides information to GSA users, core team members, and SAS&T personnel about new features, upcoming releases, product line changes, and product roadmap strategies.
● The Incumbent provides information to GSA users, core team members, and SAS&T personnel about scheduled maintenance periods, unscheduled performance degradations or system outages, and other information that impact usage of the system.
● The Incumbent provides user guides, quick reference guides, and other instructional material for all system functionality in use by GSA, including all new features and functionality upon release to GSA’s Kahua environment. The Incumbent maintains configuration specifications for all apps in use in GSA’s Kahua environment and ensures that GSA’s implemented configurations are kept up to date in all technical documentation and support materials.
3.4 SCOPE
The scope of the resulting contract will include all services provided by the Incumbent Contractor as described in Section 3.3 above. This includes O&M support, including perfective maintenance, helpdesk support, and optional enhancements as executed by the Contracting Officer.
The scope of this SOO includes, but is not limited to, software development, integration, testing, maintenance, audit support, system analysis, impact analysis, documentation, reports, and progress monitoring using reporting procedures and measures of performance. The offeror's solution should align with industry best practices, National Institute Standards and Technology (NIST), Office of Management and Budget (OMB), GSA, and PB-ITS policy and guidance in a manner consistent with CMMI Level III and ISO 9001:2015 practices and protocols.
3.5 PERIOD AND PLACE OF PERFORMANCE
The Phase-In period is approximately one (1) month. The Base period of performance is approximately eleven (11) months from contract award with four Option periods. The remaining four (4) Option periods are twelve (12) months each.
The anticipated period of performance will be as follows:
Period Starting Ending
Phase-In 8/1/2024 8/31/2024
Base 9/1/2024 7/31/2025
Optional Year 1 8/1/2025 7/31/2026
Optional Year 2 8/1/2026 7/31/2027
Optional Year 3 8/1/2027 7/31/2028
Optional Year 4 8/1/2028 7/31/2029
GSA is currently in a full-time telework environment. The work performed for this effort will be at Contractor facilities within the United States. Access to the Government facilities are limited at the Government's discretion and meetings may be scheduled requiring in-person attendance by contracted participants. Where possible, at least one (1) business day notice will be provided.
Accommodations including remote meeting space, teleconference and similar technology may be used to conduct meetings. The hours, exact location, and availability of government work space is subject to availability and identified by the Government. Contractor meetings shall be conducted at a location to be approved by the GSA COR or other designated GSA representative.
3.5.1 PERIOD OF TRANSITION
The Phase-In/Phase-Out process is defined as a smooth transition from one Contractor to another, in order to maintain the program’s integrity required under this and the previous agreements. The Phase-In period shall be limited to 8/1/2024 to 8/31/2024, or as specified by the Contracting Officer (CO).
3.6 TECHNICAL OBJECTIVES
3.6.1 Procure support services with a high degree of reliability and availability.
1. Procure support that includes effective contingency and disaster recovery planning.
2. Procure support that provides Kahua services that are dependable and provide response rates that are consistent with industry standards.
3. Provide support that scales with GSA needs and requirements, including performance, storage, and responsiveness. Relevant orders of magnitude for the desired implementation include:
a. 10,000 users
b. 25,000 projects of 11 varieties in 12 programs
c. A minimum of 25 documents per project
d. 25GB/file for some file types, such as BIM files
4. Provide support that meets the following service level objectives:
The following table describes the priority levels assigned to requests for problem resolution with the associated response and completion time commitments.
Priority Definition Response Time During Business Hours
Completion Time
Critical
● A problem that affects the entire Kahua user community or a group of users such as login
15 minutes 4 hours
High
● A problem with no known workaround that affects a single user
● An issue involving one of the following apps: File Manager, RFIs, Submittals, or Schedules
1 hour 8 hours
Medium
● A general service request or problem with a workaround solution
● Call for service that affects daily productivity, but does not meet the requirements of higher priority levels
● An issue involving any app not listed in the High section above
4 hours 24 hours
Low
● A service request that does not require immediate attention or involves long-range planning
8 hours 3 days
For proposed performance that falls outside the SLA, the Offeror shall provide:
● A description of the practices, protocols, and inspection system to cover all services listed in the SOW, exclusive of the SLA. The description shall include specifics as to the areas to be inspected on both a scheduled and unscheduled basis and frequency of these inspections.
● A follow-up description of procedures to ensure that deficiencies are corrected and the time frames involved in correcting these deficiencies
● A description of the records to be kept to document inspections and corrective or preventive actions taken
● Contractor’s concise overview description supporting their capability to implement proposed practices
● The records of inspections shall be kept and made available to the Government, when requested, throughout the performance period, and for the period after completion, until final settlement of any claims under this agreement.
3.6.2 Procure support services that ensure that all Kahua platform level, application level, or customization changes are fully functional at time of release to the Federal Network and GSA environment.
1. Support the production environment as well as other technical environments required by the Government including but not limited to development, user acceptance testing, training.
2. Provide at least one independent non-production FedRAMP approved environment so that pre-release testing can be conducted in the Federal Network without impacting the production environment.
3. Implement communication protocols to ensure that GSA is provided with timely information prior to release of any new feature at the GSA environment or Kahua platform level.
4. Ensure that all GSA customizations, configurations, or application extensions are maintained and fully functional for all versions and upgrades of Kahua at the Federal Network or commercial platform level. Propose and implement configurations and solutions that enhance and do not degrade system operability, including all integrations.
3.6.3 Procure support services that ensure that Kahua is fully supported for the life cycle of the system. Software must be on GSA’s Enterprise Architecture IT Standards List.
1. Identify and track all software components and associated end of life dates, including third party software, used within or integrated with the application as a part of the system inventory or to provide core functionality via integration.
2. Notify the Government of hotfixes or end-of-life dates to the operating system, middleware, database, third party components or technical platforms (including patches) impacting the security posture or usability of the application as soon as the end of life date is identified.
3. Replace or upgrade unsupported information system components or provide justification for the continued use of unsupported components.
4. Meet all requirements for continued approval by the GSA Enterprise Architecture IT Standards.
5. Provide up-to-date editable diagrams and documentation of technical architecture and other technical information as requested by GSA.
6. Propose configurations and solutions to meet government requirements that lie within the Kahua COTS PMIS technology roadmap to minimize cost to the government from customizations and extensions.
3.6.4 Procure support services that provide tools for data display, reporting, and dashboarding of all data contained in the system.
1. Ensure that all app fields are selectable for inclusion in log views for all system apps.
2. Enable data to be selected across apps for reporting and dashboarding, including in use of the Report Wizard.
3. Ensure that dashboards can use filters to show a specific set of projects.
4. Enable admin users to see all reports with scheduled deliveries.
5. Enable viewing of data from a single partition or rolled up from lower partitions (ex.
Partition above a project should show rollup of Safety items from child projects)
3.6.5 Procure support services that adheres to IPv6 Requirements.
Operational deployment and use of IPv6 has been mandated by the Office of Management and Budget (OMB) via M-21-07. The OMB directive, issued on November 19, 2020, includes the requirement to upgrade internal client applications that communicate with public Internet servers and supporting enterprise networks to operationally use native IPv6. All Agency systems, software, and equipment, or their replacements, shall be supported by IPv6.
3.7 QUALITY
Both the contractor and the Government have responsibilities for providing and ensuring quality services, respectively.
3.7.1 Contractor Quality Management
The contractor shall identify and implement its approach for providing and ensuring quality by developing a Quality Management Plan (QMP). The QMP shall describe the application of the appropriate methodology (i.e., quality control and/or quality assurance) for accomplishing performance requirements. The QMP shall describe how the appropriate methodology integrates with the Government’s requirements. The contractor shall submit the QMP as part of its technical quote. The contractor shall make appropriate modifications to the QMP (at no additional cost to the Government). The Government has the right to require revisions of the QMP (at no cost to the Government) should the QMP fail to deliver the quality of the services required at any time during the performance.
3.7.2 Performance Measures
The Contractor is expected to develop performance measures and metrics that directly correlate to the SOO. The Government will develop and utilize a Quality Assurance Surveillance Plan (QASP) throughout the life of the task order to ensure that the contractor is acceptably performing the required services. The Government reserves the right to alter or change the surveillance methods in the QASP at its own discretion, such change shall be subject to the appropriate changes clause. A Performance-Based Service Assessment Survey will be used in combination with the QASP to assist the Government in determining acceptable performance levels.
3.7.3 Government Quality Assurance
The Government will perform periodic reviews of the contractor’s performance per the Government’s QASP. The QASP will be finalized after the award. The Government reserves the right to review services to be provided, including those developed or performed at the contractor's facilities, to determine conformity with performance and technical requirements.
3.7.4 Deliverables
Timely submission of deliverables is essential to successfully completing this requirement.
Schedules for deliverables are specified in Exhibit A. All deliverables shall be prepared and submitted according to format, content, and schedule described in the SOO. The Contractor will produce numerous working deliverables to facilitate the agile project management approach;
such deliverables shall be proposed in the Contractor’s Performance Work Statement and amended, as required, over the life of the task order. The Government will participate collaboratively in the creation and revision of these deliverables and will have ultimate approval of these deliverables. The contractor-developed Performance Work Statement (PWS) shall include all deliverables identified in the table below. All deliverables shall be produced per PB-ITS software standards as well as GSA security standards (See Attachment 1).
The contractor-developed PWS shall include proposed due dates and update frequency for all required deliverables, leveraging the values and principles of an Agile framework to the maximum extent practicable. In addition to the deliverables listed below, the contractor shall comply with all deliverable requirements mandated by Attachment 1 - GSA IT Security Requirements.
At a minimum, the Contractor developed PWS shall address:
Exhibit A
Deliverable Frequency Test Plans For each release Iteration Review A hands-on demonstration in the GSA-provided development environment showcasing the output of the sprint and hands-on business line testing of all sprint development prior to release.
Iteration Burndown
Release Burndown
Velocity Maximization - Anticipated VS. Actual
Work in Progress
Defect Management - Log containing discovered defects
Test Reports Service Level Agreement including Backup, Business Continuity and Disaster Recovery Plans
Included in contractor developed PWS
After Incident Report / Root Cause Analysis Within 2 business days of any performance or security incident
Project Plan and Project Schedule Included in the contractor developed PWS.
Weekly Status Updates (including Agile artifacts) in a form acceptable to the Government
Weekly
Monthly Status Updates (including Agile artifacts) in a form acceptable to the Government
Monthly
User Support Plan Included in contractor developed PWS Training Plan Included in contractor developed PWS Training Materials Included in contractor developed PWS Quality Management Plan Included in contractor developed PWS Communication Plan Included in contractor developed PWS Contractor Self-Evaluation of Performance Annually
Draft Phase-Out Plan 90 days prior to task order expiration Final Phase-Out Plan 75 days prior to task order expiration
The Contractor shall deliver the deliverables specified in the table above on dates specified therein, or on such revised dates as the Contracting Officer may specify. All deliverables expected to be included in the contractor-developed PWS (as indicated in the table above) shall also be revised throughout this contract, as applicable.
All documentation, including, but not limited to, documented processes, procedures, software tools and applications, test materials, text, notes, electronic files, data, new capabilities or modification of existing applications, source code and records generated, modified, acquired, or produced by the Contractor under this task order shall become the property of the Government.
Per FAR 52.227-14(b), the Government shall have unlimited rights to all produced materials, including the right to modify, distribute and publish. The Contractor shall deliver electronic copies of all produced materials to the Government quarterly (or as requested) and upon expiration or termination of this task order. The Contractor may mark the deliverables to indicate its authorship, provided, however, that it shall not include any markings inconsistent with the Government’s unlimited rights. The Contractor agrees that the Government may release any deliverable in response to a Freedom of Information Act (FOIA) request, subject to any right to object or to request redactions that the Contractor may otherwise have under the Act or applicable agency regulations.
All deliverables in printed or other media forms containing Personally Identifiable Information (PII) and/or Sensitive But Unclassified (SBU) information shall follow applicable policies including (2103.2 CIO Controlled Unclassified Information (CUI) Policy - April 10, 2021);
(2180.2 CIO GSA Rules of Behavior for Handling Personally Identifiable Information (PII) - October 8, 2019) and (3490.3 PBS CHGE 1 Security for Sensitive Building Information Related to Federal Buildings, Grounds, or Property - March 22, 2021). The Contractor shall ensure and the application is designed to function per applicable Federal Information Processing Standards Publication (FIPS PUB) 140-2 and all applicable annexes or subsequently approved federally recognized policy for the protection, operation, and/or delivery of Federal information technology systems.
3.8 CONSTRAINTS
This section lists laws, rules, regulations, standards, technology limitations and other constraints that the service and/or service provider must adhere to or work under.
3.8.1 GSA IT Security/Access Control/Authentication
Contractors entering into an agreement for services to the General Services Administration (GSA) and/or its Federal customers shall be contractually subject to all GSA and Federal IT Security standards, policies, and reporting requirements. The Contractor shall meet and comply with all GSA IT Security Policies and all applicable GSA and NIST standards and guidelines, other Government-wide laws and regulations for protection and security of Information Technology. Additional information regarding requirements for this SOO, specific to different types of information systems/IT solutions, is available in the Attachment 1 GSA IT Security Requirements.
The information system/IT solution shall support an Multi-factor Authentication (MFA) solution that aligns with a Digital Identity Acceptance Statement per NIST SP 800-63-3, Digital Identity Guidelines, and acceptable authentication methods specified in NIST 800-63B, Digital Identity Guidelines: Authentication and Lifecycle Management.
The MFA solution shall meet the requirements specified in GSA-IT Security-01-01, Identification and Authentication. MFA solutions that meet GSA’s requirements include:
● Personal Identity Verification (PIV) Cards
● PIV derived (SAML, OIDC, OAUTH)
● Time-Based One Time Password (e.g., Google Authenticator, Authy)
● HMAC-Based OTP (physical token)
● Fast Identity Online (FIDO)/Web Authentication (WebAuthn)
The information system/IT solution shall implement encryption algorithms and cryptographic modules that are FIPS-approved and FIPS PUB 140-2 validated, respectively, including Digital signature encryption algorithms, block cypher encryption algorithms and secure hashing algorithms. For web services connections, implement end to end encryption terminating the connection at the web server; connections terminated at a load balancer shall employ re-encryption techniques to ensure end to end encryption. Internet accessible Websites shall implement HTTPS Only with HTTP Strict Transport Security (HSTS), have no weak ciphers, have no weak protocols, and preload .gov domains. (see Binding Operational Directive (BOD) 18-01, Enhance Email and Web Security). SSL/TLS implementations shall align with GSA IT Security Procedural Guide 14-69, “SSL/TLS Implementation.”
Any cloud information systems or components, including Infrastructure as a Service (IaaS), Platform as a Service (PaaS), or Software as a Service (SaaS), must be FedRAMP authorized, in-process, or ready. Additional information on Fedramp authorization and requirements can be found on the FedRamp web page and Attachment 1 GSA IT Security Requirements.
RFI Submission Instructions
Vendors shall submit responses to the RFI via email, no later than 11:00 AM EST, Friday, January 12, 2024. Responses shall be submitted to the Contract Specialist, Kenya McPherson, kenya.mcpherson@gsa.gov and Contracting Officer, Erica Pelham at erica.pelham@gsa.gov.
Responses shall not exceed 25 pages. All responses shall be typewritten and presented in MS Word or PDF format (minimum of 12 point, Times New Roman or Arial font). Vendors may provide additional materials relevant to the RFI (e.g., screenshots, etc.) as attachments outside of the 25 pages, for a maximum of 10 additional pages.
GENERAL QUESTIONS AND FEEDBACK:
Vendors are encouraged to submit general questions and feedback to help GSA to strengthen its requirement. Questions and feedback shall be limited to one (1) page. All Vendor questions shall be presented no later than Monday, January 8, 2024 at 10:00 AM ET. The government (GSA) reserves the right to not respond to Vendor questions prior to the RFI close date.
All interested parties shall furnish the following information:
● Name of Company
● POC, Telephone Number(s), Address, Website and Email Address
● Applicable Contract Vehicles (e.g., GSA Schedule, GWAC, BPAS, etc.)
● Unique Entity Identifier (UEI) Number
● Business Size
PUBLIC RECORDS AND REQUESTS FOR CONFIDENTIALITY:
Any document submitted that contains confidential information must be watermarked as containing confidential information, and each page upon which confidential information appears must be marked as containing confidential information. The confidential information must be clearly identifiable to the reader wherever it appears.
COPYRIGHTS
By submitting a response, the vendor agrees that the government may copy the response for purposes of facilitation of review or to respond to requests for public records. The vendor certifies that such copying will not violate any copyrights in the materials submitted.
COST TO VENDORS
The government is not responsible for any costs incurred by a vendor in relation to the preparation of a response to this RFI.
NO OBLIGATION TO ISSUE REQUEST FOR QUOTE
This Request for Information (RFI) is issued solely for information and planning purposes - it does not constitute a Request for Proposal (RFP), Request for Quote (RFQ), Solicitation, or a promise to issue an RFP, RFQ, or Solicitation in the future. This RFI does not commit the Government to contract for any supply or service whatsoever. Unsolicited proposals will not be accepted.
Interested parties are advised that the Government will NOT pay for any information or administrative costs incurred in response to this RFI; all costs associated with responding to this RFI will be solely at the interested party's expenses. Not responding to this RFI does not preclude participation in any future Solicitation, if issued. It is the responsibility of the interested parties to monitor the official Government Points of Entry for additional information pertaining to this requirement.
The information provided in this RFI is subject to change and is not binding on the Government.
No commitment is being made to procure any of the items discussed, and release of this RFI should not be construed as such a commitment or as authorization to incur cost for which reimbursement would be required or sought. All submissions become Government property and will not be returned.
Proprietary information, if any, should be minimized and must be clearly marked. To aid the Government, please segregate proprietary information. Please be advised that all submissions become Government property and will not be returned in any format or manner.
Vendor Questionnaire
Please provide your responses to the questions below as part of your RFI response. The responses to these questions are part of the maximum page count.
1. Does your firm have experience working with federal government IT systems? Please specify if that experience includes experience with GSA IT and/or PBS IT.
2. Does your firm have personnel with current, unexpired HSPD-12 clearances? If so, in what roles?
3. Does your firm have any existing contract vehicles in place with GSA? If so, please specify.
4. Describe your experience as a prime contractor supporting various stakeholders such as Leasing, Portfolio, Finance, Operations, including supporting data integrations between key IT applications for multiple stakeholder groups, and handling conflicting priorities.
(OR Experience integrating complex systems with other systems operated and maintained by a diverse group of contractors and employees).
5. What is your firm’s socioeconomic status?
6. What percentage and total number of your project personnel have PMP, Scrum, PMI-ACP, or other relevant certifications? In what roles?
7. Do you have experience with Agile Scrum projects in excess of $10 million? If so, please provide details.
8. Describe your experience as a prime contractor supporting systems or applications that integrate with a variety of systems, such as financial, project management, accounting, documentation, and scheduling systems.
9. Do you have experience with complex hybrid platforms that use bi-directional data from multiple interfaces such as CAST, API, and ETL? Please explain.
10. Describe your ability to support growth in volume of data sources and data elements.
11. Describe your incident/problem reporting and tracking systems, and the ability for authorized customer staff to access those systems directly.
12. What is your firm’s experience supporting Kahua in their commercial environment?
13. What is your firm’s experience supporting Kahua in their Federal Network environment?
14. What is your firm’s experience developing and/or modifying dashboards and reports in
Kahua?
15. Is your firm able to provide licenses for Kahua? If yes, please provide an idea of the license structure you are able to procure.
16. What is your experience with SecureAuth, Login.gov, and other identity and authentication providers?
File details come from the government source that posted it. Updated .