Matter of: Allied Signal, Inc., Electronic Systems File: B-275032; B-275032.2 Date: January 17, 1997 * Redacted Decision

Matter of: Allied Signal, Inc., Electronic Systems File: B-275032; B-275032.2 Date: January 17, 1997 * Redacted Decision

DIGEST

Attorneys

DECISION

Allied Signal, Inc., Electronic Systems protests the award of a contract to Hughes Aircraft Company under request for proposals (RFP) No. DAAB07-96-R-S998, issued by the United States Army Communications- Electronics Command (CECOM) for the Joint Tactical Terminal/Common Integrated Broadcast Service Modules (JTT/CIBS-M), which is to provide war fighters with tactical intelligence and targeting information. Allied argues that the Army waived a mandatory requirement of the solicitation for Hughes.

We sustain the protest.

BACKGROUND

The military services use numerous types of terminals, or radios, to transmit and receive critical intelligence and targeting information for military operations. Some of the intelligence terminals fielded by the Department of Defense (DOD) include: Commanders' Tactical Terminal (CTT), Multi-Mission Advanced Tactical Terminal (MATT), Tactical Receive Equipment (TRE), Synthesized UHF Computer Controlled Equipment Sub-System (SUCCESS), Tactical Information Broadcast Service (TIBS) Interface Unit (TIU), and Quad Net Radio and Joint Communications Interface Terminal (JCIT). Due to Congressional and agency-level concern, DOD is attempting to move to a single family of intelligence terminals and modules (circuit cards and software programs) for transmitting and receiving critical intelligence and targeting information for military operations and a single broadcast architecture, the Integrated Broadcast Service (IBS), for intelligence dissemination. As part of this effort, DOD officials drafted the Joint Operational Requirements Document (JORD) which sets forth the minimum required capabilities for the JTT/CIBS-M and user needs and/or potential improvements above the required capabilities. The JTT/CIBS-M contract also is part of this effort to move to a single family of intelligence terminals and modules.

The JTT/CIBS-M solicitation contemplated a fixed-price production contract for an initial version of a terminal that receives intelligence and targeting information (JTT-R), a terminal that transmits and receives intelligence and targeting information (JTT-T/R) and production of hardware and software modules (CIBS-M) that can be packaged as a stand-alone JTT terminal or integrated into other terminals in accordance with user requirements. The RFP states that additional configurations of CIBS-M modules and JTT terminals are to be developed through contractual pre-planned product improvements (P3I) which will incorporate additional program requirements from the JORD.

The basic requirement for the first contract year includes JTT terminals (but no CIBS-M modules), warranties, services and data. There are also 9 option years in which additional quantities of JTT terminals, CIBS-M modules, and warranties and services can be purchased. The solicitation includes a performance based "System Specification" which the offerors were to modify to reflect the characteristics and performance capabilities of the items they offered. This procurement was not a "build to print" production effort, but rather allowed offerors to integrate existing designs with evolving technology in order to meet the performance requirements set forth in the system specification.

Under the heading "MINIMUM REQUIREMENTS," the RFP listed five requirements which were to be "[t]he ONLY requirements set forth in this solicitation which are considered by the Government to be minimum requirements which MUST be satisfied. . . ." The first of the minimum requirements was stated as follows, in relevant part:

"The JTT/CIBS-M family of terminals and modules must meet the following Key Performance Parameters ("KPPs"):

(a) Must be flexible, scaleable and use an open architecture.

. . . . .

(f) Must accommodate all (TRIXS, TIBS, and TDDS/TADIXS-B) IBS formats and protocols.

(g) CIBS-M must be available in common module form factors.

(h) CIBS-M designs must be bus independent.

(i) CIBS-M must be backward compatible [1] with CTT and MATT." [2]

Another of the five minimum requirements was that "[a]t least 50 JTT-T/R terminals from the basic contract must be delivered no later than 30 Sept 98." Finally, after the list of minimum requirements, the RFP stated: "All other requirements are considered to be 'desired' and may be traded-off by the Offeror in order to . . . present what the Offeror considers to be a 'best value' solution."

The RFP contemplated a best-value procurement with four evaluation factors: technical, performance risk, price, and supportability. As relevant to this protest, the solicitation described subfactors under the technical evaluation factor as: (a) architecture, (b) performance, and (c) validation, with (a) and (b) of approximately equal importance and each more important than (c).

