IndraSoft, Inc.

DOCUMENT FOR PUBLIC RELEASE
The decision issued on the date below was subject to a GAO Protective Order. This redacted version has been approved for public release.

Decision

Matter of:  IndraSoft, Inc.

File:  B-414026; B-414026.2

Date:  January 23, 2017

DIGEST

Protest challenging an agency’s assessment of technical risk is denied where the agency reasonably determined that the protester’s technical approach warranted a moderate risk rating and the awardee’s approach warranted a low risk rating.

DECISION

IndraSoft, Inc., a woman-owned small business of Reston, Virginia, protests the issuance of a task order to DSD Laboratories, Inc., of Sudbury, Massachusetts, pursuant to request for proposals (RFP) No. FA8770-14-R-0517, which was issued by the Department of the Air Force for an integrated supply chain planning service to support Air Force sustainment centers.  IndraSoft challenges the agency’s assessment of risk with respect to both its and DSD’s proposed technical approaches.

We deny the protest.

BACKGROUND

The Air Force issued the solicitation on March 14, 2016, seeking proposals for the enterprise supply chain analysis, planning, and execution (ESCAPE) acquisition.  The ESCAPE solicitation, which was issued pursuant to Federal Acquisition Regulation (FAR) subpart 16.5 and limited to small businesses holding Network-Centric Solutions-2 (NETCENTS‑2) contracts, anticipated the issuance of a fixed‑price order for a base year and four option years.  RFP, attach. 3, Contract Line Item Number (CLIN) Structure, at 1-9.  

Under the ESCAPE acquisition, the Air Force sought to improve the agency’s supply chain planning capabilities, enabling more effective warfighter combat support and enhanced supply chain decision making.  Performance Work Statement (PWS) ¶ 2.  The program aimed to consolidate legacy-driven processes, creating a more efficient supply chain planning workforce with improved inventory performance for Air Force operations.  Id. ¶ 1.  Specifically, the PWS required the contractor to provide an information technology (IT) supply chain planning service solution consisting of project management, service lifecycle management, and technical service requirements.  Id. ¶ 3. 

With respect to service lifecycle management, the PWS outlined hundreds of IT functional requirements for the ESCAPE service program.[1]  Id., app. D, Contextual Model, at 64-611.  These functional requirements were further delineated in a spreadsheet referred to as the requirements traceability matrix (RTM).  Id., app. J, RTM, at 730-58.  In all, the RTM identified 1,244 unique IT functional requirements necessary to produce and track inventory levels, repair and procure inventory items, and track part movements through the Air Force-wide supply chain.[2]  See id.; Contracting Officer’s Statement (COS) at 15.

Pursuant to the solicitation, award was to be made on a best-value basis, considering price and the following non-price factors:  technical, technical risk, and past performance.  RFP, Evaluation Factors for Award, at 2-3.  The technical factor, which was to be evaluated on an acceptable/unacceptable basis, included four subfactors:  project management, service lifecycle management, technical service requirements, and data rights.  Id. at 3-6.  For all technically acceptable proposals, past performance was significantly more important than technical risk, and those two factors, when combined, were significantly more important than price.  Id. at 3.

Of relevance here is the agency’s assessment of risk based on the offerors’ approaches to service lifecycle management.  Under one element of the service lifecycle management subfactor, offerors were to address their plan for meeting the functional requirements of the ESCAPE program.  RFP, Instructions to Offerors, at 11.  Specifically, the RFP instructed offerors to fill in blank columns in the PWS’s RTM spreadsheet for each of the 1,244 functional requirements.  Id.  Column G anticipated a brief description (no more than 50 characters per cell) of the offeror’s proposed solution for each of the requirements.[3]  PWS, app. J, RTM, at 730-58.  In this “Proposed Solution Approach” column, the RFP and RTM instructed offerors to specify the applicable software name and version used to satisfy each requirement, or if an alternative approach was proposed, the offeror was to specify “Development,” “Manual Activity,” or describe the proposed alternative (within the 50 character limit).  Id.; RFP, Instructions to Offerors, at 11.

