Skip to content
This repository has been archived by the owner on Dec 8, 2017. It is now read-only.

Latest commit

 

History

History
375 lines (214 loc) · 33.4 KB

File metadata and controls

375 lines (214 loc) · 33.4 KB

PERFORMANCE WORK STATEMENT

Disaster Data Recovery Portal Pilot

1. OBJECTIVES

The US Department of Housing and Urban Development (HUD) seeks the creation of a technological solution to facilitate rapid and secure transmission of data from Federal Emergency Management Agency (FEMA) to HUD Community Development Block Grant Program - Disaster Relief (CDBG-DR) grantees. The new system will improve the existing data sharing procedures and meet evolving requirements while leveraging best practices in software development. HUD will be able to better carry out its mission by: avoiding duplicative disaster aid grants, providing grantees with better quality data related to the impact of a disaster, and improving relief efforts as a whole.

To help mitigate risk associated with our timeline, the system will be built following agile development principles. Additionally, it will leverage open-source code, robust documentation, human-centered design, and an extensible infrastructure.

The initial phase of work will center on developing a registration system that will allow an appropriately authenticated user to access data through the use of FEMA’s existing Application Programming Interface (API). The second phase of work will center on developing a user interface that will allow that user to sort the data and subsets of the data in a variety of ways, including tables. The final phase of work will center on developing a mapping function that will visualize the data and subsets of the data while overlaid on Geographic Information System (GIS) maps. All these items will be developed while keeping in mind general Privacy Act-related requirements as well as the heightened security requirements imposed upon this project by FEMA.

2. BACKGROUND

The Disaster Data Recovery Portal Pilot is anticipated to replace the currently used system that involves a variety of data sharing methods ranging from the default method of sending physical media (e.g., CD-ROM, flash drive, portable hard drive, etc.) to a state-specific secure File Transfer Protocol (FTP) system. The Disaster Data Recovery Portal Pilot’s primary goal is to put an end to “double-dipping” by aid recipients while the secondary goal is to provide a secure and real-time (or as real-time as is feasibly possible) system to support state and local governments in their relief efforts. The Tool supports the mission of HUD CDBG-DR grantees by allowing them to efficiently and effectively route aid to the locations and individuals with the most need for that aid. HUD CDBG-DR grantees face many challenges in the wake of a disaster, including limited information about the type and extent of damages sustained. This Tool will provide those grantees with information that will allow them to assess needs and rapidly develop recovery programs.

3. SCOPE

The Disaster Data Recovery Portal Pilot is anticipated to replace the currently used system that involves a variety of data sharing methods ranging from the default method of sending physical media (e.g., CD-ROM, flash drive, portable hard drive, etc.) to a state-specific secure File Transfer Protocol (FTP) system. The Disaster Data Recovery Portal Pilot’s primary goal is to put an end to “double-dipping” by aid recipients while the secondary goal is to provide a secure and real-time (or as real-time as is feasibly possible) system to support state and local governments in their relief efforts. The Tool supports the mission of HUD CDBG-DR grantees by allowing them to efficiently and effectively route aid to the locations and individuals with the most need for that aid. HUD CDBG-DR grantees face many challenges in the wake of a disaster, including limited information about the type and extent of damages sustained. This Tool will provide those grantees with information that will allow them to assess needs and rapidly develop recovery programs.

The scope of this call order is for the contractor to deliver the Disaster Data Recovery Portal Pilot system. The Period of Performance will cover creation of the registration/authentication system, a user interface that allows for the selection and sorting of all data as well as user-selected subsets of data, and a visualization of the data and/or subsets of data over GIS maps.

In creating the Disaster Data Recovery Portal Pilot, the contractor will work with 2-3 different municipalities that will be confirmed by time of award.

This Performance Work Statement (PWS) describes the technical and administrative components of the requirement as follows:

  • Tasks that the contractor must successfully perform.

  • Operational requirements that must be met while the contractor performs.

  • Generalized administrative requirements and any other terms and conditions.

  • Invoicing Instructions for contractor to receive payment.

4. ROLES & RESPONSIBILITIES

Contracting Officer. The Contracting Officer (CO) is responsible for monitoring call order contract compliance, contract administration, and cost control and for resolving any differences between the observations documented by the Government and the contractor. The CO will designate, at a minimum, one (1) CO’s Representative (COR) and one (1) Alternate CO’s Representative (ACOR) as the Government authority for performance management. The CO may, at their discretion, designate in writing any number of additional representatives to serve as technical inspectors depending on the complexity of the services measured as well as the contractor’s performance.

