Skip to main content

B-247106, B-247106.2, May 4, 1992

B-247106,B-247106.2 May 04, 1992
Jump To:
Skip to Highlights

Highlights

That is. Technical proposals were required to show the offeror's technical approach or methodology. Of all assumptions upon which the technical proposal was based. The crux of ACC's protest is that the agency improperly evaluated Hughes's technical proposal and prejudiced ACC by accepting Hughes's lower -priced. The evaluation of proposals is primarily within the discretion of the procuring agency. We only question an agency's technical evaluation when the record shows that the evaluation does not have a reasonable basis or is inconsistent with the stated evaluation criteria. ACC contends that Hughes is barred from running mixed versions of Novell Netware by the solicitation's C.3 general requirement that "the contractor shall provide.

View Decision

B-247106, B-247106.2, May 4, 1992

PROCUREMENT - Special Procurement Methods/Categories - Computer equipment/services - Computer software - Technical acceptability DIGEST: Solicitation specifications for local area network reasonably allow for awardee's software approach notwithstanding protester's more restrictive view of the specifications.

Attorneys

American Communications Company:

American Communications Company (ACC) protests the award to Hughes LAN Systems, Inc. of a contract by the General Services Administration (GSA) under solicitation No. GSC-OIT-- 1006 /1/ for Token Ring Local Area Networks (LAN) to be used by the Social Security Administration's Office

We deny the protests.

The procurement addresses the replacement of Wang LANs used by more than 5,000 employees at over 150 offices nationwide with International Business Machines (IBM)-compatible Token Ring LANs. See Hearing Transcript /2/ (Tr.) at 43. The solicitation, issued in May 1991, requested offers using specifications that set out GSA's requirements in technical as opposed to functional terms. That is, the agency asked offerors to propose solutions that supported a specific set of technical characteristics.

The solicitation stated that award would be made to the lowest priced, technically acceptable offeror. Technical proposals were required to show the offeror's technical approach or methodology. Solicitation provision M.3.1 apprised the competitors that GSA would evaluate technical approaches for "feasibility, practicality, and appropriateness in accomplishing the tasks and deliverables identified." Solicitation provisions L.10.5 and M.3.5 expressly required the submission in writing, under a separate tab of the technical proposal, of all assumptions upon which the technical proposal was based.

The solicitation provided for two walk-throughs of the Office of Hearings and Appeals' facilities /3/ with a pre-proposal conference following the second walk-through, Tr. at 48, and the submission of written questions after the pre-- proposal conference. Tr. at 36. The agency received, and by solicitation amendment, answered over 100 offeror questions. Tr. at 36. The agency amended the solicitation five times prior to the July 11 closing date for receipt of proposals.

GSA received six proposals in response to the solicitation. After an initial evaluation, it established a competitive range of four firms. GSA conducted written discussions with each of the competitive range offerors and solicited revised proposals. Further evaluation of the offerors' revised technical proposals resulted in the rejection as technically unacceptable of two more offerors leaving a competitive range of two-- Hughes and ACC. In mid-October, GSA held price negotiations with both firms and requested best and final offers (BAFO). On November 21, GSA found both firms technically acceptable.

On December 18, GSA awarded a delivery order to Hughes as the lowest priced, technically acceptable offeror. This protest followed on December 24. GSA has stayed performance pending resolution of the protest. February 12, 1992, following receipt of the agency report on its initial protest, ACC filed a second protest.

The crux of ACC's protest is that the agency improperly evaluated Hughes's technical proposal and prejudiced ACC by accepting Hughes's lower -priced, technically unacceptable solution. ACC's protest focuses on technical facets of two solicitation-required software types: the network operating system software, and the 3270 communication service software. The network operating system software controls workstation/file server access to the network as well as the execution of network programs and related utility services. The 3270 software allows work-station/file server communication with IBM 3270 mainframe computers.

