TDP_Sole Source 2.0 software development PWS_updated.pdf

Administration for Children and Families

Office of Family Assistance

Temporary Assistance for Needy Families (TANF) Data Portal (TDP) 1.0 Sole Source 2.0

Software Development Services

1.0 Purpose and Background

1.1 Purpose

In fiscal year 2020, the Office of Family Assistance (OFA) within the Administration for

Children and Families (ACF) awarded a contract for software development services in support of the Temporary Assistance for Needy Families (TANF) program. The TANF Data

Portal (TDP) was incrementally rolled out, with initial release to production in July 2022, onboarding of pilot users beginning in August 2022, and launch with all users in 2023. This is a second sole-source extension of the current contractor with a reduced team to assist in the smooth transition and hand off to the contractors of TANF Data Portal 2.0 at a crucial time in development. OFA will oversee contractor performance and review deliverables. This requirement anticipates using GSA IT Professional Services Schedule – SIN 54151S.

1.2 Background

The Personal Responsibility and Work Opportunity Reconciliation Act of 1996 (PRWORA) created the Temporary Assistance for Needy Families (TANF) program. OFA administers the

TANF program on behalf of the Department of Health and Human Services (HHS). Since

1996, the TANF program has served as one of the nation’s primary economic security and stability programs for low-income families with children. TANF is a block grant that provides $16.6 billion annually to states, territories, the District of Columbia, and federally-recognized Indian tribes. These TANF jurisdictions use federal TANF funds to provide income support as well as a wide range of services to vulnerable families with minor children.

As part of oversight and administration of the TANF Program, OFA operates the TANF Data

Portal (TDP).

OFA's TANF grantees submit data to TDP that they are legislatively-mandated to report (42

U.S.C. § 611(a)). OFA then aggregates the data and uses it for descriptive analyses and program accountability, most notably through the work participation rate calculations. Work participation rates measure the degree to which families receiving TANF assistance are engaged in work activities specified under federal law (42 U.S.C. § 607(d)). States, territories, https://www.acf.hhs.gov/ofa and tribes must meet both an overall work participation rate and a two-parent work participation rate or be subject to a financial penalty. The Fiscal Responsibility Act of 2023 introduced new TANF work outcomes measures that will require new data collection starting in fiscal year 2025, which is also part of this requirement.

After moving to a production environment in July 2022 and rolling out to all users in late

2023, TDP will officially replace the legacy TANF Data Reporting System in the Spring of

2024.

1.3 Problem

TDP is a new application that was developed to replace a very broken system with a painful user experience. TDP currently has the minimum features that were required to be able to retire the old system, but there are many additional features that would improve the user experience and pave the way for better TANF data and programs.

States, tribes, and territories distribute cash assistance in various ways and collect information about recipients in a variety of different systems. Some of this data is passed to OFA through

TDP and is critical to OFA’s responsibility to report on the TANF program. The data provides information about how grantees are meeting their work participation rate targets and complying with the TANF program’s federal 60-month time limit, as well as demographic information about families receiving TANF cash assistance.

High quality data leads to informed decision-making, and the TANF program relies on this information to make policy recommendations. Additionally, states and territories may face penalties of up to four percent of their total grant award each quarter if TANF data is not timely, complete, and accurate.

Data quality issues and interactions with legacy data systems have hindered the federal team from being able to accurately gauge TANF’s impact.

The initial contract for the TANF Data Portal (TDP 1.0) is coming to an end at a crucial time in development. The current vendor is finishing up work on features that represent parity with the legacy TDRS, and are required before the final switchover to TDP. The ATO for TDRS expires

May 22, 2024 and so the switch must happen before then. A scaled down version of the current vendor team is needed to complete this work and aid in the transition to the vendor team for TDP

2.0.

1.4 Current TANF Data Portal

OFA partnered with 18F to conduct the initial research, scoping, prototyping, and strategy for