Contracting Officer’s Representative and Alternate Contracting Officer’s Representative. The Contracting Officer’s Representative (COR) and the Alternate Contracting Officer’s Representative (ACOR) are designated in writing by the CO to act as his or her authorized representative to assist in administering a contract. COR/ACOR limitations are contained in the written appointment letter. The COR/ACOR are responsible for technical administration of the project and ensure proper Government surveillance of the contractor’s performance. The COR/ACOR are not empowered to make any contractual commitments or to authorize any contractual changes on the Government’s behalf. Any changes that the contractor deems may affect contract price, terms, or conditions shall be referred to the CO for action. The COR/ACOR will have the responsibility to document the inspection and evaluation of the contractor’s work performance. The COR/ACOR’s acceptance of the vendor product is dependant on the Product Owner’s approval.

Procurement Project Manager. The Procurement Project Manager (PM) is the interface between the requiring organization (GSA TTS) and contracting organization (GSA FAS AAS/NCR). The Procurement PM coordinates technical aspects of the contract with the COR/ACOR and CO, assists with contract administration, ensures client acceptance of services, and reviews invoices for payment.

TTS Product Lead. The TTS Product Lead is responsible for coordination between the contractor, the Product Owner, as well as the CO and COR/ACOR.

TTS Technical Lead. The TTS technical lead is responsible for coordination between the contractor’s development team, the Product Owner and the key interagency stakeholders.

Product Owner (HUD). The Product Owner is the project’s key stakeholder and is from the HUD team. They are responsible for having a vision of what he or she wishes to build, and conveying the vision to the TTS Product Lead and the contractor’s scrum or development team. The Product Owner does this in part through the product backlog, which will be a prioritized features list for the product. The Product Owner is responsible for advocating on behalf of the agency’s needs and responsible for decision-making during sprint planning and implementation. The Product Owner will work with the COR/ACOR to inspect vendor work.

5. TASKS

The contractor will provide the following services:

  • Contractor shall create and execute a web-based registration process that interfaces with the FEMA’s existing API, allowing authorized HUD grantees to access an authorized subset of records.

  • Contractor shall develop a web-based, interactive system, allowing authorized users to retrieve an authorized subset of records as bulk data, in such formats as are necessary to support the needs of HUD grantees.

  • Contractor shall develop a web-based, interactive mapping interface, allowing authorized users to review household-level data from the FEMA API, rendered geospatially.

  • Contractor will conduct research activities including, but not limited to, ethnographic studies, stakeholder interviews, and usability tests. Contractor shall create and deliver to HUD, records and notes collected during their research.

  • Contractor shall work with TTS, HUD, and the FEMA project teams to ensure that the system is compliant with security policies.

  • Contractor shall ensure that the system includes user authentication and authorization functionality that uses open source encryption protocols.

  • Contractor shall post all code to a publicly-available code repository, with a Public Domain license.

  • Contractor shall ensure that the architecture is extensible to allow for future development.

  • Contractor shall incorporate analytics, monitoring, continuous integration, and measurement tools into their code base.

  • Contractor shall use plain language in application design and development whenever possible. In the event that HUD does not provide the Contractor with content-specific guidance or grammatical rules for the Disaster Data Recovery Portal Pilot, Contractor should adhere to 18F’s content guide.

  • Contractor shall establish, and ensure the Disaster Data Recovery Portal Pilot’s adherence to, a reasonable performance budget for mobile devices.

  • Contractor shall utilize the U.S. Web Design Standards or other development standards as developed by the 18F team.

Additional requirement:

  • As part of this being purchased off of the Agile Blanket Purchase Agreement (aBPA), work will be conducted in two-week sprints and reviewed at the end of each sprint for acceptability before moving on. The contractor and government may mutually agree to alter sprint length as needed.

The contractor will not be responsible to perform the following:

  • Hosting of the system.

  • Manage the granting of an authority to operate.

6. OPERATIONAL REQUIREMENTS

6.1 Personnel

6.1.1 Skills and Knowledge

The contractor shall provide qualified personnel commensurate with this task's performance work statement, in terms of necessary skills at the requisite level of knowledge and experience.