The evaluation of proposals is primarily within the discretion of the procuring agency, not our Office. Consequently, we only question an agency's technical evaluation when the record shows that the evaluation does not have a reasonable basis or is inconsistent with the stated evaluation criteria. East, Inc., B-235687.2, Dec. 26, 1989, 89-2 CPD Para. 591. The fact that the protester disagrees with the agency's judgment does not render the evaluation unreasonable. ESCO, Inc., 66 Comp.Gen. 404 (1987), 87-1 CPD Para. 450.

ACC objects to Hughes's offering a system that runs some of the Office of Hearings and Appeals' LANs under one version of a Novell brand name network operating system, while running the balance of the LANs under another version of the same vendor's software. Specifically, Hughes proposed Novell Netware Version 3.11 for the two sites that had 108 users and Novell Netware Version 2.2 for the balance of the LAN sites. Tr. at 165. In contrast, ACC offered Novell Netware Version 3.11 for all of the LAN sites.

ACC contends that Hughes is barred from running mixed versions of Novell Netware by the solicitation's C.3 general requirement that "the contractor shall provide, install, integrate, and implement, as operational, multiple ... LANs, all of which shall be of ... a single standard software configuration ... for all ... sites.". The upshot of ACC's position is that "single" in this paragraph must be read as meaning one vendor's software, and only one version thereof. This contention, in part, arises because Version 2.2-- a less expensive software package than Version 3.11 (Tr. at 147)-- only became /4/ available shortly before the solicitation's release. Tr. at 234.

GSA advised offerors of Version 2.2's possible availability as a candidate software solution when it amended the solicitation to include the following questions and answers:

"Q: The solicitation ... states that the network operating systems must be compatible with the large installed base of Novell Netware versions 2.15 and 3.1, and IBM OS/2 LAN Server Systems, version 1.2, that the Social Security Administration ... is currently utilizing nationwide. Does compatible mean server to server connectivity of different operating systems that share files and/or resources? Why was Netware 2.15 or the new 2.2 (replaces 2.15) not included with those that were "certified" in section C.1 when it is operational in the Social Security Administration ... environment.

"A: Please refer to the answer to Question #65 and revised subsection C.1."

The answer to Question #65 was:

A: Yes, the Government will consider another operating systems as long as it meets the hardware, software and communications requirements as stipulated in Section C. Please refer to revised subsection C.1."

ACC admits that before it entered into the pre-BAFO discussions with the agency it was aware of Version 2.2's existence and was concerned by its relationship to Version 3.11. Tr. at 233. ACC's concern was "whether" or not 2.2 was going to be allowed in the procurement." Tr. at 234, 238. Despite the technical advice from his employees that Version 2.2 was technically unacceptable, ACC's vice president and general manager was of the view that "it seemed like 2.2 would have been allowed." Tr. at 234. An ACC employee was instructed to raise the issue at the pre-BAFO discussions with GSA. The employee raised the issue twice in the form of a statement, variously remembered as either "Novell 2.2 does not work" by the government, Tr. at 128, /5/ or "Novell 2.2 would not meet the requirements" by ACC. Tr. at 239. The government personnel present did not respond to either statement.

The agency says that the single configuration requirement was "aimed at any piece of software that is on the network, that which we provide, that which the vendors provide. They all have to, you know, work together in a -- you know, in a single configuration." Tr. at 117.

The concept of mixing two versions of Novell Netware on the same multiple LAN system did not concern the evaluators because the Social Security Administration currently operated "totally intermixed" versions of the software in question. /6/ Tr. at 120. An evaluator testified that, in terms of the technical requirements of the solicitation, there were no technically significant differences, Tr. at 121, or maintenance differences, Tr. at 141, between the two versions of the software, and that based on the agency's practical experience "they're interchangeable from the way we use the systems." Tr. at 142. Finally, there was unrebutted testimony that during the entire procurement process no one asked any specific questions as to what the agency meant by single standard software configuration. Tr. at 150.

