Matter of: TRW Inc.; Systems Research and Applications Corporation File: B-260968.2; B-260968.3; B-260968.4; B-260968.5 Date: August 14, 1995

Matter of: TRW Inc.; Systems Research and Applications Corporation File: B-260968.2; B-260968.3; B-260968.4; B-260968.5 Date: August 14, 1995

Protesters' contention that agency improperly evaluated proposals is denied where the record shows that the agency evaluated in accordance with the criteria announced in the solicitation, and the record reasonably supports the evaluators' conclusions. Agency was not required to raise during discussions weaknesses identified in the protester's proposal for a global transportation network related to known problems with prototype software the agency made available to all offerors where offerors were not required to use the prototype software; the agency explicitly informed prospective sources that the prototype software did not provide an optimal solution; the technical reference library established for the procurement contained incident reports and other critical information detailing problems with the prototype software, thus placing the offerors on notice of the problems with the prototype software; and the weaknesses identified in the protester's proposal in this regard did not render the proposal unacceptable. Agency conducted meaningful discussions where the record shows that the agency held written and oral discussions based on items consistent with the weaknesses and deficiencies identified in the protesters' proposals, and those items sufficiently alerted the protesters to specific areas of their proposals considered weak or deficient and requiring further explanation. Agencies are not required to identify during discussions every aspect of an offeror's proposal that receives less than the maximum technical ratings. Allegation that agency improperly adjusted protesters' proposed costs is denied where, based on the results of a life cycle cost/benefit analysis of the global transportation network system contemplated under the solicitation, the agency calculated cost savings to the government resulting from early delivery of capabilities under the solicitation, and the record reasonably supports the agency's upward adjustment of the protesters' proposed costs based upon: (1) additional costs to the government resulting from estimated later delivery of capabilities; (2) additional effort not provided for in the proposal; and (3) agency's conclusion that, given its approach, protesters could not reasonably be expected to provide required effort at proposed cost. Allegation that agency improperly determined that software proposed under solicitation for a global transportation network (GTN) is nondevelopmental is denied where the agency reasonably determined that software is commercially available, and that planned future modifications or enhancements to the software would not require major developments unique to the GTN requirements. Award to offeror submitting a higher-rated, slightly higher-cost, low risk proposal is unobjectionable where the evaluation scheme announced in the solicitation gave more weight to the technical area than to cost, and the agency reasonably found that awardee's technical superiority and low risk outweighed the lower costs of the protesters' higher risk proposals.

Attorneys

DECISION

TRW Inc. and Systems Research and Applications Corporation (SRA) protest the award of a contract to Unisys Corporation under request for proposals (RFP) No. F19628-94-R-0021, issued by the Department of the Air Force for a global transportation network (GTN) system. The protesters' contentions may be summarized as follows: the Air Force improperly evaluated the competing proposals; failed to conduct meaningful discussions; performed a flawed cost realism analysis; and made an unreasonable cost/technical tradeoff decision.

We deny the protests.

BACKGROUND

The acquisition is to obtain an automated command and control system to support the Global Transportation Management mission of the United States Transportation Command (TRANSCOM). [1] The objective of the GTN acquisition at issue here is to develop, implement, test, install, and maintain a command and control information system to facilitate TRANSCOM's evolving mission of global transportation management. TRANSCOM's mission will evolve over the next few years as more effective methods are developed to meet DOD's transportation requirements during peacetime and during military conflicts. The GTN system contemplated by the RFP will handle over 2 million transactions daily, collecting and consolidating data on the status and location of military cargo, passengers, medical patients, air refueling, and lift assets.

The RFP, issued May 5, 1994, contemplated the award of a cost-plus-award fee contract with certain fixed price contract line item numbers (CLIN). The RFP sought proposals for a 5-year base period (the developmental phase), with up to two 1-year option periods (system maintenance). Offerors were required to propose delivery of these hardware and software [2] components in a minimum of five evolutionary increments, with each delivery resulting in increased capabilities for the GTN. [3] The RFP emphasized that the acquisition is a developmental effort and that the Air Force had no preference for a particular solution.

Section M of the RFP stated that proposals would be evaluated in the following areas, listed in descending order of importance: technical, management, and cost/price. The RFP stated that within the technical and management areas, proposals would be evaluated in three ways: a color/ adjectival rating; a proposal risk rating; and a performance risk rating. [4] The color/adjectival ratings were to reflect whether the offeror's proposal met the technical evaluation standards and solicitation requirements; proposal risk assessed the risks associated with the proposed approach, considering both the written proposal and the results of a GTN demonstration; and performance risk assessed each offeror's relevant present and past performance history.

Within the technical area, the RFP listed the following evaluation factors: (1) requirements satisfaction and evolution; (2) system design and architecture characteristics; (3) system and technology integration process; (4) system level engineering process; (5) scheduled delivery of capabilities; (6) use of nondevelopmental items (NDI); and (7) software development process. [5] Within the management area, the RFP identified the following evaluation factors: (1) software capability evaluation; (2) management visibility and control; (3) organization structure and staffing; and (4) integrated logistics support. [6]

