Chenega Agile Real-Time Solutions, LLC

Decision

Matter of: Chenega Agile Real-Time Solutions, LLC

File: B-423512

Date: July 31, 2025

DIGEST

1. Allegation that agency unreasonably evaluated protester’s technical proposal is denied where the evaluation was consistent with the solicitation and procurement law and regulation.

2. Allegation that offerors did not compete on an equal basis is denied where the record demonstrates that the protester’s proposal was evaluated against the announced evaluation criteria and not compared to the current Navy architecture, which was known only to the incumbent awardee.

Chenega Agile Real-Time Solutions, LLC (CARS), of Lorton, Virginia, protests the award of a contract to PCG-SMX JV, LLC, of Lexington Park, Maryland, under request for proposals (RFP) No. N0042124R0009, issued by the Department of the Navy for information technology (IT) enterprise engineering, operations, and hosting support services (EEOHSS). CARS asserts that the agency unreasonably evaluated the protester’s technical proposal and that offerors competed on an unequal basis.

We deny the protest.

BACKGROUND

The Navy requires a contractor with the skills and experience to provide enterprise-wide applications, server, storage, data protection/recovery, data transport, and data environment engineering, operations, and hosting support services. Agency Report (AR), Tab 1, RFP at 36. Requirements include planning, engineering/design, acquiring, provisioning, operating, administering, troubleshooting, repairing, and managing all aspects of the Naval Air Systems Command’s (NAVAIR’s) centrally and remotely located IT solutions managed by the Naval Air Warfare Center Aircraft Division Digital Network & Applications (DNA) Department. Id.

To procure these services, the agency issued this solicitation--a small business set-aside--that contemplated the award of a single indefinite-delivery, indefinite-quantity contract with a 5-year base ordering period and an optional 2-year ordering period; the contract would include cost-plus-fixed-fee, cost-reimbursement, and fixed-price contract line items. Id. at 2. The agency would award the contract to the responsible offeror whose proposal represented the best value to the agency, considering technical and past performance factors and cost/price. Id. at 144. The technical factor contained two elements--management and resources, and understanding of the requirements (sample task); the management and resources element was more important. Id. The technical and past performance factors, when combined, were significantly more important than cost/price. Id.

Under the management and resourcing element of the technical factor, the agency would assess: the offeror’s understanding and ability to manage the basic contract and task orders effectively; how the offeror would monitor and manage performance quality; the offeror’s ability to provide and maintain qualified personnel; the approaches, methods, processes, and tools the offeror would utilize in performance to support the current and emerging IT/cyber environments; and the risk associated with the proposed teaming structure, including whether the team structure had been used before. Id. at 145-146. Under the understanding of the requirements (sample task) element, the agency would evaluate the offeror’s response to the RFP’s sample task to assess the offeror’s understanding and capability to perform the requirements, the ability to effectively plan and manage the representative requirement, the ability to introduce innovative approaches in supplying IT solutions, and the offeror’s understanding of the associated risks, skills, and resources required. Id. at 146. The agency would assign proposals a rating of outstanding, good, acceptable, marginal, or unacceptable under the technical factor. Id. at 149-150.

