Matter of: Sprint Communications Corporation, L.P. File: B-271035; B-271035.2 Date: June 10, 1996 * Redacted Decision

Matter of: Sprint Communications Corporation, L.P. File: B-271035; B-271035.2 Date: June 10, 1996 * Redacted Decision

Protest challenging agency's refusal to grant request for change to benchmark script (to allow protester to defer until after award demonstration of its ability to switch data display from full screen to teletype format without leaving the application) is denied since waiver of the type protester requests would be inconsistent with the purpose of the benchmark--to require offerors to demonstrate, before award, their capability to meet mandatory solicitation requirements. Protest that requirement for offeror to demonstrate dual mode emulation during benchmark is unduly restrictive of competition because agency has no valid requirement for dual mode emulation is untimely where the requirement was stated in the solicitation but protest was not filed until well after time set for receipt of initial proposals. Protest that agency improperly waived for one offeror a mandatory solicitation requirement--for use of a commercial operating system--is denied where record shows that the offeror's proposed operating system is available commercially.

Attorneys

DECISION

Sprint Communications Company, L.P. protests the agency's actions under request for proposals (RFP) No. DACW31-94-R-0145, issued by the U.S. Army Corps of Engineers for information processing services. Sprint contends that the Army improperly and unreasonably rejected its request for modification of a benchmark test. Sprint also alleges that the agency improperly waived a mandatory solicitation requirement for another offeror, [REDACTED].

We deny the protests.

BACKGROUND

On November 1, 1994, the agency issued the RFP for software, hardware, and telecommunications to support the agency's Programming, Administration and Execution (PAX) system for a base year, with four 1-year options. Through various program management applications sponsored by the agency, the PAX system provides international teleprocessing support for the Army's military construction program, as well as service to a variety of military and civilian agencies. [1]

The solicitation provided for evaluation of proposals in three stages. Stage I, which is now complete, involved evaluation of proposals by a technical evaluation committee to determine whether they met the mandatory requirements of the statement of work (SOW). Offerors whose proposals were found to comply with the SOW requirements then must perform a benchmark demonstration, stage II of the evaluation, the terms of which are at issue in this protest. In stage III, offerors who pass the benchmark will submit price proposals. Selection of a contractor, presuming that offerors meet mandatory criteria and pass the benchmark, will be based on price and technical factors, including soundness of approach, the results of a user survey, and the offeror's FTS2000 Network Design.

Paragraphs C.3 and M.2.1 of the RFP provide that an offeror must satisfy all requirements of the SOW to be technically acceptable. Paragraph 6.2.1 of the SOW requires the contractor to convert the four major PAX applications, which have been written in a modified version of the International Business Machines Corporation's (IBM) VM/ESA operating system known as VMTI/ESA. [2] The Army made available to offerors, in a reading room, a document describing the incumbent's functional modifications to the operating system, including a feature known as dual mode emulation. [3] This feature allows a user to switch back and forth between teletype (display of one line at a time) mode and full screen mode without leaving an application.

Amendment No. 0001 to the RFP, dated November 4, 1994, advised offerors that the benchmark package would be made available on November 8; however, the agency had begun to suspect certain problems with the benchmark package. Specifically, it appeared that [REDACTED] meeting the mandatory requirement for dual-mode emulation through "calls" to proprietary codes. A "call" is software code resident in a program that allows (or causes) the program to branch outside to another program and execute code located in that program. In pertinent part, it appeared that, in switching between the two modes of display, PAX applications were branching out to [REDACTED] proprietary code located in the mainframe supporting the PAX system. This created a problem in that other offerors would be unable to run the benchmark as initially issued--specifically, the demonstration of dual-mode capability--if the function required the system to have access to a proprietary code. [4]

While agency personnel confirmed [REDACTED] use of a proprietary code to perform the dual mode emulation, the Army also was issuing several amendments to the solicitation, which required extensions of the due date for initial proposals. On March 6, 1995, the agency provided offerors with a revised benchmark package that eliminated the calls to [REDACTED] proprietary code. In response to several questions submitted by offerors, the agency specifically advised competitors that [REDACTED] modified the operating system to meet some of the mandatory requirements, and that, since the government did not own rights to these modifications, other offerors would have to create their own proprietary software to meet certain requirements. The VMTI/ESA Features Supplement described dual mode emulation and identified it as a key function requiring some modification to the operating system, although the supplement provided no details on [REDACTED] proprietary code used to accomplish the function.

