B-237368, Feb 16, 1990

B-237368, Feb 16, 1990

DIGEST: 1. Where solicitation read as a whole advised offerors that a proposal complying with only one of he requirements concerning computer operating systems and host computers would be considered only if the agency received no proposal that complied with all of the requirements, and awardee submitted proposal complying with all requirements, agency properly rejected the awardee's proposal that met only one requirement. 2. Protest that awardee's proposed computer software failed to comply with requirement for "formal" language is denied where protester fails to demonstrate that the agency acted unreasonably in determining that the offered software was compliant.

Attorneys

Teledyne Brown Engineering, Inc.:

Teledyne Brown Engineering, Inc. (TBE), protests the award of a contract to i-Logix Corporation (ILC), under request for proposals (RFP) No. N62269 -89-R-0398, issued by the Department of the Navy for computer software. TBE asserts that the Navy failed to adhere to the RFP's evaluation scheme in excluding TBE from the competitive range, improperly failed to conduct discussions with TBE, and awarded the contract to ILC despite that firm's failure to meet certain mandatory requirements of the RFP.

We deny the protest.

BACKGROUND:

The RFP was issued to obtain computer software, designated as a "system specification tool," to be used for software and systems design and maintenance by numerous elements of the Naval Air Systems Command. The solicitation called for commercially available, off-the-shelf software capable of operating on two widely used operating systems, namely, VMS, used on Digital Equipment Corporation's VAX-series computers, and Unix. The solicitation stated that the agency would order a minimum of 8 and a maximum of 80 software packages for Unix based systems, and a minimum of 2 and a maximum of 20 for VMS-based systems, for a total of 10 to 100 software packages; it provided that the government would have 3 years in which to order the minimum number. Award was to be made to the lowest priced offeror, evaluated on the basis of the maximum quantities, whose proposal was determined to be technically acceptable, and the RFP stated that award could be made on the basis of initial proposals.

Of the four offers submitted in response to the solicitation, TBE's initial proposal appeared to be the lowest in price, at $962,900. Directly below the price figure in its proposal, however, the firm added the statement, "procurement for 100 tools must be over a 24-month window; otherwise catalog prices apply (see attachment)." The Navy considered this notation as conditioning the stated price of $962,900 in two respects, both of them at variance with the RFP and unacceptable to the agency; it compressed the ordering period from the 3 years specified in the RFP to a period of 2 years, and it based the total price on the purchase of the entire maximum quantity of 100, while the RFP stated that the government would be obligated to purchase no more than the minimum quantity of 10. Consequently, the agency calculated the proposed price on the basis of TBE's catalog prices, as the only ones applicable under the conditions placed on the proposal, and arrived at an estimated revised price of $1,952,900. /1/ This price was higher than ILC's proposed price of $1,300,000.

Moreover, the Navy found that TBE's software failed to comply with the solicitation requirement that the software be capable of operating both on VMS and Unix operating systems which were referred to as "machine types" in the RFP; TBE's product operated on Unix-based systems, but not on those models of computers referred to in the RFP as "host computers" that utilized the VMS operating system. As a result, the Navy found TBE's proposal technically unacceptable, and excluded the firm from further consideration for award. In reviewing the other three proposals received in response to the RFP, the Navy determined that only one, ILC's, was technically acceptable, and made the award to that firm.

In its protest, TBE concedes that, as proposed, its software does not operate on VMS-based systems; it argues, however, that the RFP does not require software capable of operating on both Unix and VMS systems. this regard, paragraphs 5 and 6 of the RFP's General Requirements specified that "the host computer requirements for the software are defined in terms of the 'Machine Types' that are required to be supported;" provided that "the specific Machine Types that must be supported ... as a minimum, are Unix-Based and VMS-Based;" and specified one model host computer for the VMS system and one for the Unix system. TBE points out, however, that General Requirements paragraph 7, "Compliance with Host Computer Requirements/Machine Types," provided that:

"Since there is no accurate way to assess beforehand if any software tool can satisfactorily meet all the requirements of this solicitation, bidders are encouraged to judiciously submit proposals even if they do not meet all the MANDATORY host computer requirements for a particular Machine Type. However, at least one of the MANDATORY Host Computer MUST be satisfied and first consideration will be given to those bidders offering tools which are fully compliant with all the MANDATORY host requirements."

According to the protester, since each machine type has only one mandatory host computer associated with it, and since paragraph 7 stated that only one of the mandatory host computer requirements had to be satisfied, only one of the machine types had to be satisfied as well, namely, the machine type VMS or Unix that was used on the particular host computer the offeror chose to address in its proposal.

