Skip to main content

LS3 Technologies Inc.

B-407459,B-407459.2 Jan 07, 2013
Jump To:
Skip to Highlights

Highlights

LS3 Technologies Inc., of Odenton, Maryland, protests the award of a task order to Electrosoft Services, Inc., of Reston, Virginia, under request for quotations (RFQ) No. VA118-12-R-0438, issued by the Department of Veterans Affairs (VA) for an Enterprise physical access control system (ePACS). The protester argues that the agency unreasonably found its proposal unacceptable, and that the award to Electrosoft was flawed because the awardee’s proposal included items that were not on its FSS contract and because the agency failed to evaluate the realism of the awardee’s price.

We deny the protest.
View Decision

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.

Decision

Matter of: LS3 Technologies Inc.

File: B-407459; B-407459.2

Date: January 7, 2013

Fernand A. Lavallee, Esq., Seamus Curley, Esq., and C. Bradford Jorgensen, Esq., DLA Piper US LLP, for the protester.
Katherine S. Nucci, Esq., Timothy Sullivan, Esq., and Scott F. Lane, Esq., Thompson Coburn LLP, for Electrosoft Services, Inc., the intervenor.
James V. Scuro, Esq., and Colin L. Nash, Esq., Department of Veterans Affairs, for the agency.
Jonathan L. Kang, Esq., and James A. Spangenberg, Esq., Office of the General Counsel, GAO, participated in the preparation of the decision.

DIGEST

1. Protest challenging the evaluation of the protester’s technical approach is denied where the agency reasonably concluded that the lack of detailed information regarding material solicitation requirements rendered its proposal unacceptable.

2. Protest challenging an award under the Federal Supply Schedule that included items labeled “open market” is denied where the record shows that the items were inaccurately labeled and were in fact part of a larger item that was on the awardee’s schedule contract.

DECISION

LS3 Technologies Inc., of Odenton, Maryland, protests the award of a task order to Electrosoft Services, Inc., of Reston, Virginia, under request for quotations (RFQ) No. VA118-12-R-0438, issued by the Department of Veterans Affairs (VA) for an Enterprise physical access control system (ePACS).[1] The protester argues that the agency unreasonably found its proposal unacceptable, and that the award to Electrosoft was flawed because the awardee’s proposal included items that were not on its FSS contract and because the agency failed to evaluate the realism of the awardee’s price.

We deny the protest.

BACKGROUND

The RFQ was issued on July 20, 2012, and sought proposals to provide an ePACS solution for the VA. The solicitation explained that the VA currently uses a number of physical access control systems (PACS) to control access to VA facilities. RFQ at 23. The successful offeror will be required to design, implement, and support an ePACS solution that will incorporate and connect the agency’s existing PACS, in a manner that complies with various security and privacy regulations, including Homeland Security Presidential Directive 12, and Office of Management and Budget Memorandum M-11-11. RFP at 23-25. Although the scope of the task order requires the ePACS to be implemented at the VA Central Office facilities in Washington, DC, the solicitation stated that the proposed ePACS must be “scalable to supporting the more than 6,000 VA facilities.” RFQ at 25-26.

The competition was a small business set-aside, and was limited to firms who hold contracts under FSS contract No. 70. The RFQ anticipated award of a fixed-price and time-and-materials task order with a base period of 1 year, and one 1-year option. The RFQ advised that proposals would be evaluated based on the following four factors: (1) technical, (2) past performance, (3) veterans involvement, and (4) price. RFQ at 77. For purposes of award, the technical factor was “more important” than price; price was “slightly more important” than past performance; and past performance was “slightly more important” than veterans involvement. RFQ at 76. As relevant here, the solicitation stated that, “[t]o receive consideration for award, a rating of no less than ‘Acceptable’ must be achieved for the Technical Factor.”[2] Id.

The VA received two proposals, from LS3 and Electrosoft, by the closing date of August 10. The agency found that LS3’s proposal had no significant strengths, one strength, two weaknesses, one significant weakness, and six deficiencies. Agency Report (AR), Tab K, LS3 Technical Evaluation, at 2-4. As relevant here, the six deficiencies concerned the proposal’s failure to adequately address the following solicitation requirements: (1) scalability; (2) emerging PACS technology; (3) data integrity; (4) security requirements; (5) data storage; and (6) system latency. Id. at 3-4. Based on the deficiencies, the VA rated LS3’s proposal as unacceptable for the technical factor, stating that its proposal “indicates a lack of understanding of the problem and involves a very high risk approach,” and that “these errors and omissions could not be corrected without a major rewrite or revision of the proposal.” Id. at 6.

