Encl-4_Proposal.Submission.Instr_ FINAL.docx

W900KK-22-R-00XX

ENCLOSURE 4: W900KK-22-R-0012

PROPOSAL SUBMISSION INSTRUCTIONS

Applicant Considerations and Caveats Step-Two: Request for Proposals/Solutions The Contracting Office will notify offerors if their white paper was selected, or not selected, for further consideration. If the white paper receives a favorable review and is being considered for award, the Contacting Officer will forward to the Offeror a formal Solicitation (Request for Proposal (RFP) for FAR-based contracts or Request for Solutions (RFS) for Other Transaction (OT) Agreement) requiring a full proposal submission as addressed later in this document. Based upon white paper evaluation feedback, the RFP/RFS may include clarifications to address in requested solutions based on the entire white paper, or a portion of the white paper submission.

During the evaluation of the RFP/RFS responses, the Government may seek further offeror clarifications of content to resolve evaluation assessments.

Award Consideration Upon completion of evaluations within a TTA’s submission, the Contracting Office will notify offerors if their submission was selected, or not selected, for award consideration. If an offeror is notified with an intent to award, the request does not mean an award is assured. Award is determined after resolution of potential further clarifications, pending contract negotiations, and availability of funds. The official notification for intent to award will be sent via email to the technical and administrative POCs identified on the response’s Data Sheet submission.

Offerors must be aware that it is their responsibility to ensure: (1) correct email addresses are provided at the time of submission, (2) email notifications reach the intended recipient(s), and, (3) the email is not blocked by the use of ‘spam’ filtering software or other means that the recipient’s Internet Service Provider may have implemented as a means to block the receipt of certain emails.

TRMC may make selections up to 12 months after proposal evaluation and determination of interest via contracting officer communications to the offeror. TRMC may make selections anytime during the BAA open period and up to 12 months following the closing date of this BAA. If the contracting officer issues correspondence for intent to award and the project is not awarded within 180 days of proposal submission, the offeror is provided an opportunity to revise costs based upon labor escalation and material availabilities/market prices.

Teaming Perspectives This BAA is intended to encourage the use of complementary, interdisciplinary research and development teams consisting of industry, academia, national test centers, and/or laboratories that leverage individual strengths coupled with unique resources and experience. Offerors must be willing to cooperate and exchange software, data and other information in an integrated program with other contractors. The TRMC T&E/S&T Program will not actively participate in the creation of project teams. If an offeror is proposing a contribution arrangement with a Government/Federal laboratory (personnel, services, facilities, and equipment) as a joint effort to develop the technology, a Cooperative Research and Development Agreement (CRADA) may be required. If an established CRADA exists between the offeror and the intended Government laboratory/entity, the offeror shall provide a copy of the CRADA when submitting the proposal.

Offerors may propose subcontracting and teaming arrangements; however, it is expected for FAR based solutions that the submitting offeror will lead and perform 50% of the effort by cost. For OTs, the lead offeror, if seeking to qualify as a non-traditional defense contractor, must participate to a "significant extent." There is no set dollar amount or percentage of work that is considered a "significant extent" and offerors must provide justification to support a determination by the Contracting Officer that they are participating to a "significant extent."

Submission Marking Requirements Potential offerors are responsible for clearly identifying proprietary information. Submissions containing proprietary information must have the cover page and each page containing such information clearly marked with a label such as “Proprietary” or “Company Proprietary.” NOTE: “Confidential” is a classification marking used to control the dissemination of U.S. Government National Security Information as dictated in Executive Order 13526 and shall not be used to identify proprietary business information. Applicable page markings for any identified Controlled Unclassified Information (CUI), including Controlled Technical Information (CTI) information must be indicated.

TRMC will protect all white papers and proprietary information from unauthorized disclosure and will only disclose the contents for the purpose of evaluation. Offerors are responsible for marking proprietary information with the proper disclosures. This requirement applies to both white paper and full proposal submissions, if solicited.

Government Intentions Regarding Proposal Submissions The Government intends to select solutions without discussions based upon its evaluation of proposals; however, the Government reserves the right to hold discussions or obtain clarifications of the proposal with the offeror, if deemed necessary.

This announcement does not commit the Government to pay for the preparation of white papers. The cost of preparing a response to this announcement is not considered an allowable direct charge to any resulting award.

Research Project Eligibility Considerations Offerors are reminded this BAA is for the acquisition of advanced technology directed toward advancing the state-of-the-art of test and evaluation technologies, and increasing knowledge and understanding of the trade-offs between optimizing different parametric elements that are required to enable the advancement. Proposals related to the development of a specific system will not be accepted since they are non-conforming to the intent of this BAA.

All research projects must meet the following eligibility requirements for consideration:

· T&E Need. The candidate project must address limitations in the current T&E infrastructure to measure or assess performance of a DoD military capability, system, prototype, or concept.