The RFP stated that the technical factor and performance risk factor were the most important factors and were of approximately equal importance. The technical factor and the performance risk factor combined were significantly more important than price and the supportability factor combined. Price was to be less important than either the technical or the performance risk factors and the supportability factor was to be less important than price. In order to be eligible for award, a rating of no less than "Acceptable" was required for both the technical and supportability factors.

Three firms, including Allied and Hughes, submitted proposals. All three proposals were found to meet the KPPs and other minimum requirements and oral presentations and face-to-face discussions were conducted with each offeror. After each firm submitted revisions to its offer, there were telephonic discussions to resolve open items, further revisions to the proposals, the completion of an initial source selection evaluation board (SSEB) evaluation report and source selection advisory council (SSAC) and source selection authority (SSA) briefings. All three offerors were requested to submit best and final offers (BAFO). The final evaluation results for the Allied and the Hughes proposals were as follows:

Factors and subfactors Allied Hughes

Technical [deleted] [deleted]

Architecture [deleted] [deleted]

Performance [deleted] [deleted]

Validation [deleted] [deleted]

Performance risk [deleted] [deleted]

Price (base and options) [deleted] [deleted]

Supportability [deleted] [deleted]

The SSA determined that the offer submitted by Hughes represented the best overall value to the government. Among other factors in the selection decision, the SSA noted that [deleted]. The contract was awarded at a price of $21,952,768 for the base requirement.

PROTEST ALLEGATIONS

Allied argues that in its evaluation of the Hughes proposal, the Army waived the KPP for backward compatibility with the CTT and MATT. As explained above, under the minimum requirements provision, the RFP stated that one of the KPPs which "[t]he JTT/CIBS-M family of terminals and modules" was required to meet was "(i) CIBS-M must be backward compatible with CTT and MATT." Allied explains that it understood the RFP as requiring that all CIBS-M modules, including those that will make up the required base year quantity of 50 JTT terminals, be backward compatible with CTT and MATT. In addition, Allied states it understood that the RFP, as clarified by the agency's answers to two questions posted by offerors on an electronic bulletin board, required offerors to propose modules that are backward compatible with CTT or MATT to the point that all that will remain to be done before delivery is easy repackaging or integration into the CTT or MATT. Allied maintains that its own proposal met these requirements. According to Allied, however, "[deleted]". Allied states that [deleted]. Allied also maintains that the Hughes proposal [deleted]."

As support for this allegation, Allied notes that the record shows that [deleted]. Specifically, Allied notes that the Army evaluators [deleted]. According to Allied, "[t]his offer of [deleted] cannot reasonably be viewed as compliant with this critical mandatory minimum requirement necessary to fulfill DOD policy as articulated to Congress."

THE AGENCY'S RESPONSE

CECOM argues that Allied has mischaracterized the backward compatibility requirement. CECOM maintains that the RFP did not require proposals for initially delivered CIBS-M modules that are backward compatible with CTT and MATT. Rather, according to the agency, the RFP required only that proposals offer a "path" to backward compatibility using P3I. In support of this position, the agency notes that the RFP, in the System Specification, under the heading "System Description," and in the Executive Summary, described the "family" of JTT terminals and CIBS-M modules as including not only the specific JTT terminal configurations and CIBS-M modules proposed for initial delivery, but also JTT terminals and CIBS-M modules that may be procured through "P3I and module integration into other terminals" in the future. Specifically, the agency refers to the System Specification which states:

"The JTT/CIBS-M consists of a family of JTT terminals and CIBS-M modules. JTT terminals shall be provided in multiple configurations to meet varying user requirements through the use of modules. CIBS-M modules shall be integrated directly into systems other than JTT terminals on a module-by-module basis to provide selective functionality. Modules should maximize interdependence among components, and provide ease of replacement of individual modules. The JTT/CIBS-M shall provide an architecture that shall support multiple terminal configurations, technology insertion, P3I and module integration into other terminals or processors."

Based on this and similar language elsewhere in the RFP, the agency argues that an offeror could satisfy the minimum requirement for backward compatibility "by describing how the family of CIBS-M modules (not necessarily the initial delivery CIBS-M modules) can provide backward compatibility in the future, i.e. by offering a reasonable path to backward compatibility using P3I." The agency also argues that any doubt concerning this requirement was cleared up by the electronic bulletin board questions and answers.