The RFP also called for a demonstration to assess the offeror's GTN solution (e.g., existing capabilities, commercial products, design, developed software, and system architecture). The RFP stated that the results of the GTN demonstration would be considered in evaluating each of the seven factors within the technical area. The cost/price area was to be evaluated separately based upon a most probable cost developed for each offeror and a cost realism assessment. The RFP provided for award to the offeror whose proposal conformed to the solicitation requirements and, based on an integrated assessment of the evaluation factors announced in the RFP, was considered to be the most advantageous to the government.

Five firms submitted proposals in response to the RFP. A source selection evaluation board (SSEB) evaluated initial proposals, and based on those results, all five proposals were included within the competitive range. The agency conducted both written and oral discussions with these five offerors and requested best and final offers (BAFO) from all five. The SSEB reevaluated proposals based on BAFOs, with the following overall final results, including evaluated cost, for the protesters and the awardee:

Color/Proposal Risk Total Costs

Offeror Technical Management (in millions)

Unisys Blue/Low Green/Low $55.2 TRW Green/Moderate Green/Low 54.9 SRA Green/High Green-Yellow/ 56.8 High

Based on these results, the source selection authority (SSA) concluded that the Unisys proposal offered the best value to the government. On March 23, 1995, the agency awarded the contract to Unisys, and on that date, informed TRW and SRA of the award decision. These protests followed. [7]

TECHNICAL EVALUATION

SRA argues that the SSEB improperly downgraded its proposal for having a high schedule risk due to its lack of an "automated interface builder". According to SRA, this assessment was unreasonable because SRA proposed two automated interface building tools for external interfaces. SRA also argues that the SSEB improperly downgraded its proposal for weaknesses related to its screen builder program. In addition, both TRW and SRA challenge the agency's conclusion that the software Unisys proposed was an NDI.

In reviewing a protest challenging an agency's technical evaluation, we examine the record to ensure that the agency's evaluation was reasonable and consistent with the stated evaluation criteria. See Abt Assocs., Inc., B-237060.2, Feb. 26, 1990, 90-1 CPD Para. 223. Based on our review of the record here, we find no basis to question the agency's evaluation of proposals.

Evaluation of SRA's Proposal

SRA proposed two tools to process external interfaces, however, they were not considered "automated" by the SSEB because they did not provide all of the interface functions of the GTN system specifications. [8] The evaluators assessed the capability of the tools during SRA's GTN demonstration, and concluded that, although the tools SRA proposed provided adequate support in some respects, they would require significant manual development effort. The agency explains, for example, that the software developers would be required to determine which aspects of the software were automatically generated (i.e. determine structure, elements, looping conventions, etc.), then determine where to insert manually- generated code. The SSEB concluded that the manual effort involved was significant and time-consuming and would adversely affect SRA's aggressive schedule for delivery of initial and final operational capability.

SRA contends that the RFP did not require a fully automated interface builder. The protester also argues that, in any event, the system it offered is substantially automated.

Although it is apparent that SRA and the agency have differing views of what constitutes an "automated" interface builder, it is also apparent that the tools SRA proposed require manual development of some lines of codes to produce a fully operational system. The record shows that the SSEB did not simply downgrade SRA's proposal for lack of an automated interface builder. Rather, based on its extensive review of the system proposed, the SSEB concluded that SRA's tools were not as automated as described in the proposal, and that along with other features of its proposed architecture, the degree of automation in SRA's tools would jeopardize SRA's aggressive delivery schedule. Given the SSEB's conclusion regarding the amount of additional manual effort that SRA would be required to dedicate to the proposed tools--a conclusion that SRA has not shown to be unreasonable--the SSEB reasonably concluded that SRA's delivery schedule could be jeopardized, and assigned SRA's proposal a risk rating of "high" under the "scheduled delivery of capabilities" evaluation factor. [9] We have no basis to question the SSEB's evaluation of SRA's proposal in this area. [10]

SRA's proposal was also downgraded under the "systems design and architecture characteristics" evaluation factor due to weaknesses related to the firm's approach to data integration and management. SRA proposed a database design that, among other things, merged the prototype GTN database and other databases to create a new GTN database. SRA proposed to complete these tasks within 12 months after contract award. The SSEB concluded that accomplishing all of the tasks required to merge the databases within the first 12 months of performance was a significant undertaking that presented high schedule risk.

Although SRA disagrees with the evaluators' conclusion, given the importance the RFP gave to the offerors' data management and proposed database architecture, and in view of the agency's conclusion that SRA's proposed approach required multiple engineering tasks to accomplish, the SSEB reasonably downgraded SRA's proposal for scheduling risks.

SRA further maintains that the agency's past performance risk assessment of SRA's principal subcontractor was unreasonable, because the agency failed to consider its explanations for performance problems. [11] The record shows that the performance risk analysis group downgraded SRA's proposal for performance problems (e.g, relocation of technical staff, management responsiveness, and cost overruns) associated with its principal subcontractor. The agency issued several clarification requests (CR) to SRA questioning the subcontractor's performance problems. The record shows that SRA's responses simply did not overcome the evaluators' concerns regarding the subcontractor's prior performance, and those concerns were properly reported to the SSA. SRA's disagreement with this aspect of the agency's evaluation does not establish that the evaluation was unreasonable. See Sarasota Measurements & Controls, Inc., B-252406.3, July 15, 1994, 94-2 CPD Para. 32.

