United States Government Accountability Office

Washington, DC 20548

Comptroller General

of the United States

 

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

 

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 

 The protester argues that the 

(continued...)

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.
Page 2 B-407459, B-407459.2 

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

 

(...continued)

no material bearing on our analysis in this protest, we adopt the usage of the terms 

“proposal” and “offerors” in this decision.

 Id.

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.
Page 3 B-407459, B-407459.2 

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 
Page 4 B-407459, B-407459.2 

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. 

 

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.
Page 5 B-407459, B-407459.2 

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. 
Page 6 B-407459, B-407459.2 

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. 
Page 7 B-407459, B-407459.2 

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). 
Page 8 B-407459, B-407459.2 

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. 
Page 9 B-407459, B-407459.2 

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
Page 10 B-407459, B-407459.2 

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 

 

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.
Page 11 B-407459, B-407459.2 

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). 

 

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.
Page 12 B-407459, B-407459.2 

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