Broadly, a team assigned to this task order is expected to have experience with:

  • Interfacing with a representational state transfer (RESTful) and Simple Object Access Protocol (SOAP) APIs

  • Building applications that interact with RESTful and SOAP APIs

  • Displaying geodata on a lightweight, responsive map, using open source software

  • Human-centered design practices, such as:

    • Research, such as (but not limited to) contextual inquiry, stakeholder interviews, and usability testing

    • User experience design

    • Front end development

    • Sketching, wireframing, and/or prototyping

    • Visual design

    • Content design

  • Responsive design

  • Performance budgeting, and progressive enhancement

  • Building and testing public facing sites and tools

  • Open source software development

  • Cloud deployment

  • Open-source login/authentication services

  • Low-bandwidth environments

  • Managing and securing PII

  • Agile and scrum methodologies

6.1.2 Key Personnel

Contractor’s Project Manager (PM) and Technical Lead for this project must be listed as Key Personnel.

To ensure successful performance of the requirement, contractor shall satisfy the following:

A. The contractor shall assign a PM and a Technical Lead as Key Personnel whose résumés are submitted with its quotation to perform this call order.

B. Key Personnel must have a full understanding of the technical approach discussed in the Oral Presentations and delivered by the contractor after award. NOTE - the labor category proposed is at the contractor's discretion.

C. Key Personnel will be a direct liaison to the COR/ACOR and the TTS Product Lead. Key Personnel shall be responsible for the supervision and management of the contractor’s personnel, technical assistance, and interface. Desired skills and experience include:

  • Experience in technical leadership.

  • Ability to rapidly prioritize competing requirements.

  • Ability to understand and simplify customer requirements.

  • Ability to communicate end user feedback to technical and design leads.

  • Strong communication skills.

  • Proven knowledge of industry standards.

6.1.2.1 Key Personnel Substitution

If any individual proposed as Key Personnel becomes unavailable during the course of the solicitation and evaluation process:

A. The contractor shall notify the CO immediately and provide a substitute person with résumé. Any Key Personnel proposed who are not currently employed by the contractor shall be identified as such and an additional letters of intent signed by the proposed Key Personnel shall be provided that indicates that person's intent to be employed by the contractor if awarded this call order.

B. The contractor agrees that through the duration of the base period of performance of the call order, no Key Personnel substitutions shall be made unless necessitated by an individual’s sudden illness, death, or termination of employment for cause. In any of such event, the contractor shall promptly notify the COR/ACOR and the TTS Product Lead and provide the information required by paragraphs below on the proposed replacement for Government approval.

C. All requests for substitutions/additions of Key Personnel must include a detailed explanation of the circumstances necessitating the proposed substitution or addition, a complete résumé for the proposed substitute or addition including skills, experience, education, training, and security level. As determined by the CO, all proposed substitutes/additions must have qualifications that meet or exceed the qualifications of the person to be replaced.

D. The CO, or duly designated COR/ACOR and the TTS Product Lead, will evaluate the request(s) for substitutions/additions of Key Personnel and the CO will notify the contractor, in writing, of approval or disapproval. Disapproval of the proposed individual(s) shall not provide grounds for non-performance by the contractor or form the basis of any claim for monies, delivery schedule extension, or any other equitable adjustment.

6.1.3 Project Management

The contractor shall provide a Project Manager (PM) as the primary point of contact for the government’s program office to enable timely problem resolution, reporting in accordance with Program Management methodologies, and properly aligning staffing requirements. Sprint plans will be developed collaboratively with the TTS Product Lead for this aBPA buy as well as the Product Owner from the HUD team.

Per agile development principles, the contractor will be expected to work with the COR/ACOR, the TTS Product Lead and the Product Owner.

6.1.4 Estimated Level of Effort

The Government estimates this project will require no more than 4-5 personnel --- though not all will be needed on a full time basis. Contractors are encouraged to use their own estimating methodology to determine the skill mix and level of effort necessary to successfully perform this task order.

6.2 Post Award Orientation Conference

The Government's team, CO, COR/ACOR, the TTS Product Lead and the Product Owner will hold a Kick-Off Meeting/Post-Award Conference with the the contractor. Because the HUD, FEMA, and TTS team are distributed throughout the US, this kickoff will be done virtually with contractor’s team and other relevant Government staff to review and clarify the project’s objectives, expectations from the Government, and address any questions the contractor may have. Discussion topics shall include, but not be limited to:

  • Introduction of the contractor and Government Staff;

  • Understanding of the workflow;

  • Project management expectations;

  • Agreement on communication methods; and

  • Discussion of any other relevant specific concerns.