We find the agency's interpretation of the term "single standard software configuration" to allow the use of more than one version of a single vendor's software to be reasonable. We think the notion of multiplicity is inherent in the concept of a "configuration," /7/ particularly since nothing in the solicitation ruled out multiplicity as to versions within single software configuration. While ACC asserts the possibility that using more than one version of a single vendor's software might result in maintenance problems, there is no evidence that this is the case. Tr. at 142. Tr. at 142. In the absence of contrary evidence, we find reasonable the agency's determination that software that functionally works together can satisfy the single configuration requirement, and that Novell Version 2.2 and Version 3.1 are interchangeable from the way the agency uses the system and that they functionally work together. Tr. at 142.

Underlying ACC's understanding that Version 2.2 was not a viable solution was ACC's belief that the solicitation's "File Service/Network Security" requirement (C.6.3.1) prohibited any use of Novell Netware Version 2.2. The provision required the offered file service to support security mechanisms at a minimum of three different levels-- user log-in, file directory, and individual file security- and to provide users with "an associated set of capabilities to access, read, write, create, and delete file directories and individual files stored on the file service." This is an actual limitation of Version 2.2, as opposed to Version 3.11, which provides individual file level security.

Hughes devised a sophisticated, albeit somewhat more cumbersome, work- around of Version 2.2's file security limitation, using features of other software in its proposed system to the end that Hughes was able to use Version 2.2 and provide the required security. The agency evaluators verified the work-around and provided evidence at the hearing that it would work, Tr. at 167-8, which ACC has not rebutted.

The agency's acceptance of the Version 2.2 with the work-around was reasonable and consistent with solicitation's advice that offeror's technical approaches would be evaluated for "feasibility, practicality, and appropriateness." The solicitation only requires the file security capability and makes no mention that it must be provided in a "user friendly" fashion. Also, the agency has structured its computer records so that for most purposes security is at the directory level-- that is, the agency has allocated a directory to each user and, thereby, for the most part, obviated the need for individual file level security since users will not have access to each others directories. Tr. at 177. find the agency's acceptance of Hughes's Version 2.2 file level security work-around unobjectionable since it is an acceptance alternate to Version 3.11's actual file level security for most of the agency's LANs.

Finally, ACC contends that Hughe's proposed communications software is technically unacceptable because it does not meet the solicitation's 3270 compatibility requirement (C.6.6.4), which states"

The 3270 Communication Service shall provide its services to workstations on the network ... The workstation service must also include interfaces that support all IBM's 3270 Application Programming Interfaces (APIs)."

An API can be both a standard and a piece of software. APIs are encountered in the area of computer communications protocols-- i.e., norms governing the exchange of information between computer systems. The IBM 3270 APIs enable the user to exchange information between software applications on IBM-compatible personal computers (PC)/workstations/file servers and software applications on IBM mainframe computers. Early computer communication was basically a matter of transmitting keystrokes from a mainframe terminal (monitor and keyboard) to applications software within a mainframe computer. With the advent of the PC, it was was possible to exchange information resident on the PC's software applications to other software applications resident on a mainframe computer if the PC had the capability of emulating (i.e., passing itself off as) the mainframe computer's terminal. Programmers look to APIs-- as standards-- for the rules governing this PC/main-frame interaction. Programmers embody these rules in their own software applications programs (i.e., programs they write themselves) either by using pre-packaged API software programs produced by various vendors, including IBM, or by writing their own APIs using the API standards. As PCs have become more sophisticated, different APIs have evolved. APIs differ from one another by the specific elements they incorporate; these elements the most part interchangeably) as functions, calls, or verbs (e.q., function 40).

Essentially, this aspect of ACC's protest concerns the definition and scope of the term "all" IBM's API's. We find reasonable the agency position that, under the circumstances, the term obviously means all API's currently supported by IBM. Tr. at 50. IBM's current production system of API is called Extended High Level Language Programming Interface (EHLLAPI) and it consists of 36 functions that IBM currently supports. Tr. at 50. Hughe's BAFO offered EHLLAPI, which the agency found met its requirements. Tr. at 71. ACC has urged several contrary, but inconsistent, definitions in the course of this protest for the term "all" IBM's APIs. First ACC argued a literalistic definition that the solicitation required "all" APIs IBM ever wrote (approximately 106 functions), whether they have a current use or not. Next, ACC contended that the requirement referred to an API IBM wrote for one of its first work-station personal computers-- the 3270 PC-- called High Level Language Application Programming Interface (HLLAPI), which had 44 functions. See Tr. at 180. Neither of these earlier API packages are currently supported by IBM.

