Free Amended Complaint - District Court of Federal Claims - federal

Case 1:07-cv-00631-TCW

Document 16

Filed 01/11/2008

Page 1 of 71

IN THE UNITED STATES COURT OF FEDERAL CLAIMS BEARINGPOINT, INC., Plaintiff, v. THE UNITED STATES OF AMERICA, Defendant. Case No. 07-631(C) (Judge Wheeler)

FIRST AMENDED COMPLAINT BearingPoint, Inc., by counsel, for its First Amended Complaint against the United States of America, alleges as follows: PARTIES 1. Plaintiff BearingPoint, Inc. ("BearingPoint") is a Delaware corporation with its

principal place of business at 1676 International Drive, Tyson's Tower, McLean, VA 22102. 2. Defendant is the United States of America (the "Government"), acting by and

through the United States Department of the Interior and the GovWorks Federal Acquisition Center (collectively "DOI"). JURISDICTION 3. This Court has jurisdiction over the subject matter of this action pursuant to the

Tucker Act, 28 U.S.C. § 1491, and the Contract Disputes Act, 41 U.S.C. §§ 601-613. BACKGROUND 4. This action arises from DOI's improper and unauthorized termination for cause of

Blanket Purchase Agreement No. 73873 (the "BPA") and Task Order 3 (Order No. 0404DO37408) under the BPA. DOI's unlawful terminations for cause of Task Order 3 and the BPA must be converted to terminations for convenience. Alternatively, DOI's actions, described

Case 1:07-cv-00631-TCW

Document 16

Filed 01/11/2008

Page 2 of 71

below, individually represent material breaches of Task Order 3, and combined represent a material breach of the contract's implied duty of cooperation. 5. The BPA contemplated the performance of software implementation and other

related services in connection with a Department-wide enterprise resource planning ("ERP") integrated software solution to be known as the Financial and Business Management System ("FBMS"). Task Order 3 required BearingPoint to implement FBMS functionality at three (3) DOI Bureaus. 6. Because the BPA left open the design decisions antecedent to implementation of

the BPA, and due to the complex subject matter of the procurement, cooperation between the parties was essential to successful performance. Notwithstanding this heightened need for cooperation, DOI consistently failed, for example, to make critical design and other decisions in a timely manner, to provide indispensable information and resources within its exclusive possession, and to make available personnel and facilities in accordance with its express contractual requirements. DOI's conduct in this regard delayed the work under Task Order 3, making it impossible to complete the Task Order 3 work in a timely fashion. 7. Notwithstanding its responsibility for BearingPoint's inability to render timely

performance, BearingPoint's repeated assertions that the resulting performance delays were excusable, and the clear regulatory and contractual requirement to refer the assertion of excusable delay to BearingPoint's General Services Administration ("GSA") Schedule Contracting Officer, the DOI Contracting Officer took it upon herself to issue a Contracting Officer's Final Decision terminating Task Order 3 for cause and ordered BearingPoint to vacate immediately the premises. Weeks later, she issued a second Contracting Officer's Final

W02-EAST:9CML1\200053207.3

-2-

Case 1:07-cv-00631-TCW

Document 16

Filed 01/11/2008

Page 3 of 71

Decision terminating the BPA for cause based, in part, upon BearingPoint's inability to perform additional work under the BPA absent the completion of Task Order 3. 8. On July 28, 2006, BearingPoint submitted a properly certified claim to both the

