RFI SOW OIP Portal draft 4.11.24.pdf

RFI: 70RSAT24RFI000018

DEPARTMENT OF HOMELAND SECURITY (DHS)

SCIENCE AND TECHNOLOGY DIRECTORATE (S&T)

STATEMENT OF WORK (SOW)

FOR

INDUSTRY PARTNERSHIPS PORTAL

MARCH 2024

1.0 GENERAL

1.1 BACKGROUND

The Department of Homeland Security (DHS) Science and Technology Directorate (S&T) administers several programs under Office of Industry Partnerships (OIP), including the Small Business Innovation Research (SBIR), the Silicon Valley Innovation Program (SVIP), Long Range Broad Agency Announcement (LRBAA), and Broad Agency Announcement (BAA) for DHS Research and Development (R&D)-related subjects. The DHS S&T OIP Government Off-the-Shelf (GOTS) web portal automates the administration of these programs’ solicitation, submission, evaluation, award and deliverable activity. The OIP web portal has public-facing side with training, document submission and tracking capabilities, and an internal-use side with documentation, tracking, query and reporting requirements. Support for these requirements necessitates tools and functionality for the entire life cycle of the OIP–supported programs.

The OIP portal functions as an end-to-end proposal management system that supports the BAA, LRBAA, SVIP, and SBIR award processes – from solicitation development, to proposal submission and evaluation, to contract award and administration. This award is expected to extend the current functionality, as defined by the OIP Portal Program Managers, to ensure the OIP portal is responsive to the changing needs of S&T and is providing S&T, industry, and other Government users with a high performing portal to ensure ease and convenience.

The contractor shall provide the services described in the following fourteen (14) task areas for the OIP web portal:

1. Web Portal Requirements

2. Functional and System Requirements

3. Web Portal Enhancements Development

4. Quality Assurance for All System Activity

5. Operations and Maintenance

6. Help Desk Support

7. Application Security and Support

8. Functionality Enhancements and Technical Modifications

9. Portal Content Additions and Modifications

10. User Training

11. SBIR Specific Functions

12. SVIP Specific Functions

13. LRBAA Specific Functions

14. BAA Specific Functions

1.2 SCOPE

1.2.1 The Contractor shall furnish all facilities, materials, equipment and services necessary to fulfill the requirements of this contract, except for those outlined in Section 6.0 below.

1.2.2 The Contractor shall operate, maintain and develop enhancements for the OIP web portal to meet the needs of Industry Partnership programs. The web portal shall provide tools and functionality for the entire life cycle of the javascript:__doPostBack('ctl00$ctl00$body$homebody$RecentDocuments$C$RecentDocumentsControl$PinnedDocumentResults$ctl00$DocumentNumberLink','') programs’administration to include topic development and selection, proposal submission, proposal evaluation, and post-award management to include but not limited to:

• Accounting of funds spent, obligated, and expensed

• Tracking of deliverables from awardees

• Generation of reports for administrative purposes and to support external data calls such as requests from

Congress for program statistics

1.2.3 Enhancements to the portal’s functionality is contingent on available funding and stakeholder prioritization, may include the following:

• Tracking of program performance and commercialization data in order to capture impact of award(s)

• Custom Reporting Capabilities

• Management of Umbrella/Bundled BAA’s

• Public site modernization

• Responsive web design for mobile access

• Dashboards and project timeline trackers

• Computer-based training

• Incorporation of new user roles

• Integration with user eco-system (e.g., DHS active directory, outlook, calendar, mobile phone)

• Automated interfaces with other federal systems, such as SBIR.gov for exchange of program data

Contractor access to Controlled Unclassified Information may be required under this SOW. The Contractor shall safeguard this information against unauthorized disclosure or disseminination.

Controlled Unclassified Information (CUI) Definitions (See 48 CFR 3002.1): any information the Government creates or possesses, or an entity creates or possesses for or on behalf of the Government (other than classified information), that a law, regulation, or Governmentwide policy requires or permits an agency to handle using safeguarding or dissemination controls.

The Contractor will have access to the following types of CUI:

Protected Critical Infrastructure Information (PCII): as set out in the Critical Infrastructure Information Act of 2002 (title XXII, subtitle B of the Homeland Security Act of 2002 as amended through Pub. L. 116–283), PCII's implementing regulations (6 CFR part 29), the PCII Program Procedures Manual, and any supplementary guidance officially communicated by an authorized official of the Department of Homeland Security, the PCII Program Manager, or a PCII Program Manager Designee.

Personally Identifiable Information (PII): PII refers to information that can be used to distinguish or trace an individual's identity, either alone or when combined with other information that is linked or linkable to a specific individual; and SPII is a subset of PII that if lost, compromised, or disclosed without authorization could result in substantial harm, embarrassment, inconvenience, or unfairness to an individual. To determine whether information is PII, DHS will perform an assessment of the specific risk that an individual can be identified using the information with other information that is linked or linkable to the individual. In performing this assessment, it is important to recognize that information that is not PII can become PII whenever additional information becomes available, in any medium or from any source, that would make it possible to identify an individual. Certain data elements are particularly sensitive and may alone present an increased risk of harm to the individual.

Sensitive PII (SPII): a subset of PII that if lost, compromised, or disclosed without authorization could result in substantial harm, embarrassment, inconvenience, or unfairness to an individual.