· S&T Proposed. The candidate project should develop one or more specific innovations distinct from engineering efforts to improve an existing capability, involving technology at TRL 3-6. DoD TRL definitions: https://api.army.mil/e2/c/downloads/404585.pdf A submission that does not identify a T&E Need and the S&T Proposed within TRL3-6 will be considered non-compliant.

TRMC Program Common Software Development Terminology Discussion of software development and related deliverables discussions should comply with the following definitions.

“Computer Databases” are defined as “a collection of recorded data in a form capable of being processed by a computer. The term does not include computer software.”

“Computer Software” means computer programs, source code, source code listings, object code listings, design details, algorithms, processes, flow charts, formulae and related material that would enable the software to be reproduced, recreated, or recompiled. Computer software does not include computer databases or computer software documentation.

“Computer Software Documentation” means owner's manuals, user's manuals, installation instructions, operating instructions, and other similar items, regardless of storage medium, that explain the capabilities of the computer software or provide instructions for using the software."

“Technical Data (TD)” includes any recorded information of a scientific or technical nature (e.g., product design or maintenance data, "Computer Databases", and "Computer Software Documentation").

Highlighted Policy Expectations Regarding Offeror Participation Range System Interoperability: TRMC’s Test and Training Enabling Architecture (TENA) is a system architecture designed to bring interoperability to United States Department of Defense test and training systems. TENA is designed to promote integrated testing and simulation-based acquisition through the use of a large-scale, distributed, real-time synthetic environment, which integrates testing, training, simulation, and high-performance computing technologies, distributed across many facilities, using a common architecture. TRMC-sponsored technology and capability development pursues TENA-complaint software architecture and development, where applicable. See https://www.tena-sda.org for more information. Project submissions shall support TENA compliance unless identified in the submission as not applicable nor value-added in doing so.

Use of Data: TRMC may share some or all of the program-generated data with the broader research community as open data (with permission to access, reuse, and redistribute under appropriate licensing terms where required) to the extent permitted by applicable law and regulations (e.g., privacy, security, rights in data, and export control). TRMC plans to enable reproducibility of results through data sharing and to establish (or contribute to) digital collections that can advance this and other scientific fields.

Data are increasingly the key product of research and engineering endeavors. To ensure the reproducibility of results and access to source data for future research, awardees will be required to maintain and deliver any data generated during award performance (“program-generated data”) that is needed to accomplish these goals. Awardees shall be expected to document both the proprietary and non-proprietary products of their research to ensure the retention and potential reusability of this information. This may include, but is not limited to:

· Raw unprocessed data, software source code and executables, build scripts, process sequence, programmatic communication and other collaboration activities

· Data sets: rarified, experimental, test and measurement data

· Design of experiments and simulations

· Models or simulations (computational or mathematical)

· Recordings of various physical phenomena (including images, videos, sensor data, etc.)

· Access to and use of institutional, organizational or scientific community repositories and archives Enclosure 5 – Administrative and National Policy Requirements and the associated attachments that address Organizational Conflict of Interest, and Intellectual Property should be clearly understood prior to developing white paper and proposal submissions.

Proposal Submission Process

1. Method for Submission The offeror shall submit requested proposals only via email. Submissions shall not exceed email size of 20MB for proposal submission documents including digital signature. Submissions that DO NOT contain any CUI, including CTI, shall be sent via UNCLASSIFIED email to usarmy.orlando.peo-stri.list.trmc-te-st-baa@army.mil. The subject line of the email shall include:

1) The TTA abbreviation (for the submission’s topic), then (dash)

2) Proposed project acronym/initialism , then (underscore) For the offeror’s proposed project title, create a project acronym/initialism (preferably four to five characters, but no longer than six)

3) Offeror’s organization identifier, then underscore) Organization identifier should be created as follows: ‘Company or Academia acronym’(1), then (hyphen), ‘Business Unit Designation’(2), and using these conventions

- (1) one word name (or acronym/initialism) with no more than 8 characters included;

- (2) acronym or abbreviation of business unit or location with no more than 5 characters - omit if none.

4) “BAA #(insert correct Opportunity Notice number after an underscore, if applicable) (space) either RFP or RFS Response”.

*example subject line* “HSST-SPEEDY_BDC-HS_W900-22-R-0012_1.1 RFP Response” This is based on a RFP response to a High Speed Systems Test TTA topic that was submitted by Big Defense Contractor's Hypersonics Solutions business unit and where the project submission’s initialism is “SPEEDY”. The submission was made under the BAA’s Opportunity Notice 1.1.