While the service lifecycle management subfactor would be assessed as either acceptable or unacceptable, weaknesses assigned under the subfactor would impact the technical risk factor evaluation.  In this regard, in evaluating proposals under the technical risk factor, the agency was to assess the risks and weaknesses associated with an offeror’s proposed technical approach to meeting the service lifecycle management and technical service requirements.[4]  RFP, Evaluation Factors for Award, at 6.  The evaluation was to consider the potential for disruption of schedule, increased costs, degradation of performance, the need for increased government oversight, or the likelihood of unsuccessful contract performance.  Id.  The agency was to evaluate the offeror’s independent assessment of risk,[5] as well as any risks or weaknesses identified by the Air Force as part of its technical evaluation.  Id. at 33.  Pursuant to the RFP, the Air Force would assign proposals a risk rating of either low, moderate, or high.  Id.

The Air Force received proposals from IndraSoft, DSD, and one other offeror by the April 18 response date.  COS at 8.  With respect to service lifecycle management, IndraSoft proposed to meet approximately 1,171 of the 1,244 functional requirements through the use of a commercially available off-the-shelf (COTS) software developed by PTC, Inc., called Service Part Management version 11 (SPM v11).[6]  Agency Report (AR), Tab 21, IndraSoft RTM, column G, at 1-89.  For the remaining 73 requirements (approximately 6 percent), IndraSoft indicated in the RTM, “SPM v11 + Development” for 21 requirements, “SPM v11 + Development or Other Proposed Alternative” for 51 requirements, and “SPM v11 + Development + Manual Activity” for the remaining requirement.[7]  Id. at 3-79.  In its technical proposal, IndraSoft further explained that, for these requirements, it was proposing the use of extensions that included “the use of PTC previously developed library code and Team IndraSoft developed code that leverage USAF specific code, as available, and requirements” or an alternative approach.  AR, Tab 20, IndraSoft Final Technical Proposal, at 32.

DSD also proposed the use of PTC’s SPM v11 for the bulk of the functional requirements.  Specifically, in its RTM, DSD indicated it would satisfy 1,169 requirements with SPM v11, 8 with SPM v11 with PTC library code, 39 with SPM v11 in conjunction with government furnished equipment (GFE)/maintenance and repair operations (MRO), and 28 solely with GFE/MRO.  AR, Tab 23, DSD RTM, column G, at 1-39.  Thus, for the requirements that could not be met through the use of SPM v11, DSD explained in its technical proposal that it proposed to utilize government equipment.  AR, Tab 22, DSD Final Technical Proposal, at 46.

A technical evaluation team (TET) assessed the firms’ proposed technical approaches and rated both IndraSoft’s and DSD’s proposals acceptable under the four technical subfactors.[8]  AR, Tab 14, IndraSoft Initial Technical Chief Summaries, at 1, 5, 10, and 13; Tab 15, DSD Initial Technical Chief Summaries, at 1, 5, 11, and 14.  Notwithstanding the acceptable technical ratings, the TET identified weaknesses with both offerors’ approaches due to the need for additional software (besides SPM v11) to complete the requirements.  With respect to IndraSoft, the TET deemed its approach to satisfying the gap in SPM v11 functionality as “risky to the Government since it relie[d] on new development outside the offeror’s primary COTS solution to satisfy the requirement.”  AR, Tab 24, IndraSoft Technical Subfactor Chief Summary, at 2.  As a result, IndraSoft’s proposal was assigned a moderate risk rating under the technical risk factor.  AR, Tab 28, Proposal Analysis Report (PAR), at 34.

For DSD, the TET also highlighted the gap in functionality for the requirements that could not be satisfied with SPM v11.  AR, Tab 26, DSD Technical Subfactor Chief Summary, at 3.  The TET assigned DSD’s proposal a weakness because the firm’s approach necessitated a reliance on existing legacy systems.  Id.  DSD’s proposal was assigned a low risk rating under the technical risk factor.  AR, Tab 28, PAR, at 18.