javascript:__doPostBack('ctl00$ctl00$body$homebody$RecentDocuments$C$RecentDocumentsControl$PinnedDocumentResults$ctl00$DocumentNumberLink','') https://www.ecfr.gov/current/title-48/chapter-30/subchapter-A/part-3002

Data Management The Contractor will access Protected Critical Infrastructure Information (PCII) while supporting the hardening of all Government-provided hardware in accordance with DHS and S&T procedures. The Contractor will access Personally Identifiable Information (PII)/Sensitive PII (SPII) while maintaining a repository of all proposals and awards as part of overall data management and while conducting help desk support. The Contractor will not share this data. The Contractor will not be required to retain this data for the Government. The Government will retain records included in and resulting from use of the OIP Portal in accordance with the S&T Records Inventory/File Plan for the OIP Portal System.

The Department has determined that Contractor and/or subcontractor employee access to CUI or Government facilities needs to be limited to U.S. citizens and lawful permanent residents. No foreign end products or services will be used under this contract. All data and/or information must be retained on Government Furnished Equipment and no data and/or information is to go into a Contractor information system. No foreign end products or services will be used under this contract.

1.3 OBJECTIVE

The objective of the OIP portal provide a secure web-based application environment that automates the administration of the proposal lifecycle for Industry Partnership Programs. Modification and enhancement of the OIP portal is expected to continue as currently evolving Government requirements crystallize into compliance and reporting requirements for the DHS Industry Partnership programs.

1.4 APPLICABLE DOCUMENTS

1.4.1 Compliance Documents

The following documents provide specifications, standards, or guidelines that must be complied with in order to meet the requirements of this contract:

• Office of Management & Budget (OMB) A-123 http://www.whitehouse.gov/omb/circulars_a123_rev

• OMB A-11 http://www.whitehouse.gov/omb/circulars_a11_current_year_a11_toc Federal Acquisition Regulation (FAR) https://www.acquisition.gov/far/

• FTR (Federal Travel Regulation) http://www.gsa.gov/portal/content/104790

• DHS Information Technology (IT) Security Program Publication DHS Management Directive (MD) 4300.Pub http://www.uscg.mil/acquisITION/nais/RFP/SectionJ/DHS- MD-4300-1.pdf Federal Enterprise Architecture Framework version 2 (January 29, 2013)

• DHS Acquisition Planning Forecast System Quick Reference Guide (Office of the Chief Procurement Officer/Acquisition Systems Branch), Version 1.0, April 14, 2011 http://www.dhs.gov/xlibrary/assets/opnbiz/cpo_hsam.pdf

• Economy Act (31 U.S.C. 1535 et seq.) as implemented in subpart 17.5 of the Federal Acquisition Regulation http://www.casu.gov/authority/usc1535.html Public Law 108-330 “The Department of Homeland Security Financial Accountability Act” http://www.hsdl.org/?view&did=467854

