RFP_Attachment_5_-_Section_L_-_Instructions,_Conditions,_and_Notices_to_Offerors_or_Respondents.pdf

FA8770-20-R-0004

RFP Attachment 5: Section L

FOR OFFICIAL USE ONLY (FOUO)

Section L

Instructions, Conditions, and Notices to Offerors or Respondents

1. PROGRAM INFORMATION

The Item Master Logistics Capability Initiative (IMLCI) provides the Air Force (AF) enterprise with a capability to generate and manage comprehensive, accurate, and reliable item specific data within the AF Logistics enterprise. It will provide enterprise users with the breadth and depth of accurate item data necessary to support and enable dependent processes, initiatives, programs and transformational concepts. Item Master provides the following capabilities: Item Standardization, Item Configuration Management, and Single Authoritative Source. Refer to Technical Data Package (TDP) (RFP Attachment 4) Sections 2 and 3 for more details.

2. GENERAL INSTRUCTIONS

Solicitation FA8770-20-R-0004 consists of a Gate and a Full Proposal Submittal:

1) Gate: Information Technology Functional Requirements (ITFR) Capability Assertion List

2) Full Proposal: Product, Services, and Price

The Gate will consist of all interested Offerors submitting a fully completed Item Master Logistics Capability Initiative (IMLCI) ITFR Capability Assertion List (RFP Attachment 2). The Government has pre-determined a minimum score that interested offerors must meet before submitting the full proposal. The pre-determined minimum score is documented in the IMLCI Source Selection Plan (SSP) but will not be released to offerors until after the due date of Gate submissions. The Government will not validate each assertion submitted by the offeror, but will enforce compliance with the submitted assertions in accordance with the contract terms and conditions (See RFP Attachment 12, Section H, Special Contract Requirement H002).

2.1 POINT OF CONTACT (POC)

The Procurement Contracting Officer (PCO) is the sole point of contact for this acquisition.

Offerors shall address any questions or concerns they may have to the PCO. Written requests for clarification may be emailed to the PCO and Contract Specialist at the address listed below:

Procurement Contracting Officer (PCO) Contract Specialist Attn: Zach Huffman Attn: Brock Moon Telephone: (937) 257-5139 Telephone: (937) 257-7440 zachary.huffman.2@us.af.mil brock.moon@us.af.mil

Every effort will be made to respond to requests for clarification in as timely a manner as possible.

However, in order to guarantee a response, the clarification request must be received no later than 1 week prior to the Gate due date and 2 weeks prior to the full proposal due date.

2.2 Discrepancies

If an offeror believes the requirements in these instructions contain an error, omission, or are otherwise unsound, the offeror shall immediately notify the PCO in writing with supporting

FOR OFFICIAL USE ONLY (FOUO)

rationale as well as the remedies the offeror is asking the PCO to consider as related to the omission or error.

2.3 Electronic Reference Documents

All referenced documents for this solicitation are available on the Federal Business Opportunities (FedBizOpps) website at https://www.fbo.gov/. Potential Offerors are encouraged to subscribe for real-time e-mail notifications when information has been posted to the website for this solicitation.

2.4 Communications

Exchanges of source selection information between Government and Offerors will be controlled by the PCO. Exchanges may include oral presentations, Evaluation Notices (written and oral), clarifications, communications, and/or discussions as defined in FAR 15.306. Email may be used to transmit such information to Offerors only if the email includes “Source Selection Information

– See FAR 2.101 & 3.104” in the Subject line. Source selection information may also be transmitted via the DoD SAFE website (https://safe.apps.mil/).

3. PROPOSAL PREPARATION INSTRUCTIONS

3.1 Gate - ITFR Capability Assertion List

In accordance with this solicitation, all interested Offerors shall return only the required Gate documentation electronically to the PCO and Contract Specialist (See Section 2.1) no later than the due date listed in the solicitation.

The ITFR Capability Assertion List provided during the Gate portion of this competition by the ultimate awardee shall be included as a contractually binding document at contract award.

Furthermore, Special Contract Requirement H002 (RFP Attachment 12, Section H) shall be in full force during the performance of the resultant IDIQ and orders.

The due date for Gate submissions will be no later than 1200 noon Eastern Standard Time (EST) on 10/25/2019.

3.1.1 Required Documents

The Offeror’s Gate proposal shall include only the following documents and information:

1) Company Information document containing only the following information (Page Limit: 1):