The Army subsequently extended the time for submission of initial proposals to April 12, 1995, and the time for submission of any requests for changes to the benchmark to April 28. The agency received proposals from the protester and [REDACTED]. None of the offerors, except [REDACTED], submitted requests for benchmark changes. [REDACTED]

On May 17, and again on August 11, the agency provided offerors with further opportunities to request changes to the benchmark. On August 14, Sprint submitted a letter requesting changes to the benchmark, none of them relevant to the issues in this protest. Further, in correspondence dated September 1, Sprint advised the agency that, [REDACTED].

On October 11, the agency conducted a conference with representatives of Sprint by telephone. The agency hoped to schedule the benchmarks immediately upon completing the technical evaluation, and was unwilling to allow further delay. For this reason, the agency advised Sprint that its September 1 letter [REDACTED]. The agency took the opportunity to raise additional concerns--specifically, [REDACTED] which had arisen as a problem with other proposals. Sprint then raised the question of [REDACTED]. The agency advised Sprint, as it had stated in response to prior inquiries, [REDACTED]. [5]

The agency extended the deadline for requesting benchmark changes to November 3. In the interim, one offeror withdrew because of problems associated with rewriting the code to allow dual mode emulation. In a letter dated October 30, the agency specifically asked Sprint whether it understood its responsibility for developing the code necessary to perform the dual mode emulation during the benchmark. Sprint responded the next day that it understood and was prepared to satisfy the requirement for demonstrating both modes, teletype and full screen, without logging off.

By letter of November 3, the agency accepted all but one of Sprint's requests for benchmark changes. [6] Although the deadline for submission of change requests had again passed, Sprint continued to submit, and the agency to consider, other requests for changes to the benchmark script. [REDACTED]

On November 17, Sprint acknowledged the need to develop software to interface with the PAX applications and operating system. The protester asked the agency to delay the benchmark test until February 1995, in order to allow Sprint to complete the development effort. The agency was unwilling to commit itself to such a delay, although it continued to accept and consider Sprint's requests for changes to the benchmark script.

The specific issues arising from this protest came to a head with Sprint's December 18 request for four additional script changes. Sprint requested that the requirement for a dot prompt during full screen emulation be eliminated. [7] (The dot prompt is indicative of teletype mode.) Sprint also asked to perform all benchmark edit sessions utilizing full screen mode. The thrust of these changes would be to allow Sprint to run the entire benchmark in full screen mode, waiving the requirement for dual mode emulation during the benchmark. Sprint also asked that it be allowed to ignore an error message--"INVALID DEVICE TYPE"--during the benchmark but failed to provide any information on the context in which the error message appeared. [8]

By letter dated January 2, 1996, the agency denied Sprint's December 18 request. The requests for omission of the dot prompt and for performance of edit sessions in full screen mode were denied because they were inconsistent with the requirement to demonstrate dual mode emulation. Sprint's other request was denied because, absent additional information, the agency could not tell how frequently or under what circumstances the error messages might appear. On January 16, Sprint filed a protest with the agency over the rejection of its requests for changes to the script. The agency denied this protest on January 24, and this protest to our Office followed.

DISCUSSION

Sprint contends that, while it ultimately can meet the solicitation requirement for dual mode emulation, the Army's insistence that it demonstrate dual mode capability during the benchmark is unreasonable.

The record shows that while full screen mode has obvious advantages, teletype mode is faster over a modem and generally more economical than full screen mode. Separate pricing of the two modes had resulted in appreciable savings during the past contracts, and the agency wanted the continued capability for operators to switch to teletype mode when feasible to take advantage of its generally lower price. The requirement has been in the solicitation since its issuance, and indeed appeared in a draft solicitation distributed for comment before that. As discussed above, the record demonstrates that Sprint never objected to the requirement prior to its December 1995 request for a change to the benchmark, and on several occasions acknowledged the requirement and assured the Army of its ability to provide the dual mode feature.