NOTE: If sending updates to any submissions, add “_r(#)” onto the encoded project submission name, as follows:*example subject line* “HSST-SPEEDY_BDC-HS_W900-22-R-0012_1.1_r1 RFP Response” for the first revision/update to the submission.

All attached files associated with the proposal submission shall use a file name convention as described in paragraph B.

Submissions that DO contain any CUI, including CTI, must be transmitted via DoD SAFE (https://safe.apps.mil). If an offeror is a ‘guest’ per the DoD SAFE guidelines, a drop-off request must be submitted per the BAA document, and after receipt of an email with the drop-off code, a submission shall be made for the ENTIRE proposal package to ensure it remains intact vs. only CUI documents. Follow other guidelines provided in the DoD SAFE email sent. Place the email subject line described above in the drop-off field labeled “Short Note to the Recipient.” Also identify which files contain CUI in this field.

The offeror should mitigate the impact of any possible transmission interruptions by submitting in advance of any deadline. The offeror shall ensure that the data sheet, title page, and all forms are signed by an authorized official for the offeror. The offeror shall ensure the submission is sent to the correct email address as listed above. Submissions sent to an incorrect email address will not be evaluated. The offeror may not submit by fax or in person, as any submission not received via the approved method will not be evaluated. For a proposal submission from an RFP/RFS, the offeror is responsible for submitting the proposal by the time specified. A proposal received after the RFP/RFS deadline is deemed “late” and may not be considered for award. Other guidance includes

· Submissions are expected to be UNCLASSIFIED. If submission of CLASSIFIED information is approved, follow the instructions provided by the Contracting Officer. Note that requests should be made well before the submission due date to allow for the request’s review and approval in time.

Proposal submission documents shall be letter size (8.5 x 11 inches), have one-inch margins on all sides, and use a 12-point font. General text of the technical proposal shall use font size 12. Any figures, schematics, drawings, diagrams, schedule charts, and tables may also include single-spaced text that shall use a font not smaller than 8 point. Each page must be single-sided and numbered. Each page must have the title of the project and its acronym in the one-inch top margin as a header. If applicable, each page must reference any proprietary data disclosure statements and CUI in the one-inch bottom margin as a footer with appropriate markings discussed previously.

The proposal and any external forms shall be prepared in accordance with all instructions referenced herein. There are four volumes to the proposal:

· Volume 1: Technical/Management Proposal

· Volume 2: Draft Statement of Work

· Volume 3: Cost and Pricing Data

· Volume 4: Administrative Submission Requirements VOLUME 1: Technical/Management Proposal and Related Document Instructions Proposal package submissions shall be responsive to any further guidance regarding the submitted white paper as per the RFP/RFS instructions. The offeror shall date all proposal submission items. In all circumstances a proposal submission shall consist of the following items as separate files, also using a specified file naming convention.

*example file name* “22HS102_BDC-HS_SPEEDY_1TMV” Each element below is separated by an underscore. The first element is based on an internally generated TRMC project code (e.g. 22HS102) and is provided in the RFP/RFS. The second element is the company and project acronym as described in para A above. The third element is a document code as described for each required submission document (e.g. “1TMV” abbreviation for the technical and management volume document).

If the document was submitted as a revision to a prior submission, include the revision/update number per the below example:

*example file name* “22HS102_BDC-HS_SPEEDY_1TMV_r1” Required document submissions:

1) Volume 1: Technical/Management Proposal (1TMV) (limited to 25 pages of submission content, as specified)

· Format: Office Open XML Document (.docx) or Portable Document Format (.pdf)

· Naming convention suffix abbreviation: 1TMV

· NOTE: if the file contains controlled unclassified information, add “_CUI” at the end of the file name

2) Gantt Chart Project Schedule (1SKED) (as specified later in this document)

· Format: Portable Document Format (.pdf)

· Naming convention suffix abbreviation: 1SKED

· NOTE: if the file contains controlled unclassified information, add “_CUI” at the end of the file name

3) Copy of CRADA (1CRA), if applicable (see section I.C Teaming Perspectives )

· Format: .pdf

· Naming convention suffix abbreviation: 1CRA

4) Attachment 6 - Proposal Data Sheet (1DSX)(completed but unsigned)

· Format: Office Open XML Workbook (.xlsx)

· Naming convention suffix abbreviation: 1DSX

5) Attachment 6 - Proposal Data Sheet (1DSS) (signed)

· Format: .pdf

· Naming convention suffix abbreviation: 1DSS

6) Attachment 3 - Government Data Rights Acknowledgement (1DRK) (signed)

· Format: .pdf

· Naming convention suffix abbreviation: 1DRK

7) Attachment 4 - Intellectual Property/Data Rights Assertions (1DRA) (signed)

· Format: .pdf

· Naming convention suffix abbreviation: 1DRA

8) Attachment 7: Project Quad Chart (1PQC)

· Format: Open Office XML Presentation (.pptx)