The agency notes that there was no statement in the RFP requiring a proposal to "comply with" or "meet" the KPPs in "the initial deliveries." Rather, in the agency's view, the RFP required that "the family of terminals and modules" meet the KPPs. Thus, according to the agency, a proposal could meet the minimum requirement for backward compatibility by offering a reasonable path to backward compatibility using P3I.

The agency also argues that Hughes [deleted] met the minimum requirement for backward compatibility. According to the agency, Hughes [deleted] was judged by agency evaluators to have met them.

Finally, the agency disputes Allied's contention that the Hughes proposal and supporting documentation [deleted]. The agency notes that [deleted]. According to the agency, [deleted]. Moreover, the agency argues that [deleted]. Furthermore, the agency asserts, Hughes [deleted]. In summary, consistent with the agency's view that P3I was a valid means of meeting the backward compatibility KPP, the agency argues there was no waiver of that requirement for Hughes.

ANALYSIS

We conducted a hearing to obtain testimony from CECOM personnel and representatives of Allied and Hughes concerning the backward compatibility KPP. In addition, we obtained assistance from our Office's technical staff. Based on our review, we conclude that the requirements of the RFP concerning backward compatibility were ambiguous, that is, subject to more than one reasonable interpretation, and that Allied, which was constrained in its proposal approach by its reasonable but more restrictive understanding of the requirement, was prejudiced by the ambiguity.

We first consider the terms of the RFP concerning backward compatibility. First, as explained above, under the "MINIMUM REQUIREMENTS" section, the RFP listed five requirements which were to be "[t]he ONLY requirements set forth in this solicitation which are considered by the Government to be minimum requirements which MUST be satisfied . . . ." The first of the minimum requirements was the KPPs and the requirement that "[t]he JTT/CIBS-M family of terminals and modules must meet the following [KPPs]: . . (i) CIBS-M must be backward compatible with CTT and MATT."

Second, under the architecture subfactor of the technical evaluation factor, among other considerations, the RFP stated that the evaluators would consider in each proposal "[t]he degree to which the proposed architecture and family of CIBS-M functional modules: . . . meets or exceeds [KPPs] (a), (d), (g),(h) and (i) as described in Section 3.0 Minimum Requirements." The "(i)" is a reference to the KPP concerning backward compatibility. Thus, read literally, one consideration under the architecture subfactor was the "degree to which the proposed architecture and family of CIBS-M functional modules" meets the KPP that "CIBS-M must be backward compatible with CTT and MATT."

Finally, the RFP system specification stated: "CIBS-M shall also be backward compatible with the [CTT] and the [MATT]. This is a KPP."

In addition to these RFP references, as noted above, the agency provided guidance to offerors via an electronic bulletin board concerning the backward compatibility requirement. The electronic bulletin board questions and answers were as follows:

Question 1: "Ref[erence] [Specification] Para 3.2. Does CIBS-M backwards compatibility to CTT and MATT mean physical, functional or both e.g. [d]oes a CIBS-M have to have the same form factor as the CTT and MATT modules?

Answer 1: "The Offeror shall address the ability of the proposed architecture to be physically and functionally backward compatible to both the CTT and MATT. The CIBS-M will consist of a set of core software and hardware modules which must be easily repackaged or integrated for use in CTT and MATT. The initial CIBS-M modules comprising the JTT-T/R and JTT-R are not required to have the same form factor as either the CTT or MATT.

Question 2: "Ref[erence] [Specification] Para 3.2 Identifies a KPP for backward compatibility with CTT and MATT. At what level is this compatibility required, network or module backplane? If module backplane compatibility is required, must the offeror define and price each CIBS-M module in two configurations, one compatible with MATT SEM-E [Standard Electronic Module-E] and one compatible with CTT VME [VersaModule Eurocard] bus architectures?

Answer 2: "Backward compatibility includes both the required network functionality and physical hardware modules that can be repackaged and integrated into both the CTT and MATT backplane architectures. Only one configuration of each module is required at this time."

Although there had been numerous disputes among the parties concerning the backward compatibility requirement, the parties now substantially agree to the following concerning that requirement:

1. Offerors were required to propose and price CIBS-M modules in only one configuration, MATT or CTT.

2. The configuration proposed was not required to use the same form factor as MATT or CTT.

3. Offerors were required to price one, and only one alternate configuration of modules that were form, fit and function compatible with the CTT or the MATT.

4. Each offeror was required to propose deliverable CIBS-M modules which could be "easily repackaged or integrated for use in CTT and MATT."

Notwithstanding this agreement, Allied and Hughes nonetheless interpreted the backward compatibility KPP differently in two material respects. First, Allied understood that all CIBS-M modules to be delivered under the contract, including the CIBS-M modules that would make up the base quantity JTT terminals, were required to be fully backward compatible with the CTT and MATT. [3] Hughes, on the other hand, explains that it understood that the CIBS-M modules that would make up the base quantity JTT terminals were not required to be fully backward compatible with the CTT and MATT. Tr. at 439, 449 and 483.

Second, Allied and Hughes interpreted the specific requirement for easy repackaging or integration in significantly different manners and prepared their proposals based on those differing interpretations. [Deleted].

Hughes interpreted the RFP as requiring proposals to include [deleted]. Tr. at 398-399, 400, 402, 449. Consequently, Hughes' understanding was that [deleted]. Tr. at 407, 410.

This understanding was reflected in the Hughes proposal. [Deleted].

Allied, on the other hand, in its proposal approach focused [deleted]. Tr. at 344-347. As a result, Allied proposed [deleted]. Since, as recognized by both CECOM and Hughes, offerors were required to propose and price CIBS-M modules in only one configuration, [deleted].

Although Allied alleges that CECOM waived a material requirement of the RFP, we conclude there was a latent ambiguity in the solicitation concerning the backward compatibility KPP which also led these two competitors to propose two different approaches based on their interpretations of the RFP.

Backward compatibility for the CIBS-M modules was a KPP, one of the minimum requirements which the RFP stated must be satisfied. The RFP called for delivery of the JTT terminals which include CIBS-M modules. Since the RFP required that the modules be backward compatible, under the RFP, a reasonable conclusion is that all CIBS-M modules to be delivered, including those that make up JTT terminals, would have to be backward compatible. The electronic bulletin board advice further supports the reasonableness of Allied's position. The agency specifically advised that "[t]he CIBS-M will consist of a set of core software and hardware modules which must be easily repackaged or integrated for use in CTT and MATT." Nothing in this advice explicitly waived the requirement that CIBS-M modules provide backward compatibility. Moreover, with respect to what offerors were required to propose in order to meet the KPP, Allied could reasonably rely on the electronic bulletin board advice to conclude that proposals were required to include a substantially complete design for backward compatibility.

CECOM and Hughes have cited a number of provisions of the RFP in an attempt to demonstrate that Allied's interpretation of the backward compatibility requirement was not consistent with the solicitation read as a whole and in a reasonable manner. For example, based on RFP references to a "family of JTT terminals and CIBS-M hardware and software modules," and references to P3I, the agency argues that an offeror could satisfy the minimum requirement for backward compatibility "by describing how the family of CIBS-M modules (not necessarily the initial delivery CIBS-M modules) can provide backward compatibility in the future by offering a "reasonable path" to backward compatibility. The agency and Hughes also argue that their interpretation of the RFP as only requiring proposals to show a reasonable path to backward compatibility is supported by the agency's answer on the electronic bulletin board that "[t]he Offeror shall address the ability of the proposed architecture to be physically and functionally backward compatible to both the CTT and MATT.

While we think there is room in the RFP language cited by CECOM and Hughes to allow for their interpretation, this does not detract from the reasonableness of Allied's interpretation. For example, nothing in the RFP references to a "family of terminals and modules" indicated to offerors that only later delivered CIBS-M modules would be required to be backward compatible with MATT and CTT. On the contrary, since the "family of terminals and modules" consists of both deliverable terminals and modules under the base and option years of the contract and future deliverable terminals and modules, a reasonable reading of the requirement is that it must be met by all CIBS-M modules delivered under the contract, regardless of when they are delivered. As Allied emphasizes in its reading of the RFP, backward compatibility was a KPP--a minimum requirement--which the RFP stated "MUST be satisfied." Moreover, nothing in the RFP stated that any CIBS-M modules would not have to meet all of the minimum specifications. Thus, based on the RFP itself, we conclude that Allied reasonably could have understood that all terminals and modules to be delivered under the contract are required to be backward compatible.