• Section 309 (a) (1)(c) of the Homeland Security Act of 2002, Public Law 107-296 (116 Stat. 2135 (2002) http://www.gpo.gov/fdsys/pkg/PLAW-107publ296/pdf/PLAW- 107publ296.pdf

• Department of Energy (DOE) Order 484.1, Reimbursable Work for the Department of Homeland Security (August 17, 2006), including its attachments https://www.directives.doe.gov/search?Title=%22DOE+o+484.1%22&Subject:list=status:+current&submit=Sear ch

• Interagency Acquisition Guide, Office of Federal Procurement Policy, OMB, June 2008 Intragovernmental Business Treasury Bulletin 2011-04 http://www.fms.treas.gov/factsi/manuals/tfm-bulletin-2011-04.pdf

• Section 508 of the Rehabilitation Act of 1973 (29 U.S.C. 794d) http://uscode.house.gov/view.xhtml?req=508+compliance&f=treesort&fq=true&num=133&hl=true&edition=prel im&granuleId=USC-prelim-title29-section794d#sourcecredit javascript:__doPostBack('ctl00$ctl00$body$homebody$RecentDocuments$C$RecentDocumentsControl$PinnedDocumentResults$ctl00$DocumentNumberLink','') http://www.whitehouse.gov/omb/circulars_a123_rev http://www.whitehouse.gov/omb/circulars_a11_current_year_a11_toc https://www.acquisition.gov/far/ http://www.gsa.gov/portal/content/104790 http://www.uscg.mil/acquisITION/nais/RFP/SectionJ/DHS-%20MD-4300-1.pdf http://www.dhs.gov/xlibrary/assets/opnbiz/cpo_hsam.pdf http://www.casu.gov/authority/usc1535.html http://www.hsdl.org/?view&did=467854 http://www.gpo.gov/fdsys/pkg/PLAW-107publ296/pdf/PLAW-%20107publ296.pdf https://www.directives.doe.gov/search?Title=%22DOE+o+484.1%22&Subject:list=status:+current&submit=Search https://www.directives.doe.gov/search?Title=%22DOE+o+484.1%22&Subject:list=status:+current&submit=Search http://www.fms.treas.gov/factsi/manuals/tfm-bulletin-2011-04.pdf

1.4.2 Reference Documents

1.4.2.1 All IT systems being planned, designed, developed, and maintained for the Department of Homeland

Security, Science and Technology Directorate (DHS-S&T), its customers, and/or with DHS data, shall be:

1.4.2.1.1 Aligned with the Federal Enterprise Architecture Framework. All solutions and services shall meet DHS

Enterprise Architecture policies standards and procedures.

1.4.2.1.2 In compliance with appropriate Office of Management and Budget (OMB) Circulars, including but not limited to OMB Circulars A-11 and A-130 as implemented by the S&T CIO.

1.4.2.1.3 In compliance with Federal Regulations including but not limited to the E-Government Act (including

Privacy Impact Assessment), Paperwork Reduction Act, Federal Information Security Management Act (FISMA), and Section 508 of the Rehabilitation Act of 1973, per the 1998 Amendments, and the Architectural and Transportation Barriers Compliance Board’s Electronic and Information Technology Accessibility Standards at 36 CFR 1194.

1.4.2.1.4 In compliance with DHS Management Directives including 4010.2, 1400, 4300.1 (and 4300A), 4900, and others as appropriate.

1.4.2.1.5 In compliance with other guidance and best practices related to the Secure Coding Initiative and secure coding verification

1.4.2.2 The following documents may be helpful to the Contractor in performing the work described in this document:

• Current OIP Portal User Guides

• Additional documents to be provided as GFI to describe current portal functionality

1.5 SPECIFIC REQUIREMENTS/TASKS

1.6 TASK 1 – SUPPORT AND ADMINSTRATIVE

The Contractor shall provide support to maintain three (3) separate IT systems for the portal:

• Development System (Hosted at the Contractor site) - used for portal development and research

• Staging System (Hosted at DHS Center 2) - closely mirrors the Production System and will be used for testing of new functionality and all system changes and modifications to the portal.

• Production System (Hosted at DHS Center 2)

Staff with administrative privileges shall be able to:

• Emulate all other user modes, both internal and public facing, to help address user issues

• Override default values in data submission fields for users as long as they do not violate data structures

• Upload and edit content on public facing sites. Such content may include audio, video, plain text, pdf, embedded application files and other generally used media formats.

• Have access to a “sandbox” mode of Staging System to be able to recreate issues experienced by users without impacting the functionality of or data in the Development, Staging or Production Systems javascript:__doPostBack('ctl00$ctl00$body$homebody$RecentDocuments$C$RecentDocumentsControl$PinnedDocumentResults$ctl00$DocumentNumberLink','')

1.7 TASK 2 – FUNCTIONAL AND SYSTEM REQUIREMENTS

The Contractor shall maintain and update and provide monthly to DHS S&T all current OIP web portal functional requirements, features and capabilities which include, but are not limited to, the following:

• Solicitation posting

• Proposal submissions

• Online review and selection of proposals

• Contract Administration

• Track awards through phases and display their status on dashboards

• Manage financials associated with awards, across the life cycle of the awards process

• Generate standard and ad hoc reports for data calls

• Store and manage current and historical data

• Migrate historical data

The Contractor shall maintain, update and provide monthly to DHS S&T all current OIP web portal system requirements, ensuring accurate inventory and documentation of all current system components). The inventory of system requirements shall include, but not be limited to the following:

• System hardware

• System software (inclusive of all appliances and tools used for development)

• Data flow diagram

• Data dictionary

• System code (current version of all code, portal source and object code)

The Contractor shall prepare functional descriptions, as appropriate, for any major changes to the OIP web portal and present them, with a proposed level-of effort and expense (e.g., labor hours by Labor Category) to the OIP Portal Program Managers for review and approval.

Upon OIP Portal Program Managers’ approval of the proposed upgrade/enhancement, the Contractor shall follow DHS and S&T CIO configuration/change management procedures to design, test and implement the change. This activity will include, but not be limited to, the following tasks:

• Filing with the S&T CIO Change Control Board for review and approval

• Creating a project plan and reviewing it with the DHS S&T CIO IT Project Manager

• Coordinating with OIP Portal ISSO to update all system documentation

• Coordinating with OIP Portal ISSO for all compliance items, e.g., code testing and system scans

1.8 TASK 3 – WEB PORTAL ENHANCEMENT DEVELOPMENT

The Contractor shall provide ability for users to identify issues and improvements to portal functionality. Bi-weekly configuration management meetings with DHS S&T will address new issues from application/program owners as well as user input. The Contractor shall provide recommendations, estimated level of effort for recommended approach and status of any ongoing change efforts.

The Contractor shall meet with program/application owners to tailor input to meet program needs. Part of this process shall be to identify potential commonalities across programs that may be adopted system-wide.

System shall be developed within the architecture prescribed by DHS S&T Office of the Chief Information Officer

(OCIO).

javascript:__doPostBack('ctl00$ctl00$body$homebody$RecentDocuments$C$RecentDocumentsControl$PinnedDocumentResults$ctl00$DocumentNumberLink','')

1.9 TASK 4 – QUALITY ASSURANCE FOR SYSTEM ACTIVITY

The Contractor shall follow DHS Systems Engineering Life Cycle Instructions (Instruction 102-01-103, Revision 00, Systems Engineering Life Cycle; and, Instruction 102 01 103 01, Revision 00, Systems Engineering Life Cycle Guidebook) and the DHS Test and Evaluation Directive and Instructions (MD 026-06,Test and Evaluation (Revision 01);

Instruction 026-06-001, Revision 00, Test and Evaluation; and Instruction Guide 026-06-001-01, Revision 01, Test and Evaluation Master Plan (TEMP)) for software development, testing and quality assurance (QA) so that system modifications, enhancements and maintenance tasks are performed without any negative impact to system performance and user experience. Development and QA activities shall include, but not be limited to:

• System Acceptance Testing

• Test Case Specification documentation.

• Traceability Matrix (RTM) documentation

• Load-testing (baseline and post-implementation)

• Unit Testing

• Functional Testing

• Production Verification Check

1.10 TASK 5 – OPERATIONS AND MAINTENANCE

The Contractor shall develop and execute an Operations and Maintenance plan to provide in-depth technical and expert product and service support services including, but not limited to, the following:

• System patching at the web tier and applications tier levels,

• Routine application and system maintenance,

• Inventory of all GOTS hardware on Contractor site (e.g., serial numbers) and all system software license keys used by Contractor,

• Production fixes,

• Installation of upgrades and enhancements,

• System back-up,

• Periodic back-up and restore, as specified in a OIP Portal Content Back-up Plan to be developed by the

Contractor, in conjunction with S&T CIO Operations, and approved by the Contracting Officer Representative (COR) and S&T IT Security.

1.11 TASK 6 – HELP DESK SUPPORT

The Contractor shall provide Help Desk Support to web portal users. This support shall include, but not be limited to, the following:

• Help Desk support will be provided weekdays, except for Federal holidays, 9AM to 5PM, EST.

• The Help Desk shall support questions on routine user issues, e.g., password re-sets, using the system to accomplish various solicitation/review/award tasks, etc.

• Help Desk activity will be managed using a ticketing system of the Contractor’s choice. Help Desk activity will be reported monthly and will contain the number, types, response times, and resolution times of tickets created and the number of labor hours spent on Help Desk support.

• Help Desk issue resolution should be address expeditiously with a goal to resolve the issue within an hour (during normal business hours). Any issue that requires more time should be brought to the immediate attention of the OIP Portal Program Managers.

javascript:__doPostBack('ctl00$ctl00$body$homebody$RecentDocuments$C$RecentDocumentsControl$PinnedDocumentResults$ctl00$DocumentNumberLink','')

• The Contractor shall provide personalized Help Desk support to the OIP Portal Program Managers, as needed.

This includes, but is not limited to, the following:

o Hands-on training and teleconference training.

o Documentation of usability issues and referring them to the Contractor team for follow-up.

o Updating of dates posted on the portal at Program staff request.

o Posting new solicitations.

o User account management.

o Documenting any issue with regard to the web portal and providing to the developers to address.

1.12 TASK 7 – APPLICATION SECURITY AND SUPPORT

The Contractor shall provide support to the system Information System Security Officer (ISSO), the S&T IT Security team and, as necessary, the DHS IT Security to ensure compliance with all DHS IT Security policies, directives and guidelines.

• System Security Plan (SP) and Inventory Documentation. The Contractor will rely on The OIP Portal Security Plan (SP) maintained by the ISSO, for day-to-day guidance in making system changes and enhancements. The Contractor will support the ISSO in keeping all system component elements of the SP up-to-date and accurate.

• The Contractor will abide by, and support all, requirements of the system’s Security Certification and Accreditation (C&A) documentation, which includes, but is not limited to, the following:

o OIP Portal IT Security Plan (SP) o Privacy Threshold Assessment o Configuration management Plan o Disaster Recovery Plan

The Contractor shall provide application security support at the web-tier and application-tier levels of the OIP Portal system. The security support tasks include, but are not limited to, the following:

• Hardening of all Government-provided hardware in accordance with DHS and S&T procedures.

• Performance of all software development work in accordance with DHS Procedures, as delineated in the DHS

Systems Engineering Lifecycle (SELC). This includes working with the OIP Portal ISSO to ensure that all software changes are reviewed by IT Security code reviewers and testers.

• Implementation of all security patches (ISVM’s) in accordance with the process established by S&T CIO IT Security:

ISVM acknowledgement by Contractor system administrator, confirmation of ISVM applicability (or not); and, if applicable, confirmation of patch application to ISSO and request to test.

• Quarterly certification provided to system ISSO confirming software inventory in Security Plan is up-to-date.

1.13 TASK 8 - FUNCTIONALITY ENHANCEMENTS AND TECHNICAL MODIFICATIONS

The Contractor shall support requirements for modifications and enhancements to the web portal capabilities and functionality. Some of these requirements will be planned modifications that will be shared with the Contractor during discussions with OIP Portal Program Managers. Other modifications will arise in response to externally generated Program requirements with which S&T must comply (e.g., Small Business Administration directives and policy changes).

OIP Portal Program Managers will prioritize all modifications according to business need and available funding.

Technology Modifications. The Contractor shall support S&T CIO technology requirements for upgrades and modifications to the OIP portal. Some of these technology requirements will be planned upgrades or modifications that will be shared with the Contractor during discussions with the S&T CIO leadership. Other system changes will arise in response to un-planned events (e.g., IT Security directives, hardware or software performance issues requiring out-of-javascript:__doPostBack('ctl00$ctl00$body$homebody$RecentDocuments$C$RecentDocumentsControl$PinnedDocumentResults$ctl00$DocumentNumberLink','') cycle infrastructure modifications, etc.). OIP Portal Program Managers will prioritize all modifications according to business need and available funding.

The Contractor shall prepare a functional description, as appropriate, for all modifications. This document, to be shared no less than 45 days in advance with OIP Program Managers of a proposed Monthly Release, shall also include the proposed level-of effort and expense (e.g., labor hours by labor category) for the Release.