The source selection authority (SSA) performed an integrated assessment of the proposals and concurred with the TET’s evaluation findings.  In his best-value determination, the SSA noted that both offerors were technically acceptable and assigned the same substantial confidence rating under the past performance factor.[9]  AR, Tab 29, Source Selection Decision Document (SSDD), at 8, 15.  The SSA also noted that IndraSoft’s $77,043,768 offer was 1.3 percent lower-priced than DSD’s $78,355,197 offer.  Id. at 15.  With respect to technical approaches, the SSA acknowledged that the firms identified “very similar capability gaps” (outside of the SPM v11 solution) that amounted to approximately 5 percent of the total functional requirements.  Id. at 16.  However, the SSA highlighted that, whereas DSD proposed to resolve the gaps through integration with already operational systems, IndraSoft proposed developmental activities with subsequent integration.  Id.  With respect to IndraSoft’s approach, the SSA noted that “the risk of schedule slippage due to inherent difficulties associated with development is high, and protracted delays associated with development likely.”  Id.  Ultimately, the SSA concluded that the benefit the Air Force would receive from DSD’s less risky approach offset IndraSoft’s $1.3 million price premium.

The Air Force issued the task order to DSD on September 28.  Following a post‑award debriefing, IndraSoft protested to our Office.[10]

DISCUSSION

IndraSoft challenges the agency’s assessment of technical risk.  Specifically, IndraSoft disputes that its proposed approach warranted a moderate risk rating.  The protester also argues that the Air Force misevaluated DSD’s proposed approach to satisfying the functional requirement, and that the evaluation reflects unequal treatment since both firms proposed to use the same PTC SPM v11 software.  Lastly, IndraSoft argues that the agency made an unreasonable best‑value determination that was based on the flawed risk assessment.[11]

The evaluation of offerors’ technical proposals, including the determination of the relative merits of proposals, is primarily a matter within the contracting agency’s discretion, since the agency is responsible for defining its needs and the best method of accommodating them.  Highmark Medicare Servs., Inc., et al., B‑401062.5 et al., Oct. 29, 2010, 2010 CPD ¶ 285 at 12.  In reviewing protests challenging the evaluation of proposals in a task order competition, we do not conduct a new evaluation or substitute our judgment for that of the agency but examine the record to determine whether the agency’s judgment was reasonable and in accord with the evaluation criteria.  Booz Allen Hamilton, Inc.; Leidos Inc., B‑410032.4 et al., Mar. 16, 2015, 2015 CPD ¶ 108 at 5.  A protester’s disagreement with an agency’s judgment is not sufficient to establish that an agency acted unreasonably.  STG, Inc., B-405101.3 et al., Jan. 12, 2012, 2012 CPD ¶ 48 at 7.

As noted above, IndraSoft proposed to use PTC’s SPM v11 to satisfy 94 percent of the ESCAPE functional requirements.  For the remaining 73 requirements that could not be satisfied through SPM v11 exclusively, IndraSoft proposed extensions that included the use of PTC’s previously developed library code and Team IndraSoft developed code, along with Air Force code where available.  AR, Tab 20, IndraSoft Final Technical Proposal, at 32.  IndraSoft also proposed an alternative if the agency agreed that an alternate approach was “required to reduce the size and complexity of extensions during the initial analysis. . . .”  Id.  IndraSoft further explained that its alternate solution did “not depend on any special software to be developed by any service provider outside our solution, because the product selected [would] be commercially available software. . . .”  Id.  IndraSoft maintained that such a solution would not require additional monitoring nor add risk to its approach.  Id.

The TET reviewed IndraSoft’s proposed technical approach and disagreed with the firm’s self-assessment that the solution was not risky.  In this regard, the TET described IndraSoft’s proposed approach to fulfill the supply planning requirements outside of SPM v11 as “development with the option of discussing an alternative after cont[r]act award.”  AR, Tab 24, IndraSoft Technical Subfactor Chief Summary, at 3.  Specifically, for the 22 requirements where IndraSoft did not indicate any alternate solution in the RTM, the TET was concerned that the agency would incur integration and development costs.  Regarding IndraSoft’s approach to use library code, the TET explained:

This has the potential to cause additional integration and additional Government monitoring to ensure the development effort is proceeding on schedule and the interfacing partners are cooperating.  This may cause cost increases to the interfacing programs and potentially degraded service that will necessitate close Government monitoring.

