THIS OPINION WAS INITIALLY ISSUED UNDER PROTECTIVE ORDER AND IS BEING RELEASED TO THE PUBLIC IN REDACTED FORM ON JUNE 15, 1994 _____________________ DENIED: May 10, 1994 _____________________ GSBCA 12754-P FEDERAL COMPUTER CORPORATION, Protester, v. DEPARTMENT OF THE TREASURY, Respondent, and ViON CORPORATION, Intervenor. Gerard F. Doyle, Alexander T. Bakos, and Scott W. Woehr of Doyle & Bachman, Washington, DC; and David Kovach of Federal Computer Corporation, Falls Church, VA, counsel for Protester. Donald M. Suica, Duane L. Zezula, James W. Corbitt, Jr., Greg M. Weinman, and Corlyss M. Drinkard, Office of Chief Counsel, Internal Revenue Service, Washington, DC, counsel for Respondent. David R. Hazelton, Roger S. Goldman, Philip L. Gordon, and C. Chad Johnson of Latham & Watkins, Washington, DC, counsel for Intervenor. Before Board Judges DEVINE, BORWICK, and NEILL. NEILL, Board Judge. This protest has been filed by Federal Computer Corporation (FCC). It concerns the acquisition of large-scale International Business Machines Corporation (IBM) compatible computer hardware and software as well as maintenance, training and other supplies and services for centralized support of tax administration processing at two sites operated by the Internal Revenue Service (IRS). FCC challenges IRS's award of a contract for this procurement to ViON Corporation (ViON). ViON has intervened in this protest as an intervenor of right. FCC has formally amended this protest on four different occasions. At the start of the hearing on the merits, the protest contained four basic counts. Count I alleges that ViON's proposal was non-compliant with mandatory technical requirements of the solicitation. Count II contends that the IRS failed to treat offerors equally and in accordance with the solicitation. Count III states that IRS did not conduct meaningful discussions. Finally, Count IV avers that in awarding the contract to ViON, IRS has awarded to a non-responsible offeror.[foot #] 1 We have examined each of protester's various arguments. We find that often they involve an interpretation of solicitation provisions which is restrictive of competition. By contrast, the interpretation given to the same provisions by IRS is considerably more supportive of full and open competition. For this and other reasons more fully described below, we deny the protest. Findings of Fact The Solicitation 1. On April 29, 1992, the General Services Administration (GSA) granted a delegation of procurement authority to the Department of the Treasury to establish a Corporate Systems Modernization/Mirror Image Acquisition (CSM/MIA). The purpose of CSM/MIA is to replace IRS's inventory of aging IBM and compatible mainframe computers, and storage subsystems that are currently used to support tax administration processing at two IRS computing centers. Protest File, Exhibit 725 at C-10, C-11. 2. The solicitation or request for proposals (RFP) for the CSM/MIA procurement was issued on July 31, 1992. The solicitation describes the scope of this procurement in the following terms: To meet the requirements of the Corporate Systems Modernization/Mirror Image Acquisition (CSM/MIA), the IRS intends to acquire large-scale IBM compatible host system's hardware; peripheral storage subsystem's hardware and firmware; maintenance services, support services, training, and other supplies and services. ----------- FOOTNOTE BEGINS --------- [foot #] 1 This final count has not been addressed in protester's posthearing brief. We, therefore, consider it to have been abandoned. ----------- FOOTNOTE ENDS ----------- Protest File, Exhibit 725 at C-11. Clause H.14 3. One of the solicitation provisions of particular importance in this protest is Clause H.14, entitled "Availability." In Count I of its protest, FCC contends that the ViON proposal is not in compliance with the requirements of Clause H.14. The final amended version of this clause reads as follows: H.14 AVAILABILITY The equipment and software proposed and delivered in response to this solicitation must have fully and successfully completed all beta and field testing and be capable of performing the requirements specified in Section C. This requirement must be met by August 1, 1993, and applies only to the major components of the Initial Systems delivery (see Section C.2.6.8). This does not include minor components, connectors, cables, or other standardized mass-produced integral parts. Protest File, Exhibit 725 at H-17. The "major components" referred to in the availability provision are, as the clause indicates, found in Section C.2.6.8. This clause identifies three components as major, namely, the CEC (Central Electronic Complex), the DASS (Direct Access Storage Subsystems), and the RCSS (Robotics Cartridge Storage System). Id. at C-49. The RFP provides no other definition of "major components." 4. The original version of Clause H.14 did not distinguish between major and minor components. Protest File, Exhibit 12 at 488. The change was made in Amendment 17, issued on August 9, 1993.[foot #] 2 Id., Exhibit 140. In answer to interrogatories posed during this protest, IRS has explained: [Amendment 17] relieved Offerors from the onerous task of verifying that "minor components, connectors, cables, and other standardized, mass produced integral parts" had met the required availability date of August 1, 1993. Additionally, this elaboration was provided so that any minor integral hardware components within the units being offered would not in themselves cause the larger, major components from being unacceptable. ----------- FOOTNOTE BEGINS --------- [foot #] 2 This date may be August 19 rather than August 9. The date shown on copies of the amendment contained in the record is not clear. See Protest File, Exhibits 13 at 748, 140 at ___ 26455. ----------- FOOTNOTE ENDS ----------- Respondent's Trial Exhibit 24 (IRS Answers to FCC Interrogatory No. 4). 5. Closely related to Clause H.14 is a certification provision contained in Clause K.31 of the RFP. It reads: K.31 BETA AND FIELD TESTING CERTIFICATION OF FULL AND SUCCESSFUL COMPLETION OF ALL BETA AND FIELD TESTING AND THE CAPABILITY TO PERFORM THE REQUIREMENTS SPECIFIED IN SECTION C IN ACCORDANCE WITH H.14 AVAILABILITY. The Offeror certifies to the best of its knowledge and belief that: All major hardware components necessary, and proposed, to meet the CSM/MIA Initial Systems requirements (see Section C.2.6.8) for host processing and storage subsystems have fully and successfully completed all beta and field testing and are capable of performing the requirements specified in Section C as of August 1, 1993. Protest File, Exhibit 725 at K-40. Clause K.31 was added to the solicitation by Amendment 17, which introduced the distinction between major and minor component into Clause H.14. Id., Exhibit 140. 6. Protester's proposal manager contends that Clause K.31 was added to the solicitation because of concerns voiced by FCC representatives over the need to verify compliance with the beta and field testing requirement set out in Clause H.14. He has testified that, at a meeting with IRS representatives in August 1993, FCC questioned how compliance with the requirement for beta and field testing could be verified. FCC representatives noted that they could find no mechanism in the RFP to establish that a vendor really was compliant with H.14. Transcript at 200-02. 7. Protester's proposal manager has also testified that the beta and field test requirement of Clause H.14 prior to its amendment in August 1993 was a matter of special concern to FCC 8. Protester's proposal manager has testified that after amendment of H.14 and the issuance of the certification provision in Clause K.31 in August 1993, he discussed with the contracting officer the documentary support required under Section L of the solicitation to demonstrate compliance with the beta and field testing requirement of the amended Clause H.14. 9. The contracting officer recalls having had a discussion with FCC's proposal manager sometime in August 1993 regarding certifications which would be required to demonstrate compliance with the requirements of Clauses H.14 and K.31. She also recalls that this conversation included discussion of a certification from one of FCC's subcontractors. She denies, however, that the conversation involved discussion of 10. By letter dated August 19, 1993, FCC amended its proposal 11. There is nothing in the record to indicate that, at the time Clause H.14 was amended in August 1993, FCC viewed the major/minor component distinction as being a significant change in the ground rules of the solicitation. No objection or protest was lodged. The IBM Code Compatibility Provision (Clause C.2.6.1) 12. Another RFP provision discussed at great length in this protest is Clause C.2.6.1. In Count I, FCC contends that ViON's proposal failed to meet the requirements of this provision. Clause C.2.6.1 is the first subsection of section C.2.6, which is entitled "Hardware Components." In its final amended version, Section C.2.6.1 reads as follows: C.2.6.1 IBM CODE COMPATIBILITY a. The Contractor shall provide hardware, software, and firmware all of which are capable of supporting all of the functions and features of MVS/ESA System Product Version 4.2 and Data Facility Product (DFP) Version 3.3, except for support of the "dual copy" feature. 1. The Contractor shall provide full support for the "dual copy" feature of DFP Version 3.3 no later than the scheduled delivery of Hardware Upgrade 1 (see Section F.6.2 for schedules). b. The Contractor shall deliver and install hardware, software, and firmware all of which is fully code compatible with existing systems (operating systems, applications systems and program products) that are required to be connected (C.2.6.6) to CSM/MIA systems. An inventory of the current hardware may be found in Section J, Attachment VI. Software environments may be found in Section J, Attachments II and IV. Protest File, Exhibit 725 at C-21. 13. MVS/ESA System Product Version 4.2 and Data Facility Product (DFP) Version 3.3 are operating system software products developed and licensed by IBM. MVS/ESA 4.2 and MVS/DFP 3.3 are both specifically named as the existing operating system at the IRS Martinsburg and Detroit Computing Centers. Protest File, Exhibit 725 at J-III-1 to J-III-2. The IRS is not acquiring these operating software systems under this solicitation. Transcript at 112, 119-20. 14. FCC read "capable of supporting" in C.2.6.1.a to mean that offerors had to provide hardware, software, and firmware which actually allowed IRS to use all of the features and functions of MVS/ESA 4.2 and DFP 3.3, except dual copy. Transcript at 196, 213. 15. Two features which received a considerable amount of attention in this protest were "Dynamic Reconfiguration Management" (DRM) and "PDS [Partitioned Data Set] Search Assist." DRM is a function of MVS/ESA 4.2. Transcript at 390. An expert called by FCC[foot #] 3 explained that the benefit of DRM is that, with this feature, a new device can be added to or deleted from a system without the need to pre-engineer or "pre- gen" the I/O configuration. Devices can be added or changed dynamically, on the fly, without the need to turn off the processor. Id. at 387-89. PDS Search Assist is a feature of DFP 3.3. It serves to improve access to the directories of data sets. Id. at 425-26. 16. 17. The IRS contends that it does not need DRM or PDS Search Assist. IRS states that it has DRM functionality through pre-genning with a system called "Shamman." Although this still requires a power-on-reset to update the hardware system area inside the CEC, this is not a concern because IRS does a power- on-reset every two weeks. Transcript at 547-48, 571-73. 18. FCC's expert testified regarding the language used in Clause C.2.6.1. He explained that "capable of supporting all features and functions" of a particular version and release of operating system software means the equipment is presently able to execute all of the features and functions of that version. It is "available now, not at some future time; . . . testing is ----------- FOOTNOTE BEGINS --------- [foot #] 3 This witness was recognized by the Board as a qualified expert in the area of mainframe computer environments, including feature availability on such environments. Transcript at 385. ----------- FOOTNOTE ENDS ----------- complete, the debugging is complete and it's ready to go." Transcript at 397. 19. Prior to the release of this solicitation, vendors were invited to comment on draft provisions of it. Transcript at 743. IBM submitted comments regarding the proposed Clause C.2.6.1. It urged IRS to modify the RFP in such a way as to exact from vendors detailed information regarding their ability to support the features and functions of the operating systems mentioned in the clause. This information would then serve as the basis for evaluating the level of support offered. Protest File, Exhibit 6 at 68-70. In making its suggestion, IBM did not hesitate to list the multiple functions and features its own equipment is capable of supporting. Id. at 101-02. The individual who was serving as the contracting officer at the time comments were provided on the draft RFP has testified that IRS did not respond to IBM's suggestions or those submitted by any other vendor. Rather, the written and oral comments were reviewed and, as considered appropriate, incorporated into the RFP. Transcript at 745-46. 20. As originally issued, C.2.6.1.a read: a. The Contractor shall provide hardware, software, and firmware all of which are capable of supporting all of the functions and features of: 1. Enterprise Systems Architecture/390 (ESA/390), and 2. MVS/ESA System Product Version 4.2 and Data Facility Product (DFP) Version 3.3. Protest File, Exhibit 12 at C-21. 21. One offeror, commenting on this original version of C.2.6.1.a in a formal question to IRS, suggested that IRS either specify the features which it required or accept a statement of intent from vendors to provide comparable functionality after IBM provides the detailed documentation for its announced feature which is required by IRS. Protest File, Exhibit 18 at 1764-65. In responding to this question, IRS referred offerors to two changes in the solicitation. Id. The first was a change in Clause C.2.6.1 itself. Reference to ESA/390 system architecture was deleted. The second change was the addition of a new provision to Clause C.2.2, GENERAL HARDWARE REQUIREMENTS. This new section read: (d) The Contractor shall furnish hardware and software technology products for CSM/MIA that provide support for the various new features and functions of Enterprise Systems Architecture/390 (ESA/390) and related systems software products within twelve (12) months from the time such new features and functions are generally available for commercial distribution. Id. at C-12, C-21. This twelve month period was later extended to twenty-four months through Amendment 5. Id., Exhibit 30 at C- 12. 22. One particular feature of DFP 3.3 which was called out in the original solicitation was the so called "dual copy requirement." The requirement is found in subsection C.2.6.4.2.f of the original solicitation. Protest File, Exhibit 12 at C-31. Based on vendor response, IRS eventually relaxed this specific requirement. Transcript at 542-43. In Amendment 5, subsection C.2.6.4.2.f was amended to require this feature at the time of the first upgrade. Protest File, Exhibit 30 at C-31. This change was also reflected in the IBM compatibility provision of the solicitation, namely subsection C.2.6.1.a, by the addition of the following provision: 1. The Contractor shall provide full support for the "dual copy" feature of DFP Version 3.3 no later than the scheduled delivery of Hardware Upgrade 1 (see Section F.6.2 for schedules). Id. at C-21. 23. FCC's proposal manager has testified that he interpreted the separation of dual copy from the other features and functions of MVS/ESA 4.2 and DFP 3.3, and deferral of the requirement to provide the dual copy feature by Hardware Upgrade 1 as confirming that the offered hardware, software, and firmware had to be presently able to execute all other features and functions of MVS/ESA 4.2 and DFP 3.3. Transcript at 194, 210-13. This witness does not see any significant difference in the use of the terms "full support for the 'dual copy' feature" in C.2.6.1.a in referring to the dual copy feature at Hardware Upgrade 1 and the words "capable of supporting all of the functions and features" appearing in that same clause. Id. at 283-84. 24. IRS procurement officials contend that Clause C.2.6.1 is, as it states, simply a compatibility provision. The chairman of the technical evaluation panel, who was also associated with the drafting of the solicitation, testified: The title of the section is "IBM CODE COMPATIBILITY" and it's pretty straightforward to me. IBM code compatibility is the common denominator in IBM PCM [plug compatible machine] buys. I mean, compatibility with MVS/ESA is what defines an IBM PCM acquisition. . . . . Elsewhere in our RFP, in addition to this section, we talk about hardware, software and firmware, so to me it's clear that we were looking to acquire the physical systems hardware that was capable of supporting MVS/ESA features. With just one exception in this section to dual copy, this section is only an implicit -- makes only implicit reference to any MVS/ESA feature. So, that's what we were looking for, general code compatibility with a futuristic view. Transcript at 540-41. Similarly, the project manager for this procurement testified that the particular requirements put forth in the solicitation were defined by the benchmark and other specific provisions of the RFP. By contrast, the language in C.2.6.1 was to identify a compatibility environment for the acquisition and not to define features or a delivery schedule for features of MVS/ESA. Id. at 118-22. 25. In discussing the language of C.2.6.1.a, IRS officials have stated that a significant difference was intended by the choice of the terms "full support" with regard to the dual copy feature and the words "capable of supporting" used with reference to "all of the functions and features of MVS/ESA System Product Version 4.2 and Data Facility Product (DFP) Version 3.3. . . ." The project manager has explained that the term "full support" was intended to be more onerous in view of the importance of this specific feature. Transcript at 121, 139. The chairman of the technical evaluation panel, contrasting the two phrases, explained: that "capable of supporting" relates to the agency's overall purpose in this procurement of acquiring physical systems hardware that is capable of supporting MVS/ESA features. "Full support," on the other hand, "means the feature is operational. All the pieces have to be there to let us use the feature." Id. at 540-42. 26. A review of the solicitation for this procurement readily discloses that in those instances where IRS was desirous of a specific feature or function, it was quite capable of so specifying. As already noted, the requirement for the dual copy feature, even before mention of it was added to the compatibility provision in Clause C.2.6.1, was expressly called out in subsection C.2.6.4.2.f of the original solicitation. Finding 22. Similarly, a requirement that the CEC be capable of dynamically allocating processing cycles, central storage, expanded storage, and channel resources in a physically partitioned mode and in a logically partitioned mode is set out in C.2.6.2.3.b. Likewise, the requirement for support of the native ESCON[foot #] 4 connectivity feature is spelled out at C.2.6.6.2.2 and C.2.6.6.3.2, and the need for support for 36- track capability is expressly called for in C.2.6.5.6.d.2. Protest File, Exhibit 725 at C-24, C-31, C-39, C-42b, C-45. ----------- FOOTNOTE BEGINS --------- [foot #] 4 Enterprise Systems Connection Architecture. ----------- FOOTNOTE ENDS ----------- 27. FCC's proposal manager for this procurement and its own qualified expert have both testified that support of two gigabytes of central storage is a feature of MVS/ESA. Transcript at 219, 726. FCC's proposal manager has admitted, however, that the IBM processor is configured with one gigabyte in accordance with the requirements of the solicitation[foot #] 5 and is not sold with two gigabytes. He testified that, in discussions with representatives, he confirmed that the is architecturally capable of supporting two gigabytes of central storage but that it is a marketing decision on the part of not to sell it with two gigabytes. Id. at 219-20. 28. FCC's expert has testified that an additional gigabyte of central storage can be added to the processor through the addition of memory cards or memory boards to the machine. It is the opinion of an expert called by ViON[foot #] 6 that, given the design and size of the frame, there simply is not room for the addition of this equipment. Transcript at 629. Neither of these experts has ever seen an processor with two gigabytes of central storage. Id. at 452, 629. Although recognizing that the typical processor does not contain two gigabytes of central storage, FCC's proposal manager remains convinced that it is "capable of supporting two gigabytes." Id. Conformance with Underwriters Laboratory (UL) Standard 1950 (Clause C.2.3.2) 29. Another provision in the solicitation which has been the source of considerable discussion in this protest is Clause C.2.3.2. In Count I, FCC contends that ViON's proposal failed to comply with the requirements of this clause as well. The clause reads as follows: C.2.3.2 ELECTRONIC EQUIPMENT CONSTRUCTION Except as modified below, the Contractor shall provide equipment under this contract that conforms to the requirements of the current revision of UL Standard 1950, "Safety - Information Technology Equipment including Electrical Business Equipment." Equipment that began manufacture prior to the date the current standard took effect must be compliant with the ----------- FOOTNOTE BEGINS --------- [foot #] 5 Section C of the solicitation requires the contractor to configure each CEC with a minimum of one gigabyte of central storage. Protest File, Exhibit 725 at C-23. [foot #] 6 This individual was recognized by the Board as expert, inter alia, in mainframe computer environments, including features in such environments. Transcript at 601, 610. ----------- FOOTNOTE ENDS ----------- standards in effect at the time the equipment began manufacture. Protest File, Exhibit 725 at C-18. 30. Protester contends that the Robotic Cartridge Storage Subsystem (RCSS) offered by ViON in this procurement is not in compliance with the requirements of C.2.3.2. Complaint 26. 31. The RCSS offered by ViON is the Bosch BSS 8800 ATL (Automated Tape Library). Protest File, Exhibit 154 at 27003. Section L of the RFP requires offerors to provide a detailed explanation of how their proposals met each of the requirements of the RFP. Id., Exhibit 725 at L-18. To demonstrate that the RCSS it was offering complied with the requirement of C.2.3.2, namely, that equipment conform with UL Standard 1950, ViON included in its proposal a letter dated October 9, 1992, from the Director of Marketing and Sales of Bosch Storage Systems. The letter states in part: Bosch Storage Systems (BSS) certifies that the Bosch Robotic Cartridge Storage System has the following characteristics: 1. All equipment conforms to the requirements of UL Standard 1950, "Safety - Information Technology Equipment Including Electrical Business Equipment." Id., Exhibit 56 at 2341. The chairman of the technical evaluation panel testified that the panel had no reason to believe that the Bosch RCSS was not compliant with UL Standard 1950. Transcript at 562. 32. [foot #] 7 33. [foot #] 8 34. 35. ----------- FOOTNOTE BEGINS --------- [foot #] 7 [foot #] 8 ----------- FOOTNOTE ENDS ----------- 36. At hearing, FCC called a witness whom the Board recognized as an expert in the UL listing process versus compliance with UL standards and UL product evaluation procedures. To prepare for his testimony, this individual reviewed the UL file documentation on the Bosch application provided by UL to FCC in response to subpoenas issued during the protest. This expert also personally interviewed the UL project engineer to whom the Bosch application has been assigned. This expert commented briefly on some observations contained in handwritten notes of the project engineer regarding the Bosch equipment. These notes of the UL engineer are contained in the record. Protester's Hearing Exhibit 9 at 4, 7, 8, 11 (unnumbered). 37. 38. 39. FCC's expert on UL compliance has also testified that he has never analyzed the Bosch BSS 8800 ATL, never looked at the machine or drawings of the machine, and never observed the operating characteristics of the machine. Transcript at 904. 40. 41. The Grau and Bosch ATLs 42. ViON and IRS maintain that the Bosch BSS 8800 ATL is identical to the ABBA/2, a system developed and engineered by Grau Automation, a German concern. The record contains information which supports the conclusion that although the systems may not be absolutely identical, they are, nonetheless, substantially the same. During the course of this protest, FCC counsel was able to secure from counsel for Bosch what was purported to be Bosch's entire file relating to Bosch's ongoing effort to obtain UL approval of the BSS 8800 ATL. In this package is a three page article of unknown origin on the ABBA/2. It appears to have been prepared by Grau Automation to promote its system. Protest File, Exhibit 662 at P.29-31/31. As already noted, through subpoenas served on UL, FCC counsel was also able to secure UL's file on the Bosch application for approval of the BSS 8800 ATL. This material contains technical literature describing the BSS 8800 ATL. Id., Exhibit 668. The record also contains a three page announcement issued by Bosch on March 2, 1993, indicating that Bosch is entering the U.S. mainframe storage market with the launching of the BSS 8800 ATL. Id., Exhibit 667. 43. A comparison of the materials described in the finding above demonstrates that the ABBA/2 system and the BSS 8800 ATL are substantially the same in function and design. The March 2, 1993, Bosch announcement states that the BSS 8800 will be "based on the successful Grau ABBA/2 ATL" which is currently installed at over 120 sites in Europe. However, a comparison the article on the ABBA/2 and the technical literature on the BSS 8800 shows that the BSS 8800 appears to be more than simply "based on" the Grau ABBA/2. The systems are alike in that they involve the same type of design and technology. Both are modular in nature and utilize "quadro tower" components. Both employ a robotic "gripper." The key features of open architecture, configurability, small footprint, and adaptability to new media characterize both systems. The systems are alike even to the degree that a single robot system in each is said to be able to sustain a mount/dismount rate of 250 actions per hour. 44. The article on the ABBA/2 which is found in Bosch's files reports that Grau Automation, in order to handle the large market in North America, has entered a partnership with Bosch GmbH in Stuttgart, Germany. The article, which bears no date, states: "This year we're scheduled to begin manufacturing under license at the Bosch factory in Chicago." Protest File, Exhibit 662 at P.30/31. 45. Production of the Grau system in the United States appears to have begun in late 1992 or early 1993. 46. In this same letter of August 17, 1993, from Bosch to ViON, Bosch explains that it is manufacturing and distributing the ATL that was developed and engineered by Grau Automation in Germany. Because Grau did all testing prior to initial shipment, Bosch contends that no Beta or field testing is required for the U.S. manufactured ATLs. Protest File, Exhibit 547. 47. 48. 49. Since this protest has been filed, Bosch has contacted Grau Automation and asked for a confirmation of whether the BSS 8800 ATL and the Grau ABBA/2 are the same. By letter dated March 29, 1994, Grau replied: The BSS 8800 system is identical to the ABBA/2 system. After more than 100 systems of its predecessor ABBA/1 had been successfully installed, the improved model ABBA/2 was presented on "cebitc" fair in Hanover in March 1992 and was ready to go into production. Respective field tests had already been completed at that time. Since December 1991, two ABBA/2 systems were in permanent test operation under MVS connection to a service computer centre. Intervenor's Hearing Exhibit 8. OEM and Third Party Certification 50. At hearing, ViON called an employee of the GSA to comment on Clause C.2.3.2 and related provisions. This witness was recognized as an expert in the area of equipment fire protection, and specifically fire protection in Government environments. Transcript at 834-37. This expert explained that, as part of his position, he has advised agencies, including IRS, on general specifications calling for fire safety. He further explained that there are various options open to the Government in drafting specifications of this type. Vendors can be asked to provide their own certification that the equipment offered complies with specified criteria or standards. Alternatively, vendors can be asked to demonstrate that some third party such as a private engineering firm or a laboratory has reviewed the product for compliance and found it acceptable. Id. at 838-39. This expert identified Clause C.2.3.2 as an example of a vendor's own certification of compliance -- as opposed to a certification from some third party. Id. at 838-42. 51. The chairman of the technical evaluation panel, who admits to having had a hand in drafting Section C, has testified that what the Government sought in Clause C.2.3.2 was an engineering judgment of the OEM (original equipment manufacturer) as to the conformity of an item with a specified standard. Transcript at 539-40, 561-63. He pointed out that in this RFP, when the Government sought equipment adjudged or listed by third parties as compliant with a particular standard, it could and did expressly ask for it. Id. at 561-64. 52. In point of fact, in contrast to Clause C.2.3.2, which refers simply to equipment which "conforms" to the requirements of a UL standard, other provisions in the RFP require the vendors to provide equipment that is UL "listed." For example, Clause C.2.3.3 requires that cable provided under the contract be listed by UL or other nationally recognized testing laboratories. Protest File, Exhibit 725 at C-20. Similarly, Clause C.2.3.2.4 requires that the contractor provide air filters that "comply with Underwriters' Laboratories, Inc. Class I or better, and shall be a listed type." Id. at C-19. Compliance of the ABBA/2 With Safety Standards 53. At hearing, ViON introduced a letter dated March 29, 1994, from Grau Automation to a representative of Bosch Storage Systems. The letter states: Before starting marketing ABBA/2, the IBM safety department examined and certified our ABBA/2 system according to all German and European rules. ABBA/2 was accepted (see enclosure OEM safety) as per -EN 50204 -VDI 2853 -IEC 950 -VDE 0871 Intervenor's Hearing Exhibit 8. 54. IEC 950, which is referenced in the Grau letter of March 29, 1994, is a European safety standard issued by the International Electrotechnical Commission (IEC). It is similar in many respects to UL Standard 1950. Indeed, the intent is to make these standards similar and ultimately the same so that products found to be in compliance with them can be sold both in Europe and America without the need for multiple testing. Transcript at 919-20. An edition of UL 1950 included in the record contains printed marginal notations showing where IEC 950 deviates from similar provisions of UL 1950. These deviations may represent provisions which are less stringent than, equivalent to, or more stringent than component requirements in IEC 950. Protest File, Exhibit 665 at 5 (Prologue) and marginal notes throughout. In view of these differences, if a product complies with IEC 950, it may or may not comply with UL 1950. Transcript at 868, 902. Benchmark Provisions and Guidance 55. In Count II of its protest, FCC contends that it was unfairly treated during the benchmark process of this procurement. Clause L.18.1.8 of the solicitation addresses the purpose and procedure for the benchmark portion of the evaluation process. The relevant portions of this section state: L.18.1.8 BENCHMARK a. The Offeror shall perform a benchmark which the Government will use to validate the compliance of the proposed CEC, DASS, RCSS, and Connectivity subsystems with Section C performance requirements. . . . . g. Offerors are advised that they should be prepared to rerun the benchmark for Government verification (as stated in Section M.5) within twenty-one (21) calendar days from receipt of written notification by the contracting officer. And, . . . . 2. the Offeror shall perform the Government-observed benchmark on identical equipment as was used to run the benchmark for which results were evaluated. Protest File, Exhibit 725 at L-27 to L-29. 56. Subsection C.2.6.2.c of the RFP provides: The minimum CEC performance level is defined by the CSM/MIA benchmark. The Contractor shall demonstrate a minimum CEC performance level by successful execution of the CSM/MIA benchmark. Protest File, Exhibit 725 at C-23. The solicitation's benchmark manual provides: 1.1 OBJECTIVES OF THE BENCHMARK The benchmark will be used to validate the compliance of the proposed CEC (Central Electronic Complexes) DASS (Direct Access Storage Subsystem) RCSS (Robotic Cartridge Storage Subsystem), and Connectivity Subsystems with the requirements stated in Section C of the CSM/MIA RFP. It will be evaluated in accordance with Section M. The benchmark shall be performed by all offerors and results submitted by April 30, 1993. The apparent winner's performance validation execution may, at the Government's option be witnessed by a Government evaluation team prior to contract award. Id. at J-X-6. 57. In publishing its response to a vendor question at the time it issued Amendment 7 in December 1992, the IRS stated that benchmark configuration substitutions were not permitted unless specifically granted by the benchmark instructions. Protest File, Exhibit 507 at 35; Transcript at 226. 58. In March 1993, at the time it issued RFP Amendment 10, the IRS modified its position regarding substitution in benchmarking. It did so through a published answer to a question posed by a vendor. Protester claims to have posed the question itself. Transcript at 230-31. The question and answer were as follows: Q1. To avoid incurring unnecessary expenses, we wish to make some equipment substitutions in the hardware configuration for the initial benchmark. Will the Government permit us to conduct the initial benchmark test with certain items of equipment substituted for the devices actually proposed by us, provided that benchmark results are not affected in any way? A1. Yes, for Performance Validation Element One (the unwitnessed benchmark), such substitutions are permitted, provided that the substitution has no impact on system performance. Protest File, Exhibit 511 at 1 (unnumbered). 59. The record contains a single sheet said to be an excerpt from minutes of a meeting of FCC and IRS officials on August 11, 1993. At that meeting, IRS is reported to have informed FCC that offerors were expected to benchmark what they propose and propose what they benchmark. Protest File, Exhibit 706, Subtab 14. 60. FCC's proposal manager contends that, under the question and answer guidance provided with Amendment 10, an offeror could substitute equipment at the benchmark only if it had no impact whatsoever on benchmark performance. Transcript at 230-31. 61. IRS understands the guidance differently. The project manager for the CSM/MIA procurement has testified: I think it's implicit in this answer as to what our objective was. I don't know how anyone in this competitive arena responding to questions and answers could have -- could not understand. And when we speak of impact on system's performance, we're talking about impact that's detrimental to the other offerors in the competition. Transcript at 157. This witness also observed that he did not believe that any two runnings of a benchmark would have precisely identical performance results. Id. at 158. 62. 63. 64. 65. 66. FCC's Alleged Understanding Regarding Benchmark Substitution 67. FCC's proposal manager has testified that, based on provisions in Clause L.18.1.8 (Finding 55) and guidance issued with Amendment 7 (Finding 57) and Amendment 10 (Findings 58, 60), his company understood that equipment demonstrated in the unwitnessed benchmark had to be the same as that used for the witnessed benchmark. Transcript at 227-31. 68. FCC's proposal manager has also testified that at the FCC debriefing, he learned that FCC's Modification of the Benchmark 69. The IRS benchmark team leader has testified that FCC's first unwitnessed benchmark submission employed changes to the block sizes of the benchmark materials. Transcript at 167, 592. IRS identified the changes as deficiencies and informed FCC that its initial submission was unacceptable. Id. at 590-91. When FCC reran the benchmark, its benchmark score dropped. Id. at 593. 70. In reviewing the rerun of FCC's unwitnessed benchmark, the benchmark contractor assisting IRS with this CSM/MIA procurement noticed that FCC had made what appeared to be an inadvertent change in the benchmark.[foot #] 9 Protest File, Exhibit 137 at 26217. The effect of the error was to impose a variable rather than constant workload on the system. This resulted in a greater workload and would, in the opinion of the benchmark contractor, cause FCC's wall clock time for the running of the benchmark to be overestimated. The conclusion reached by this contractor was that FCC's proposal "may have received a lower score for its benchmark results than it would have, had this parameter change not been present." Id. at 26445. The benchmark contractor recommended, therefore, that FCC be given a chance to correct and rerun the unwitnessed benchmark yet another time. Id. 71. The benchmark evaluation team leader reported the error to the chairman of the technical evaluation panel. In a memorandum to him he noted that the error was neither a deficiency nor a matter requiring clarification. Protest File, Exhibit 137 at 26217. IRS chose not to act on the recommendation of the benchmark contractor. FCC was not advised of the error. Transcript at 566. The chairman of the technical evaluation panel has testified that FCC was not contacted because this would have been perceived as technical leveling or fine tuning of a benchmark. Id. 72. The technical evaluation report shows that of the total 95 points available for a perfect merit score on this procurement, thirty involved system performance as evidenced in the offeror's benchmark. Ten of the thirty points were for "Interactive Transaction Response Time"; ten were for "CPU Time"; and a final ten points were for "Elapsed Wall Clock Time." The ----------- FOOTNOTE BEGINS --------- [foot #] 9 The documentation cited here does not refer expressly to FCC, but rather to "violet," which was the coded name assigned to FCC during the procurement evaluation process. Transcript at 172. ----------- FOOTNOTE ENDS ----------- points obtained for wall clock time by FCC for its five proposals were: Primary and alternate #1: ; alternate #2: ; alternate #3: ; and alternate #4: . Protest File, Exhibit 154 at 27004. 73. Under the terms of the solicitation, an offeror received a full ten points for "Elapsed Wall Clock Time" if that time measured less than forty minutes. Protest File, Exhibit 18 at 1703; Transcript at 169. The elapsed wall clock time for FCC's five proposals ranged from 74. At hearing, the IRS benchmark team leader was asked if he could accurately predict that FCC could not have executed a wall clock time of less than 40 minutes if given the opportunity to rerun its unwitnessed benchmark after correction of the error detected in the results of its second unwitnessed benchmark. He replied: "I do not know that is impossible." Transcript at 177- 78. Later in his testimony, he elaborated on this statement. He stated that he did not personally believe that a correction and rerun of the benchmark should have changed FCC's wall clock time scores. He explained in some detail and with specific examples how, given the rounding out of FCC's prior scores, he did not believe that a rerun of the benchmark would succeed in pushing the prior wall clock time scores beyond the point to which they had already been rounded in the earlier run. Id. at 184-88. Nevertheless, he stated: "I decline to say that it's impossible because the benchmark is sufficiently complex that there may be something that I don't know." Id. at 181-82. Final Evaluation Results 75. The Technical Evaluation Report for the CSM/MIA procurement shows that out of a possible 95 points, ViON obtained a score of . Protester obtained the following scores on its primary and four alternate offers: Protest File, Exhibit 154 at 27004. 76. The final evaluated life cycle costs of the ViON and FCC proposals were as follows: ViON FCC FCC FCC FCC FCC Protest File, Exhibit 184 at 27829. Discussion Count I - Non-Compliance of ViON's Proposal with Mandatory Technical Requirements In its posthearing brief, FCC narrows its allegation of non-compliance to three solicitation provisions, namely: Clause C.2.6.1, which deals with IBM Code Compatibility; Clause H.14, which relates to the availability of equipment and software proposed and delivered; and Clause C.2.3.2, which requires conformity of equipment to UL standards. We discuss them in the order listed. Clause C.2.6.1 Central to this protest is the interpretation given by FCC to Clause C.2.6.1, the IBM compatibility provision of the RFP. For the convenience of the reader, we repeat the clause here. C.2.6.1 IBM CODE COMPATIBILITY a. The Contractor shall provide hardware, software, and firmware all of which are capable of supporting all of the functions and features of MVS/ESA System Product Version 4.2 and Data Facility Product (DFP) Version 3.3, except for support of the "dual copy" feature. 1. The Contractor shall provide full support for the "dual copy" feature of DFP Version 3.3 no later than the scheduled delivery of Hardware Upgrade 1 (see Section F.6.2 for schedules). b. The Contractor shall deliver and install hardware, software, and firmware all of which is fully code compatible with existing systems (operating systems, applications systems and program products) that are required to be connected (C.2.6.6) to CSM/MIA systems. An inventory of the current hardware may be found in Section J, Attachment VI. Software environments may be found in Section J, Attachments II and IV. Finding 12. FCC contends that this is a "technology differentiation specification." Protester's Posthearing Brief at 77. Protester writes: [In this clause,] IRS called out a specific version and release of operating system software to achieve the hardware, software, and firmware functionality of all of the features and functions of the specified version and release of the operating system software, and this equipment capability had to be out of beta or field testing by August 1, 1993. Id. at 77-78; see also Findings 14, 18, 23. Protester's interpretation of this clause is critical to the claim that ViON's proposal is non-compliant. By arguing that Clause C.2.6.1 requires an offeror to support fully all features and functions of the software mentioned, FCC is in a position to demonstrate non-compliance simply by showing that two special features -- DRM and PDS Search Assist -- are not currently supported by the equipment offered. In the final analysis, whether ViON's equipment does or does not support these or other features is immaterial to us since we reject FCC's interpretation of Clause C.2.6.1.[foot #] 10 The interpretation given by IRS to Clause C.2.6.1 is certainly a reasonable one. We find it very much in keeping with the context of the solicitation when read as a whole. The solicitation describes the scope of the CSM/MIA procurement as basically being a hardware buy. Finding 1. The section in which Clause C.2.6.1 appears relates to hardware. Finding 12. The title of the clause itself refers to IBM compatibility. Specific features and functions, to the extent they are required in this RFP, are called for elsewhere in Section C and the RFP's benchmark is intended to validate compliance of the proposed configuration with the requirements of Section C. Findings 26, 56. We find nothing in the history of Clause C.2.6.1 which would indicate that IRS ever intended it to be anything but a general compatibility provision which would serve to delineate the operating environment and market area to which the RFP was directed. Indeed, the record shows that IRS carefully avoided ----------- FOOTNOTE BEGINS --------- [foot #] 10 FCC does have one additional argument regarding DRM which arguably should be addressed even if protester's interpretation of C.2.6.1 is rejected. IBM is said to have announced MVS/ESA Version 4.2 on March 12, 1991. Because this version included the new feature of DRM, FCC argues that under Clause C.2.2, ViON was required to include DRM in its proposal by March 12, 1993. Protester's Posthearing Brief at 77. We find the argument without merit. Based upon the language of the clause itself and the origin of subsection C.2.2.d dealing with new features, we consider that the requirement for the "Contractor" to furnish new features and functions is applicable only to features and functions announced subsequent to award. See Finding 21; Transcript at 756. ___ ----------- FOOTNOTE ENDS ----------- suggestions made prior to the issuance of the solicitation and shortly after it was issued that this clause be modified to deal specifically with various required features and functions. See Findings 19-21. Admittedly, the clause was eventually amended to include reference to one specific function, namely, dual copy. Nevertheless, this was not the RFP provision relied upon by IRS to require this feature. As a specific feature, dual copy, from the start, was called for elsewhere in the solicitation. Finding 22. Furthermore, within Clause C.2.6.1, the requirement for this feature called for "full support" as opposed to the more general terminology of "capable of supporting" which was used with reference to all other features and functions of the software programs mentioned in the clause. We find this distinction a valid one and have no reason to believe it was not deliberately made by IRS in amending the clause. See Finding 25. In short, we find the agency's interpretation squares with the plain meaning of the clause and the other related provisions of the solicitation. See Finding 24. In addition, its interpretation is supported by the documentation describing the development of the clause from prior to issuance of the RFP to its amendments afterwards. Protester's interpretation, on the other hand, is not without serious problems. First, in arguing that specific features such as DRM and PDS Search Assist are requirements implicit in the language of the clause, FCC is urging a considerably more restrictive interpretation than that used by IRS and one which results in requirements which the IRS contends it does not even have. See Finding 17. Certainly the interpretation given to C.2.6.1 by IRS is a reasonable one. Furthermore, there is no indication that protester, prior to this time, ever formally challenged the wording of the clause. We have long held that when a vendor does not protest the meaning of a solicitation provision prior to the time established for submission of offers, it must be content with any reasonable interpretation the Government applies to that provision, as long as the agency's interpretation promotes rather than restricts full and open competition. E.g., Vion Corp. v. Department of the Army, GSBCA 12736-P, 1994 BPD 37 (Feb. 17, 1994); HFS Inc. v. National Archives, GSBCA 12010-P, 93-2 BCA 25,812, 1993 BPD 40. We consider this precedent clearly applicable to the facts in this case. Consequently, we reject the interpretation offered by protester. Both IRS and ViON contend that if consistently applied, FCC's contention that offerors were required to provide all features and functions of MVS/ESA 4.2 would ultimately lead to the elimination of some of FCC's own proposals. They note that some solutions proposed by FCC do not provide two gigabytes of central storage, a feature of MVS/ESA 4.2. See Findings 27-28. FCC's response is that the solicitation itself only required a minimum of one gigabyte of central storage. Protester's Posthearing Brief at 27. While we certainly do not accept FCC's interpretation of Clause C.2.6.1, we do agree with the response of FCC. In the event FCC's interpretation were to be acceptable, the RFP's minimum requirement for one gigabyte of central storage would clearly constitute an exception to the all-inclusive feature and function requirement which FCC believes is implicit in Clause C.2.6.1. We therefore are unpersuaded by the efforts of IRS and ViON to reduce protester's argument to the absurd. Nevertheless, we find it significant that FCC's proposal manager, in discussing this matter during his cross examination, did not hesitate to point out that the processor offered by FCC was "capable of supporting" the two-gigabyte feature even if it did not currently do so. We note that the meaning thus given by him to the phrase "capable of supporting" appears to be substantially the same as that given to it by IRS in interpreting similar language in C.2.6.1. Compare Finding 28 with Finding 25. In conclusion, for the reasons stated above, we reject FCC's contention that Clause C.2.6.1 requires offerors to propose equipment which fully supports all features and functions of the operating systems mentioned in that clause. We find the interpretation unduly restrictive and not in keeping with the overall context of the solicitation when read as a whole. Clause H.14 Availability For the convenience of the reader, we begin this part of our discussion with the text of the clause in question. Clause H.14, as amended, reads: H.14 AVAILABILITY The equipment and software proposed and delivered in response to this solicitation must have fully and successfully completed all beta and field testing and be capable of performing the requirements specified in Section C. This requirement must be met by August 1, 1993, and applies only to the major components of the initial Systems delivery (see Section C.2.6.8). This does not include minor components, connectors, cables, or other standardized mass-produced integral parts. Finding 3. Protester contends that the plain meaning of Clause H.14 is clear and is subject to only one reasonable interpretation. FCC asserts: All of the components and capabilities required by Section C for the CEC, DASS, and RCSS had to be out of beta or field testing by August 1, 1993. Protester's Posthearing Brief at 72. The protester, therefore, makes no distinction between the CEC, DASS, and RCSS and any of their subcomponents or subassemblies. Such a sweeping interpretation of the clause makes other requirements of Section C, such as ESCON conductivity, subject to the beta and field testing requirement of H.14. For this reason, protester contends that the ViON proposal fails to comply with the requirement of this clause as well. Arguably, there is support for protester's reading of Clause H.14 as it was originally issued. Following amendment of the clause in August 1993, however, and, in particular, the addition of a distinction between major and minor components, the situation changed radically. As amended, the clause no longer supports protester's view. This late modification of Clause H.14 represented a significant relaxation of the availability requirement. Clause H.14 refers vendors to Clause C.2.6.8 for identification of major components. That clause, however, provides little detail as to the nature of a "major component." These components are simply identified as the CEC, DASS, and RCSS. Finding 3. Just where the line of differentiation should be drawn between these major components and the minor components referred to in the revised H.14 is far from clear. Apparently IRS wanted the discretion to draw such a line itself, if necessary, to save the procurement from challenge. In reserving this discretion to itself, it chose not to reveal precisely where it would draw such a line. See Finding 4. Admittedly, Clause H.14, as amended in August 1993 and read in conjunction with Clause C.2.6.8, is far from a model of clarity. Coming as it did months after offerors had planned, benchmarked, and proposed their respective solutions, it is surprising that a protest was not filed if, as FCC now contends, the amendment put a vendor in an unfair competitive position. Protester now writes: [I]f FCC had known that the IRS was not going to enforce the plain meaning of Section H.14's beta testing and availability requirement, FCC would not have lost technical points, and would have lowered its cost significantly. Protester's Posthearing Brief at 106. Our difficulty with protester's complaints at this time regarding IRS's decision in August 1993 to relax the requirements of H.14 is that all vendors -- including FCC -- were put on notice of this decision at that time with the issuance of Amendment 17. The Government's course of action subsequent to that change has been consistent with it. If the Government chose to reserve to itself an extraordinary degree of discretion in the application of the requirements of Clause H.14 (as we believe it did with the issuance of this amendment), then the time for challenging that decision was when it was announced in August 1993, not now. FCC did not protest the amendment. Finding 11. Protester apparently concluded that, notwithstanding the late amendment, it could still reasonably compete under this change. It must now live with the consequences of that decision. DALFI, Inc., GSBCA 8975-P, 87-3 BCA 20,018, at 101,356, 1987 BPD 131, at 2. One remaining issue relating to Clause H.14 is FCC's contention that the RCSS offered by ViON, namely the Bosch 8800 ALT, did not complete beta and field testing prior to August 1, 1993. Certainly, under the terms of H.14, as amended, this is a major component to which the beta and field testing requirement of the RFP apply. The position of ViON, Bosch Storage Systems, and Grau Automation is that the Bosch 8800 ATL and the Grau ABBA/2 are identical and that, in view of prior testing done in Europe on the ABBA/2, none was required for U.S. produced systems. Finding 46. As already noted, based upon the record before us, we conclude that the systems are substantially the same. Findings 42-47. [foot #] 11 We, therefore, conclude that the IRS has acted reasonably in not holding the Bosch 8800 ATL subject to the beta and field testing requirement of H-24.[foot #] 12 Clause C.2.3.2 Protester contends that the RCSS offered by ViON does not comply with UL Standard 1950 as required under Clause C.2.3.2 of the RFP. The RCSS offered by ViON was the Bosch 8800 ATL. Finding 31. If protester is to prevail on this issue, its task is clear. It must prove that the Bosch ATL does not comply with UL Standard 1950. We would expect this showing to be made in terms of the standard itself. FCC has failed to do so. Instead, it has relied on evidence which is circumstantial at best. The evidence produced by FCC for the record in support of its allegation is sparse and unconvincing. ----------- FOOTNOTE BEGINS --------- [foot #] 11 [foot #] 12 ----------- FOOTNOTE ENDS ----------- We find the testimony of FCC's expert likewise unconvincing. In short, what we expected from FCC's expert or some other knowledgeable witness was an analysis of the Bosch 8800 ATL and UL Standard 1950 and an explanation of where this equipment fails to meet that standard. The issue here is not whether Bosch's ATL has been listed by UL. We agree with IRS and ViON that there is a clear distinction between a requirement for an item which complies with a UL Standard and an item which is UL listed. See Findings 50-52. We likewise agree that, with Clause C.2.3.2, we are dealing with the former. protester must, of necessity, go to the UL Standard itself and demonstrate noncompliance of the equipment with it. FCC's expert has failed to do this. He freely admits that he has not even examined or observed the Bosch 8800 ATL. Finding 39. FCC, although recognizing that ViON's supplier certified that the Bosch equipment was in compliance with UL Standard 1950, nevertheless attempts to make the most of its circumstantial evidence to prove its allegation that there is no basis in fact for this certification. Protester's Posthearing Brief at 88-90. Admittedly, this is a secondary issue -- the primary issue being, as already stated, whether the proposed RCSS actually complies with UL 1950. Nevertheless, weak as it is, it effectively rebuts protester's allegation that the certification was devoid of any basis in fact. FCC's allegation, therefore, fails for want of adequate proof. Consequently, we find that the contracting officer's continued reliance on the certification is reasonable. Counts II & III - Failure to Conduct Meaningful Discussions and Lack of Equal Treatment In its final brief, protester has combined the allegations set out in the second and third count of its complaint. It asserts: The IRS Misled FCC, Failed To Conduct Meaningful Discussions, And Failed To Treat All Offerors Equally And In Accordance With The Solicitation Requirements. Protester's Posthearing Brief at 101. The principal thrust of FCC's argument in support of this remaining allegation is that IRS allegedly relaxed solicitation requirements for ViON while simultaneously misleading FCC into strictly conforming to the solicitation requirements as stated. Id. at 102. Several examples of this alleged unfair and misleading conduct are offered in FCC's final brief. We have examined them in detail but find none to have any significant merit. FCC believes that IRS acted most unfairly in granting express and de facto waivers to ViON for the unwitnessed benchmark. IRS readily admits that the configuration used for the unwitnessed benchmark differed from the proposed configuration. IRS likewise admits to granting various express and de facto waivers to ViON for the unwitnessed benchmark. Findings 62-65. In objecting to the substitutions ViON was permitted to make, FCC relies heavily upon language in Clause L.18.1.8, which provides that an offeror shall perform the Government-observed benchmark on identical equipment as was used for the unwitnessed benchmark, i.e., that for which results were evaluated. See Finding 55. FCC likewise relies on a question and answer issued in December 1992 which confirmed that configuration substitutions were not permitted unless specifically granted by the benchmark instructions. See Finding 57. Finally, FCC contends that it was advised by IRS that offerors were expected to benchmark what they propose and propose what they benchmark. See Finding 59. Undoubtedly, until March 1993, IRS's policy on substitution in benchmarking was extremely rigid. The guidance issued in March 1993, however, represented a significant relaxation of the standard originally enunciated in the original RFP and in the confirmation of that standard in the question and answer released in December 1992. The parties are in disagreement over how the answer provided by IRS in March 1993 should be interpreted. For purposes of the discussion here, we quote both the question and answer: Q1. To avoid incurring unnecessary expenses, we wish to make some equipment substitutions in the hardware configuration for the initial benchmark. Will the Government permit us to conduct the initial benchmark test with certain items of equipment substituted for the devices actually proposed by us, provided that benchmark results are not affected in any way? A1. Yes, for Performance Validation Element One (the unwitnessed benchmark), such substitutions are permitted, provided that substitution has no impact on system performance. Finding 58. Under FCC's interpretation of the answer, substitution is not allowed if it has either a positive or negative effect on the benchmark results. Finding 60. Undoubtedly, this interpretation relies heavily on the terms "not affected in any way" which appear in the original question. Admittedly, the wording of the answer to the question could be clearer. Nevertheless, on balance, we find FCC's interpretation excessively rigid, restrictive of competition, and unrealistic. We note first of all that the language in the question "not affected in any way" does not appear in the Government's answer. Instead, the condition has been changed to read "provided that substitution has no impact on system performance." IRS contends that this condition should be read in a competitive context. The impact which the Government intended to exclude is that which would give an offeror an unfair or unjustified competitive advantage over other participants in the procurement. Finding 61. We find the interpretation of FCC to be unreasonable. The question itself suggests the possibility of something more than a merely nominal substitution. Reference is made to "equipment substitutions in the hardware configuration" to avoid incurring unnecessary expenses. During the hearing, one witness referred, in passing, to what is a recognized phenomenon in benchmarking, namely, that any two runnings of a benchmark seldom, if ever, produce identical results. Id. Recognizing this ourselves, we find it unrealistic to assume that, with the kind of substitutions described in the question posed, the results of a rerun would not change in some respect. Rather, the normal expectation would be that a change would occur. A question then arises. What substitution would be permitted, given that such changes occur? We agree that it is in this context that the Government's guidance -- only substitutions which produce no unfair impact on system performance will be permitted -- should be understood. The record shows that once ViON was selected as the apparent successful offeror and required to perform a witnessed benchmark of the equipment actually proposed, its performance was superior to that reported to IRS for the unwitnessed benchmark. Finding 66. Accordingly, we conclude that the substitutions permitted for the unwitnessed benchmark did not produce an unfair impact on system performance and, given the guidance issued by IRS in March 1993, the substitutions were permissible. Indeed, in opting for some substitution during the unwitnessed benchmark (which produced less favorable results), ViON put itself at some risk inasmuch as the technical evaluation of offers was based on the results of the unwitnessed and not the witnessed benchmark. Id. In its posthearing brief, protester refers with some frequency to a remark allegedly made to FCC employees by IRS representatives to the effect that one must benchmark what one proposes and propose what one benchmarks. See Finding 59. The implication is that this remark misled FCC as to the impossibility of benchmark substitution. For several reasons, we are not prepared to attach to this remark the weight which FCC does. First, we know very little about the piece of paper in the record which records this remark. It is simply said to be an excerpt from minutes of a meeting of FCC and IRS officials on August 11, 1993. Id. Second, if the remark was made, it was made over three months after FCC had submitted the results of its unwitnessed benchmark and even longer after FCC had decided on the configuration it would use for that benchmark.[foot #] 13 Made at that late date, the remark could scarcely have influenced FCC's decision as to what equipment it would use for the unwitnessed benchmark. Finally, the remark makes no distinction between benchmarks. Conceivably it may refer to the witnessed rather than the unwitnessed benchmark. At that juncture in the procurement, it was in fact correct that the offeror would be expected to benchmark what it proposed and propose what it benchmarked. As we have already noted, we believe the guidance was sufficiently clear from the context. We do not view FCC's loss of technical points on this issue as attributable to any misinformation on the part of IRS, but rather to FCC's apparent failure to recognize the significance of the guidance provided to offerors in March 1993. Another example of allegedly unfair treatment cited by FCC concerns the position taken by IRS regarding the manual mode feature of the BSS 8800 ALT offered by ViON for the RCSS. IRS has explained that this is a requirement of the RFP and ViON met it. However, IRS has not required that this feature meet the beta and field test requirement of Clause H.14 because it is not a major component. Protest File, Exhibit 604 at 29. FCC complains that the position taken by IRS relative to ViON's compliance with the manual mode requirement for the RCSS contrasts vividly with the position taken by IRS regarding the FCC claims that, even after the testing requirements of Clause H.14 were relaxed in August 1993, the contracting officer indicated that she was expecting ----------- FOOTNOTE BEGINS --------- [foot #] 13 Results of the unwitnessed benchmark were to be submitted by April 30, 1993. Finding 56. ----------- FOOTNOTE ENDS ----------- In addressing this grievance of FCC, we note at the outset that we have no problem with the position of IRS regarding the manual mode feature of the RCSS offered by ViON. The IRS position is based on an interpretation of Clause H.14 which we have already found to be acceptable. The treatment of ViON -- which is said to contrast with that accorded FCC -- was in keeping with the terms of the RFP and, therefore, proper. What of the treatment accorded FCC? Protester's version of the facts would have us accept that: (1) at the time it submitted its proposals, FCC clearly indicated to IRS (2) this fact was communicated again to IRS even after the introduction of the notion of major and minor components into Clause H.14; and (3) IRS failed to remind FCC after Amendment 17 issued See Findings 7-8. We view the relevant facts differently. The RFP expressly provides that the RCSS is a major component. Finding 3. FCC should, therefore, have been concerned with the beta and field testing requirement of Clause H.14 so far as the was concerned. Our understanding of the facts, therefore, is that We are not convinced, however, that this guidance descended to the specific level of which components required certification. Nevertheless, we do not believe that this, in and of itself, should have prompted the contracting officer or any other IRS official to question FCC concerning its understanding of Clause H.14. In short, we can not find in the facts presented to us any indication that FCC was treated unfairly in this regard. FCC also complains that it was treated unfairly in not being informed of the problem found by the benchmark contractor in the rerun of FCC's unwitnessed benchmark. IRS's failure to inform FCC is said to be particularly egregious in view of a recommendation made by the benchmark contractor that FCC be given the opportunity to correct the error and rerun the benchmark yet another time. Protester's Posthearing Brief at 104-05. See Findings 69-71. The chairman of the technical evaluation panel has justified IRS's failure to advise FCC of the problem with the second unwitnessed benchmark on the grounds that going back again to FCC and permitting yet another rerun would have amounted to technical leveling or benchmark tuning. Finding 71. We see no benefit in examining the correctness of this position or in examining related issues of whether the error in question actually constituted a deficiency or whether, if it was a deficiency, IRS was required to go back to FCC and permit it to correct the new mistake. The fact is that even if FCC had been given the opportunity to correct this error, there is no persuasive evidence that this would have changed the outcome. The error detected by the benchmark contractor in FCC's corrected unwitnessed benchmark affected only FCC's wall clock time. Finding 70. Testimony from the benchmark team leader supports the proposition that if FCC had been permitted to correct the error and rerun its benchmark, this would probably not have improved FCC's wall clock scores at all. Finding 74. Finally, even if FCC were to receive perfect wall clock scores for all five of its proposals, this adjustment would not bring any of them to the level of ViON's technical score. Findings 72- 73, 75. We therefore put this complaint of FCC aside. If, in fact, IRS was required to advise FCC of the defect in the rerun of the unwitnessed benchmark, this was harmless error and did not, in the final analysis, prejudice protester. See Andersen Consulting, GSBCA 10833-P, 91-1 BCA 23,474, at 117,759-60, 1990 BPD 396, at 22-24, aff'd, 959 F.2d 929 (Fed. Cir. 1992). Comments on the Dissent Although we believe that the concerns raised by the dissent have been addressed in the body of our decision, we nonetheless make the following observations. Our interpretation of Clause C.2.6.1 is, as we have noted, based upon a reading of the solicitation and resulting contract as a whole. It is well established that "[a] contract should be interpreted in such a way that all parts make sense." Hughes Communications Galaxy, Inc. v. United States, 998 F.2d 953, 958 (Fed. Cir. 1993); Intel Corp. v. International Trade Comm'n, 946 F.2d 821, 826 (Fed. Cir. 1991) ("When interpreting a contract, we must, where possible, give meaning and purpose to every term used in the contract."); United States v. Johnson Controls, Inc., 713 F.2d 1541 (Fed. Cir. 1983) ("[A]n interpretation that gives a reasonable meaning to all parts of the contract will be preferred to one that leaves portions of the contract meaningless . . . .") The interpretation urged on us by protester and favored by the dissent runs contrary to this well established principle. Protester would read the clause as requiring offerors to support fully and immediately all features and functions of the specified software. Our difficulty with this interpretation is that it renders superfluous provisions elsewhere in Section C which specifically call for some but not all of those specific features and functions. See Finding 26. We do not view Clause C.2.6.1 as ambiguous when read in the context of the solicitation/contract taken as a whole. Protester's interpretation, however, does give rise to an ambiguity -- to the extent that it places in question the purpose of other provisions in the same Section C which call for some but not all of the features and functions. Indeed, we consider this resulting ambiguity to be far from latent. It should, therefore, have prompted protester to challenge Clause C.2.6.1 or request a clarification prior to the submission of proposals. In the absence of such a challenge, "the agency has the discretion to choose its own interpretation of the disputed language and that interpretation is binding unless it is unreasonable or otherwise constitutes an abuse of discretion." Grumman Data Systems Corp. v. Widnall, 15 F.3d 1044, 1047 (Fed. Cir. 1994). The dissent observes that we have failed to set out the original version of Clause H.14. The clause, as originally issued, read as follows: H.14 AVAILABILITY The equipment and software proposed in response to this solicitation must have completed all beta and field testing, have entered into production for commercial distribution and sale, and be capable of performing the requirements specified in Section C, by one hundred and eighty (180) calendar days after proposal due date (as shown in Section A, Standard Form 33, Item 5, or as subsequently modified). Protest File, Exhibit 12 at H-17. For purposes of comparison, we restate the clause here as finally amended: H.14 AVAILABILITY The equipment and software proposed and delivered in response to this solicitation must have fully and successfully completed all beta and field testing and be capable of performing the requirements specified in Section C. This requirement must be met by August 1, 1993, and applies only to the major components of the Initial Systems delivery (see Section C.2.6.8). This does not include minor components, connectors, cables, or other standardized mass-produced integral parts. Finding 3. We remain convinced that the changes made in this clause over the course of the procurement represent a significant relaxation of the original requirement and cannot be ignored. Decision This protest is DENIED. The Board's order of February 17, 1994, suspending respondent's delegation of procurement authority expires in accordance with its terms. _______________________ EDWIN B. NEILL Board Judge I concur: _______________________ ANTHONY S. BORWICK Board Judge DEVINE, Board Judge, dissenting. I dissent from the majority opinion because I find its reasoning either wrong or non-existent on two of the major grounds upon which it finds against protester. The first is the IBM compatibility clause which is designated C.2.6.1. This clause requires that all hardware, software, and firmware supplied under this procurement be "capable of supporting all of the functions and features" of two specific, named, sets of software, except for a feature called "dual copy." This equipment and software had to be field tested and ready to go by August l, 1993. "Full support" for the dual copy feature, on the other hand, did not have to be supplied until a later date under the terms of an amendment to the basic clause. The clause also requires that the "hardware, software, and firmware" be "fully code compatible" with existing IBM systems. Protester interprets this clause to mean what it says: all the features and functions of the specified operating systems software, and the hardware that the systems controlled, had to have been operative and field tested by August l, l993. Protester next says that ViON's offer does not comply with the RFP because at least two special features, designated "DRM" and "PDS Search Assist," are not supported by ViON's equipment. The majority, in the teeth of the plain language of the clause, brushes this off as a simple misinterpretation, and thus fails to address the issue of whether ViON's equipment does or does not support these two special features, as the clause requires. In taking this position the majority first notes that the clause in question relates to hardware, implying, I suppose that any mention of software is somehow to be discounted. However, software is mentioned at least as plainly as hardware. Next the majority tells us that the title of the clause itself refers to IBM compatibility, and again seems to be implying that anything not to do with compatibility should be ignored. Next the majority gives us a further reason to ignore any mention in the clause of specific features and functions: they are called for in another section of the RFP, and besides the IRS intended the clause to be merely a general compatibility provision "which would serve to delineate the operating environment and market area to which the RFP was directed," whatever that means. Of course it really doesn't matter what the IRS intended to write into the clause. What it actually says is what counts. The original version of the clause did not contain the exception for the "dual copy" feature found in the final version. The fact that this clause, which the majority says is basically general in nature, was amended to exclude a very specific function, gives the majority trouble, since the fact of the amendment supports protester's interpretation that it deals not with generalities but with specifics. The majority, however, explains the whole thing away by finding a distinction between the IRS's use of the phrase "full support" in the amendment and its earlier use of the phrase "capable of supporting" in the body of the original clause. Apparently the majority finds the former specific and the latter general. I simply find no rational basis for this distinction. Next, still looking for solid ground, the majority finds protester's interpretation of the clause more restrictive of competition than IRS's interpretation, and therefore not to be preferred. And finally, somewhat astonishingly, the majority says that if protester wants to protest "the meaning of a solicitation provision" it must do so prior to the time for submitting offers. If it doesn't, then it is stuck with the Government's interpretation, so long as it is reasonable. This idea seems to be an aberrant outgrowth of the old rule that he who drafts a clause will have its uncertainties construed against him, only in our case it's construed against the non-drafter. If this is, in fact, the law, (and it may be, there are GSBCA decisions that so state) then protester is charged with the impossible task of predicting, for every significant clause in the RFP, how the IRS will interpret it. Protester must then figure out whether it agrees with what it thinks will be the IRS's interpretation and if it doesn't, file a protest before offers are due. Beyond the obvious fact that clairvoyance is required, there is the further fact that there is no trigger, no warning bell to cause the offeror to even look into its crystal ball. There is never a reason, in advance of a dispute over it, for an offeror to protest the meaning of an RFP provision. As far as the offeror knows, each provision means what it says. Therefore to say that an offeror must protest the meaning of a clause before bid closing time is to say nothing. No offeror will ever do so, unless there is an existing dispute as to meaning. Therefore: Where an offeror knows before bid closing that the Government attributes a different meaning to a particular clause than offeror does, then it must file a protest before bid closing to preserve its arguing rights. The converse, however, is also true. Where it doesn't know the parties differ on meaning, it doesn't have to protest prior to bid closing. In any event, once the protest is filed, if protester's interpretation is correct and the Government's isn't, which is the case here, protester wins. Clause H.l4 Once again protester and the IRS are at odds over the meaning of a clause, and once again protester's position is that it means what it says. And once again the plain language of the clause supports protester's position that all of the specified components had to have been field tested by August l, l993. The majority is willing to concede some validity to protester's position with respect to the clause as originally written. At that time it made no distinction between major and minor components. The majority does not set out the text of the original. The final version required that all major components be field tested and ready to operate by August l, l993. It contained the language: "This does not include minor components, connectors, cables, or other standardized mass-produced integral parts." This is apparently the language of the amendment that installed the majority firmly on the side of the IRS. Following the addition of this language, according to the majority, "the situation changed radically. As amended, the clause no longer supports protester's view." The majority never explains why the change had this effect. Protester's view, of course, was that all the major components and their subassemblies that were not "connectors, cables or other standardized mass-produced integral parts" had to be tested, up, and running by August l, l993. This was important to protester lowered its technical score and increased its costs. Protester thus found itself unfairly treated because other offerors were not held to so strict a standard. I would grant this protest, at least in part. _______________________ DONALD W. DEVINE Board Judge