Evaluation of Unisys' Proposal

Both TRW and SRA argue that the Air Force unreasonably concluded that the software products Unisys proposed (identified in the record as Encompass and SuiteDOME) were NDI because, according to the protesters, the proposed software requires "significant" modifications to meet the RFP's minimum requirements. [12]

The statutory definition of NDI, found at 10 U.S.C. Sec. 2325 (1988 and Supp. II 1990), in relevant part, provides that NDI includes:

"(1) any item of supply that is available in the commercial marketplace;

. . . . .

(3) any item of supply described in paragraph (1) . . . that requires only minor modification in order to meet the requirements of the procuring agency. . . ." [13]

The determination as to whether modifications to an already developed and available product are minor--and thus whether the product properly fits within the definition of NDI--is within the agency's technical judgment, which we will overturn only if it shown to be unreasonable. See Eyring Corp., B-245549.7, Mar. 31, 1992, 92-1 CPD Para. 320. In considering whether a modification is in fact minor, agencies should consider both the technical complexity of the change and the degree of risk associated with it. Id. A protester's mere disagreement with the agency's determination in this regard is not sufficient to establish that the agency acted unreasonably. Ronnoc, Inc., B-243729, Aug. 19, 1991, 91-2 CPD Para. 163. For the reasons set forth below, we conclude that the agency's determination that the products Unisys proposed are NDI was reasonable.

Unisys proposed to use software products developed by its teaming partner Encompass. At the GTN demonstration, which featured several versions of the software, Encompass developers briefed the government on the software's current capabilities, as well as on future plans for the product. The agency also received positive feedback from two current commercial users of Encompass' product detailing their experience with the software and with the company's management. [14] The evaluators examined the software both for its functional capabilities and suitability, and for its technical maturity and content.

The evaluators found that Unisys proposed to meet the vast majority of the first required function (the GTN Intransit Visibility or "ITV"), with an essentially unmodified, commercially available software item. [15] The evaluators concluded that the version of Encompass Unisys proposed demonstrated a "very good" solution to nearly all of the initial operational capabilities requirements of the RFP. The evaluators also found that future planned modifications to the software would reflect commercial releases, rather than developments unique to the GTN requirements. In this connection, the agency explains that the transportation requirements of the commercial marketplace closely resemble the government's for ITV. In sum, the evaluators found that the Encompass software was used by at least two large commercial firms, and would require only minor modifications to meet the RFP's requirements. Based on our review of the record, including the evaluators' conclusions regarding the Encompass software, the agency could reasonably conclude that the software products Unisys proposed qualified as NDI.

Despite the protesters' assertions to the contrary, the fact that the Encompass software products Unisys proposed may undergo future modifications does not render unreasonable a finding that the software qualifies as NDI. [16] The RFP emphasized that the acquisition was designed as an evolutionary program, requiring that each of the minimum required five deliveries of capabilities include enhancements to the GTN system. Thus, it is not unreasonable to expect that future, enhanced versions of the software will contain modifications to meet the evolutionary requirements of the RFP. [17]

The protesters also argue that the agency failed to evaluate Encompass' software capabilities, and thus failed to assess the subcontractor's role as a member of the Unisys team. In this connection, the RFP stated that the government would conduct "one [software capability evaluation (SCE)] per offeror team," and instructed offerors to submit eight projects for evaluation from "the prime team member or the team member who is to accomplish the majority or most critical system/software engineering effort for GTN."

Unisys designated itself for the required SCE. The agency concluded that the highest technical risk in the proposed GTN architecture is associated with the integration of the NDI Encompass functionality with current and future operations of the system. In this connection, Unisys explains that its relationship with Encompass is not one of prime to subcontractor. The firm states that Unisys purchased the Encompass software through a license fee arrangement, and that Unisys will integrate the Encompass product into its solution to satisfy the GTN requirements. Thus, Unisys is not subcontracting for a major developmental effort. Since Unisys, not Encompass, would perform the significant engineering effort required in this area, we think that the agency reasonably decided to conduct the SCE on Unisys, rather than on Encompass. [18]

DISCUSSIONS

Both TRW and SRA challenge the agency's approach to discussing perceived weaknesses in their respective proposals. Specifically, TRW argues that the agency failed to conduct meaningful discussions because it failed to apprise the firm of weaknesses in its proposal related to prototype software the agency made available to offerors under the RFP, and that TRW proposed to use. SRA argues that the agency failed to conduct meaningful discussions because the Air Force did not apprise SRA of three areas of its proposal considered weak or that presented high technical or schedule risks.

Contracting officers must balance a number of competing interests in selecting matters for discussion based on the facts of each acquisition. FAR Sec. 15.610; Matrix Int'l Logistics, Inc., B-249285.2, Dec. 30, 1992, 92-2 CPD Para. 452. They must point out weaknesses that, unless corrected, would prevent an offeror from having a reasonable chance for award. Department of the Navy--Recon., 72 Comp.Gen. 221 (1993), 93-1 CPD Para. 422. On the other hand, agencies are admonished by the FAR to protect the integrity of the procurement process by balancing the need for meaningful discussions against actions that result in technical leveling (FAR Sec. 15.610(d)), technical transfusion (FAR Sec. 15.610(e)(1)), or auctions (FAR Sec. 15.610(e)(2)). For the reasons set forth in detail below, we conclude that under the circumstances here, the Air Force's approach to discussions was reasonable.