TDP. The vendor team built the TANF Data Portal in close collaboration with OFA (and initially

18F).

https://github.com/HHS/TANF-app/blob/main/docs/Technical-Documentation/diagrams/tdp-environments.png see also the Boundary Diagram

The infrastructure is intended to provide OFA and the contractor with a system that is easy to learn, manage, and use. The components are:

● The TDP system’s user interface (front end) was developed using the ReactJS framework, and the backend uses the Django framework, and a 508-compliant version of

Django Admin serves as the system-admin user interface.

● Cloud.gov This is a GovCloud-based platform-as-a-service that removes almost all of the infrastructure monitoring and maintenance from the system, is already procured for OFA, and has a FedRAMP Joint Authorization Board Provisional Authority to Operate (JAB P-

ATO) on file. FedRAMP is a standardized federal security assessment for cloud services, and the FedRAMP ATO helps agencies by providing confidence in the security of cloud solutions and security assessments.

● Terraform is in-use for automated provisioning of Cloud.gov-brokered infrastructure.

● Strong multi-factor authentication is required for all users to access the TDP system:

Login.gov authentication service is currently integrated with TDP via OpenID

Connect (OIDC) for states, tribes, and territories to access the system for data submission. Login.gov has a FedRAMP ATO on file.

ACF AMS authentication service is also currently integrated with TDP via OIDC for OFA staff to use Homeland Security Presidential Directive 12 Personal

Identity Verification (HSPD 12 PIV) for identity verification.

● CircleCI is a CI/CD system with a FedRAMP ATO on file. It is used to automate builds, testing, and deployments from GitHub.

● OWASP Zap scanner is in-use for continuous system security monitoring; and clamAV scanner is in-use to ensure all files uploaded into the system are safe from viruses.

https://github.com/HHS/TANF-app/blob/main/docs/Technical-Documentation/diagrams/tdp-environments.png https://github.com/HHS/TANF-app/blob/main/docs/Technical-Documentation/diagrams/tdp-environments.png https://github.com/HHS/TANF-app/blob/main/docs/Security-Compliance/boundary-diagram.md https://github.com/HHS/TANF-app#infrastructure https://github.com/HHS/TANF-app/tree/main/tdrs-frontend https://github.com/HHS/TANF-app/tree/main/tdrs-backend https://cloud.gov/ https://marketplace.fedramp.gov/#/product/18f-cloudgov?sort=productName https://marketplace.fedramp.gov/#/product/18f-cloudgov?sort=productName https://marketplace.fedramp.gov/#/product/18f-cloudgov?sort=productName https://marketplace.fedramp.gov/#/product/18f-cloudgov?sort=productName https://marketplace.fedramp.gov/#/product/18f-cloudgov?sort=productName https://marketplace.fedramp.gov/#/product/18f-cloudgov?sort=productName https://github.com/HHS/TANF-app/blob/main/docs/Technical-Documentation/Architecture-Decision-Record/015-terraform-service-provisioning.md https://marketplace.fedramp.gov/#/product/logingov https://marketplace.fedramp.gov/#/product/logingov https://marketplace.fedramp.gov/#/product/logingov https://circleci.com/ https://marketplace.fedramp.gov/#/product/circleci-cloud https://github.com/HHS/TANF-app/blob/main/docs/Technical-Documentation/Architecture-Decision-Record/016-zap-waiver.md https://github.com/HHS/TANF-app/blob/main/docs/Technical-Documentation/Architecture-Decision-Record/012-antivirus-strategy.md https://github.com/HHS/TANF-app/blob/main/docs/Technical-Documentation/Architecture-Decision-Record/012-antivirus-strategy.md

● Docker is in-use for local development.

TDP received its Authority to Operate (ATO) from the ACF Chief Information Officer on

May 18, 2021. The ATO was extended on March 29, 2023, through May 22, 2024.

1.5 Product Vision