The VA found that Electrosoft’s proposal was technically acceptable, based on a rating of good for the technical evaluation factor. AR, Tab H, Source Selection Decision (SSD), at 2. The agency concluded that discussions were not required with the offerors in order to make award. Id. at 4. The agency, however, requested that Electrosoft provide information concerning “how your total proposed price breaks down in correlation to the products and services on your GSA Schedule 70 contract.” AR, Tab I, Electrosoft Clarification Request, at 1. The agency stated that the request was for a clarification of the offeror’s price, and that “adjustments shall not be made to your proposal at this time.” Id. Electrosoft responded to the request by providing a chart showing the prices for products and services proposed by the offeror and its subcontractors, and the applicable FSS contract for each item. AR, Tab I, Electrosoft Clarification Response, at 1. As discussed below, the prices for one of Electrosoft’s proposed subcontractors, Quantum Secure, included items that were labeled “open market,” rather than indicating the FSS contract on which they were available. Id.

The VA’s evaluation of the offerors’ proposals was as follows:

LS3

ELECTROSOFT

Technical

Unacceptable

Good

Past Performance Risk

Low Risk

Low Risk

Veterans Involvement

No credit

Some consideration

Price

$1,924,337

$6,897,193

AR, Tab H, SSD, at 2.

The contracting officer (CO), who was also the source selection authority, noted that while LS3 proposed a significantly lower price than Electrosoft, the protester’s proposal was unacceptable based on “significant errors and omissions” in its technical proposal which could not be corrected without discussions. Id. at 4. The CO selected Electrosoft’s proposal for award because it received a good rating under the technical factor, and the proposed price was fair and reasonable. Id. at 3-4. On September 24, the VA advised LS3 of the award to Electrosoft. This protest followed.

DISCUSSION

LS3 argues that the VA unreasonably found its proposal technically unacceptable, and thus improperly excluded it from award. The protester also argues that the award to Electrosoft was improper because its proposal included open-market items that were not on its FSS contract. Finally, the protester argues that the agency failed to evaluate the realism of the awardee’s proposed price. For the reasons discussed below, we find no basis to sustain the protest.[3]

Technical Acceptability

As discussed above, the VA identified six deficiencies in LS3’s proposal, and concluded that none of the deficiencies could be corrected without a “major rewrite or revision of the proposal.” AR, Tab K, LS3 Technical Evaluation, at 5. The protester argues that none of the deficiencies assessed for its proposal were reasonable, and that the agency should have considered its proposal for award. We discuss the first deficiency below, and because we find that it was reasonably assessed we need not address the other deficiencies.

Where, as here, an agency issues an RFQ to FSS contractors under Federal Acquisition Regulation (FAR) subpart 8.4 and conducts a competition, we will review the record to ensure that the agency’s evaluation was reasonable and consistent with the terms of the solicitation and applicable procurement laws and regulations. Digital Solutions, Inc., B-402067, Jan. 12, 2010, 2010 CPD ¶ 26 at 3-4. A protester’s mere disagreement with the agency’s judgment does not establish that an evaluation was unreasonable. DEI Consulting, B-401258, July 13, 2009, 2009 CPD ¶ 151 at 2. In a competitive FSS procurement, it is the vendor’s burden to submit a quotation or proposal that is adequately written and establishes the merits of the quotation or proposal. The Dixon Group, Inc., B-406201, B-406201.2, Mar. 9, 2012, 2012 CPD ¶ 150 at 6.

The first deficiency for LS3’s proposal concerned its approach to the scalability requirements, that is, the approach to expanding its proposed ePACS from the initial test facilities to all VA facilities. The statement of work (SOW) required offerors to address the following requirement:

The Contractor shall provide systems engineering, architecture, development, deployment, testing, operations and maintenance, training, and installation activities necessary to provide VA with a multi-vendor centralized ePACS access control server (head-end) scalable to supporting the more than 6,000 VA facilities with an easy to use ePACS dashboard providing control, displaying, and reporting ePACS situational awareness.