The record shows that the Air Force issued CRs and deficiency reports (DR) to both TRW and SRA, pointing out those areas of their proposals needing further explanation or clarification. For each offeror, the Air Force also issued written points for negotiations (PFN) for face-to-face discussions. For each weakness and deficiency identified, the record contains a detailed explanation of the agency's evaluation rationale, and a reference to the corresponding CR, DR, or PFN. In several cases, the agency issued a second set of written discussion items to confirm the offerors' responses or to verify its understanding of the proposals. Based on the record of extensive discussions in this case, and on our review of the specific contentions below, we conclude that the agency's discussion questions were consistent with the weaknesses and deficiencies identified in the protesters' proposals, and that the agency adequately pointed out those areas of the proposals requiring further clarification or explanation. See ITT Fed. Servs. Corp., B-250096, Jan. 5, 1993, 93-1 CPD Para. 6.

TRW's Protest

With respect to TRW's claim that the agency failed to advise it of weaknesses with the prototype software, we note that TRANSCOM began developing GTN proof-of-concept prototypes in 1989. According to the agency, these prototypes have demonstrated many of the key functions necessary to support detailed engineering and functional requirements analysis and concept validation. The final version of the prototype became available in late 1994. The agency planned to continue maintaining and supporting that prototype until the initial operational capability is delivered under the contract contemplated by the RFP.

Despite TRW's assertion that the agency should have advised TRW during discussions of the perceived weaknesses related to its use of the prototype software, the record shows that during the pre-solicitation conference, which TRW personnel attended, the Air Force provided prospective sources with information concerning the prototype software. The presentation documents used for that conference show that the Air Force informed offerors that although the prototype software validated the GTN ITV concept, it was not designed or envisioned as providing an optimal or long-term solution to the RFP. In response to offerors' questions, the agency also stated that offerors were not required to use the prototype software.

In addition, the Air Force expressly made available to offerors other sources of information in the government's possession concerning the prototype software, including the GTN technical library and the agency's electronic RFP bulletin board. Both the technical library and the bulletin board contained incident reports issued on the GTN prototype software identifying discrepancies and other problems users experienced with the software, and detailed information concerning the prototype software (e.g., a reference table data; a business rule and query package information; a description of changes to the prototype software; a current incident reports; and test descriptions). TRW does not dispute the availability of this information.

TRW argues that several prior decisions of our Office [19] mandate a conclusion that the agency's discussions were deficient with respect to weaknesses related to the GTN prototype. We disagree. In the cases cited, we sustained protests where an agency failed to inform an offeror of concerns with its proposal that significantly affected its technical ratings, and thus denied that offeror a reasonable opportunity for award. That is clearly not the case here. As already explained, the agency provided sufficient information on the known problems with the prototype software such that TRW could have taken those problems into account when preparing its proposal.

Given that offerors were not required to use the prototype software, and were explicitly advised that the Air Force did not view the prototype as providing an optimal solution to the RFP, we think that TRW could have examined the technical data concerning the GTN prototype software, and, based on its review of the reported problems, determined for itself which aspects of the software, if any, were suitable as an initial solution to the RFP. [20] Instead, TRW proposed to use the prototype software, which the firm either knew, or should have known, was considered prone to problems. [21] The agency was not required to raise in its discussions with TRW questions concerning weaknesses in its proposal related to known problems with the prototype software.

SRA's Protest

SRA argues that the agency failed to conduct meaningful discussions because the Air Force did not apprise SRA of three areas of its proposal which were considered weak or presented high technical or schedule risks. These included weaknesses related to inconsistent data retrieval and responses experienced during the GTN demonstration, and weaknesses with SRA's proposed screen-builder and its automated interface builder.

During SRA's GTN demonstration, the evaluators noted that several queries of the system produced inconsistent results. [22] In one instance, the evaluator received different results in response to the same query; an initial "run time error;" and one search never executed properly. In his sworn affidavit to our Office, a senior SRA team member who was present during the GTN demonstration acknowledges that the evaluators pointed out to him the problems experienced during the GTN demonstration.

With respect to the screen-builder problems noted, SRA acknowledged at the demonstration that the version of the screen-building product it demonstrated had a memory limitation which forced changes in the amount of data that could be displayed at one time. Although SRA informed the evaluators at the demonstration that a new version of the screen-builder would be released soon after the demonstration, SRA never offered that new version to the Air Force for further evaluation.

As with TRW, although these weaknesses were not specifically raised in written and oral discussions with SRA, SRA was aware of the problems experienced during its GTN demonstration. SRA was present at the GTN demonstration, and SRA had ample opportunity to cure these problems between the GTN demonstration and the close of discussions in January 1995, several months later. Thus, the fact that the agency did not reduce to writing the problems experienced during SRA's GTN demonstration--of which SRA was made aware--does not provide a basis for concluding that the agency's discussions with SRA were deficient.

COST REALISM ADJUSTMENTS

Both TRW and SRA challenge the agency's adjustments to the proposed costs of their respective proposals. The protesters also challenge agency's cost realism analysis of the Unisys proposal.

