Global Computer Enterprises, Inc. v. United States

OPINION AND ORDER

SWEENEY, Judge.

This bid protest comes before the court on Defendant’s Motion to Dismiss or, in the Alternative, Motion for Judgment Upon the Administrative Record, and Defendant’s Opposition to Plaintiffs Motion for a Preliminary Injunction and Application for Temporary Restraining Order (“government’s motion and opposition”); Defendant Intervenor’s Memorandum in Support of Intervenor QSS Group, Inc.’s Motion to Dismiss for Lack of Jurisdiction, Opposition to Plaintiffs Motion for Preliminary Injunction and Application for Temporary Restraining Order and, Alternatively, Motion for Judgment on the Administrative Record (“QSS’s motion and opposition”); and Plaintiffs Cross-Motion for Judgment on the Administrative Record and Motion for Permanent Injunctive Relief (“cross-motion for judgment on the administrative record” and “motion for permanent injunctive relief’). Plaintiff Global Computer Enterprises, Inc. (“GCE”) protests the issuance of two modifications to a task order awarded to defendant-intervenor, QSS Group, Inc. (“QSS”), by the United States Coast Guard (“Coast Guard”) to perform software engineering and technical services at the Coast Guard’s Operations Systems Center (“OSC”) in Kearneysville, West Virginia. Specifically, GCE maintains that Modifications P00030 (“Modification 30”) and P00032 (“Modification 32”) to the Systems Engineering and Technical Services (“SETS”) II task order, which involved the provision and maintenance of audit-supporting federal financial management systems, exceeded the scope of the SETS II task order, thereby resulting in an unlawful standalone, sole-source procurement that extended the underlying Information Technology Omnibus Procurement (“ITOP”) II contract beyond its or-

*355 dering period. For the reasons discussed below, GCE’s cross-motion for judgment on the administrative record is granted, GCE’s motion for permanent injunctive relief is granted, the government’s motion and opposition is denied in part, and QSS’s motion and opposition is denied in part. 1

Due to the length of this opinion, the court provides the following table of contents:

I. FACTUAL BACKGROUND. LO CO

A. Audit-Supporting Federal Financial Management Systems t-1-0 CO

1. Nature of Audit-Supporting Federal Financial Management Systems 00 LC CO

a. Definitions. 00 1C CO

b. Regulatory Framework. Q LO CO

2. Market for Audit-Supporting Federal Financial Management System Services and Related IT Work. o zd CO

3. Government Procurement Practices for Audit-Supporting Federal Financial Management Systems Services and Related IT Work CO Ci to

a. Examples of Agency Procurements Outside the Coast Guard. CO Cl CO

b. Recent Coast Guard Procurements. CO Ci Cl

B. The Coast Guard’s OSC. CO Ci Cl

C. The ITOP II Contract. CO G3 <1

1. The Scope of the ITOP II Contract. CO O QO

2. Task Order Provisions Contained Within the ITOP II Contract. CO C5 U3

3. Labor Categories and Qualifications Set Forth Within the ITOP II Contract. O t> CO

4. Limitations Under the ITOP II Contract. H t-CO

5. The SETS I Task Order. H fc-CO

D. The SETS II Task Order and Solicitation. H t-CO

1. The Scope of the SETS II Task Order. CM CCO

a. General Contract Services Under the SETS II Task Order. CO £*• CO

b. System Services Under the SETS II Task Order. CO CCO

i. Functional Area Management, Help Desk Support, and Software Development and Maintenance. s CO

ii. Hardware Maintenance, System Administration, and Database Administration. CO

iii. Network Administration, Data Management, and System Downtime. LO CO

iv. Technical Writing, System Transition, and Computer System Fielding. co cn

v. Application System Training and Technical Field Support co cn

e. OSC System Requirements Under the SETS II Task Order. co -3 cn

i. Automated Aid Positioning System (“AAPS”); Aids to Navigation Information System (“ATONIS”); Integrated-ATONIS (“I-ATONIS”). CO Oí

ii. Automated Mutual Assistance Vessel Rescue (“AMVER”) System. ZD CO

376 iii. Abstract of Operations System (“AOPS”); Training Management Tool (“TMT”); Automated Requisition Management System (“ARMS”); and ASG.

377 iv. Auxiliary Data (“AUXDATA”); Certification and Accreditation (“C & A”); and CASP.

377 v. BelManage ASM Support and Business Intelligence-Enterprise Data Warehouse (“BI-EDW”).

378 vi. CG Help (“CGHELP”) and Coast Guard List Server (“CGLS”).

378 vii. Coast Guard Recruiting Command (“CGRC”) and Configuration Management (“CM”).

*356 viii. Data Center Support; G-0 CITRIX Farm (“CITRIX”); and Configuration Management Plus Client Server (“CMPLUS”). CO

ix. DHS Directory Services (“DIRSERV”) and Disaster Recovery Business Continuity (“DRBC”) Support Services . ? CO

x. Emerging Technologies Technical Team (“ETTT”). t? CO

xi. Electronic Program Management Office (“EPMO”) System/Deepwater Program, FLS, and Geospatial Information System (“GIS”). 05 CO

xii. Housing Management Information (“HMI”) and Local Area Network (“LAN”). o co CO

xiii. Long Range Aid to Navigation Operations Information System (“LOIS”) and MMLD. o 00 CO

xiv. Marine Safety Network (“MSN”); Panorama Business Views (“PB-Views”); Naval and Electronic Supply Support System (“NESSS”); and Enterprise Management Support (“EMS”) . o 00 CO

xv. Point of Presence (“POP”); Business Intelligence-Readiness Management (“BI-RM”); and Shore Asset Management (“SAM”). rH 00 CO

xvi. Ship Arrival Notification (“SAN”) and SLDMB . CM 00 CO

xvii. System Performance Tiger Team (“SPERTT”); Systems Resource Management (“SRM”); Vessel Documentation System (“VDS”); and WEB Services. <M 00 CO

2. Evaluation Factors For Award of the SETS II Task Order . CO 00 CO

E. The Coast Guard’s Audit-Supporting Federal Financial Management Systems and Related Services. 00 CO

1. The Coast Guard’s Unified Mission Support Initiative. CO CO

2. Efforts to Create an Audit-Supporting Federal Financial Management Systems and Related Services Procurement. CO 00 05

3. The August 15, 2007 Sole-Source Bridge Contract to GCE. CO 00 CO

4. The Coast Guard’s August 2007 Solicitation and September 2007 Contract. CO CO o

5. Use of the SETS II Task Order to Transition Audit-Supporting Federal Financial Management Systems and Related Services to the OSC. O 05 CO

a. Modification 30 to the SETS II Task Order. h 05 CO

b. Modification 32 to the SETS II Task Order. N 05 CO

6. GCE Expresses Concern to the Coast Guard. CO 05 CO

II. PROCEDURAL BACKGROUND. CO co -q

A. Proceedings Before the GAO. CO CO -3

B. Proceedings Before The United States Court of Federal Claims (“Court of Federal Claims”) . 00 05 CO

III. LEGAL STANDARDS. CO CO co

A. Bid Protests. co CO co

B. Standing. O o

C. Motion to Dismiss for Lack of Jurisdiction . £*> O DO

D. Judgment on the Administrative Record. vp*. O to

E. Injunctive Relief. ^ O to

IV. DISCUSSION. o CO

A Whether the Court Possesses Subject Matter Jurisdiction. o ^

1. The Purpose of the FASA. ^ o iP^

2. The Plain Language of the FASA. ►pi. o 05

a. An Interpretation of the Scope of a Phrase in One Statute Does Not Control the Interpretation of Identical Language in a Separate Statute . CO o

*357 b. The FASA Only Bars Protests “In Connection With” Either the “Issuance” or “Proposed Issuance” of a Task Order, Not Modifications Thereto.

Alternatively, Even if the FASA Bar Applies, GCE’s Protest Falls Within the Statutory Exception Contained Therein. i-H

Whether GCE Possesses Standing. t — 1 rtf

Whether the Equitable Doctrine of Laches Applies. rH -^1

1. Standards for a Laches Defense. t — t

2. GCE’s Argument That Laches Does Not 03

3. The Government’s and QSS’s Arguments That GCE’s Delay Was Unreasonable.■. 4^ to

4. Neither the Government nor QSS Demonstrates That the Application of Laches Is Appropriate Under the Circumstances Presented in This Case . CO 03

GCE’s Claim That the Coast Guard Violated the CICA. ^ 03

1. The Court Engages in a Two-Part Inquiry to Determine Whether Modifications 30 and 32 Exceeded the Scope of the SETS II Task Order. hO 03 ^

2. Modification 30 Added Systems and Services That Materially Changed the Scope of the SETS II Task Order. t— 03

a. The SETS II Task Order Did Not Contemplate an Unlimited Expansion of Computer System. GO 03

b. Modification 30 Added Audit-Supporting Federal Financial Management Systems, Which Differ Substantially From Those Computer Systems Described in the SETS II Task Order CO

c. Modification 30 Substantially Changed the Type o f Services to Be Performed Under the SETS II Task Order by Adding Audit-Supporting Federal Financial Management Systems_ <D CO

3. A Reasonable Offeror Would Not Have Anticipated That Audit-Supporting Federal Financial Management Systems Under Modification 30 Would Fall Within the SETS II Task Order’s Changes Clause. 4^

4. The Coast Guard’s Issuance of Modifications 30 and 32 to the SETS II Task Order Extended the Ordering Period of the ITOP II Contract.

GCE’s Claim That the Coast Guard Violated the “Rule of Two”.

The Coast Guard’s Actions Prejudiced GCE.

GCE Is Entitled to Judgment on the Administrative Record.

Award of a Permanent Injunction.

1. Success on the Merits.

2. Irreparable Injury.

3. Balance of Hardships.

a. The Coast Guard’s Harms Are Overstated.

b. QSS’s Harms Do Not Outweigh GCE’s Harms.

4. Public Interest.

V. CONCLUSION.461

Appendix of Acronyms.462

I. FACTUAL BACKGROUND 2

A. Audit-Supporting Federal Financial Management Systems

In this protest, GCE alleges that the work it has performed for the Coast Guard, which *358 “involves the provision and maintenance of highly specialized audit-supporting financial management systems using government-certified financial management systems software,” 3 Compl. ¶ 10, was unlawfully shifted to QSS without competition and in violation of applicable statutory and regulatory requirements, id. ¶¶ 10, 32, 49-63. In addition to recounting the facts giving rise to this action, this portion of the court’s decision provides a background of audit-supporting federal financial management systems IT, as well as the nature of and market for this work.

1. Nature of Audit-Supporting Federal Financial Management Systems

a. Definitions

A financial system, as defined by the Office of Management and Budget (“OMB”) in Circular No. A-127 (1993), is an “information system, comprised of one or more applications,” that is used for any of the following: collecting, processing, maintaining, transmitting, and reporting data about financial events; supporting financial planning or budgeting activities; accumulating and reporting cost information; or supporting the preparation of financial statements. Pl.’s App. 262. Such a system

supports the financial functions required to track financial events[ and] provide[s] financial information significant to the financial management of the agency, and/or required for the preparation of financial statements. A financial system encompasses automated and manual processes, procedures, controls, data, hardware, software, and support personnel dedicated to the operation and maintenance of system functions. A financial system may include multiple applications that are integrated through a common database or are electronically interfaced, as necessary, to meet defined data and processing requirements.

Id. The OMB defines a financial management system as “the financial systems and the financial portions of mixed systems necessary to support financial management.” 4 Id. By contrast, a “non-financial system” is “an information system that supports non-financial functions of the Federal government or components thereof and any financial data included in the system are insignificant to agency financial management and/or not required for the preparation of financial statements.” 5 Id.

According to the OMB, financial management in the federal government “requires *359 accountability of financial and program managers for financial results of actions taken, control over the Federal government’s financial resources and protection of Federal assets.” Id. at 263. In order to comply with these requirements, financial management systems “must be in place to process and record financial events effectively and efficiently, and to provide complete, timely, reliable^] and consistent information....” Id. Consequently, the OMB implemented a financial management system policy for the federal government in order

to establish government-wide financial systems and compatible agency systems, with standardized information and electronic data exchange between central management agency and individual operating agency systems, [and] to meet the requirements of good financial management. These systems shall provide complete, reliable, consistent, timely and useful financial management information on Federal government operations to enable central management agencies, individual operating agencies, divisions, bureaus],] and other subunits to carry out their fiduciary responsibilities; deter fraud, waste, and abuse of Federal government resources; and facilitate efficient and effective delivery of programs through relating financial consequences to program performance.

Id. The OMB directed each agency to “establish and maintain a single, integrated financial management system.” Id. Each financial management system must, among other things, comply with an agency-wide financial information classification structure; design effective and efficient interrelationships between software, hardware, personnel procedures, controls, and system data; apply the requirements of the United States Government Standard General Ledger at the transaction level; maintain accounting data in accordance with accounting standards; and conform with existing applicable functional requirements for the design, development, operation, and maintenance of financial management systems. Id. at 263-65.

Additionally, the OMB set forth financial management system design requirements in order to “reflect an agency-wide financial information classification structure....” Id. at 263. Financial management system designs “shall support agency budget, accounting and financial management reporting processes by providing consistent information for budget formulation, budget execution, programmatic and financial management, performance measurement and financial statement preparation.” Id. These systems, the OMB indicated, “shall be designed to provide for effective and efficient interrelationships between software, hardware, personnel procedures, controls, and data contained within the systems.” Id. at 263-64.

b. Regulatory Framework

According to GCE, “highly specific regulations govern[ ] the maintenance of federal financial systems_” Pl.’s Mot. Prelim. Inj. & TRO 5; see also Pl.’s App. 15 (Lucas Deel. ¶ 11 (“Audits of federal financial management systems assess compliance with highly specific requirements.”)). Following a determination that “[f]ederal accounting standards have not been uniformly implemented in financial management systems for agencies,” Congress enacted the Federal Financial Management Improvement Act of 1996 (“FFMIA”), Pub.L. No. 104-208, 110 Stat. 3009-389 to 3009-393 (codified at 31 U.S.C. § 3512 (2006)), in order to, inter alia; provide for consistency of accounting by an agency from one fiscal year to the next, and uniform accounting standards throughout the Federal Government,” Pl.’s App. 209. The definition of “financial system” contained in the FFMIA is identical to the definition contained in OMB Circular No. A-127. See Pl.’s App. 211, 262. Although the FFMIA and OMB Circular No. A127 also contain similar definitions of the term “financial management system,” id. at 211, 262, the FFMIA’s definition was broader. Under the FFMIA, a financial management system also “in-clud[es] automated and manual processes, procedures, controls, data, hardware, software, and support personnel dedicated to the operation and maintenance of system functions.” Id. at 211. According to GCE, the FFMIA, along with other federal laws and regulations, requires that federal executive branch entities submit annual audited financial statements to both the President and Congress. Pl.’s Mot. Prelim. Inj. & TRO 3.

*360 GCE alleges that audit-supporting federal financial management systems services are “provided by a contractor using specialized government-certified software to support a federal agency’s core financial system.” 6 Compl. ¶ 11. An agency’s core financial system, GCE states, “produce[s] audited financial statements of records [, which] are governed by an extensive regulatory and statutory regime specific to federal financial management systems.” Pl.’s Mot. Prelim. Inj. & TRO 4; see also Pl.’s Cross-Mot. J. Administrative R. & Mot. Perm. Injunctive Relief (“Pl.’s Cross-Mot. & Mot. Perm. Inj.”) 16 (“[A]udit-supporting financial management systems are governed by extensive regulatory and statutory requirements[.]”); Pl.’s App. 276-79 (containing “Core Financial System Requirements,” a publication of the Office of Federal Financial Management that lists government-wide accounting standards, laws, and regulations, and provides other guidance related to financial system requirements). OMB Circular' No. A-123 (2004) indicates that “[flederal managers have been subject to ... internal, control reporting requirements for many years,” Pl.’s App. 247, and the Sarbanes-Oxley Act of 2002, Pub.L. No. 107-204, 116 Stat. 745 (codified as amended in scattered sections of 11, 15, 18, 28, and 29 U.S.C.), “served as an impetus for the Federal government to reevaluate its current policies relating to internal control over financial reporting and management’s related responsibilities,” Pl.’s App. 246.