• Company Name and Address; CAGE Code; DUNS Number; Company Point of Contact (POC); Identification of all product(s) being proposed to satisfy ITFRs (shall remain unchanged in accordance with RFP Attachment 12, Section H Special Contract Requirement, H004)

2) The completed ITFR Capability Assertion List (RFP Attachment 2).

3.1.2 ITFR Capability Assertion List Specific Instructions

The offeror shall completely fill out column F on the “ITFR Score Sheet” tab of the IMLCI ITFR Capability Assertion List (RFP Attachment 2). The offeror will assert the functional capability of the proposed software solution by selecting the option that communicates the solutions capability to building the Item Master solution.

1) Fill out every line item; incomplete responses will be considered non-responsive.

2) Select one of the following four options for each ITFR ID. If an ITFR requires more than one option to fully implement, then choose the lowest or most restrictive option. For example, if IM.ITFR.1.01.51 requires some OOTB, some SDK, and/or some Core Development (that the offeror agrees to do), then select “Core Development.”

• "Out-of-the-box (OOTB)": The requirement can be fulfilled with straightforward configuration. These configuration settings could be done by Integrated Program Office (IPO) and/or functional personnel.

• "SDK": The requirement can be fulfilled using the Software Development Kit (SDK). The setup, development, and execution could be done by a skilled practitioner within the IPO and/or functional personnel trained in the technology.

• "Core development": The requirement can be fulfilled with either new development or a major modification to the existing core product and should the offeror be selected for award the offeror agrees to make necessary changes. Note: If requested to submit a full proposal, the effort required to satisfy the Core Development assertion(s) should be mapped to the Offeror’s Price Volume.

• "Cannot accommodate": The requirement cannot be fulfilled by any means or the requirement can be fulfilled with either new development or a major modification to the existing product but offeror is unwilling to change the core product.

3.2 Full Proposal –Product, Services, and Price

The full proposal shall be clear, concise, and shall include sufficient detail for effective evaluation and for substantiating the validity of stated claims. The proposal should not simply rephrase or restate the Government's requirements but, rather, shall provide convincing rationale to address how the offeror intends to meet these requirements. Offerors shall assume the Government has no prior knowledge of their product or experience and will base its evaluation on the information presented in the Offeror’s proposal.

Elaborate brochures or documentation, binding, detailed art work, or other embellishments are unnecessary and are not desired.

The offeror shall make a clear statement in the Executive Summary of the proposal that the proposal is valid for a minimum of 180 days.

The due date for full proposal submission shall be determined/communicated by the PCO at the conclusion of the Gate. Offerors will receive 30 days from the date of notification to submit a full proposal.

Full proposals shall be delivered electronically to the PCO and Contract Specialist (See Section 2.1) no later than the due date that will be listed in the notification sent after the Gate.

FOR OFFICIAL USE ONLY (FOUO)

3.2.1 Proposal Organization & Page Limits

The offeror shall prepare the proposal as set forth in the Proposal Organization Table (Table 1 below). The titles and contents of the volumes shall be as defined in this table, all of which shall be within the required page limits as specified in Table 1. The contents of each proposal volume are described in the table below:

3.2.1.1 Page Limitations

Page limitations shall be treated as maximums. If exceeded, the excess pages will not be read or considered in the evaluation of the proposal. Page limitations may be placed on responses to Evaluation Notices (ENs). The specified page limits for EN responses will be identified in the letters forwarding the ENs to the Offerors. A page is defined as one face of a sheet of paper containing information and, therefore, when both sides of a sheet display printed material, it shall be counted as two pages. Each page shall be counted except for cover pages, tables of contents, tabs, and glossaries.

3.2.1.2 Page Size & Format

The proposal may contain written and visual material. It must be succinct, well written and presented in a clear straightforward manner.

The submission should be clearly indexed and logically assembled. Each volume should be clearly identified and should begin at the top of a page. All pages of each volume should be appropriately numbered and identified by the complete company name, date and solicitation number in the header and/or footer. Submissions shall conform to the following guidelines:

• Type Font: 12 point (Times New Roman)

• Orientation: Portrait

• Spacing: Single-spacing between lines of text

• Margins: 1.0 inches on all sides