When agencies evaluate proposals for the award of a cost reimbursement contract, the offerors' proposed estimated costs of contract performance are not considered controlling, since they may not provide valid indications of the actual costs which the government is required to pay. FAR Sec. 15.605(d); Bendix Field Eng'g Corp., B-230076, May 4, 1988, 88-1 CPD Para. 437. Consequently, an agency's evaluation of estimated costs should consider the extent to which an offeror's proposed costs represent what the contract should cost, assuming reasonable economy and efficiency. Arthur D. Little, Inc., B-229698, Mar. 3, 1988, 88-1 CPD Para. 225. Because the contracting agency is in the best position to make this determination, we limit our review of these matters to determining whether the agency's cost evaluation was reasonable. General Research Corp., 70 Comp.Gen. 279 (1991), 91-1 CPD Para. 183.

Adjustments to TRW's Proposed Costs

TRW argues that the agency unreasonably adjusted its proposed cost upward by $10.7 million to account for expected delays in its delivery schedule. Specifically, TRW contends that the RFP did not announce that cost proposals would be adjusted upward for relatively longer delivery periods- -i.e., delivery periods longer than those of an acceptable offeror proposing an earlier delivery of capabilities. [23]

The Air Force explains that scheduled delivery of GTN capabilities was important in assessing the value to the government of each offeror's solution. In addition to allowing DOD to more efficiently and effectively carry out its transportation operations, early delivery of GTN capabilities meant cost savings to the government. These cost savings derive from reductions in reordering processing costs; reduced lease and rental costs of property; reduced communications and transactional costs; and other costs that would be incurred by the government as a result of delayed delivery of operational capabilities. In determining these costs, the agency isolated cost savings for 12 months, and divided that figure by 12 to obtain the expected monthly operations cost. [24] The agency then treated that cost as additional monthly operations costs to the government for each offeror's proposal beyond the earliest proposed delivery schedule.

The record shows that the agency adjusted TRW's proposed total labor hours to reflect additional effort that the evaluators believed would be required to manage and resolve problems likely to rise during the initial phase of performance as a result of TRW's use of the GTN prototype software. The agency then used TRW's proposed staff-year projections to assess the impact of the additional effort on its proposed delivery schedule, and created a more realistic delivery schedule for TRW. Based on the estimated additional effort, the agency calculated a schedule slippage of TRW's first delivery from 14 to 16 months after contract award. The agency estimated the additional costs to the government of the 2-month delay as $10.7 million. We have reviewed the record, including the agency's detailed explanation of its schedule realism methodology, quantification of costs and benefits and resulting calculations, and find no basis to question the agency's adjustments to TRW's proposed cost.

We also conclude that TRW's contention that the agency applied an undisclosed evaluation factor to assess the impact of the additional effort on its delivery schedule is not supported by the record. Section M of the RFP announced that the Air Force would evaluate the offerors' proposed schedule for timeliness and progressive delivery of system capabilities, and emphasized that the agency preferred an early delivery of capabilities. [25] The record shows that the agency's methodology quantified the costs to the government of later delivery of capabilities, and added those costs to TRW's proposal based on a more realistic delivery schedule developed for TRW. The protester has not shown that the agency improperly calculated the additional costs associated with later delivery of capabilities, and we conclude that the adjustment here was reasonable.

Adjustments to Unisys' Proposed Costs

TRW argues that the Air Force's cost realism analysis of Unisys' proposed cost was flawed. Unisys reduced its initial proposed costs from $94.3 to $55 million in its BAFO, and the protester argues that the agency failed to reasonably evaluate the realism of Unisys' proposed costs or the impact of the reduction on Unisys' technical rating.

In its initial proposal, Unisys included labor hours for activities that would be performed by one of its major team members, and were thus redundant. Unisys deleted the redundant labor hours, activities and related costs from its proposal, resulting in a significant reduction in its cost. The record shows that the reduction in cost was attributed in part to the agency's clarifying its requirement under one of the fixed- price CLINs--an option for additional lines of code. These changes alone accounted for a significant portion of the overall reduction in Unisys' proposed cost.

The record shows that the redundant labor hours and activities were the topic of several areas of discussion and analysis, and that Unisys fully explained the cost rationale for its changes during discussions. The agency's cost realism assessment (CRA) team evaluated Unisys' labor hour estimates and associated costs for work breakdown consistency; the reasonableness of the level-of-effort given the technical approach proposed; and the reasonableness of the proposed labor mix and corresponding hourly rates. The CRA team also reviewed Unisys' BAFO for errors or omissions in estimated costs. The CRA team concluded that, with the exception of additional labor required for staffing a hotline for which adjustments were made, Unisys proposed adequate resources in its BAFO, and its proposed labor hour estimates were reasonable.

A BAFO request necessarily implies an opportunity to make revisions to previously submitted proposals, including price changes, unless the RFP specifically restricts the scope of changes. Here, all offerors whose proposals were retained in the competitive range, including TRW, were given an opportunity to submit a BAFO. The record shows that for all offerors, including Unisys, the CRA team conducted an extensive analysis of revised proposed costs. Contrary to TRW's contentions, the record shows that the agency thoroughly considered the impact of the reductions in Unisys' BAFO cost on its proposal, and considered the firm's explanations reasonable. We have no basis to question the CRA's conclusions in this regard.