In September 2007, the OMB issued Bulletin No. 07-04, which addresses “Audit Requirements for Federal Financial Statements.” Id. at 213-42. Applicable to “audits of financial statements of executive departments, agencies, and government corporations ... and certain components of these agencies,” OMB Bulletin No. 07-04 “establishes minimum requirements for audits of Federal financial systems.” Id. at 213. Among the provisions set forth within OMB Bulletin No. 07-04 are requirements for annual audits, id. at 218; open, timely, and frequent communication concerning the audit timetable and potential audit findings, such as indications of material misstatements or unsupported amounts in the financial statements, id. at 219; and specific parameters that address the scope of an audit and audit report, id. at 222-32.

2. Market for Audit-Supporting Federal Financial Management System Services ■ and Related IT Work

GCE represents that because audits of federal financial management systems assess compliance with specific statutory and regulatory requirements, “federal agencies use a common set of evaluation criteria to award contracts for federal financial management system IT support services.” Id. at 15 (Lucas Decl. ¶ 11). According to GCE, “[t]wo of the most important criteria in each application are specific experience and technical expertise with federal financial management systems or specially certified core financial management system software.” Id. In this regard, and “[bjecause of the unique and exacting standards for properly collecting, maintaining, and producing audited financial information,” Pl.’s Mot. Prelim. Inj. & TRO 5, GCE states that audit-supporting federal financial management systems services and related IT work constitute “a small and sharply defined niche market separate from the broader market for general IT support and software development work,” id. at 5-6; see also AR 2576-77 (identifying [ ... ] companies that, based upon “[m]arket research and past experience!],] ... possess the re *361 quired technical expertise necessary” to manage the Coast Guard’s Financial Center information systems). 7 But see QSS Group’s Opp’n Pl.’s Mots. (1) J. on the Administrative R., (2) Perm. Inj., & (3) Supplement the Administrative R., & Reply Supp. QSS Group’s Mot. Dismiss & Alternatively, J. Administrative R. (“Def.-Intervenor’s Opp’n & Reply”) App. Ex. E (Supplemental Decl. William R. Bowen (“Bowen Supp’l Decl.”) ¶ 11 (“During all my years of experience in Federal Government procurement, I have never encountered any small ‘niche market’ of audit-supporting federal financial management systems. I would have expected to have seen evidence of such a market, if it existed.”)).

GCE maintains that contractors must “have experience with FSIO-certified software, knowledge of the regulatory environment in which audited financial systems operate, and subject matter expertise in accounting, budgeting, and procurement.” Pl.’s Cross-Mot. & Mot. Perm. Inj. 16. Consequently, according to GCE, these contractors “possess distinct expertise,” Pl.’s Mot. Prelim. Inj. & TRO 5; accord Compl. ¶ 14 (“Government contractors capable of providing federal financial systems work possess a distinct set of exper-tise_”). During oral argument on GCE’s motion for a preliminary injunction and temporary restraining order, GCE explained:

Federal Financial Systems [work] requires different expertise and is subject to different regulatory requirements than other kinds of information technology work. This work is performed by different companies. When you put a solicitation out, different groups of companies bid depending [upon] whether it is one of these solicitations for Federal Financial Systems work or other kinds of IT work.

Prelim. Inj. Hr’g Tr. 6:14-22, Mar. 26, 2008. GCE alleges that this expertise includes:

a. A thorough knowledge of the federal regulatory and statutory scheme with which those audited financial management systems must comply;

b. Specific subject matter expertise in federal accounting, budgeting, finance, procurement, and related fields;

c. Technical expertise in working with government-certified commercial-off-the-shelf (“COTS”) software tools specific to federal financial systems work; [and]

d. A pool of employees who have experience with configuring and maintaining audited financial systems.

Compl. ¶ 14. According to GCE, “[o]nly a limited pool of companies have the requisite expertise to participate in this specialized field as prime contractors.” Pl.’s Mot. Prelim. Inj. & TRO 6; see also Pl.’s App. 14 (Lucas Decl. ¶ 6 (stating that a “small number of contractors in the federal financial management systems market ... have the specialized experience and expertise needed to win work as a prime contractor to support audited financial management systems”)). Members of this small group of contractors, GCE alleges, “regularly team together to compete for and perform contracts to implement and provide IT support for federal financial systems of record.” Compl. ¶ 15; accord Pl.’s App. 14 (Lucas Decl. ¶ 7). GCE states that it “specializes in providing information technology services to federal agencies in the implementation and ongoing support of federal procurement and FSIO-compliant financial management systems,” Pl.’s App. 2 (Muslimani Decl. ¶8), and, as such, is part of a niche market, Compl. ¶ 15. GCE represents that “only those contractors in the niche market for financial management systems work compete for contracts in that area, while those who do not have a specialty in financial management systems do not.” Pl.’s App. 20 (Lucas Deck ¶24); see also id. at 14 (Lucas Decl. ¶ 8 (“[T]he number of companies that can bid successfully as a prime contractor for *362 federal financial management systems work is generally limited to a few-”)).

The specialization of audit-supporting federal financial management systems and related services, as well as the contractors providing those services, is illustrated by the federal government’s recent plans to certify Shared Service Providers (“SSPs”), 8 which are “capable of providing support services for federal financial systems in accordance with accounting, business, and technical requirements that are standardized across the federal government.” Id. at 3 (Muslimani Decl. ¶ 13). The OMB established the Financial Management Line of Business (“FMLoB”), which is managed by both the FSIO and the OMB, id. (Muslimani Decl. ¶ 12), in order “to guide the acquisition of and business processes for federal financial management systems,” id. at 13 (Lucas Decl. ¶ 3). One goal of the FMLoB, which is “recognized by the federal government and the government contracts industry as an independent line of business,” id. at 3 (Muslima-ni Decl. ¶ 12), is “to move federal agencies towards procuring financial management systems IT support work from specially certified Shared Service Providers who are capable of supporting financial management systems in accordance with standardized, government-wide business and technical requirements,” id. at 13 (Lucas Decl. ¶ 4 (citation omitted)).

In order to achieve that objective, the FSIO developed a Due Diligence Checklist to be utilized by the OMB, the FSIO, and “customer agencies to assess the abilities of potential and current [SSPs] in several areas, including but not limited to past performance, overall capabilities, and experience in ... operating a customer-focused, modern financial operation.” Id. at 878. The Due Diligence Checklist is comprised of five parts. Four of these parts, which address the minimum criteria for an SSP candidate to become qualified to offer SSP services and for an existing SSP to remain compliant, determine: (1) whether an SSP candidate should have the authority to operate as an SSP; (2) whether an existing SSP remains in compliance with the Due Diligence Checklist; (3) which SSP candidates “are most qualified to serve as an SSP and to meet the goals and objectives of the FMLoB initiative”; and (4) the stability and capability of SSP candidates. Id. The fifth part “is used to better understand the capabilities of the SSP and assist Agencies in choosing between multiple SSP candidates.” Id. Although the FSIO “has announced plans to certify FMLoB Shared Service Providers ... capable of providing support services for federal financial systems in accordance with accounting, business, and technical requirements that are standardized across the federal government,” the FSIO has not yet released an FMLoB solicitation. Id. at 3 (Muslimani Decl. ¶ 13); accord id. at 13 (Lucas Decl. ¶ 4). Nonetheless, GCE anticipates that federal agencies will procure work from certified FMLoB SSPs in the future because “[s]ome agencies already require bidders for financial management system work to submit this ‘Due Diligence’ checklist as part of the competi-tion_” Id. at 13 (Lucas Decl. ¶ 4).

3. Government Procurement Practices for Audit-Supporting Federal Financial Management Systems Services and Related IT Work

While federal agencies may eventually procure audit-supporting federal financial management systems services and related IT work from certified FMLoB SSPs in the future, the prior and current government procurement practices for this type of work warrant discussion. GCE states that “[consistent with the facts that federal financial management systems IT work is unlike other kinds of IT work, and that different groups of contractors compete for the two kinds of work,” PL’s Mot. Prelim. Inj. & TRO 6; supra Part I.A.2, federal entities “consistently bid out their IT work for their audited financial systems separately from their mission-focused or other IT work,” Pl.’s Mot. *363 Prelim. Inj. & TRO 6. For example, GCE states that “[rjequirements regarding FSIO-certified software products, subject-matter expertise and technical expertise specifically relating to federal financial management systems are regularly included in federal financial management system IT support contracts.” Pl.’s App. 42 (Winslow Deel. ¶ 45). As a result, these specifications, according to GCE, “would not ... generally be required for support services for mission or administrative systems support work.” Id.

a. Examples of Agency Procurements Outside the Coast Guard

GCE states that the Coast Guard has “never bid” federal financial systems work and other types of IT work together in one solicitation. Prelim. Inj. Hr’g Tr. 6:23-25. In fact, GCE indicates that the Coast Guard kept “this work ... on parallel and separate tracks,” a course of conduct that it states comported with “a universal practice among virtually all federal agencies.” Id. at 6:25-7:4. In support of this contention, GCE “identified seventeen examples of ... solicitations from 1990 through 2008 that called for specialized expertise or otherwise made clear the highly specialized nature of these financial management systems procurements.” Pl.’s Mot. Prelim. Inj. & TRO 7. Of those seventeen, GCE represents that “at least fourteen federal entities issued competitive solicitations for audited financial management systems IT work separate from any mission-focused or other kinds of IT work.” Id. at 6; see also id. at 17 (indicating that procurements for financial management systems work after 2005 “have also been limited in scope to financial management systems, have excluded mission-related and other IT work, and have required technical expertise and past performance experiences specific to financial management systems”). The entities issuing such solicitations include the Agency for International Development (“AID”), the Environmental Protection Agency (“EPA”), the Federal Communications Commission (“FCC”), the Office of Personnel Management (“OPM”), the Pension Benefit Guaranty Corporation (“PBGC”), the National Aeronautics and Space Administration (“NASA”), the United States Secret Service (“USSS”), as well as the Departments of Agriculture (“USDA”), Commerce (“DOC”), Energy (“DOE”), Homeland Security (“DHS”), Housing and Urban Development (“HUD”), the Interior (“DOI”), Justice (“DOJ”), and Labor (“DOL”). Pl.’s App. 16-18 (Lucas Deck ¶¶ 14-16).

For example, a 1990 solicitation issued by the USDA sought an integrated financial management information system in which “management and program accounting system functions shall be fully integrated with a core financial system” and in compliance with all Joint Financial Management Improvement Program (“JFMIP”) functional and interface requirements. Id. at 302. Similarly, the AID issued a solicitation in 1999 in which it sought “to explore ways to improve agency financial management” and to invite “all firms which offer financial management system software for the Federal environment” to demonstrate a product that would comply with JFMIP core requirements and AID-speeifie requirements. Id. at 307. Other solicitations GCE identifies that demonstrate separate procurements of audit-supporting federal financial management systems work include:

• A 2000 solicitation, see id. at 311-14, wherein NASA sought the acquisition and implementation of “Core Financial software to serve as the backbone for other functional areas. Core Financial consists of standard general ledger, accounts receivable, accounts payable, budget execution, purchasing, fixed assets, project accounting, and cost allocation,” id. at 312.

• A 2000 solicitation from the DOE, see id. at 315-16, that sought “to replace its legacy financial systems with a single integrated system that meets current government standards,” id. at 316.

• A 2003 solicitation from the DOC, see id. at 317-23, that involved the agency’s Oracle-based Commerce Administrative Management System, which was composed of a standard Core Financial System that “capture[s] financial transactions and/or support[s] ledger improvements,” id. at 318, 321.

*364 • A 2004 solicitation from the DOI, see id. at 324-25, that sought systems integration and “deployment of a unified financial management system ... [that] will be able to eliminate multiple bureau-level management information and desktop applications,” id. at 324-25.

• A 2005 solicitation from the DOJ, see id. at 326-28, that sought to improve financial performance through a unified financial management system, id. at 327. The scope of work included providing functionality in several core financial management system areas, namely core financial management, cost management, receivable management, funds management, payment management, reporting, and general ledger management. Id. at 326-28.

• A 2005 solicitation, see id. at 32ÍM5, wherein the PBGC sought an overhaul of its financial and accounting programs that would replace current performance accounting, trust accounting, and financial reporting ledgers with “an accounting classification structure that is Oracle Federal Financials based,” id. at 330-31.

• A 2005 solicitation from the USDA, see id. at 346-63B, that sought “[t]o address challenges and opportunities in the rapidly changing federal financial management and technology environment” and “to improve financial management performance by efficiently providing USDA agencies with a modern, core financial management system that both complies with federal accounting and systems standards and provides maximum support to the USDA mission,” id. at 347.

• A 2006 solicitation from the EPA, see id. at 364-77, that sought the implementation of an agency-wide financial management system that “will result in an integrated solution composed of a COTS product or suite of products. The core financial system will be JFMIP-eerti-fied,” id. at 366; see also id. at 372 (containing special contract requirements reserving the EPA’s right to issue task orders for “services required to implement new, federally-mandated requirements for federal financial management systems”).

• A 2006 solicitation, see id. at 378-92, wherein the USSS sought “expert technical and operational knowledge” of various financial software applications “in order to develop and enhance interoperability of these products ... while ensuring security and enhancing reliability,” 9 id. at 380. Contractors would be required to provide “software development and maintenance services, training, production operations services!,] and help desk services-” Id. at 382.

• A 2006 solicitation from the HUD, see id. at 393-423, that sought the “re-plaeefment of] the current core financial system with a solution that includes all financial management organizations and financial systems that provide financial information to HUD’s consolidated financial statements,” id. at 418. One of the system integration objectives HUD identified was a single, scalable, integrated financial management system that “processes and reports all core financial events enterprise-wide from point of origin to point of dissemination.” Id. at 420.

• A 2007 solicitation, see id. at 424-36, wherein the DOI sought “an industry partner(s) to assist providing support to current and potential client agencies of the Oracle Federal Financials accounting system,” id. at 425, as well as a contractor with: (1) “in-depth knowledge of Oracle Federal Financial”; (2) experience “integrating other Oracle applications ... with the core Oracle Federal Finan- ' cials accounting system”; and (3) “[k]nowledge of Federal accounting concepts and standards, Chief Financial Officer (CFO) Act, (GRPA), Government Management Reform Act (GMRA), Federal Information Security Management Act (FISMA)[,] and relevant [OMB] circulars and bulletins on financial accounting and internal and system controls,” id. at 429.

*365 • A 2007 solicitation from the FCC, see id. at 437-50, that focused upon “the replacement of those processes and systems that are considered a consolidated ‘core’ based on FCC financial operations and FSIO standards,” id. at 439. The FCC indentified numerous objectives, which included, among other things, establishing an “integrated core financial management system that meets FSIO and FCC-speeific requirements as well as the financial management system requirements set forth in Section 7 of OMB Circular A-127” and improving “financial processes that complement financial management systems operational efficiency and effectiveness[.]” Id. at 440.

• A 2007 solicitation from the DHS, see id. at 451-70, that sought to establish the “Oracle Baseline as a services platform to support DHS components migrated from their existing financial management systems,” id. at 455, and to transition components onto the Transformation and Systems Consolidation Oracle Baseline “to support the Department’s financial management systems consolidation effort,” id. at 456.

• A 2007 solicitation, see id. at 471-91, wherein the OPM sought to “replace ... two core financial systems with a single, integrated financial system under the Financial Systems Modernization Project (FSM),” id. at 478, and required the contractor “to have a comprehensive knowledge of federal regulations, policies, and guidance that will impact the design and implementation of the FSM solution,” id. at 482. This solution included compliance with forty-eight publications related to financial management systems, core financial system requirements, financial and accounting services, and information technology systems. Id. at 482-84.

• A 2008 solicitation from the DOL, see id. at 492-504, that sought to migrate its Accounting and Related Systems mainframe accounting system “to a new core financial management system” that would be conducted “in compliance with all applicable financial systems regulations and guidance,” id. at 493. The solicitation sought the services of a federal or commercial financial management SSP in the following areas: (1) technology hosting and administration services, which included providing the IT infrastructure; (2) application management services, which included providing software and services for running and managing financial management software, as well as feeder systems that provided data to the financial management software; and (3) system implementation services, which included services to assist with the migration of current financial management operations to the financial management SSP environment. Id. at 495.

According to GCE, these solicitations contained “specific and detailed expertise requirements,” including specific regulatory and compliance requirements. Perm. Inj. Hr’g Tr. 16:18-20, May 28, 2008. GCE proffers these examples because it believes that these solicitations reveal a “practice across the Federal Government ... [of] what a typical solicitation for financial systems IT work looks like and what it contains.” Id. at 16:11-14. The government acknowledges that federal agencies “may very well be procuring other IT systems separately” from financial management IT systems. Prelim. Inj. Hr’g Tr. 30:11-12.