OFA is continuing to build out the TANF Data Portal, a new, secure, web-based data reporting system to improve the federal reporting experience for TANF grantees and federal staff. The new system allows grantees to directly and easily upload and submit their data and be confident that the submission complies with the reporting requirements. Additional features and enhancements will reduce the burden on all users, free up staff time, improve data quality, and ultimately help low-income families.

2.0 Scope, Expectations, Anticipated Period of Performance

2.1 Scope

OFA seeks agile software development services to complete crucial features of the TANF Data

Portal before ATO expiration and to ensure a smooth transition to the contract for TDP 2.0. The services to be provided under this task order shall include software development and coding, accessibility testing, documentation, testing, and configuration. The in-progress features to be closed out include testing and finalizing the in-app error reports, database access configuration, and bug fixes. Additionally, the contractor will review and update documentation to support the hand off to the vendor for TDP 2.0 in addition to other Phase in/Phase out services.

2.2 Expectations

This software development project shall use agile development principles, with robust documentation, human-centered design, and an extensible infrastructure. OFA expects that the development process shall be collaborative and iterative, with open, regular, and frequent communication between OFA, its partners, and the contractor.

OFA expects that the development process shall consist of sprint cycles, and that the next phases of the development process shall focus on improving the system security monitoring and administration experience, reporting and analytics, new user interfaces for OFA regional staff, APIs for automated file submission and system administration, and the submission of new work outcomes measures.

OFA’s Product Owner shall liaise with other stakeholders, weigh business needs, set direction, make prioritization choices, build a product roadmap, and support the development team.

The contractor's development and design teams will work closely with OFA’s technical lead, who, along with OFA’s TDP product owner, will direct architecture decision-making, feature prioritization, bug fixes, documentation, and implementing new security procedures. All code will be reviewed by OFA’s technical lead at the end of every development sprint to ensure submitted code is high quality, secure, maintainable, and meets other contract requirements. The contractor shall assist OFA with product management by maintaining the roadmap and backlog and facilitating sprint ceremonies.

The contractor team will arrange for external and internal usability testing. An additional OFA system administrator and TANF subject matter experts will be available promptly to assist in the development process, including internal usability testing.

ACF will be responsible for authorizing the deployed system and obtaining any necessary

Authority to Operate (ATO). The contractor shall assist with documentation to satisfy the ATO on an ongoing basis. ACF Tech will also determine which security controls are required and whether they have been satisfied according to the National Institute of Standards and Technology

(NIST) requirements (NIST SP 800-53 Rev. 5 as of October 2023) in delivering code.

Contractors will be expected to document the system’s non-inherited controls in the or OSCAL format. OpenControl or OSCAL format.

The contractor must post all developed code to a public source repository (such as GitHub) designated by OFA.

2.3 Anticipated Period of Performance

The period of performance will be 60 days. The contract type for this effort will be firm-fixed price.

3.0 Objectives

3.1 Backlog and Roadmap

The user stories below are the key in-progress features to be completed under this extension of the contract. These features do not comprise the full scope or detail of the 60-day period, and some features may be completed before this period begins.

OFA expects that the contractor shall work closely with the Product Owner and OFA Technical

Lead to prioritize the backlog of user stories for the 60-day period. The roadmap shall be a continuation of the current contract. Individual user stories will be refined, added to, retracted, sub-divided, and reprioritized by the product team throughout the 60-day period in backlog refinement and sprint planning sessions. In addition to a dynamic sprint board, work will be tracked in sprint review reports (biweekly), contract status reports (monthly), and architecture decision records (as needed).

https://github.com/HHS/TANF-app/tree/main/docs/Security-Compliance/Security-Controls https://www.nist.gov/ https://www.nist.gov/ https://pages.nist.gov/OSCAL/ https://pages.nist.gov/OSCAL/

3.1.1 User types

● STT data analysts: Staff within the US states, territories, and tribes (STT) that receive block grant TANF funding from the federal government. These individuals are responsible for reporting data about TANF recipients to OFA through TDP.