Adjustments to SRA's Proposed Costs

The agency adjusted SRA's proposed cost upward by $15.8 million to reflect a more realistic cost of generating the total lines of code SRA proposed. SRA argues that this adjustment was unreasonable because the agency applied an unreliable industry average to base its calculations. SRA also argues that the agency's methodology was flawed because it ignored SRA's approach. [26]

The record shows that the agency determined a total number of lines of code SRA proposed. [27] The agency then calculated a cost per line of code as proposed, and compared that cost to an industry average. The agency reviewed two sources of information to calculate the industry average cost per line of code. [28] Based on the results of the SSEB's evaluation, the agency concluded that SRA could not reasonably be expected to produce software for the GTN effort at the per line of code cost it proposed. The difference between SRA's cost per line of code and the industry average yielded an upward adjustment of $15.8 million to SRA's proposed cost. [29]

SRA points to language in one of the agency's sources (Capers Jones) to argue that the author did not consider the data reliable, and thus that the Air Force should not have applied the industry average described in that document to calculate a cost per line of code. While Jones acknowledged that the study described contains a "high margin of error," Jones concluded that the methodology used yielded a "useful benchmark" against which future studies of software productivity could be evaluated. The record also shows that the agency referred to historical information in the government's possession--which suggested a higher industry average per line of code cost--before settling on the lower amount used to adjust SRA's proposed cost. Although SRA contends that the agency's reliance on the average cost per line of code suggested by Jones was unreasonable because that average is too high, we have no reason to question the agency's approach. We also note that even if the agency abandoned the Capers Jones figures and instead used estimates based on historical data-- an acceptable and generally accurate basis for determining average costs, see, e.g., Alltech, Inc., B-237980, Mar. 27, 1990, 90-1 CPD Para. 335, the resulting adjustment would be based on an even higher average cost per line of code than that used by the agency.

Contrary to the protester's assertion, the agency's cost adjustments did not ignore its approach. The record shows that the agency thoroughly reviewed SRA's proposal to determine whether SRA's approach could support its low software development cost, including: the firm's rating in the software capability evaluation; SRA's proposed set of software development tools; personnel skill and experience; and past performance on other similar projects. Based on its assessment of SRA's approach, the agency reasonably concluded that SRA could not be expected to produce the total lines of code at the cost proposed. While the protester disagrees with the agency's calculation in this regard, we see no basis to conclude that the agency's approach was unreasonable.

COST/TECHNICAL TRADEOFF

TRW and SRA challenge the SSA's selection of Unisys' proposal, arguing that the SSA did not reasonably determine that Unisys' higher evaluation ratings were worth the higher cost. The protesters maintain that the SSA placed undue weight on the "Use of NDI" evaluation factor in her selection decision.

The SSA considered the strengths of Unisys' proposal in comparison to both protesters' proposals, and concluded that Unisys' proposal was technically superior overall. For instance, the SSA found that Unisys had demonstrated a clear understanding of the GTN system requirements, with a lower risk than SRA's or TRW's approach. The SSA also found that Unisys' approach provided a high degree of flexibility and capability to expand to meet future GTN requirements. The SSA also noted that Unisys' proposal offered the earliest realistic proposed delivery of the critical function (the GTN ITV capability), with the least amount of risk. The SSA specifically found that Unisys' demonstration of its intended delivery of initial operational capability adequately supported the awardee's higher technical ratings. The SSA also found that the level of technical and management effort proposed in support of Unisys' estimate of the amount of lines of code to be developed, was consistent with Unisys' demonstrated understanding of the requirements of the RFP. While Unisys was not the offeror with the lowest proposed cost, the SSA concurred with the evaluators' finding that Unisys' proposal was reasonable and realistic for the level-of-effort proposed.

With respect to SRA's proposal, while the SSA considered some of the strengths shared by SRA's and Unisys' proposals (such as proposed early deliveries of GTN ITV), the SSA concluded that weaknesses in SRA's proposal--which accounted for its lower ratings--represented qualitative differences between SRA's and Unisys proposal. The SSA found that the strengths identified in SRA's proposal presented a high risk to its proposed delivery schedule. The SSA considered these weaknesses with respect to technical risk and schedule realism, and concluded that the relative strengths of Unisys' proposal outweighed SRA's lower proposed cost.

The SSA also considered TRW's low evaluated cost proposal and weaknesses which resulted in a higher level of risk. Further, the SSA considered the additional expected costs to the government as a result of TRW's unrealistic proposed delivery schedule. In addition to quantifiable value associated with Unisys' earlier delivery of capability, the SSA also noted that Unisys' proposal had qualitative advantages over TRW's proposal, such as Unisys' use of a commercial transportation management system, which presented a low risk, phased evolution path, to meet future GTN requirements.

The protesters' argument that the SSA placed undue weight on the "Use of NDI" evaluation factor in her selection decision is without merit. The RFP clearly expressed the agency's "significant preference for the use of integrated NDI (commercial and government-off-the-shelf) products," and encouraged offerors to "maximize" the use of NDI products in deriving the system architecture. The SSA did not rely solely on Unisys' proposed use of NDI products in her selection decision. Rather, this was one aspect of Unisys' proposal which highlighted for the SSA its technical superiority.