GCE notes that it is aware of “only one counterexample ... where an agency attempted to procure IT work for both financial- and non-finaneial systems in a single, integrated solicitation”: a 2000 Department of Veterans Affairs (“VA”) competition valued at over $400 million that was known as the Core Financial and Logistics System (“CoreFLS”). 10 Pl.’s Mot. Prelim. Inj. & *366 TRO 6-7; accord Pl.’s App. 18 (Lucas Decl. ¶ 17). GCE suggests that examination of the VA’s solicitation is “very instructive” because it “combined financial systems IT work and other kinds of IT work. It did so very, very explicitly.” 11 Prelim. Inj. HFg Tr. 27:6-9.

b. Recent Coast Guard Procurements

According to GCE, “the Coast Guard has competed IT support services work for its financial management systems independently of its other IT work_” Pl.’s App. 20 (Lucas Decl. ¶ 25); see also Compl. ¶ 13 (alleging that the Coast Guard’s solicitations for audit-supporting federal financial management systems services and related IT work have, “[sjinee at least 1995, ... been issued separately and distinctly from solicitations for mission and administrative systems work”). It notes that the Coast Guard possesses an “eight year history of procuring IT services on separate tracks for financial and non-financial systems work,” Perm. Inj. Hr’g Tr. 13:19-22, during which time the agency “procured federal financial systems IT support services through competitions restricted in scope to financial systems,” Pl.’s App. 9 (Muslimani Decl. ¶ 35). GCE represents that it is unaware “of any instance in which the Coast Guard has mixed IT support services for JFMIP/FSIO-eompliant financial systems management work with mission and administrative systems work [from] ... 1995 to the present.” Id. (Muslimani Decl. ¶ 36).

GCE “has won competitive awards to provide federal financial management systems IT support services to the Coast Guard since 2000.” Id. at 33 (Winslow Decl. ¶ 3). In 2000, the Coast Guard awarded to GCE a task order related to the replacement of an obsolete financial information system with a new system based on Oracle Federal Financials. Id. (Winslow Decl. ¶¶ 4-5); see also id. at 697-717 (containing the contract). One year later, the Coast Guard competitively awarded to GCE a contract for software maintenance of its financial acquisition system. Id. at 34 (Winslow Decl. ¶ 8); see also id. at 718-28 (containing the contract). In 2002, GCE won a solicitation for work designed to upgrade the Coast Guard’s enterprise financials systems, id. at 34 (Winslow Decl. ¶ 9), and it was awarded a contract in 2004 to perform continued maintenance of the Coast Guard’s Core Accounting System (“CAS”), which included “resolution of software bugs, performing upgrades, and configuring the systems in accordance with changing federal financial accounting regulations and guidelines,” 12 id. at 34-35 (Winslow Decl. ¶ 10). Additionally, in 2005 the Coast Guard awarded to GCE a contract to provide soffcwai’e maintenance for the Coast Guard’s Finance and Procurement Desktop and Contract Information Management System programs. Id. at 35 (Winslow Decl. ¶ 12).

B. The Coast Guard’s OSC

In 1991, the Coast Guard established the OSC, a “government-owned, contractor-operated software development facility.” AR 3014. The OSC was a field unit of the Coast Guard Chief Information Officer (“CIO”). Id. at 304. “From inception, the OSC organizational model has been based on government oversight of an in-house contracting staff.” Id. Its primary function is to provide full life cycle support 13 for operationally-focused Coast Guard Automated Information *367 Systems that supported the Coast Guard’s five strategic missions. 14 Id. at 532-33, 1230. In this capacity, the OSC “engineers, develops, fields, maintains, operates[,] and provides user support for Coast Guard enterprise information systems. Such systems include navigation systems, electronic systems, sensor systems[,] etc.” Id. at 3017. “When the OSC was established, it was a data center with five operational systems.” Id. at 280. Shortly thereafter, it began running enterprise systems. Id.

In July 2000, the OSC was designated the “Systems Development Center for the Coast Guard.” Id. at 292. This designation “spearheaded the change of the OSC from a data center only to a Center of Excellence focused on Systems Development along with data floor operations.” Id. at 3014. As a System Development Center, the OSC “specifically focuses on systems with Coast Guard-wide scope.” Id. at 305. To that end, the OSC developed a “thorough process for vetting requests for system support to ensure that those systems brought into their charge have an enterprise-level focus, or support mission critical to Homeland Seeurity[,] as well as having a strong and effective business sponsorship.” Id. The OSC’s function was subsequently narrowed from a ‘“systems’ development center to a ‘software’ development center” out of a recognition that Coast Guard “ ‘systems’ development encompassed much more than software, which was the OSC’s area of expertise.” Id. at 804. In August 2004, the OSC was renamed the Software Development Center, which “provides project management expertise to all enterprise application development to ensure standards are followed and products are aligned with the Enterprise Architecture.” 15 Id. at 304-05.

Since 2000, the OSC “has become an established software engineering center for enterprise applications providing standardized lifecycle development processes, a highly productive system engineering and software development performance environment, and an efficient use of government resources in managing contractor performance.” Id. at 3014. When it was established, the OSC employed forty-five full-time personnel who supported five mission-critical information systems. Id. at 280, 532. By 2004, over 340 full-time personnel “operat[ed], maintainfed], developed], and/or provid[ed] user support for over 40 enterprise-wide information systems.” Id. at 532, 1230; cf. id. at 280, 305 (indicating over fifty-one systems). In 2005, the OSC was considered “the Coast Guard’s largest and most successful Government Owned-Contractor Operated facility.” Id. at 2911.

The OSC has utilized four major contract vehicles for supporting Coast Guard mission areas since it was commissioned in 1991. Id. at 280, 305. The first contract vehicle, the Operations and Maintenance Contract (“O & M”), expired in 1996 and was succeeded by O & M II. Id. at 305. During performance of the O & M II contract, the number of systems at the OSC increased from five to approximately twenty-four. Id. at 306. The third and fourth contract vehicles, the SETS I and SETS II task orders, were competed and issued under the Department of Transportation (“DOT”) ITOP II contract. 16 Id. at 306, 497.

C. The ITOP II Contract

The ITOP II contract was a multiple-award, indefinite-delivery/indefinite-quantity (“ID/IQ”) GWAC issued in 1999 with a base contract period of seven years. Id. at 4864; accord Pl.’s App. 535, 543. It contained provisions for firm fined-priee, 17 eost-plus-fixed- *368 price, cost-plus-award-fee, 18 time and materials, 19 and fixed-price-award-fee 20 task orders. 21 AR 4747. Awarded to thirty-five large, small, and small-disadvantaged businesses, the ITOP II contract expired on January 13, 2006, thereby precluding the placement of additional orders after that date. Id. at 4864. Existing task orders under the ITOP II contract, however, could “have a performance period of five years beyond the expiration of the ITOP II GWAC.” Pl.’s App. 543.

1. The Scope of the ITOP II Contract

The ITOP II contract was designed “to provide federal agencies and the Department of Defense with Information Technology (IT) integrated solutions to include technical services, hardware and software.” Id.; accord AR 497. Its Statement of Work (“SOW”) indicated that the ITOP II contract was “intended to cover the gamut of IT efforts,” AR 4711; see also id. at 4763 (indicating that the ITOP II contract presented a “wide diversity of work possible”), and identified three “primary functional areas” along with examples of the types of tasks included under each area, id. at 4711; see also id. at 4864 (stating that the ITOP II contract “divided the range of available IT solutions into three functional support areas”). These three functional areas included: (1) Information Systems Engineering (“ISE”); (2) Systems Operations and Management (“SOM”); and (3) Information Systems Security Support Services (“ISS”). Id. at 4711-12. Together, the three functional areas “provide[d] the flexibility and the wide range of technical and/or contracting resources necessary to help with meeting all Information Technology program requirements).” 22 Pl.’s App. 543.

The first functional support area, ISE, “ad-dresse[d] the system life cycle needs for information and computing resources at all organization levels.” AR 4713. Examples of tasks incorporated under ISE included:

(1) IT Strategic Planning, Program Assessment, and Studies; (2) Business Process Reengineering (BPR); (3) Software Life Cycle Management (SLCM); (4) Software Engineering; and (5) Software Maintenance and Licensing[;] (6) ... Support Electronic Commerce (EC)/Electronic Data Interchange [ (EDI) ]; (7) Independent Verification and Validation; (8) IT Research and Developments and (9) Other ISE Tasks. 23

Id. (footnote added). The second functional support area, SOM, “addresse[d] the overall system operations and management needs for information and computing resources at all organizational levels.” Id. at 4720. Examples of tasks incorporated under SOM included:

(1) Office Automation/Help Desk; (2) Network Support; (3) Computer Center Technical Support Services; (4) Media/Learning Center Support; (5) Tele *369 communications Support; (6) Seat Management; (7) Independent Verification and Validation; (8) Acquisition] and manage[ment of] software maintenance and/or software licenses from 3rd party sourees[;] and (9) Other [SOM] Tasks. 24

Id. (footnote added). The third functional support area, ISS, “addresse[d] the security of information and computing resources at all organizational levels.” Id. at 4730. Examples of tasks incorporated under ISS included:

(1) Mainframe Automated Information Security Systems; (2) Disaster Recovery, Continuity of Operations, and Contingency Planning; (3) Computer Security Awareness and Training; (4) Computer Security Incident Response; (5) Virus Detection, Elimination, and Prevention; (6) Computer Security Plan Preparation; (7) Certification of Sensitive Systems; (8) Quantitative Risk Analysis of Large Sensitive Systems; (9) Security for Small Systems, Telecommunications, and Client Server; (10) Hot-site, Cold-site Services; (11) Independent Verification and Validation; (12) Acquisition] and manage[ment of] software/hardware maintenance and/or software licenses from 3rd party sources[;] and (13) Other ISS Tasks.

Id. The ITOP II contract SOW indicated that the contractor was required to provide resources to support other ISE, SOM, and ISS tasks “that may not have been specifically mentioned.” Id. at 4720, 4729, 4736. It also stated, along with previously discussed ISE, SOM, and ISS tasks, that the contractor “shall be capable of providing the broad range of IT services and keep current with emerging technologies” because “[t]he contract [was] intended to cover all types of IT services [and it] would be impossible to identify all requirements and/or anticipate how technology will evolve over the life of the contract....” Id.

The ITOP II contract SOW indicated that “[u]nder any of the three functional areas, a task order may be used to acquire hardware/software that is integral to the services being provided.” Id. at 4712. It contained a nonexhaustive list of examples of envisioned hardware/software components, including network devices, switches, routers, bridges, hubs, protocol translators, models, cabling, wiring closet hardware, wireless access devices, IT infrastructure hard/software utilities, CASE tools (examples of which included Oracle Case and Netscape), personal computers, servers, printers, CD-ROMs, COTS items, and general supplies. Id.; see also id. at 4766 (noting that these are “examples of items that can be obtained”). The ITOP II contract SOW noted that the ITOP II contract was not intended to “become a shopping center” for an endless supply of hardware and software acquisitions. Id. at 4765. Rather, the ITOP II contract was designated as a “solutions based contract” in which any hardware or software “must be considered to be critical and related to the services being acquired under the Task Order.” Id. at 4766.

2. Task Order Provisions Contained Within the ITOP II Contract

The ITOP II contract provided that “[a]ll [task orders] are subject to the terms and conditions of the contract. In the event of conflict between a [task order] and the contract, the contract will take precedence.” Id. at 4747; see also id. at 4771 (indicating that the contract shall control in the event of a conflict between a delivery order or task order). The ITOP II contract did not require that task orders be issued competitively. Id. at 4749. Instead, task orders “may be issued on either a competitive or noncompetitive basis,” subject to the terms of the ITOP II contract. Id.

The government intended “to compete all [task orders] among the contractors awarded a contract "within the designated functional area.” Id. at 4748. However, awardees were not necessarily given an opportunity to be considered for a particular task order if the contracting officer determined that:

(1) The agency need for such supplies or services is of such urgency that providing *370 such opportunity would result in unacceptable delays;

(2) Only one such contractor is capable of providing such supplies or services required at the level of quality required because the supplies or services ordered are unique or highly specialized;

(3) The order should be issued on a sole source basis in the interest of economy and efficiency as a logical follow-on to a [task order] already issued under the contract or through exercise of option periods specified in the original [task order], provided that all awardees were given fair opportunity to be considered for the original [task order]; or

(4) It is necessary to place a Task Order to satisfy a minimum guarantee....

Id. The contracting officer’s “selection decision on each [task order] shall be final and shall not be subject to the protest or disputes provisions of the contract, except for a protest that the [task order] increases the scope, period, or maximum value of the contract.” Id. Although the task order “methodologies explained [in the ITOP II contract] represent the Government’s initial approach to Task Order issuance, hopefully, through Government and Contractor cooperation and innovation, these methodologies will regularly evolve to incorporate lessons learned and to become more efficient and effective.” Id. at 4748-49.

Additionally, the ITOP II contract placed time limitations upon the performance of task orders in accordance with FAR § 52.216-18, which was incorporated by reference:

a. No task order shall exceed a 5 year period of performance.

b. The period of performance, delivera-bles, and milestones shall be specified in each [task order]. No [task order] shall be issued after the date for placement of task orders as cited in Section I, FAR 52.216-18, “Ordering[.]”

Id. at 4739. Pursuant to FAR § 52.216-18, the ITOP II contract set forth the following ordering clause, which addressed each contract line item number (“CLIN”):

(a) Any supplies and services to be furnished under this contract shall be ordered by issuance of Delivery Orders or Task Ordei’s by the individuals or activities designated in the Schedule. Such orders may be issued as follows:

CLINs Ordering Period

All CLINs Seven (7) years from date of contract execution;

Id. at 4771. Delivery or performance “shall be made only as authorized by orders issued in accordance with the Ordering clause.” Id. at 4772.

Additional contract clause provisions contained within the ITOP II contract made the determination by the Government Fee Determination Official of an award fee earned both binding and “not ... subject to appeal under the ‘Disputes’ clause or to any board or court.” Id. at 4774. Furthermore, the ITOP II contract required that “[e]aeh employee of the Contractor shall be a citizen of the United States of America, or an alien who has been lawfully admitted for permanent residence ... or who presents other evidence from the Immigration and Naturalization Service that employment will not affect his/her immigration status.” Id. at 4776.

3. Labor Categories and Qualifications Set Forth Within the ITOP II Contract