• Page Size: 8.5” x 11” (exceptions for Graphics & Tables)

• Acronyms: Spell out all acronyms the first time when they are used. Additional pages shall be inserted following the proposal body to spell out acronyms, abbreviations and symbols that will not be included in the total page count.

• Language: English

• Format: MS Office 2010 Applications (i.e. Word, Excel, Project, PowerPoint) and Adobe

Acrobat X Pro.

• Graphics & Tables: 8 point, 10 pitch (Times New Roman). Tables and illustrations may use a reduced font size not less than 8-point and landscape orientation may be used. There

TABLE 1 - Proposal Organization

VOLUME VOLUME TITLE PAGE LIMITS

Volume 1 Executive Summary 5 pages Volume 2 Technical Part 1, Subfactors 1, 2, and 3 75 pages Technical Part 2, Subfactor 4 No limit Volume 3 Price No limit Volume 4 Contract Documentation/Other Business Documents No limit

FOR OFFICIAL USE ONLY (FOUO)

is no upper limit on text font size. Fonts inserted into graphics should not appear smaller than 8 point. Tables and illustrations must be complete and readable when printed on 11” x 17”.

3.2.2 Pricing Related Data

All pricing information shall only be addressed in Volume 3 – Price. The IMLCI Total Evaluated Price (TEP) Workbook (RFP Attachment 11) shall be utilized.

3.2.3 Indexing

Each volume shall contain a detailed table of contents to delineate the subparagraphs within that volume.

3.2.4 Glossary of Abbreviations and Acronyms

Each volume shall contain a glossary of all abbreviations and acronyms used, and with an explanation for each. Glossaries do not count against the page limitations for their respective volumes.

4. PROPOSAL ORGANIZATION

4.1 Gate

No further instructions are provided under this section for the Gate. Refer to Section 3.1 above.

4.2 Full Proposal – Product, Services, and Price

The full proposal shall be organized into four (4) separate volumes as illustrated in Table 1 above.

4.2.2 Volume 1 – Executive Summary

In the Executive Summary volume, the offeror shall provide the following information:

4.2.2.1 Narrative Summary

The narrative summary of the entire proposal shall be concise, to include addressing the significant risks, and highlighting any key or unique features, excluding price. The salient features should tie in with Section M (RFP Attachment 6) evaluation factors/subfactors. Any summary material presented here shall not be considered as meeting any of the requirements of the solicitation.

4.2.2.2 Table of Contents

Include a master table of contents of the entire proposal.

4.2.2.3 Specific Content

1) Names & Addresses: Offerors shall provide their company name and address and the names and addresses of all subcontractors.

2) CAGE Codes: Offerors shall provide their CAGE code and CAGE codes for all subcontractors.

3) DUNS numbers: Offerors shall provide their DUNS number and DUNS numbers for all subcontractors.

FOR OFFICIAL USE ONLY (FOUO)

4) Affirmative Statement: Offerors shall provide an affirmative statement that their company fully understands the objectives specified in the Statement of Objectives (SOO) and the offeror Statement of Works (SOWs) is contractually enforceable, in accordance with all federal regulations, and accomplishes all Government objectives.

5) Exceptions: Offerors shall provide a statement that their company does or does not take exception to any of the solicitation requirements, including terms and conditions, representations and certifications, and technical requirements. In the event that an offeror takes exception, the exception should be provided in accordance with Paragraph 5.2 - Exceptions to Solicitation Requirements.

6) Authorized offeror Personnel: Offerors shall provide the name, title and telephone number of the company and/or division point of contact regarding decisions made with respect to your proposal and who can obligate your company contractually.

Also, identify those individuals authorized to negotiate with the Government.

7) Defense Contract Management Agency (DCMA) Administration Office: Offerors shall provide the contact information for the DCMA office responsible for administering Department of Defense (DoD) contracts awarded to their company.

8) Defense Contract Audit Agency (DCAA) Office: Offerors shall provide the contact information for the DCAA office responsible completing defense audits of their company.

4.2.3 Volume 2 – Technical

4.2.3.1 General

The Technical Volume should be specific, complete, and clear. Offeror responses will be evaluated against the Technical subfactors defined in Section M, Evaluation Factors for Award (RFP Attachment 6). Using the instructions provided below, provide as specifically as possible the actual methodology you would use for accomplishing/satisfying these subfactors. All the requirements specified in the solicitation are mandatory. By your proposal submission, you are representing that your company will contractually satisfy all the requirements specified in the solicitation. Do not merely reiterate the objectives or reformulate the requirements specified in the solicitation.