· Naming convention suffix abbreviation: 1PQC The forms to be submitted with the proposal (items #3 – #8) are provided as separate attachments in the BAA posting. If the offeror revises or modifies the narrative of any form, the proposal submission will be rendered as non-compliant.

Volume 1: Technical/Management Proposal Content Each proposal must stand on its own merit. Only information provided in a proposal will be used in the evaluation process. No supplemental information provided by the offeror will be considered. Brochures or other marketing materials are not desired. All required information must be conveyed clearly and concisely.

The technical proposal shall be limited to twenty-five (25) pages (sized 8.5 by 11 inches) and may be single-spaced. Any pages beyond these limitations will not be evaluated. The responses must address the entire proposed period of performance, including all options or phases. The Title Page, Executive Summary, Clarification Index, and designated Appendix is not included in the page limitation. Page limitations do apply to any CLASSIFIED information submitted.

The proposal shall contain numbered sections and an appendix that addresses the following items in the order listed:

TITLE PAGE

The title page is NOT included in Volume I page count.

· Labeled “VOLUME 1: TECHNICAL/MANAGEMENT PROPOSAL, BAA NUMBER (insert the complete BAA number)”

· TTA abbreviation (e.g. AAIT, DET, SET, etc.): T&E/S&T Topic Domain Number and Name, Topic Number and Title

· Responsible organization and business type (large, small, non-traditional, non-profit, university, FFRDC, other)

· Assigned Identification Number (from RFP/RFS)

· Proposed title and acronym/initialism

· Submission date

· Award instrument proposed (Contract (specify type; e.g., Cost Plus Fixed Fee completion), Cooperative Agreement, Other Transaction)

· Any CUI/CTI required markings and disclosure statements

· Any company proprietary information required markings and disclosure statements

CLARIFICATION INDEX

The Clarification Index is NOT included in Volume I page count. The RFP/RFS may include elements from the review of the white paper that need to be clarified in the proposal. For any clarifying elements requested in the solicitation, the offeror shall submit an index identifying where in the proposal each of the requested clarification items have been addressed.

EXECUTIVE SUMMARY

The Executive Summary is NOT included in Volume I page count. The offeror shall submit an Executive Summary, written in plain language, which does not exceed two (2) pages. The offeror shall concisely present the important goals, aspects, and core issues of their proposal. The offeror shall describe the T&E need, the proposed solution, and S&T challenge to develop the proposed solution. The offeror shall summarize the technical approach for the proposal including the major phases, the successive progression of TRL from start to end, and the benefits of the deliverables to DoD testing. In addition, the offeror shall describe any significant work that is required beyond TRL 6 to realize the ultimate benefits of the technology to DoD testing as well as provide a summary of those ultimate benefits. If known, the offeror should cite any potential DoD test ranges/agencies/programs or the military capabilities/systems that will benefit from the proposed project.

TECHNICAL/MANAGEMENT PROPOSAL CONTENT

The technical proposal shall convey information in a concise, straightforward manner without extraneous content. Unnecessary elaboration merely to fill the 25 page limit, emphatically, is not desired. Furthermore, the Government will only review the first 25 pages. If the technical proposal exceeds the page limitations set forth herein, excess pages will be removed from the back of the proposal and will not be evaluated. A proprietary data and CUI disclosure statement must be included on the first page of the technical proposal, if applicable, with each affected page marked “Proprietary Data”. Lastly, the technical proposal shall NOT contain any cost or pricing information.

The technical proposal shall contain numbered sections and an appendix that address the following items in the order listed:

SECTION 1: T&E Need/Benefit Each listed topic of interest describes a specific high priority test technology need. The offeror should provide a short description of the proposed test technology development and summarize how it satisfies the T&E need identified in the topic. The offer is not eligible for consideration if a T&E need is not addressed. If the offeror is only addressing a limited portion of the performance objectives for the topic of interest, the offeror should clearly distinguish what aspect of the topic is being addressed.

The offeror shall address the following concerns:

a. To what extent is the technology development providing a benefit or impact over the current DoD test capabilities?

b. What utility does the end-item deliverables from this effort provide for DoD testing?

The following content supports addressing these questions:

The offeror shall provide a description or visualization of how this technology would be used in T&E (specific examples, use cases, a concept of operations, etc.) to more clearly convey how the DoD would benefit from this technology in conducting developmental, operational, and/or live-fire T&E. The offeror shall identify what will be delivered from the proposed development and articulate any benefits or usefulness those deliverables could provide DoD T&E, as well as, discuss how the technology supports DoD T&E after it is matured beyond TRL 6 and incorporated into a test capability. The offeror shall describe the variety of applications for which the technology could be used to improve testing, which can include but are not limited to the following categories and examples:

· Supporting different aspects of testing Some generic DoD T&E examples include: 1) a sensor that could be used in a ground test facility and during flight testing, 2) a stimulator that could work inside a chamber and outside on an open-air range, 3) an analysis tool that can equally process data from simulations, hardware-in-the-loop laboratories, and open-air ranges.