Upon OIP Portal Program Mangers’ approval of the proposed modification, the Contractor shall follow DHS and S&T CIO configuration/change management procedures to design, test and implement the change. This activity will include, but not be limited to, the following:

• Filing with the S&T CIO Change Control Board for review and approval

• Creating a project plan and reviewing it with the DHS S&T CIO IT Project Manager

• Coordinating with OIP Portal ISSO to update all system documentation

• Coordinating with OIP Portal ISSO for all compliance items, e.g., code testing, system scans, etc.

1.14 TASK 9 - PORTAL CONTENT ADDITIONS AND MODIFICATIONS

The Contractor shall provide support for additions and modifications to the web portal content including:

• Content Approval for Any Modification. The Contractor shall receive formal approval for any web portal content changes from the appropriate Government Program Manager impacted by, or initiating, the content change.

• If a given content change necessitates a code change, the Contractor shall coordinate the content changes, with the system ISSO, the IT Security team and the S&T Change Control Board. The Contractor shall follow DHS and S&T processes for change control and change content management documentation and seek to minimize any delay while obtaining review and approval.

• If a given content change affects the end-user interface with the system (e.g., impacts usability), the Contractor shall coordinate the content change with the DHS S&T CIO IT Project Manager in order engage the DHS S&T OCIO 508 Compliance resource.

1.15 TASK 10 – USER TRAINING

The Contractor shall provide up to 12, one (1) hour OIP web portal training to DHS internal users annually, with the schedule determined in coordination with the OIP portal management owners. The trainings shall be conducted in-person and/or via webinar.

The Contractor shall provide online user guides, including visual references such as screenshots or video walkthroughs, for all aspects of the portal and all user modes. These guides shall be maintained to reflect any changes to the portal functionality.

The Contractor shall provide online tutorials and other tools to train users and help address “user error” type issues.

1.16 TASK 11 - SBIR SPECIFIC FUNCTIONS

The Contractor shall support functionality specific to the SBIR Program requirements detailed below. While program functionality is essential, common elements and approaches across programs shall be identified and discussed with system administrators.

• Maintain a repository of all proposals and awards as part of overall data management. Actual proposal, award, modification, technical report and invoice files should be searchable PDF were possible and additional data javascript:__doPostBack('ctl00$ctl00$body$homebody$RecentDocuments$C$RecentDocumentsControl$PinnedDocumentResults$ctl00$DocumentNumberLink','') related to these documents maintained. Data queries shall be exportable to Excel at a minimum. Other formats may be considered in addition to Excel as recommendations.

• Separate tabs should be maintained for Proposal Solicitation and Source Selection, Award Data, Administrative Tools, Standard Reports, and Dynamic Queries.

• Maintain public facing proposal submission capability tied to solicitation with system generated cover sheet and cost proposal. System should also provide “Incomplete” notification and prevent completion of submission if proposal is missing technical proposal, SBA registration, briefing chart and other mandatory documents. This should be tailorable as solicitation requirements change over time. System should also record page count for technical proposals. The system should also provide a clear acknowledgement for the submitter when a submission was successfully uploaded.

• SBIR admin should have the ability to override system generated data fields by exception either by direct access or reach back to system helpdesk with changes implemented within 1 hour.

• Maintain proposal evaluation environment where SBIR admin personnel can assign roles (Contracting Officer, Program Administrator, Topic Manager, Contracting Officer Representative, Reviewer, Guest) based on topic and individual proposals.

• Maintain ability for topic managers and reviewers to read proposals, input comments based on set evaluation criteria and assess an adjectival rating for each criterion. Maintain ability for topic managers to review finalized reviewer assessments and comments and draft a consensus rating.

• Maintain system where SBIR admin can review all comments and ratings as well as status of individual and consensus reviews (not started, in progress, finalized)

• Maintain system where topic manager can prioritize proposals and provide source selection recommendations.

• Maintain award repository with files and data associated with awards, modifications, report submissions, invoicing, period of performance, budget, etc.

• Maintain Administrative Tools capability that allow SBIR admin personnel (some functions limited to

Government only or SBIR Program Director only) to manage functions associated with the SBIR program and portal content to include, but not limited to:

o add, delete, modify or activate/deactivate users o set up solicitations o administer award content o manage content on the public facing DHS SBIR site o manage listserv and mass mailings

• Provide secure capability for SBIR Program Director to transfer DHS SBIR data to SBIR.gov database in support of required reporting. This should include the ability to change the format and data content of transfers when needed (no more than semi-annually) to support Small Business Administration reporting requirements.

1.17 TASK 12 - SVIP SPECIFIC FUNCTIONS

The Contractor shall support functionality specific to the SVIP Program requirements detailed below. While program functionality is essential, common elements and approaches across programs shall be identified and discussed with system administrators.

• Shall provide the Program Administrator the ability to upload program specific information to the program’s main public page, such as “How to Apply”, “Resources" and “News and Information.”

• Shall provide public search ability on research areas, topic areas and keywords.

javascript:__doPostBack('ctl00$ctl00$body$homebody$RecentDocuments$C$RecentDocumentsControl$PinnedDocumentResults$ctl00$DocumentNumberLink','')

• Shall provide links on main public page to all program relevant functions such as Active. Topics, Registration Module, Submission site, User Login, and Awards.