● STT program director: Monitors their STT’s reports and analytics.

● OFA analyst: OFA staff who review, analyze, and report on grantee data submitted through TDP.

● OFA system admin: Oversees the collection and processing of TANF data and ensures

OFA analysts have what they need to do their work. They also approve new accounts and assign roles.

● OFA regional staff: OFA regional program managers and specialists are grantee's primary OFA points of contact. They validate STT user accounts, track TANF trends in their region, and monitor reporting.

3.1.2 User stories for the closeout period of TDP 1.0 development

● As an OFA data analyst, I need secure access to parsed data for all sections for all STTs.

● As an STT data analyst, I need all user interfaces to be accessible.

● As an OFA system admin, I want CircleCI pipelines to catch migration and/or deployment failures.

● As an OFA system admin, I need all data files submitted through TDP to be parsed and validated.

● As an STT data analyst, I need user-friendly system-generated error reports.

● As an STT data analyst, I need the TDP knowledge center to have up-to-date information on how to use TDP and its latest features.

● As an OFA system admin, I need TDP system to be following security requirements for

FISMA moderate systems.

● As a TDP 2.0 contractor, I need complete and up-to-date documentation on how to stand up TDP locally and in development, staging, and production environments.

3.2 Quality Assurance Surveillance Plan (QASP)

The government will use the Quality Assurance Surveillance Plan (QASP) to monitor the quality of the contractor’s deliverables and performance. This oversight will help the government ensure that contractor performance reaches required levels throughout the contract term. The QASP provides the government with a proactive way to avoid unacceptable or deficient performance and provides the basis for performance ratings in the Contractor Performance Assessment

Reporting System (CPARS). The QASP may be updated by modification to the contract. The

QASP provides the basis for performing and controlling the project’s activities in accordance with the contract.

The following chart sets forth the performance standards and quality levels the code and documentation provided by the contractor must meet, and the methods OFA will use to assess the standard and quality levels of that code and documentation.

Deliverable 1 Accepted Features

Performance

Standard(s)

The development team will deliver code and functionality to satisfy pre-defined acceptance criteria (AC).

Acceptable Quality

Level

Features developed meet AC stated in the issue

Method of

Assessment

Prior to submitting issues for QASP review, the contractor should check the ACs to confirm the features meet the acceptance criteria stated in the issue. This review should also include documenting the steps to manually test that the features developed meet the ACs.

Due Date Every sprint

Deliverable 2 Tested Code

Performance

Standard(s)

Code delivered under the order must have substantial test code coverage.

Version-controlled HHS GitHub repository of code that comprises products that will remain in the government domain.

Acceptable Quality

Level

Minimum of 90% test coverage of all code. All areas of code are meaningfully tested.

Method of Combination of manual review and automated testing

Deliverable 3 Properly Styled Code

Standard(s)

GSA 18F Front- End Guide

Acceptable Quality

Level

0 linting errors and 0 warnings

Method of

Assessment

Combination of manual review and automated testing

Deliverable 4 Accessible

Standard(s)

Web Content Accessibility Guidelines 2.1 AA standards

Acceptable Quality

Level

0 errors reported using an automated scanner and 0 errors reported in manual testing

Method of

Assessment

Combined approach using automated and manual testing with tools equivalent to Accessibility Insights and/or the DHS Trusted Tester process.

Deliverable 5 Deployed

Standard(s)

Code must successfully build and deploy into the staging environment.

https://frontend.18f.gov/#js-style https://accessibilityinsights.io/ https://www.dhs.gov/508-testing https://www.dhs.gov/508-testing

Acceptable Quality

Level

Successful build with a single command

Method of

Assessment

Combination of manual review and automated testing

Deliverable 6 Documented

Standard(s)

All dependencies are listed and the licenses are documented. Major functionality in the software/source code is documented. Individual methods are documented inline in a format that permits the use of tools such as JSDoc. System diagram is provided.