In a negotiated procurement, there is no requirement that award be made on the basis of lowest cost unless the RFP so specifies. Henry H. Hackett & Sons, B-237181, Feb. 1, 1990, 90-1 CPD Para. 136. Cost/technical tradeoffs may be made, and the extent to which one may be sacrificed for the other is governed only by the tests of rationality and consistency with the established evaluation factors. Grey Advertising, Inc., 55 Comp. Gen. 1111 (1976), 76-1 CPD Para. 325. Awards to offerors with higher technical scores and higher costs are proper so long as the result is consistent with the evaluation criteria, and the procuring agency reasonably determines that the technical difference is worth the cost premium. Bendix Field Eng'g Corp., B-241156, Jan. 16, 1991, 91-1 CPD Para. 44. Here, based on our review of the record, we find that the SSA reasonably concluded, consistent with the RFP, that Unisys' evaluated technical superiority and lower performance risk outweighed the protesters' lower costs. See DynCorp, B-245289.3, July 30, 1992, 93-1 CPD Para. 69.

The protests are denied.

1. TRANSCOM was established to integrate the disparate elements of the Defense Transportation System and to provide a single manager for common users. Although TRANSCOM's charter focused exclusively on coordinating the Department of Defense's (DOD) wartime transportation needs, experience gained during operations Desert Shield and Desert Storm underscored TRANSCOM's need for a system that monitors the status of transportation capabilities, as well as provides accurate reports on the readiness of transportation assets.

2. The Air Force determined that, pursuant to the provisions of 40 U.S.C. Sec. 759(a)(3)(C) (1988), it was not required to obtain a delegation of authority from the General Services Administration to conduct this procurement.

3. The RFP permitted offerors to propose as many incremental deliveries of hardware and software above the minimum required as deemed necessary to provide a GTN that met the government's requirements.

4. The color/adjectival ratings are: blue (exceptional); green (acceptable); yellow (marginal); and red (unacceptable). Risk ratings were high, moderate, or low.

5. Factor 1 was more important than factor 2; factor 2 was more important than factor 3; and factor 3 was more important than factors 4, 5, 6, and 7 which were of equal importance.

6. The RFP stated that the software capability evaluation factor was the most important factor within the management area, with the remaining factors being of lesser importance but equal to each other. The RFP also identified two "General Considerations" (the pre-award survey and the executive in-plant review), intended to confirm the offeror's capabilities; and two "Assessment Criteria" (soundness of approach, and compliance with requirements), that would also be considered in evaluating proposals.

7. TRW filed its initial protest on March 30, 1995, within 10 days after award. On April 7, the head of the procuring activity responsible for the contract determined pursuant to 31 U.S.C. Sec. 3553(d)(2)(A)(ii) (1988) that urgent and compelling circumstances significantly affecting the interests of the United States would not permit awaiting our decision and authorized Unisys to perform the contract.

8. The GTN system specifications required external system interfaces to, among other things, receive updates from source systems on a recurring basis and update the GTN database; and to support continuity of operations to maintain flow of data from the source systems to GTN and from GTN to customer systems.

9. The Air Force's definition of high risk is: "likely to cause significant, serious disruption of schedule, increase in cost, or degradation of performance."

10. SRA also argues that the schedule risk upward adjustment to its proposal of $15.8 million that resulted from this aspect of the evaluation was unreasonable. SRA apparently misunderstands the impact of this low rating on the upward cost adjustment the agency made to SRA's proposed cost. The record shows that the high schedule risk identified in this area was only one element of the agency's cost adjustment of only $1 million to SRA's proposal, not $15.8 million as SRA maintains. Although the agency apparently mislabeled the ($15.8 million) adjustment as "schedule risk" during SRA's debriefing, as discussed in greater detail below, that adjustment was not related to the weaknesses identified in SRA's proposed interface builder tools.

11. An agency may properly consider an offeror's subcontractor's capabilities and experience under relevant evaluation factors, particularly, where, as here, the RFP allowed the use of subcontractors and specifically stated that the subcontractor's experience would be evaluated. See FMC Corp., B-252941, July 29, 1993, 93-2 CPD Para. 71.

12. In its initial protest, TRW challenged nearly all of the color code ratings and risk assessments assigned its proposal under the technical evaluation factors. The agency responded in detail to each of TRW's contentions, including a point-by-point discussion of the technical ratings, risk assessments, and the agency's evaluation rationale. Although TRW states in a footnote in its comments that it "does not withdraw" any of the issues raised in its initial protest, TRW does not specifically rebut any of the agency's explanations regarding the technical evaluation or risk assessments of it proposal. We have reviewed the record in light of the agency's detailed explanation and, in the absence of any comments from TRW in this regard, find no basis to question the agency's evaluation of TRW's proposal. See CardioMetrix, B-257408, Aug. 3, 1994, 94-2 CPD Para. 57.

13. See also Defense Federal Acquisition Regulation (FAR) Supplement Sec. 211.7001, which defines "Commercial items" as including:

"items regularly used in the course of normal business operations for other than [g]overnment purposes which: (1) Have been sold or licensed to the general public; . . . [and] would require only minor modification in order to meet the requirements of the procuring agency."