• Offeror has the ability to upload a pdf application (maximum of 10 pages).

• Portal confirmation of application upload (in browser, email, etc.).

• Solicitation can handle five (5) phases of applications (the SVIP program structure is five (5) phases vs. the three

(3) phases of SBIR).

• Offeror has the ability to upload slides for oral pitch (power point or pdf) (*Note: file size could be large so SVIP needs understanding of portal file size constraints).

• Ability to host industry day slides, FAQs, etc. on public facing home page.

• Ability for reviewers to download applications with cover sheets together.

• How to apply details on public facing home page.

• Ability to reject files (applications, slide decks) based on the page length vs. file size; error displays noting the problem.

• Ability to reject an application with missing fields; error displays noting the problem.

• Additional element of the cover sheet to cover cost calculations (labor, misc., travel, etc.).

• Ability to pull consensus comments into notification emails.

• Ability for applicants to track the status of their application (under review, pitch requested, etc.).

• Provide ability to use standard reports for data as well as providing the ability to search all fields and produce ad hoc reports by defining parameters for any of the fields, including key words. Award management (collection of deliverables, etc.).

1.18 TASK 13 - LRBAA SPECIFIC FUNCTIONS

The Contractor shall maintain and support functionality specific to the Long Range BAA (LRBAA) requirements detailed below. While program functionality is essential, common elements and approaches across programs shall be identified and discussed with system administrators.

• All LRBAA topic/solicitation information, including the display and functionality of the public facing environment to allow for offerors to submit to specific topics through a three step process: Industry Engagement, Virtual Pitch (presentation slides and short video) and Written Proposal.

• Program Administrator’s ability to upload program specific information to the program’s main public page, such as “How to Apply”, “Resources” and “News and Information”

• Publicly available search capability on research areas, topic areas and keywords.

• Provide links on main public page to all program relevant functions such as Active Topics, Company Registration

Module, Submission site, User Login, and Awards.

• All internal review/evaluation(s) and recommendation(s) of each submission for each step in the process (Industry

Engagement, Virtual Pitch and Written Proposal). The final recommendations of each step result in a system generated notification memo, which can be tailored prior to being sent by the portal via a DHS email to the offeror.

• Program Administrator’s ability to assign Topic Managers and Technical Subject Matter Experts (SMEs) to offers’ submissions upon receipt and provide notification of the assignment to the users.

• Offerors must receive a recommendation to be able to access and submit data to the next step in the LRBAA process.

• Provide ability for LRBAA Program Administrator’s to set up solicitation parameters and make portal available for proposal submission from public facing environment.

javascript:__doPostBack('ctl00$ctl00$body$homebody$RecentDocuments$C$RecentDocumentsControl$PinnedDocumentResults$ctl00$DocumentNumberLink','')

• Provide ability to enter/upload Award information, such as cost, company, contract number, contract documents, etc.

• Provide ability to use standard reports for data as well as providing the ability to search all fields and produce ad hoc reports by defining parameters for any of the fields, including key words.

• Provide a repository for solicitation information; data and documents supporting submission process, including all abstracts, quad charts, virtual pitches, proposals; and contracts, contract modifications, and supporting documentation.

1.19 TASK 14 - BAA SPECIFIC FUNCTIONS

The Contractor shall support functionality specific to the Broad Agency Announcement (BAA) requirements detailed below. While program functionality is essential, common elements and approaches across programs shall be identified and discussed with system administrators

• All BAA topic/solicitation information, including the display and functionality of public facing environment to allow for offerors to submit to specific topics through a two or three step process: White Paper, Virtual Pitch (optional) and Full Proposal.

• Program Administrator’s ability to upload program specific information to the program’s main public page, such as “How to Apply”, “Resources” and “News and Information”

• Publicly available search capability on research areas, topic areas and keywords.

• Provide links on main public page to all program relevant functions such as Active Calls/Topics, Company

Registration Module, Submission site, User Login, and Awards.

• All internal review/evaluation(s) and recommendation(s) of each submission of each step in the process (White

Paper, Virtual Pitch and Full Proposal), requiring Program Manager(s) reviews/evaluations and a final Contracting Officer (CO) approval.

• Allow Program Administrator’s and Program Manager’s ability to assign Reviewers/Evaluators to offers’ submissions upon receipt and provide notification of the assignment to the users.

• Provide ability for Program Administrator’s to set up solicitation parameters and make portal available for proposal submission from public facing environment.

• Provide ability to use standard reports for data as well as providing the ability to search all fields and produce ad hoc reports by defining parameters for any of the fields, including key words.

• Provide a repository for solicitation information; data and documents supporting submission process, including all white papers, virtual pitches, proposals; and supporting documentation.

1.20 CONTRACTOR PERSONNEL

1.21 QUALIFIED PERSONNEL

The Contractor shall provide qualified personnel to perform all requirements specified in this SOW.

1.22 CONTINUITY OF SUPPORT

The Contractor shall ensure that the contractually required level of support for this requirement is maintained at all times.

The Contractor shall ensure that all contract support personnel are present for all hours of the workday. If for any reason the Contractor staffing levels are not maintained due to vacation, leave, appointments, etc., and replacement personnel will not be provided, the Contractor shall provide e-mail notification to the Contracting Officer’s Representative (COR) prior to employee absence. Otherwise, the Contractor shall provide a fully qualified replacement.