· Supporting testing different types of systems Some generic DoD T&E examples include: 1) a sensor that could support high powered microwave testing and counter improvised explosive device (IED) testing, 2) an antenna that could be installed on aircraft and on missiles, 3) instrumentation that could track airplanes, helicopters, missiles, and ground vehicles.

· Supporting different DoD test organizations Some generic DoD T&E examples include: technology that could support testing for Army, Navy, Air Force, Marines, etc.

The offeror shall describe the potential significance or degree of enhancement the technology could provide the DoD test community. If the offeror does not intend for the solution to be TENA-compliant, then appropriate rationale must be provided. The Government uses the aforementioned, among other content, in considering the offer's level of importance to agency programs.

Note that this section addresses the same interests as SECTION 1 of the white paper submission. The expectation is more thorough coverage and visualizations.

SECTION 2: S&T Proposed The offeror shall clearly delineate the technology challenges this effort is addressing and undertaking. The offeror shall also include an assessment of the current state-of-the-art and how the proposed work will advance it, that is, “push the envelope” beyond what can be done today. In addition, the offeror must assess the starting TRL for the proposed work and provide a basis for the assessment, as well as, identify the ending TRL for the technology after the proposed test technology development. Note that this section addresses the same interests as SECTION 2 of the white paper submission. The expectation is more thorough discussions that justify the proposed levels of technology advancements. The technology must be developed within the specified TRLs of this BAA. If not, the offer is not eligible for consideration.

SECTION 3: Technology Maturity Approach The offeror should address the following concerns:

a. How feasible, reasonable, logical is Technology Maturity Approach?

b. What scientific principles are used to achieve the result?

c. How does the phased approach for TRL progression adequately address risk identification and mitigation?

The following content supports addressing these questions:

The offeror is strongly encouraged to consider the content in Enclosure 2 – Project Structure Guidelines when developing project technology maturation plans. This information identifies frequently recurring activities that have enabled historic project execution success.

The offeror shall provide a detailed development strategy that demonstrates the project’s technical feasibility for maturing technology with a successive progression of TRL from start to end. The solution described should be innovative, achievable, and complete. Include describing any discernment of requirements, use case analysis, tradeoff assessments, or any early use of models and simulations. The offeror shall highlight the advantages of their proposed development strategy over other potential alternatives. The offeror shall mention any previous work, its results, and how the results would be leveraged in their proposed test technology development. If the proposed solution is predominantly hardware, the offeror must identify plans to develop breadboards, brass boards, prototypes, or any other risk reducing demonstration items. If the proposed solution is predominantly software, the offeror must identify the development methodology along with any configuration management schema, scrums, code reviews, and software test strategies.

Additionally, software development discussions shall consider the alignment with data rights assertions per your Section 5 response, alignment with DoD security or Information Assurance policies (e.g. potential CUI/CTI, ITAR, and classified work, and needed Risk Management Framework (RMF) compliance), and any dependencies on commercial items, whether they are a component project deliverable or not.

The offeror shall provide a detailed description of the major tasks to be performed – organized in phases that have defined objectives and a period of performance that is of reasonable duration. This section should describe a final outcome that achieves a goal expected for each phase. The offeror shall propose exit criteria for each phase or at major milestones associated with TRL advancement, which the Government may use as a basis for contractual decision criteria. Deliverables and schedule are to be discussed in later sections. The Government uses the aforementioned, among other content, in considering technical merit.

SECTION 4: Deliverables The offeror shall address the following concerns:

Are the deliverables well defined, adequate for the development activities, and aligned to the project goals and programmatic requirements?

The following content supports addressing these questions:

The offeror must clearly delineate and describe each deliverable for each phase for every item developed or purchased using Government funds, including technical reports, analysis results, design artifacts (drawings, schemas, etc.), hardware items, and software products. The offeror must provide a complete list of deliverables, with a brief description of each deliverable and its frequency of delivery, to include but not limited to:

· Monthly status report (covers both technical progress and financial status)

· Presentation materials (required at meetings)

· Phase report (at conclusion of each phase comprehensively addressing all prior work)

· Project final report (at conclusion of last awarded phase)

· Hardware developed or purchased using project funds, including any associated design documentation, operation manuals, and user guides

· Using definitions for Computer Databases, Computer Software, Computer Software Documentation, and Technical Data (TD) from para I. G. above, software developed or purchased using project funds, including source code, software documentation, user manuals, example use cases, verification cases, and any other associated software artifacts

· Development tools created or purchased using project funds

· Interim development products, such as preliminary reports, and/or test plans, and/or devices

· Design review documents