The ITOP II contract set forth twenty-four labor categories and qualifications, ranging from ITOP II Program Manager to Imaging Specialist. Id. at 4779-83. The descriptions of these labor categories provided the scope of various responsibilities expected to be encompassed under the ITOP II contract. For example, a Computer System Analyst, among other things, “review[ed] computer software possessing a wide range of capabilities, including numerous engineering, business, and records management functions” and provided “support for the installation, testing, implementation, and ongoing maintenance of the hardware/software....” Id. at 4779. A Systems Engineer, as part of his or her work, “[a]pplie[d] software, hardware, and standard! ] information technology skills in the analysis, specification, development, integration, and acquisition of systems for information management applications” *371 and ensured that those systems were “compliant with standards for open systems architectures, reference models, and profiles of standards_” Id. at 4780. An Information Systems Engineer, among other things, “[e]valuate[d] analytically and systematically problems of workflow, organization, and planning and developed] appropriate corrective action,” as well as developed and applied organization-wide information models to design and build integrated, shared software and database management systems. Id. at 4781. It is noteworthy that none of these labor categories or job qualifications specifically referenced knowledge or expertise in audit-supporting federal financial management systems. Cf. id. at 4780 (describing a functional expert in a particular subject matter who “[pjossesses requisite knowledge and expertise so recognized in the professional community that the Government is able to qualify the individual as an expert in the field for an actual [task order]”).

4. limitations under the ITOP II contract

The ITOP II contract also included a provision governing a contractor’s exclusion from future government contracts. Id. at 4761-62. Because work performed under the ITOP II contract “may [have] provide[d] the Contractor with access to advance information about future Government procurement, which information is not generally available to other persons or firms,” the ITOP II contract imposed several restrictions upon the contractor’s ability to participate in future competitions “in order to prevent a potential bias, unfair, competitive advantage, or other potential conflict of interest_” Id. at 4761. For example, the contractor was excluded from, among other things, competition for, or award of, any government contract “which call[ed] for the evaluation of system requirements, systems definitions, or other products developed by the Contractor under this contract” or “which call[ed] for the construction or fabrication of any system, equipment, hardware, and/or software for which the Contractor participated in the development of requirements or definitions pursuant to this contract.” 25 Id. However, these restrictions did “not exclude the Contractor from performing work under any amendment or modification to this contract or from competing for an award for any future contract for work which is the same or similar to work performed under this contract,” and the government reserved the right to waive any of these provisions “if deemed in the best interest of the Government.” Id. at 4762.

5. The SETS I Task Order

As noted above, the third and fourth contract vehicles utilized by the OSC were competed and issued under the ITOP II. See swprn Part I.B. The third contract vehicle, the SETS I task order, was competitively awarded to QSS in July 2001, with the final option expiring in June 2005. AR 497. During the four-year base and option periods under the SETS I task order, the OSC grew from supporting twenty-four critical, mission-essential systems to forty-one systems. Id. at 306; cf. id. at 497 (stating that the OSC began with twenty-one critical, mission-essential systems).

D. The SETS II Task Order and Solicitation 26

In 2004, the Coast Guard identified a “need to provide all supplies and services required to support Information Technology (IT) functions and equipment hosted by” the OSC. Id. at 497. Those functions included:

primary software development and software maintenance activities, but also include[d] the software development and maintenance support functions such as: project management; software engineering; system life cycle management review and audits; quality assurance; configuration management; security; hardware maintenance and systems integration; da *372 tabase administration; system administration; network administration; database management; computer operations; technical writing; computer system fielding; system training; technical field support; data center analysis and capacity planning; and disaster recovery business continuity.

Id. The Coast Guard analyzed “potential contract vehicles for the SETS re-compete” in order to determine a “ ‘best fit’ recommendation for the anticipated tasking at [the] OSC.” Id. at 503. After researching various government contract vehicles, the Coast Guard determined that “[t]he opportunity to use a GWAC or Multiple Award Contract (MAC) was attractive since this was a prime example of an acquisition streamlining technique as opposed to a full and open competition.” Id. at 503-04. Utilizing a GWAC vehicle, the Coast Guard reasoned, “would be in place with a pool of the best-qualified vendors. In short, a competed infrastructure of qualified companies, known to have the technical capabilities would be in place, with an added level of competition among eligible contractors. Selection procedures are flexible, efficient, and less susceptible to protest.” Id. at 504. Ultimately, after researching nineteen contract vehicles, the Coast Guard determined that the ITOP II contract would “best suit [the] OSC’s needs based on criteria such as the number of eligible [Small Business Administration section] 8(a) companies, available ceiling over a 5-year period, support for a performance based statement of work, suitability in supporting a 5-year contract, references, analysis of labor rates, and customer service.” Id.

On March 3, 2005, the Coast Guard issued a Task Order Request for Proposal. (“RFP”) under the ITOP II contract in “Functional Areas 1 and 2,” id. at 512, ISE and SOM, respectively, which it noted were the functional areas that “represent the majority of services/support necessary at the OSC,” id. at 503; see supra Part I.C.l. As a “follow-on to replace the existing four-year task order,” AR 498, the Coast Guard “anticipated that this competition wül be among eligible 8(a) firms under the GSA ITOP II contract,” id. at 503. Specifically, the SETS II acquisition plan listed “five qualified [section] 8(a) firms eligible to compete for providing the required services,” id., and indicated that the solicitation would be competed among these five firms, 27 id. at 504; cf. id. at 512 (stating that the SETS II task order would be competed among seven eligible 8(a) contractors, one of which was QSS). The SETS II task order solicitation would be evaluated in accordance with FAR Part 16.505, id. at 512, and would be awarded on a combination fixed-price and cost-plus-award-fee basis, id. at 532. Its period of performance was five years, including a one-month phase-in period, an initial six-month base period, four one-year option periods, and a final five-month option period. Id. at 533.

1. The Scope of the SETS II Task Order

The SETS II task order Performance Work Statement (“PWS”) indicated that the purpose of the task order was to obtain IT systems engineering and technical services to support the OSC. Id. at 532. According to Patricia A. Thompson, Chief of the Office of IT Systems and Infrastructure at the Coast Guard, the strategy for the SETS II task order “was to have one contractor provide all development and maintenance services for all of the systems at OSC, as well as allow for the growth in the number of systems supported during the term of the task order.” Def.’s Mot. Dismiss or, Alternative, Mot. J. Administrative R. & Def.’s Opp’n Pl.’s Mot. Prelim. Inj. & Application TRO (“Def.’s Mot. & Opp’n”) Ex. 3 at 3 (Decl. Patricia A. Thompson (“Thompson Dec!.”) ¶ 4). A “single contractor approach ... ensure[d] that there would be a consistent enterprise focus on all development work and not put OSC in the position of managing multiple contracts *373 with various vendors[,] which is counter productive to managing from an enterprise perspective.” Id.

The contractor was required to demonstrate “[appropriate systems engineering technical proficiency and experience,” AR 501, in order to “provide software engineering and technical services that apply to existing and future computer systems and communications networks designated by the OSC for SETS II support under this Task Order,” id. at 532. Specifically, the SETS II task order PWS indicated that the contractor would

provide software engineering and technical services that apply to existing and future computer systems and communications networks designed by the OSC for SETS II support under this Task Order. 28 The Contractor shall respond to changing regulatory and mission requirements of the Coast Guard that may result in new computer systems and communications networks that [the] OSC hosts.

Id. (footnote added).

a. General Contract Services Under the SETS II Task Order

The SETS II task order PWS required the contractor to “provide a broad range of services-” Id. at 543. These services, “applicable to the Task Order overall[ and] not unique to a specific area,” id., included: (1) Contract Program Management; (2) Technical and Business Area Management; (3) Human Resources Management; (4) Quality Assurance; and (5) Property Management, id. at 543-50. Specific responsibilities were enumerated within these categories. For example, one component of Technical and Business Area Management services included “provid[ing] direct supervision of system management in the performance of the requirements of this PWS.” Id. at 546. Property Management services required the contractor to (1) “establish and maintain agreements with vendors of software and hardware as required for and used by the systems covered under the SETS II Task Order,” (2) “establish software licensing and maintenance agreements for all commercial-off-the-shelf software (COTS) required for the systems specified in this PWS,” id. at 549, and (3) “establish and maintain hardware licenses and maintenance agreements required to meet or exceed system availability for each system specified in this PWS,” id. at 550.

b. System Services Under the SETS II Task Order

In addition to enumerating general contract services, the SETS II task order PWS listed specific “services to be provided for [Coast Guard] systems under this Task Order.” Id. at 561. Contractor-provided IT services included:

SETS II project management, system life cycle management, software engineering, software development, software upgrade and maintenance, quality assurance, configuration management, security, hardware upgrade and maintenance, hardware/software integration, database administration, system administration, network administration, data management, computer operations, technical writing services, customer hotline support, computer system fielding services, application system training, application technical field support, data center environmental monitoring and control, data center analysis and capacity planning, data center infrastructure reconfiguration, disaster recovery business continuity support, technical reference library support, property management, magnetic media support, and system transitions.

Id. at 532. Many of these services can be classified within fourteen broad categories, all of which contained specific responsibilities: (1) Functional Area Management; (2) Help Desk Support; (3) Software Development and Maintenance; (4) Hardware Maintenance; (5) System Administration; (6) *374 Database Administration; (7) Network Administration; (8) Data Management; (9) System Downtime; (10) Technical Writing; (11) System Transition; (12) Computer System Fielding; (13) Application System Training; and (14) Technical Field Support. Id. at 550-60; see also Part I.D.l.b.i-v, infra (describing each of these categories). Appendix 5 of the SETS II task order PWS — “Additional Computer Systems Scenario” — outlined “general assumptions that can be made concerning the future for each general contract service area and system for the entire period of contract performance” and “assumed that none of the currently supported general contract services will be removed from the contract.” Id. at 839. Although the Coast Guard anticipated that “[n]o changes in requirements are anticipated,” the SETS II task order PWS indicated that “future systems may require an additional general contract service level of effort.” Id.

i. Functional Area Management, Help Desk Support, and Software Development and Maintenance

Functional area management included the employment of functional area managers, who “shall act as department heads of contract work groups assigned to specific OSC systems.” Id. at 550. The contractor was required to furnish managers who “shall be qualified to manage and supervise the day-today operation of the assigned OSC system. ...” Id. According to the SETS II task order PWS, help desk support service was “currently not a SETS II service,” except to the extent that this service related to a particular system discussed within the PWS. Id. Thus, unless otherwise indicated, the contractor was not responsible for help desk support. Id.

Software development and maintenance services required that the contractor “develop, maintain, update and change application, system and [commercial-off-the-shelf] software for the systems specified in this PWS,” as well as “provide software development and maintenance services for systems in this PWS.” Id. Specifically, the contractor was expected to “[p]erform software engineering (e.g. [,] analysis, design, development, testing, installation and implementation) to create software required to meet new or modified functional requirements,” and “[d]evelop and submit ... detailed, step-by-step software testing procedures for software changes to each system covered by this Task Order.” Id. at 551.

ii. Hardware Maintenance, System Administration, and Database Administration

The SETS II task order PWS indicated that the contractor would perform hardware maintenance, which included “any preventative, corrective, and remedial hardware maintenance not covered by any hardware maintenance agreement with an outside vendor. This maintenance shall adhere to recommendations of original or equivalent replacement equipment manufacturers and to system availability requirements as defined for each individual system under this PWS.” Id. at 552. Examples of hardware maintenance included hardware testing (e.g., quality assurance), documentation (e.g., updating manuals, diagrams, and depicting logical and physical designs of each system), performance level and efficiency (e.g., analyzing capacity levels and utilization), and improvement (e.g., installing, testing, and evaluating new hardware). Id. at 552-53.

The contractor was also required to perform system administration activities, which were designed to maximize system availability and to provide monthly progress reports for the status of these activities. Id. at 553. As part of its system administration duties, the contractor was expected to engage in systems resource management support (e.g., developing parameters and procedures for responding to alarms and warnings, and recovering and restoring operations from backups) and to establish procedures (1) “to ensure the security, control and auditing of each system” (e.g., “maintaining user access control lists to delineate authorized access to computer systems and provide data security),” (2) “to provide for the organization and availability of ... data (e.g., data management),” (3) “to provide for effective and efficient production control,” (4) “to provide for effective and efficient performance monitoring and resource accounting (e.g., monitoring *375 system activities such as memory consumption, response time, resource usage requirements),” and (5) “to provide user account administration.” Id. at 553-54. Additionally, the contractor assumed database administration responsibilities, which included maintaining data element dictionaries, updating documentation depicting logistical and physical designs of databases, delivering a Database Activity Report, and implementing proposed database improvement alternatives. Id. at 554.

iii.Network Administration, Data Management, and System Downtime

The contractor’s network administration responsibilities required it to “operate, maintain, and update network hardware, software, and configuration files required for the operation and maintenance of each system specified in this PWS.” Id. at 555. Transmission Control Protocol and Internet Protocol software, for example, constituted one of several components incorporated into network administration. Id. Data management required the contractor to perform various tasks related to data entry and validation (e.g., ensuring correct and valid data are entered into each system), data analysis and validation (e.g., cheeking and correcting errors), and data retrieval and transfer. Id. at 555-56.

The contractor also would perform system downtime services, which required “providing] system-wide on-line access to authorized system users, allowing access to simultaneously logged in users.” Id. at 556. As such, the contractor was required to schedule maintenance and other downtime services during hours specified within the SETS II task order PWS. Id.; accord id. at 557 (setting forth parameters related to scheduled system downtime). Additionally, the SETS II task order PWS contained provisions related to unscheduled system downtime and provided examples of systems, such as the monthly calculation of actual system availability, that must be performed during downtime periods. Id. at 556, 558.

iv.Technical Writing, System Transition, and Computer System Fielding

As part of its technical writing services, the contractor was required to “prepare, update, and maintain documents necessary to facilitate ... use, operation, development, and maintenance.” Id. at 558. In addition to listing specific materials that must be included within contractor-developed documentation, the SETS II task order PWS indicated that the contractor must “follow [the] OSC’s existing templates, document formats, and style guidelines.” Id. The contractor’s system transition services included support for each system as specified. Id. at 559. Computer system fielding services required, among other things, that the contractor prepare and distribute release packages, as well as other materials, to accredited user sites. Id.

v.Application System Training and Technical Field Support

Finally, the contractor was responsible for providing application system training and technical field support. Id. at 559-60. Application system training involved the contractor training government-approved field users and systems managers. Id. at 559. Technical field support services included the contractor “providing technical expertise and problem resolution” and “configuring] and maintain[ing] an online database functional test environment” that would support development contractors, student access, and program manager testing. Id. at 560.

c. OSC System Requirements Under the SETS II Task Order

In Parts I.D.l.b.i-v, supra, the court described system services that the contractor was required to provide for Coast Guard systems under the SETS II task order. This section details each system encompassed by the SETS II task order in order to provide an understanding of the types and functions of the systems hosted by the OSC. For each system, the SETS II task order PWS designated which system services were applicable, identified additional requirements that the contractor must apply to each system when necessary, and specified any other pertinent performance requirements. Id. at 561. Each system was represented by a sub-CLIN. See id. at 561-618.

*376 As mentioned in Part I.D.l.b, supra, Appendix 5 of the SETS II task order PWS outlined “general assumptions that can be made concerning the future for each general contract service area and system for the entire period of contract performance.” AR 839. The categories into which a particular system was classified depended upon the system’s size. 29 Id. The SETS II task order PWS also detailed future assumptions for systems and indicated that the Coast Guard anticipated the addition of twenty-five computer systems to the SETS II task order over its performance period. 30 Id. at 841-42. Each new system was likened to a comparable, existing system for illustrative purposes. 31 Id.

i.Automated Aid Positioning System (“AAPS”); Aids to Navigation Information System (“ATONIS”); Integrated-ATONIS (“I-ATONIS”)

AAPS “collect[ed] positioning information from a differential global positioning system ... receiver to determine whether an aid [was] on or off station and create[d] an assigned positioning report when the servicing [was] complete.” Id. at 561. The Coast Guard utilized ATONIS, a database management system, id. at 2742, “to manage aids to navigation data,” which included “tracking and scheduling aid inspections and service visits, managing power systems, and performing administrative functions,” id. at 561. I-ATONIS, a web application, replaced ATONIS. Id. The contractor was required to provide “limited services for systems resource management, system licensing and maintenance agreements, and data support” for these applications. Id. When combined together, I-ATONIS and AAPS comprised a centralized OSC application. Id. at 2742.

ii. Automated Mutual Assistance Vessel Rescue (“AMVER”) System

AMVER was “a unique computer-based and voluntary global ship reporting system used worldwide by Search and Rescue (SAR) authorities to arrange for assistance to persons in distress at sea.” Id. at 562. It was a “mission-critical computer system,” id. at 2743, that enabled rescue coordinators to “identify participating ships in an area of distress and divert the best-suited ship or ships to respond,” id. at 562. AMVER’s mission was “to quickly provide [Search and Rescue] authorities, on demand, accurate information of the positions and characteristics of vessels near a reported distress.” Id. Contractor responsibilities associated with AMVER included availability “on an on-call basis 24 hours a day, 365 days a year (366 days during leap year) to assist in the resolution of any [AMVER] hotline calls involving an active Coast Guard Search and Rescue (SAR) mission.” Id. at 563. The contractor was also required, among other responsibilities, to “perform error checking,” verify and correct incoming data, track errors in AM-VER reports, and plot vessel routes for vessels from their departure to destination ports. Id. at 565.

iii. Abstract of Operations System (“AOPS”); Training Management Tool (“TMT”); Automated Requisition Management System (“ARMS”); and ASG

The Coast Guard utilized AOPS, a web-based software application, to “track[] Cutter and Small Boat resource hours expended performing operational missions.” Id. at 566, 2743. One AOPS component, the Resource Management Module, “create[d] an *377 inventory of Cutter and Small Boat resources and ... manage[d] these resources across the entire [Coast Guard].” Id. at 566. TMT “assisted] units in planning, tracking, and reporting personnel and unit level training activities.” Id. Together, AOPS and TMT “provide[d] mobile access for underway cutters” so that they could synchronize data. Id. The contractor was required to perform data management services, as well as data entry validation, for these systems. Id. at 567.

The Coast Guard utilized ARMS to track “requisition transactions sent by Coast Guard field units ... to the Defense Logistics Agency’s system,” id. at 568, by following the status of requisitions, “including whether the requested item has been shipped, received, back-ordered, ete.,” id. at 2744. ARMS received requisitions from Coast Guard field units, checked requisitions for validity, entered requisitions into its database, and forwarded these requisitions to a separate system for filing. Id. ARMS also “generate[d] obligation accounting data for transmittal to the Coast Guard Oracle Finan-cials (CGOF) accounting system.” Id. at 568. The contractor was required to “provide limited services for systems resource management, system licensing and maintenance agreements, and data center support only,” as those services related to ARMS. Id.