RFQ at 25-26. The solicitation instructed offerors to address the following requirements in their proposals:

(i) VOLUME I – TECHNICAL FACTOR. Offerors shall propose a detailed approach that addresses the following:

* * * * *

b) Expertise in scaling PACS systems to extremely large, complex, and secure ePACS.

RFQ at 80.

The agency’s evaluation identified a deficiency in LS3’s proposal, as follows:

The Offeror’s proposal failed to provide detail on how the Offeror can scale PACS systems to extremely large, complex, and secure ePACS. The Solicitation requires that the ePACS solution be scalable to support more than 6,000 VA facilities. In its proposal, the Offeror failed to show how it would meet this requirement. . . . This lack of detail appreciably increases the risk to the Government of the Offeror successfully performing the contract to an unacceptable level.

AR, Tab K, LS3 Technical Evaluation, at 3.

LS3’s protest contained a 41-page document responding to each of the deficiencies, with detailed annotations and explanations as to why its proposal was technically acceptable. See Protest, attach. C. With regard to the scalability requirement, LS3 contends that it’s proposal contained a number of references which related to scalability. The protester contends that these features, collectively, should have led the agency to understand that it met the requirements for scalability.

The agency contends that the references, which were in different parts of its proposal, did not adequately address the requirement to explain in detail its approach to scalability. The agency further argues that the protester’s arguments concerning the deficiency rely primarily on detailed explanations or characterizations of its approach which were not provided in its proposal. We agree, and address several examples below.

First, LS3 notes that its proposal described a “hub and spoke” network configuration approach:

The ePACS solution will be implemented with a hub and spoke network configuration that integrates all local PACS solutions to the common ePACS network configuration. The network configuration will leverage multiple paths to each PACS end-point to ensure that more than 1 network path is always available to support provisioning and deprovisioning services between the ePACS back end infrastructure and each PACS endpoint solution. LS3 is pleased that this important communications issue is being addressed by VA.

AR, Tab Q, LS3 Technical Proposal, at 8.

LS3 contends that this description demonstrates that its proposal met the scalability requirements because it “expresses a solution architecture that is infinitely scalable to any number of ‘spokes’ that connect to a solution ‘hub.’” Protest, attach. C, at 8.

The VA argues that the description of the hub and spoke network addressed the offeror’s network configuration, but did not specifically discuss the way in which the configuration related to the offeror’s approach to the scalability requirements. We agree that the proposal did not specifically address scalability. Further, the explanation provided in the protest that the hub and spoke network configuration was “infinitively scalable”--and therefore met the solicitation requirements--was not apparent from the proposal.

Next, LS3 argues that its discussion of the two sites required under the RFQ to host the “backend” of the ePACS solution demonstrates that it could meet the scalability requirements, as follows:

The ePACS will be configured where each “Site” (e.g., Martinsburg or Richmond) will be sized and equipped to host the VA enterprise need. We will provide this configuration specification within our System Design under the Section 2.2.5 task.

AR, Tab Q, LS3 Technical Proposal, at 11.

LS3 contends that this quote from its proposal should have been understood to address scalability, for the following reason:

This LS3 response demonstrates capability to address all VA facilities with our overall implementation approach. It further stipulates that we will provide a proven design as part of our design work within Section 2.2.5, which obviously is inclusive of scalability needs.

Protest, attach. C, at 8.

The VA argues that LS3’s proposal merely restated the RFQ requirement to ensure that the two “backend” facilities for the ePACS solution in Martinsburg, West Virginia, and Richmond, Virginia, could independently handle the entire workload. See RFQ at 32. We agree. The protester’s proposed approach merely confirms that it would be “sized and equipped” to meet the agency’s needs with regard to the backend facilities; it did not discuss the requirement to scale the ePACS to the 6,000 VA facilities. Although the protester contends that its proposed approach “obviously” addressed the scalability requirements, we do not think that its proposal clearly addressed this requirement.

Next, LS3 argues that its discussion of its compliance with “VA and Federal requirements” demonstrated that it would meet the scalability requirements, as follows:

We will utilize these Use Cases [a series of defined steps] as lifecycle artifacts that incorporate all requirements early on in the project execution and that are leveraged at the end of our implementation as major components of our Test Cases that will demonstrate full compliance with all VA and Federal requirements.

AR, Tab Q, LS3 Technical Proposal, at 13.