Acceptable Quality

Level

Code must be understandable and contextualized for the reviewers possess the knowledge and background necessary for analysis and constructive criticism to take place.

Method of

Manual review

Deliverable 7 Secure

Standard(s)

Open Web Application Security Project (OWASP) Application Security

Verification Standard 3.0

Acceptable Quality

Level

Code submitted must be free of medium- and high-level static and dynamic security vulnerabilities

Method of

Assessment

Clean tests from a static testing SaaS (such as Snyk or npm audit) and from OWASP ZAP, along with documentation explaining any false positives

Deliverable 8 User research

Standard(s)

Usability testing and other user research methods must be conducted at regular intervals throughout the development process (not just at the beginning or end).

Acceptable Quality

Level

Research plans and artifacts from usability testing and/or other research methods with end users are available at the end of every applicable sprint, in accordance with the contractor’s research plan.

Method of

Assessment

OFA will manually evaluate the artifacts based on a research plan provided by the contractor at the end of the second sprint and every applicable sprint thereafter.

Due Date As needed

3.3 Application Support

The Contractor shall perform application level, ongoing maintenance, and support for the application to include:

• Taking corrective action for where the solution fails to perform as detailed in the Service

Level Agreement (SLA).

• Implementing requested solution modifications in accordance with Agency policies.

• All modifications must adhere to ACF’s change management processes.

• Revise or produce appropriate documentation.

• Provide ongoing Application Support for customer support as requested and required.

• Support ACF’s reporting and data sharing requirements.

• Adapt the application set to adjust to changes that affect overall operations, including but not limited to changes in (1) rules, laws, and regulations; (2) data formats and file structures; and (3) Application technology stack.

• Where necessary working with other third-party vendors on application support

• End-User Support for Application accessibility and usability issues

• Institute emergency maintenance in cases where software changes are mandatory to keep the solution set operational.

3.4 Transition Plan

The contractor shall ensure and agree that all deliverables, products, licenses, designs, data, documentation, tests, user research notes, source code, configuration settings and files, and materials developed throughout the contract will be the property of the U.S. Government and in the public domain. One week prior to the task order conclusion, all deliverables, products, will be incorporated into the project repository. Exclusion of project artifacts may be allowed in coordination with the Product Owner and COR. The contractor shall provide any other reasonable assistance to the Government to deploy the latest version of the application.

3.4.1. Transition Activities

During the transition to a new contractor, the Contractor shall perform all necessary transition activities. Expected transition activities may include, but not be limited to:

• Continuation of full services to HHS and other customers

• Participation in meetings with the Government or a new contractor to effect a smooth transition and provide detailed information on the operation of all deliverables, at COR and the Product Owner’s discretion

• Training of new personnel, either Government or a new contractor, during transition period.

• Appropriate close-out of any outstanding technical and related performance elements for this task

4.0 Contract Place of Performance

The place of performance shall be at the Contractor Site. Any work done, whether onsite or offsite, must be covered by the rate agreed upon between the government and Contractor.

Normal working hours are from 9:00AM to 5:00PM Eastern time Monday through Friday. The

Contractor will generally be expected to be readily available during core working hours from

10:00am to 4:00pm Eastern time Monday through Friday. They are not expected to work federal holidays. If the federal government shuts down for any reason, Contractors may seek approval from the COR to telework during this time.

The contractor may choose the location(s) from which to perform the required software development services. The contractor will not be required to work at a government facility however, occasional travel to government facilities may be required. Actual travel costs to government facilities will be reimbursed in accordance with federal travel regulation. All travel must be approved by the contracting officer’s representative (COR) prior to booking.

4.1 Federal Holidays

https://www.gsa.gov/policy-regulations/regulations/federal-travel-regulation-ftr

There are 11 federal holidays set by law (USC Title 5 Section 6103) that ACF/OFA follows. Under current definitions, the following holidays are set by date:

1. New Year's Day: January 1