ASG “provide[d] technical support for IT infrastructure for the OSC and enterprise business services.... ” Id. The contractor’s ASG responsibilities included “maintaining] and configuring] the OSC’s Production Domain Controllers that are responsible for use and machine authentication across the OSC [Local Area Network].” Id. at 568. Additionally, the contractor was advised that each system within ASG must maintain a ninety-nine percent availability rate, thereby requiring the contractor to schedule system downtown only during specific time frames. Id. at 569.

iv. Auxiliary Data (“AUXDATA”); Certification and Accreditation (“C & A”); and CASP

AUXDATA “track[ed] [Coast Guard] Auxiliary activities, performance, membership, training, and resource management.” Id. at 570. Its goal was “to provide the Auxiliary management information needed to bring greater unity to Auxiliary and [Coast Guard] activities and missions.” Id.; see also id. at 2745 (indicating that AUXDATA permitted the Coast Guard to track, analyze, and report Auxiliary activity in a timely manner). C & A “[e]nsure[d] that all major applications and general support systems [we]re certified and accredited in accordance with Federal, [DHS,] and Coast Guard security policies and guidelines.” Id. at 571. A C & A team was required to “audit each system periodically to ensure C & A requirements are met.” Id. Although the C & A team “d[id] not currently utilize a specific [COTS] application as part of the C & A process,” the SETS II task order PWS indicated that this team “may [have] be required to do so during the life of this contract.” Id.

CASP was a “mission-critical computer system” utilized for search and rescue purposes. Id. at 572. Its software “supported] [Coast Guard] customers by generating probability data sets or ‘drift models’ used to locate objects (ships, rafts, people) adrift at sea.” Id. Utilized for developing search plans, CASP “improve[d] the chances of saving lives and property” by “developing search patterns [and] by using advanced techniques to help predict the most likely areas where a distressed vessel might be located.” Id. The contractor was required to be available on an “on-call basis 24 hours a day, 365 days a year (366 days during leap year) to assist in the resolution of any CASP hotline calls involving an active Coast Guard Search and Rescue mission.” Id. at 573.

v. BelManage ASM Support and Business Intelligence-Enterprise Data Warehouse (“BI-EDW”)

BelManage ASM Support “provide[d] real-time data for hardware and software assets deployed through the Coast Guard enterprise to a central colleetion/database server.” Id.; see also id. at 2746 (indicating that Bel-Manage ASM Support “allow[ed] users to simplify and automate the management of all user desktops, servers and laptops ... using a single database and Intranet server”). BelManage ASM Support was comprised of several functions, including: (1) ensuring *378 software-licensing compliance; (2) capturing detailed hardware profiles for all systems running the BelManage agent; (3) providing detailed reports for all hardware and software assets; (4) improving help desk efficiency; and (5) providing easy access to asset management reporting functions. Id. at 574.

BI-EDW, described as “a central repository for enterprise information captured by numerous [Coast Guard] systems,” was intended to provide ‘“one-stop shopping for Coast Guard information’ via a self-service, web-based tool.” Id. at 575. The contractor was required to “provide tools and perform systems, performance, tuning, and capacity analysis studies for specified applications” by using “modeling and/or prototyping techniques to size and quantify data.” Id. at 576. Additionally, the contractor was expected to perform technology assessments, including studies aimed at migrating secure application data. Id.

vi.CG Help (“CGHELP”) and Coast Guard List Server (“CGLS”)

CGHELP was “an automated help desk used by Coast Guard personnel, world wide [sic], to report problems with or request assistance_” Id. at 577. It exported information to the Coast Guard information system for reporting purposes. Id. The contractor was required to “primarily provide limited services for systems resource management, system licensing and maintenance agreements, and data center support”; however, the contractor was also expected “to perform other services in support of the application when specifically requested.” Id. The SETS II task order PWS described CGLS as “a mailing list manager” that enabled elements within the Coast Guard to “send notices via email out to a mailing list.” Id. at 578. The contractor would provide “limited services” in relation to this system, id., and would ensure that system availability was maintained at a ninety-nine percent level, id. at 579.

vii.Coast Guard Recruiting Command (“CGRC”) and Configuration Management (“CM”)

CGRC provided access to recruiting centers across the country and was “used to provide centralized access to the Coast Guard Message System, Coast Guard email, and other ... services for Coast Guard recruiters.” Id. The OSC’s CGRC support team provided system administration support and computer security support for hardware, functional software, and the operating system. Id. The contractor was expected to provide specifically enumerated services, with the exceptions of computer system fielding, application system training, and technical field support. Id. at 579-80.

CM activities “include[d] but [we]re not limited to document reviews; requirement reviews; [and] maintaining and updating OSC CM policy and associated documenta-tion_” Id. at 580. The contractor was required to “[e]nsure all published instructions; handbooks; and procedures are consistent with Coast Guard Configuration Management Policy....” Id. According to the SETS II task order PWS, a CM auditor would schedule and perform configuration status accounting activities for each functional area on an annual basis, id., perform a physical configuration audit, which “consisted] of determining that all items identified as being part of the configuration [we]re present in the product baseline,” id. at 581, and perform a formal functional configuration audit that “ensure [d that] the development of a Computer Software Configuration Item ... ha[d] been completed satisfactorily and ... [had] achieved the performance and functional characteristics” specified in documentation, id. These audits were designed to “verify that the [Coast Guard’s Computer Software Configuration Item] complie[d] with ... developmental specifications,” id.

viii.Data Center Support; G-0 CITRIX Farm (“CITRIX”); and Configuration Management Plus Client Server (“CMPLUS”)

The contractor was required to perform “centralized data center support” using an automated Systems Resource Management system. Id. at 582. These responsibilities included, among other things: (1) maintaining daily operations and system performance logs, as well as other record keeping documentation; (2) establishing management procedures; (3) maintaining a supply of *379 computer consumables used in support of each system; (4) maintaining an unclassified Magnetic Media Library; (5) providing help desk support via a hotline; (6) procuring and replenishing computer supplies; and (7) monitoring and adjusting computer room air handling equipment controls to maintain temperature and humidity specifications. Id. at 582-83. The contractor was also expected to provide support for the Coast Guard’s Customer Service Division functions “during primary work hours up to 1.5 hours during a normal workweek.” Id. at 584.

CITRIX was “a load balanced Citrix Me-taframe environment.” Id. The contractor was required to “primarily provide limited services for systems resource management, system licensing and maintenance agreements, and data center support” for CITRIX. Id. at 585. CMPLUS, which was an online configuration-based supply and maintenance system for updating and maintaining baseline configuration data and replacement materials, id. at 2749, “allow[ed] cutters and selected shore units to manage local configuration, maintenance, and supply information,” id. at 585. The contractor was expected to maintain and support several peripheral applications that supported CMPLUS and assume responsibility for augmenting training of the Vessel Logistics System Support Branch, which was “the primary training source for the program to provide training to the field_” Id. at 586.

ix.DHS Directory Services (“DIR-SERV”) and Disaster Recovery Business Continuity (“DRBC”) Support Services

DIRSERV “provide[d] 24 x 7 mission critical email relay and directory services to the Department of Homeland Security.” Id. at 587. This system “[a]ssign[ed] uniform email address[es] to all 22 DHS agency employees and route[d] email traffic to, from, and between all agencies and the Internet.” Id. A DIRSERV team provided on-site staffing at the OSC. Id. DIRSERV utilized COTS products, and the contractor was expected to perform activities that “may include modifications to the commercial products for improved efficiencies or to align the products with DHS business practices.” Id. at 587-88.

The contractor was expected to provide support for DRBC services and be “primarily responsible for the establishment and continued support and development of a DRBC capability for systems supported at the OSC.” Id. at 588. A DRBC contractor team was responsible for developing and maintaining the OSC’s overall DRBC and IT contingency plans, and for assisting “each business system’s functional area with developing specific contingency and disaster reeover[y] plans relevant to each such system....” Id. The contractor was required to “test each plan at least annually,” evaluate each test, and make recommendations for improvements. Id.

x.Emerging Technologies Technical Team (“ETTT”)

The SETS II task order PWS described the responsibilities of the ETTT as follows:

The Emerging Technologies technical team researches, prototypes, integrates and develops new technologies for the Operations System Center and the Coast Guard enterprise. The objective of Emerging Technologies is to assist the Coast Guard in keeping abreast of the latest IT ... and [to] assess how these technologies can be employed in the Coast Guard environment. Emerging Technologies may be employed to assess IT compatibility and interoperability in the Coast Guard environment. Emerging Technologies may be employed to assess IT compatibility and interoperability in the Coast Guard to ensure the Coast Guard is getting the best value for IT procurements.

Id. at 590. The contractor was required to provide various services related to the ETTT, with the exception of data management and system transition. Id. at 590-91.

xi.Electronic Program Management Office (“EPMO”) System/Deepwater Program, FLS, and Geospatial Information System (“GIS”)

EPMO was a web-based application “used to manage the project office of the Deepwa-ter program and to host web sites for various other organizations.” Id. at 591. EPMO “servers replicatefd] information between the production and backup servers and the third *380 party contractor server.” Id. The contractor was required to provide system administration services for EPMO. Id. at 592.

As a “web-based application designed to automate the management of [Coast Guard] vessel logistics,” id., FLS was designed to provide an “integrated, automated system to support ... Coast Guard vessel logistics needs,” id. at 2752. FLS incorporated “configuration management activities, maintenance actions, procurement and supply activities, and associated financial transactions.” Id. at 592. The contractor was required to “provide support for maintaining [the] integrity and quality of FLS common tables” and to schedule system downtime while maintaining particular percentages of system availability. Id. at 593.

GIS “provide[d] an array of geospatial data, map services and images for Coast Guard Enterprise GIS usage.” Id. The contractor was required to, among other things, develop and maintain GIS data, update GIS map services, and “[a]nalyze vector, raster, and imagery data as it relates to a GIS and the geospatial environment.” Id. at 594. Additionally, the contractor was expected to “provide access to 250 simultaneously logged in GIS users.” Id.

xii.Housing Management Information (“HMI”) and Local Area Network (“LAN”)

An intranet web application serving the Coast Guard’s housing community, HMI “in-elude[d] over 90 housing sites and 250 end users ... [and was] used to manage leased and owned housing inventory to include barracks.” Id. HMI tracked occupancy and provided information for ease of transfers between housing sites and Coast Guard facilities. Id. Contractor-provided network administration services for HMI included the following components: (1) WEB server software; (2) HMI system host application; and (3) HMI system database server software. Id. at 595.

The LAN team “provide[d] data communications technical support throughout the OSC” and was responsible for “the physical connectivity, designing and managing the devices (switches and routers), and software ... required for a local area network.” Id. at 596. Services included items such as address management, name resolution, time, connectivity, server load balancing, and statistical data gathering. Id. The contractor was required to manage and administer a LAN in order to provide “complete data networking connectivity” between various systems. Id. at 597. Additionally, the contractor was expected to monitor capacity and performance, and to make recommendations for handling increased usage. Id.

xiii.Long Range Aid to Navigation Operations Information System (“LOIS”) and MMLD

LOIS was designed to assist Long Range Aid to Navigation personnel “in their daily reporting on the operation of the LORAN-C system.” Id. at 598. This application supported “data entry, calculations, query functions, plotting/graphing, and reporting capabilities needed to record and analyze station performance.” Id. Although the contractor was required to perform limited services, such tasks included “resource management, system licensing and maintenance agreements, and data support.” Id.

MMLD “automate[d] the various marine licensing and documentation processes, including record keeping of merchant mariners” of the United States. Id. These records included documentation, licenses, “employment information on each U.S. mariner[,] and World War II Merchant Mariner Veteran’s Status information.” Id. The contractor was required to perform various network administration services and to provide coverage for (1) terminal servers and software and (2) modem drivers and configurations. Id. at 599.

xiv.Marine Safety Network (“MSN”); Panorama Business Views (“PB-Views”); Naval and Electronic Supply Support System (“NESSS”); and Enterprise Management Support (“EMS”)

MSN was “a [Coast Guard] Intranet application” with a database that resided at the OSC. Id. at 600. It provided management information systems that supported Coast Guard programs, including Marine Safety, Law Enforcement, Search and Res *381 cue, Response, Legal, and Finance. Id. The contractor was required to provide various network administration services, as well as coverage for the terminal server and software, for MSN. Id. at 601.

PB-Views was created in order to permit the Office of the Chief of Staff to evaluate COTS packages in order “to determine the feasibility and usefulness of the software. ...” Id. The contractor, in addition to satisfying specific system availability requirements in accordance with PB-Views specifications, was required to ensure accessibility of the system for fifteen simultaneously logged in users while maintaining an availability level of ninety-six percent for the primary system. Id. at 602. Additionally, the contractor was directed to schedule system unavailability for specific times unless prior approval was obtained from a project officer. Id.

NESSS was an Oracle-based database system used primarily by the Coast Guard Yard and the Engineering Logistics Center. Id. The contractor was responsible “for the software development and maintenance of the NESSS system.” Id. at 603. Additionally, the contractor was required to provide network administration services and coverage for the following components: (1) X-terminal server and terminal software; (2) modem drivers and configurations; and (3) NESSS mail server to host application. Id. at 603-04. Furthermore, the contractor “shall provide access to 500 simultaneously logged in NESSS users” in order to ensure that system availability, measured monthly, remained at levels of ninety-nine percent for the primary system and ninety-eight percent for the secondary system. Id. at 604.

An EMS team “provide[dj technical support for IT infrastructure and enterprise business services for OSC.” Id. EMS

buil[t], test[ed], patche[d], deployed] and perform[ed] system life cycle management on OSC resources such as: file, application, email and print servers, enterprise system servers, desktop systems and SWI-II Testing Laboratory. Additionally, the EMS manages the PADLOC authentication domain, and the TISCOM mail hub, which provides internal email throughout the Coast Guard.

Id. The contractor was required to provide EMS servers system availability at a level of 99.9% during normal working hours and to schedule maintenance at specific hours. Id. Furthermore, the contractor

participate^] in monitoring established network and EMS service levels and eon-tribute[d] to any OSC reports, notifications, tracking, and performance statistics as appropriate. The contractor ... participate^] in supporting ... services at levels that achieve OSC’s availability requirements. This support ... include[d] quick response to changes in technology, dynamic requirements!,] and system, equipment, software, service, and carrier outages.

Id. The contractor was expected to provide on-call support, which also included “response[s] to automated pager systems,” twenty-four hours each day, seven days a week. Id.

xv. Point of Presence (“POP”); Business Intelligence-Readiness Management (“BI-RM”); and Shore Asset Management (“SAM”)

A POP team was “tasked with managing the external interface between the Coast Guard Data Network and the Internet.” Id. at 605. POP involved, among other things, the following: (1) wide area network technical support and configuration management; (2) mail distribution; (3) anti-spam; (4) anti-virus; (5) network security, including access control lists maintenance, firewall management, and intrusion detection; and (6) asset management of project equipment. Id. According to the SETS II task order PWS, the POP team “work[ed] with a large assortment of networking, email, firewall, and security hardware, software, and middleware products, and [was] responsible for building, testing, patching, and performing system life cycle management on all POP resources.” Id. Additionally, the POP system team’s engineers were required to provide twenty-four hour, seven days per week Internet availability for the entire Coast Guard. Id. at 605-06. The contractor was also responsible for providing functional area management, cus *382 tomer hotline support, system availability at a level of ninety-eight percent per month, and technical writing services. Id. at 606-07.

The Coast Guard utilized BI-RM, a web-based reporting tool, “to monitor, assess, and manage [Coast Guard] readiness,” to “mine data from existing [Coast Guard] systems[,] and report on six facets of readiness according to mission, organization, and unit.” Id. at 607. BIRM business lines included GIS, Cubes, Reports, Score Card, and Portlets. Id. The contractor, in addition to providing various services, was required to ensure access to 300 simultaneously logged in BI-RM users and to maintain a monthly availability level of ninety-nine percent. Id. at 608.

SAM “provide[d] core information about the [Coast Guard] facility and civil engineering and [was] used to track activities and assist in management of the Facility Engineering (FE) and Civil Engineering (CE) Programs.” Id. The contractor was required to provide various network administration services, plus coverage for the following components: (1) WEB server software; (2) SAM host application; and (3) SAM database server software. Id. at 608-09. The contractor was required to ensure access to one hundred simultaneously logged in SAM users and to maintain a monthly system availability level of 97.5%. Id. at 609.