GSA and DOI Contracting Officers seeking monetary compensation under various theories, including breach of contract, resulting from the improper actions of DOI. 9. BearingPoint filed suit in the United States Court of Federal Claims ("Court of

Federal Claims" or the "Court") on September 26, 2006, challenging solely the DOI Contracting Officer's Final Decisions to terminate for cause Task Order 3 and the BPA, and immediately filed a motion to dismiss its Complaint for lack of subject matter jurisdiction based on the DOI Contracting Officer's failure to follow required procedures. 10. On January 16, 2007, the DOI Contracting Officer issued a Final Decision

denying BearingPoint's certified claim for monetary compensation and, in the process, reasserted her position that the terminations for default of Task Order 3 and the BPA were proper. 11. On April 30, 2007, the Court granted BearingPoint's Motion to Dismiss its

Complaint, holding that DOI's purported terminations of Task Order 3 and the BPA for cause were improper and exceeded the scope of the DOI Contracting Officer's authority because she was required to refer BearingPoint's assertions of excusable delay to BearingPoint's GSA Schedule 70 Contracting Officer for a final decision. See BearingPoint, Inc. v. United States, 77 Fed. Cl. 189 (2007). As a result, the Court dismissed the Complaint, as requested by BearingPoint. 12. BearingPoint filed the present action on August 24, 2007 seeking monetary

compensation in accordance with its certified claim. The Government filed a Motion to Stay for the Purpose of a Remand to the General Services Administration on October 18, 2007. On

W02-EAST:9CML1\200053207.3

-3-

Case 1:07-cv-00631-TCW

Document 16

Filed 01/11/2008

Page 4 of 71

November 9, 2007, the Court granted the Government's motion, ordering, inter alia, that "GSA's Contracting Officer shall issue a final decision within 40 days, on or before December 19, 2007." 13. On December 19, 2007, the GSA Contracting Officer issued a purported Final

Decision that, among other things, denied all but one of BearingPoint's claims of excusable delay, concluded that DOI's Final Decision to terminate for cause Task Order 3 was proper, and purported to deny the BearingPoint July 28, 2006 certified claim. 14. In this action, BearingPoint seeks relief from DOI's improper and unauthorized

terminations of the BPA and Task Order 3 for cause. As delineated below, BearingPoint requests that the Court: a. Hold that the GSA Contracting Officer's December 19, 2007 Final

Decision was erroneous and inconsistent with law; b. Hold that the purported termination for cause of Task Order 3 was

improper because (i) any delay in performance was due to excusable delay, (ii) the delivery schedule for Task Order 3 was waived, and/or (iii) BearingPoint's performance complied with all material requirements of the contract; c. Hold that the purported termination for cause of the BPA was improper

because (i) the BPA is not a contract, (ii) any delay in performance was due to excusable delay, and/or (iii) BearingPoint's performance complied with all BPA requirements; d. Hold that, to the extent it is not a nullity, the DOI Contracting Officer's

January 16, 2007 Final Decision denying BearingPoint's certified claim was erroneous and inconsistent with law;

W02-EAST:9CML1\200053207.3

-4-

Case 1:07-cv-00631-TCW

Document 16

Filed 01/11/2008

Page 5 of 71

e.

Hold that the procedurally defective and improper terminations for cause

of Task Order 3 and the BPA were converted to terminations for convenience as a matter of law pursuant to FAR 52.212-4(m); f. Hold that the procedurally defective and improper terminations for cause

of Task Order 3 and the BPA were otherwise improper and, therefore, deemed to be terminations for convenience (or, in the alternative, find that DOI's actions amounted to breaches of contract), entitling BearingPoint to $16,522,063 in termination for convenience costs or, in the alternative, $19,842,777 in breach of contract damages; g. h. Provide an increase in the Task Order 3 contract price of $5,038,000; Find that Task Order 3 expired on April 6, 2005, and the Contracting

Officer's direction to perform without a valid contract was a breach of contract (or, alternatively, a constructive change) for which BearingPoint is entitled to an equitable adjustment in the amount of $19,842,777; and/or i. Determine that BearingPoint is entitled to payment of $19,842,777 for

work delivered to, and accepted by, DOI in accordance with DOI direction. Blanket Purchase Agreement Request for Quotations 15. On August 7, 2003, DOI issued Request for Quotations No. 73873 (the "RFQ").

The RFQ solicited quotations for the implementation of a commercial off-the-shelf ("COTS") ERP software package and related hardware and services to integrate DOI's administrative systems and operations. The resulting integrated solution was to be known as the FBMS. 16. The RFQ informed offerors that DOI intended to "use FAR Part 8 procedures" to

issue a BPA, with one (1) base year and up to nine (9) option years, against the awardee's GSA

W02-EAST:9CML1\200053207.3

-5-

Case 1:07-cv-00631-TCW

Document 16

Filed 01/11/2008

Page 6 of 71

Schedule 70 contract. The RFQ further provided that the terms and conditions of the awardee's GSA Schedule 70 contract would apply to the resulting BPA. 17. A GSA Schedule BPA is a simplified method of filling anticipated repetitive

needs for supplies or services by establishing a "charge account" under a contractor's GSA Schedule contract. Acquiring agencies, such as DOI, compete, negotiate, and award GSA Schedule BPAs pursuant to FAR Part 8 and then, subsequently, issue Task Orders, also pursuant to FAR Part 8, as the need arises. 18. Consistent with FAR Part 8, the RFQ explained that DOI intended to procure

equipment, software, and services for implementation of FBMS by issuing firm fixed-price Task Orders under the BPA. The RFQ provided further that deliverables under these Task Orders would be determined by mutual agreement of the Government and the Contractor. In addition, the RFQ contemplated the post-award addition of new tasks and the incorporation of future requirements and mandated changes unknown at the time of award. 19. The RFQ indicated that FBMS was to be a Department-wide solution. In this

regard, the RFQ informed offerors that FBMS would integrate the following business functions throughout the Office of the Secretary ("OS") and each of DOI's eight (8) Bureaus: Budget Formulation, Core Financials, Acquisition, Personal Property and Fleet Management, Travel, Financial Assistance, Real Property, and Enterprise Management Information. DOI's Bureaus include the Bureau of Land Management ("BLM"), the Minerals Management Service ("MMS"), the Office of Surface Mining, Reclamation, and Enforcement ("OSM"), the Bureau of Reclamation ("BOR"), the United States Geological Survey ("USGS"), the United States Fish and Wildlife Service ("FWS"), the National Park Service ("NPS"), and the Bureau of Indian Affairs ("BIA").

W02-EAST:9CML1\200053207.3

-6-

Case 1:07-cv-00631-TCW

Document 16

Filed 01/11/2008

Page 7 of 71

20.

The RFQ identified the following "project specific objectives" for the BPA: · Implement a Department-wide solution that will standardize and integrate financial and business management processes while meeting all applicable current and future security and privacy requirements. Provide business intelligence and analytic capabilities to financial and business management processes to strengthen decision-making capabilities to more effectively carry out the Department's missions. Ensure financial and business management data and transactions are recorded properly, accurately, timely, and efficiently with strong internal controls. Satisfy critical and routine, internal and external requests for financial and business management related information and data. Provide a solution that economically and efficiently leverages technology over the solution's life cycle and accommodates changes in federal laws, regulations, and financial and business management mandates. Implement, reform, and streamline key financial and business management processes building on available government and industry best practices to improve performance and reduce operating costs. Provide a solution that fosters employee retention, professionalism, creativity, excellence, and implements cultural transformation within Interior's financial and business management communities. Implement an effective document and records management solution for financial and business management activities that meet standard records management requirements. Enable an effective migration from the legacy environment to the new financial and business management solution through available risk minimization techniques. Provide a solution with the capability to balance financial and business management workload across DOI.

·

·

· ·

·

·

·

·

·

RFQ, Enclosure 1 at § 3.2.2. 21. Although the RFQ identified "definitions of success" and "sample performance

measures" for each project specific objective, no specifications or requirements were included in

W02-EAST:9CML1\200053207.3

-7-

Case 1:07-cv-00631-TCW

Document 16

Filed 01/11/2008

Page 8 of 71

the RFQ. Instead, offerors were instructed to prepare a Statement of Work describing how their solutions would meet the RFQ's stated objectives. 22. The RFQ also required each offeror to propose a Quality Assurance and

Surveillance Plan ("QASP"). For each project-specific objective set forth in the RFQ, the QASP was required to identify the proposed performance standard, acceptable level of performance, surveillance methodology, and associated financial incentives and disincentives for performance. 23. The RFQ contemplated that the awardee's proposed solution would be subject to

changes in design and pricing as the FBMS project progressed. BearingPoint's Quotation 24. BearingPoint submitted its quotation for the BPA (the "BPA Quotation") on

October 10, 2003. 25. BearingPoint proposed to use the "mySAP Business Suite" as the core software

solution, together with a number of other tightly integrated COTS applications, including CompuSearch "PRISM" software for the Acquisition business function, and STR "eGrantsPlus" software for the Financial Assistance business function. Further, BearingPoint proposed to use IXOS "Document Manager" as an infrastructure for DOI's document management, imaging, and archival needs. 26. The BPA Quotation placed DOI on notice that BearingPoint's initial design

concept for the FBMS system was preliminary in nature and that changes likely would occur during performance of the Task Orders. For example, the BPA Quotation included the following admonition: "Understand that our view of the architectural landscape will be refined as the final environment evolves." BPA Quotation, Volume II, Tab 1 at § 1.2 (emphasis added). 27. BearingPoint did not propose, because the RFQ did not call for, a firm fixed-price

for the BPA. Instead, the BPA Quotation set forth fixed-price hourly labor rates that would be -8-

W02-EAST:9CML1\200053207.3

Case 1:07-cv-00631-TCW

Document 16

Filed 01/11/2008

Page 9 of 71

used as the basis for negotiating the fixed-price Task Orders. These rates were based upon two levels of discounts from BearingPoint's GSA Schedule 70 rates. BearingPoint offered DOI a global 10% discount across all proposed labor categories. In addition, BearingPoint offered incremental volume discounts across all individual labor category rates. In offering these two levels of discounts, the company made clear to DOI that its approach was based upon an anticipated labor staffing mix and a projected labor mix. 28. BearingPoint also offered different rates for work performed at Government

facilities and work performed at contractor facilities. Specifically, BearingPoint proposed a 4.5% discount against FBMS Bid Rates to reflect Government Site Rates. This difference is reflected in Section 2.4.5 of BearingPoint's Business Quotation, entitled "Final Proposed BPA Rates," which lists both the "Proposed Program BPA Contractor Site Rate" and the "Proposed Program BPA Government Site Rate." Id. (emphasis added). In response to DOI's questions regarding the BPA Quotation, BearingPoint clarified the use of these different rates as follows: As stated in our proposal, the BearingPoint Team has proposed both on-site and off-site rates allowing DOI to select which option best fits its perspective and facility capabilities for hosting the entire project team. Responses to DOI FBMS Questions, Question 99 (November 13, 2003) (emphasis added). 29. The BPA Quotation further contemplated that travel would be billed on a cost-

reimbursement basis, in accordance with the Joint Travel Regulations and GSA Domestic Maximum Per Diem Rates. No cap on travel costs was included in the BPA Quotation or the BPA itself. 30. BearingPoint's proposed QASP placed all of BearingPoint's system integration

labor fees and approximately 15% of its system integration direct costs into a pool that would be

W02-EAST:9CML1\200053207.3

-9-

Case 1:07-cv-00631-TCW

Document 16

Filed 01/11/2008

Page 10 of 71

awarded to BearingPoint, as a matter of right, if it met certain metrics for system deployment and defined levels of customer satisfaction. BPA Award to BearingPoint 31. On January 5, 2004, DOI awarded BPA No. 73873 to BearingPoint. The award

document was designated by DOI as a GSA Schedule "Blanket Purchase Agreement" and prepared by DOI using GSA's standard Schedule BPA template. Although the BPA included labor hour and cost estimates, the award document did not obligate any funds or require DOI to purchase a minimum number of labor hours. 32. The BPA expressly incorporated BearingPoint's BPA Quotation, oral

presentations, answers to DOI's questions, and GSA Schedule 70 contract. In addition, the BPA provided that all orders placed against the BPA would be subject to the terms and conditions of BearingPoint's GSA Schedule Contract. 33. The BPA provided that travel would be funded on a cost-reimbursement basis in

accordance with the Joint Travel Regulations. The BPA did not specify a limit on the total amount of travel costs that DOI would be required to reimburse. 34. The BPA together with the BearingPoint GSA 70 Schedule Contract,

incorporated the following relevant terms and conditions: Default. In addition to any other clause contained herein related to termination, the following is applicable to orders placed under Federal Supply Schedule contracts. Any ordering office may, with respect to any one or more orders placed by it under the contract, exercise the same right of termination, acceptance of inferior articles or services, and assessment of excess costs as might the Contracting Officer, except that when failure to deliver articles or services is alleged by the Contractor to be excusable, the determination of whether the failure is excusable shall be made only by the Contracting Officer of the General Services Administration, to whom such allegation shall be referred by the ordering office and from whose -10-

W02-EAST:9CML1\200053207.3

Case 1:07-cv-00631-TCW

Document 16

Filed 01/11/2008

Page 11 of 71

determination appeal may be taken as provided in the clause of this contract entitled "Disputes." Default (I-FSS-249-B) (May 2000) (emphasis added). (c) Changes. Changes in the terms and conditions of this contract may be made only by written agreement of the parties. (d) Disputes. This contract is subject to the Contract Disputes Act of 1978, as amended (41 U.S.C. 601-613). Failure of the parties to this contract to reach agreement on any request for equitable adjustment, claim, appeal or action arising under or relating to this contract shall be a dispute to be resolved in accordance with the clause at FAR 52.233-1, Disputes, which is incorporated herein by reference. The Contractor shall proceed diligently with performance of this contract, pending final resolution of any dispute arising under the contract. * * * (f) Excusable delays. The Contractor shall be liable for default unless nonperformance is caused by an occurrence beyond the reasonable control of the Contractor and without its fault or negligence such as, acts of God or the public enemy, acts of the Government in either its sovereign or contractual capacity, fires, floods, epidemics, quarantine restrictions, strikes, unusually severe weather, and delays of common carriers. The Contractor shall notify the Contracting Officer in writing as soon as it is reasonably possible after the commencement of any excusable delay, setting forth the full particulars in connection therewith, shall remedy such occurrence with all reasonable dispatch, and shall promptly give written notice to the Contracting Officer of the cessation of such occurrence. * * * (l) Termination for the Government's convenience. The Government reserves the right to terminate this contract, or any part hereof, for its sole convenience. In the event of such termination, the Contractor shall immediately stop all work hereunder and shall immediately cause any and all of its suppliers and subcontractors to cease work. Subject to the terms of this contract, the Contractor shall be paid a percentage of the contract price reflecting the percentage of the work performed prior to the notice of termination, plus reasonable charges the Contractor can demonstrate to the satisfaction of the Government using its standard record keeping system, have resulted from the

W02-EAST:9CML1\200053207.3

-11-

Case 1:07-cv-00631-TCW

Document 16

Filed 01/11/2008

Page 12 of 71

termination. The Contractor shall not be required to comply with the cost accounting standards or contract cost principles for this purpose. This paragraph does not give the Government any right to audit the Contractor's records. The Contractor shall not be paid for any work performed or costs incurred which reasonably could have been avoided. (m) Termination for cause. The Government may terminate this contract, or any part hereof, for cause in the event of any default by the Contractor, or if the Contractor fails to comply with any contract terms and conditions, or fails to provide the Government, upon request, with adequate assurances of future performance. In the event of termination for cause, the Government shall not be liable to the Contractor for any amount for supplies or services not accepted, and the Contractor shall be liable to the Government for any and all rights and remedies provided by law. If it is determined that the Government improperly terminated this contract for default, such termination shall be deemed a termination for convenience. * * * FAR 52.212-4, Contract Terms and Conditions ­ Commercial Items (Feb 2002) (emphasis added). Task Order 1 35. DOI did not utilize the task structure set forth in the BPA, but instead required

BearingPoint to submit a new proposal prior to the award of each Task Order. Consequently, each Task Order issued by DOI incorporated a different mix of effort and a different performance schedule from that initially quoted by BearingPoint in the BPA Quotation. 36. BearingPoint submitted its proposal for Task Order 1 ("Task Order 1 Proposal")

to DOI on January 9, 2004. 37. The Task Order 1 Proposal included efforts related to the design of various

components of the FBMS architecture and preparation of certain reports and plans preliminary to the implementation of FBMS. Illustrative deliverables included: (1) a Project Charter summarizing the activities, time frame, scope, procedures, and resources applicable to the

W02-EAST:9CML1\200053207.3

-12-

Case 1:07-cv-00631-TCW

Document 16

Filed 01/11/2008

Page 13 of 71

development of FBMS; (2) a Departmental Business Blueprint describing the high-level design of the Department-wide elements of FBMS; and (3) an Architecture Report providing a highlevel strategic design of issues such as data conversion, interfaces, technical infrastructure migration, and system integration. 38. DOI awarded Task Order 1 (Order No. 33532) to BearingPoint on January 22,

2004. The award document, which incorporated the Task Order 1 Proposal and the BPA, specified a firm-fixed-price of $2,830,102.79, plus travel costs to be billed on a costreimbursement basis. The period of performance for Task Order 1, as modified, extended through April 23, 2004. 39. Because the RFQ did not specify the requirements that BearingPoint's software

would be required to meet, it was necessary for BearingPoint to work with DOI during Task Order 1 to define those requirements. This task was to be accomplished through meetings, known as "workshops," between BearingPoint personnel and DOI personnel. During the workshops, it became apparent that DOI's eight Bureaus had different and conflicting requirements. 40. DOI has accepted and paid for all work performed under Task Order 1. Task Order 2 41. BearingPoint submitted its final proposal ("Task Order 2 Proposal") for Task 1A

("Task Order 2"), which, subsequently, the parties commonly referred to as Task Order 2, on June 25, 2004. 42. The Task Order 2 Proposal included BearingPoint's response to DOI's instruction

to extend the review period for the Departmental Business Blueprint. As a result of the extended review period, BearingPoint's Task Order 2 Proposal set forth a revised implementation schedule. Pursuant to that revised schedule: -13-

W02-EAST:9CML1\200053207.3

Case 1:07-cv-00631-TCW

Document 16

Filed 01/11/2008

Page 14 of 71

a. 2004. b.

The Departmental Business Blueprint was to be completed by July 7,

Deployment 1A, to go live by February 28, 2005, was to implement

Financial Assistance functionality at MMS, OSM and FWS. c. Deployment 1B, for which no go live date was provided in BearingPoint's

proposal, was to implement Travel functionality following DOI's selection of a travel application vendor. d. Deployment 2A, to go live by October 1, 2005, was to implement Core

Financials, Property, Acquisition, PCS, and EMIS functionality at BLM, OSM, and MMS. e. Deployment 2B, to go live by November 1, 2005, was to implement

Budget Formulation and Budget Planning functionality at BLM, OSM, and MMS. f. Deployment 3 was to implement FBMS functionality in all functional

areas at FWS, NPS and OS, and was to go live by November 1, 2006. g. Deployment 4 was to implement all functional areas at USGS, BOR and

BIA, and was to go live by October 1, 2007. 43. The scope of the Task Order 2 Proposal included additional activities preliminary

to Deployments 1A and 2A, activities that were not part of the BPA Quotation. 44. DOI issued Task Order 2 (Order No. 35880) to BearingPoint on June 28, 2004.

The award document, which incorporated the Task Order 2 Proposal and the BPA, specified a period of performance through July 31, 2004. Task Order 2 was awarded with a firm fixed-price of $4,434,960.00, plus reimbursement of certain other direct costs, including travel.

W02-EAST:9CML1\200053207.3

-14-

Case 1:07-cv-00631-TCW

Document 16

Filed 01/11/2008

Page 15 of 71

45.

BearingPoint submitted the revised Departmental Business Blueprint to DOI on

July 15, 2004. The revised blueprint, accepted by DOI in October 2004, included a list of proposed requirements that FBMS would be required to meet. 46. DOI has accepted and paid for all work performed under Task Order 2. Task Order 3 BearingPoint's Task Order 3 Proposal 47. BearingPoint submitted its initial proposal for Task Order 3 on July 15, 2004.

Task Order 3 was to include Deployments 1A, 2A, and 2B. In addition, BearingPoint's initial proposal for Task Order 3 included certain interfaces and other additional work, not contemplated by the RFQ or the BPA, that were identified by DOI during Task Orders 1 and 2. 48. Following lengthy negotiations and multiple proposal revisions, the parties agreed

that the additional work identified during Task Orders 1 and 2 would be removed from the scope and price of Task Order 3 and included in BearingPoint's proposal as a list of options that DOI could add to the Task Order at a later date ("Options List"). The Task Order 3 Proposal contemplated that these optional items would be proposed, priced, and added to Task Order 3, if at all, as bilateral changes. The parties subsequently agreed to a change order process whereby BearingPoint would draft so-called "White Papers" to address these and other potential changes to Task Order 3. 49. BearingPoint submitted the final version of its proposal for Task Order 3 on

September 17, 2004. 50. The scope of the Task Order 3 Proposal included implementation of Deployments

1A, 2A, and 2B in accordance with the schedule set forth in its Task Order 2 Proposal. For each of these deployments, BearingPoint's proposal identified the data to be converted and the interfaces to be provided to DOI. -15-

W02-EAST:9CML1\200053207.3

Case 1:07-cv-00631-TCW

Document 16

Filed 01/11/2008

Page 16 of 71

51.

The terms of the Task Order 3 Proposal required DOI to make decisions in a

timely manner and included specific timeframes in which DOI was required to make certain types of decisions. In this regard, the Task Order 3 Proposal included the following requirements: a. "Design resolution (direction on process procedures) will occur within 72

hours of PMO [Program Management Office] notification to ESC [Executive Steering Committee] of the design gap or design issue." Task Order 3 Proposal at § 4.1. b. "The Executive Steering Committee . . . will review business issues and

make timely decisions." Id. c. "Critical Business Issues will be resolved in 3 business days." Id. Task

Order 3 Proposal at § 4.3.1. d. "DOI will make business decisions within 48 hours for any escalated gap

that should be resolved through either process redesign or enhancements. On an exception basis only, BearingPoint Team understands that some decisions . . . will take no longer than 5 business days." Id. 52. BearingPoint expressly conditioned its proposal on the predicate that "DOI

project team members will be empowered to make strategic and programmatic decisions on behalf of the entire DOI users community without necessity for consensus." Task Order 3 Proposal at § 4.3.1. The Task Order 3 Proposal required DOI to make a decision regarding which entity would be responsible for hosting (i.e., providing facilities, hardware, applications support, and operating support) for the FBMS infrastructure by August 13, 2004. The proposal also placed DOI on notice that its failure to make a timely hosting decision could delay the project. Id. at § 4.3.

W02-EAST:9CML1\200053207.3

-16-

Case 1:07-cv-00631-TCW

Document 16

Filed 01/11/2008

Page 17 of 71

53.

The Task Order 3 Proposal included specific requirements regarding the number

and categories of personnel that both DOI and its Bureaus would be required to devote to the FBMS project. For example, DOI was required to dedicate to the FBMS Project ­ on a full time basis ­ one subject matter expert ("SME") per Bureau for each of 13 enumerated functional areas. In addition, BearingPoint's Task Order 3 Proposal required DOI to devote full time technical experts to each of those functional areas. 54. The Task Order 3 Proposal placed DOI on notice that the flow of information

between the parties would be crucial to the success of the FBMS project. In this regard, BearingPoint's proposal included the following predicates and assumptions: a. "DOI will provide all necessary software licenses and information for any

current products that may be reused." Task Order 3 Proposal at § 4.1. b. "DOI will provide access to databases, records, information, data, file

layouts, as required, to support this project." Id. c. "DOI will make available to the BearingPoint Team, for reference, all

current systems and functional documentation such as narratives, process flows, technical architectures, and application data models." Id. 55. The Task Order 3 Proposal stated that "the performance location for all work is

assumed to be government facilities with the appropriate network connectivity." Task Order 3 Proposal at § 4.3.1. 56. The Task Order 3 Proposal clarified that the implementation of any customized

functionality not embedded in the delivered software solution, as well as any changes to the system proposed by DOI after approval of the Functional Design Specifications ("FDSs") and Technical Design Specifications ("TDSs"), would constitute changes to the Task Order.

W02-EAST:9CML1\200053207.3

-17-

Case 1:07-cv-00631-TCW

Document 16

Filed 01/11/2008

Page 18 of 71

57.

The Task Order 3 Proposal included the following acceptance provision: When the BearingPoint Team provides the client with draft deliverables, DOI will have five (5) business days to review and approve or request changes and BearingPoint will have five business days to incorporate feedback into the final. Requested changes will be specific in nature. Deliverables not explicitly accepted or rejected by DOI within the time period allotted will be deemed accepted.

Task Order 3 Proposal at § 4.3.1. 58. BearingPoint's proposed firm fixed price for Task Order 3 was $26,353,263 plus

a holdback of $3,952,990 for the performance incentive incorporated into BearingPoint's QASP. Task Order 3, Proposal at § 6.3. BearingPoint's proposal also included an estimate for other direct costs, including travel ($2,619,853) and certain hardware ($245,070), to be provided on a cost-reimbursement basis. Id. The proposal did not specify a cap on travel costs. Award to BearingPoint 59. Task Order 3 (Order No. 0404DO37408) was issued to BearingPoint on

September 20, 2004. The award document incorporated BearingPoint's Task Order 3 Proposal and the terms and conditions of the BPA. Task Order, Block 17. 60. The award document indicated that Task Order 3 would be funded incrementally.

The funding for Task Order 3, as awarded, was $7,800,000. Deployment 1A 61. Deployment 1A required BearingPoint to implement Financial Assistance

functionality at MMS, OSM, and FWS by February 28, 2005. 62. 63. Deployment 1A went live on March 1, 2005. BearingPoint was required to provide technical support for Financial Assistance

functionality for 30 days following the go live date for Deployment 1A. DOI, however, continued to rely on BearingPoint for support well beyond the contractual 30 day transition

W02-EAST:9CML1\200053207.3

-18-

Case 1:07-cv-00631-TCW

Document 16

Filed 01/11/2008

Page 19 of 71

period. As a result, BearingPoint's Financial Assistance team was required to divert critical resources away from activities related to Deployment 2A. Deployment 2A 64. Deployment 2A required BearingPoint to implement Core Financials, Property,

and Acquisition Functionality at BLM, OSM, and MMS by October 1, 2005. 65. From the outset, Deployment 2A was plagued with delays caused by DOI.

DOI's Failure to Approve Functional Design Specifications for Interfaces 66. Commercial ERP packages such as SAP generally provide functionality for most,

but not all, of the business processes of a large and complex organization such as DOI. In particular, software integrators frequently must design and develop customized code for enhancements, interfaces to external applications, data conversion, and custom reports. 67. In general terms, the accepted procedure for designing, developing, and testing

customized software functionality is as follows: a. The software integrator first prepares a Functional Design Specification

("FDS"), which provides high level, technical descriptions of what the software must accomplish and how it must perform. b. After the FDS has been finalized, the integrator prepares a Technical

Design Specification ("TDS"), which describes the functionality at a more detailed technical level. Because TDSs are derived from, and depend upon, FDSs, it is standard industry practice to finalize an FDS before work on the corresponding TDS begins. c. Once the TDS has been accepted, the integrator writes the code that will

implement the customized functionality. The integrator then performs unit testing, which tests the functionality in isolation from other components of the system.

W02-EAST:9CML1\200053207.3

-19-

Case 1:07-cv-00631-TCW

Document 16

Filed 01/11/2008

Page 20 of 71

d.

Integration testing is performed after all application components are

configured and the programs have been unit tested. Integration testing tests the end-toend business process of an entire system. 68. BearingPoint's Project Plan, a deliverable accepted by DOI on November 14,

2004, contemplated that development and testing would proceed in accordance with the sequence described above. In this regard, the Project Plan identified "sign off" of each FDS as a "predecessor" to the development of the corresponding TDS, and "sign off" and baselining of each TDS as the "predecessor" to development and testing of the corresponding functionality. The Project Plan further provided that DOI would approve most FDSs within one day of submission. 69. For the FBMS project, customizations to SAP were required for interfaces to

numerous external applications. In many cases, DOI failed to approve the FDSs for these interfaces, either because DOI continued to add functionality or because it was unable to make timely decisions regarding the nature of the functionality it required. In other cases, DOI approved FDSs, but continued to request changes after they were accepted and baselined. 70. BearingPoint timely notified DOI of delays associated with its failure to approve

BearingPoint's FDSs in weekly status reports, meetings and email correspondence. Weekly status reports were jointly prepared by DOI and BearingPoint. The weekly status reports, among other things, identified areas of performance and schedule risk. The levels of criticality for each schedule risk was identified in clear language with a clear color-code. Each week, BearingPoint and DOI personnel met to review the weekly status report in detail. This was the notification process agreed to and utilized by the parties throughout the FBMS project.

W02-EAST:9CML1\200053207.3

-20-

Case 1:07-cv-00631-TCW

Document 16

Filed 01/11/2008

Page 21 of 71

71.

Because the Project Plan did not provide for preparation of a TDS until DOI

approved the corresponding FDS, or for development until DOI approved the TDS, delays associated with DOI's approval of the FDSs impacted the overall project schedule for Deployment 2A. Changes made to an interface after acceptance of the FDS also impacted the project schedule by requiring BearingPoint to revise the FDS and TDS and code the change. 72. The following examples illustrate the delays occasioned by DOI's failure to

timely approve and finalize the FDSs for various FBMS interfaces. a. BearingPoint submitted its proposed FDS for the FBMS interface to the

Federal Personnel and Payroll System ("FPPS") by the first week of November 2004. Completion and approval of the FDS, however, was delayed by DOI's failure to make a decision regarding how to resolve an issue associated with the interface's 23 character field limitation. Although BearingPoint's Status Reports repeatedly notified DOI of the need for a decision regarding this issue, no such decision was forthcoming from DOI. Even after the FPPS interface was "finalized" in mid-January 2005, DOI continued to request changes to the interface through August 2005, months after the date for acceptance identified in BearingPoint's approved Project Plan. BearingPoint informed DOI that these design changes would require a long development time and could delay the October 1 "go live" date. Nevertheless, DOI chose to proceed with the changes. These delays and continuing changes directly impacted BearingPoint's ability to timely complete Deployment 2A. b. BearingPoint submitted its proposed FDS for the FBMS interface to

MAXIMO, an external application for inventory and asset management, on November 1, 2004. DOI continued to request revisions to the MAXIMO interface for approximately

W02-EAST:9CML1\200053207.3

-21-

Case 1:07-cv-00631-TCW

Document 16

Filed 01/11/2008

Page 22 of 71

eight months. BearingPoint notified DOI of these delays and the impact on the program schedule in weekly status reports beginning in December 2004 and continuing through June 2005. Further, status reports provided in February 2005 and March 2005 placed DOI on notice that BearingPoint had been forced to commence work on the MAXIMO TDSs before DOI finalized the corresponding FDSs. These delays and continuing changes directly impacted BearingPoint's ability to timely complete Deployment 2A. Data Conversion Delays Caused by DOI 73. DOI failed to timely approve numerous data conversion FDSs submitted by

BearingPoint, thereby delaying the data conversion process. DOI also failed to fulfill its obligations with respect to the Portal and Interfaces, including, but not limited to, making a timely encryption decision. In addition, BearingPoint could not complete certain data conversion FDSs because DOI attempted to require BearingPoint to transform historical data in a manner that was not within the scope of Task Order 3. 74. The various Bureaus also delayed data conversion by failing to provide

BearingPoint with usable data/extracts for executing mock conversions, attempting to require BearingPoint to comply with audit standards that exceeded the scope of Task Order 3, and unilaterally declining to assist BearingPoint during certain "blackout" periods. 75. BearingPoint timely notified DOI of delays associated with data conversion in

weekly status reports and email correspondence. 76. DOI precluded timely completion of the data conversion process. Delays

associated with data conversion, in turn, delayed the overall completion of Deployment 2A.

W02-EAST:9CML1\200053207.3

-22-

Case 1:07-cv-00631-TCW

Document 16

Filed 01/11/2008

Page 23 of 71

DOI's Failure to Baseline System Requirements in a Timely Manner 77. In the software design and implementation context, a "requirement" refers to a

function that the software must perform. Examples of requirements include the ability to collect particular data, to interface with particular systems, and to generate particular reports. a. Requirements are the foundation for software design and implementation.

Because software must be designed or configured to meet the requirements, the requirements must be agreed upon, or "baselined," before development and configuration begin. b. Requirements also define the scope of a software implementation, i.e.,

what functions the software must perform, and constitute the criteria against which the software is to be tested. c. Once the software integrator and the client have "baselined" the

requirements, either the system must be configured to meet those requirements or an FDS and TDS must be written and custom code must be designed and developed. The integrator then prepares "test scripts" that will be used to verify compliance of the code with the baselined requirements. Each requirement must be linked to a test script that defines how the software should respond to a specified input. If, upon entering the input specified in the test script, the desired output is obtained, then the designed or configured software meets the requirement to which the test script is linked. 78. BearingPoint's BPA Quotation and Task Order 3 Proposal, in accordance with

applicable industry standards, required the parties to baseline requirements before the commencement of integration testing. Further, BearingPoint's Requirements Management Plan, a deliverable first submitted by BearingPoint in late 2004 and belatedly accepted by DOI on April 15, 2005, provided that the requirements would be baselined by April 30, 2005. -23-

W02-EAST:9CML1\200053207.3

Case 1:07-cv-00631-TCW

Document 16

Filed 01/11/2008

Page 24 of 71

79.

BearingPoint provided an initial list of requirements to DOI as an attachment to

the Departmental Business Blueprint and submitted revised requirements lists in September 2004 and February 2005. 80. Despite multiple requests from BearingPoint, DOI made little effort to review

BearingPoint's proposed requirements for several months. DOI took no serious interest in the requirements submittals until late May 2005, over a month after the baselining was required to be completed. Further, DOI continued to add Property requirements until September 2005, approximately five (5) months after the deadline for baselining specified in the Requirements Management Plan, eight (8) months after BearingPoint submitted its revised requirements list to DOI, and approximately one month prior to the scheduled "go live" for Deployment 2A. In addition, many of the additional Property requirements proposed by DOI were not within the scope of Task Order 3, as DOI ultimately conceded. 81. BearingPoint timely notified DOI of the need to baseline the requirements in

weekly status meetings held in November and December 2004. DOI was advised of the need to finalize the requirements baseline, and the delays being experienced, in status reports between May and September 2005. Further, in April 2005, BearingPoint verbally informed DOI that it could not begin integration testing as scheduled because the requirements had not been baselined. The Test Readiness Review ("TRR"), conducted on May 25, 2005, provided DOI with additional notice of the need to baseline the requirements. 82. On November 5, 2004, DOI's Independent Verification and Validation Contractor

advised DOI of the need to promptly baseline DOI's requirements, and delineated to DOI various adverse consequences that might occur if it failed to do so.

W02-EAST:9CML1\200053207.3

-24-

Case 1:07-cv-00631-TCW

Document 16

Filed 01/11/2008

Page 25 of 71

83.

DOI's delay in baselining the Property requirements alone delayed Deployment

2A by at least four (4) months. Extensive negotiations regarding the Property requirements also diverted key BearingPoint resources from other tasks, thereby causing additional delays. DOI's Failure to Approve and Fund White Papers in a Timely Manner 84. During the FBMS project, BearingPoint prepared approximately 80 "White

Papers" designed to facilitate DOI's ability to make certain decisions about the project. Each White Paper explained an issue relevant to the project, analyzed DOI's options, and presented BearingPoint's recommendations. 85. The parties agreed to written procedures for the submission and review of White

Papers in November 2004. Pursuant to those procedures, DOI was required to resolve the issues identified in a White Paper by the "Critical Resolution Date" identified in the document in order to avoid impacting the project schedule. Further, BearingPoint was not permitted to begin the work identified in a White Paper until it received approval from DOI and, in the case of options that entailed additional costs, a written modification from the Contracting Officer. 86. DOI failed to approve approximately one third of BearingPoint's White Papers by

the respective Critical Resolution Date and also failed to fund several additional White Papers by the Critical Resolution Date. Of the White Papers that were not timely approved or funded, approximately seven were between one and two months past the Critical Resolution Date, approximately twenty-one were between two and four months past the Critical Resolution Date, approximately four were four to six months past the Critical Resolution Date, and approximately seven were more than six months past the Critical Resolution Date. 87. Several causes contributed to DOI's failure to make timely decisions regarding

the White Papers. In many cases, DOI required BearingPoint to submit multiple revisions because one or more Bureaus could not agree on a resolution or desired additional functionality. -25-

W02-EAST:9CML1\200053207.3

Case 1:07-cv-00631-TCW

Document 16

Filed 01/11/2008

Page 26 of 71

In other cases, DOI's Project Management Office determined that it could not make a decision regarding a White Paper and wanted to elevate the issue to the Executive Steering Committee, but failed to place White Papers on the Executive Steering Committee's agenda, thereby delaying their consideration. Even when the Executive Steering Committee finally made decisions, DOI frequently failed to fund the work described in the approved White Paper for a number of additional weeks or even months. 88. BearingPoint timely notified DOI of delays occasioned by its failure to timely

approve and fund White Papers. BearingPoint maintained and tracked the status of each White Paper in an Issues Database that was accessible to DOI. Further, BearingPoint notified DOI of delays associated with the White Papers in weekly status reports and also provided to DOI several email analyses of delays associated with particular White Papers. 89. BearingPoint needed DOI to approve each White Paper by the Critical Resolution

Date in order to implement the functionality described in that White Paper by the October 2005 deadline for Deployment 2A. FBMS could not go live without certain functionality described in the White Papers, either because DOI so stated or because the system would not have passed user acceptance testing. As a result, DOI's failure to timely approve and fund the White Papers delayed Deployment 2A as a whole. DOI's Failure to Make Available Online Service Support Connectivity 90. Online Service Support ("OSS") is a "help line" service provided by SAP to

software integrators such as BearingPoint. It is an invaluable aid to software integration because it accelerates greatly the resolution of questions and problems. For the service to be effective, SAP must be able to access the user's system remotely.

W02-EAST:9CML1\200053207.3

-26-

Case 1:07-cv-00631-TCW

Document 16

Filed 01/11/2008

Page 27 of 71

91.

DOI was contractually required to establish and maintain OSS connectivity

throughout the implementation of FBMS. To that end, DOI directly contracted with SAP for OSS connectivity. 92. DOI, however, did not provide OSS connectivity until August 2005, only weeks

before Deployment 2A was scheduled to go live. 93. BearingPoint timely brought the lack of OSS connectivity to DOI's attention in

June 2004, and subsequently raised the issue and its impact on the project in weekly status reports provided between January and August 2005, in email correspondence, and in special meetings devoted to developing a solution to the OSS connectivity issue. An SAP Functional Assessment Report, provided to DOI and BearingPoint in April 2005, also underscored the severity of the issue, as did the May 25, 2005 Test Readiness Review ("TRR"). 94. DOI's failure to provide OSS connectivity for over a year delayed BearingPoint

and prevented the timely resolution of numerous open issues, with several issues remaining unaddressed at the time of termination. BearingPoint could not have proceeded with the project because resolution of these issues was a prerequisite to the commencement of integration testing. Accordingly, the lack of OSS connectivity delayed Deployment 2A. Non-Contiguous Testing 95. BearingPoint staffed the FBMS project consistent with its contractual

understanding that testing would take place at a single location. BearingPoint informed DOI in December 2004 of the problems, difficulties, and negative impacts of testing at two locations. 96. Over BearingPoint's objection, DOI required BearingPoint to conduct

simultaneous testing in Denver, Colorado and Herndon, Virginia. 97. As a result of testing in two locations, DOI personnel often improperly signed-off

on test scripts, either because they lacked expertise in the relevant testing area or because they -27-

W02-EAST:9CML1\200053207.3

Case 1:07-cv-00631-TCW

Document 16

Filed 01/11/2008

Page 28 of 71

failed to obtain input from teams located at the other venue. DOI's actions in this regard precluded the subsequent identification of errors in a timely fashion and forced BearingPoint to comb through earlier test results to ascertain the cause of software problems. 98. Testing in multiple locations also hindered communication and unduly burdened

BearingPoint personnel. Had testing occurred at one location, BearingPoint could have assigned one individual from each functional team to conduct testing and another to support testing activities. With testing split between two locations, however, each location had only one individual who was responsible for both conducting tests and performing supporting tasks. Despite extended working hours, this additional workload both decreased productivity and diverted resources from other tasks. 99. The problems and difficulties that resulted from non-contiguous testing delayed

Deployment 2A as a whole beyond its scheduled "go-live" date. DOI's Failure to Provide Adequate Facilities 100. Notwithstanding the express requirements of Task Order 3, DOI failed to make

available adequate facilities to BearingPoint personnel. 101. Dozens of BearingPoint personnel lacked access cards for the Herndon project

facility. BearingPoint submitted multiple written requests for additional access cards between May and June 2005, and also addressed the need for its personnel to obtain access to the Herndon facility in weekly status reports submitted between April and September 2005. 102. As of the date of termination, however, the issue remained unresolved. As a

result, BearingPoint personnel that possessed access cards wasted valuable time escorting their co-workers in and out of the Herndon project facility. 103. DOI also failed to provide for adequate parking at the Herndon facility. Cars at

the Herndon facility were occasionally towed, which required BearingPoint personnel to stop -28-

W02-EAST:9CML1\200053207.3

Case 1:07-cv-00631-TCW

Document 16

Filed 01/11/2008

Page 29 of 71

work while they reclaimed their cars. BearingPoint notified DOI by email dated June 28, 2005 that inadequate parking at the Herndon facility was impacting performance. The only proposed solution offered by DOI was for BearingPoint personnel to park their cars at a National Park Service building and call an FBMS team member for a ride. As a result, BearingPoint personnel were required to waste valuable time shuttling each other between the Herndon facility and the satellite parking lot. 104. Further, DOI failed to provide BearingPoint personnel sufficient office space at

the Herndon facility. At times, as many as three desks were placed into a cubical designed for a single person. BearingPoint timely notified DOI of the need for additional space beginning in February 2005 and identified the issue in weekly status reports provided to DOI from March through September 2005. The resulting working conditions not only undermined efficient performance, but also contributed to an increased rate of illness and staff turnover, which further contributed to inefficiencies. 105. The lack of building access, parking, and office space at the Herndon facility

contributed to inefficient performance and caused additional delays to the timely completion of Deployment 2A. DOI's Failure to Provide Adequate Staffing 106. Notwithstanding its contractual requirements, DOI provided no full time Subject

Matter Experts for eleven of thirteen functional areas, and provided only one Subject Matter Expert for the remaining two functional areas. 107. The need for additional Subject Matter Experts was timely raised by BearingPoint

in May 2005 and acknowledged by DOI in the Lessons Learned Worksheet, a deliverable accepted by DOI in June 2005.

W02-EAST:9CML1\200053207.3

-29-

Case 1:07-cv-00631-TCW

Document 16

Filed 01/11/2008

Page 30 of 71

108.

The lack of full time Subject Matter Experts impeded BearingPoint's ability to

obtain crucial information in a timely manner, increased the time required for DOI to make decisions, and required BearingPoint to make changes later in the project than necessary due to untimely input from the Bureaus. 109. Notwithstanding the requirements set forth in BearingPoint's Task Order 3

Proposal, DOI provided only one full time technical expert for the FBMS project until mid-2005, when a second technical expert was added. BearingPoint timely addressed the need for technical experts in weekly status reports and meetings held throughout February and March 2005. 110. The lack of full time technical experts prevented BearingPoint from obtaining

information necessary to complete and obtain approval of its TDSs, and also delayed testing because such personnel were necessary to provide and validate data. 111. DOI's failure to meet the staffing requirements set forth in BearingPoint's Task

Order 3 Proposal delayed the overall timely completion of Deployment 2A. DOI's Failure to Make a Timely Hosting Decision 112. Task Order 3 required DOI to make a decision regarding hosting of the FBMS by

August 13, 2004. 113. 114. DOI failed to make a FBMS hosting decision until October 22, 2005. BearingPoint timely notified DOI of delays associated with its failure to make a

hosting decision and of the resulting impact in correspondence beginning in August 2004. BearingPoint provided additional notice to DOI in weekly status reports and meetings from August through October 2004. 115. As a result of DOI's failure to make a timely hosting decision, the schedule to

complete Deployment 1A was extremely compressed and BearingPoint was forced to divert technical resources from Deployment 2A so that Deployment 1A would be completed by -30-

W02-EAST:9CML1\200053207.3

Case 1:07-cv-00631-TCW

Document 16

Filed 01/11/2008

Page 31 of 71

March 1, 2005. This diversion of resources directly impacted BearingPoint's ability to meet the October 2005 deadline for Deployment 2A. Interference by DOI's Independent Verification and Validation Contractor 116. DOI employed The Titan Group ("Titan") as an Independent Verification and

Validation ("IV&V") contractor for the FBMS project. 117. Titan repeatedly submitted comments requiring BearingPoint to address issues

that previously had been resolved. DOI refused BearingPoint's request to remove from any list of comments provided by Titan issues that already had been resolved by the parties. As a result, BearingPoint was forced to waste valuable time and personnel resources addressing issues that were no longer relevant to its performance. The overall completion of Deployment 2A was thereby delayed. BearingPoint's Compliance with Certain Contractual Requirements Project Control Reporting 118. Earned Value Management ("EVM") is a technique for monitoring project

schedule and cost. All work is planned, budgeted, and scheduled in time phased "planned value" increments. When the contractor completes a task or milestone, it is said to have earned the value associated with that task or milestone. Earned value can be compared with planned value and actual cost to measure schedule and cost variance, respectively. 119. The parties defined the EVM requirements applicable to Task Order 3 in

Appendix D of BearingPoint's Schedule Management Plan. The Schedule Management Plan, a contract deliverable, was accepted by DOI in December 2004. 120. BearingPoint complied with the applicable EVM project control reporting

requirements as approved in the Schedule Management Plan. DOI was fully apprised of

W02-EAST:9CML1\200053207.3

-31-

Case 1:07-cv-00631-TCW

Document 16

Filed 01/11/2008

Page 32 of 71

BearingPoint's level and quality of compliance with the requirements established by the Schedule Management Plan for fourteen months prior to the Task Order 3 termination. 121. The EVM project control reporting requirements applicable to Task Order 3 were

not material contract requirements. Project Quality Assurance 122. The BPA Quotation and the Task Order 3 Proposal included certain quality

assurance provisions. 123. BearingPoint complied with the quality assurance provisions included in the BPA

and the Task Order 3. 124. The quality assurance provisions included in the BPA Quotation and Task Order 3

were not material contract requirements. DOI Funding of BearingPoint's Performance 125. Task Order 3 was issued on September 20, 2004 as a segmented Task Order, with

each segment to be separately funded, and with initial funding set at $7,800,000. This amount included 100 percent of the labor portion of the first segment of Task Order 3, including the 15 percent deferred amount for achieving the performance standards of the QASP. 126. 127. The initial funding for Task Order 3 was exhausted in November 2004. Modification 0001 to Task Order 3 ("Modification 1"), issued on November 29,

2004, increased the total funds "available and allotted" to Task Order 3 to $15,177.086.00. This amount included 100 percent of the labor portion of the second segment of Task Order 3, including the 15 percent deferred amount to be paid to BearingPoint for achieving the performance standards of the QASP. In addition, Modification 1 added the following language to Task Order 3: "[T]he Government shall not be obligated to reimburse the Contractor for costs

W02-EAST:9CML1\200053207.3

-32-

Case 1:07-cv-00631-TCW

Document 16

Filed 01/11/2008

Page 33 of 71

in excess of the current allotment, nor will the Contractor be obligated to continue performance and incur costs in excess of the amount allotted." Modification 1, Block 14. 128. Modifications 0002 through 0005 included only minor increases in funding. As

of Modification 0005 ("Modification 5"), issued on March 29, 2005, the total amount of funds allotted to Task Order 3 was $15,182,930.00. This amount was sufficient to cover 100 percent of the labor portion of the second segment of Task Order 3, including the 15 percent deferred amount to be paid to BearingPoint for achieving the performance standards of the QASP. 129. 130. The funding issued pursuant to Modification 5 lasted until April 2005. On April 26, 2005, DOI provided BearingPoint with a draft of Modification 6,

which would have increased the amount of funds allotted to Task Order 3 to $27,572,218.00. 131. If accepted by BearingPoint, Modification 6 would have materially changed the

terms and conditions of Task Order 3 in a number of respects. In particular, Modification 6, among other things, would have: a. b. Added FAR 52.232-18, Availability Of Funds to Task Order 3; Added new CLIN 0013, "QASP Holdback," which provided in part "This

line item is not currently fully funded. . . . An additional $1,651,812.00 is needed to fund this line item fully;" c. Changed the reimbursement of travel from a not-to-exceed amount for the

entire funding period to a not-to-exceed amount for each month of performance, thereby exposing BearingPoint to the risk of not receiving full compensation for travel costs incurred during travel-intensive months of the project; d. Created additional requirements for the reporting of travel costs, thereby

imposing an administrative burden to which BearingPoint had not agreed; and

W02-EAST:9CML1\200053207.3

-33-

Case 1:07-cv-00631-TCW

Document 16

Filed 01/11/2008

Page 34 of 71

e.

Failed to fund all work ordered under the CLIN by failing to fund the 15

percent of the labor portion of the third segment of Task Order 3, representing the deferred amount to be paid to BearingPoint for achieving the performance standards of the QASP, thereby exposing BearingPoint to the risk that it would not receive the performance incentives for which it had bargained. 132. These material changes to Task Order 3 were unacceptable to BearingPoint.

Accordingly, by letter dated April 26, 2005, BearingPoint rejected the proposed modification, as permitted by the terms of its GSA Schedule 70 contract. Further, BearingPoint expressly advised DOI that any continued performance by BearingPoint should not be construed by DOI as acceptance of the draft modification. 133. On April 29, 2005, the DOI Contracting Officer informed BearingPoint that he

did not intend to cure the deficiencies in, or otherwise reissue, the draft Modification 6 in any fashion. Later that day, he confirmed by email his intent not to "alter or re-issue the modification." 134. By letter dated May 9, 2005, BearingPoint once again advised DOI of its rejection

of Modification 6. 135. As a result of the parties' failure to reach a bilateral agreement, Modification 6

never became effective and Task Order 3 remained unfunded. As such, BearingPoint's obligations under the Task Order were suspended and the company was entitled to stop work until such time as the Task Order was properly funded. 136. BearingPoint continued to perform Task Order 3 notwithstanding its rejection of

Modification 6 because (1) BearingPoint viewed DOI's assertion of the right to issue the modification unilaterally as contractual direction to perform in accordance with Modification 6,

W02-EAST:9CML1\200053207.3

-34-

Case 1:07-cv-00631-TCW

Document 16

Filed 01/11/2008

Page 35 of 71

and (2) continued performance was needed in order to mitigate any further DOI delay to the FBMS project. DOI's Waiver of the October 2005 Deadline for Deployment 2A DOI's Knowledge of BearingPoint's Inability to Meet the Deadline 137. Upon information and belief, Titan (DOI's IV&V Contractor) notified DOI of the

potential for untimely performance under Task Order 3 as early as December 2004. 138. Based upon BearingPoint's weekly project status reports, DOI knew or should

have known by no later than April 2005 that BearingPoint would be unable to meet the October 2005 deadline for Deployment 2A. 139. As early as