The Navy disputes TBE's interpretation of the specification. maintains that in encouraging the submission of offers "even if they do not meet all of the MANDATORY Host Computer requirements for a particular Machine type," the specification clearly envisioned that the proposed software would be able to operate on at least one mandatory host computer for each of the two required machine types. The agency contends that any confusion in this regard is eliminated by a reading of the solicitation as a whole, which indicates two models of host computers for the DOS-based system. According to the agency, in a procurement of software that also had to be compatible with DOS, the specification language would mean that an offeror could propose software that operated on DOS but did not operate on both of the mandatory host computers that use DOS-- that is, it could offer software for "at least one" of the mandatory host computers for that particular machine type. The Navy simply retained language used for generic software procurements and did not customize it for this procurement.

We find that, read together, paragraphs 5, 6 and 7 clearly provided that the software had to operate on both the Unix and VMS systems. In this regard, paragraph 5, as noted above, unequivocally requires, "as a minimum," that both the Unix and VMS machine types be supported, and states that the host computer requirements are "defined in terms of" the required machine types. Paragraph 6, in turn, lists one model of computer for the VMS machine type and one for the Unix machine type. Paragraph 7, in permitting offers for only one of the host computers, does qualify the host computer requirement to the extent of permitting offers for only one host computer rather than two; however, it does not qualify the underlying requirement that the software operate on both machine types. We also find it significant that, as noted above, the RFP specified minimum and maximum quantities in terms of amounts required for Unix and amounts required for VMS; this clearly indicates that the agency contemplated purchasing software that would run on both machine types.

In any case, even if TBE were correct that an offer of software that would operate on only one machine type/host computer could be submitted, we think the RFP nevertheless made it clear that the agency would accept a degradation of its requirement for software than ran on both machine types only if a fully compliant proposal were not received. The RFP explicitly stated that the rationale for this approach was the inability to determine in advance whether "any software tool can satisfactorily meet all the requirements." Therefore, once the Navy made the threshold determination that fully compliant software was available, as it did in the case of ILC's software, it properly eliminated TBE from the competitive range. /2/

TBE also argues that the Navy acted improperly in making an award without conducting discussions with TBE, even though the agency held discussions with ILC. However, once an offeror properly has been excluded from the competitive range, as was the case here, discussions need not be held with that firm. See Fayetteville Group Practice, Inc., B-226422.5, May 16, 1988, 88-1 CPD Para. 456. This is true even though, as the protester points out, only one firm may remain in the competitive range. See Kay and Assocs., Inc., B-234509, June 16, 1989, 89-1 CPD Para. 567.

Finally, TBE argues that ILC's proposed software failed to meet a mandatory requirement of the RFP that the software use a formal language that is capable of supporting the specification of system functions in logical and algorithmic forms. In this regard, both the protester and the Navy agree on the following definition of a formal language, approved by the American National Standards Institute (ANSI) in August 1983:

"Formal language. A language whose rules are explicitly established prior to its use. Synonymous with artificial language. Examples include programming languages such as FORTRAN and Ada, and mathematical or logical languages, such as predicate calculus. Contrast with natural language."

According to the protester, ILC's proposed software package, STATE MATE, unlike programming languages such as FORTRAN, is not a formal language, because it cannot automatically execute mathematical system design specifications.

The Navy reports, however, that while a programming language such as FORTRAN is one example of a formal language, it is not the only kind; according to the agency, STATE MATE is a graphical specification language, rather than a programming language, but is nonetheless a formal language. Indeed, the agency asserts that since, as stated in the ANSI definition, all languages are either formal artificial or natural, and since even TBE does not claim that STATE MATE is a natural language, it must be a formal language by definition. In any event, the agency reports that, based on its evaluation of the software, there is no doubt that the product meets all of its technical requirements.

Where technical services or products are involved, the contracting agency's technical judgments are entitled to great weight; we will not substitute our judgment for the agency's unless its conclusions are shown to be arbitrary or otherwise unreasonable. See Kay and Assocs., Inc., B-234509, supra. In reviewing ILC's proposal, we have consulted computer industry trade periodicals concerning the characteristics of STATE MATE. We conclude that, while the language employed by STATE MATE differs from others on the market, TBE has not demonstrated on this record that STATE MATE cannot execute the system specification functions required by the RFP, or that it otherwise does not satisfy the above definition of a formal language.

The protest is denied.

/1/ Since, contrary to TBE's note, no attachment to the price schedule was included, the agency used a copy of TBE's then current price list.

/2/ TBE argues that it could have provided the VMS capability some time after award the precise time frame is in dispute; however, as noted above, the RFP clearly required that the software be commercially available and capable of full performance as of the time proposals were submitted. See generally Martin Marietta Corp., B-233742, Jan. 31, 1990, 90-1 CPD Para. ***.