2. Independence Day: July 4

3. Veterans Day: November 11

4. Christmas Day: December 25

5. Juneteenth: June 19

If any of the above falls on a Saturday, then Friday shall be observed as a holiday. Similarly, if one falls on a Sunday, then Monday shall be observed as a holiday. The other six holidays are set by a day of the week and month:

1. Martin Luther King's Birthday: Third Monday in January

2. Washington's Birthday: Third Monday in February

3. Memorial Day: Last Monday in May

4. Labor Day: First Monday in September

5. Columbus Day: Second Monday in October

6. Thanksgiving: Fourth Thursday in November

In addition to the days designated as holidays, the Government observes the following days:

• Any other day designated by Federal Statute

• Any other day designated by Executive Order

• Presidential Inauguration Day

• Any other day designated by the President’s Proclamation

It is understood and agreed between the Government and the Contractor that observance of such days by Government personnel shall not otherwise be a reason for an additional period of performance, or entitlement of compensation except as set forth within the contract. In the event the Contractor’s personnel work during the holiday, they may be reimbursed by the Contractor, however, no form of holiday or other premium compensation will be reimbursed either as a direct or indirect cost, other than their normal compensation for the time worked.

5.0 Operating Constraints (Non-functional Requirements)

The Contractor shall submit to the COR a written monthly progress report by the 20th calendar day of every month that summarize the status of project activities and accomplishments, any potential issues and risks that may cause a delay in performance and the proposed corrective action to be taken. These monthly reports must detail past-month and cumulative spending by task and spending projections by task for the remainder of the project. The format of this report, frequency, and content of the progress reports may be modified at the COR discretion.

5.1 System Requirements

The System shall:

● Incorporate an intuitive, web-based interface that is accessible from both internal and external platforms, including desktops, laptops, tablets, thin/zero clients, and mobile devices

● Incorporate application programming interfaces (APIs) to intermediate major components

● Be highly available to users and have adequate capacity to handle the load

● Include Login.gov user authentication and authorization functionality and use open-source encryption protocols for all data transmission.

● Be developed in Cloud.gov and shall be built so that it has the capability for eventually migrating to another ACF cloud environment (e.g. AWS GovCloud). The type of environment is unknown at this time, so the application should be written to be as operationally portable as possible.

5.2 Authentication Requirements

The software shall have multi-factor authentication for the grantees and PIV authorization for the

OFA staff and contractor key personnel as needed. The Login.gov and ACF AMS systems have already been implemented to fulfill these requirements.

5.3 Software Requirements

The software architecture shall be extensible to allow for future development including the addition of new statutorily mandated data reporting. The code base shall incorporate analytics, monitoring, testing, and measurement tools. Application design and development shall use plain language to the extent practical.

5.4 Design Requirements

Any website that is developed or otherwise delivered as a result of this contract shall be in compliance with the website standards of the Technology Transformation Services of the

General Services Administration.

The contractor will employ the U.S. Web Design System (USWDS) and create design elements that are reusable by OFA.

5.5 Environments

The System was developed and is currently hosted on Cloud.gov (a FedRAMP-certified internet-connected Platform as a Service). OFA will continue to own and manage the Cloud.gov account.

The contractor shall be granted access to the development and staging environments and shall be responsible for maintaining those environments. The contractor shall be required to post all developed code to the public source repository as designated by OFA. OFA will be responsible for managing this repository. OFA will be responsible for maintaining a Continuous https://content-guide.18f.gov/plain-language/ https://content-guide.18f.gov/plain-language/ https://designsystem.digital.gov/website-standards/

Integration/Continuous Deployment system to automate the deployment of the code in GitHub, and the contractor will be able to contribute configuration-related code that will improve it as needed-related code that will improve it as needed.

5.6 System Access

All contractor personnel working under the resulting contract will need to obtain a Homeland

Security Presidential Directive 12 (HSPD-12) Tier 1 clearance (or Tier 4 if handling PII).