· Technical reports For all documentation deliverables, the offeror shall recommend the appropriate distribution statement by marking in accordance with Department of Defense Directive 5230.24, Distribution Statements on Technical Documents (as revised). The Government will determine the distribution statement for all documentation. The offeror must propose proper markings for any technical data whose export is restricted by the Arms-Export Control Act (Title 22, U.S.C, Sec 2751, Et Seq.) or the Export Administration Act Of 1979 (Title 50, U.S.C., App. 2401 Et Seq.), as amended. The offeror shall make sure all listed deliverables match those listed in the SOW and any data rights assertions noted. The offeror must also delineate any special requirements that may be required to make use of any deliverable (e.g., special power required to operate a delivered hardware item, a software product required to view a delivered drawing, or a software environment required to run a delivered software tool). The Government uses the aforementioned, among other content, in considering technical merit.

SECTION 5: Technical Risk Identification & Mitigation Strategy The offeror shall address the following concerns. Are risks that are directly associated with technology maturation activities effectively reduced as the project progresses? The following content supports addressing this question.

The offeror should address the following concerns:

a. Are risks that is directly associated with technology maturation activities effectively reduced as the project progresses?

b. The following content supports addressing this question?

The following content supports addressing these questions:

The offeror shall provide a detailed description on how technical risk will be mitigated during the development. The offeror shall present their own identification of major risk factors and make their own risk assessment, with the likelihood and consequence of each risk progressing from the start to and the end of each phase. The offeror shall identify any recent effort or source of information to justify the risk assessment. The Government uses the aforementioned, among other content, in considering technical merit.

SECTION 6: External Dependencies The offeror shall address the following concerns:

Are external project dependencies and related programmatic/funding risks adequately identified?

The following content supports addressing these questions:

The offeror must identify and explain any external dependencies that could impact the execution of the proposed work resulting in a schedule delay. Examples of external dependencies may include, but are not limited to:

1) the offeror may propose using a Government facility to demonstrate the technology, which would be dependent on the availability of the facility,

2) the offeror may propose using data from a test event of an acquisition program, which would be dependent on the schedule and availability of that test event,

3) the offeror may need specific Government Furnished Property (GFP) as a component element of development or to conduct the development,

4) the offeror may propose leveraging technology from another development which would make that task dependent on the success of that external effort, or

5) the offeror may propose a dependency for project success based upon pending work to be performed under other funding sources. If applicable, explain the related funding sharing structures (as a percentage of proposed costs for TRMC BAA efforts vs. needed funds required for all required development). The offeror should include the synergistic benefits gained from leveraging the external dependency. The offeror should discuss any risk associated with any external dependency, along with a potential contingency plan or alternative solution to mitigate the risk with the external dependency. The Government uses the aforementioned, among other content, in considering technical merit.

SECTION 7: Project Schedule The offeror shall address the following concerns:

a. Does the schedule make sense?

b. Are the project phases of reasonable duration and the work elements adequate with necessary milestones for reviews and decisions?

The following content supports addressing these questions:

The offeror shall provide a Gantt-chart type schedule as a separate document submission per previously provided filename convention. The proposed project schedule has no page limits. The schedule should reflect work breakdown structure content used to develop the proposed cost/pricing in the technical approach with consideration of Enclosure 2: Project Structure Guidelines. The offeror must ensure the tasks are organized in a logical order and that the time allocated for each is reasonable for the work identified. It shall include, at a minimum, the following elements:

· Identified Phases (or Major Milestones) addressing TRL advancement, including the overall period or performance,

· Milestone activities and component tasks within each phase with designations of responsible party (e.g. prime contractor, subawardee(s), consultant(s)),

· Milestone events including tests/demonstration events, product deliveries, and significant meetings (e.g. design and in-progress reviews for transition partners) within each phase,

· Schedule-dependent correlations and task interrelationships, including any external dependencies (as previously

· defined), and

· Project Management activities/milestones (including periodic reporting requirements/deliverables).

In addition, the offeror shall identify/include three key types of meetings significant in executing the project:

· Post Award Conference. A Government’s Contracting Officer representative will conduct a contract overview shortly after award. The contracting representative for the offeror must attend this contract compliance discussion, which may either be via teleconference or at the offeror’s location. The offeror shall identify this as a Post Award Conference. The purpose of this meeting is to ensure a clear and mutual understanding of all contract requirements. This meeting may coincide with the EA’s project “kickoff meeting”, to be conducted within a month after award. The purpose of the “kickoff meeting” is to more fully understand the offeror’s intended plan of action, to clarify the EA’s expectations for project communications and deliverables and to identify and resolve any potential problems.

· Phase Decision Meeting. The offeror shall identify a Phase Decision Meeting to be conducted 30-45 days prior to the end of every phase, except for the last phase which has a Close-out Meeting. The purpose of the phase decision meeting is to provide the Government adequate time to evaluate project status and determine its decision, such as exercising the next contract phase, before the end of the period of performance of the current phase.