LS3’s protest argued that this quote from its proposal should have been understood to address scalability, for the following reason:

This response demonstrates LS3 understands that ALL requirements that pertain to this opportunity leverage a methodology that ensures that all VA requirements will be satisfied. It further demonstrates that our solution for VA will be in full compliance to ALL Federal and VA requirements with our resulting solution, which is inclusive of all functional and non-functional requirements that include scalability and security.

Protest, attach. C at 9 (emphasis in original).

VA argues that LS3’s proposal merely states that it will comply with applicable requirements, and does not explain any specific details regarding scalability. We agree. Neither LS3’s proposal nor its protest specifically explains the protester’s proposed approach to the scalability requirements. Where, as here, a solicitation requires an offeror to explain its approach to specific requirements, an agency may reasonably find a blanket statement that the offeror will comply with the requirements to be deficient. See T-L-C Sys., B-287452, June 18, 2001, 2001 CPD ¶ 106 at 4.

Finally, LS3 states that its proposed subcontractor, Johnson Controls, Inc. (JCI) has built and tested a product called the Global Provisioning Access Control System (GPACS), which will be the “core” of LS3’s proposed ePACS solution. See AR, Tab Q, LS3 Technical Proposal, at 2. The protester contends that its proposal addressed JCI’s experience and thus demonstrated that LS3’s approach to the ePACS requirement was adequate, as follows:

JCI has validated and tested large scale deployment of the GPACS solution at the Center for Medicare and Medicaid Systems (CMS) customer environment and the solution can scale to support this requirement.

AR, Tab Q, LS3 Technical Proposal, at 11.

LS3’s protest argued that this quote from its proposal should have been understood to address scalability, for the following reason:

This LS3 response demonstrates the [commercial off the shelf] vendor’s validation that the solution can address the need for 6,000 VA facilities, without obligating that vendor to disclose sensitive information pertaining to their current customer.

Protest, attach. C at 9.

In its evaluation, the VA stated that LS3’s proposal merely stated that its proposed subcontractor had “validated and tested a large scale deployment” of its GPACS system, but did not provide adequate details as to how LS3 would use JCI’s system to develop an ePACS that could support the 6,000 VA facilities. AR, Tab K, LS3 Technical Evaluation, at 3. We think the agency’s concern was reasonable, in that the brief statement in LS3’s proposal merely addresses the experience of its subcontractor, and not the protester’s proposed approach to scalability.

In sum, we conclude that the agency reasonably identified a deficiency for LS3’s proposal regarding the scalability requirements, and assigned a rating of unacceptable.

Open Market Items in Electrosoft’s Price

Next, LS3 argues that the award to Electrosoft was improper because its proposal contained open market items, that is, items not on its FSS contract. For the reasons discussed below, we find no basis to sustain the protest.

As a general matter, FSS procedures provide agencies a simplified process for obtaining commonly used commercial supplies and services, and, although streamlined, satisfy the requirement for full and open competition. See 41 U.S.C. §259(b)(3) (2006); FAR § 6.102(d)(3). However, non-FSS products and services--frequently termed “open market”--may not be purchased using FSS procedures; their purchase requires compliance with otherwise applicable procurement laws and regulations, including those requiring the use of full competitive procedures. Symplicity Corp., B–291902, Apr. 29, 2003, 2003 CPD ¶ 89 at 4. Thus, where an agency announces its intention to order from an existing FSS, all items quoted and ordered are required to be on the vendor’s schedule contract as a precondition to its receiving the order. Science Applications Int’l Corp., B-401773, Nov. 10, 2009, 2009 CPD ¶ 229 at 2 n.1. The sole exception to this requirement is for items that do not exceed the micro-purchase threshold of $3,000, since such items properly may be purchased outside the normal competition requirements. See FAR § 2.101; Maybank Indus., LLC, B-403327, B-403327.2, Oct. 21, 2010, 2010 CPD ¶ 249 at 4.

As discussed above, the VA requested that Electrosoft provide the following information regarding its proposed price:

Please provide clarification of how your total proposed price breaks down in correlation to the products and services on your GSA Schedule 70 contract. For services, please provide the GSA Schedule 70 labor category proposed, as well as total proposed hours for each category.

AR, Tab I, Electrosoft Clarification Request, at 1.