In addition, the technical lead will need to obtain a personal identity verification (PIV) card in order to provide system operations and maintenance support for contingency planning and incident response purposes.

Contractor personnel that are required to obtain a PIV card will be issued a government-furnished laptop from HHS/ACF. Any work that requires access to and handling of PII must be performed on the HHS/ACF government-furnished laptop. Contractor personnel that are not required to obtain a PIV card can use contractor-furnished equipment to perform work. The government anticipates that contractor personnel will need to access PII data only on a very limited basis.

Contractors may have to establish multi-factor authentication (MFA) to access systems that require government laptops with PIV cards or to access other applications that require MFA.

6.0 Personnel Skills and Knowledge

6.1 Key Personnel

The contractor must designate who will fill these three separate roles: Product Manager, Technical Lead, and Design Lead.

The Product Manager will be a direct liaison to the government product team and shall be responsible for the management of the project milestones and deliverables in support of the product owner. This person shall have a background as a scrum master, product manager, agile coach, or a similar role.

The Technical Lead shall have a full understanding of the technical approach to be used by the contractor’s development team and will be responsible for ensuring that the contractor’s development team follows that approach, in close collaboration with the OFA Technical Lead.

This person shall have a background as full-stack software engineer.

https://www.dhs.gov/homeland-security-presidential-directive-12

The Design Lead shall have a full understanding of the research approach and design patterns to be used by the contractor’s development team and will be responsible for ensuring that the contractor’s development team follows that approach. This person shall have a background as a user experience researcher or designer.

6.2 Key Personnel Substitution

Key Personnel substitutions shall be in accordance with HHSAR 352.237-75 Key Personnel

(DEC 2015). 352.237-75 Key Personnel. | Acquisition.GOV (link for GCS reference)

6.3 Skills

The contractor shall provide a cross functional team that is experienced in working in an agile process. They must be qualified and capable of delivering value iteratively and be able to pivot quickly based on a continuous learning environment.

The required skills for this project include:

● Product management

● Back-end engineering

● Front-end engineering

● User research

● Accessibility/508 compliance

● User support

This sole source extension does not require content design, visual design, or user training and onboarding, nor does it require development, security, and operations (DevSecOps) engineering.

7.0 Administration

7.1 Government Personnel

This acquisition will be administered by the following individuals who will also monitor contractor performance:

● Contracting Officer (CO): Vinton Grant

● contract Specialist CS): Amadou Tounkara

● OFA Contracting Officer’s Representative (COR): Lisa Washington-Thomas

The government will notify the contractor if a change occurs to either the CO or COR.

Specifically for the COR, the contractor will receive a copy of the “COR Delegation of

Authority” assignment letter when a COR is assigned, and the contractor will also receive a letter rescinding the COR’s delegation when appropriate.

https://www.acquisition.gov/hhsar/352.237-75-key-personnel.

7.2 Authorities and Delegations

7.2.1 The ACF Office of Government Contracting Services is the only organization authorized to enter into or terminate this task order, modify any term or condition of this agreement, waive any requirement of this agreement, or accept nonconforming work.

7.3 Contractor Administration

The contractor must provide the name of the individual responsible for centralized contract administration in support of all work performed under this order. This individual, at a minimum, will serve as the point of contact for contractual issues, invoices, and the contractor representative for annual performance reviews (see section 7.5).

7.3.1 Travel

Costs for lodging, meals, and incidental expenses incurred by Contractor personnel shall be considered to be reasonable and allowable to the extent they do not exceed on a daily basis the per diem rates set forth in the Federal Travel Regulations, General Services Administration

(GSA). Therefore, if travel costs are applicable and proposed by offerors, please be advised that they shall be calculated using the per diem rate schedule as established by GSA. Reimbursement of travel costs under any contract awarded from this RFP shall be in accordance with FAR

31.205-46. Travel must be submitted to the COR for authorization prior to traveling.