· Close-out Meeting. The offeror shall identify one Close-out Meeting to be conducted prior to the end of the project, to ensure its successful transition of technology and finalization. Finalization includes 1) ensuring all deliveries are accepted in accordance with the SOW and associated logistic and management closeout activities(e.g. Contract Data Requirements List (DD Form 1423) items, 2) preparing, submitting, and distributing the Material Inspection and Receiving Reports (DD Form 250) for final acceptance of deliverables and Project Final Report, and 3) determining the disposition (via either DD Form 250 or left for DCMA resolution) of excess Contractor Acquired Property (CAP) (not identified as a specified end-item deliverable), assigned Government-owned property, and patents (and related applications)).

The Government uses the aforementioned, among other content, in considering technical merit.

SECTION 8: Qualifications The offeror shall address the following concerns:

Does the project team have necessary background or demonstrated expertise, facilities, and capabilities useful to execute this project?

The following content supports addressing this question:

The offeror shall provide a narrative of past and present experience (both technical and management) that involve work that addressed similar or analogous technical challenges. The offeror shall include any organizational experience, key personnel responsibilities and expertise (with concise summary of qualifications/accomplishments/ related work), special facilities, or unique capabilities relevant to the technology to be developed.

The Government uses the aforementioned, among other content, in considering technical merit.

SECTION 9: Project Team Organization and Commitments The offeror shall address the following concerns:

Is the project team effectively structured organizationally (including external teaming activities) to efficiently address required work elements in obtaining project goals?

The following content supports addressing this question:

The offeror shall outline the intended organizational means to conduct the proposed technology development effort. The offeror shall include any pertinent or useful information, but, at a minimum, the offeror shall include the following:

· organization chart(s) with all personnel/labor enumerated in the direct labor section of the cost proposal, including prime offeror and any subcontractors/consultants,

· description of key collaborations, teaming arrangements and/or subcontractor/consultant arrangements with rationale for choices made, as well as justifications for any partnerships with Government agencies (established via MIPR funding arranged through the EA or a CRADA),

· amplification of the above by providing:

· identification of a single overall Project Manager, and

· identification of a Principal Investigator for each major work effort in the project.

· program management functions and activities including:

· description of reporting requirements, frequency, and method for Principal Investigator reporting to the Project Manager;

· description of reporting requirements, frequency, and method for the Project Manager reporting to the T&E/S&T Executing Agent, which at a minimum, is monthly status reports, phase reports at the end of each phase, and presentation material (at the Executing Agent’s request); and

· location(s) where work will be performed.

NOTE: The offeror shall elaborate further on personnel management and technical team labor categories in the cost proposal, where task delineation/responsibilities/duties are to be discussed uniquely per proposed phases/milestones. The Government uses the aforementioned, among other content in considering technical merit.

SECTION 10: Data Rights The offeror shall address the following concern:

How significant would the impact be for future use of the technology if the Government does not retain full data rights (as a return on investment consideration)?

The following content supports addressing this question:

The offeror shall address the Government’s anticipated unlimited data rights, and if applicable, state whether there are any potential assertions to restrict use as discussed in the Intellectual Property Representations subsection under Enclosure 5 - Administrative and National Policy Requirements.

The offeror shall complete Attachment 4 - Data Rights Assertions to address the assertions for both non-commercial and commercial items, including those of offeror’s subcontractors or suppliers.

Assuming that Attachment 4 is properly completed, the comments in this section can be a short generalized summary providing contextual rationale.

The Government uses the aforementioned, among other content, in considering the offer’s level of importance to agency programs.

SECTION 11: Transition Potential (beyond the project scope) The offeror shall address the following concerns:

a. Upon successful completion of the project, what further TRL development would provide a feasible, beneficial, and lasting test capability?

b. Does continued investment for more robust operational use effectively address future obsolescence and appear as a feasible expenditure?

c. Can DoD test ranges/laboratories/facilities readily adopt the technology?

The following content supports addressing this question:

The offeror shall describe the general scope of work to mature the technology beyond TRL 6 to fully transition into a test capability. NOTE: any discussion of development beyond TRL 6 is beyond the scope of the proposed effort and is not to be addressed within the cost proposal. The offeror shall highlight any major engineering steps and address how the technology could be verified, validated, and accredited to support DoD T&E with an associated ROM cost estimate. The offeror shall assess the long-term outlook for the technology and discuss the projected obsolescence of the technology. If known, the offeror shall identify any major modifications, work efforts, or configuration changes necessary at existing DoD test facilities and ranges required to adopt the proposed technology. For example, a new telemetry transceiver that operates at a non-traditional frequency may require changes to an existing ground station at a test range. Another example, a new keystroke logging device that records each key typed during a test event may require the Universal Serial Bus (USB) port to be activated on the laptop for the logging device to collect data. The Government uses the aforementioned, among other content, in considering the offer’s level of importance to agency programs.