Paragraph C.8.3 of the RFP identifies three purposes of the benchmark. As the agency notes, the benchmark generates cost information to establish the basis of pricing proposals and to allow the agency to monitor the selected vendor's performance and price procedures during performance. That paragraph also states that the benchmark serves to demonstrate whether the vendor can accomplish mandatory requirements of the RFP. Failure to perform tasks during the benchmark is cause for rejection of the proposal as technically unacceptable. The RFP, to the extent it allows an offeror to seek changes to the benchmark, states that such changes are restricted to "job control instructions and any related machine-dependent changes to the software" if essential to make them perform on the vendor's system.

Consistent with these provisions of the RFP, the agency asserts that the purpose of the benchmark is to test the potential offeror's configuration to ensure that it will support the PAX production environment. The benchmark also serves, the agency states, as a pre-award demonstration of the offeror's anticipated technical competence in converting technical code during contract performance. In addition, the benchmark measures resource consumption for each offeror's proposed configuration, for use in evaluating the price proposal. Changes to the benchmark are for the purpose of accommodating the offeror's configuration, the agency argues, not for the purpose of deferring the offeror's responsibility of demonstrating its ability to meet solicitation requirements until after award.

As discussed above, the subject of Sprint's requested waiver of the benchmark test--dual mode emulation capability--is a mandatory requirement of the RFP. Clearly it would be inconsistent with the purpose of the benchmark test--to require offerors, before award, to demonstrate their capability to meet the RFP's requirements--to waive the requirement for demonstration of dual mode capability during the benchmark. We therefore have no basis for finding the agency's refusal to grant Sprint's request to be unreasonable.

Sprint raises several other issues relating to the dual mode capability requirement, the essence of which is to challenge the agency's need for this function. Specifically, Sprint argues that there is no reason to measure or compare its resource consumption during the benchmark because it might not price teletype and full screen modes separately; thus, the protester argues, the agency has no actual need for the dual mode emulation, given that offerors might be willing to provide full screen and teletype mode at the same price. Sprint also asserts that the agency can have little use for teletype mode; if some installations continue to use equipment incapable of displaying full screen, they could not take advantage of the capability of switching to full screen. Finally, Sprint challenges the agency's statement that it has no right to the proprietary software [REDACTED] to perform the dual mode emulation function. Sprint contends that the agency should obtain the software [REDACTED] and provide it to Sprint and other offerors, to allow them to meet the requirement without having to develop their own code. We conclude that these contentions constitute untimely challenges to the terms of the RFP.

Our Bid Protest Regulations, 4 C.F.R. Sec. 21.2(a)(1) (1996), require protests based upon alleged improprieties in a solicitation to be filed prior to the time set for receipt of initial proposals. Here, the agency points out that the requirement for dual mode emulation has been in the RFP since the Army issued it in November 1994. In addition, amendment No. 0005, issued on March 3, 1995, specifically advised offerors that the agency did not have and would not provide the codes necessary to perform all the functions of the operating system [REDACTED]. Given that the RFP established the dual mode emulation requirement and advised that the agency would not provide the necessary codes, Sprint should have raised its objections to the requirement before the time set for receipt of initial proposals on April 12, 1995. Since Sprint's agency-level protest was not filed until January 16, 1996, that protest and Sprint's subsequent protest to our Office are untimely. . [10]

Regarding the request that the agency ignore the error message "INVALID DEVICE TYPE" during the benchmark, the agency points out that in the absence of any information from Sprint regarding the frequency and location of occurrence, it could not grant the request for waiver. In general, the presence of an error message presents an unacceptable risk, in the agency's opinion, since it could lead to confusion between intended and unintended error messages indicating actual malfunctions of the offeror's configuration or computer code. If passed through to users, particularly less sophisticated ones, it would generate confusion and thus unnecessary processing and terminal input/output costs. Sprint provides no clarification of the issue in its protest, and we have no basis to find that the agency unreasonably denied Sprint's request.

Upon receiving the agency report filed in response to its initial protest, Sprint filed a second protest, asserting that the Army improperly waived mandatory requirements of the RFP [REDACTED]. Specifically, the protester cites paragraph C.4.4 of the solicitation, which requires each offeror to warrant that its operating system is the most recent release commercially available for the last 6 months. Sprint contends that the agency should not have found [REDACTED] proposal technically acceptable because it is offering [REDACTED], a proprietary operating system that is not commercially available.