4.2.3.2 Format and Specific Content

1) Volume II – Technical

i. Subfactor 1 – Product Description

ii. Subfactor 2 – Cybersecurity and Lifecycle Support

iii. Subfactor 3 – Architecture, Integration/Interoperability, and System

Maintenance

iv. Subfactor 4 – Product Evaluation

4.2.3.3 Technical

In the technical volume, address your technical solution for meeting the Government’s performance or capability requirements of each technical subfactor.

4.2.3.4 Technical Risk

Address Technical Risk associated with those aspects of your proposed technical approach you consider to have the potential for disruption of schedule, increased costs, degradation of performance, the need for increased Government oversight, or the likelihood of unsuccessful contract performance. Classify each risk in accordance with Table 3, Technical Risk Rating, of Section M (RFP Attachment 6). Provide the rationale for each risk and its rating, including quantitative estimates of the impact on cost, schedule, and performance. Describe the impact of each identified risk in terms of its potential to interfere with or prevent the successful accomplishment of other contract requirements, whether or not those requirements are identified as subfactors. Propose a realistic mitigation plan for identified risks that will eliminate or reduce risk to an acceptable level. Identify and classify any new risks introduced by such risk mitigation.

Solicitation Risk Matrix and Mitigation Plan do not count against the page limitations.

4.2.4 Technical Volume Organization

The Technical Volume shall be organized according to the following general outline:

1) Table of Contents

2) List of Tables and Drawings

3) Part 1 - Subfactors 1, 2, and 3

4) Part 2 - Subfactor 4

5) Risk Matrix and Mitigation Plan

6) Glossary

4.2.4.1 Subfactor 1 – Product Description

The Offeror shall describe how their proposed product (SOO, RFP Attachment 1, Para 2.1) meets and/or exceeds the Item Master Functional Requirements. The response shall include the following information:

• Offeror’s Out of the Box (OOTB) capability;

• Offeror’s Software Development Kit (SDK) capability to include the languages and skillsets required;

• Work necessary to bring the product capability up to the required functional baseline (Core

Development);

• Offeror’s explanation of any “cannot accommodate” assertion to the ITFR Capability

Assertion List (RFP Attachment 2) as submitted during the Gate.

• A product roadmap identifying the strategic plan, release schedule, and required milestones necessary to produce the capability; and

• All descriptions shall clearly distinguish, by role, work required of the host, IPO, and

Offeror to ensure successful implementation of the product(s).

4.2.4.2 Subfactor 2 –Cybersecurity and Lifecycle Support

The Offeror shall describe how their product meets and/or exceeds the Cybersecurity and Lifecycle Support, Test, Release Management and Hosting objectives identified in SOO paragraphs 2.2 and

2.3 (RFP Attachment 1). The response shall include the following information:

FOR OFFICIAL USE ONLY (FOUO)

• Active product security certifications, such as current National Information Assurance Partnership (NIAP) certification(s) and/or current authority to operate (ATO); OR a task level plan and schedule to meet product security requirements if not certified;

• Product cybersecurity diagnostic and monitoring capabilities, including data, tool and utility usage, and integration services;

• Approach to automated testing, including a description of each test phase and environment, recommended automated testing tools and utilities, and test artifacts that will be shared with the IPO;

• Approach to automating software releases, including a description of requirements by environment, recommended tools and utilities for ensuring configuration control of the product (source and object code), and release artifacts that will be shared with the IPO;

• Approach to integration with hosting services, including what is required to configure and/or reconfigure the core product to meet hosting requirements, Application CI/CD pipeline management, containerization, virtualization, infrastructure expansion, and integration with platform integration services (identify management, interface integration, database management, etc.); recommended hosting tools and utilities, and available artifacts;

• Recommended plan and schedule to meet cybersecurity, testing, release and hosting objectives.

4.2.4.3 Subfactor 3 –Architecture, Integration/Interoperability, and System Maintenance The Offeror shall describe how the product meets and/or exceeds the Architecture, Integration, Interoperability, and Maintainability and Scalability objectives in SOO paragraph 2.1 (RFP Attachment 1) and the Requirements List (RFP Attachment 3) “IM LSR” tab. The response shall address the following information:

• How and where the product leverages industry best practices regarding the use of open architectural standards and open source utilities in a pipeline by describing the technology stack, server and storage requirements, and technical configuration options; itemizing the components and modules required to implement the IMLCI solution (i.e., installation package and corresponding product description); identifying product network port and protocol requirements and options; explaining how the product can be configured and/or decoupled to work with USAF-owned micro-services and other operational USAF systems; and providing an application topology;

• How the product handles data collection, transform and load capabilities for both initial loads and recurring exchanges; explain available open APIs; identify all one-time components needed to load data; addressing data duplication prevention, error handling, data quality/data integrity options, data business rule management, data security, data encryption, and storage options; identify how the data architecture supports synchronization with other operational USAF systems; and provide data mapping options that explain how the Offeror’s product attributes will be aligned with and mapped to the USAF business requirements and IMLCI data model;

• How ongoing vendor upgrades, changes, patches and enhancements are kept compatible with existing capability (both in work and in production); explain the version control policies and options with respect to code management; describe the product lifecycle retirement policy with respect to end of life support for in-use OOTB and SDK features;

FOR OFFICIAL USE ONLY (FOUO)

and provide a plan that identifies how the government will be assured of utilizing the most recent product components and configurations at all times;

• How the product scales by adding capacity at each layer of the technology stack (database, application, web servers, other); provide a scalability plan that explains how to scale the product; discuss, lead time preparation, prerequisites and configuration options, criteria for making scalability adjustments, risks and required tools and utilities; include a description of how to handle production surges in regards to annual price updates, temporary increases in the user base to support a mission need; and surges in transaction volume due to emergent business needs; and explain how new features/components are added without deprecating existing functionality.

4.2.4.4 Subfactor 4 – Product Evaluation

The Offeror shall prepare an operational business architecture in the form of a website that provides the requirements and corresponding end user guides to support a hands-on product evaluation by the Source Selection Team.

The intent is for the Offeror to leverage their OOTB-configured product to enable the Air Force to evaluate the capabilities cited in Paragraph 3 below. The Offeror is not expected to configure to the IMLCI data model or every ITFR. Additional information describing the IMLCI solution and business context can be found in the TDP (RFP Attachment 4).

The website and responses shall include, but are not limited to, product functionality and corresponding documentation that enable the Source Selection Team to execute the capabilities cited herein:

1) General Site Instructions:

• Provide a secure URL compatible with the Air Force Standard Desktop Configuration (SDC) identified in Section 5.5 of the TDP (RFP Attachment 4); product evaluation sites that are incompatible with the SDC will not be evaluated;

• Provide a Version Control Document and change log of the product submitted for evaluation; last modified date must be the same as or earlier than the full proposal submission date;

• Provide audit logs at the end of the evaluation period demonstrating the site has not been modified by the Offeror after submission of the full proposal or as otherwise directed by the Government;

• Ensure the unaltered Product Evaluation website is available until notification from the Contracting Office;

• Provide an installation guide that identifies the steps taken and components used to prepare the product evaluation site;

• The configured site shall be based on the Offeror’s core product as identified in the Offeror’s licensing terms and agreements;

• The Offeror can pre-populate their site with content of their choosing.

2) Specific Instructions:

• Provide a minimum of two (2) unique user accounts for each role associated with the product evaluation;

• Provide login instructions for each configured role;

FOR OFFICIAL USE ONLY (FOUO)

• Populate the website with data prepared by the Offeror in sufficient detail to demonstrate each capability; the Offeror can create and pre-populate as many data structures as necessary to enable the desired capabilities;

• Provide the government with a user guide that explains how to create and manage (change) items, workflows, business rules, reference data, roles, and exchanges.

• Provide the government with test data for use during the product evaluation;

• Provide the government with instructions for adding its own data to the site in accordance with the user guides;

3) Detailed Product Capabilities:

• Provide the capability to manage Assistance Request (AR) Templates;

• Provide the capability to manage the following items using ARs: Parts, Product Structures, Customers, Vendors, and Warranties;

• Provide the capability to link Part to Product Structures, Customers, Vendors and

Warranties;

• Provide the capability to add new attributes to existing Items;