Electrosoft provided a spreadsheet detailing the products and services proposed for itself and its subcontractors, including a bill of materials (BOM) from its proposed subcontractor Quantum Secure. AR, Tab I, Electrosoft Clarification Response, at 6. The Quantum Secure BOM listed seven products comprising or associated with its SAFE software, four of which were listed on Electrosoft’s FSS contract, and three of which were listed as “Open Market.” Id. These items were as follows:

BOM Item

Product

FSS Schedule

1

SAFE For Government

132-33

2

SAFE PACS Agents

132-33

3

SAFE ERP/HRMS/IDM Agent

132-33

4

SAFE Data Source Agent

132-33


5

SAFE Platform: Policy,

Orchestration and Integration


Open Market

6

SAFE Data Match and Reconciliation

Open Market

7

SAFE High Availability License

Open Market

Id.[4]

The VA’s evaluation of Electrosoft’s proposal did not address the inclusion of items listed as open market, and the agency states that it was not aware of the reason why the items were listed as open market. Supp. AR (Dec. 11, 2012), at 1.

In response to the protest, the intervenor explains that the three items listed as open market on the Quantum Secure BOM were mistakenly included as separate items. Quantum Secure and Electrosoft currently have an agreement wherein Quantum Secure’s products are offered on Electrosoft’s FSS contract. Decl. of Quantum Secure Sales Director (Dec. 10, 2012) ¶ 4; Decl. of Electrosoft CEO (Dec. 5, 2012) ¶ 2. Quantum Secure explains that it had previously included the price of the fifth and seventh items in the cost of the first item, which is the primary “bundle” of software to be provided. Decl. of Quantum Secure Sales Director (Dec. 10, 2012) ¶¶ 5a, 5b. Prior to providing the BOM to Electrosoft for this procurement, however, Quantum Secure began listing items five and seven separately on BOMs to reflect increased costs from Quantum’s suppliers. Id. Because of this change, Quantum Secure states that it listed items five and seven separately on the BOM for this procurement, despite its intent to include them in the price for item one; because the items were not available as separate items on Electrosoft’s FSS contract, they were listed in the BOM as open market items. Id. ¶¶ 5a, 5b, 6. Quantum Secure states that it will honor the price for the first item as including the fifth and seventh items. Id. ¶ 4; Email from Quantum Secure to Electrosoft (Dec. 3, 2012), at 1.

The VA and Electrosoft contend that the information provided by Quantum Secure demonstrates that items five and seven were intended to be included as part of the price of item number one, which was on Electrosoft’s FSS contract. We think the record here supports the agency’s and intervenor’s arguments, and that items five and seven are properly viewed as part of the intended price for item one. For this reason, these items should not be viewed as open market items outside of Electrosoft’s FSS contract.

With regard to the sixth item, Quantum Secure does not contend that the item was intended to be included in the price of an item that was available on Electrosoft’s FSS contract. Instead, the Quantum Secure states that item six “is not an actual deliverable to the VA that must be present for the system to operate and meet the SAFE software infrastructure requirements,” and was instead a tool for “internal use” by Electrosoft in installing and configuring the SAFE software. Decl. of Quantum Secure Sales Director (Dec. 10, 2012) ¶ 5c. We need not resolve whether the explanation for the inclusion of item six on the BOM was reasonable, because the price of this item was under the micro-purchase threshold. In this regard, the price for item six under was listed as $[deleted], but was, along with the other items listed in the BOM, discounted by [deleted] percent. AR, Tab I, Electrosoft Clarification Response, at 6. Applying this discount to item six yields a price of $[deleted], which is under the micro-purchase threshold of $3,000. Thus, even though item six was not included in the price of an item already on Electrosoft’s FSS contract, the item could have, in any case, been purchased without regard to the FSS or any other competition requirement. See Maybank Indus., LLC, supra. On this record, we find no basis to sustain the protest.[5]

Price Evaluation

Finally, LS3 argues that the VA failed to evaluate the realism of Electrosoft’s proposed price. The RFQ did not provide for the evaluation of the realism of offerors’ proposed prices. See RFQ at 78. Under such circumstances, the agency was not permitted to conduct a price realism evaluation, that is, an evaluation of offerors’ proposed prices to identify performance risk regarding their understanding of the solicitation requirements. See FAR § 15.404-1(d)(3); Milani Constr., LLC, B-401942, Dec. 22, 2009, 2010 CPD ¶ 87 at 4-5 (protest sustained where the solicitation did not provide for a price realism evaluation, and the agency’s evaluation of the protester’s proposal relied on such an evaluation).