14. The evaluation concluded that Encompass is a commercial product that is used by several "Fortune 500" companies. While SRA disputes the total number of commercial firms that use the Encompass software, the agency did not rely solely on that number, as reported by Unisys, to base its conclusion that the software is a commercial product.

15. SRA correctly notes that following the initial evaluation, the evaluators noted that proposed enhancements to the software could create a scheduling risk, and assigned Unisys' proposal an initial risk rating of "Moderate" overall under the "Use of NDI" evaluation factor. Following discussions, however, the evaluators concluded that Encompass's extensive commercial customer base, and widely used SuiteDOME software, strengthened Unisys' proposal, and ultimately assigned a technical rating of "blue" (exceptional) and low risk under the "Use of NDI" evaluation factor.

16. SRA argues that the Encompass software should not be considered commercially available because Unisys indicated in its proposal that several hundred thousand lines of code will be developed over the life of this contract to enhance the software capability. As explained here, the fact that additional lines of code will be developed to enhance the proposed software does not affect our conclusion that the agency could reasonably find that it is commercially available. Further, SRA does not explain why the total number of additional lines of code should be viewed as "significant" modifications, rather than enhancements to an already existing commercial product, as the agency concluded.

17. We note that TRW likewise proposed software that would undergo "modifications" during contract performance. TRW explained that while it proposed its most current release of the software, a new version--with enhanced performance features incorporating "evolving standards and technology"--was scheduled for later release. TRW also describes in detail its process for "integrating evolving NDI technology and upgrades" to future versions of the software.

18. The protesters also argue that the agency had insufficient information to assess the role of Encompass in the Unisys team, and thus, that the agency's low performance risk rating assigned Unisys' proposal related to its use of Encompass software was unreasonable. This argument is without merit. The record shows that the agency recognized the role of Encompass in Unisys' proposal, and evaluated both the maturity and technical schedule risks associated with the product. As already explained, the evaluators also experienced first hand the strengths, weaknesses, and capabilities of the software during the GTN demonstration. Based on the evaluators' assessment, the low risk rating assigned Unisys proposal was reasonable.

19. TRW cites American Dev. Corp., B-251876.4, July 12, 1993, 93-2 Para. 49; Department of the Navy--Recon., supra; and Eldyne, Inc., B-250158 et al., Jan. 14, 1993, 93-1 CPD Para. 430.

20. In this connection, the record shows that Unisys also proposed to use the prototype software, but limited its use to those aspects of the software which it determined, based on its review of the technical information provided concerning the software, were not problematic.

21. Despite TRW's assertion to the contrary, this is not a case where the government possesses "superior knowledge" not shared by the offerors. See, e.g., EER Sys. Corp., B-248904.3, Mar. 8, 1993, 93-1 CPD Para. 211; see also Helene Curtis Indus. v. the United States, 312 F.2d 774 (Ct. Cl. 1963); Globe Woolen & Co. v. Utica Gas and Elec. Co., 121 N.E. 378, 380 (N.Y. 1918). As explained above, the deficiencies with the software were revealed to prospective offerors.

22. SRA maintains that the data management problems and inconsistent results experienced during the GTN demonstration stemmed from the government's delay in providing data for the demonstration. The record shows, however, that the agency made data available in the technical library to potential sources as early as July 1993, and no later than July 1994. SRA's last visit to the technical library was on June 28, 1994. Thus, contrary to SRA's assertions, it appears that, at the latest, the agency made the necessary data available more than 1 month before SRA's scheduled demonstration in late August 1994.

23. Since Unisys proposed the earliest realistic delivery of capabilities, the Air Force used Unisys' schedule as a baseline. The agency then added additional costs to other offerors' proposals for each day delivery of capabilities would be delayed beyond Unisys' earliest delivery date.

24. The Air Force documented its methodology, assumptions, and techniques used to quantify these costs and benefits in a final report entitled United States Transportation Command Global Transportation Network Life Cycle Cost/Benefit Analysis (January, 1995).

25. The agency calculated this figure based on estimated costs to the government of $6.7 million in additional transportation costs and $4 million in redundant cargo moving on DOD assets. The agency explains that reordered item savings are attained through additional insight into the transportation system provided by the GTN ITV capability, a reorder is not placed because the system will be able to keep close track (e.g., location and expected delivery schedule) of ordered items. Additionally, the costs of canceling duplicate orders and returning the items to their originating depots are avoided.

26. In its initial protest, SRA claimed that in adjusting its cost, the agency improperly double counted lines of code, resulting in an apparent unrealistically low cost per line of code. The agency explains, however, that it used only the number of lines of code identified by SRA in its proposal, throughout discussions, and confirmed in its BAFO. The protester does not take issue with the agency's statements in this regard.

27. SRA confirmed the specific number of both manual-and machine-generated lines of code it proposed in response to discussion questions.

28. The agency referred to Capers Jones Applied Software Measurement (1991), and the Air Force's Electronic System Center Historical Database. The cost per line of code (including maintenance) proposed by the offerors ranged from $29 to $237. The Capers Jones study yielded an industry average of $96 per line of code, while the agency's historical database yielded an average of $118.

29. This adjustment appears as a "schedule realism" adjustment to SRA's proposal in several documents in the agency report. The agency explains, however, that the adjustment should have been labeled a "cost realism" adjustment, and that it was reported as such to the SSA.