javascript:__doPostBack('ctl00$ctl00$body$homebody$RecentDocuments$C$RecentDocumentsControl$PinnedDocumentResults$ctl00$DocumentNumberLink','')

1.23 KEY PERSONNEL

Before replacing any individual designated as Key, the Contractor shall notify the Contracting Officer no less than 15 business days in advance, submit written justification for replacement, and provide the name and qualifications of any proposed substitute(s). All proposed substitutes shall possess qualifications equal to or superior to those of the Key person being replaced, unless otherwise approved by the Contracting Officer. The Contractor shall not replace Key Contractor personnel without approval from the Contracting Officer. The following Contractor personnel are designated as Key for this requirement. Note: The Government may designate additional Contractor personnel as Key at the time of award.

• Program Manager

• Senior Programmer/Principal Engineer

• Senior System Database Administrator

• System Administrator

• Functional Analyst Senior

• Systems Architect

1.23.1 Contractor Key personnel shall not be assigned by the Contractor to more than one key position for this requirement.

1.24 PROJECT MANAGER

The Contractor shall provide a Project Manager who shall be responsible for all Contractor work performed under this SOW. The Project Manager shall be a single point of contact for the Contracting Officer and the COR. It is anticipated that the Project Manager shall be one of the senior level employees provided by the Contractor for this work effort. The name of the Project Manager, and the name(s) of any alternate(s) who shall act for the Contractor in the absence of the Project Manager, shall be provided to the Government as part of the Contractor's proposal. The Project Manager is further designated as Key by the Government. During any absence of the Project Manager, only one alternate shall have full authority to act for the Contractor on all matters relating to work performed under this contract. The Project Manager and all designated alternates shall be able to read, write, speak and understand English. Additionally, the Contractor shall not replace the Project Manager without prior approval from the Contracting Officer.

1.24.1 During any absence of the Program Manager (PM), only one alternate shall have full authority to act for the

Contractor on all matters relating to work performed under this contract. The PM, or the single designated alternate in the PM’s absence, shall be available to the COR via telephone between the hours of 09:00 and 17:00 ET (Monday – Friday) and shall respond to a request for discussion, or resolution of a technical issue, within two hours of notification. Notification to the COR who the alternate PM is shall be made no later than 9am of the workday the PM is absent.

1.25 EMPLOYEE IDENTIFICATION

1.25.1 Contractor employees visiting Government facilities shall wear an identification badge that, at a minimum, displays the Contractor name, the employee’s photo, name, clearance-level and badge expiration date. Visiting Contractor employees shall comply with all Government escort rules and requirements. All Contractor employees shall identify themselves as Contractors when their status is not readily apparent and display all identification and visitor badges in plain view above the waist at all times.

1.25.2 Contractor employees working on-site at Government facilities shall wear a Government issued identification badge. All Contractor employees shall identify themselves as Contractors when their status is not readily apparent (in meetings, when answering Government telephones, in e-mail messages, etc.) and display the Government issued badge in plain view above the waist at all times.

javascript:__doPostBack('ctl00$ctl00$body$homebody$RecentDocuments$C$RecentDocumentsControl$PinnedDocumentResults$ctl00$DocumentNumberLink','')

1.26 EMPLOYEE CONDUCT

Contractor’s employees shall comply with all applicable Government regulations, policies and procedures (e.g., fire, safety, sanitation, environmental protection, security, “off limits” areas, wearing of parts of DHS uniforms, and possession of weapons) when visiting or working at Government facilities. The Contractor shall ensure Contractor employees present a professional appearance at all times and that their conduct shall not reflect discredit on the United States or the Department of Homeland Security. The Project Manager shall ensure Contractor employees understand and abide by Department of Homeland Security established rules, regulations and policies concerning safety and security.

1.27 REMOVING EMPLOYEES FOR MISCONDUCT OR SECURITY REASONS

The Government may, at its sole discretion (via the Contracting Officer), direct the Contractor to remove any Contractor employee from DHS facilities for misconduct or security reasons. Removal does not relieve the Contractor of the responsibility to continue providing the services required under the contract. The Contracting Officer will provide the Contractor with a written explanation to support any request to remove an employee.

1.28 PERSONAL IDENTITY VERIFICATION (PIV) CREDENTIALS

PIV-enabled information systems must demonstrate that they can correctly work with PIV credentials by responding to the cryptographic challenge in the authentication protocol before granting access. If a system is identified to be non-compliant with HSPD-12 for PIV credential enablement, a remediation plan for achieving HSPD-12 compliance shall be required for review, evaluation, and approval by the CISO.

The Homeland Security Presidential Directive 12 (HSPD-12) requires the use of the Personal Identity Verification (PIV) credentials as the common means of authentication for access to DHS facilities, networks, and information systems.

Personal Identity Verification (PIV) credentials shall be used as the primary means of logical authentication for DHS sensitive systems. The Contractor must use his or her federal issued Personal Identity Verification (PIV) credentials to access DHS resources to include IT applications and physical facility.The DHS Office of the Chief Security Officer shall be notified of all terminations/resignations within five (5) days of occurrence. The Contractor shall return to the Contracting Officer Representative (COR) all DHS issued Personal Identity Verification (PIV) credentials/identification cards and building passes that have either expired or have been collected from terminated employees. If a PIV credential/identification card or building pass is not available to be returned, a report shall be submitted to the COR, referencing the PIV credential, pass or card number, name of individual to who it was issued and the last known location and disposition of the PIV credential, pass or card. The Contractor or Contractor personnel's failure to return all DHS- or Federal Emergency Management Agency (FEMA)-issued identification cards and building passes upon expiration, upon the Contractor personnel's removal from the contract, or upon demand by DHS or FEMA may subject the Contractor personnel and the Contractor to civil and criminal liability.