• Provide the capability to manage simple, compound and complex business rules (See RFP

Attachment 8, Product Evaluation Supplement)

• Provide the capability to associate business rules to the user interface and exchange framework

• Provide the ability to manage reference data attribute names and definitions (RFP

Attachment 8 - Product Eval Supplement)

• Provide the ability to manage serial, parallel and complex workflows

• Provide the ability to manage User Profiles and Roles,

• Assign organizations, as opposed to individuals, to roles

• Provide the ability to search all item types, ARs; describe all advanced search options

• Provide the capability to manage interface integrations using the Offeror’s exchange framework (See RFP Attachment 8, Product Evaluation Supplement) to allow the Source Selection Team to complete the following:

a. Create new interfaces (3 inbound and 3 outbound)

b. Update an existing interface by changing a data element (name, structure, and/or length)

c. Update an existing interface by adding a data element

d. Import and Export test data (stubbed data load);

e. Test business rules and error handling against stubbed data loads in accordance with the Offeror’s instructions.

4.3 Volume 3 –Price

Volume 3 – Price shall consist of a narrative document and a completed Total Evaluated Price (TEP) Workbook (RFP Attachment 11). These instructions are to assist the Offeror in developing and presenting the information required to support the Price proposal. Proper presentation and adequate supporting documentation shall ensure that the Price proposal is evaluated fairly and that the Government is able to understand all assumptions concerning the Price presented in the proposal. The burden of proof for Price credibility rests with the Offeror. Any Price information

FOR OFFICIAL USE ONLY (FOUO)

not submitted in the Price proposal volume shall not be evaluated. All pricing information shall be addressed only in the Price Proposal.

4.3.1 General Instructions

1) The Price proposal shall be submitted in its entirety by the prime Offeror, although proprietary data to support fully burdened labor rates, may be submitted separately by the subcontractor to the PCO and Contract Specialist, via email to the address identified in Paragraph 2.1 if desired by individual subcontractors. Any data submitted separately by the subcontractor must be received by the PCO by the due date specified in the notification sent after the Gate. Compliance with these instructions is mandatory. Failure to comply may result in rejection of an Offeror’s proposal.

2) The Government price evaluation team will perform a price analysis to determine completeness, reasonableness, and balance. Per Section M (RFP Attachment 6), paragraph 2.2.2.4, the Government will calculate a Total Evaluated Price (TEP). The proposal shall demonstrate completeness, reasonableness, and balance.

3) The burden of proof for price credibility rests with the Offeror; therefore, the Offeror shall submit pricing information that is fully responsive to the requirement.

4) The period of performance for the basic IDIQ award shall be five (5) years from contract award.

5) Rounding – All proposed labor rates shall be rounded to the nearest penny. Overall proposed CLIN amounts shall be rounded to the nearest dollar.

4.3.1.1 Price Reasonableness and Balance

This section is to assist you in submitting data other than certified cost or pricing data that is required to evaluate the reasonableness and balance of your proposed Price. Compliance with these requirements are mandatory and failure to comply may result in rejection of your proposal.

Unbalanced pricing poses an unacceptable risk to the Government and may be a reason to reject an Offeror’s proposal. Offers should be sufficiently detailed to demonstrate their reasonableness and balance. The burden of proof for credibility of proposed prices rests with the Offeror.

4.3.1.2 Price Data

Data beyond that required by this instruction shall not be submitted, unless the Offeror considers it essential to document or support the price position. All data relating to the proposed price, including all required supporting documentation, must be included in the section of the proposal designated in the Price volume. Under no circumstances shall this data and documentation be included elsewhere in the proposal.

4.3.1.3 Cost or Pricing Data Requirements

Offerors shall submit pricing data using the TEP Workbook (RFP Attachment 11). Refer to Paragraph 4.3.3 below for further instructions.

FOR OFFICIAL USE ONLY (FOUO)

4.3.1.4 Volume Organization

The Price narrative shall consist of the following sections:

1) Section 1 – Table of Contents

2) Section 2 – General Information

3) Section 3 – Completed Total Evaluated Price (TEP) Workbook (RFP Attachment

11)

4.3.2 Total Evaluated Price (TEP) Workbook