The Kick-Off Meeting/Post-Award Conference will take place within 10 calendar days from award. The contractor shall provide any finalized contractor Teaming Arrangements (CTAs)/Subcontractor arrangements at this time.

6.3 Daily Operations

Contractor’s Project Manager shall be responsible for daily operations as well as coordinating and communicating with the TTS Product Lead. Daily operations may include:

  • Daily standup via video or phone, depending on the technology available at HUD.

  • Regular, informal daily communication via web-based chat software, github issues, or other system as mutually agreed upon.

  • Manage and update user stories and workflow tasks in shared project management system - could be Github or another system.

6.4 GSA AAS Business Systems (AASBS) Web Portal

The GSA AASBS (Assisted Acquisition Services Business Systems also known as IT Solutions Shop (ITSS)) web portal will be accessible to the contractor during the performance of the call order and be used in the administration of the call order. This web-based system at https://portal.fas.gsa.gov/web/guest shall be used by the contractor to upload status reports, deliverables, invoices, and to respond to inquiries. The contractor shall maintain a current account on this system.

6.5 Travel

No travel is anticipated or will be required as part of this task order.

6.6 Deliverables

6.6.1 Status Reports

In lieu of a typical status report, contractor's progress must be documented and submitted to the the COR/ACOR, the TTS Product Lead and the Product Owner for each sprint's period of performance with a mix of the following deliverables:

  • Github issues/commits/branches accepted by the TTS Project Team

  • Screenshot, links, or other documentation from the shared project management system reflecting completed features, including number and percentage of completed sprint tasks (e.g. percentage of tasks completed)

  • User research documentation

  • Summary slide decks or other collateral created for design, development, system architecture, and stakeholder briefings

6.6.2 Impact Reports

The contractor shall be responsible for providing timely notification to the COR/ACOR and the TTS Product Lead when activities or issues outside of the contractor’s control may directly impact the contractor’s performance. This notification shall be provided in writing or via email within 24 hours of any anticipated or known impact.

6.6.3 List of Deliverables

Deliverable Due Date Description
Code & Status Reports 1 business day after each sprint Demonstration of progress throughout each sprint.
Code Repository of Product End of call order Version-controlled Open Source repository of code that comprises prototype.
Research A research plan shall be delivered during the first sprint. Research-related records shall be delivered at the end of the second sprint and every applicable sprint. thereafter A summary of research conducted and results found. If applicable, next steps or recommendations based on research.
Design Deliverables End of every applicable sprint Mock ups and/or design files if applicable, or design changes reflected in the Development Prototype.
Development Prototype End of second sprint and every sprint thereafter In-progress development prototype, accessible on the web via staging server / development server.
Transition Plan To be worked on no later than the second to last sprint of the initial Period of Performance Work with HUD and TTS team to make sure there is a clear plan for handing off the code repository.

The contractor shall submit all deliverables to COR/ACOR, TTS Product Lead, and Product Owner.

6.6.4 Delivery Instructions

Code deliverables shall be submitted via the Github repository. A copy of any document deliverables shall be submitted to the COR/ACOR, the TTS Product Lead and the Product Owner, and uploaded to the AASBS (Assisted Acquisition Services Business System) web portal. Refer to Section 6.11 for additional information on the AASBS web portal.

Research-related records shall be delivered in accordance with OMB Circular A-130.

6.6.5 Inspection and Acceptance of Services

Within approximately 5 business days of each sprint's conclusion, the Government will inspect, test, review and accept all periodic reports and task deliverables, as applicable.

Only the COR/ACOR, TTS Product Lead, and their designated alternate, has the authority to accept or reject all deliverables. The COR/ACOR and the TTS Product Lead will provide written final acceptance of all deliverables to the contractor within approximately 30 days from the end of the call order, via electronic means. The COR/ACOR’s acceptance of all deliverables will be contingent on Product Owner approval.

Any contractor performance to correct defects found by the Government as a result of quality assurance surveillance and by the contractor as a result of quality control, shall be in accordance with FAR 52.246-6, Inspection – Time-and-Materials and Labor-Hour. The COR/ACOR and the TTS Product Lead will monitor compliance and report to the Procurement Project Manager.

6.6.6 System Documentation