Concerning the bulletin board answer that proposals should address the "ability of the proposed architecture to be physically and functionally backward compatible to both the CTT and MATT," this language standing alone supports the agency's less restrictive interpretation that a "reasonable path" to backward compatibility was all that offerors were required to show in their proposals. Nonetheless, the reference to the "ability of the proposed architecture to be physically and functionally backward compatible," when read in the context of the RFP as a whole and the complete questions and answers provided to offerors on the electronic bulletin board, including the answer that "[t]he CIBS-M will consist of a set of core software and hardware modules which must be easily repackaged or integrated for use in CTT and MATT," does not make Allied's interpretation unreasonable.

In short, while, the agency and Hughes had their permissible interpretation, we think Allied's interpretation clearly is a reasonable one. In other words, this RFP, subject to two different interpretation, was ambiguous. We also conclude that Allied was prejudiced by the ambiguity in the RFP. As Allied's representative testified, since the RFP requirement for backward compatibility was a KPP, a minimum requirement, it was required to be met. Tr. at 344-346. Allied's representative also noted, however, there were eight other KPPs in the RFP, and that in preparing a technical proposal, an offeror was "constrained in nine different ways." Tr. at 345. He noted that, in particular, KPP(a), "[m]ust be flexible, scaleable and use an open architecture," conflicts with the backward compatibility KPP since by meeting one of those requirements, it becomes harder to meet the other. Tr. at 344-345. Allied's representative also testified that, in addition to this conflict between flexible, scaleable and open architecture and backward compatibility, its flexibility in deciding on an approach also was constrained by the minimum requirement that 50 JTT terminals must be delivered by September 30, 1998 since, as explained, all CIBS-M, including those that make up the JTT terminals, have to be backward compatible with CTT and MATT. Tr. at 349-350.

As a result of these constraints, to meet the backward compatibility KPP, Allied proposed [deleted].

The record thus shows that [deleted]. Where, as here, the solicitation is ambiguous with the result that offerors responded to it based on different reasonable assumptions as to what was required, the competition has been conducted on an unequal basis and the government has been deprived of the full benefits of competition. Under these circumstances, the requirement should be resolicited. MLC Fed., Inc., B-254696, Jan. 10, 1994, 94-1 CPD Para. 8; Reflect-A-Life, Inc., B-232108.2, Sept. 29, 1989, 89-2 CPD Para. 295.

Accordingly, we recommend that CECOM resolicit with an appropriate statement of the agency's needs. If based on the recompetition, a firm other than Hughes is selected for award, the agency should terminate the contract with Hughes and reaward the contract. We also recommend that Allied be reimbursed its cost of pursuing this protest, including reasonable attorneys' fees. Bid Protest Regulations, section 21.8(d)(1), 61 Fed. Reg. 39039, 39046 (1996) (to be codified at 4 C.F.R. Sec. 21.8(d)(1)). Allied's certified claim for such costs, detailing the time expended and costs incurred, should be submitted directly to the agency within 60 days after receipt of this decision. Bid Protest Regulations, section 21.8(f)(1), 61 Fed. Reg. supra (to be codified at 4 C.F.R. Sec. 21.8(f)(1)).

The protest is sustained.

Comptroller General of the United States

1. Backward compatibility refers to hardware or software that is compatible with earlier versions.

2. The CTT is produced by E-Systems, Inc., while the MATT is manufactured by Allied.

3. When he was asked about Allied's understanding of what was required to meet the backward compatibility KPP, Allied's representative testified:

"All the documents are pretty consistent in that they say all CIBS-M must be backward compatible with CTT and MATT. That's KPP(i). CIBS-M, in the terminology of this procurement, consists of the modules that make up the terminal. I'm going to build you a radio, and the radio is going to have a set of boards in the radio. Those boards will become the core of the CIBS-M family of modules. Those CIBS-M modules now must meet this requirement. So we have the KPPs requirements that apply to the architecture, and requirements that apply to the terminals, and requirements that apply specifically to the CIBS-M modules. If it is CIBS-M, it must be backward compatible to CTT and MATT."

Hearing Transcript (Tr.) at 345-346.

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.