Id.  In addition, for the 51 requirements covered by IndraSoft’s proposed alternative solution, the TET highlighted that IndraSoft had not specifically described or provided details regarding alternative approaches or explicitly stated which alternative products would be used to satisfy specific requirements.  Thus, the TET concluded that the firm failed to provide sufficient detail regarding its alternative approaches to lower the overall risk.  Id.  Because, in the TET’s view, the risk had the potential to cause disruption of schedule, increased costs, or degradation of performance, a moderate risk rating was assigned.  AR, Tab 28, PAR, at 34.

Here, we find unobjectionable the agency’s evaluation of IndraSoft’s proposed approaches to satisfying the ESCAPE functional requirements.  The RFP required the agency to consider the risks associated with the offeror’s approach to meeting the requirements.  RFP, Evaluation Factors for Award, at 6.  The agency reviewed IndraSoft’s proposed approaches and had concerns with how the firm anticipated satisfying requirements not covered by SPM v11.  The agency viewed the integration of the PTC library code with the IndraSoft code as developmental because, while the PTC code and IndraSoft code already existed, IndraSoft proposed to integrate the codes together to create a new product (or software extensions), which did not exist.  COS at 17-18; AR, Tab 35, Declaration of TET Chief, at 7.  The agency concluded that the integration of the separate codes could produce unforeseen and/or unanticipated problems.  Moreover, while IndraSoft proposed an alternate approach for some of the requirements, the firm failed to describe or provide details regarding which alternative products would be used.  Based on our review of the record, we find the moderate risk assessment to be reasonable.

IndraSoft counters that the use of library code and extensions “would not require significant software development,” and that the requirements to be satisfied outside of the COTS solution amounted to only 6 percent of the functional requirements.  Protest at 9.  IndraSoft further asserts that the Air Force conceded during the debriefing that the use of PTC library code was low risk.  Notwithstanding these complaints and IndraSoft’s view that the software development would not be burdensome, the record is clear that part of IndraSoft’s proposed technical approach involved integrating code that was not currently operational.  Indeed, IndraSoft, itself, categorized this aspect of its approach as developmental in its RTM.  The agency reasonably considered the approach moderately risky given that the solution had yet to be developed and did not have a proven track record. 

Moreover, while the total number of affected requirements is relatively small, the agency explains that the failure to meet any single requirement could negatively impact the entire program.  Finally, the TET’s risk assessment was not based on the stand-alone PTC or IndraSoft library code, as IndraSoft suggests.  Rather, the risk focused on the development necessary to integrate the library code and Air Force specific code to develop the software extensions.  IndraSoft may disagree with this assessment, but it has not shown it to be flawed, unreasonable, or otherwise inconsistent with the terms of the solicitation.

Next, IndraSoft protests the evaluation of DSD’s technical approach.  IndraSoft complains that DSD failed to identify what government equipment it would use to satisfy the requirements not covered by SPM v11.  IndraSoft further argues that the solicitation did not contemplate the provision of any GFE.

As noted above, DSD proposed the same SPM v11 COTS solution as IndraSoft to satisfy most of the functional requirements.  For the requirements that could not be met through the PTC software, DSD’s technical approach involved the use of government equipment.  See AR, Tab 23, DSD RTM, column G, at 1-39; Tab 22, DSD Final Technical Proposal, at 46.  Specifically, DSD explained in its proposal that 1,169 requirements could be met by standard PTC SPM v11 functionality and 8 could be satisfied by SPM v11 with PTC library code.  AR, Tab 22, DSD Final Technical Proposal, at 46.  For 39 requirements, DSD proposed SPM v11 “in conjunction with GFE/MRO . . . assuming the Government chooses to utilize existing GFE resources (PTC has an extensive client base of joint production PTC SPM/MRO systems or systems like [EXPRESS]).”  Id.  For the remaining 28 functional requirements (related to capacity constraints or execution activities), DSD also proposed PTC SPM/MRO systems or systems like EXPRESS.  Id.