The contractor shall consult with the TTS Product Lead to determine what is appropriate, effective, and essential for system documentation. The Government requires, at a minimum, that the contractor will generate comprehensive and complete documentation, both within the code itself, within the source code version control system (e.g., through proper use of descriptive commit messages, issue tracking, pull requests, etc.), and as appropriate, in separate documentation, provide artifacts, and create new user stories based on each sprint.

6.6.7 Quality Assurance

The Government will use the attached draft Quality Assurance Surveillance Plan (QASP) to monitor the contractor’s performance. The QASP will provide oversight help to ensure that service levels reach and maintain the required levels for performance of this task. Further, the QASP provides the Government with a proactive way to avoid unacceptable or deficient performance, and provides verifiable input for the required Past Performance Information Assessments. The QASP is a living document and may be updated by the Government as necessary. Any updates to the QASP will be provided to the contractor. If needed, the draft QASP will be updated within 10 business days of contract kick off meeting by TTS Product Lead and/or the COR/ACOR.

6.7 Transition

6.7.1 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 this call order will be the property of the U.S. Government and in the public domain.

  • Two weeks prior to call order conclusion, provide a brief Transition Plan for all deliverables, products, and materials in coordination with the COR/ACOR, TTS Product Lead and Product Owner.

  • Coordinate with the COR/ACOR and the TTS Product Lead and potentially another vendor, and implement the Transition Plan according to the COR/ACOR and the TTS Product Lead’s direction.

  • Provide assistance to the COR/ACOR, TTS Product Lead, and potentially other Government staff to stand-up the application.

6.7.2 Transition Activities

During the transition to the Government, or 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 TTS and other customers; participation in meetings with the Government or new contractor to effect a smooth transition and provide detailed information on the operation of all deliverables, at COR/ACOR and the TTS Product Lead's discretion; training of new personnel, either Government or new contractor, during transition period; and appropriate close-out of any outstanding technical and related performance elements for this task.

Final report shall include a list of sprint tasks completed, documentation, and link to code repository developed for TTS. Should the contractor be terminated prior to the end of the period of performance, the contractor shall transfer all project materials to the COR/ACOR and the TTS Product Lead within two weeks of the COR/ACOR and the TTS Product Lead’s request.

7. TERMS AND CONDITIONS

7.1 Type of Contract

This is a labor-hour (LH) order under master Agile BPA (aBPA) Pool Stack 3 terms and conditions.

7.2 Period of Performance

The Period of Performance (POP) is four (4) months. Further, a contingency of up to 6 months may be exercised . The POP is expected to begin within 10 calendar days after award.

7.3 Place and Hours of Performance

The primary place of performance will be at the contractor’s facility. The contractor may set its own work hours; however, the contractor shall be available for technical contact by the Government between the hours of 0900 and 1800 eastern time on Government work days.

7.4 Administration Points of Contact

The following Points of Contact (POC) are applicable to this order:

  1. Contracting Officer (CO): Fred Thomas, Federal Acquisition Service, GSA

  2. CO’s Representative (COR): Randy Hart, GSA, Technology Transformation Services

  3. Alternate CO’s Representative (ACOR): Omid Ghaffari-Tabrizi, GSA, Technology Transformation Services

7.5 Government Furnished Items

The Government will provide access to the Application Programming Interface and its underlying data at the time of award. No other hardware or software will be provided by the Government.

7.6 Non-Personal Services

This call order is not being used to procure personal services prohibited by FAR 37.104, Personal services contract.

7.7 Transparency Policy

Vendors are advised that TTS will publish on a publicly available website documents associated with this requirement, including any Requests for Quotation (including amendments), Question and Answer exchanges with vendors (source-identifying information removed), and other relevant information that is not confidential/proprietary in nature or source selection sensitive information that would otherwise implicate procurement integrity concerns.

Upon award, TTS will publish the total price of the selected proposal and certain non-source-identifying data (for example, the number of bids, the mean price, median, and standard deviation of price). During the performance of this call order, TTS will similarly publish source code, data related to project management (for example, user stories, milestones, and performance metrics), and top-line spending data.

7.8 Data Rights and Ownership of Deliverables

TTS intends that any data or deliverable created as a result of the work performed under the call order be committed to the public domain.

Further, TTS intends to commit the following items, to the public domain, at a minimum:

  • All data, documents, graphics and code created under this call order including but not limited to, plans, reports, schedules, schemas, metadata, architecture designs, and the like;

  • Any and all new open source software created by the contractor and forks or branches of current open source software where the contractor has made a modification; and,

  • Any and all new tooling, scripting configuration management, infrastructure as code, or any other final changes or edits to successfully deploy or operate the software.

