BNUMBER:  B-275032; B-275032.2 
DATE:  
TITLE:  

**********************************************************************

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.
Matter of:Allied Signal, Inc., Electronic Systems

File:     B-275032; B-275032.2

Date:January 17, 1997

William A. Roberts III, Esq., Lee P. Curtis, Esq., Harvey G. Sherzer, 
Esq., Jerone C. Cecelic, Esq., Richard P. Castiglia Jr., Esq., Howrey 
& Simon, for the protester.
Thomas C. Papson, Esq., Ian T. Graham, Esq., and Alan Brown, Esq., 
McKenna & Cuneo, for Hughes Aircraft Company, an intervenor.
Joshua A. Kranzberg, Esq., and Thomas D. Carroll, Esq., Department of 
the Army, for the agency.
John Van Schaik, Esq., and Michael R. Golden, Esq., Office of the 
General Counsel, GAO, participated in the preparation of the decision.

DIGEST

Solicitation for tactical intelligence terminals and modules is 
ambiguous where protester and awardee both have reasonable 
interpretations of a requirement that the proposed modules must be 
backward compatible with two existing intelligence terminals. 

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