The arguments of the Army and the intervenor address the issue of whether [REDACTED] may be considered to have proposed [REDACTED] as the operating system, or whether the operating system is really VM/ESA with modification. [10] Sprint argues extensively that [REDACTED] is an operating system separate and distinct from VM/ESA. What Sprint does not do is address the assertions of the agency and [REDACTED] that even if one views [REDACTED] as an operating system in itself, [REDACTED] is licensed, as VM/ESA is, to a variety of commercial customers, and therefore meets the RFP requirement of being commercially available. Thus, even if we accept Sprint's argument that the operating system is not VM/ESA but [REDACTED], the record supports the agency's conclusion that [REDACTED] is offering a commercially available operating system. The agency therefore properly found that [REDACTED] proposal was technically acceptable and met the mandatory requirements of the RFP.

The protests are denied.

Comptroller General of the United States

1. The chief applications supported include the following: the Accounting and Control System, which acts as the systems manager, directing users to the appropriate application and tracking costs of the overall PAX system; the Army Tracking System, used for facilities planning at major army installations; the Army Defense Energy Information System Data System, which collects energy consumption data for Army installations, as well as the Reserves and National Guard; the Construction Appropriations, Programming, Control and Execution system, which tracks individual construction projects throughout the Army; and the DD Form 1391 Processor System, which provides estimates and justifications for Army construction projects.

2. The record shows that since award of the initial contract in 1982, there have been periodic upgrades and improvements to the system. The original contractor, TYMSHARE, Inc., was purchased by McDonnell Douglas Corporation, which later sold the unit [REDACTED]. It was McDonnell Douglas that, in 1988, installed the system on the mainframe using IBM's VM/ESA operating system and that created the proprietary software [REDACTED], to interface between the standard operating system and PAX users and installations.

3. Initially, the agency referred to this document as the Cumulative Functional Modification. The Army later changed the title to the VMTI/ESA Features Supplement.

4. The benchmark created "calls" to the proprietary code, without providing the code itself.

5. Specifically, amendment No. 0005 to the solicitation, dated March 3, contained a list of 230 questions asked by vendors and the agency responses. In response to question No. 165, as noted above, the agency had advised offerors [REDACTED] that a generic description of the modifications was available in a reading room previously made available to offerors. Question No. 168 specifically asked the agency to make available the code for modifications; the Army's response specifically stated that the government did not own the modifications and that offerors would have to develop their own code.

6. The agency rejected Sprint's log-on procedure, which is not relevant to this protest.

7. As the agency notes, the use of a dot, rather than some other prompt, is not significant. It is the use of a prompt that is critical when running applications in teletype mode. Without a prompt of some kind, PAX users could become confused as to the beginning and end of data, input or output routines, database modification routines or other procedures.

8. Sprint also requested permission to clear the display screen with a keystroke when the message "...MORE" was received. The agency rejected this request because Sprint had provided no details. Although Sprint included this issue in its protest to the agency, it withdrew the request prior to the Army's decision on that protest.

9. To the extent that Sprint suggests that the requirement was not clear from the face of the RFP, the protest nevertheless is untimely. The record clearly demonstrates that the agency raised the dual mode emulation issue with Sprint on numerous occasions prior to the agency-level protest. For example, the agency raised it during the October 11, 1995 teleconference, and Sprint specifically acknowledged and took no objection to the requirement in its letter of October 31. Thus, the record shows that even if the requirement were not clear from the face of the RFP, Sprint could and should have raised the issue well before the filing of its agency-level protest on January 16, 1996. See 4 C.F.R. Sec. 21.2(a)(2) (protests must be filed within 14 days of when the basis of protest is or should have been known).

10. The agency also asserts that the protest is untimely. Sprint asserts that until it viewed the agency report, it had no way of knowing that [REDACTED] or that the agency had found the proposal technically acceptable. We note that Sprint's initial protest specifically argued that the requirement was unduly restrictive of competition because there was no commercial software capable of emulating [REDACTED] operating system. Since, as noted below, Sprint does not deny that [REDACTED] itself is commercially available, we need not address the timeliness issue.

DOCUMENT FOR PUBLIC RELEASE A protected decision was issued on the date below and was subject to a GAO Protective Order. This version has been redacted or approved by the parties involved for public release.