The contractor shall use open source technologies wherever possible, in support of the 18F Source Code Policy. All licenses must be expressly listed in the deliverable. Regardless of license(s) used (e.g., MIT, GPL, Creative Commons 0) the license(s) shall be clearly listed in the documentation.

If the contractor needs to use work that does not have an open source license, the contractor is required to request permission from TTS, in writing, before utilizing that work in any way in connection with the order. If approved, all licenses shall be clearly set forth in a conspicuous place when work is delivered to TTS.

If an open source license provides implementation guidance, the contractor shall ensure compliance with that guidance. If implementation guidance is not available, the contractor shall attach or include the license within the work itself. Examples of this include code comments at the beginning of a file or contained in a license file within a software repository.

7.9 Section 508 Compliance

The contractor shall support the Government in its conformance with Section 508 throughout the development and implementation of the work to be performed.

Section 508 of the Rehabilitation Act of 1973, as amended (29 U.S.C. 794d) requires that when Federal agencies develop, procure, maintain, or use electronic information technology, Federal employees with disabilities have access to and use of information and data that is comparable to the access and use by Federal employees who do not have disabilities, unless an undue burden would be imposed on the agency. Section 508 also requires that individuals with disabilities, who are members of the public seeking information or services from a Federal agency, have access to and use of information and data that is comparable to that provided to the public who are not individuals with disabilities, unless an undue burden would be imposed on the agency.

The following standard is applicable for compliance:

1194.22 Web-based Intranet and Internet Information and Applications.

The contractor should review the following websites for additional 508 information:

7.10 Non-Disclosure Agreement

All contractor key personnel, employees, agents, subcontractors and subcontractor personnel who will have access to documents or data during the performance of their duties under the contract shall execute the attached Non-Disclosure Agreement and return it to the CO within 5 calendar days of award and before being given access to such information or documents.

8. INVOICING & PAYMENT

The period of performance for each invoice shall be for one calendar month. The contractor shall submit only one invoice per month per order/contract.

The Government reserves the right to audit, thus; the contractor shall keep on file all backup support documentation for travels as applicable.

8.1 Content of Invoice

The contractor’s invoice will be submitted monthly for work performed the prior month. The contractor may invoice only for the hours, travel and unique services used in direct support of the call order. The invoice shall be submitted on official letterhead and shall include the following information at a minimum.

  • Client Order ID Number

  • ACT Number

  • Prompt Payment Discount

  • Remittance Address

  • Period of Performance for Billing Period

  • Point of Contact and Phone Number

  • Invoice Amount

  • Skill Level Name and Associated Skill Level Number (for Labor Hour)

  • Actual Hours Worked During the Billing Period (for Labor Hour)

  • Clearly indicate both the current invoice’s monthly “burn rate” and the total average monthly “burn rate” (for Labor Hour)

8.2 Invoice Submission

All invoicing shall be done electronically. Password and electronic invoice access may be obtained through the AASBS web portal.

The Invoice and the Status Reports for the applicable billing period shall be entered into the AASBS portal within 5 to 10 calendar days after the end of the month. The contractor shall submit invoices electronically by logging into the AASBS portal, navigating to the appropriate order, and creating the invoice for that order and attach a copy of invoice, status reports with all required back-up documentation as applicable.

The contractor shall NOT submit any invoices directly to the GSA Finance Center (neither by mail nor via electronic submission). If the invoices are acceptable, then the Procurement Project Manager and COR/ACOR will approve them for payment and complete the information in the AASBS portal.

8.3 Final Invoice

Invoices for final payment must be so identified and submitted within 60 calendar days from task completion and no further charges are to be billed. A copy of the written acceptance of task completion must be attached to final invoices. The contractor shall request for an extension from the COR/ACOR for final invoices that may exceed the 60-day time frame.

The Government reserves the right to require certification by a COR/ACOR before payment is processed, if necessary.

8.4 Close-out

The contractor shall submit a final invoice within 60 calendar days after the end of the performance period. After the final invoice has been paid the contractor shall furnish a completed and signed Release of Claims (GSA Form 1142) to the CO. This release of claims is due within 15 calendar days of final payment.

ATTACHMENTS

  1. PWS - QASP

  2. Non Disclosure Agreement - Company

  3. Non Disclosure Agreement - Employee