At the hearing, ACC introduced another definition-- that "all" IBM's APIs means EHLLAPI and its 36 functions plus three additional functions from HLLAPI. Tr. at 189-190,199. In our view the three additional HLLAPI functions, albeit possibly useful, are not required by the solicitation since IBM no longer supports them, Tr. at 185] consequently, we do not consider them to be IBM's APIs as contemplated by this specification.

ACC's position on this issue stems in large part from advice that an ACC subcontractor, with expertise in the area of APIs, provided to ACC. Tr. at 203. That advice was premised on a "default assumption"-- that the agency either (1) had previously written software applications that required more functions than the current IBM APIs could provide, or (2) wanted to use APIs no longer supported by IBM in its application software. Tr. at 205-206. These assumptions are in fact inconsistent with the environment in which the software will be used. Specifically, the agency notes that: (1) the Wang system being replaced does not use APIs, Tr. at 49; (2) the system is for the most part limited to word processing and communications, Tr. at 41; and (3) any applications programming that may be done in the future will use the current IBM APIs. Tr. at 47. ACC's subcontractor made its assumptions without attending the site visits, Tr. at 204, and it is apparent that the assumptions missed the mark and resulted in ACC's proposal providing unnecessary API capability in excess of the agency's minimum requirements. ACC did not advise the agency of any assumptions made in the preparation of its technical proposal with regard to this requirement, as it was admonished to do in the solicitation, and, consequently, the agency was unable to address this matter during discussions.

Under the circumstances, we find reasonable the agency's determination to accept Hughe's proposal software that furnishes APIs currently supported by IBM.

The protest are denied.

/1/ The solicitation was issued to 11 vendors under master solicitation No. OIT-8052-- a multiple award contract.

/2/ A hearing was conducted, pursuant to 4 C.F.R. Sec. 21.5 (1992) to receive testimony on the issues of this case.

/3/ The sites selected were the Baltimore, Maryland, hearing office and the Falls Church, Virginia, headquarters.

/4/ Versions 2.2 is limited by a maximum capacity of 100 users per site license (i.e., it cannot be used for LANs having more than 100 users). Tr. at 235. The average agency LAN has about 12 users). Tr. at 235. The average agency LAN has about 12 users. Tr. at 126. Two of the agency LAN sites exceed the Version 2.2 limitations since they have 108 users each, hence, Hughe's offer of two LANs running Version 3.11, a solution that can accommodate more than 100 users on LAN. Tr. at 165.

/5/ A government evaluator testified:

"Both statements were made, very curios by us, just out of the blue with no-- they didn't tie it to anything we were talking about. The statements just-- they didn't tie it to anything that we talked about. They were between comments. The statement was made twice that 2.2 does not work and that was the total extent of the statement." Tr. at 128.

ACC asserts that the government's silence constituted misleading discussions and that GSA had a duty to correct ACC's misapprehension of the specification since GSA was aware Version 2.2 was acceptable. disagree. The record establishes that ACC's comments regarding Version 2.2 were statements and could not be reasonably taken as questions. Under the circumstances, given that ACC's technical approach was acceptable, GSA had no independent duty to apprise ACC that Version 2.2 could be acceptable.

/6/ The agency offered unrebutted testimony that it was currently running three different versions of Novell Netware on a single LAN. Tr. at 120.

/7/ Webster's New World Dictionary of Computer Terms, 3rd Ed. defines "configuration" as:

"An assembly of machines that are interconnected and are programmed to operate as a systems. The layout or design of elements in a hardware or information processing system." and "configure" as:

"To assemble a selection of hardware or software into a system and to adjust each of the parts so that they all work together."

GAO Contacts

Office of Public Affairs