The VA’s evaluation of LS3’s technical proposal did not address the protester’s proposed price. In the selection decision, however, the CO made the following comment regarding the offerors’ proposed prices:

Although [LS3’s] price was significantly less than both [Electrosoft’s] proposed price and the independent Government cost estimate (IGCE), the significant price difference, paired with their unacceptable technical volume, further substantiates that [LS3] did not have a clear understanding of the requirements set forth in the solicitation.

AR, Tab H, SSD, at 2-3.

LS3 argues that the CO’s reference to its proposed price demonstrates that the agency conducted an improper price realism evaluation. The protester further argues that the award to Electrosoft was improper because the agency failed to conduct a realism evaluation regarding the awardee’s price.

Even if the CO’s reference to LS3’s proposed price could be construed as a price realism evaluation, there was no prejudice to the protester. The statement cited by the protester does not state that its technical proposal was found unacceptable based on a price realism evaluation. Instead, the CO stated that LS3’s proposal was technically unacceptable, and that its low price was further evidence of its lack of understanding of the technical requirements. AR, Tab H, SSD, at 2-3. Thus, the fact that the agency may have found that LS3’s low price provided further support for its concerns regarding the protester’s understanding of the requirements does not change the fact that its proposal was technically unacceptable, and thus ineligible for award.

With regard to the evaluation of Electrosoft’s proposal, there is no basis to argue that the agency should have conducted an evaluation of the realism of the awardee’s proposed price. As stated above, the RFP did not provide for such an evaluation, and thus any such evaluation would have been improper. See Milani Constr., LLC, supra. For this reason, even if we were to conclude that the agency treated the offerors unequally with regard to the evaluation of price, this matter did not affect the eligibility of the protester’s proposal for award. See NCI Info. Sys., Inc., B-405589, Nov. 23, 2011, 2011 CPD ¶ 269 at 6 n.5 (protester was not prejudiced even if agency improperly conducted a price realism evaluation because its proposal was otherwise technically unacceptable).

The protest is denied.

Susan A. Poling
General Counsel



[1] Although the solicitation was an RFQ that anticipated the issuance of a task order under the General Services Administration’s Federal Supply Schedule (FSS), the evaluation record here refers to “offerors” and “proposals.” For the sake of consistency, and because the distinction between a quotation and a proposal has no material bearing on our analysis in this protest, we adopt the usage of the terms “proposal” and “offerors” in this decision.

[2] For the technical factor, the agency assigned the following ratings: outstanding, good, acceptable, susceptible to being made acceptable, or unacceptable; for the past performance factor the agency assigned the following ratings: high risk, moderate risk, low risk, or unknown risk; for the veterans involvement factor, the agency used the following ratings: full credit, partial credit, or some consideration. AR, Tab U, Source Selection Plan, at 9-10.

[3] LS3 raises other collateral arguments. For example, the protester argues that the agency failed to give it credit under the veterans involvement factor. Because we conclude that the VA reasonably rejected LS3’s proposal as unacceptable, the protester is not an interested party to raise this issue. We have reviewed all of the issues raised by the protester, and find no basis to sustain the protest.

[4] LS3 also argues that the VA’s exchanges with Electrosoft were discussions, and that the agency was required to conduct discussions with the protester and provide it an opportunity to address the deficiencies in its proposal. As discussed above, the information provided by Electrosoft confirming its proposed prices and their correlation to FSS contracts did not result in a material change to the proposal. For this reason, and to the extent we apply the general principles of negotiated procurement under FAR part 15 to this part 8.4 procurement, the agency did not conduct discussions with Electrosoft, and was therefore not required to conduct discussions with LS3 to address the deficiencies in its proposal. See Pinnacle Solutions, Inc., B-406998, B-406998.2, Oct. 16, 2012, 2012 CPD ¶ 338 at 7.

[5] As the intervenor acknowledges, the mistakes in the BOM regarding items five, six, and seven results in a lower price to Electrosoft by approximately $[deleted] which should be passed on to the government. Intervenor’s Comments (Dec. 11, 2012), at 4.

Downloads

GAO Contacts

Office of Public Affairs