Matter of: Robbins-Gioia, Inc. File: B-274318; B-274318.2; B-274318.3; B-274318.4 Date: December 4, 1996 * Redacted Decision
Admission of an in-house counsel to a General Accounting Office protective order was appropriate over the objection of the contracting agency, where the record showed that the in-house counsel did not participate in competitive decision-making and that there was not otherwise an unacceptable risk of inadvertent disclosure of protected information; the agency’s objection that the in-house counsel reported to corporate officials that advise and participate in competitive decision-making does not itself establish that the in-house counsel advises or participates in competitive decision-making herself. In a negotiated procurement for information system modernization and integration, the contracting agency reasonably assessed the protester’s proposed immediate implementation of a distributed object computing architecture as representing a moderate risk–potentially causing some disruption of schedule, increase in cost, or degradation of performance– where the agency found that protester’s proposed architecture was based upon emerging technology that was not yet fully supported in the marketplace and which would entail a substantial amount of custom software development. Protest that the contracting agency treated the protester and the awardee unequally in the agency’s proposal risk assessment of the two firms’ proposed architectures is denied, where the protester proposed the immediate implementation of a distributed object architecture with a substantial amount of custom software development, which the agency assessed as a moderate proposal risk, while the awardee proposed the more mature distributed computing environment architecture, emphasized the use of commercial-off-the-shelf software, and promised to evolve into a distributed object approach, as that technology evolved, which the agency assessed a low proposal risk. Protest that the contracting agency did not conduct meaningful discussions with the protester because the agency did not specifically inform the protester that the agency viewed its offer to immediately implement a distributed object computing approach as a moderate risk is denied, where the agency conducted several rounds of written and oral discussions that identified a number of concerns with the protester’s proposed architecture and provided the protester with significant opportunities to explain and support its proposed architectural approach. The contracting agency appropriately considered past experience information in its evaluation of the protester’s proposal under the development/implementation processes evaluation factor, where that factor specifically provided for consideration of offerors’ relevant experience in system engineering, customer training, and life-cycle management support. The contracting agency properly limited its consideration under the performance risk factor of the awardee’s performance of major system procurements to procurements that the awardee itself had performed, as opposed to procurements performed by other divisions of the corporation of which the awardee was a part, where the awardee and the other divisions are separate entities within the parent corporation, and the record establishes that the other divisions will not be involved in the performance of the contract to be awarded. Protest that the contracting agency misevaluated the protester’s performance risk is denied, where the agency appropriately considered the satisfactory and relevant performance of the protester’s proposed subcontractors, but found that although the protester’s past performance was satisfactory its experience was on “somewhat relevant” contracts, none of which was of the magnitude or complexity of the contract to be awarded, and the protester had no specific experience as a general contractor, which was the role it proposed for itself in this procurement. The contracting agency properly considered proposals submitted by the awardee and another offeror, which were a subsidiary and division, respectively, of a larger corporation, despite the solicitation prohibition against offerors’ submitting more than one proposal, where the agency reasonably determined that the awardee and the other corporate division were separate business entities, and the record shows that the awardee did not have an unfair advantage or that the government’s interests were prejudiced.
Robbins-Gioia, Inc. protests the award of a contract to Lockheed Martin Federal Systems, Inc. (LMFS) under request for proposals (RFP) No. F1620- 95-R-A245, issued by the Department of the Air Force for services supporting the agency’s base level system modernization (BLSM) of the Global Combat Support System (GCSS). Robbins-Gioia challenges the agency’s evaluation of proposals and conduct of discussions.
We deny the protest.
The GCSS program is the second phase of an umbrella program to incrementally modernize Department of Defense (DOD) standard information systems, which, among other things, will provide a Common Operating Environment (COE) for each application. These modernized systems will integrate existing legacy systems  that make up DOD’s GCSS and migrate these systems to an open systems environment using the appropriate COE. In support of this program, the RFP sought a total systems integration contractor to modernize, integrate, evolve, and maintain 26 functionally aligned Air Force standard base level AISs,  and to develop hardware and software technologies to establish COEs to host these modernized AISs on a variety of open platforms. These 26 standard Air Force information systems, consisting of nearly 9 million lines of predominantly old COBOL software, residing on proprietary Wang and Unisys mainframe computers and early AT&T UNIX computers, track supply, maintenance, contracting, financial, logistics planning, police, bombs and ammunition, pilot flying hours, and cargo load planning actions at Air Force installations world wide. The agency’s Standard Base Supply System (SBSS) was identified as the first system to be modernized.
The RFP provided for the award of an indefinite delivery, indefinite quantity contract with fixed-price, cost reimbursable, and labor hour elements for a 10-year term.  The stated maximum contract value was $1.2 billion. Offerors were informed that other DOD agencies or components would be permitted under the contract to procure COE and other commercial-off-the-shelf (COTS) components, or AIS modernization tasks.
Technical requirements were detailed in a Technical/Management Requirements Document, which referenced applicable specifications and standards for contractor performance. Among other things, offerors were informed that:
“[s]oftware should be developed only after considering affordable, widely used COTS, GOTS [government-off-the-shelf], NDI [nondevelopmental item] and other reusable components . . . . When a procedural language is used, Ada is the preferred choice for new development in support of the proposed software engineering process.” 
The RFP also provided that the Air Force would support an offeror’s request for a waiver of the Ada requirement where the offeror proposed the use of a fourth generation language  to develop personal computer based applications. Offerors were also informed that existing legacy systems must remain operational until replaced Air Force-wide, and that interfaces from legacy to modernized systems must be maintained until the legacy systems are phased out.
The RFP provided that the procurement would be conducted in accordance with the streamlined source selection procedures defined in Air Force Acquisition Regulation Supplement Appendix AA, Formal Source Selection for Major Acquisition. Award was to be made on a best value basis, based upon an integrated assessment of the offerors’ proposals for compliance with solicitation requirements and soundness of approach under stated specific evaluation criteria. The following technical/management evaluation factors were identified:
1. Architecture Assesses the performance characteristics and the Air force-wide impact of the offeror’s overall approach to satisfying the RFP requirements.
2. COEs Assesses the current and planned capability and robustness of the development and runtime COEs, based upon the technical capabilities described and demonstrated in an offeror’s proposal.
3. Management Assesses an offeror’s capability to successfully plan, control, and execute a large scale, complex management information system modernization program within cost and on schedule.
4. Development/Implementation Processes Assesses the capability of an offeror’s systems engineering, implementation, customer training, customer support, and life-cycle management processes to develop, implement, and sustain modernized AISs on schedule, considering affordability throughout the process and the role of government personnel in these processes.
5. SBSS Application Approach Assesses how well the offeror’s proposed COTS/GOTS/NDI components in conjunction with the COE and developed application software satisfy the stated solicitation objectives and constraints.
6. Software Capability Evaluation (SCE) Assesses an offeror’s software development capabilities by evaluating the offeror’s software process improvement plan and using the Software Engineering Institute’s SCE.
Factors 1, 2, and 3 were stated to be of equal importance and higher in priority than factors 4, 5, and 6, which were of equal importance. Offerors were informed that proposals would be color/adjectivally rated  and evaluated for proposal and performance risk. 
The RFP stated that cost/price was significantly less important than the technical/management evaluation factors and provided for various cost/price analyses to evaluate offerors’ proposed costs/prices, including the determination of the offerors’ Proposed Total Contract Cost (PTCC) with Present Value (PV) applied, the Government Estimate of Most Probable Cost (GEMPC), GEMPC with PV applied, and Cost Price Realism Assessment (CPRA).
Detailed proposal preparation instructions were provided that required the submission of six proposal volumes: (1) Executive Summary, (2) Technical/Management, (3) Contract and Associated Information, (4) Cost/Price Proposal, (5) SCE Questionnaire and Project Profiles, and (6) Performance Risk Questionnaire. For each required proposal volume, the RFP detailed the information required. The RFP further stated:
“An [o]fferor may submit a maximum of one fully compliant proposal in response to this solicitation. No alternate proposals will be accepted. If an [o]fferor submits more tha[n] one proposal, all proposals will be returned without evaluation since the [g]overnment would have no basis upon which to determine which of the proposals the [o]fferor desired to have evaluated. For purposes of this solicitation, an [o]fferor is defined as an individual, partnership, proprietorship, joint venture, corporation, or other business entity.”
The RFP also provided for a demonstration at a site to be selected by the offeror, at which the offeror would have the opportunity to clarify its proposed approach, capability, and design.
Proposals were received from seven offerors, including Robbins-Gioia, Loral Federal Systems–Oswego, and Lockheed Martin Management and Data Systems (LMMDS). During the procurement and prior to the submission of best and final offers (BAFO), Lockheed Martin Tactical Systems, Inc., a wholly owned subsidiary of Lockheed Martin Corporation (the parent corporation of LMMDS) acquired, by stock purchase, Loral Federal Systems– Oswego, which became a wholly owned subsidiary of Lockheed Martin Tactical Systems, Inc. and changed its name to LMFS.
The Air Force provided offerors with two rounds of clarification requests (CR) and deficiency reports (DR), attended a demonstration with each offeror, and conducted face-to-face discussions. At the conclusion of discussions, BAFOs were requested from the seven offerors. LMFS’s and Robbins-Gioia’s BAFOs were evaluated as follows:
Adjectival/Risk Rating LMFS Robbins-Gioia
Architecture Blue/Low  Blue/Moderate  COE Blue/Low Blue/Low Management Green/Low Green/Low Processes Blue/Low Green/Moderate SBSS Green/Moderate Green/Moderate SCE Blue/Low Blue/Low
OVERALL Blue/Low Blue/Moderate
Technical Performance Risk Low Moderate
PTCC/PV $207.2M  [DELETED] CPRA/PV $201.1M [DELETED]
Cost Performance Risk Low Low
As indicated, the difference in Robbins-Gioia’s and LMFS’s overall technical/management evaluation score was primarily attributable to Robbins-Gioia’s higher risk rating under the architecture factor, to Robbins-Gioia’s lower adjectival score and higher risk rating under the development/implementation processes factor, and to Robbins-Gioia’s moderate technical performance risk.
With regard to the architecture factor, the agency’s evaluators viewed Robbins-Gioia’s proposed software architecture, which was based upon an immediate implementation of a distributed object oriented solution, as a strong but somewhat risky approach because, in the evaluators’ judgment, distributed object computing was still an “emerging technology.” LMFS, on the other hand, proposed to implement an architecture based on the distributed computing environment (DCE) model, which has been in use in commercial and federal automation systems since the mid-1980s, and to evolve into a distributed object architecture when and if it becomes a more stable and generally accepted standard.
The development/implementation processes factor (for which Robbins-Gioia’s proposal was evaluated as green/acceptable with moderate risk) evaluates an offeror’s capability to develop, implement, and maintain the modernized AISs. Robbins-Gioia proposed a “general contractor” approach to performing the contract effort, in which Robbins-Gioia would coordinate and manage subcontractors that would perform the contract work. While the agency assessed as acceptable the subcontractors’ development and implementation capabilities, it viewed Robbins-Gioia’s lack of experience in managing system engineering processes as a risk. LMFS, on the other hand, was determined to have a proven, strong system engineering process.
Robbins-Gioia’s technical performance risk was evaluated as moderate because of its lack of directly relevant management and development experience on contracts for work of the nature or scope of GCSS. Although Robbins-Gioia’s proposed subcontractors were found to have performed satisfactorily on mostly relevant work, the Air Force was concerned that Robbins-Gioia had not previously performed as a general contractor on any directly relevant contracts of equal magnitude and complexity as the GCSS modernization project. LMFS’s technical performance risk was evaluated as low.
Based upon an integrated assessment of the evaluation record, the source selection authority (SSA) determined, in a detailed source selection decision, that LMFS’s proposal offered the best value to the government. With regard to Robbins-Gioia’s proposal, the SSA found that Robbins- Gioia’s proposal was less desirable than LMFS’s, noting that:
“[while Robbins-Gioia] offer[ed] to lead the program into the 21st century with a solution based on emerging distributed object technologies and, like LMFS, was rated blue in both Architecture and COE[,] [i]t was my conclusion that [Robbins-Gioia’s] approach was riskier than LMFS’s approach due to [Robbins-Gioia’s] (1) planned immediate and extensive use of emerging technologies and developed software in their described architecture and (2) absence of extensive prime contractor experience in implementing large scale software development.”
Because Robbins-Gioia’s proposal was lower-rated and higher-cost/priced than LMFS’s proposal and, in fact, represented the highest evaluated cost/price of the seven offers received, the SSA eliminated Robbins- Gioia’s proposal from further consideration. After consideration of the remaining lower-rated, lower-cost/priced offers, the SSA concluded that LMFS’s superior proposal was the most advantageous to the government. Award was made to LMFS and this protest followed.
ADMISSION TO PROTECTIVE ORDER
A protective order was issued pursuant to section 21.4 of our Bid Protest Regulations, 61 Fed. Reg. 39039, 39044 (1996) (to be codified at 4 C.F.R. Sec. 21.4), which allowed the limited release of confidential or source selection sensitive information to counsel and consultants for Robbins- Gioia and LMFS who were admitted under the protective order. The Air Force objected to the admission of Ms. Alice Crook, an in-house attorney employed by Lockheed Martin Federal Systems, Inc., on the basis that Ms. Crook reports to the Vice President/General Counsel of Lockheed Martin Federal Systems, who is a competitive decision-maker. The Air Force does not assert that Ms. Crook herself advised or participated in competitive decision-making, but contends that “too much is at stake to admit in-house counsel who directly report to persons who engage in competitive decision- making.” Robbins-Gioia did not object to Ms. Crook’s admission under the protective order.
In considering the propriety of granting or denying an applicant admission to a protective order, we review each application in order to determine whether the applicant is involved in competitive decision-making or there is otherwise an unacceptable risk of inadvertent disclosure of protected information should the applicant be granted access to protected material. See McDonnell Douglas Corp., B-259694.2; B-259694.3, June 16, 1995, 95-2 CPD Para. 51. Applicants are neither automatically admitted because they are outside counsel nor automatically denied access because they are in- house counsel. Consistent with the holding in U.S. Steel Corp. v. United States, 730 F.2d 1465 (Fed. Cir. 1984), our Office has no per se rule in this regard. Instead, in reviewing each application for admission to a protective order, we consider and balance a variety of factors, including the nature and sensitivity of the material to be protected, the attorney’s need for the confidential information sought in order to adequately prepare the party’s case, and whether there is opposition to an applicant expressing legitimate concerns that the attorney’s admission would pose an unacceptable risk of inadvertent disclosure. Magnavox Elec. Sys. Co., B-258037; B-258037.2, Dec. 8, 1994, 94-2 CPD Para. 227; Akzo N.V. v. United States Int’l Trade Comm’n, 808 F.2d 1471, 1484 (Fed. Cir. 1986), cert. denied, 482 U.S. 909 (1987); cf. Mastushita Elec. Indus. Co., Ltd. v. United States, 929 F.2d 1577 (Fed. Cir. 1991); U.S. Steel Corp. v. United States, 730 F.2d 1465.
We admitted Ms. Crook to the protective order based upon our finding that Ms. Crook was not involved in competitive decision-making and that there was not otherwise an unacceptable risk of inadvertent disclosure of protected information should Ms. Crook be granted access to protected material. As noted above, it was unrebutted that Ms. Crook herself did not participate in competitive decision-making; in this regard, Ms. Crook stated that she was not involved in preparing or approving proposals for government business. Furthermore, Ms. Crook offered additional assurance by, among other things, promising to have access to protected information only in the offices of LMFS’s outside counsel who were admitted to the protective order. While it is true that Ms. Crook reports to Lockheed Martin Federal Systems’ General Counsel, who advises competitive decision-makers, this alone did not demonstrate that there was an unacceptable risk of inadvertent disclosure of protected information. Regular contact with corporate policy-making or competitive decision- making officials does not establish that an in-house counsel advises or participates in competitive decision-making. Mastushita Elec. Indus. Co., Ltd. v. United States, 929 F.2d 1577.
Robbins-Gioia challenges the risk assessment of its proposed software architecture. Specifically, Robbins-Gioia disagrees with the Air Force’s judgment that Robbins-Gioia’s proposed distributed object computing architecture was “emerging” and represented a moderate risk. Robbins-Gioia states that it:
“proposed a target system architecture that was based upon the use of distributed object technology. This type of architecture enables the development of applications in a distributed environment of client and server systems. The open standard which governs the communication among objects in a distributed environment is called the Common Object Request Broker Architecture (CORBA). . . .  Robbins-Gioia proposed a CORBA- compliant system and used the [COTS] product ‘Orbix’ as its object request broker (ORB). An ORB is a software device that provides interoperability among applications on different machines in heterogeneous distributed environments and seamlessly interconnects multiple object systems.”
Robbins-Gioia argues that the CORBA standard and CORBA-based products are well established and have, in fact, been embraced by the Defense Information Systems Agency (DISA)  and provided to the Air Force under other procurements. Robbins-Gioia contends that the Air Force’s view of the relative maturity of distributed object computing is based upon the agency’s reliance upon out-dated literature and that more recent industry literature, such as The Essential Distributed Objects Survival Guide (1996) by Robert Orfali, Dan Harkey, and Jeri Edwards, “recognizes that the CORBA standard has become well-established.”
In considering a challenge to a particular evaluation conclusion, we examine the record to determine whether the judgment was reasonable and in accord with the evaluation criteria listed in the solicitation. Abt Assocs., Inc., B-237060.2, Feb. 26, 1990, 90-1 CPD Para. 223. A protester’s mere disagreement with the agency’s evaluation determination does not demonstrate that the evaluation was unreasonable. Brunswick Defense, B-255764, Mar. 30, 1994, 94-1 CPD Para. 225.
The Air Force and LMFS dispute Robbins-Gioia’s view that distributed object computing technology and CORBA are so well established that the agency’s assessment of Robbins-Gioia’s proposed software architecture as representing a moderate risk was unreasonable. The Air Force and intervenor note that the agency’s moderate risk assessment was based upon more than the fact that Robbins-Gioia’s distributed object oriented approach was based upon relatively new and emerging technology; the agency’s evaluators were also concerned with, among other things, the complexity of Robbins-Gioia’s approach; the lack of detail provided by Robbins-Gioia to establish the credibility of its approach; the limited amount of currently available CORBA-compliant COTS applications software; and the need to write a substantial amount of new software code, which Robbins-Gioia committed to write in Ada95, a third generation language (as opposed to the newer fourth generation language that LMFS committed itself to use).  Hearing Transcript (TR) at 499-500, 531-532. 
We find that, despite Robbins-Gioia’s attempts to characterize its proposed CORBA-based, distributed object computing architecture as well established, the record supports the Air Force’s conclusion that Robbins- Gioia proposed a state-of-the-art approach that entailed some risk. Robbins-Gioia proposed a modernization and migration approach that was based upon an immediate implementation of a distributing computing environment using CORBA. This was an approach that Robbins-Gioia itself characterized in its proposal, during its demonstration, and in discussions as “state-of-the-art,” “cutting edge,” “innovative,” and “90s technology.”
CORBA 2.0 (the version of the standard proposed by Robbins-Gioia) is relatively new, having been promulgated by the OMG in December 1994. As recognized in The Essential Distributed Objects Survival Guide (the book cited by the protester), the CORBA standard is still evolving and represents the “cutting edge of distributed object technology and client/server middleware.” Id. at 202. Although the authors of this book admittedly are proponents for CORBA-based distributed computing, they too acknowledge that CORBA is not fully mature–for example, the authors note, at the time of printing, the lack of robust commercial ORBs suitable for mission-critical client/server environments (the authors predicted the introduction of robust ORBs from commercial vendors sometime in 1996) and the unavailability of COTS message oriented middleware.  Id. at 63-65.
Robbins-Gioia’s chief engineer recognized that some elements of the CORBA standard remained undefined and that, within the industry, there was discussion of whether CORBA was “ready for prime time.” TR at 371-377. In this regard, the chief engineer admitted that CORBA security services such as would support the C2 level of security  required for GCSS had not yet been implemented, and that there was a limited amount of CORBA- compliant, COTS software currently available to support GCSS functional applications. TR at 115-116, 369-370.
DISA’s acceptance of the CORBA standard for DOD procurements of object oriented computing does not, in our view, demonstrate that Robbins-Gioia’s proposed distributed object approach was so well established that it could not be characterized as “emerging technology” or assessed as a moderate risk. While it is true that DISA has stated in the TAFIM that CORBA is the standard to be employed in DOD procurements of distributed object oriented computing, the TAFIM does not mandate the acceptance of distributed object oriented approaches or indicate when such approaches are acceptable; rather, TAFIM merely indicates that where object oriented approaches are used CORBA is the DOD standard. See TR at 683 (LMFS’s technical consultant testified that the TAFIM only indicated the use of CORBA as a standard when distributed object computing is used). Moreover, although DISA intends to incorporate CORBA into the Defense Information Infrastructure COE, DISA warns that CORBA product recommendations have not yet been made and identifies, as issues for future resolution, CORBA requirements, migration, and Ada bindings.
The emerging nature of distributed object oriented computing and the CORBA standard is also indicated by the lack of any evidence in the record of completed, large scale commercial or government projects that would validate the maturity of the technology. Although Robbins-Gioia’s proposal references several large commercial projects, and its protest identifies two other Air Force procurements in which CORBA or a CORBA-based distributed system was being acquired, none of these projects is close to completion and implementation. TR at 106-107.
The record also supports the reasonableness of the Air Force evaluators’ other concerns with the complexity of Robbins-Gioia’s approach and Robbins-Gioia’s failure to provide sufficient details to establish the credibility and lack of risk of its approach. For example, the lack of available CORBA-compliant COTS application software for Robbins-Gioia’s proposed architecture and the need to perform custom software development, using Ada95, add complexity and risk to Robbins-Gioia’s approach. In this regard, the record establishes that Robbins-Gioia will have to do a substantial amount of custom applications software development, for which Robbins-Gioia will use Ada95, a third generation language. TR at 148-149, 162, 170-171, 658-659. The Air Force’s chief technical evaluator and LMFS’s consultant testified that software development using a third generation language is more complex and requires significantly more effort than software development using a fourth generation language. TR at 507, 655-656, 659. Robbins-Gioia has not shown otherwise.
In sum, we find the agency reasonably evaluated Robbins-Gioia’s offer to immediately implement a distributed object approach. As noted above, the Air Force credited Robbins-Gioia’s proposal for its innovative, state-of-the-art distributed object architecture in assessing the proposal as blue/excellent under architecture.  Nevertheless, the agency was justifiably concerned that the offer of an emerging technology, that was not yet fully supported in the marketplace and that would require a substantial amount of custom software development, posed some potential risk of schedule disruption, increase in cost, or degradation of performance–that is, a moderate risk. While Robbins-Gioia clearly disagrees with this risk assessment, its disagreement alone does not establish that the agency’s technical judgment was unreasonable. Brunswick Defense, supra.
Robbins-Gioia complains that it and LMFS were treated unequally by the Air Force in the evaluation of the two offerors’ proposed architectures because LMFS also proposed the use of CORBA but received a low risk rating. The record shows, however, that Robbins-Gioia and LMFS did not propose similar technical approaches or architectures. As noted above, Robbins-Gioia proposed the immediate implementation of CORBA-based, distributed object architecture; such an approach would entail a substantial amount of custom software development. LMFS, on the other hand, proposed a DCE approach,  emphasized the use of COTS software, and promised to evolve into a distributed object approach using CORBA as that technology matured. TR at 515-516, 558-563, 653-658. As even the protester’s chief architect acknowledged, the DCE approach proposed by LMFS is more mature than the distributed object technology proposed by Robbins-Gioia. TR at 217. LMFS’s use of this more mature technology, allowed LMFS, in accordance with the RFP’s stated preference, to offer more COTS software than that proposed by Robbins-Gioia under its less mature distributed object approach.
In sum, we find that Air Force did not treat Robbins-Gioia and LMFS unequally, but had a reasonable basis for its low risk assessment of LMFS’s proposed architecture.
Robbins-Gioia also complains that the Air Force did not sufficiently identify its risk concerns of Robbins-Gioia’s proposed architecture during discussions. The Air Force and LMFS respond that Robbins-Gioia was reasonably apprised of the agency’s concerns through a number of CRs that identified agency concerns with the risk presented in Robbins-Gioia’s proposed architecture and during the demonstration and face-to-face discussions, in which Robbins-Gioia had the opportunity, in a give-and-take presentation with the agency, to establish the desirability of its distributed object computing approach. The Air Force and LMFS also argue that the agency was not obligated, in any event, to specifically identify its risk assessment of Robbins-Gioia’s proposed architecture during discussions, and the Air Force contends that more specific discussions with Robbins-Gioia might have resulted in technical leveling.
Agencies are required to conduct meaningful discussions with all competitive range offerors. Price Waterhouse, B-254492.2, Feb. 16, 1994, 94-1 CPD Para. 168. In order for discussions to be meaningful, contracting officials must advise offerors of deficiencies in their proposals and afford offerors an opportunity to revise their proposals to satisfy the government’s requirements. Miltope Corp.; Aydin Corp., B-258554.4 et al. June 6, 1995, 95-1 CPD Para. 285. This does not mean that offerors are entitled to all-encompassing discussions or that an agency must “spoon-feed” an offeror as to each and every item that must be revised, added, deleted, or otherwise addressed to improve a proposal; rather, an agency must only lead offerors into the areas of their proposals considered deficient. SeaSpace Corp., B-252476.2, June 14, 1993, 93-1 CPD Para. 462. Nor is there any requirement that an agency identify relative weaknesses in a proposal that is technically acceptable, but presents a relatively less desirable approach than others received. Id. Contracting officials must balance a number of competing interests in selecting matters for discussions based upon the facts of each procurement, see Federal Acquisition Regulation (FAR) Sec. 15.610 (FAC 90-31); Docusort, Inc., B-254852, Jan. 25, 1994, 94-1 CPD Para. 38; thus, while agencies are required to conduct meaningful discussions, contracting officials are admonished by the FAR to not engage in actions that would result in technical leveling, technical transfusion, or auctions. See FAR Sec. 15.610(d), (e).
We find here that the Air Force conducted legally sufficient discussions with Robbins-Gioia concerning its proposed architecture. It is true that the Air Force did not specifically notify Robbins-Gioia during discussions that the agency viewed the protester’s proposed architecture as being based upon “emerging technology” or that the agency assessed the protester’s architecture as representing a moderate proposal risk. Nevertheless, the written discussions reasonably apprised Robbins-Gioia that the agency had numerous concerns with the risks attendant in its proposed architecture, including how Robbins-Gioia would provide the required C2 level of security; how it would perform custom software development with Ada95 to support its distributed object approach; how its architecture would be implemented on “today’s hardware and software resources” and what hardware requirements would be associated with its architecture approach; what resource impacts would result from parallel operation of modernized AISs and legacy systems; and the lack of specificity provided for its SBSS solution. In addition, the protester had the opportunity in its face-to-face discussions for a detailed back-and-forth discussion of its proposed architecture. TR at 271, 289- 290, 487-495. These discussions touched upon the software applications Robbins-Gioia proposed to provide and clarified that these applications would be developed using Ada95, upon how Robbins-Gioia intended to satisfy the RFP security requirements, and upon whether Robbins-Gioia had done any modeling or simulations to support its proposed approach. Id. Under the circumstances, even though Robbins-Gioia was not specifically informed that the agency viewed its overall CORBA-based approach as somewhat risky, we find that taken as a whole the Air Force discussions reasonably led Robbins-Gioia into the areas of its proposed architecture that were of concern to the agency and required amplification, and should have reasonably informed Robbins-Gioia that its proposed architecture was seen as having the potential for causing schedule disruption, increase in cost, or degradation of performance.
Moreover, even assuming the Air Force was required to more specifically identify its risk assessment of Robbins-Gioia’s proposed architecture to the protester, Robbins-Gioia was not prejudiced by the agency’s failure to do so. The record is clear that if Robbins-Gioia had been informed during discussions that its proposed architectural approach was considered excellent but moderate risk, the protester would then have attempted to persuade the agency that its distributed object approach was not risky.  TR at 380-381. Furthermore, despite numerous lengthy submissions disagreeing with the agency’s risk assessment of its proposed architecture, Robbins-Gioia has yet to demonstrate that its offered approach was not reasonably assessed to be a moderate risk; thus, we find no possibility that Robbins-Gioia could have offered additional information or argument that would have improved the competitive standing of its proposal in response to additional discussions. See Microeconomic Applications, Inc., B-258633.2, Feb. 14, 1995, 95-1 CPD Para. 82.
Robbins-Gioia also challenges the Air Force’s assessment of its proposal as moderate risk under the development/implementation processes factor. Specifically, Robbins-Gioia argues that the agency unreasonably considered past performance information–that is, that Robbins-Gioia had no directly relevant past experience supporting its general contractor approach–in its assessment of Robbins-Gioia’s proposal risk under this factor.
The RFP provided that the evaluation of the development/implementation processes factor would be based on an assessment “of the effective and credible processes and approach as described and demonstrated in the [o]fferor’s proposal” for systems engineering, customer training, and life-cycle management support. “Effective and credible process” is defined by the RFP as:
“an engineering, administrative, or managerial process currently in use that is measured, continuously improved and proven to produce a desired result.” [Emphasis added.]
In this regard, the RFP instructed offerors that:
“As a minimum, the [o]fferor shall describe their effective and credible processes, approach, and relevant experience. . . .” [Emphasis added.]
While it is true, as noted by the protester, that Robbins-Gioia’s proposal was evaluated as containing a number of strengths under the development/implementation processes factor, these evaluated strengths were attributable to the development and implementation capabilities demonstrated by Robbins-Gioia’s proposed subcontractors. Robbins-Gioia has not attempted to rebut the Air Force’s view that Robbins-Gioia had limited systems engineering experience and lacked experience overseeing these processes as a general contractor. Accordingly, we conclude that the agency had a reasonable basis for its determination that Robbins-Gioia’s limited relevant experience and lack of experience overseeing systems engineering processes could potentially cause some disruption in schedule, increase in cost, or degradation of performance, despite the strengths offered by Robbins-Gioia’s subcontractors.
Robbins-Gioia also protests the Air Force’s assessment of LMFS’s performance risk as low. Specifically, Robbins-Gioia argues that the agency did not assess LMFS’s allegedly poor past performance on three large programs: the Department of the Army’s Sustaining Base Information System (SBIS); the Federal Aviation Administration’s (FAA) Advanced Automation System (AAS); and DOD’s Defense Message System (DMS). Robbins-Gioia asserts that LMFS’s performance risk should have been assessed as high.
The Air Force and LMFS respond that only one of these three programs (the SBIS program) was performed by the LMFS division (LMFS-Oswego, New York) that will be performing the GCSS contract and that, pursuant to the RFP, only LMFS’s performance of the SBIS program, as well as its performance under other relevant contracts, was evaluated. The Air Force and LMFS state that the contract for the DMS program was awarded to and performed by LMFS-Manassas, Virginia, and the contract for the AAS program was awarded to and performed by LMFS-Rockville, Maryland. LMFS-Manassas and LMFS-Rockville are separate divisions within LMFS, which will have nothing to do with LMFS-Oswego’s performance of the GCSS contract. The agency also states that it assessed LMFS-Oswego’s performance of SBIS as low risk after considering the comments of both Army contracting officials and LMFS, which explained that 75 percent of the problems that occurred during contract performance of this program were the responsibility of the government.
The RFP required offerors to complete a performance risk questionnaire to aid the Air Force in its evaluation of the offerors’ performance risk, which was stated to measure the probability of an offeror’s successful performance based on the offeror’s demonstrated past and present experience. Offerors were instructed to:
“complete the Performance Risk Questionnaire attachment for all active or completed contracts executed within the last 3 years that the [o]fferor considers relevant in demonstrating its ability to perform the proposed effort. . . . This information may include data on efforts performed by other divisions, corporate management, critical subcontractors, or teaming contractors, if such resources will be used or significantly influence the performance of the proposed effort. . . . The [o]fferor shall not include performance data from other divisions or corporate management entities not planned for direct involvement during the execution of the GCSS-AF (BLSM II) program.” [Emphasis added.]
We find from this record that the Air Force’s determination to not consider LMFS’s (then, Loral’s) performance under the AAS and DMS programs was reasonably based. First, the record shows that LMFS, which is incorporated in the State of Delaware, consists of number of separate offices, each of which is headed by a separate president, vice-presidents, and general counsel, and that LMFS-Oswego, LMFS-Manassas, and LMFS-Rockville function as separate operating units, receiving and performing their own contracts. This fact was recognized in the Name Change Agreement, executed on July 1, 1996, by Lockheed Martin Corporation and the Defense Contract Management Center that assigned individual Commercial and Government Entity Codes for each of these LMFS offices.
The record also shows that LMFS-Manassas and LMFS-Rockville will not be involved in performance of the GCSS contract. In this regard, the RFP required offerors to propose labor rates in given labor categories for all prime and subcontractor organizations the offeror planned to use in contract performance. LMFS’s cost/price proposal identified no hours for the LMFS-Manassas and LMFS-Rockville offices. Because LMFS-Manassas and LMFS-Rockville have no planned direct involvement in the performance of the GCSS contract, the Air Force reasonably did not evaluate these divisions’ prior performance experience, consistent with the RFP’s instructions. 
We also find reasonable the Air Force’s low risk assessment of LMFS’s past performance on the SBIS program. In accordance with the RFP instructions, LMFS disclosed its performance of and problems under the SBIS program– which involved a large scale modernization of the Army’s legacy combat support systems. In response to discussions concerning its performance of the SBIS contract, LMFS informed the Air Force that its schedule slippage and over-budget situation were related to significant increases and changes in the government’s requirements. The Air Force contacted Army officials involved in the SBIS program, including the SBIS program managers and contracting officer. Based upon discussions with these Army officials, the Air Force determined that 75 percent of LMFS’s performance problems and cost overruns under the SBIS program were attributable to the government and not LMFS. From the information the Air Force received from various contract respondents, including Army SBIS officials, the agency determined that LMFS was a “strong engineering software company” whose past record indicated its capability to provide an acceptable product for the GCSS program. Robbins-Gioia has not shown this assessment to be unreasonable.
Robbins-Gioia also challenges the Air Force’s assessment of Robbins-Gioia’s performance risk as moderate risk, arguing that the agency did not evaluate the experience offered by Robbins-Gioia’s subcontractors or properly consider Robbins-Gioia’s own experience. Robbins-Gioia’s arguments are refuted by the record. The agency’s performance risk evaluation documentation, including the Performance Risk Analysis Group Final Report, shows that the Air Force did consider Robbins-Gioia’s and its subcontractors’ experience in assessing Robbins-Gioia’s proposal under this factor. Robbins-Gioia’s subcontractors’ performance risk was assessed as low risk, on the basis of the subcontractors’ successful performance of contracts that were judged to be relevant and very relevant. Robbins-Gioia’s performance risk was judged to be moderate risk because although Robbins-Gioia’s performance was found to be satisfactory, its experience was on “somewhat relevant” contracts, none of which were of the magnitude or complexity of the GCSS contract, and Robbins-Gioia had no specific experience as a general contractor (although, as a subcontractor, it had performed “program control-like” tasks).
Robbins-Gioia also protests that LMFS’s and LMMDS’s proposals should have been rejected because the RFP prohibited the submission of more than one proposal by an offeror. Robbins-Gioia argues that the submission of proposals by LMFS and LMMDS, which are a subsidiary and division, respectively, of Lockheed Martin Corporation, was tantamount to receiving multiple proposals from Lockheed Martin. (Robbins-Gioia states, however, that it “is not alleging collusion” between LMFS and LMMDS.)
The Air Force and LMFS respond that LMFS and LMMDS are separate corporate entities. The record shows that LMFS is a Delaware corporation, whose stock is owned by Lockheed Martin Tactical Systems, Inc., a New York corporation, which is wholly owned by Lockheed Martin Corporation, a Maryland corporation, and that LMMDS is a separate operating division within Lockheed Martin Corporation. The agency and intervenor state that while the operative RFP provision limited each offeror to one proposal, it defined an offeror broadly as “an individual, partnership, proprietorship, joint venture, corporation, or other business entity,” and that under this definition, LMFS and LMMDS are separate “business entities” entitled to submit their own proposals. The Air Force and intervenor also state that LMFS and LMMDS prepared their proposals on an independent basis, sharing no proposal information with each other.
We agree with the Air Force and LMFS that the RFP did not prohibit the submission of independent offers by affiliated offerors, such as LMFS and LMMDS. As a general rule, contracting agencies may accept bids and offers from affiliated firms, unless doing so would be prejudicial to the interests of the government or would give the affiliated offerors an unfair advantage over other offerors. District Moving & Storage, Inc; Guardian Storage, Inc.; and Quality Transp. Servs., Inc., B-272070, Aug. 9, 1996, 96-2 CPD Para. 60. Here, the plain language of the RFP permits the submission of separate proposals by separate business entities, which could reasonably be said to include separate corporate subsidiaries or divisions that operate as individual, autonomous business units. Moreover, Robbins-Gioia has not shown that LMFS or LMMDS had an unfair advantage, or that the Air Force’s acceptance of proposals from LMFS and LMMDS was prejudicial to the interests of the government.
The protest is denied. 
Comptroller General of the United States
1. A “legacy system” is defined by the RFP as “[e]xisting operational information systems maintained and modified using software engineering techniques and methods on [COEs] that pre-date the GCSS-AF (BLSM II) COE and respective Automated Information Systems (AIS) to be modernized.”
2. The RFP defined an AIS to be an “[a]ggregation of software, control language, data structures, and user interface that support a functional activity.”
3. Maintenance services could be ordered for 15 years.
4. Ada is a standard high-level programming language specified by the DOD.
5. Fourth generation languages are specifically designed to manipulate data records in certain kinds of databases using English-like or natural language statements.
6. Proposals could be evaluated under each evaluation factor as either: blue/excellent; green/acceptable; yellow/marginal; or red/unacceptable.
7. The RFP provided that “proposal risk” would assess the risk associated with the offeror’s approach as it relates to accomplishing the requirements of the solicitation, and that “performance risk” would assess the probability of the offeror successfully accomplishing the proposed effort based upon the offeror’s demonstrated present and past performance. Risk was assessed as either low, moderate, or high.
8. “Low risk” was defined by the RFP as:
“Has little potential to cause disruption of schedule, increase in cost, or degradation of performance. Normal [o]fferor effort and normal [g]overnment monitoring will probably be able to overcome difficulties.”
9. “Moderate risk” was defined by the RFP as:
“Can potentially cause some disruption of schedule, increase in cost, or degradation of performance. However, special [o]fferor emphasis and close [g]overnment monitoring will probably be able to overcome difficulties.”
10. “M” means a million.
11. CORBA is a standard for distributed object computing that was developed by the Object Management Group (OMG), a consortium including information system vendors, software developers, and end users. Founded in 1989, the OMG promotes the theory and practice of object oriented technology in software development. The CORBA: Architecture and Specification, Revision 2.0, July 1995, can be viewed on Internet at http://www.omg.org/corba2.
12. DISA is responsible for information technology within the DOD and publishes the Technical Architecture Framework for Information Management (TAFIM) to guide the development of architectures that satisfy requirements across missions, functional areas, and functional activities. The TAFIM can be accessed at DISA’s website on the Internet at http://www.itsi.disa.mil/cfs/tafim.html.
13. Ada was only extended to support object oriented approaches in 1995.
14. A hearing was conducted to elicit testimony from the agency’s chief technical evaluator, Robbins-Gioia’s chief engineer, Robbins-Gioia’s chief architect, and Robbins-Gioia’s and LMFS’s technical consultants, concerning the agency’s evaluation of the firms’ proposed software architectures and the agency’s conduct of discussions.
15. Message oriented middleware provides for asynchronous message queues on clients and servers, allowing clients and servers to function at their own designated times and speeds without necessarily being simultaneously active.
16. The RFP required security solutions to prevent unauthorized alteration of, or access to, information processed by each modernized system. A C2 level of security, as defined by DOD in its Trusted Computer System Evaluation Criteria, DOD Publication No. CSC-STD-001-83, provides both discretionary (need-to-know) protection and controlled access.
17. The Air Force considered Robbins-Gioia CORBA-based approach to be the “distinguishing feature of [its] proposal” and “very exciting and where the field was going.” TR at 463, 476, 496.
18. Robbins-Gioia also complained that the Air Force did not consider Robbins-Gioia’s offer to use DCE in conjunction with the protester’s distributed object computing approach. The record shows that the agency did reasonably assess this aspect of Robbins-Gioia’s proposal, but correctly noted that Robbins-Gioia’s approach was primarily based upon an immediate implementation of a CORBA-based, distributed object computing model.
19. The protester asserts that if it had been unable to convince the Air Force that its proposed architectural approach was not a moderate risk, it would have radically altered its approach. We find it implausible on this record that the protester would have radically altered its proposed approach, for which it was evaluated to be blue/excellent, merely because the agency was concerned that its approach entailed some potential risk. Not only would such a change in the protester’s technical approach entail significant proposal revision, but Robbins-Gioia’s chief architect testified that he would resign prior to being associated with an approach that was not based upon distributed object computing and CORBA. TR at 252-253.
20. In its comments, Robbins-Gioia also asserted that LMFS poorly performed the Global Transportation Network (GTN) program. This program was not identified by Robbins-Gioia in its protest as a basis for its challenge to the Air Force’s assessment of LMFS’s past performance. Our Bid Protest Regulations do not contemplate the unwarranted piecemeal presentation of protests issues. Armstrong Motorcycles Ltd., B-238436; B-238436.2, June 5, 1990, 90-1 CPD Para. 531. In any event, the record establishes that the GTN program was not performed by LMFS-Oswego and therefore was appropriately not considered by the Air Force in its assessment of LMFS’s performance risk.
21. Robbins-Gioia also protested a number of other aspects of this procurement, including the agency’s evaluation of Robbins-Gioia’s and LMFS’s proposed cost/price. Because the agency responded in detail in its report to each of Robbins-Gioia’s protest allegations, and Robbins did not address the agency’s response to these allegations in its comments, we find these other protest allegations have been abandoned. TM Sys., Inc., B-228220, Dec. 10, 1987, 87-2 CPD Para. 573.
DOCUMENT FOR PUBLIC RELEASE A protected decision was issued on the date below and was subject to a GAO Protective Order. This version has been redacted or approved by the parties involved for public release.
Greetings I’m Sam.
I edit, report and maintain this site. If you have any questions You can mail below me but it could be a while before I get back to you.