Oracle America, Inc.
B-417046: Jan 31, 2019
- Full Report:
Oracle America, Inc. (Oracle), of Redwood Shores, California, protests the award of an indefinite-delivery, indefinite-quantity (IDIQ) contract to ViON Corporation (ViON), of Herndon, Virginia, under request for proposals (RFP) No. HC1028-17-R-0015 issued by the Department of Defense, Defense Information Systems Agency (DISA), for on-demand processing capabilities for the agency's scalable processor architecture (SPARC). The protester challenges the agency's technical evaluation and its best-value tradeoff decision.
We deny the protest.
DOCUMENT FOR PUBLIC RELEASE
The decision issued on the date below was subject to a GAO Protective Order. This redacted version has been approved for public release.
Matter of: Oracle America, Inc.
Date: January 31, 2019
Oracle America, Inc. (Oracle), of Redwood Shores, California, protests the award of an indefinite-delivery, indefinite-quantity (IDIQ) contract to ViON Corporation (ViON), of Herndon, Virginia, under request for proposals (RFP) No. HC1028-17-R-0015 issued by the Department of Defense, Defense Information Systems Agency (DISA), for on-demand processing capabilities for the agency's scalable processor architecture (SPARC). The protester challenges the agency's technical evaluation and its best-value tradeoff decision. 1
We deny the protest.
DISA issued the RFP on May 8, 2017, seeking on-demand SPARC processor capacity services within DISA and at DISA-approved locations in the United States and worldwide. RFP at 1;2 Agency Report (AR), Tab 2A, Performance Work Statement (PWS) § 4.0, at 1-2. The stated objective of the procurement is "to obtain reliable, responsive, and cost effective processor infrastructure services of 'on-demand' SPARC Compatible chipset processing capabilities[.]"3 AR, Tab 2A, PWS § 4.0, at 1-2.
The PWS required the contractor to "acquire, deliver, install, configure, deinstall, and provide the necessary hardware (which may include but is not limited to cabinets/racks/ cabling/cable management/power distribution units (PDUs)), hardware maintenance, operating system software, hypervisor solution, as well as, any other software required for the Contractor's solution to operate, and services to support the processor infrastructure associated with this contract." Id. at 3. The PWS provided that the government would maintain daily operational control and oversight responsibility for the processing environment, while the contractor would provide all software required for the solution to operate, as well as software maintenance and licenses. Id.
The RFP contemplated the award of a single IDIQ contract with a base ordering period of 5 years followed by five 1-year option periods. RFP at 3-5, 30. Orders issued under the contract would be performed on a fixed-price basis. Id. at 86. The minimum value for all orders was $630,000 and the maximum value was $329,586,627. Id. at 3.
The RFP notified offerors that the agency would make an award to "the offeror whose proposal is the most advantageous to the Government, based upon an integrated assessment of" proposals under the following five evaluation factors: (1) technical/ management, (2) past performance, (3) cost/price, (4) supply chain risk management plan, and (5) small business participation plan. AR, Tab 2J, RFP § M.2.0, at 2-3. There were seven subfactors evaluated under the technical/management factor (factor 1).4 Id. at 3.
With regard to the relative importance of the factors, the RFP provided that all non-cost factors were equal in importance and, when combined, were approximately equal to the cost/price factor. Id. The RFP further provided that all non-price factors and subfactors, with the exception of subfactors 1, 2, and 3 within the technical/management factor, were to be evaluated on an acceptable/unacceptable basis. Id., RFP § M.2.0, at 3; § M.2.2.1, at 7; § M.2.4, at 10; § M.2.5, at 11.
Subfactors 1, 2, and 3 within the technical/management factor were of equal importance. Id., RFP § M.2.0, at 3. For these subfactors, the RFP provided that the agency would assign two distinct but related ratings: (1) a technical/management rating and (2) a technical/management risk rating. Id., RFP § M.2.1.1, at 3. The former represents DISA's assessment of the offeror's capability to satisfy the government's technical processor requirements. Id. For this rating, the agency considered strengths, deficiencies, and uncertainties of an offeror's proposal and assigned one of the following color/adjective ratings: blue/outstanding, purple/good, green/acceptable, yellow/marginal, or red/unacceptable. Id., RFP, Table M.2, at 3-4. The latter rating, i.e., the risk rating, represents the government's assessment of the potential for disruption of schedule, increased cost or degradation of performance, the need for increased government oversight, and the likelihood of unsuccessful contract performance. Id., RFP § M.2.1.1, at 4. For this rating, the agency considered weaknesses and significant weaknesses of an offeror's proposal and assigned one of the following risk ratings: low, moderate, or unacceptable. Id., RFP, Table M.3, at 4-5.
In response to the solicitation, the agency received proposals from two offerors: Oracle and ViON. The agency evaluated proposals from August 2017 through October 2018. Contracting Officer's Statement at 13. During the evaluation period, the agency issued three rounds of evaluation notices and requested two rounds of final proposal revisions from the offerors. Id. at 3, 13.
The following is a summary of the agency's final ratings of Oracle's and ViON's proposals:
|Factor 1: Technical/Management5|
|Subfactor 1: Technical Solution: SPARC Compatible||Acceptable/Low||Acceptable/Low|
|Subfactor 2: Technical Solution: Virtualization||Acceptable/Low||Acceptable/Low|
|Subfactor 3: Transition Plan||Acceptable/Low||Acceptable/Low|
|Subfactor 4: Capacity||Acceptable||Acceptable|
|Subfactor 5: Integration/Interfaces||Acceptable||Acceptable|
|Subfactor 6: Performance/Availability||Acceptable||Acceptable|
|Subfactor 7: Technical Requirements and Architecture||Acceptable||Acceptable|
|Factor 2: Past Performance||Acceptable||Acceptable|
|Factor 3: Total Evaluated Price6||$113,589,847||$111,917,392|
|Factor 4: Supply Chain Risk Management||Acceptable||Acceptable|
|Factor 5: Small Business Participation||Acceptable||Acceptable|
AR, Tab 7, Source Selection Decision Document (SSDD), at 38-39.
The record reflects that the agency did not identify any strengths, weaknesses, or deficiencies in Oracle's proposal under subfactors 1, 2, and 3 within the technical/ management factor. See e.g., AR, Tab 5, Technical Report, at 7. Likewise, the record reflects that the agency did not identify any strengths, weaknesses, or deficiencies in ViON's proposal under these subfactors. AR, Tab 7, SSDD, at 41. As relevant to Oracle's protest, the agency assigned Oracle's proposal a technical/management rating of "acceptable" under subfactors 1, 2, and 3 because DISA concluded that the proposal "clearly indicates an adequate approach and understanding of the requirements[.]" AR, Tab 5, Technical Report, at 7. The agency assigned the proposal a risk rating of "low" because DISA concluded that the proposal "contains no weaknesses" and "meets the Government's requirements" under each of the applicable PWS tasks. Id. at 10.
In conducting the best-value tradeoff, the source selection authority (SSA) summarized and concurred with the underlying evaluation of both proposals under each of the five evaluation factors. AR, Tab 7, SSDD, 14-37, 39. The SSA also conducted a comparative assessment of the two proposals under each factor, id. at 39-41, concluding that "both offerors' proposals are essentially equal under the non-price factors." Id. at 41. As relevant to Oracle's challenge, the SSA found that "there is no advantage or disadvantage for either offeror's proposal" under subfactors 1 through 3 of the technical/management factor. Id. at 39. The SSA noted that, although the proposals were essentially equal under the non-price factors, Oracle proposed a price that was 1.47 percent higher than ViON's proposed price. Id. at 41.
Having found that both offerors' proposals were essentially equal under the non-price factors and recognizing that, under the terms of the RFP, the non-price factors, when combined, are approximately equal to price, the SSA concluded that ViON's lower-priced proposal represented the best value to the government. Id. In reaching this conclusion, the SSA explained that "[b]ecause ViON's proposal is an acceptable solution and there is no aspect of Oracle's proposal that would support paying an additional $1,672,555 more, I have determined that ViON's solution is the best value to the government in accordance with the RFP." Id.
The agency awarded the IDIQ contract to ViON on October 16. That same day, the agency provided a written debriefing to Oracle, and, on October 19, the agency provided an enhanced debriefing pursuant to Department of Defense Class Deviation 2018-0011. AR, Tab 8A, Debriefing; Tab 10, Enhanced Debriefing. This protest followed on October 24.
Oracle challenges the agency's evaluation of its proposal under subfactors 1 and 3 of the technical/management factor, contending that its proposal demonstrated an exceptional understanding of the requirements and warranted the assignment of several strengths.7 Protest at 1, 14-19. Specifically, Oracle asserts that its proposal merited five strengths under subfactor 1 and one strength under subfactor 3.8 Oracle also challenges the agency's best-value tradeoff decision, contending that DISA failed to assess the relative technical merit of the proposals and, instead, improperly made award on a lowest-priced, technically acceptable basis. Id. at 11-14. In challenging the agency's tradeoff decision, Oracle also contends that the decision was insufficiently documented. Id. at 19-20. For the following reasons, we find no basis upon which to sustain the protest.
It is well-established that the evaluation of proposals is a matter within the discretion of the contracting agency. Raytheon Co., B-416211 et al., July 10, 2018, 2018 CPD ¶ 262 at 4. In reviewing protests challenging an agency's evaluation of proposals, our Office does not reevaluate proposals or substitute our judgment for that of the agency; rather, we review the record to determine whether the agency's evaluation was reasonable and consistent with the solicitation's evaluation criteria, as well as applicable statutes and regulations. Desbuild, Inc., B-413613.2, Jan. 13, 2017, 2017 CPD ¶ 23 at 3. A protester's disagreement with the agency's judgment, without more, is insufficient to establish that the agency acted unreasonably. Novetta, Inc., B-414672.4, B-414672.7, Oct. 9, 2018, 2018 CPD ¶ 349 at 13.
Evaluation Under Subfactor 1: Technical Solution (SPARC Compatible)
Oracle alleges that its proposal merited five strengths under subfactor 1 of the technical/management factor. Protest at 15-18; Comments at 10-18; Supp. Comments, Dec. 13, 2018, at 2-7. In evaluating offerors' proposals under subfactor 1, the RFP provided that the agency would consider an offeror's ability to provide solutions that met or exceeded the technical requirements outlined in sections 6.1.1, 6.1.2, 184.108.40.206, and 6.11.1 of the PWS.9 AR, Tab 2J, RFP § M.2.1.1, at 5. The RFP defined a strength as "an aspect of an offeror's proposal that has merit or exceeds specified performance or capability requirements in a way that will be advantageous to the Government during contract performance." Id.
Oracle claims that it offered solutions that exceeded the minimum requirements of all four of these sections of the PWS. Although we discuss only a few representative examples of the arguments raised by Oracle regarding DISA's evaluation of its proposal under subfactor 1, we have reviewed each of the protester's arguments, and find no basis to sustain the protest. Rather, the record demonstrates that the agency's evaluation was reasonable, adequately documented, and in accordance with the terms of the RFP.10
Copper and Fiber Network Connections
Oracle claims that its proposal merited a strength under subfactor 1 because it offered a solution that exceeded the requirements of PWS section 220.127.116.11. Protest at 16. Very generally, this section of the PWS pertains to network and storage connections and requires the contractor to meet requirements for a number of connections, separated connections, and speed for Ethernet and Host Bus Adapter connectivity. AR, Tab 2A, PWS § 18.104.22.168, at 7. Among other things, the RFP required offerors to propose a solution for network connections that would integrate into DISA's existing processing infrastructure "with minimal disruption or reconfiguration of network infrastructure." Id. The RFP further required that contractors propose components that are "compatible with the government's network switching infrastructure." Id.
In its proposal, Oracle offered [DELETED]. AR, Tab 4, Oracle's Technical Proposal, § 7.2, at II-40, Note 2; Oracle's Post-Hearing Comments at 5; Tr. at 35:16-36:9, 62:14-16. Oracle contends that this [DELETED] merited a strength because it provides the agency the "flexibility to meet future requirements while still meeting current needs." Protest at 16. Oracle contends that its [DELETED] solution merited a strength for the cost savings it afforded to DISA.11 Oracle's Post-Hearing Comments at 9.
In response, the agency points out that the RFP did not specify the use of fiber or copper network connections because both types of connections were acceptable from the agency's perspective.12 Tr. at 31:12-18, 42:14-18. As a result, in considering Oracle's proposed [DELETED] solution, the evaluation team concluded that "[DELETED] are acceptable from a technical standpoint." AR, Tab 5, Technical Report, at 8; Tr. at 42:14-18.
Although the agency recognizes that Oracle's [DELETED] solution may provide some value to the agency in terms of flexibility, see e.g., Tr. at 68:4-7, 84:5-19, 85:18-20, the agency contends that such a solution also has several disadvantages, including the fact that a [DELETED] solution introduces complexity for DISA technicians. Id. at 43:22-44:7, 81:12-82:16. In this regard, the agency explains that, through this contract, DISA is replacing 400 SPARC servers, each with at least four network connections. Id. at 15:15. In servicing the connections, technicians would be required to remember which connections are [DELETED] to ensure that compatible switches and cabling are used.13 Id. at 82:9-16. As the Technical Chair testified, "[i]t's a very large environment with a lot of pieces and parts to keep track of," id. at 82:13-15, and "[i]t's hard to keep track of hardware, connections, ports, cable runs, where does this cable go, what does this connect to." Id. at 95:15-18.
For this reason, the agency asserts that simplicity and standardization are more advantageous to the agency than flexibility. See, id. at 82:1-7 (agreeing that the "agency values standardization over flexibility."). See also e.g., id. at 82:15-16 (explaining that a homogenous solution is beneficial "to ensure that we can account for and know what we're managing"); id. at 81:17-19 (testifying that "[w]e look for standardization, just to make things as simple as possible in a complex configuration and complex environment"); id. at 81:20-22 (contending that "one standard rather than two" is preferred); id. at 95:18-19 (explaining that "our goal was to not introduce complexity"). Accordingly, although a [DELETED] solution met the agency's needs and was deemed to be acceptable, the agency concluded that such a solution did not exceed the agency's needs in a manner that was advantageous to the agency.
Additionally, to the extent Oracle proposed an [DELETED] solution, the agency explains that the solution did not merit a strength because copper connections are an older, legacy technology and not likely to be the connection of choice over the 10-year contract. AR, Tab 12, Technical Declaration, at 7 (explaining that "[c]opper connectivity is not current technology and use of copper is less advantageous to the Government"); Tr. at 28:14-15 (asserting that "[c]opper has been around for a while, and it is an older technology"); id. at 74:19-20 (predicting that copper "is a resource that could become scarce"); Agency Post-Hearing Comments at 5 (representing that "[a]n all-copper cabled solution would likely be detrimental to the Agency over the ten years of performance").
In contrast, the agency contends that "modern" fiber connections "provide some benefits over copper." Tr. at 28:18-19; Supp. MOL at 7. For instance, the agency explains that fiber connections offer faster connections "from the server to the network to the outside world and back again." Tr. at 23:6-9. The agency also explains that there is less risk associated with fiber connectivity because it is newer technology. Id. at 74:9-10 (explaining that the use of fiber connections "would minimize risk for the Agency" over the course of the 10-year contract); id. at 74:16-20 (testifying that "[f]iber would provide us with insurance of the technology being available for 10 years or more").14 The protester itself recognizes the benefits of fiber connections, representing that "[f]iber connections also offer enhanced security, as signals from fiber connections cannot be intercepted; whereas, signals traveling on copper connections can be." Oracle's Post-Hearing Comments at 9.
Furthermore, because of the age of the copper technology, the agency anticipates that, during the contract period of performance, it may require replacement of copper connections with fiber connections, which would negate any alleged cost savings associated with Oracle's [DELETED] solution under both the SPARC and CSC II contracts. Agency Post-Hearing Comments at 6. See also Tr. at 74:16-20 (stating that, "[w]hile copper may be cheaper," it does not provide the same "insurance" as fiber because copper may not be available for the life of the contract).
Accordingly, although an [DELETED] solution was acceptable under the terms of the RFP, the agency "determined that it would be better to move towards fiber[.]" Id. at 28:16-18. See also id. at 29:20-21 (testifying that "it's more advantageous to move to fiber over copper"). For these reasons, the agency did not assign a strength to Oracle's proposal for its offer to provide what the agency refers to as "near-obsolete" connections. MOL at 46.
We find the agency's conclusions to be unobjectionable. The agency's evaluation of Oracle's proposal demonstrates that the agency was willing to accept a solution that utilizes legacy copper, modern fiber connections, or a combination thereof. AR, Tab 5, Technical Report, at 8. To the extent Oracle contends that its [DELETED] solution merits a strength, DISA reasonably concluded that the disadvantages associated with such a solution outweigh any alleged flexibility. Likewise, to the extent Oracle contends that its [DELETED] solution merits a strength for the cost savings that the agency may realize on the CSC II contract, DISA reasonably concluded that the disadvantages associated with the use of copper outweigh any alleged costs savings. Although Oracle may disagree with the agency's subjective business judgments in these respects, such disagreement, without more, is insufficient to demonstrate that the judgments were unreasonable.15 Crowder Constr. Co., B-411928, Oct. 8, 2015, 2015 CPD ¶ 313 at 10. Accordingly, we deny this ground.
Additional Fiber Storage Connections
Oracle also claims that it was entitled to a strength for another aspect of its approach under the same section of the PWS discussed above, i.e. section 22.214.171.124. Protest at 16. As relevant to this ground, Oracle points to section 126.96.36.199 of the PWS, which required offerors to propose "two separate ports for fiber storage connectivity."16 AR, Tab 2A, PWS § 188.8.131.52, at 7. The RFP further provided that the ports "must be distributed across a minimum of 2 Host Bus Adapter (HBA) cards."17 Id.
The record reflects that Oracle proposed a total of four ports provided via two dual-port HBA cards. AR, Tab 4, Oracle's Technical Proposal, at II-39. Oracle claims that it was entitled to a strength because "Oracle's provision of two dual-port HBA cards exceeds the RFP's minimum requirements by providing four total HBA ports instead of the PWS-required two HBA ports." Comments at 16. Oracle further claims that the excess ports benefit the agency by providing additional redundancy and the ability to exceed Recovery Time Objectives (RTOs).18 Protest at 17; Comments at 16; Oracle's Post-Hearing Comments at 12. Oracle explains that, with four ports spread across two HBA cards, DISA could experience a failure of one of the cards and still maintain access to the network infrastructure. Comments at 16.
In response, the agency explains that it did not assign Oracle's proposal a strength for proposing four ports because Oracle's solution did not exceed the agency's minimum requirements. Tr. at 113:20-114:15. At the hearing, the Technical Chair testified that the agency, in fact, required four ports, as proposed by Oracle, not two ports. To support its contention, the agency points to Appendix One of the PWS, which set forth the technical specifications for each of the required SPARC server tiers. Id. at 109:16-18, 110:5-11. With respect to the requirements for storage connections, Appendix One indicates that offerors must propose a "minimum of 2 Host Bus Adapters to have a minimum of 4 fiber channel ports to meet bandwidth needs." AR, Tab 2A, PWS Appx. One, at 35 (emphasis added). The same requirement applied to each of the four tiers. Id. The Technical Chair testified that section 184.108.40.206's reference to a "minimum of two Host Bus Adapter (HBA) ports" was an "oversight," which was not discovered "until well after award." Tr. at 112:1-17, 114:12-15, 125:8-11, 139:2-7, 115:14-15, 139:8-11.
Assuming for the sake of argument that Oracle relied upon the language in section 220.127.116.11 when preparing its proposal, this language was in direct conflict with the agency's statement of requirements contained in Appendix One, which established the agency's requirement as four ports. This conflicting language created a patent ambiguity regarding the agency's requirements. A patent ambiguity exists where the solicitation contains an obvious, gross, or glaring error; for example, where the solicitation provisions appear inconsistent on their face. AOC Connect, LLC, B-416658, B-416658.2, Nov. 8, 2018, 2018 CPD ¶ 384 at 6. Having failed to seek clarification of the conflicting language, Oracle relied upon the language in section 18.104.22.168 at its peril. Where a patent ambiguity is not challenged prior to the submission to proposals, any subsequent challenge is untimely. 4 C.F.R. § 21.2(a)(1).
Additional Network Connections
Finally, Oracle claims that it was entitled to a strength for yet another aspect of its approach under the same section of the PWS discussed above, i.e. section 22.214.171.124. Protest at 16. As relevant to this ground, section 126.96.36.199 required offerors to propose four network ports to support Ethernet traffic. AR, Tab 2A, PWS § 188.8.131.52, at 7. Two ports were dedicated to production traffic and two ports were dedicated to out of band (OOB)/enterprise backup network (EBN) connections. Id. Regarding the two ports dedicated to OOB/EBN connections, one port served as the primary port and one port served as the backup port. Id. The RFP informed offerors that "[t]he contractor's solution should provide reliable, cost effective cabling approach that will condense the amount of network cabling and network ports required." Id.
Oracle's solution offered [DELETED] ports. AR, Tab 4, Oracle's Technical Proposal, at II-39, II-40; Tr. at 100:13-17. [DELETED]. AR, Tab 4, Oracle's Technical Proposal, at II-40; Tr. at 100:18-101:17. Accordingly, because the RFP required four network ports and because Oracle proposed [DELETED] network ports, there is no dispute that Oracle exceeded the PWS's requirement. Tr. at 102:7-9, 120:11-19, 121:1-3. Oracle contends that its solution provides "additional isolation and redundancy" and, thus, merited a strength. Protest at 17.
The agency disputes that this slight increase over the specified minimum number of network connections provided sufficient benefit to warrant a strength. Tr. at 124:11-14. In this respect, the agency explains that the additional ports provide no measurable benefit in terms of redundancy because the necessary redundancy was already built into the PWS's minimum requirement. Id. at 92:20-93:1, 93:11-14, 141:19-142:4. By having two ports for production traffic and two ports for OOB/EBN requirements-- a primary and a backup port--DISA can spread the network traffic over separate connections. Id. at 141:19-142:1. If one of the network ports were to fail, the agency can use the second, redundant port. Id. at 142:1-4. The agency did not require redundancy beyond that specified in the PWS.
Moreover, the agency asserts that the additional ports were not beneficial because they add complexity and cost to the agency. Id. at 102:12-14; 108:4-6. The Technical Chair testified that the agency "doesn't want a proliferation of anything." Id. at 95:13-14. He explained that "our goal was to not introduce complexity." Id. at 95:18-19. For that reason, DISA expressly informed offerors in the RFP that it desired a solution "that will condense the amount of network cabling and network ports required." AR, Tab 2A, PWS § 184.108.40.206, at 7; Tr. at 95:19-21. The Technical Chair also explained that DISA is charged under the CSC II contract for each port used. Tr. at 96:2-6, 96:21-22. Each additional port on the SPARC server will have a corresponding cost on the CSC II contract, the contract through which the agency procures switches. Additional ports also require additional cabling, which adversely affects the temperature in the data center.19 Id. at 107:20-108:3. Therefore, the use of additional ports would increase the cost to DISA. Id. at 96:2-6, 96:21-22, 107:6-108:3.
Although Oracle argues that its solution provides the agency the flexibility to use the additional ports in the future, should DISA determine them to be necessary despite the additional cost, Tr. at 119:10-19, 122:6-10, DISA contends that it is unlikely that it will have a need for additional ports based upon the agency's assessment of its past needs. Id. at 102:15-20, 108:4-6, 123:14-124:2. In this respect, the agency explains that its assessment of its needs is based upon its historical usage on the current contract and the previous contract. Id. at 123:20-124:5. In this regard, the agency, once again, indicates that it values simplification over flexibility.
We find the agency's conclusions to be unobjectionable. To the extent Oracle contends that its solution merits a strength due to additional redundancy and flexibility, DISA reasonably concluded that the potential disadvantages associated with such a solution outweigh any alleged redundancy and flexibility. Although Oracle may disagree with the agency's subjective business judgments in this respect, such disagreement, without more, is insufficient to demonstrate that the judgments were unreasonable. Crowder Constr. Co., supra. Accordingly, we deny this ground.20
Evaluation Under Subfactor 3: Transition Plan
Oracle also contends that its proposal merited a strength under subfactor 3 for its proposed call order system, which it refers to as its [DELETED]. Protest at 18. Under this subfactor, the RFP provided that the agency would evaluate an offeror's ability to meet or exceed the requirements outlined in sections 220.127.116.11 through 6.11.2 of the PWS pertaining to an offeror's incoming and exit transition plans. AR, Tab 2J, RFP § M.2.1.1, at 6; Tab 2A, PWS § 18.104.22.168--6.11.2, at 14-15.
Relevant here, section 22.214.171.124 required the offeror to deliver within 60 days of award an incoming transition plan, addressing, among other items, "details about the call order system being provided[.]" AR, Tab 2A, PWS § 126.96.36.199, at 14-15. Oracle contends that its proposal exceeded the requirement by offering to provide the transition plan prior to the 60-day period. Comments at 19-20, Supp. Comments at 8. Oracle also contends that its proposal exceeded the requirement by providing "significant detail" regarding its call order system, which the agency allegedly failed to properly consider. Protest at 18.
The agency responds that Oracle was not entitled to a strength because its proposal did not exceed the requirement. MOL at 54. In this regard, the agency argues that the deliverable requirement under section 188.8.131.52 was to submit an incoming transition plan "within 60 days of award." AR, Tab 2A, PWS § 184.108.40.206, at 15. In its proposal, Oracle represented that it "will deliver a transition strategy plan within sixty (60) days of contract award." AR, Tab 4, Oracle's Technical Proposal, at II-68; id. at II-20 (proposing to deliver "[t]he detailed transition plan . . . within sixty (60) days of contract award"). Accordingly, because the proposal did not indicate that the deliverable would be completed sooner than the 60-day requirement, the agency concluded that Oracle did not exceed the requirement. AR, Tab 12, Technical Declaration, at 11-12.
We agree with the agency in this respect. Although Oracle's proposal indicates, generically in a single instance, that it "will provide a detailed transition plan . . . prior to the sixty (60) day period as required by the Government," such a representation is vague and suggests mere compliance with the agency's requirement where other language on the same page of the proposal provided that the plan "will be delivered within sixty (60) days of contract award." AR, Tab 4, Oracle's Technical Proposal, at II-20, (emphasis added). Thus, we find no support for Oracle's contention that its proposal exceeded the deliverable requirements contained in section 220.127.116.11 of the PWS.
The agency also argues that the requirements pertaining to an offeror's call order management system were set forth in section 6.17.2, Call Order Management System, and that, per the terms of the RFP, an offeror's proposed call order management system was not an aspect that the agency would evaluate under subfactor 3. MOL at 53. The record supports the agency's position. Moreover, the protester appears to recognize this when it included its call order system in a table of "responses to PWS items that are not included in the Sub-Factors." AR, Tab 4, Oracle's Technical Proposal, at II-63, II-69. Thus, we find the agency's failure to award Oracle a "missing" strength for the level of detail it provided regarding its call order system to be reasonable.
Best-Value Tradeoff Decision
In challenging the agency's best-value tradeoff decision, Oracle alleges that DISA failed to properly assess the relative technical merit of the proposals and, instead, made an award to the lowest-priced, technically acceptable offeror, in violation of the solicitation's terms. Protest at 11; Comments at 3. In this regard, Oracle claims that the agency failed to look beyond the adjectival ratings to consider the qualitative differences of the proposals. Protest at 13. We disagree.
Oracle incorrectly assumes that such qualitative differences existed. The record demonstrates, however, that the SSA concluded otherwise. After summarizing the underlying evaluation of both Oracle's and ViON's proposals (with which he expressly concurred), the SSA determined that there was "no advantage or disadvantage" associated with either proposal under subfactors 1, 2, or 3 of the technical/management factor--the only evaluation factor for which qualitative differences could be considered. AR, Tab 7, SSDD, at 39. Moreover, the SSA recognized that neither proposal received any strengths, weaknesses, significant weaknesses, deficiencies, nor uncertainties under these subfactors to potentially distinguish them from one another. Id. at 41. For these reasons, and because the proposals were both rated acceptable under the pass/fail factors, the SSA concluded that "both offerors' proposals are essentially equal." Id. We find the SSA's conclusions to be reasonable.
Because the proposals were reasonably determined to be equal, no price/technical tradeoff was required. In this regard, in a negotiated procurement with a best-value tradeoff evaluation methodology, where selection officials reasonably regard proposals as being essentially technical equal, price properly may become the determining factor in making the award. Staff Tech, Inc., B-403035.2, B-403035.3, Sept. 20, 2010, 2010 CPD ¶ 233 at 6. A finding that proposals are essentially equivalent technically means that there is no meaningful difference in what the proposals have to offer. AMEC Earth & Environmental, Inc., B-404959.2, July 12, 2011, 2011 CPD ¶ 168 at 9. Thus, it was not necessary to perform a price/technical tradeoff. Staff Tech, Inc., supra. Moreover, in light of the fact that no tradeoff was required, we see no basis to conclude that the agency failed to adequately document its source selection decision here. See The MIL Corp., B-297508, B-297508.2, Jan. 26, 2006, 2006 CPD ¶ 34 at 14.
The protest is denied.
Thomas H. Armstrong
 Our Office conducted a hearing in this protest on January 10, 2019, during which the agency provided the testimony of the Source Selection Evaluation Board Technical/ Management Chair (hereinafter "Technical Chair"). Transcript citations in the decision are to the transcript of this hearing.
 The agency amended the RFP 15 times. Memorandum of Law (MOL) at 3. All citations to the RFP are to the conformed copy included at Tab 2 of the agency report.
 Very generally, SPARC is a computing chipset used to support computing processing and the running of the Solaris operating system. Hearing Transcript (Tr.) at 13:10-13. The SPARC hardware can be used for a number of various business-type applications. Id. at 13:22-14:3. The term "on-demand," as it is used here, refers to the contractor's ability to "grow" or "shrink" capacity or computing power in an expedited manner as needed by the agency. Id. at 20:4-20. The "processor infrastructure services" requested here primarily include maintenance of the equipment. Id. at 21:4-8.
 The seven subfactors are as follows: (1) technical solution (SPARC compatible); (2) technical solution (virtualization); (3) transition plan; (4) capacity; (5) integration/ interfaces; (6) performance/availability; and (7) technical requirements and architecture. AR, Tab 2J, RFP § M.2.0, at 3.
 The RFP provided that subfactor ratings would not be "rolled up" into an overall rating for the technical/management factor. AR, Tab 2J, RFP § M.2.1.1, at 3.
 Both offerors' proposed prices were found to be complete and reasonable. AR, Tab 7, SSDD, at 40.
 In its protest, Oracle also challenged the agency's evaluation of ViON's proposal under these same two subfactors, i.e., technical solution (SPARC compatible) and transition plan, respectively. Protest at 14-19. In response to a request for partial dismissal filed by the intervenor, our Office dismissed Oracle's challenge to the evaluation of ViON's proposal, concluding that Oracle failed to provide a detailed statement of the legal and factual grounds of protest, as required by our Bid Protest Regulations, 4 C.F.R § 21.1(c)(4), 21.1(f), 21.5(f). In this regard, we found that the protester included a few, very general remarks about ViON's proposal, see Protest at 16, 18, but did not allege, with sufficient specificity, that the agency misevaluated ViON's proposal. Accordingly, we dismissed this ground.
 Initially, Oracle argued that its proposal merited eight strengths under subfactor 1. Protest at 15-18. Based upon its review of the record, however, Oracle withdrew its allegation that the agency failed to assess a strength for Oracle's inclusion of an optional subline item number. Comments, Nov. 29, 2018, at 14. During the hearing, Oracle withdrew its allegation that the agency failed to assess two additional strengths for Oracle's proposed use of [DELETED], respectively. Tr. at 143:3-13. Oracle acknowledged that, pursuant to the terms of the RFP, these aspects of its proposal were to be evaluated under subfactor 7 (technical requirements and architecture), which was evaluated on an acceptable/unacceptable basis. Id.
 Section 6.11.1 of the PWS, entitled "Service Transition Strategy," was to be evaluated under multiple subfactors. The RFP clarified that only those aspects of an offeror's proposal pertaining to "physical migrations" would be considered under subfactor 1. AR, Tab 2J, RFP § M.2.1.1, at 5.
 In responding to Oracle's protest, DISA relies heavily upon a declaration from the Technical Chair, in which he explains why Oracle's proposal did not merit any strengths. See AR, Tab 12, Technical Declaration. Oracle asserts that the declaration is "nothing more than a post hoc rationalization" submitted in the "heat of litigation," and, consequently, that our Office should afford it no weight. Comments at 9. We disagree. Notwithstanding the protester's suggestions to the contrary, the agency was not required to document "determinations of adequacy" or otherwise explain why aspects of Oracle's proposal did not merit a strength. See Innovative Solutions, Inc., B-414650.8, B-414650.13, May 2, 2018, 2018 CPD ¶ 167 at 7 n.7; Building Operations Support Servs., LLC, B-407711, B-407711.2, Jan. 28, 2013, 2013 CPD ¶ 56 at 5. See also Federal Acquisition Regulation § 15.305(a) ("The relative strengths, deficiencies, significant weaknesses, and risks supporting proposal evaluation shall be documented in the contract file."). As DISA aptly argues, to mandate otherwise would "require the Agency to constantly shadow box by trying to anticipate what an offeror might consider a strength, and if such a strength was not assigned, to explain why." MOL at 37.
 Oracle does not claim that the alleged cost savings are reflected in its price proposed for the requirement here. See Oracle's Post-Hearing Comments at 9. Rather, Oracle explains that its [DELETED] solution permits the agency to purchase [DELETED], which Oracle alleges are significantly less expensive than fiber switches. Id. (explaining that [DELETED]). See also Tr. at 66:5-67:9. The switches-[DELETED]--are procured through a different contract vehicle, referred to as the CSC II contract. Tr. at 94:18-20. Accordingly, Oracle's argument is that the agency could realize cost savings on the CSC II contract by implementing Oracle's [DELETED] solution. Oracle's Post-Hearing Comments at 9.
 Although the agency's current environment uses copper connections, the agency represented that fiber connections or a mixed solution would be compatible with the agency's infrastructure. Tr. at 72:10-73:10.
 The agency explained that only copper switches and copper cabling can be used with a copper connection and only fiber switches and fiber cabling can be used with fiber connections. Tr. at 24:14-19, 29:2-4, 72:5-9. They are not interchangeable. Id. at 24:14-19.
 When asked how probable it was that the industry would trend back to copper, the Technical Chair responded that "[i]t would be difficult for me to say, but we usually don't go backwards in technology." Tr. at 88:16-22.
 In its post-hearing comments, Oracle contends that DISA applied unstated evaluation criteria. Oracle's Post-Hearing Comments at 2. In this regard, Oracle maintains that, although there was no requirement in the RFP for a specific approach, the record shows that the agency had an unannounced preference for standardization over flexibility and a preference to move towards an all-fiber solution. Id. Oracle's arguments are unavailing. The record indicates that the agency did not downgrade Oracle's proposal on account of its proposed solution. To the extent Oracle complains that it was not informed that an all-fiber solution would have been considered more favorably, such disclosure was not necessary. Where, as here, the solicitation allows for alternative approaches to meeting the agency's requirements, the agency is not required to advise a technically acceptable offeror that it considers another approach to be superior to that proposed by the protester. American States Utilities Servs., Inc., B-291307.3, June 30, 2004, 2004 CPD ¶ 150 at 5; Cerner Corp., B-293093, B-293093.2, Feb. 2, 2004, 2004 CPD ¶ 34 at 8.
 Unlike the network connections, where the PWS did not specify the use of fiber or copper, the PWS mandated the use of fiber for storage connections. AR, Tab 2A, PWS § 18.104.22.168, at 7; Tr. at 109:12-15.
 Very generally, an HBA card is a device that supports connectivity between a server and a storage device. Tr. at 53:11-13, 109:7-11.
 The RTO is the duration of time and a service level within which a business process must be restored after a disruption in order to avoid unacceptable consequences associated with the break in business continuity.
 Oracle points out that the agency's evaluators concluded that Oracle's proposed solution of using [DELETED] network ports does not require more cabling than is currently being used in Oracle's incumbent SPARC system. Oracle's Post-Hearing Comments at 11; AR, Tab 5, Technical Report, at 8. We fail to see the relevancy of this fact. The relevant inquiry is not what Oracle is providing on its incumbent contract, but rather whether Oracle's proposed solution of using [DELETED] network ports would require more cabling than what is required by the solicitation--a solution that uses four network ports.
 Oracle also claims that its proposal merited a strength under subfactor 1 for its offer to provide [DELETED] as part of its transition plan under section 22.214.171.124 of the PWS, Incoming Strategy Plan. Protest at 17-18 (citing AR, Tab 4, Oracle's Technical Proposal, at II-31); Comments at 18. The agency, however, correctly notes that section 126.96.36.199 was not included in the RFP as one of the sections of the PWS to be evaluated under subfactor 1. Id.; AR, Tab 2J, RFP § M.2.1.1, at 5. Thus, Oracle's claim that its proposal merited a strength under subfactor 1 for its approach meet the requirements of section 188.8.131.52 of the PWS is unavailing.