xvi. Ship Arrival Notification (“SAN”) and SLDMB

SAN “collected], store[ed,] and disseminate[d] information regarding vessels arriving to[ ] and departing from U.S. ports.” Id. It was comprised of three subsystems: (1) Internal SAN, or iSAN, which was an Active-X website used for data entry and as a decision support tool; (2) DHS-SAN, which was a system transactionally replicated from iSAN; and (3) Electronic Notice of Arrival/Departure, or eNOAD, which allowed the public to submit electronically formatted data directly to the government. Id. at 609-10. The contractor was required to perform data entry and data validation services for SAN, id. at 610, which included the following functions: (1) verification that each notice of arrival/departure report received contained required information; (2) entry of the minimum required information into the SAN database for each SAN report received; and (3) entry of the minimum required information into the SAN database for each High Interest Vessels/Speeial Interest Vessels Report received. Id. at 611. In addition, the contractor was required to: (1) perform SAN data entry modifications in order to ensure that requested changes to reports were entered into the SAN database; and (2) implement quality assurances measures to ensure the accuracy of SAN data. Id. The SETS II task order PWS also set forth performance standards for ship arrival report processing and additional contractor expectations and requirements. Id. at 611-12.

SLDMB was designed to “traek[] buoys that [we]re deployed by various surface vessels and aircraft into areas,” id. at 612, and “to track the upper three feet of surface currents ... to estimate the movement of a search object,” id. at 2759. SLDMB received positioning data that was utilized by SAR Mission Controllers “to locate lost objects or provide environmental data.” Id. at 612. The contractor was expected to, among various responsibilities, provide non-stop on-call support to assist in the resolution of any SLDMB hotline calls involving an active Coast Guard search and rescue mission. Id. at 613. Additionally, the contractor was required to ensure access to sixty simultaneously logged-in SLDMB users and to provide a system availability level of 99.5%, measured monthly. Id.

xvii. System Performance Tiger Team (“SPERTT”); Systems Resource Management (“SRM”); Vessel Documentation System (“VDS”); and WEB Services

SPERTT performed the following responsibilities: (1) development of system performance baselines that were used for comparative analysis to determine how system changes or enhancements affect system performance; (2) troubleshooting in order to determine why system performance was degraded; and (3) application modeling and assessment in order to analyze how a system or technology would perform in a new configuration or environment. Id. at 614. The contractor was required to provide various services to other systems at the OSC or off- *383 site, as requested, in order to measure and evaluate system performance. Id. These services included, but were not limited to, system administration, database administration, and network administration. Id. at 614-15.

An SRM team was responsible for “building, testing, and managing OSC enterprise applications used for system backups, system monitoring, storage area networks, and system notification.” Id. at 615. The SETS II task order PWS enumerated specific availability requirements for backup service, enterprise monitoring and notification services, and enterprise storage services, including availability rates and time periods during which the contractor must schedule downtime. Id. at 616.

VDS was “an imaging and workflow system used to capture documentation information for U.S. owned vessels.” Id. Specifically, VDS collected certificates of documentation, vessel title information, and vessel ownership information. Id. The contractor was required to ensure that VDS would support 110 simultaneously logged in users and was expected to maintain a monthly availability level of 99.5%. Id. at 617.

Lastly, WEB Services, which included CG Central Portal, CG Web, WWW, and Home-port Portal, provided intranet and internet web content information, as well as services for the entire Coast Guard. Id. WEB Services Intranet was comprised of two components, CG Central Portal and CG Web. Id. CG Central Portal provided services “for the entire [Coast Guard] enterprise of approximately 80,000 employees and volunteers, located throughout the country, on afloat units, and in foreign lands.” Id. Its goals were to “provide a secure, flexible, single point of entry to [Coast Guard] intranet information and services, and a means for Team [Coast Guard] to gain a sense of community and involvement in the organization.” Id. CG Central Portal was designed to “bring [Coast Guard] Intranet-web presences into one unified, consistent, user-friendly interface.” Id. In addition, Homeport Portal, one component of WEB Services Intranet, would provide “a secure, flexible, single point of entry to [Coast Guard] internet information and services,” would also address port security and marine safety, id., and was designed as a “sole source interface with the public,” id. at 618. The contractor’s requirements included, among other things, ensuring a monthly availability level of 99.5% and scheduling downtime that did not coincide with CG Central Portal working hours. Id.

2. Evaluation Factors For Award of the SETS II Task Order

The Coast Guard based its award decision for the SETS II task order upon an evaluation of each offeror’s complete proposal submission, which included a technical proposal and a cost/price proposal. Id. at 951. Although offerors’ technical proposals and cost/ price proposals were evaluated, neither proposal was rated. Id. Of the two proposals, the Coast Guard considered technical proposals “significantly more important in the evaluation process than Cost/Price Proposals.” Id. By contrast, the Coast Guard both evaluated and rated each offeror’s past performance. 32 Id. The Coast Guard’s award was made to the offeror “whose proposal [was] determined to best meet the need of [the] Government after consideration of all information. — i.e., provides the ‘best value,’ ” which was defined as “the procurement process that results in the most advantageous acquisition decision for the government and is performed through an integrated assessment and trade-off analysis between the technical and cost factors.” Id. Offerors were “reminded that any award under the ITOP II program [was] not subject to protest.” Id. at 800.

According to the SETS II task order acquisition plan, the contractor was required to follow the OSC System Life Cycle Management Policy, a document that “outline[d] the life cycle phases of all IT business systems and denote[d] how ... testing requirements [we]re integrated into other key life cycle *384 phases.” Id. at 508. Additionally, the contractor was required to follow the OSC’s Security and Risk Management Program Plan when performing all IT activities, including software development and maintenance. Id. at 509. The SETS II task order acquisition ultimately presented “no classified security considerations,” although any security considerations would be addressed by the contracting officer at his or her discretion. Id.

The period of performance for the SETS II task order was “five years, including a one-month phase-in period, an initial six-month base period, four one-year option periods, and a final five-month option period.” 33 Id. at 533; supra Part I.D. “A key part of the contractor phase-in plan [was] the obligation of the contractor to demonstrate technical capability prior to the assumption of Task Order responsibility.” AR 507.

On June 9, 2005, the Coast Guard awarded the SETS II task order to QSS, id. at 954, which became “the single largest contractor on site ... responsible for operating and maintaining over 35 Coast Guard Mission Essential systems,” 34 id. at 2911. Through various modifications to the SETS II task order between June 2005 and December 2007, the Coast Guard added at least ten new systems. Id. at 4155. “Task order modifications that add[ed] systems [did] not expand any of the services included in the umbrella SETS II task order scope.” Id. On September 25, 2007, Modification 30 incorporated Coast Guard Financials into the SETS II task order. Id. at 4155. Through issuance of Modification 32 on December 31, 2007, the Coast Guard exercised option period three. Id. at 4153; supra note 33. Modifications 30 and 32, which are the subject of this action, are discussed in Parts I.E.5.a-b, infra.

E. The Coast Guard’s Audit-Supporting Federal Financial Management Systems and Related Services

The Coast Guard’s Office of Financial Systems Management Division provided Coast Guard management “with reliable financial information for managing and making day-today decisions[,] thus resulting in improved financial management systems and controls to safeguard the government’s assets.” AR 2651. The Coast Guard’s CAS “operate[d] on a 24/7 basis providing financial management services,” id., and “also maintain[d] a variety of financial feeder systems, information, and document management systems,” id. at 2652. CAS supported approximately 25,500 users and serviced 2,400 operational Coast Guard units and commands. Id.

CAS applications included Oracle Federal Financials, the Finance and Procurement Desktop (“FPD”), FPD-to-go, Contract Information Management System (“CIMS”), Sunflower, Markview, Workflow Imaging Network System (“WINS”), Informática, and a Remote Test Facility. Id. at 2652-53. Oracle Federal Financials maintained the Coast Guard’s General Ledger and “contained] modules that eontribute[d] to the transactions in the General Ledger_” Id. at 2652. The FPD, which was used “to commit and obligate funding and interface” into Oracle Federal Financials, provided procurement and accounting functions for units throughout the Coast Guard. Id. FPD-to-go was a portable, “lite version” of the FPD. Id. CIMS was a contracting management system that created and managed large contracts, id., while Sunflower was a “property management system, which provide[d] the primary business functions] like Acquisitions, Transfers, Retirements, Modifications, and Asset *385 tracking,” id. at 2653. The Coast Guard utilized Markview, an imaging and workflow program, to manage invoices. Id. WINS, an imaging and document processing system, permitted images and scanned documents to be processed for verification, reconciliation, and payment. Id. Informática generated reports from Oracle, FPD, CIMS, and Sunflower. Id. Finally, the Remote Test Facility was designed to test these and other Coast Guard financial applications. Id.

Prior to September 25, 2007, the Coast Guard did not procure audit-supporting federal financial management systems and related services via the SETS II task order. Id. at 4865. “Rather, the agency had separately procured these services from GCE....” 35 Id. As noted in Part I.A3.b, supra, GCE has “developed and maintained financial management systems of the [Coast Guard] that create[d] the Coast Guard’s financial statements of record for audits using government-certified financial management systems software” for nearly a decade. Compl. ¶ 4; see also AR 2860 (“GCE has been the systems integrator for the [Coast Guard] financial enterprise since 2000.”). The Coast Guard awarded contracts to GCE for the maintenance of CAS and FPD in 2000 and 2001, respectively. Compl. ¶ 19; see also AR 477 (stating that GCE “provide[d] the current support and development” of the FPD application and “ha[d] a separate Task Order contract to provide software maintenance on CAS”). GCE was awarded contracts for CAS and FPD support work when both were recom-peted in 2004 and 2005, respectively. 36 Compl. ¶ 19. These contracts, GCE alleges, were set to reach their maximum value on August 15, 2007, after which the Coast Guard “planned to re-eompete the financial systems work under a [Department of Homeland Security]-wide multiple [ID/IQ] IT-procurement contract vehicle.” Id. ¶ 20. According to GCE, “[a]t no time during any of the Coast Guard competitions did the Coast Guard indicate that the financial management systems work might fall under some other contract or task order-” Pl.’s App. 22 (Lucas Decl. ¶ 34).

GCE’s multiple prime contracts with the Coast Guard were worth approximately sixty million dollars. AR 2860. GCE indicated that its relationship with the Coast Guard enabled it to gain “unparalleled experience” in Coast Guard financial management processes and systems, as well as in federal accounting business processes. Id. Part of this work involved past Coast Guard transitions “from being serviced by the [DOT] accounting system to becoming the owner and operator of its own financial systems.” Id.

1. The Coast Guard’s Unified Mission Support Initiative

The Coast Guard began an “extensive modernization effort aimed at providing unified mission support to optimize mission execution.” Id. at 3011. In 2004, the Coast Guard’s Financial Systems Transition Work Group (“FSTWG”) commenced “initial planning for the consolidation] of Information Systems_” Id. at 474. The FSTWG compiled information related to “financial information systems, lifecycle documentation, contract vehicles, budgets and funding, configurations and related items,” and met with GCE in early 2005. Id. at 475; see also id. at 3014 (noting that a work group was ehar- *386 tered to “study the state of Coast Guard Financial systems with the intended goal of determining a path to transition the management and oversight ... activities for all financial and mixed IT systems”). The FSTWG determined:

The current state of systems development, support, maintenance, testing and systemic lifecycle practices for financial information systems are completely separate and apart from any connection to the Coast Guard [CIO’s] office. While some of the lifecycle practices employed for financial application systems closely mirror the best practices of industry, ... there are some significant gaps that are likely to lead to problems in the longer term.

Id. at 476. The FSTWG recommended that “[b]etter alignment and stricter compliance with Coast Guard system lifecycle practices ... [was] needed for the long-term stability and viability of [Coast Guard] financial systems.” Id.

On August 31, 2006, the Coast Guard issued “Commandant’s Intent Action Order # 10-eCG Service Oriented Architecture Implementation” (“Order Number 10”). Def.’s Mot. & Opp’n Ex. 3 (Thompson Decl. Ex. 1 at 1-2). Order Number 10 called for the “consolidation of all associated development, operation, and maintenance resources.” Id. (Thompson Decl. Ex. 1 at 1). Specifically, the consolidation contemplated by Order Number 10 included “new system development as well as any upgrades and revisions to existing systems and applications regardless of in-house or COTS sources.” Id. Order Number 10 emphasized that the effort to consolidate was “not solely on billets or specific IT applications.” Id. Rather, “[i]t [was] critical that [the Coast Guard] assertively chart a course to consolidate functional responsibilities.” Id.; see also AR 3011 (indicating that the Coast Guard was “undergoing an extensive modernization effort aimed at providing unified mission support to optimize mission execution”). In November 2006, the Coast Guard conducted another review of financial and mixed IT systems in order “to evaluate significant changes, issues, and gaps,” and a working group evaluated recommendations in light of the issuance of Order Number 10. AR 3014.

Pursuant to the mandate set forth in Order Number 10, the Coast Guard’s Chief Financial Officer (“CFO”) and CIO began working together with the OSC “to effect the transition of financial systems development work.” Def.’s Mot. & Opp’n Ex. 3 at 2 (Thompson Decl. ¶ 3). The Coast Guard recognized that the “transition of CG Financials to OSC ha[d] high visibility.” AR 2844. As a result, it established a Financial Systems Working Group (“FSWG”) Charter in or about January 2007. 37 Def.’s Mot. & Opp’n Ex. 3 (Thompson Deck Ex. 2 at 1-3). The FSWG Charter created the FSWG, which was a “cross-organizational team [tasked with] developing] an information system plan for Coast Guard Financial Systems to include a single general ledger, single property system and eventually a single logistics system that will be compliant with Federal financial accounting and reporting requirements.” Id. (Thompson Decl. Ex. 2 at 1). “The specific objective which must be achieved,” according to the FSWG Charter, was “the creation of a financial system which [would] allow the Coast Guard to effectively and efficiently obtain unqualified audit opinions on its external financial reports and internal controls over financial reporting.” Id. The FSWG Charter set May 1, 2007, as the target date for the development and delivery of a Plan of Action and Milestones. Id. (Thompson Deck Ex. 2 at 2).

2. Efforts to Create an Audit-Supporting Federal Financial Management Systems and Related Services Procurement

According to GCE, the Coast Guard “planned to re-compete the financial systems work under a[DHS]-wide multiple [ID/IQ] IT-proeurement contract vehicle” at some point between January 2007 and May 2007. Compl. ¶ 20; see also AR 285 (“[T]he original plan was to try to compete the work for the period beginning August 15, 2007[,] under *387 the DHS [Enterprise Acquisition Gateway for Leading-Edge Solutions (“EAGLE”) ] contract.” 38 ), 2917 (“In light of the fact that GCE’s contract was nearing the end of the period of performance, an acquisition plan for the [Coast Guard] Enterprise Financial Systems was developed by the [Coast Guard] contracting office.” 39 ). To that end, the Coast Guard developed an acquisition plan in order “to compete the services provided for by the current GCE contract for the [Coast Guard] Enterprise Financial Systems.” AR 2917. Ultimately, however, “[t]hat plan rapidly ran into problems,” including the fact that “the GCE work crossed ... four functional areas,” thereby raising concerns that there might be a lengthy process to obtain a waiver in order to cross functional areas.” 40 Id. at 286. Ultimately, the Coast Guard preferred to utilize the EAGLE vehicle for its acquisition. 41 Id. at 2422; see also id. at 2919 (noting, in a November 7, 2007 memorandum from GCE to the Coast Guard contracting officer, that the Coast Guard “demonstrate[d] clear intent ... to compete the work of the [Coast Guard] Financial Systems under the DHS EAGLE contract”). However, by mid-June 2007, the goal of making an award by August 15, 2007, seemed “unlikely.” Id. at 286; see also id. (noting that the EAGLE vehicle could not handle anticipated changes to the contract and that plans were shifted to the GSA schedule instead), 2416 (“The Eagle Contract vehicle does not provide the flexibility to have continuity of service with the same vendor when requirements change.”). 42