SECTION 12: Security and Classified Material If the proposed effort requires a security classification level above UNCLASSIFIED, the offeror shall provide the address where actual contract performance will be located, its associated Commercial And Government Entity (CAGE) code, and address of its associated Defense Security Service office. The offeror shall identify any security classification guide(s), as applicable. The offeror shall clearly identify the classification level of the proposed effort, any component(s) thereof, and any required access (e.g., a project may require access to classified information even when the deliverables of the project could be unclassified). The offeror must address any sensitive, but unclassified elements of the effort, including applicable Militarily Critical Technologies List (MCTL) and/or ITAR constraints, as well as, the appropriate Controlled Technical Information (CTI) DoD distribution statement and proprietary restrictions for release. The offeror must have the capability (e.g., cleared personnel, cleared facilities) to perform the effort at the required classification levels. If there are no known issues, so state. This information is not evaluated, but used to facilitate an understanding of project security requirements for award and contract execution related activities.

SECTION 13: Government Furnished Property The offeror shall identify and justify any proposed use of Government Furnished Property (GFP). If the offeror is not proposing to use GFP, the offeror shall mark this section as “Not Applicable”. This information is not evaluated, but used to facilitate an understanding of necessary project logistics for award and contract execution related activities.

APPENDIX: Table of Abbreviations, Acronyms, and Initialisms While the table is appended to the technical proposal, the content in the Appendix is NOT included in Volume I page count.

The offeror shall provide an appendix containing a table defining all abbreviations, acronyms, and initialisms used in the technical proposal, if any, with the list in alphabetical order.

Project Quad Chart Instructions The offeror shall provide a project quad chart in the format provided as an attachment to the BAA posting. The offeror shall not submit quad charts as image files that are locked and not editable. The offeror shall not use any font smaller than size 7 on the project quad chart. Project quad chart content should address the following elements:

Project Quad Title: The offeror must include the full project title and the project acronym/initialism in the title section.

Project Description (Upper Left Quadrant): The offeror must provide a description of the project in the upper left quadrant, either in paragraph form or in a list of bullets. In addition, the offeror may include a small picture or a diagram if it helps describe the project. The purpose of this quadrant is to answer the question: “What is this project developing?”

Project T&E Need and S&T Challenge (Upper Right Quadrant): The offeror must provide a list of bullets defining the T&E Need and a list of bullets highlighting the S&T Challenge. In addition, the offeror must provide a list of significant deliverables at the completion of the project. The purpose of this quadrant is to answer the questions:

Project Plan (Lower Left Quadrant): The offeror must provide a list of bullets for each proposed phase that summarizes the major tasks of the phase. The purpose of this quadrant is to answer the question: “How is the technology going to be developed?”

Programmatic Information (Lower Right Quadrant): The offeror must identify the prime performer and all key subcontractors, including their location. In addition, the offeror shall complete the phase information table including POP (in months), TRL advancement, funding proposed from the T&E/S&T Program, and funding from a source other than the T&E/S&T Program. Lastly, if any potential transition partners have been identified, the offeror should list them at the bottom of this quadrant. The purpose of this quadrant is to answer the questions:

“Who is performing the work?”

“How long is the work estimated to take?”

“How much is the work estimated to cost?” and “Which T&E organizations could benefit from this technology?”

Volume 2: DRAFT Statement of Work (SOW) Document Instructions The draft SOW has no page limitations, but should be focused on addressing required content with brevity. File naming convention shall follow that of Volume 1 as below:

· Format: Portable Document Format (.pdf)

· Naming convention suffix abbreviation: 2SOW Offerors shall use Attachment 8 – Draft SOW Template to prepare the technical content for a SOW submission aligned with the technical proposal. Note that the Draft SOW document shall also include contractually-required administrative items of scope that are pre-populated in the template.

VOLUME 3: Cost Proposal and Related Document Instructions Cost Proposal File naming conventions shall follow that of Volume 1. The offeror shall carefully and diligently adhere to all cost proposal preparation specifications using the following documents, if/when a Request for Proposal is made:

1) Attachment 10 - Cost Volume Template (3CV) (no page limit restrictions)

· Format: Portable Document Format (.pdf)

· Naming convention suffix abbreviation: 3CV

2) Attachment 11 - Cost Proposal Workbook (3CWB) (no page limit restrictions)

· Format: Office Open XML Workbook (.xlsx)

· Naming convention suffix abbreviation: 3CWB

3) Contractor Cost Narrative document (limited to 10 pages): This is an Offeror generated document, and no template is provided. In this narrative, the contractor shall provide a narrative explanation of the proposed costs, by cost element, and include the Basis of Estimate (see Attachment 12 – Basis of Estimate Desk Guide) for each cost element. Both the offeror narrative and accompanying basis of estimate must provide sufficient detail that the Government can understand the reasoning and rationale that support the Offeror’s proposed cost, and can make a qualitative determination that proposed costs are appropriate for the work proposed, and that the proposed costs are fair and reasonable. Such cost elements generally include, but are not limited to:

· Labor

· Fringe

· Overhead

·…