The agency reviewed DSD’s proposed solution and assigned a weakness to the proposal due to the gap of SPM v11 functionality that necessitated a reliance on existing legacy systems.  AR, Tab 26, DSD Technical Subfactor Chief Summary, at 3.  Nevertheless, the TET concluded that the use of legacy systems had “little potential to cause additional integration and normal Government monitoring [would] be required to ensure partners [were] cooperating.”  Id.  This weakness, along with the consideration of risks identified by DSD in its proposal (and proposed mitigation of those risks) resulted in the awardee’s low risk rating.  AR, Tab 28, PAR, at 17-18.

Based on our review of the record, we find that the agency reasonably assessed DSD’s proposed approach as low risk.  First, the agency was clear regarding what DSD was proposing.  Specifically, the TET chief explains that based on the nature of the 67 requirements not covered by SPM v11, coupled with the TET’s knowledge of the legacy systems, the TET interpreted that DSD was proposing a limited number of legacy Air Force systems would be necessary to meet these requirements.  AR, Tab 35, Declaration of TET Chief, at 3.  In actuality, the awardee would not be furnished tangible government equipment (in this case, software) with the expectation of using it in a production capacity.  Supp. COS at 4.  Rather, the Air Force systems would pass information to the contractor’s solution and receive returning information from the contractor’s solution, and the Air Force-operated systems would continue to provide the functionality identified in the requirements annotated as requiring GFE in DSD’s RTM (such as capacity constrained supply planning, capacity management, and order prioritization for parts).  AR, Tab 35, Declaration of TET Chief, at 3.  The TET further assessed that the Execution and Prioritization Repair Support System (EXPRESS)[12] would likely be the primary system to provide and receive the required information to and from the contractor in meeting these 67 requirements not satisfied by the COTS solution.[13]  Id.

Thus, the TET viewed DSD’s approach as requiring the transfer of information between systems (e.g., SPM v11 and EXPRESS) similar to how information was currently being passed between legacy systems, which, in the TET’s judgment, was a low-risk approach even though it continued the use of certain legacy systems and processes.  See COS at 23.  Given that the awardee proposed to use existing legacy government systems, such as EXPRESS, which were already developed, in use, and receiving data from other logistics systems, we see nothing objectionable with the low risk rating.

In addition, despite what IndraSoft argues, the solicitation did not preclude the continued use of legacy systems as part of an offeror’s technical approach.  On the contrary, the RFP plainly contemplated it.  While the consolidation of legacy system‑driven processes was a purpose of the ESCAPE acquisition, the solicitation did not mandate that an offeror’s approach completely rely on new systems and processes.[14]  Accordingly, the PWS provided a comprehensive list of the legacy systems and processes that “may” be replaced by ESCAPE; it did not require the replacement of each one.  See PWS, app. E, Data Acquisition Methods and Priorities, at 614-16; app. H, Legacy System Information, at 647-711.  Nevertheless, DSD’s proposal was still assigned a weakness due to the gap in SPM v11 functionality and the need to rely on legacy systems to satisfy those functional requirements.

Lastly, IndraSoft’s asserts that the evaluation conclusions are the result of disparate treatment.  Where a protester alleges unequal treatment in a technical evaluation, it must show that the difference in ratings did not stem from differences between the proposals.  Raytheon Co., Space & Airborne Sys., B-411631, Sept. 16, 2015, 2015 CPD ¶ 361 at 8.  IndraSoft cannot make such a showing here. 

The record is clear that while both firms proposed PTC’s SPM v11, how the companies planned to fill gaps in functionality is what resulted in the different risk ratings.  In this respect, whereas IndraSoft proposed to develop software extensions to provide functionality that would be similar to EXPRESS and other legacy systems, DSD proposed to simply leverage the existing system.  Thus, because DSD’s proposed approach to satisfy the gap in SPM v11 functionality did not require developing a new software product or solution, and IndraSoft’s approach did, we fail to see how the different risk ratings were the result of an unequal evaluation, as IndraSoft alleges.

In sum, we find unobjectionable the agency’s concerns regarding IndraSoft’s approach to fulfill the functional requirements that could not be met through its COTS solution.  We also find reasonable the Air Force’s evaluation of DSD’s proposed approach.  Finally, because IndraSoft’s objection to the agency’s best‑value determination is premised on the alleged evaluation errors, this line of protest also fails.

The protest is denied.

Susan A. Poling
General Counsel