Offerors shall populate the TEP Workbook (RFP Attachment 11) using the instructions provided in the TEP Workbook itself. The TEP will automatically populate in the second tab of the TEP Workbook, Tab A, Cell 19O. The Offeror is responsible for ensuring the total price reflects their proposal as shown in the submitted TEP Workbook. Offerors shall not modify embedded formulas within the TEP Workbook. If an error is found contact the PCO immediately.

5. Contract Documentation / Other Business Documents

5.1 Representations & Certifications

Offerors shall respond to all representations and certifications listed in Section K of the Model Contract (RFP Attachment 12).

5.2 Exceptions to Solicitation Requirements

Offerors are required to meet all solicitation requirements, such as terms and conditions, representations and certifications, and requirements, in addition to those identified as evaluation factors or subfactors. Offerors must clearly identify any exception to the solicitation terms and conditions and provide complete accompanying rationale. Each exception shall be specifically related to each paragraph and/or specific part of the solicitation to which the exception is taken.

Provide rationale in support of the exception and fully explain its impact, if any, on the performance, schedule, price, and specific requirements of the solicitation. This information shall be provided in the format and content of table below. The Government reserves the right to determine any such exception unacceptable. Any exception determined unacceptable by the Government may result in the Offeror’s proposal being determined unacceptable and ineligible for award.

Solicitation Exceptions Template

Solicitation Document

Page/ Paragraph

Requirement/ Portion Rationale

SOO, SOW, SPEC,

Model Contract, ITO, etc.

Applicable Page and Paragraph Numbers

Identify the requirement or portion to which exception is taken

Describe why the requirement can/will not be met

FOR OFFICIAL USE ONLY (FOUO)

5.3 Other Information Required

5.3.1 Attachments to the Model Contract

The Offeror shall provide the following as attachments to the model contract:

5.3.1.1 Associate Contractor Agreements

Include Associate Contractor Agreements (or Letters of Intent), if applicable.

5.3.1.2 Required Attachments

5.3.1.2.1 Statement of Works (SOWs) Basic IDIQ SOW and Delivery Order 01 SOW A Statement of Objectives (SOO) for the basic IDIQ and for Delivery Order 01 is provided as RFP Attachment 1. The SOOs represent the Government's minimum objectives for the IMLCI program. The Offeror shall use the SOOs to propose two separate Statement of Works (SOWs) (one for the basic IDIQ and one for Delivery Order 01) which expand upon these minimum objectives to the extent necessary to accomplish the requirements and objectives. The proposed SOWs shall define the tasks required to ensure all requirements of the Government provided SOOs have been addressed. The proposed SOWs shall not contain informational notes, as the Technical Volume provides ample opportunity for discussion and description of the Offeror’s approach. The proposed SOWs shall follow the same numbering convention as the Government SOOs. In addition, the proposed SOWs shall copy each section of the Government SOO and then place the proposed solution in “shall” statements below each Government SOO Section. The proposed SOWs, when accepted by the Government, will be put on contract at award. There are no page limitations to the SOWs.

5.3.1.2.2 ITFR Capability Assertion List

The offeror shall use RFP Attachment 2 to assert the functional capability of the proposed software solution. The offeror shall follow the instructions at paragraph 3.1.2 herein and the instructions in the attachment to properly assert the proposed solution’s capability. The completed attachment will be placed on contract should the offeror be selected for contract award. The offeror is hereby notified that, post contract award, failure of the delivered software to meet any assertion to the ITFR Capability Assertion List shall be subject to the assessment of liquidated damages as set forth in Special Contract Requirement H002 (See RFP Attachment 12, Section H).

5.3.1.2.3 Small Business Subcontracting Plan

The Offeror shall submit a Small Business Subcontracting Plan IAW FAR 52.219- 8, Utilization of Small Business Concerns; FAR 52.219-9, Small Business Subcontracting Plan (Alternate II);

DFARS 252.219-7003, Small Business; and AFFARS 5319.704, Subcontracting Plan Requirements. The Small Business Subcontracting Plan will be reviewed for responsibility. If the Offeror is a participant in the DoD Comprehensive Subcontracting Test Program specified in DFARS 252.219-7004, Small Business Subcontracting Plan (Test Program), the Offeror shall provide a copy of the approved comprehensive plan that shall suffice for its Small Business Subcontracting Plan. IAW FAR 52.219-9(c), failure to submit and negotiate a subcontracting plan acceptable to the PCO shall make the offer ineligible for award of a contract.