2.0 OTHER APPLICABLE CONDITIONS

2.1 SECURITY

2.1.1 OIP Portal functions include solicitations and proposal submission and handling. As a result there is potential for

Contractor access to unclassified, but Security Sensitive Information, in terms of source selection sensitive data, intellectual property and personally identifiable information (PII) under this SOW. Contractor employees shall safeguard this information against unauthorized disclosure or dissemination. As such, the Contractor shall comply with all applicable requirements within the DHS contract clauses listed below:

javascript:__doPostBack('ctl00$ctl00$body$homebody$RecentDocuments$C$RecentDocumentsControl$PinnedDocumentResults$ctl00$DocumentNumberLink','')

2.2 PERIOD OF PERFORMANCE

The period of performance for this contract is a 13-month base period with four (4) 12-month option periods as follows:

Base Period: 13 months from effective date of award Option Period 1: 12 months from the exercise of Option Period 1 Option Period 2 : 12 months from the exercise of Option Period 2 Option Period 3: 12 months from the exercise of Option Period 3 Option Period 4 : 12 months from the exercise of Option Period 4

2.3 PLACE OF PERFORMANCE

Contractor personnel shall generally perform all work at the Contractor’s facility or relevant remote work location(s) within the United States.

However, work at the Government site includes participation in meetings, requirements gathering, training, and performing system backup.

2.4 HOURS OF OPERATION

Contractor personnel shall generally perform all work between the hours of 09:00 and 17:00 EST (Monday through Friday), except for Federal holidays. However, there will be frequent occasions when Contractor employees shall be required to work other than normal business hours, including weekends and holidays, to fulfill requirements under this Statement of Work (SOW).

2.5 TRAVEL

Contractor travel shall not be required for this requirement.

2.6 POST AWARD CONFERENCE

The Contractor shall attend a Post Award Conference with the Contracting Officer and the COR no later than five (5) business days after the date of award. The purpose of the Post Award Conference, which will be chaired by the Contracting Officer, is to discuss technical and contracting objectives of this contract and review the Contractor's draft project plan. The Post Award Conference will be held at the Government’s facility, located in the Washington, DC metropolitan area, or via teleconference.

2.7 PROJECT PLAN

The Contractor shall provide a draft Project Plan at the Post Award Conference for Government review and comment. The Contractor shall provide a final Project Plan to the COR not later than 20 business days after the Post Award Conference.

2.8 BUSINESS CONTINUITY PLAN

The Contractor shall prepare and submit a Business Continuity Plan (BCP) to the Government. The BCP Plan shall be due 30 business days after the date of award and will be updated on an annual basis. The BCP shall document Contractor plans and procedures to maintain support during an emergency, including natural disasters and acts of terrorism. The BCP, at a minimum, shall include the following:

• A description of the Contractor’s emergency management procedures and policy.

• A description of how the Contractor will account for their employees during an emergency.

• How the Contractor will communicate with the Government during emergencies.

• A list of primary and alternate Contractor points of contact, each with primary and alternate:

javascript:__doPostBack('ctl00$ctl00$body$homebody$RecentDocuments$C$RecentDocumentsControl$PinnedDocumentResults$ctl00$DocumentNumberLink','')

• Telephone numbers

• E-mail addresses

2.8.1 Individual BCPs shall be activated immediately after determining that an emergency has occurred, shall be operational within 24 hours of activation or as directed by the Government, and shall be sustainable until the emergency situation is resolved and normal conditions are restored or the contract is terminated, whichever comes first. In case of a life threatening emergency, the COR shall immediately make contact with the Contractor Project Manager to ascertain the status of any Contractor personnel who were located in Government controlled space affected by the emergency. When any disruption of normal, daily operations occurs, the Contractor Project Manager and the COR shall promptly open an effective means of communication and verify:

• Key points of contact (Government and contractor)

• Temporary work locations (alternate office spaces, telework, virtual offices, etc.)

• Means of communication available under the circumstances (e.g., email, webmail, telephone, FAX, courier, etc.)

• Essential Contractor work products expected to be continued, by priority

2.8.2 The Government and Contractor Project Manager shall make use of the resources and tools available to continue contracted functions to the maximum extent possible under emergency circumstances. Contractors shall obtain approval from the Contracting Officer prior to incurring costs over and above those allowed for under the terms of this contract. Regardless of contract type, and of work location, Contractors performing work in support of authorized tasks within the scope of their contract shall charge those hours accurately in accordance with the terms of this contract.

2.9 TRANSITION OUT PLAN

The Contractor shall provide a Transition-out Plan (the Plan) to the Contracting Officer and COR via electronic mail. The Plan shall address the Contractor’s plan to transition to another Contractor at the end of a period of performance. The goal of the Plan shall be to minimize the impact of transition such that continuity of services will be maintained during the transition period and key system documentation, as identified by the COR, will be available to the Contractor’s successor.

The Plan shall describe the specific actions, tasks, timelines and deliverables the Contractor shall be responsible for in…