Under the past performance factor, the RFP required offerors to submit no more than five contract references. Id. at 129. Offerors were required to provide “electronic copies of the complete final versions of the [statement of work(SOW)/[performance work statement (PWS)] or other supporting solicitation/contract documentation from each contract or delivery/task order reference.” Id. at 129-130. The RFP provided that “[t]he burden of providing thorough and complete past performance and systemic improvement information remains with the Offeror.” Id. at 131.

The solicitation established a two-step evaluation for past performance. RFP at 146. First, the government would determine which contracts were recent and relevant. Id. (Recency determinations are not at issue in this protest.) To determine relevancy, the Navy would consider contract references (CRs) under three categories--technical scope, complexity, and magnitude--and would assign a relevancy rating of very relevant, relevant, somewhat relevant, or not relevant to each category. Id. The Navy would then determine the overall relevancy rating for the CR, which would be “the lowest relevancy rating achieved based on the assessment of Scope, Complexity, and Magnitude.” Id. For example, the RFP explained that, if the Navy evaluated a CR as very relevant for technical scope, very relevant for complexity, and somewhat relevant for magnitude, the reference’s relevancy rating would be somewhat relevant--the lowest of the three relevancy ratings. Id. at 146. The solicitation advised offerors that only CRs that received an overall rating of very relevant, relevant, or somewhat relevant would be further considered in the past performance evaluation. Id.

Second, the Navy would evaluate how the offeror performed on each of the very relevant, relevant, or somewhat relevant contracts. Id. Based on an integrated consideration of all performance areas for those contract references, the Navy would assign a “Performance Confidence Assessment Rating” of substantial confidence, satisfactory confidence, neutral confidence, limited confidence, or no confidence.[1] Id. at 147, 150-151.

Five firms, including the protester and awardee, which is the incumbent provider for a portion of the requirement, submitted timely offers. Contracting Officer’s Statement and Memorandum of Law (COS/MOL) at 3. Under the technical factor, the agency assessed CARS’s proposal no significant strengths, one strength, five weaknesses, one significant weakness, and no deficiencies and assigned the proposal a technical/risk rating of marginal.[2] AR, Tab 5, CARS Source Selection Evaluation Board (SSEB) Report at 23. The significant weakness resulted from three related weaknesses. Id. at 27. The table below summarizes the SSEB evaluation of the proposals of CARS and PCG-SMX:

Factor	Offeror
	CARS	PCG-SMX
Technical/Risk Rating	Marginal	Outstanding
Past Performance	Satisfactory Confidence	Substantial Confidence
Total Evaluated Price	$791,782,530	$868,984,167

 

AR, Tab 4, SSEB Brief to Source Selection Advisory Council at 54.

The source selection authority (SSA) determined that the benefits of PCG-SMX’s proposal merited the price premium. AR, Tab 7, Source Selection Decision (SSD) at 5. The SSA explained that, although CARS’s total evaluated price was approximately 8.9 percent less than PCG-SMX’s, PCG-SMX’s proposal had a significant advantage under the technical factor and an advantage under the past performance factor, which, combined, were significantly more important than cost/price. Id. The SSA selected PCG-SMX for contract award, id. at 6, and this protest followed.

DISCUSSION

CARS asserts that the Navy unreasonably assessed the protester’s proposal the significant weakness and five weaknesses, failed to assign its proposal several strengths, and unreasonably evaluated past performance. The protester also contends that the offerors did not compete on a level basis. As explained below, we find no merit to these allegations.[3] We first address the protester’s complaints pertaining to the significant weakness.

Challenge to Significant Weakness

The Navy assessed CARS’s proposal a significant weakness under the understanding of the requirements (sample task) element of the technical factor because the protester’s description of its proposed architecture/design lacked sufficient content and detail for the Navy to clearly understand CARS’s proposed approach to the sample task. AR, Tab 5, CARS SSEB Report at 26. Three weaknesses contributed to the assessment of this significant weakness. See id. at 17-18. CARSs challenges the assessment of those three weaknesses.

In reviewing a protest challenging an agency’s evaluation of proposals, our Office will not re-evaluate proposals or substitute our judgment for that of the agency. ACC Constr. Co., Inc., B-420801, Sept. 2, 2022, 2022 CPD ¶ 216 at 4. The evaluation of proposals is generally a matter within the agency’s discretion. Id. Our Office examines the record to determine whether the agency’s judgment was reasonable and in accord with the evaluation factors set forth in the RFP. Id. A protester’s disagreement with the agency’s evaluation, without more, does not establish that the agency acted unreasonably. Id.

Weakness 1 of 3--Architecture and Design Description

The significant weakness that the Navy assessed CARS’s proposal was under the understanding of the requirements (sample task) element of the technical factor. In setting out the sample task, the RFP advised offerors that DNA would soon be embarking on efforts to migrate significant segments of its on-premises hosting and service offerings into various cloud service providers (CSP) in order to satisfy Department of Defense (DOD) mandates. RFP at 128. One area of particular interest, the agency explained, involves the analysis of a network and operating environment consisting of roughly twenty geographically dispersed enclaves. Id. Using certain assumptions, the offeror was to describe the criteria and approach it would use to determine which application types, services, and workloads can and should move to a CSP only architecture, a hybrid-cloud architecture, or remain on premises. Id. at 128‑129.

Offerors were to provide an end-state design architecture that is technically viable and to justify the design by comparing it with other feasible design architectures. Id. at 129. Offerors were to comprise a deployment, data migration, and scheduling plan for the example application types, services, or workloads involved, including any potential challenges to the identification, analysis, planning, deployment, and migration phases of this effort. Id. The RFP advised offerors it was critical that the response show understanding of the current DOD/Navy cloud environment, including, for example, how policy and required oversight by external entities shape and limit design. Id. Responses were also required to consider how DOD/Navy mandates, such as those regarding security, enterprise solution use/integration, contract use, and the like influence proposed design. Id.

In assessing the first weakness, the evaluators found that, rather than provide a rationale for its proposed architecture, CARS’s proposal “highlighted the main attributes within a Secure Cloud Computing Architecture (SCCA) in its architecture narrative description.” AR, Tab 5, CARS SSEB Report at 19. The Navy noted that “the construct of a SCCA was mentioned in the architectural assumptions provided to the Offeror within the Sample Task.” Id., citing RFP at 7 (“A cloud agnostic Secure Cloud Computing Architecture (SCCA) already exists in one [cloud service provider], and that basic, but not robust, network topography exists between the geographic enclaves and the SCCA.”). CARS’s architecture design included [DELETED]. AR, Tab 2, CARS Technical Proposal at 37. Because the protester’s proposal did not elaborate on how it would incorporate the [DELETED] components into the existing SCCA or describe what roles those new elements would play in CARS’s design, the technical evaluation team (TET) assessed the protester’s proposal a weakness for the lack of content and clarity of the offeror’s architecture/design--a flaw that increases the risk of unsuccessful contract performance. AR, Tab 5, CARS SSEB Report at 17.

CARS asserts it clearly described [DELETED] in its proposal at paragraph 2.2.6.1 and disclosed their roles in the design of the architecture in an accompanying figure. Protest at 31. CARS’s proposal states: “[DELETED], provides the data centric security for all the cloud services. The [DELETED] hosts the cloud management and security tools.” AR, Tab 2, CARS Technical Proposal at 37. The accompanying figure 16 contains a schematic diagram showing [DELETED] and various other components of CARS’s proposed architecture. See id. at 38. While CARS claims that the Navy ignored this brief discussion of the [DELETED], the evaluation makes mention of both and faults the protester’s proposal for not explaining how the components would be incorporated into the architecture or what roles they would play in the design. See AR, Tab 5, CARS SSEB Report at 26. Given that the proposal’s treatment of [DELETED] consisted of two brief sentences and a schematic diagram--information the agency expressly considered and found to be lacking in detail--the record fails to support the protester’s argument that the agency erred in assessing a weakness for CARS’s failure to provide a sufficiently detailed rationale for its proposed architecture.[4] Accordingly, this argument is denied. See Guidehouse Inc., B-422147, B‑422147.2, Jan. 25, 2024, 2024 CPD ¶ 39 at 16 n.12 (disagreement with agency conclusion that proposal lacks detail, without more, is not a basis to sustain the protest).

Weakness 2 of 3--Network Connectivity Approach

The Navy assessed CARS’s proposal the second of three weaknesses comprising the significant weakness for the protester’s “network connectivity approach,” which “[DELETED].” AR, Tab 5, CARS SSEB Report at 26. The agency found that the protester’s proposed approach “presented undue complexity as the geographically dispersed locations have direct network connectivity to the cloud currently and filtering that traffic through a single point of entry presents risk of a single point of failure during execution.” Id.

In challenging the agency’s evaluation, CARS asserts that, “[a]s instructed,” it “provided a ‘generic’ architecture that showed generic connectivity paths leading to the SCCA.” Comments at 21. If the agency had disclosed its existing architecture, CARS contends that it “could have made recommendations for network optimization.” Id. We note that, in challenging the agency’s evaluation, CARS never rebuts the agency’s conclusion that the protester’s proposed single point of failure represents high risk. See Protest at 31‑32; Comments at 21-22.

The Navy argues that the RFP advised offerors that they did not need to describe “bandwidth or connectivity between the geographic enclaves and the SCCA.” COS/MOL at 41, quoting RFP at 128. In this regard, the Navy further asserts that notwithstanding this instruction, which was “provided to all offerors,” the protester elected to describe that connectivity. COS/MOL at 43. Having provided the unsolicited information, however, the Navy contends that CARS’s proposal was not assessed a weakness for providing a “generic” response. Id. at 44. Rather, the agency maintains that CARS’s specific connectivity approach provided undue complexity and resulted in a high risk associated with the proposed single point of failure. Id. Such an approach, the Navy argues, “would be a high risk in any cloud landscape, whether CARS had any knowledge of the Agency’s cloud landscape or not.” Id. CARS does not contest the agency’s claim that, in proposing a certain type of connectivity, the protester ignored the RFP’s instruction to all offerors that their proposals were not required to address connectivity. See Protest at 31-32; Comments at 21-22. Because CARS does not challenge the agency’s determination that the protester’s proposed approach to connectivity increases risk, and because the RFP advised offerors that they were not required to address connectivity, the record provides no basis on which to find that the Navy unreasonably assessed a weakness. We deny this allegation.

Weakness 3 of 3--Architecture/Design Toolset

The Navy assessed the protester’s proposal the third of the three weaknesses for failing to effectively describe how CARS would use three “original detail” items within its supporting toolset. AR, Tab 5, CARS SSEB Report at 26. The evaluators found that, although CARS’s proposal contained a diagram depicting the three items within its supporting toolset, [DELETED], the offeror “did not describe that the concept of [DELETED] were specific to AWS [Amazon Web Services] and were not utilized with other cloud service providers.” Id., citing AR, Tab 2, CARS Technical Proposal at 38, figure 16. CARS contends that the agency indicated that the sample task was intended to be generic in nature and that the assessment of this weakness further demonstrates the agency’s “unlawful deviation from the disclosed evaluation scheme and criteria.” Id. at 31.

Throughout its challenge to the assessment of weaknesses, CARS reiterates that, although the agency requested only a generic response, the Navy evaluated the protester’s proposal against the existing Navy architecture, which was known only to the incumbent awardee. See Protest at 32-33. The protester also asserts this as a separate allegation. See id. at 44-45 (alleging that the agency failed to maintain a level field of competition). Because this was a separate allegation, we consider this assertion in detail below and find that it has no merit. We note, however, that CARS does not dispute that it failed to adequately describe how it would utilize its supporting toolset, nor did it challenge the Navy’s claim that the protester’s use of [DELETED] was unique to AWS, which CARS did not discuss. See id. at 32-33. As a result, we have no basis to question the reasonableness of this weakness.

In sum, the record provides no basis for sustaining the challenges to the three related weaknesses that, combined, constitute the significant weakness that the Navy assessed CARS’s proposal for a proposed architecture/design that lacked sufficient content and detail. See AR, Tab 5, CARS SSEB Report at 26. There is thus no basis for questioning the reasonableness of the assessment of that significant weakness, and this allegation is denied.

Challenge to other weaknesses

In addition to challenging the agency’s assignment of the significant weakness discussed above, the protester challenges each of the five weaknesses assigned to its proposal under the technical factor. We address each of the five below.

Weakness 1--Communication with Agency and Organizational Relationship Between CARS and Agency

The agency assessed the first weakness in the protester’s proposal under the management and resourcing element of the technical factor because CARS did not describe how its leadership would effectively communicate with the agency and did not describe the relationship between CARS’s leadership and the “Government’s team.” AR, Tab 5, CARS SSEB Report at 24. The evaluators found that CARS’s proposal lacked a description of “the communication flow and the organizational relationship between the Offeror’s [program manager (PM)]/CARS Chief Operating Officer and the Government Contracts or Leadership team.” Id.

CARS argues that the RFP did not disclose that the agency would evaluate lines of communication between the offeror and the government. Protest at 28-29. The agency first argues that the solicitation required proposals to include a description of “the team management structure, roles, responsibilities, chains of communications, process/action approvals, performance accountability, and if a similar teaming structure has been previously utilized.” COS/MOL at 20, quoting RFP at 127 (emphasis added by agency). This requirement, CARS asserts, pertains to the offeror’s team structure and not to the offeror’s relationship with the agency. Comments at 13. CARS reiterates that the RFP did not disclose “that [the Navy’s] evaluations would assess lines of communication between the offeror and the government.” Id.

While we agree with CARS that the requirement to provide a description of “chains of communication” pertained to the offeror’s team structure, we nevertheless find the evaluation reasonable. The Navy argues that the evaluation finding was reasonably encompassed by the provision of the RFP advising offerors that “[t]he Government will evaluate the Offeror’s proposed Management and Resourcing approach, to assess [ ] the Offeror’s understanding and ability to manage the basic contract and task orders effectively.’” COS/MOL at 20, quoting RFP at 145 (emphasis added by agency). It is well settled that an agency may evaluate proposals based on unidentified areas provided that the areas are reasonably related to, or encompassed by, the established factors. Sprezzatura Mgmt. Consulting, LLC, B-420858.2, Mar. 6, 2023, 2023 CPD ¶ 100 at 9.

Providing a description of the way in which CARS’s leadership would effectively communicate with the agency, as well as the relationship between CARS’s leadership and the agency’s, is reasonably related to the agency’s evaluation of the offeror’s ability to manage the basic contract and task orders effectively. Those communication channels and relationships are necessary for successful contract performance; CARS does not argue otherwise. See Protest at 28‑29; Comments at 12‑14. Because a description of the relationship between the leadership of the offeror and the agency--including their methods of communication--is reasonably related to an announced evaluation criterion, and because the protester does not contend that its proposal satisfied this requirement, we have no basis on which to sustain the challenge to the reasonableness of the assessment of this weakness.

Weakness 2--Managing Performance Across Multiple Locations

Under the management and resourcing element of the technical factor, the agency advised offerors that the Navy would evaluate how the offeror would monitor and manage performance quality. RFP at 145. The agency assessed CARS’s proposal a weakness under this element for failing to explain “its chain of command at remote sites.” AR, Tab 5, CARS SSEB Report at 24. The agency found that CARS’s proposal “did not describe how [team leads (TLs)] communicate performance issues to the Program Manager and/or the Offeror’s leadership team” and “does not describe the process TLs would use to report performance quality issues to the Offeror’s leadership or how TLs would be held accountable for quality concerns.” Id.

CARS argues that figures 2 and 4 and tables 2, 3, and 6 of the protester’s proposal meet the RFP requirement. CARS asserts that the figure 2 organizational chart “clearly shows direct reporting from [task order lead (TOL)] to PM.” Protest at 29, citing AR, Tab 2, CARS Technical Proposal at 6. CARS, however, does not contend that figure 2 contained a chain of command at remote sites or a description of how team leads communicate performance issues with the program manager. CARS also argues that “Figure 4 provides a list of items and interactions between Execute and Monitor & Control functions.” Protest at 29. Figure 4, titled “Team CARS’ Task Oder Method is a scalable and effective approach for [task order (TO)] management,” contains five columns, including two adjacent columns labeled execute and monitor & control. See AR, Tab 2, CARS Technical Proposal at 12. However, it is not clear from the figure--and CARS offers no supporting rationale--how this figure satisfies the RFP requirement in question. Specifically, figure 4 does not explain CARS’s chain of command at remote sites, describe how TLs communicate performance issues to the PM, or describe the process TLs would use to report performance quality issues to CARS’s leadership. See id.

The protester asserts that table 2 of its proposal “lists direct up and down reporting between the PM and TOLs.” Protest at 29, citing AR, Tab 2, CARS Technical Proposal at 7. Table 2 in fact shows that TOLs report to the PM. AR, Tab 2, CARS Technical Proposal at 7. The table does not explain how team leads, particularly those that are remote, communicate performance issues to the program manager. See id. CARS argues that table 3 lists forums in which the PM and TOLs participate in communicating performance. Protest at 29. Table 3 provides the following four communication “methods”: contract management team (CMT)[5]/DNA collaboration; program management review with DNA hosted by the PM; monthly risk management boards (RMB)[6] with DNA, hosted by the PM; and “[w]eekly status with DNA,” in which TOLs discuss task order progress. Id. at 8.

None of those four communication methods explains how TLs communicate performance issues to the PM or describe the process TLs would use to report quality issues to CARS’s leadership. CARS contends that its proposal “provides specific details on managing remote work including use of collaboration tools to engage staff across multiple locations.” Protest at 29, citing AR, Tab 2, CARS Technical Proposal at 15, Table 6. The evaluation recognized the “collaboration tools” that CARS would use “to engage staff across multiple locations.” AR, Tab 5, CARS SSEB Report at 24. In the agency’s view, however, a list of tools did not adequately describe how the TLs would report quality issues to the PM. See id. CARS contends that table 6 also provides “Daily Scrums to remain informed of TO performance.” Protest at 29, quoting AR, Tab 2, CARS Technical Proposal at 15. The proposal provides no details on the participants in or the specific content of the daily scrums. See AR, Tab 2, CARS Technical Proposal at 15.

In summary, CARS asserts that figures 2 and 4 and tables, 2, 3, and 6, refute the agency’s finding that the protester’s proposal fails to explain how TLs communicate performance issues to the PM or to describe the process TLs would use to report quality issues to CARS’s leadership. Those figures and tables provide a wealth of information on how CARS would perform the RFP’s requirements, but those figures and tables do not support a finding that the assessment of this weakness was unreasonable. We therefore deny this allegation.

Weakness 3--Workforce Training

Under the management and resourcing element of the technical factor, the RFP required proposals to “[d]escribe how the Offeror will ensure approaches, methods, processes and tools utilized in performance, support the current and emerging IT/Cyber Environments.” RFP at 128. The agency assessed the protester’s proposal the following weakness regarding training:

[T]he Offeror’s proposal lacked a detailed description of how the Offeror would train its staff to evaluate and adapt to new methods, processes, and tools. The Offeror did not describe how it would educate the employees on the methodologies proposed, which increases the risk that the Offeror could not execute the proposed methods and approaches. Additionally, the Offeror’s proposal did not describe how it would support emerging IT environments.

AR, Tab 5, CARS SSEB Report at 25.

CARS contends that the RFP did not contain “an approach to training as a topic for evaluation.” Protest at 30. The protester argues that “Offerors would have to be clairvoyant to anticipate that in response to RFP Section L., 2.1(v) they should include in their proposals a description of how it would train staff.” Comments at 17. Echoing the language of the RFP, CARS argues that “‘[t]raining” is not an ‘approach,’ ‘method,’ ‘process,’ or ‘tool’ ‘to be utilized in contract performance,’” and that “[t]raining, by definition, occurs before individuals are entrusted to support current and emerging IT/Cyber environments.” Id.

The solicitation required training facilities and contemplated the need for technical training. RFP at 43. The contractor was required to provide a facility that supports “training environment development.” Id. at 39. The RFP advised offerors that, “[d]ue to the technical nature of the work, there may be special, unique, and emergent training required during the execution of this contract.” Id. at 43. The RFP explained that “[t]his training may include, but is not limited to, specific software, hardware, and procedures as required for the specific system or requirements being supported.” Id. Some of that training could be cost-reimbursable. See id. As CARS notes, moreover, offerors “by definition” provide training so that personnel may support “current and emerging IT/Cyber environments.” Comments at 17. An agency may evaluate proposals based on unidentified areas provided that the areas are reasonably related to, or encompassed by, the announced evaluation factors. Sprezzatura Mgmt. Consulting, LLC, supra. The record supports a finding that training was reasonably related to and encompassed by the RFP requirement that offerors describe how they will ensure the approaches, methods, processes, and tools utilized in performance will support the current and “emerging IT/Cyber Environments.”

Regardless, the protester argues that its proposal satisfied that requirement. Protest at 30, citing AR, Tab 2, CARS Technical Proposal at 29 (paragraph 2.2.4). Section 2.2.4--Description of the Technical Approach and Methodology--covers seven pages of the protester’s proposal; no portion of that section provides a detailed description of how CARS would train its staff to evaluate and adapt to new methods, processes, and tools. See AR, Tab 2, CARS Technical Proposal at 29-36. CARS offers the bare assertion--without elaboration--that section 2.2.4 satisfies the requirement. Protest at 30. Section 2.2.4 addresses the understanding of the requirement (sample task) element of the technical factor, see AR, Tab 2, CARS Technical Proposal at 24 (noting that section 2.2 addresses that element), and this weakness was assessed under the management and resourcing element, addressed in section 2.1. See id. at 5. Even if section 2.2.4 addressed the requirement to provide training, the agency was not required to search the understanding of the requirement (sample task) element for information responsive to a requirement under the management and resourcing element. In this regard, an agency is not required to search other sections of an offeror’s proposal for information to meet requirements related to a different section. Dawson Sols., LLC, B-418587, B‑418587.2, June 19, 2020, 2020 CPD ¶ 216 at 6. For the above reasons, this allegation is denied.

Weakness 4--Implementation of Innovative Solutions

Under the understanding of the requirements (sample task) element of the technical factor, proposals were to demonstrate the offeror’s ability to introduce innovative approaches in supplying IT solutions. RFP at 146. Proposals were also to “offer an end-state design architecture that is technically viable” and to “[j]ustify the design by comparing and contrasting it with other feasible design architectures.” Id. at 129. The evaluators also determined that CARS’s proposal “did not clearly define the comparison of its proposed design to other cloud deployment strategies.” AR, Tab 5, CARS SSEB Report at 22. CARS contends that the RFP contained no such requirement. Comments at 18. The protester argues that its proposal met the RFP requirement because CARS’s proposal identified specific examples of alternate design areas. Comments at 18, citing AR, Tab 2, CARS Technical Proposal at 37, Appraisals Against Alternative Designs.

CARS’s proposal states:

2.2.6.2 Appraisals Against Alternative Designs

There are multiple design alternatives that are considered when developing an overarching Cloud Architecture. Initially, Team CARS designs the proposed architecture in accordance with the [DOD] CSP requirements to fully engage with commercial service providers. Some other items considered are preferring a [DELETED], if possible. [DELETED] is much preferred if the network bandwidth can support it. Many of our approach decisions include maintaining security at local enclaves vs. the cloud. Security is best managed in a [DELETED] to reduce the risk of security breaches and thus, implemented into our design.

AR, Tab 2, CARS Technical Proposal at 37.

The agency recognized that CARS’s proposal “highlighted a few alternatives for connectivity such as utilizing a [DELETED] solution or a [DELETED] solution.” AR, Tab 5, CARS SSEB Report at 22. In the evaluators’ view, however, the protester did not elaborate on the positive or negative attributes of either solution. Id. Similarly, the agency argues that CARS stated that, if feasible, [DELETED] was the preferred solution without stating why that was the case. Id., citing AR, Tab 2 CARS Technical Proposal at 37. The RFP required proposals to “offer an end-state design architecture that is technically viable” and to “[j]ustify the design by comparing and contrasting it with other feasible design architectures.” RFP at 129. Given that explicit RFP language, we see no merit to the protester’s assertion that the agency utilized an unstated evaluation criterion when assessing this weakness. The record supports the reasonableness of the agency’s evaluation, and this allegation is denied.[7]

Weakness 5--Understanding of the Associated Risks

The agency assessed CARS’s proposal a final weakness under the second element of the technical factor--understanding of the requirements (sample task). AR, Tab 5, CARS SSEB Report at 25-26. The evaluators noted that CARS’s proposal listed several DOD/Navy policy items that shape the cloud environment without specifying how those policies would shape the protester’s design. Id. at 26. The TET found that CARS was aware of the risks regarding DOD/Navy cloud policy, but the TET concluded that the protester’s proposal “did not show a clear understanding of how those risks affected its architecture/design.” Id.

CARS maintains that section 2.2.6.3 of its proposal--“How DoD/Navy Mandates Impact Proposed Design”--took into account DOD/Navy mandates regarding security, solution impacts, and uses in contracts and that the agency’s evaluation reflected as much. Protest at 35, citing AR, Tab 2, CARS Technical Proposal at 39; AR, Tab 5, CARS SSEB Report at 22 (noting that the protester’s proposal “did list several DoD/[Navy] policy items that do shape the cloud environment”). CARS further maintains that demonstrating a clear understanding of how these policies would affect its architecture/design was not an RFP requirement. Protest at 35. Rather, CARS asserts, demonstrating an understanding of associated risks was the explicit evaluation criterion, and CARS’s proposal satisfied that requirement. Id., citing RFP at 146.

Under the understanding of the requirements (sample task) element of the technical factor, the agency advised offerors that

[t]he Government will evaluate the Offeror’s response to the sample task provided in Section L to assess the Offeror’s understanding and capability to perform the requirements representative of the activities to be executed under this PWS, the ability to effectively plan and manage these representative requirements, the ability to introduce innovative approaches in supplying IT solutions, and the Offeror’s understanding of the associated risks, skills, and resources required.

RFP at 146. The RFP advised offerors that the agency would assess “the Offeror’s understanding of the associated risks” inherent in performing the requirement. Id. Additionally, under this element the RFP advised offerors that they should “be mindful of the need for timely accomplishment of the objectives with minimal risk to the program achievement and realism of the approach.” Id. at 128. The RFP further advised that offerors “shall take into consideration” an “understanding of the uncertainties and difficulties associated with this type of requirement.” Id. The RFP thus placed offerors on notice that risk was an integral part of the evaluation of the management and resource element of the technical factor. At a minimum, the risk to architecture development posed by DOD/Navy policy considerations was reasonably related to, or encompassed by, the announced evaluation factors. Sprezzatura Mgmt. Consulting, LLC, supra. There is thus no merit to the protester’s contention that the agency employed an unstated evaluation criterion when it assessed CARS’s proposal a weakness for not showing a clear understanding of how the risks associated the with DOD/Navy cloud policy would affect the proposed architecture/design. We deny this allegation.

Alleged Unassigned Strengths and Significant Strengths

CARS contends that the Navy’s evaluation unreasonably failed to assess six strengths or significant strengths in the protester’s proposal. Protest at 36-41. As explained below, we find no merit to these allegations.

An agency’s judgment that the features identified in a proposal do not significantly exceed the requirements of the solicitation or provide advantages to the government--and thus do not warrant the assessment of unique strengths--is a matter within the agency’s discretion and one that we will not disturb where the protester has failed to demonstrate that the evaluation was unreasonable. Bluehawk, LLC, B-421201, B‑421201.2, Jan. 18, 2023, 2023 CPD ¶ 43 at 5.

CARS first contends that, under the management and resourcing element of the technical factor, the agency failed to evaluate proposed teaming structures in conformance with the solicitation. The RFP required offerors to describe the team management structure--including whether the offeror had previously utilized a similar approach. RFP at 127. The agency would then evaluate the risk associated with the proposed teaming structure, considering whether the offeror had made prior use of the proposed approach. Id. at 146. CARS argues that the agency failed to consider that the teaming structure it proposed for this effort is like that used in a prior contract. Protest at 36, citing AR, Tab 2, CARS Technical Proposal at 10.

The agency did consider this facet of the protester’s proposal; the SSEB referenced it and found that “this business strategy was not considered an aspect of the proposal that had merit or exceeded requirements.” AR, Tab 5, CARS SSEB Report at 10. CARS quotes that language and then argues that the “TET admits it did not perform the evaluations disclosed in the RFP.” Protest at 37. We do not interpret the foregoing language as constituting such an admission; the SSEB report memorialized the agency’s contemporaneous consideration of whether CARS’s proposed teaming arrangement merited a strength and determined that it did not. That finding was within the agency’s discretion, and the protester has not demonstrated that it was unreasonable. We deny this allegation.

CARS contends that the Navy unreasonably failed to credit its proposal with a strength for its approach to continuous improvement. Protest at 37. The pertinent requirement is contained in the following four PWS paragraphs:

3.3.4.13. The Contractor shall support After Actions Reviews (AAR) to identify and review lessons learned to apply to future implementations.

3.3.4.14. The Contractor shall ensure that data records for all newly procured equipment and software are included in CM documentation. The Contractor shall conduct a review and analysis of releases that resulted in implementation of the back-out plan and develop recommendations for a Service Improvement Plan (SIP) to address and resolve failure points and implement Government approved corrective or follow-up actions to minimize future occurrences.

* * * * *

3.3.6.13. The Contractor shall support studies, improvements, and implementation of IT service offerings and capabilities, IT service delivery governance structures, frameworks, and related IT policies and procedures.

3.3.6.14. The Contractor shall conduct research, studies, analysis, and strategic planning for organizational optimization and efficiency, process optimization, standardization, decision making, leadership engagement, and communications.

RFP at 56, 58.

The protester enumerates several ways in which, in CARS’s view, its proposed continuous service improvement approach exceeded the solicitation requirement. Protest at 37. For example, CARS contends that its proposal contained a continuous service improvement program that was not an RFP requirement. Id. The agency evaluation considered this facet of the protester’s proposal and concluded “the approach was not considered an aspect of the proposal that had merit or exceeded requirements.” AR, Tab 5, CARS SSEB Report at 10 (noting that the “TET determined that the Offeror’s incorporation of Continuous Improvement met the solicitation requirements”). That determination was within the agency’s discretion, and the protester’s disagreement, without more, is insufficient to demonstrate that the agency acted unreasonably. Accordingly, this allegation is denied.

The protester asserts that its proposal should have been assessed a strength for CARS’s cloud experience. Protest at 38-39. The Navy argues that the RFP did not include experience as an evaluation criterion. COS/MOL at 30, citing RFP at 145-146. The protester failed to rebut the agency’s argument, see Comments at 23, and we therefore consider this allegation abandoned. Avionic Instruments LLC, B-418604.3, May 5, 2021, 2021 CPD ¶ 196 at 5 (noting that, in responding to an agency report, protesters are required to provide a substantive response to the arguments advanced by the agency; a protester’s statement, without elaboration, that its initial arguments are reiterated will result in the dismissal of the arguments as abandoned).

CARS argues that the agency unreasonably failed to assess the protester’s proposal a strength for its [DELETED] and [DELETED] tools. Protest at 39-40. The protester stresses that access to those tools will be “at no extra cost to the Government.” Protest at 39, quoting AR, Tab 2, CARS Technical Proposal at 24 (emphasis added in protest). The Navy expressed no concern about the cost of the tools. See AR, Tab 5, CARS SSEB Report at 12. Rather, the agency determined that “the time and labor necessary to duplicate our production environment into the Offeror’s prototype to reap its benefits would cause unnecessary delays which could increase risk to performance.” Id. The protester does not challenge that determination as unreasonable, see Comments at 23, and we thus deny this allegation.

CARS asserts that the agency unreasonably failed to assess the protester’s proposal a strength for its inclusion of [DELETED]. Protest at 40. The protester argues that [DELETED] was not an RFP requirement and that it differs from IT change management, which was required. Id., citing RFP at 55. The TET evaluation considered the protester’s proposed [DELETED] plan and did not consider it an aspect of the proposal that had merit or exceeded requirements. AR, Tab 5, CARS SSEB Report at 13, citing RFP at 55. We agree with the protester that [DELETED] and IT change management are distinct, and that the TET incorrectly stated that CARS’s proposed [DELETED] “met the solicitation requirements.” AR, Tab 5, SSEB Report at 13; Protest at 40. Nevertheless, the RFP defined a strength as “[a]n aspect of an Offeror’s proposal with appreciable merit or will exceed specified performance or capability requirements to the considerable advantage of the Government during contract performance.” RFP at 153.

CARS’s [DELETED] does not exceed a specified performance or capability requirement; [DELETED] is not responsive to a solicitation requirement. Protest at 40 (“There is no requirement for [DELETED] in the RFP.”). As noted above, the record demonstrates that the SSEB considered CARS proposed [DELETED] plan and found that it lacked merit and the determination of whether a proposal feature provides advantages to the government is a matter within the agency’s discretion that we will not disturb where the protester has failed to demonstrate that the evaluation was unreasonable. Bluehawk, LLC, supra. The protester here has not demonstrated the unreasonableness of the evaluation, and we deny this allegation.

Lastly, CARS asserts that its “detailed solution” to provide “incidental materials (ODC’s)” should have been assessed a strength. Protest at 41, citing AR, Tab 2, CARS Technical Proposal at 14. The TET considered the protester’s ODC procurement strategy and found that it did not exceed the RFP requirement in a way that merited the assessment of a strength. AR, Tab 5, CARS SSEB Report at 11. CARS has not demonstrated the evaluation was unreasonable, and this allegation is denied.

Unlevel Playing Field

CARS argues that, although the RFP instructed offerors to present a generic architecture, the Navy evaluated proposals “against the Navy’s current architecture and Landscape Cloud environment despite the fact that the only competitor with access to and knowledge and insight into what the Navy’s current architecture consists of is the incumbent contractor competitor [the awardee].” Protest at 45.

Generally, a solicitation must be drafted in a fashion that enables offerors to intelligently prepare their proposals and must be sufficiently free from ambiguity so that offerors may compete on a common basis. Seventh Dimension, LLC, B-417630.2, B-417630.3, Dec. 26, 2019, 2020 CPD ¶ 12 at 5. A competitive advantage of an incumbent contractor, which was gained by virtue of that contractor’s performance of the incumbent contract, is not an unfair or improper competitive advantage, and an agency is not required to attempt to equalize competition to compensate for that advantage unless there is evidence of preferential treatment or other improper action. Assured Performance Sys., B-418233.2, Mar. 10, 2020, 2020 CPD ¶ 101 at 5.

The allegation that the agency established an unlevel playing field is inextricably linked with the allegation that the agency disingenuously advised offerors to propose a generic architecture. CARS asserts throughout its protest that the agency advised offerors that the sample task was “intended to be ‘generic’ in nature to highlight an Offeror’s ability to understand and operate in [a Navy] Cloud Landscape.” Protest at 33, quoting RFP at 7; see Protest passim. The agency described the sample task as generic in a particular context. The Navy received numerous questions, including one about the 20 geographically disperse enclaves that were to be migrated. RFP at 7, Questions and Answers 9.

An offeror noted that the RFP did not provide the number, size, or currency of the systems and applications, the data throughput and capacity requirement, or the availability requirements. Id. The offeror asked the agency to “provide more information regarding the cloud targeted 20 enclaves” so that offerors could in turn provide a more realistic network architecture and more accurate project schedule. Id. In that context, the Navy advised offerors that the sample task was intended to be “generic” in nature. Id. With respect to the enclaves, the agency advised the offerors that the Navy intended that the offerors assume a geographically dispersed customer base and workloads that, as described, were particularly diverse in nature. Id. Finally, the agency’s response instructed offerors to document their assumptions, as requested in RFP section L. Id. In other words, the requirement was, in one respect, “generic,” but it was not undefined. For example, offerors were to assume a geographically dispersed customer base with diverse workloads. CARS contends that, rather than evaluate offers against the evaluation criteria, the agency compared proposals to the Navy’s existing requirement, which was known only to the incumbent awardee. Protest at 48-49.

The record demonstrates that the weaknesses and significant weakness that the agency assessed CARS’s proposal were unrelated to the protester’s lack of knowledge of the Navy’s current architecture. The protester’s proposal received five weaknesses, three of which were wholly unrelated to the proposed architecture: failure to describe effective communication channels; failure to explain the protester’s chain of command at remote locations; and failure to define workforce training. The fourth weakness was for a failure to define the implementation of its proposed innovative solutions, including an explanation of why CARS chose its proposed architecture. The final weakness was for a failure to explain the risks associated with DOD/Navy policies. Neither of those weaknesses implicates a lack of knowledge of the Navy’s current architecture. Similarly, the three weakness that constituted the significant weakness were all for shortcomings inherent in CARS’s proposal--not comparative weaknesses: failure to clearly describe the role of [DELETED] in its proposed architecture; selection of a risky method of network connectivity when offerors were not required to address the issue; and failure to describe how CARS would utilize its proposed toolkit.

Furthermore, the intervenor argues that “CARS’ own proposal represents that ‘[d]uring the pre-Request for Proposal (RFP) phase, Team CARS conducted multiple meetings with DNA to gain a deep understanding of their goals and objectives for the IT EEOHSS contract.’” Intervenor’s Comments at 11, quoting AR, Tab 2, CARS Technical Proposal at 5. The intervenor notes that CARS has a “presence at all NAVAIR locations.” Id. The intervenor further notes that, “as a result of [CARS’] ‘[c]ollective presence at all NAVAIR locations supported by DNA,’ CARS claimed that it has a ‘current understanding of [the] environment.’” Intervenor’s Comments at 11, quoting AR, Tab 2, CARS Technical Proposal at 4, fig. 1. The intervenor contends that, while CARS claims in this protest to have a limited, unequal understanding of the current environment at the agency, “its own proposal demonstrates otherwise--belying its belated claims that it needed more information and, without it, could not compete fairly.” Intervenor’s Comments at 11-12.

The record does not support the allegation that an unlevel playing field--the protester’s lack of knowledge of the Navy’s current architecture--influenced the assessment of weaknesses and a significant weakness in the protester’s proposal. As discussed above, the record supports the Navy’s contention that the protester’s proposal was reasonably evaluated against the RFP requirements. To the extent that knowledge of the Navy’s current architecture provided the awardee with an advantage, an agency is not required to attempt to equalize competition to compensate for such an advantage unless there is evidence of preferential treatment or other improper action. Assured Performance Sys., supra. This allegation is denied.

Evaluation of Past Performance

CARS asserts that its first past performance reference should have been evaluated as very relevant, rather than relevant, and that its second past performance reference was unreasonably evaluated as not relevant. Protest at 42-43. Our Office will examine an agency’s evaluation of an offeror’s past performance only to ensure that it was reasonable and consistent with the stated evaluation criteria and applicable statutes and regulations. Sysco Cent. Texas, Inc., B-422356, May 8, 2024, 2024 CPD ¶ 117 at 4.

Contract Reference 1

The RFP provided that a reference demonstrating performance of five to seven scope elements would be rated relevant, and a reference demonstrating eight or more scope elements would be rated very relevant for technical scope. RFP at 152. The Navy evaluated CARS’s first contract reference as relevant, finding that it demonstrated performance of five out of ten technical scope elements. AR, Tab 5, CARS SSEB Report at 29-30. The protester asserts that the evaluation was unreasonable because CARS’s proposal provided justification for eight, not five, of the ten technical scope elements and the reference should therefore have been evaluated as very relevant. Protest at 42.

The Navy argues that the RFP provided that “[a] Contract reference relevancy rating will be the lowest relevancy rating achieved based on the assessment of Scope, Complexity, and Magnitude.” COS/MOL at 34, quoting RFP at 146. The agency’s evaluation found that reference one demonstrated a magnitude of greater than $12 million and less than $24 million. AR, Tab 5, CARS SSEB Report at 30. CARS does not contest that portion of the past performance evaluation. See Protest at 41-42. The RFP provided that a reference with a value between $12 million and $24 million would be evaluated as relevant for magnitude. RFP at 153. Because the reference was reasonably evaluated relevant under magnitude, the agency argues that the reference could not have been evaluated higher than relevant overall. COS/MOL at 34.

CARS argues that “the Government performed an integrated assessment of scope, complexity, and magnitude to determine similarity to this solicitation.” Comments at 24, quoting AR, Tab 5, CARS SSEB Report at 28; RFP at 146. The RFP provided that the performance confidence assessment rating would “be assigned based on an integrated assessment of all performance areas for the [very relevant, relevant, and somewhat relevant] contract references.” RFP at 147. Nothing in the CARS SSEB report contradicts the plain language of the RFP evaluation criteria that provided a contract relevancy rating would be the lowest relevancy rating achieved in the assessment of scope, complexity, and magnitude. The performance confidence assessment rating--which considered the performance of all very relevant, relevant, and somewhat relevant contracts--was separate and distinct from the relevancy rating of a single contract. This allegation is denied.

Contract Reference 2

The RFP required offerors to provide “electronic copies of the complete final versions of the SOW/PWS or other supporting solicitation/contract documentation from each contract or delivery/task order reference.” RFP at 129-130. For contract reference 2, CARS provided a draft PWS, labeled for official use only, because the final PWS was not available due to its restricted classification. AR, Tab 3, CARS Past Performance Proposal at 72.

Because CARS submitted a draft unsigned subcontractor statement of work for this reference, the Navy contends it was unable to determine whether CARS was awarded the work under the reference. AR, Tab 5, CARS SSEB Report at 30. The agency argues that the draft statement did not conform to the RFP requirement that the offeror submit final versions of statements of work. The agency asserts it could thus not determine the technical scope, complexity, or magnitude of the work CARS may have performed and rated the reference as not relevant under each of the three categories. Id. at 30-31. In accordance with the RFP, the Navy assessed the reference as not relevant. Id. at 30.

CARS contends that the Navy’s evaluation ignored the RFP’s provision that, in lieu of final versions of a statement of work, the offeror could provide other supporting documentation. Protester Resp. to GAO Req. at 3, citing RFP at 129-130. CARS contends that it provided other supporting documentation, namely, the “unsigned draft PWS.” Protester Resp. to GAO Req. at 3. The solicitation does not describe other supporting documentation; the RFP is explicit, however, that whatever documentation the offeror provided must be “complete final versions.” RFP at 129-130. In other words, the offeror could provide the complete final version of the statement of work or the complete final version of some other supporting documentation. The protester’s contention that the other supporting documentation could be a draft statement of work reads out of the solicitation the requirement that offerors produce complete final versions of documents, and that reading of the solicitation is therefore unreasonable. Graham Techs., LLC, B-413104.25, Feb. 25, 2019, 2019 CPD ¶ 94 at 4 (noting that, to be reasonable, and therefore valid, an interpretation must be consistent with the solicitation when read as a whole and in a reasonable manner).

CARS’s proposal did not provide the complete final statement of work for CR 2, and the protester failed to provide the complete final version of some other supporting documentation. In the absence of that required documentation, we have no reason to question the relevancy ratings of not relevant for technical scope, complexity, or magnitude; a not relevant rating under any one of the categories would have mandated an overall rating of not relevant. The allegation that the Navy unreasonably evaluated CR 2 as not relevant is denied.

In sum, the record fails to support either set of challenges to the evaluation of the technical factor--that the agency unreasonably assessed weaknesses and a significant weakness and unreasonably failed to assess strengths and significant strengths. Nor does the record support a conclusion that the agency unreasonably evaluated the protester’s proposal under the past performance factor. Throughout record development, CARS asserted that offerors did not compete on a level playing field because the agency failed to evaluate its proposal against the announced generic standard and instead compared it to the Navy’s existing architecture. The record demonstrates that the agency evaluated CARS’s proposal in accordance with explicit evaluation criteria and criteria reasonably related to or encompassed by the stated criteria.

The protest is denied.[8]

Edda Emmanuelli Perez
General Counsel

 

---