Even as early as February 2007, the Coast Guard encountered challenges in preparing the solicitation. For example, it was unclear whether the Coast Guard would issue “an *388 unrestricted solicitation (large and small vendors) or [a] set-aside for the small vendors only....” Id. at 2381. A preference for large vendors was advanced on account of “[t]he complexity of Federal Financial Oracle Information system development required under this requirement to consolidate IT systems where systems perform duplicate functionality, achieve real time integration of financial IT systems, and ... consolidate to a single core accounting system general ledger.” 43 Id. However, it was recommended that the Coast Guard not restrict competition to large businesses because the Coast Guard believed it was “going to have some problems with [the] Small Business Administration representative ... since small businesses] could team with a large business and do the work as well.” Id. at 2380. Nevertheless, recognizing that existing task orders issued to GCE were set to expire on August 15, 2007, the Coast Guard continued its efforts to issue an award effective August 16, 2007, in order “to have a follow on contract for system development and on-going technical maintenance support. Any break in technical maintenance support services for the CAS w[ould have] negatively impacted] the operations of the [Coast Guard].” Id. at 2397.

The Coast Guard devised a risk mitigation plan comprised of three alternatives for its Federal Financial System Development and Technical Maintenance Support Requirement. Id. at 2406. One alternative proposed the award of a new contract under the GSA schedule. Id. at 2407. A second alternative proposed modification of the existing GCE task orders for FPD/CIMS and Coast Guard Oracle Federal Financials through September 25, 2007, and the exercise of an option to issue new task orders — commencing on September 26, 2007, and ending on September 25, 2008 — to GCE. Id. A third alternative proposed modifying the existing GCE task orders through September 25, 2007, and ex-ereising an option on the GCE contract to issue task orders for performance ending March 11, 2008. Id. at 2408; cf. id. at 2415 (indicating that two options were contemplated: the first to modify the existing task orders through September 25, 2007, and the second to exercise existing options through September 25, 2008). These alternatives were deemed practicable for three reasons:

1) Provides the time/flexibility to work through the contracting and DHS/[EAGLE] issues that are presenting major challenges for award of a new combined maintenance and development contract by 16 August [2007].

2) Continued service under the existing eontractor[ ] enables the [Coast Guard] to address immediate pressing audit remediation system development requirements (milestones in the financial and mixed system initiative comprising $5.2M) and provides critical technical maintenance support services for the Core Accounting System (CAS) through September 2008.

3) On or about September 2008, the [Coast Guard] will have completed a business analysis and process review of the Core Accounting System by an independent contractor ... [and] will have more clearly definable system development requirements (to move our current CAS financial system(s) to a single “out of the box” Oracle system) and will have a more clearly definable project plan.

Id. at 2415-16. While the Coast Guard wanted to avoid changing contractors working on CAS, see supra note 42, it nevertheless characterized retention of GCE beyond the August 15, 2007 performance date as a “fall back” plan, AR 2426.

By late June 2007, the Coast Guard determined that “EAGLE [was] not a practicable strategy of procuring Federal Financial Systems Development and technical maintenance support.” 44 Id. at 2420. It also con- *389 eluded that “it is most unlikely that the new requirement will be awarded by August 16, 2007,” id. at 2415, and determined that the GSA Schedule would be utilized in lieu of the EAGLE contracting vehicle, id. at 2431. But see id. at 2918 (indicating that the DHS EAGLE opportunities website forecasted a Coast Guard solicitation). Despite its apparent inability to utilize the EAGLE contracting vehicle, the Coast Guard remained committed to issuing a solicitation for competition: “[W]e want to pursue the contracting strategy that will optimize our chance for success. The BEST way to get there is to recompete the current contract and have it awarded in time to use FY-07 funds.” Id. at 2432; see also id. (noting that the Coast Guard’s “preferred method [was] to pursue the recompete”).

3. The August 15, 2007 Sole-Source Bridge Contract to GCE

In July 2007, the Coast Guard began pursuing the following “strategic direction”: “extending the current GCE contract for 6 months (31 March [2008] makes for a ‘cleaner’ transition point, but we can live with 6 months).” Id. at 2439; accord id. at 286 (indicating that the Coast Guard began developing a strategy to “extend[] GCE[’s work] to March 31, 200[8,] and transition!] the software work to OSC”). Because GCE “maintained] the financial management systems test, development, and training environments[, which were] required to support the [Coast Guard’s] financial management system’s production environment,” and possessed an “intimate knowledge of the [Coast Guard’s] financial management system [that] provide[d] the ability to promptly remediate identified deficiencies,” the Coast Guard determined that a sole-source bridge contract with GCE would alleviate the problem that “another vendor could not immediately establish and provide these environments.” Id. at 2618. The Coast Guard determined that extending the GCE contract represented “the least risky way to proceed.” Id. at 2444.

The primary purpose of the Coast Guard’s August 15, 2007 sole-source bridge contract to GCE was “to assist the [Coast Guard’s] Office of Financial Policy and Systems ... and the Office of Financial Systems Management Division ... in complying with: federal financial management systems requirements; applicable federal accounting standards; U.S. Government Standard General Ledger at the transaction level; and Federal Financial Management Improvement Act (FFMIA) requirements.” Id. at 2618. Specifically, the Coast Guard required:

a wide-range of Federal Financial Information Technology (IT) system development, technical maintenance, project management, audit remediation!,] technical assistance, training, administration, software maintenance, configuration management, migration, user support, and database administration support.... This support is required to implement, maintain and comply with: federal financial management systems requirements; applicable federal accounting standards; and U.S. Government Standard Ledger at the transaction level.

Id. at 2619. The bridge contract “enablefd] the [Coast Guard] to transition the System Development Agent (SDA) role from a contractor provided facility to a Government provided facility,” a transition that was “part of the overall plan to transition all information technology to the Office of Information Systems and Infrastructure_” Id. at 2618.

In order to meet its needs, the Coast Guard required “comprehensive project management, audit remediation, and support for the completion of ongoing Federal Financial IT systems development as well as continuous support and maintenance of the activities involved with these production systems on a 24/7 basis.” Id. at 2622. As a result, GCE was required to “provide a wide-range of ongoing Federal Financial IT systems development, technical maintenance, project management, audit remediation, technical assistance, training, administration, software maintenance, configuration management, mi *390 gration, user support, database administration support, and certification and accreditation for the [Coast Guard] Financial System.” Id. at 2622-23. With respect to audit remediation responsibilities, the Coast Guard expected that “Federal Financial IT systems development ... [would] meet Initiative Action Plan (IAP) milestones for the ongoing audit remediation effort.” Id. at 2623.

The Coast Guard estimated that this transition would require seven and one-half months of planning, acquisition, and integration. Id. at 2618. On August 15, 2007, it awarded to GCE the bridge contact, which “provide[d] contractor assistance in Federal Financial Information Technology (IT) system, software development, technical maintenance, project management and database administration support for the [Coast Guard] as well as [DHS] and its components[’] financial and mixed IT systems.” Id. at 2607. The performance period under the contract spanned from August 16, 2007, through March 31, 2008. Id. at 2645.

4. The Coast Guard’s August 2007 Solicitation and September 2007 Contract

In August 2007, the Coast Guard issued a solicitation for financial systems expertise, business process development, and project management support to migrate its financial systems to “a single ‘out of the box’ Oracle™ system,” an effort that required the contractor to demonstrate “extensive knowledge of Oracle software and a comprehensive understanding of best practices for accounting and financial reporting business processes using Oracle.” Id. at 2820. The solicitation noted that the Coast Guard was “currently engaged in a major Financial Management Transformation Project to create world-class accounting, business information, and financial processes.” Id. at 2821. Among the goals enumerated in the solicitation were: (1) efficient financial operations; (2) an “unqualified Statement on Auditing Standards (SAS) 70 opinion for [Coast Guard Finance Center] operations”; (3) an “unqualified financial statement audit”; and (4) an “unqualified opinion on internal controls over financial reporting.” Id.

GCE, the incumbent contractor, expressed an interest in bidding on this contract. Pl.’s App. 24 (Lucas Deck ¶ 43). However, according to GCE, the Coast Guard “informed GCE that [it] would compete the software development tasks separately, and that GCE should wait for that competition.” 45 Id. In fact, GCE was unable to compete for this work because the solicitation prohibited software developers from participating in the competition. Id.; see also AR 2835 (indicating that the contractor “shall be an independent entity of the software developers used for development and maintenance of the system. The Contractor shall also be an independent entity of the contractor operational staff that operates the system ”). After the solicitation was awarded to Pricewaterhouse-Coopers in September 2007, see AR 2799-802, GCE believed that it would work with PricewaterhouseCoopers to perform this contract and that a separate solicitation would be issued for related software development tasks, Pl.’s App. 25 (Lucas Decl. ¶ 43).

5. Use of the SETS II Task Order to Transition Audit-Supporting Federal Financial Management Systems and Related Services to the OSC

In July 2007, the “OSC SETS [II task order] was being evaluated as a possible alternative [for the Coast Guard] to meet [its] contracting needs.” AR 2431; see also id. at 286 (indicating that in August 2007, the SETS II task order was mentioned as a vehicle through which to implement the transition to the OSC), 2618 (“[A] new contract modification is planned to be made under the SETS [II task order] at OSC Martinsburg, West Virginia.”). One month later, “an agreement was reached between the [CFO] and [CIO] ... to shift responsibility for Financial Management Systems....” Id. at 2710. Although this transition would “be a huge and monumental effort,” it “demon-stratefd] the importan[t], far reaching and long-range implications of this decision for the entire Coast Guard.” Id.; see also id. *391 (stating that a change order implementing this transition “is in the best interest of the Coast Guard”). Any “transition of the operations and maintenance of the enterprise financial system” was required to “include a thorough analysis of the current systems maintenance function_” Id. at 3012. According to the Coast Guard, this transition “of financial systems software development to [the] OSC ... ensure[d] that the Coast Guard can meet its customers’ needs while at the same time work[ ] in partnership with the DHS ... on its initiative to develop a department-wide shared financial application baseline.” Id.

The Coast Guard ultimately utilized the SETS II task order to procure services for its audit-supporting federal financial management systems. See id. at 2929 (“[T]he OSC Contracting Officer and legal counsel determined the financial systems requirement to be within [the] scope of the SETS II Contract”). GCE alleges that despite this determination, Coast Guard personnel “raised concerns regarding the propriety of using SETS II” as the contract vehicle beginning in late June 2007. Compl. ¶ 27. Beginning in August 2007, GCE learned that the Coast Guard began considering a noncompetitive transfer of financial management work to QSS. Pl.’s Mot. Prelim. Inj. & TRO 11. GCE states that these rumors persisted into October 2007, at which time the Coast Guard “denied the rumors.” Pl.’s App. 25 (Lucas Deck ¶ 44).

a. Modification 30 to the SETS II Task Order

A September 25, 2007 Coast Guard memorandum announced the issuance of a change order “to establish a new Sub-CLIN for Financial Management Systems (FMS)” within the SETS II task order and “direct[ed] the SETS II Contractor, QSS, to immediately begin tasking to initiate the transition of Financial Management Systems to the OSC.” AR 2710. The memorandum explained:

Several weeks ago an agreement was reached between the [CFO] and [CIO] of the Coast Guard (CG-6 and CG-8[, respectively]) and a plan was devised to shift responsibility for Financial Management Systems to CG-6. CG-6 directed that [the] OSC, as the Coast Guard’s Software Development Center of Excellence, would take on the responsibility for all Financial Management Systems. Meanwhile, the current task order with Global Computer Enterprises, Inc. (GCE) was extended by the Contracting Officer ... from October 15, 2007[,] through 31 March 2008.

The transition of tasking to the OSC will be a huge and monumental effort and the on-going negotiations, agreements, and discussions between CG-6 and CG-8 demonstrate the importance, far reaching and long-range implications of this decision for the entire Coast Guard.

Id.; see also id. at 2295-313 (containing Modification 30 to the SETS II task order). Although this decision was made in September 2007, the Coast Guard apparently did not seek general counsel’s opinion as to whether audit-supporting federal financial management systems fell within the scope of the SETS II task order until after November 7, 2007. See infra note 52.

The period of performance for Modification 30 spanned through May 31, 2010, AR 2296, the date on which the final, five-month option period under the SETS II task order terminated. See supra note 33. A new section added to the SETS II task order PWS indicated that

[t]he purpose of this Change Order under the SETS II Task Order is to facilitate the transition of Financial Information Technology (IT) systems, software development, technical maintenance, project management, technical analysis/assistanee, training, incidental administration, trouble shooting, software bugs correction, new system components installation, configuration management, migration, user support, and data base administration support for all [Coast Guard] as well as [DHS] and its components financial and mixed IT systems to the [OSC] on or before 31 March 2008. 46

*392 AR 2312 (footnote added); cf. id. at 4140 (enumerating the following services: Federal Financial Information Technology (IT) system development, software development, technical maintenance, project management, audit remediation, technical assistance, administration, software maintenance, configuration management, migration, user support, and database administration support). .These tasks were part of a “wide-range” of work. Id. at 4140. Modification 30 also included the following labor categories: Applications Programmer, Communications Network Specialist, Data Analyst, Database Analyst, Document Management Specialist, Functional Area Manager IV, Software Systems Specialist, Systems Analyst, Systems Administrator/Operator, and Word Processor. Id. at 284.

Additionally, the new section of the SETS II task order PWS enumerated milestone events that would be included in a draft transition plan, some of which included:

• The deployment, installation, and configuration of new hardware_At a minimum this will include a development and a test environment for the affected systems ....

• Establishment of an automated source code repository for effective source code management. This will include migration of baselined and fully-documented source code to this new repository.

• The establishment of the exchange of staffs between the OSC contract staff and [GCE’s] staff as established mutually during the Scoping Session. It is a requirement for effective transition that appropriate numbers of cleared/qualified staff from the OSC be stationed temporarily at [GCE’s] facility.

• The successful build of a deployable, executable version of the system code baseline. This build must be performed by OSC staff to be considered a success ....

• The transfer of all Government-owned software licenses from the servers/workstations at the contractor’s site to the OSC, or other location designated by the Government.

Id. at 2313. The draft transition plan would “detail all steps necessary, to include staffing, hardware and software configurations, milestone dates for major activities, and related tasks such that the systems are successfully transitioned prior to the expiration of the period of performance of this PWS.” Id. Timing was “imperative” in order “to get the Contractor working on the critical tasks to achieve the required outcome by 31 March 2008....” Id. at 2710.

In summary, Modification 30 “was a change order transaction ... [that] incorporate[d] the transition work and equipment necessary to transition [Coast Guard] Finan-cials to OSC,” id. at 2841, and reflected “a direction to get started on transition,” 47 id. at 284. It required that QSS conduct an on-site scoping session at GCE’s facility “for the express purpose of collecting copies of system documentation, system code libraries and repositories, and for allowing the Contractor to observe the breadth and scope of the effort to maintain, build[,] and deploy a working copy of the system software involved.” Id. at 2312-13. Furthermore, Modification 30 required that QSS provide a final transition plan identifying milestone dates for major activities and detailing all steps necessary to successfully transition staffing, hardware and software configurations, and related tasks. Id. at 2313.

b. Modification 32 to the SETS II Task Order

In November 2007, the OSC “sent the SETS II Contractor, QSS[,] written notice of the Government’s intent to exercise Option Period 3 of the SETS II task order.” Id. at 4153. On December 5, 2007, the Coast Guard “directed] the transition of software development and support for the financial IT systems from the current program-centric *393 software development model to a CIO-centric development model_” Id. at 3011. It then issued Modification 32 to the SETS II task order on December 31, 2007. Id. at 3963, 4153. Through Modification 32, the Coast Guard exercised “Option Period 3 for the period January 01, 2008-December 31, 2008” of the QSS task order. Id. at 3963, 4153; supra note 33. Modification 32 reflected the Coast Guard’s determination that the “exercise of Option Period 3[was] most advantageous to the government” and that “[f]ailure to exercise the option ... resulted] in diminished capability of the [Coast Guard OSC] to perform [its] functions.” AR 4158. The contracting officer further determined that in accordance with FAR § 6.001(e), Modification 32 was “exempted from the competition requirement because it [was] determined the requirement [came] under the scope of the existing contract.” Id.

6. GCE Expresses Concern to the Coast Guard

GCE alleges that the Coast Guard never informed it about Modification 30. Compl. ¶ 34. On October 25, 2007, after GCE learned of the issuance of Modification 30, it “raised its own concerns with the ... SETS II modification strategy.” Id. But see AR 3 (indicating that GCE first learned about Modification 30 from the Coast Guard on November 8, 2007). GCE “repeatedly expressed concern about [its] role post transition” to Coast Guard officials, who believed that GCE “was looking for a venue to engage the OSC in a direct contractual arrangement.” AR 2854. GCE’s concerns can be separated into three categories: (1) competition; (2) contract scope; and (3) adverse impact to the Coast Guard. Id. at 2863.

First, GCE “expressed concern that the work was given to [the] OSC ‘without competition.’ ” Id. at 2854; see also Compl. ¶ 32 (alleging that the Coast Guard issued Modification 30 “with no competition”). GCE indicated that it “would expect to have the opportunity to compete” for financial systems support work and anticipated a competitive solicitation. AR 2863. GCE noted that as the incumbent contractor, it not only competed in full and open competitions that it won, but it also had “a reasonable expectation that [this work would have] be[en] re-competed.” Id. It stated that the consequences of the Coast Guard’s intention not to compete this work would cause GCE to lose approximately [...], or [...] of its annual revenue. 48 Id. Furthermore, because GCE was required to assist and train the OSC contractor, it believed that the Coast Guard “tasked [it] to transition intellectual capital to another contractor,” which would result in giving the contractor “an unfair advantage when a competitive acquisition occurs.” Id. at 2864. In response, the Coast Guard indicated that the OSC contract “was competitively awarded and was the Coast Guard[’s] mechanism for providing software development services.” Id. at 2854.

Second, in response to the Coast Guard’s use of the SETS II task order to task QSS with audit-supporting federal financial management systems services, GCE stated that it was “unusual that the scope of a single contract covers the development and maintenance for every line of business within a federal agency” and that it was “not reasonable to expect that any single contractor possesses all requisite expertise in every line of business.” 49 Id. at 2864. Furthermore, GCE indicated that audit-supporting federal financial management systems “have been traditionally regarded as an independent line of business ... and have been treated as such through contractual vehicles, i.e. [,] awarded independently of other lines of business.” Id. It also questioned what it believed was an inconsistent application of the transition of audit-supporting federal financial *394 management systems to the OSC — as it related to GCE’s contract — by noting that “[t]here are several financial management contracts that are not being transitioned to [the] OSC. Several aspects of the [Coast Guard] financial systems enterprise software development and hosting are not following this transition methodology.” Id. at 2865. Additionally, GCE sought clarification about whether the development of key components of the audit-supporting federal financial management systems services were being transitioned to the OSC and where the operations of these systems would occur. Id.

GCE provided to the Coast Guard a SETS II task order PWS “Section Detailed Analysis” table, which it utilized in support of its position that the SETS II task order PWS “clearly indicate[d] that the [Coast Guard] Enterprise Financial Systems are not in the scope of the SETS II [task order] work”. Id. at 2899; see also id. at 2899-902 (containing the entire table). For example, GCE noted that the General Scope section of the SETS II task order PWS indicated that “[s]ervice applies to existing and future systems,” that Coast Guard “Enterprise Financial Systems existed but are not named,” that those systems “would not be considered a ‘future’ system as it already existed,” and, as such, the Coast Guard “could have easily identified those systems and placed them within the scope of this contract.” Id. at 2899. Additionally, GCE apprised the Coast Guard that the SETS II task order CLINs, in GCE’s opinion, did not name any Coast Guard Enterprise Financial Systems or financial system applications and, as such, those systems were outside the scope of the SETS II task order. Id.; see also id. at 2900-02 (explaining that the SETS II task order System Services, Software Development and Maintenance, Network Administration, System Availability, Scheduled System Downtime, Mean Time to Restore/Repair, and OSC System Requirements sections of the SETS II task order PWS do not list Coast Guard Enterprise Financial Systems as systems covered under the task order).

GCE also provided to the Coast Guard a table of the SETS II task order PWS “Section 8 List of SubCLINs/Systems.” Id. at 2903-07. According to GCE, Section 8 of the SETS II task order PWS “designates each system covered under this PWS and all of the services to be provided for those named systems.” Id. at 2903; see supra Parts I.D.l.c.i-xvii. In addition to providing a description of each system, GCE noted that the SETS II task order PWS “does not include CLINs for any component of the [Coast Guard] Enterprise Financial Systems.” AR 2903.

Finally, GCE addressed how the transition adversely impacted the Coast Guard. Id. It noted that the Coast Guard’s transition plan “duplicate[d] GCE’s Software Development Center,” a state of the art software development center and testing facility in which the Coast Guard invested millions of dollars, and emphasized that the Coast Guard would have spent “an additional [ ... ] to duplicate the infrastructure that [it] has already paid GCE to build and maintain.” Id. Additionally, GCE indicated that it

has been intimately involved in supporting the audit remediation efforts over the past two years. It is risky to transition the software development to a new contractor team who has not worked on the [Coast Guard] financial systems in the midst of the audit remediation. GCE is deeply concerned about any interruption to the [Coast Guard] audit remediation effort and the operational capability of the financial management systems.

Id. GCE recommended that it “enter into discussions” with the Coast Guard and “hold[] scoping sessions to convey to [the] OSC the depth and breadth of the [Coast Guard] financial systems.” Id. at 2866.

On October 31, 2007, GCE notified the Coast Guard via electronic mail that it “submitted a [Freedom of Information Act (“FOIA”) ] request for the SETS II [task order] PWS and contract” and “documented [its] concerns with respect to whether or not the [Coast Guard] Enterprise Financial Systems fit under the current scope.” Id. at 2891. In an accompanying memorandum, Mr-. Winslow articulated GCE’s “position that any change order or task order issued subsequent to a modification of the SETS II [task order] contract that includes [Coast Guard] *395 Enterprise Financial Systems software maintenance or support is out of the scope of the SETS II [task order] contract and the SETS II Performance Work Statement....” Id. at 2892. GCE maintained its belief that, among other things, (1) the scope of the SETS II task order “is very well defined and focused on ... operational mission systems,” id. at 2895; (2) the SETS II task order PWS “sets out a very clear scope that is not ambiguous,” id. at 2896; (3) Coast Guard financial systems “do not meet the scope criteria and are not named in the PWS,” id. at 2895; (4) if enterprise financial systems at the OSC were intended to fall within the scope of the SETS II task order, then they could have been easily added within the SETS II task order PWS, id.; and (5) enterprise financial systems “could be added to the OSC mission,” but such a “new requirement would not fall under any existing contracts of the OSC,” id. at 2896. GCE also indicated its belief that the Coast Guard “will independently conclude that the SETS II contract is not an appropriate contracting vehicle to support the transition of the [Coast Guard] Enterprise Financial Systems to the OSC" and recommended that the Coast Guard pursue a “competitive acquisition process” for those services. 50 Id. at 2898.

The Coast Guard responded to GCE’s concerns in a memorandum dated November 8, 2007. Id. at 2929. Carmen L. Correa, Chief of the Formal Contracting Division, reiterated that GCE’s contract was awarded on a sole-source basis, that the Coast Guard’s “Commandant directed the consolidation and responsibility of our financial systems from the current program office,” and that the Coast Guard “[was] working on consolidating all financial systems.... When this [was] done[,] it [was] likely to be competed among DHS EAGLE contractors.” 51 Id. Ms. Cor-rea also indicated that although she was “not responsible for the decision to transition the financial systems requirements to [the] OSC or responsible for [its] contracts,” a determination was made within the agency that the financial systems requirement fell within the scope of the SETS II task order. 52 Id.

On November 13, 2007, GCE submitted a memorandum to Ms. Correa questioning the draft PWS of its sole-source bridge contract. Id. at 2932-34. GCE stated that a draft PWS modification removed audit remediation tasks and added system transition tasks that included providing the Coast Guard with “documentation, issues in the issue tracking' system ..., and software managed by [the Coast Guard].” Id. at 2933. GCE noted that it formed and staffed a prototype and analysis team that “for well over three months ha[d] been executing the audit tasks,” id. at 2979, that it worked on remedi-ating “ten material weaknesses” exposed in the Coast Guard’s audit for fiscal year 2005, and that the audit tasks it intended to perform “implement[ed] the gap analysis portion of the agency migration plan,” 53 id. at 2933. *396 It sought clarification as to the rationale behind the removal of audit tasks from its PWS and questioned the ten-day deadline within which it.was required to gather, consolidate, and furnish Enterprise Financial Systems documentation, a time frame it believed was “not sufficient to organize the information in any meaningful way.” Id.

Internal communication indicates that the Coast Guard eliminated these audit tasks due to its “desire to concentrate more fully on strategic transition.” 54 Id. at 2935. However, on November 13, 2007, Ms. Dearing indicated that “[a]lthough it is our right to change our requirements, we must be sure it is not arbitrary. The reasoning for the change should be documented.” Id. GCE believed these changes were “unwise” and perceived them as a reflection of the Coast Guard holding “something personal against GCE.” Id. Moreover, GCE stated that it

does not agree with the removal of these tasks. GCE can only infer from the [Coast Guard’s] actions that the [Coast Guard] is penalizing GCE for raising [its] concerns about the bundling of requirements of [its] contract under the SETS II contract.... GCE, in good faith, staffed up to support this audit work, purchased additional hardware to support the prototyping effort, and continues to execute for over three months. The removal of these tasks will cause significant harm to GCE.

Id. at 2980.

On October 25, 2007, Mr. Bowen, the SETS II Program Manager for the OSC, expressed displeasure to Mr. Lucas over GCE’s apparent “lack of cooperation” with the transition, 55 stating:

It seems we are at [an] impasse on next Monday’s scheduled scoping session. Emails and phone messages ... have gone unanswered_The continued lack of correspondence between our staffs is of great concern to me as the person who is ultimately responsible for the success of CG Financials after April 1st.

Let me be very blunt. I see no future relationship between my contract and GCE if this level of cooperation or lack of cooperation continues_[M]y company is investing in this effort on [its] own nickel and I expect a similar effort on your part if you wish to have any role whatsoever in CG Financials post 1 April 2008. 56

*397 Id. at 2867 (footnote added). Ron Winalski, who was serving as the contracting officer’s technical representative (“COTR”) for the SETS II task order, see id. at 2959, contacted Ms. Correa and informed her of “the failure of GCE to perform to the standards set in the task order,” 57 id. at 2938. GCE, however, indicated that it “cooperate[d] with the [Coast Guard] with respect to the proposed transition tasks_” 58 Id. at 2981.

II. PROCEDURAL BACKGROUND

A. Proceedings Before the GAO

On November 16, 2007, GCE filed with the GAO protest B-310823, wherein it argued that Modification 30 exceeded the scope of the SETS II task order. Id. at 1-102. It then filed “a series of protests after it received a copy of Modification 30, and additional supplemental protests after it learned of the Coast Guard’s December 31, 2007 issuance of Modification 32.” Pl.’s Mot. Prelim. Inj. & TRO 15. GCE filed a total of five supplemental protests: B-310823.2 on November 29, 2007, AR 123-53; B-310823.3 on November 30, 2007, id. at 167-73; B-310823.4 on January 9, 2008, id. at 4165-201; B-310823.5 on January 25, 2008, id. at 4821-32; and B-310823.6 on January 28, 2008, id. at 4833-49. GCE summarized these actions as follows:

Taken together, the protests’ allegations included that Modifications 30 and 32 were unlawful because they were outside the scope of [the] SETS II [task order] and therefore unlawful under the Competition in Contracting Act, and because in issuing the Modifications the Coast Guard had violated various regulations implemented by the Small Business Administration pursuant to the Small Business Act.

Pl.’s Mot. Prelim. Inj. & TRO 15.

The GAO dismissed protest B-310823.3, in which GCE argued that the Coast Guard improperly failed to stay performance of *398 Modification 30 to the SETS II task order, see AR 167-73, on December 3, 2007:

Our bid protest jurisdiction is limited by the Competition in Contracting Act to written objections to a solicitation, proposed award, or award of a contract filed with our Office. Whether or not an agency decides to stay performance is an issue that our Office will not consider, because the stay of performance is a procedural matter that does not involve the validity of an award or selection determination (moreover, GAO also has no authority to enjoin an agency’s action).

Id. at 176 (citation omitted). On January 31, 2008, the GAO dismissed protests B-310823, B-310823.2, and B-310823.4 because it “is generally precluded from considering protests challenging the issuance of task or delivery orders under ID/IQ contracts.” Id. at 4866. Citing the Federal Acquisition Streamlining Act of 1994 (“FASA”), Pub.L. No. 103-355, § 1004 , 108 Stat. 3243 , 3252-53 (1994) (codified at 10 U.S.C. § 2304c(d) (2006) and 41 U.S.C. § 253j(d) (2006)), 59 the GAO concluded that GCE’s protests did “not fit within the exceptions provided in the statute,” thereby divesting it of jurisdiction. AR 4866.

Prior to its January 31, 2008 ruling, the GAO informed the parties that it considered GCE’s supplemental protest B-301823.5 “to be a new protest.” Id. at 4855. Consequently, protest B-301823.5 was “not joined to GCE’s other protests” and was assigned a determination date of May 5, 2008. Id. On January 30, 2008, the GAO joined protest B-310823.6 with protest B-310823.5, “but not [with] GCE’s other protests.” 60 Id. at 4861. “[A]fter learning that the GAO would not be deciding ... these protests on the original 100-day schedule” established by its initial protest, GCE, on February 4, 2008, voluntarily withdrew protests B-310823.5 and B-310823.6. Pl.’s Cross-Mot. & Mot. Perm. Inj. 13; AR 4871; see also Pl.’s Mot. Prelim. Inj. & TRO 16 (“The GAO ... did not dismiss GCE’s final two supplemental protests.”).

B. Proceedings Before The United States Court of Federal Claims (“Court of Federal Claims”)

On March 6, 2008, one month after it withdrew its remaining protests before the GAO, GCE filed its protest in the Court of Federal Claims. 61 Thereafter, QSS intervened pursuant to Rule 24(a) of the Rules of the United States Court of Federal Claims (“RCFC”). The parties subsequently agreed to an expedited briefing schedule based upon the fact that the transition of support services to QSS, absent court action, was scheduled to take effect on April 1,2008. The court heard argument on GCE’s motion for a preliminary injunction and temporary restraining order and granted GCE’s motion.

Following the court’s issuance of a preliminary injunction and temporary restraining order, the parties proposed a schedule for additional briefing and indicated their agreement to extend the temporary restraining order “during any additional briefing period, from midnight, April 9, 2008, through the date on which the Court resolves GCE’s motion for a permanent injunction.” J. Status Report 2, Apr. 3, 2008. The parties then conducted additional briefing, and the court heard argument on GCE’s motion for permanent injunctive relief. During the permanent injunction hearing, QSS renewed its motion to strike GCE’s extra-record evidence, and briefing on QSS’s renewed motion to strike followed. The court’s concurrent ruling ad *399 dresses GCE’s motion to supplement the administrative record, as well as QSS’s motion to sti’ike and renewed motion to strike.

III. LEGAL STANDARDS

A. Bid Protests

The Court of Federal Claims has “jurisdiction to render judgment on an action by an interested party objecting to ... the award of a contract or any alleged violation of statute or regulation in connection with a procurement or a proposed procurement,” 28 U.S.C. § 1491 (b)(1) (2006), and may “award any relief that the court considers proper, including declaratory and injunctive relief except that any monetary relief shall be limited to bid preparation and proposal costs,” id. § 1491(b)(2). Interested parties are those “prospective bidders or offerors whose direct economic interest would be affected by the award of the contract or by failure to award the contract.” Am. Fed’n of Gov’t Employees, AFL-CIO v. United States, 258 F.3d 1294, 1302 (Fed.Ch-.2001) (citing 31 U.S.C. § 3551 (2)(A)). Both the government and QSS challenge the court’s jurisdiction over GCE’s complaint. See Parts IV.A. 1-2, infra.

The court reviews the procuring agency’s action pursuant to the standards set forth in 5 U.S.C. § 706 . 28 U.S.C. § 1491 (b)(4). Although section 706 contains several standards, “the proper standard to be applied in bid protest cases is provided by 5 U.S.C. § 706 (2)(A): a reviewing court shall set aside the agency action if it is ‘arbitrary, capricious, an abuse of discretion, or otherwise not in accordance with law.’” Banknote Corp. of Am. v. United States, 365 F.3d 1345 , 1350 (Fed.Cir.2004). Although “it is well-settled that procurement officials are entitled to broad discretion in the ... application of procurement regulations,” Metcalf Constr. Co. v. United States, 53 Fed.Cl. 617, 622 (2002), the court may set aside a procuring agency’s contract “if either: (1) the procurement official’s decision lacked a rational basis; or (2) the procurement procedure involved a violation of regulation or procedure,” Impresa Construzioni Geom. Domenico Garufi v. United States, 238 F.3d 1324,

This text is long and has been trimmed here. Open the source document for the complete record.