AEON Group, LLC

• Court: Armed Services Board of Contract Appeals
• Decided: August 6, 2014
• Docket: ASBCA No. 56142, 56251
• Status: Published

Opinion

ARMED SERVICES BOARD OF CONTRACT APPEALS

Appeals of -- ) ) AEON Group, LLC ) ASBCA Nos. 56142, 56251 ) Under Contract No. HQ0423-04-C-0003 )

APPEARANCE FOR THE APPELLANT: Michael R. Rizzo, Esq. McKenna Long & Aldridge LLP Los Angeles, CA

APPEARANCES FOR THE GOVERNMENT: Neil Bloede, Esq. Thomas S. Tyler, Esq. Snider Page, Esq. Trial Attorneys Defense Finance and Accounting Service Indianapolis, IN

OPINION BY ADMINISTRATIVE JUDGE DICKINSON

AEON Group, LLC, (AEON) appealed in ASBCA No. 56142 from the termination for default by the Defense Finance and Accounting Service (DFAS or government) of Contract No. HQ0423-04-C-0003 for the "rehosting" of the Department of Defense (DoD) Mechanization of Contract Administration System (MOCAS) from its existing software platform to a new platform. AEON appealed in ASBCA No. 56251 from the government's final decision and demand to recover unliquidated performance-based payments in the amount of $12,905,117.22. The parties' previous cross-motions for summary judgment were denied. AEON Group, LLC, ASBCA Nos. 56142, 56251, 09-2 BCA if 34,263. We have jurisdiction under the Contract Disputes Act (CDA), 41 U.S.C. §§ 7101-7109. Only entitlement is before us.

FINDINGS OF FACT

A. Background, Solicitation and Proposal

1. The MOCAS system at issue in these appeals is a "Critical system in the DoD contracting and entitlement process supporting the Warfighter, Homeland Security and Disaster relief' (app. supp. R4, tab 281 at 6). MOCAS is used by DoD for two primary purposes: by the Defense Contract Management Agency (DCMA) for contract administration, quality assurance, property management, contract payments and financial administration; and, by DF AS to provide accounting services and payment functions for wages and contracts. 1 Over 8600 users ofMOCAS enter data into the system on-line during the day; a batch cycle runs at night and the system then automatically generates reports and payments. Contract payments are automatically generated by MOCAS when the system is able to match up a contract, a receiving report and a contractor invoice. (Tr. 1/42, 3/380, 4/753, 5/940, 1076, 1091; R4, tab 3 at 773) The MOCAS system is used to pay out about $78 billion per month under government contracts (app. supp. R4, tab 283 at 3; tr. 3/380-81). The existing MOCAS system (hereinafter "As-Is MOCAS") had three regional databases, referred to as MOCs: MOCG (southern region); MOCH (eastern region); and, MOCL (western region) (tr. 3/383, 577, 599, 4/785; R4, tab 3 at 773). The As-Is MOCAS at the time of the contract at issue was complex and comprised of over 1600 different programs (supp. R4, tab 106 at 14 ), was very old2 and had maintenance issues (tr. 1/44). Further, because the system was so old and "there had been a lot of software coders that had played with the system" over time, "probably nobody really had a full grip as to how good or how bad" the coding of the As-Is MOCAS was (tr. 1/74). Documentation for much of the As-Is MOCAS system was nonexistent:

[T]he paperwork for MOCAS is not current. The system is basically over 40 years old, and during that time a lot of the changes that were made and everything, the paperwork on them were lost.... As we make changes we try to baseline what changes we are making, but no ... we do not have a good set of baseline documentation for the whole MOCAS system.

(Tr. 5/984) The As-Is MOCAS system used a SUPRA database which, at the time of contract award had only about 200 users worldwide, compared to hundreds of thousands of users of newer software like DB2. The government was concerned that the SUPRA software was going to become unsupported, creating a variety of issues, in particular security issues. (Tr. 4/688) In spite of these challenges, the As-Is MOCAS system "operated pretty well" (tr. 4/733).

2. The government sought to have its MOCAS system be compliant with then-current DoD regulations and to take advantage of newer technology and software. Rather than incur the expense of a complete replacement of the entire system, after consideration of various options, the government made the decision to update the existing MOCAS system incrementally in steps. (App. supp. R4, tabs 100, 283, 290; tr. 4/685-86)

The goal of the program was to simply get MOCAS on a platform that was maintainable, THEN, enhancements could

1 DCMA owns 65% of the MOCAS system and holds all of the system's accreditations. DFAS owns 35% of the MOCAS system. (Tr. 3/557) 2 "[C]irca 1960" (app. supp. R4, tab 290).

2 be incrementally introduced by a [readily] available [government] workforce, based on current and accurate documentation ....

The Undersecretary of Defense, Comptroller made the decision to initiate a spiral acquisition program beginning with the replacement of the underlying DBMSY 1 This type of program is not new or cutting edge. It has been successfully performed numerous times and is nowhere near the risk [of] a complete new development or modernization effort.

(App. supp. R4, tab 283 at 3)

In order to limit scope and minimize risk, the requirement was to be completely technical, providing the exact look and feel with 100% of the existing system functionality. There was to be no functional change.

(App. supp. R4, tab 290)

As a technical upgrade, no new or altered functionality was being introduced into the system as part of the Rehost. This significantly reduced the potential for scope creep and training requirements, increased user acceptance, and reduced the need to interpret and refine requirements. These are common risk areas in all projects that often result in schedule and cost overruns, rework and disruption to production operations. As such, per the [Statement of Work] (SOW), "The contractor shall ensure that the rehosted MOCAS has 100% of the functionality of the As-Is MOCAS system." The SOW further clarified this requirement for the human-PC interfaces, system interfaces, reports and queries, on-line updates, batch updates, and error messages. In summary, all outputs of the system were required not to have any visibility of a change to the end user, and support the same business and technical capability uses as the current system.

(Supp. R4, tab 106 at 1) The government expressed in its answers to prospective offerors' questions prior to contract award that it wanted the computer screens, reports

3 Data Base Management System.

3 and all system output to remain exactly as it was before the update but to have all the code, interfaces and documentation behind the output be updated.

QUESTION 118: Reference section 7 ofthe SOW, The rehosted system will evidence no change to the screen layouts, order of fields, character input, screen resizing capabilities, help buttons, or any other characteristic. ANSWER: Comment acknowledged. NO CHANGES to any characteristics are permitted by the solicitation.

(R4, tab 1 at 183) The government considered its approach to present "limited requirements" that made a firm-fixed-price contract appropriate (tr. 5/1079-80). A firm-fixed-price contract "places upon the contractor maximum risk and full responsibility for all costs and resulting profit or loss" (FAR 16.202-1) and FAR 16.202-2(d) specifies that a firm-fixed-price contract is appropriate where: "Performance uncertainties can be identified and reasonable estimates of their cost impact can be made, and the contractor is willing to accept a firm[-]fixed[-]price representing assumption of the risks involved." The government also considered the use of a firm-fixed-price contract to mean that the government's oversight and involvement in the work performed under the contract had to be limited (supp. R4, tab 106 at 3; tr. 1/135-36, 3/520-22).

[O]ne of our concerns was that we did not hinder [the contractor] from their efforts. We did not want to be the cause of any delays.

We certainly didn't claim to have all the expertise. [The contractor] was supposed to develop their own test plans, own project management plans. It was pretty much hands off, and they were supposed to complete everything, and tum it over for Government testing, and at that point, we would test the functionality.

(Tr. 4/710-11, see also tr. 5/909)

3. The government made the decision to provide the successful offeror a "complete operation copy" of the As-Is MOCAS (tr. 4/660).

That was important because they were to deliver a system that looked, felt, operated identical to the current as-is. So that was the baseline. Everything was to be - we called it the gold tape. Everything was to be compared to that, and that is what

4 they were supposed to deliver, and it was very expensive by the way. It was unheard of.

I think it was the first time that we had ever seen that done, where a complete copy of the MOCAS was given, that a complete operational copy was given.

A Over the course of the contract [it cost the government] probably over a million dollars.

(Id.) Q ... Did the Government furnish a detailed design?

A We furnished a complete as-is, which is better than any design document that you could ever hope for.

A AEON was supposed to develop [the] design ....

(Tr. 4/729-30, see also tr. 4/874, lines 6-11) On 9 November 2005 AEON expressed its understanding that there were usually no design specifications for a conversion project such as the one at issue:

In the new development project business and systems requirements specifications are available. From these specifications, architecture and designs are developed and documented. The design documents are used to create program specifications which in tum enable program development. Programmers develop their programs in accordance with the program specification. When the program is developed the programmer unit tests the program against the program specifications. For conversion projects such as MOCAS Rehost there usually are no business or systems requirements and no design or program specifications. Further, the programs are partially or fully converted using a tool.

5 (Supp. R4, tab 68 at 2) (Emphasis added) We find that the copy of the As-Is MOCAS system provided to the successful bidder was the performance specification to which AEON was to design and produce the Rehosted MOCAS.

4. On 25 July 2003 DF AS issued Solicitation No. MDA240-03-R-0003 for the MOCAS Rehost project which was described as:

1. Scope The scope of this procurement is all services and supplies associated with, or supportive of, the rehost of the [MOCAS] including but not limited to: • Technical migration ofMOCAS to execute on a Defense Information System Agency (DISA) Standard Operating Environment (SOE) compliant Relational Database Management System (RDBMS). • Development of all system and project documentation. • Repair of the rehosted MOCAS after installation

2. Background MOCAS is an automated integrated financial and contract administration system developed in the late 1950' s and enhanced over the years to maintain regulatory compliance and to support new business functionality. The system has over 8,600 authorized end users from the [DF AS], [DCMA] and other DoD components who access the system from locations worldwide. MOCAS resides on a DISA mainframe at the Defense Enterprise Computing Center (DECC), currently in Columbus, Ohio, and consists of three separate databases (MOCH, MOCL, MOCG) that serve two regions: East and West. Each database has its own copy of executables (programs) and Job Control Language (JCL). MOCAS consists of both interactive on-line (MANTIS and Customer Information Control System (CICS)) and batch system processing. The primary programming languages are COBOL and MANTIS, and a few programs written in Assembler. There are a number of systems that interface with MOCAS using a variety of platforms and interface methods that are critical to the overall functions of MOCAS. These

6 systems are not part of the MOCAS rehost, but their interfaces must be maintained. There are approximately 1.5 million lines of source code maintained using a single source code library. The executables are, in large part, mirrored in each of the three databases.

3. Objective The objective of this program is to begin the incremental progression ofMOCAS toward a modem, integrated business solution. DFAS is, in furtherance of this objective, rehosting MOCAS. This will provide a foundation for future business process improvements, technical capabilities, and reduced costs. However, none of those improvements are included in this contract.

(R4, tab 1 at 8)

5. On 12 August 2003 DFAS held the MOCAS Rehost Request for Proposal (RFP) Conference at which Mr. Art Gold, 4 Director of Systems for Commercial Pay Business Line (CPBL), presented information to prospective bidders in the form of PowerPoint slides (R4, tab 1at94-121; tr. 1147). Over 30 companies expressed interest in the project (supp. R4, tab 120 at 2). AEON was represented at the conference by Mr. Glenn Henry (R4, tab 1 at 124). The conference slides described the existing As-Is MOCAS system as follows:

• MOCAS was developed in the late 1950's

• The last significant upgrade was in the early 1980' s migrating MOCAS from Honeywell to Total Information System (TIS)

• In 1998 MOCAS was moved to its current technology, SUPRA DBMS

• Minor compared to Honeywell to TIS move • Hierarchical DBMS with link paths to data

4 Mr. Gold was one of the principal architects of the MOCAS rehost project (tr. 2/273-76). Mr. Gold worked for AEON after his retirement from DFAS, which occurred sometime before the contract at issue was terminated for default (tr. 2/274).

7 • MOCAS contains approximately 1.5 million lines of code

• COBOL- IM lines • MANTIS - 450K lines • JCL- 73K lines • Assembler - 5K lines

• MOCAS has over 50 interface applications

• Shared Data Warehouse (SDW)

• Integrated extension of MOCAS SUPRA resident database • Provides reporting and query capabilities • Linked and populated via a hardware/software configuration referred to as "Forward Technical Bridge (FTB)" • All changes to MOCAS data is [sic] captured by a "change detector element" of the FIB and flows to/updates the SDW

• The existing documentation is outdated and incomplete

(R4, tab 1 at 101-03) The desired period of performance was presented to the prospective bidders as a total of 720 days or 2 years consisting of 540 days for contractor development and test, after which the Rehosted MOCAS was to be delivered to the government for 180 days of Government Test and Evaluation (GT&E)5 consisting of 90 days for functionality testing and followed, if functionality testing was successful, by 90 days of production testing of the installation of all three MOCs (R4, tab 1 at 109; finding 18).

6. All questions and comments submitted by potential bidders as well as the government's answers (R4, tab 1 at 156-212) were posted at www.dfas.mil/aso/contract/index.htm and available to all potential offerors by 22 August 2003 (R4, tab 1 at 165). Among those pertinent to these appeals were:

5 User acceptance testing (UAT) and GT&E are used throughout the record to refer to the same phase of the contract (tr. 3/427).

8 QUESTION 15: Will subject matter experts [SMEs] be readily available as required, or should we plan for delays in having access to subject matter experts and further delays in their responses to our questions? What standard of timeliness of access and response will DF AS provide to the vendor? ANSWER: The Government will not provide SMEs. The Government does not guarantee that it will answer any particular question that is submitted, however, questions may be submitted IAW par. 5 of the statement of work. There is no standard of timeliness of responses.

QUESTION 16: [a] Will application operational personnel be readily available as required to demonstrate operation of the programs, or [b] should we plan for delays in access to application operational personnel and/or time constraints on our use of their time in demonstrating operation of the programs? [c] What standard of access and availability will DF AS provide to the vendor? ANSWER: a.) No. b.) Questions may be submitted IA W par. 5 of the statement of work. c.) None

(R4, tab 1 at 159)

QUESTION 29: The contractor shall submit, as part of its proposal, and in accordance with the terms of the solicitation, a Software Test Plan. The Government will use the test plan, during the course of the contract, to monitor the contractor's progress toward timely and acceptable performance and to determine whether deviations from this plan are conditions threatening performance. There's no mention of Government participation during testing. We request that the Government participate during all testing to ensure successful testing and that the size of the Government team be agreed upon 60 days prior to the test period. ANSWER: See SOW section 9. The Government may observe but will not participate in contractor testing.

QUESTION 30: ... [A] complete copy ofMOCAS .... one time snapshot of full-production data. Will this snapshot include enough data to be representative of the 100% functionality (Daily, Monthly, Yearly, etc) ofMOCAS to include error processing and exception reporting?

9 ANSWER: Not necessarily, there is the possibility that specific types of data may not be included in the snapshot at the time it is replicated. The as-is snapshot will be able to process any and all data that the corresponding production database can. Therefore, the contractor can simulate any type of data and process it through the as-is environment. This includes the data for error processing and exception reporting.

(R4, tab 1 at 162)

QUESTION 33: Reference: Section C, paragraph 2 "The executables are, in large part, mirrored in each of the three databases." Concerning the "mirrored" executables in the 3 environments that are "in large part" the same, should the contractor assume that the code is exactly the same, or should a percentage delta factor be assumed? Please supply this factor if known. ANSWER: A significant portion of the performance under this contract is to ascertain the as-is environment. The Government is aware that the three environments are "in large part" mirror images. The Government suspects that the three are the same. However, the Government does not know the precise extent of possible variances between the three environments.

(R4, tab 1 at 163)

QUESTION 36: Will the Government have access to the as-is legacy MOCAS system (as awarded to the contractor) that will permit testing against this baseline as well as verification? · ANSWER: The Government will have access to the as-is system, and a back copy of the as-is system, at all times. The Government will not interfere in the contractor's use of the as-is system during development and testing. After delivery, the Government will use the as-is system as its benchmark.

QUESTION 38: Will contractor staff be permitted to schedule MOCAS re-host activities such as online and batch

10 jobs at their priority and discretion or will the Government require prior coordination? ANSWER: The as-is MOCAS, the testing environment and the development environment will all reside on the same mainframe and will be available and dedicated to the MOCAS rehost project. The Government will not interfere in the contractor's use of the as-is, development, or testing system.

QUESTION 49: ... [W]hat criteria will the Government use to assess 100% functionality in the rehost? ANSWER: See SOW sections 7 and 11.

(R4, tab 1 at 164, 166)

QUESTION 62: Do Test Scripts or a Software Test Plan exist for MOCAS As-Is? Even informal test scripts may be beneficial to the vendors bidding on' this solicitation ANSWER: The Government will not provide Software Test Plans for the MOCAS As-Is. However, ifthe contractor, during the course of performance, discovers additional documents, they may be requested through the [Contracting Officers Representative] (COR).

(R4, tab 1 at 169)

QUESTION 74: On several occasions within the RFP, the Government states that it cannot guarantee its ability to answer questions related to the MOCAS as-is system due to incomplete/outdated knowledge of the system. How does the Government expect an offeror to provide the required plans identified in Section Four Project Management in any meaningful detail or substance without having had an opportunity to conduct an assessment of the MOCAS As-Is environment, and an analysis of approximately 1.5 million lines of code? ANSWER: The Government is seeking a contractor with the expertise to do so.

(R4, tab 1at171)

11 QUESTION 77: The Government specifies in Section Seven Functionality that it requires the re-hosted system will have 100% functionality of the as-is system. Can the Government define 100% MOCAS functionality? Can the definition be provided in specific terms, quantified by the number of conditions, parameters and screen definitions that constitute MOCAS 100% functionality? ANSWER: See SOW par. 7.

(R4, tab 1 at 172)

QUESTION 98: Will DFAS consider the test coverage to be sufficient if it covers the program logic exercised in a simulated normal operational cycle for each program? Or will DFAS want the test coverage to be forced to follow all accessible logic paths? ANSWER: The contractor must determine what testing is sufficient to ensure the rehosted MOCAS complies with the contract requirements.

(R4, tab 1 at 178)

QUESTION 101: ... [A] complete copy ofMOCAS .... one time snapshot of full-production data. Will this snapshot include internal and external interfaces to include incoming and outgoing? ANSWER: The Government will provide an as-is snapshot that is a replica of the production environment. The snapshot will be able to process any and all data that the corresponding production database can. There is the possibility that specific types of data may not be included in the snapshot at the time it is replicated. The snapshot will contain the programming, within MOCAS, necessary to operate the interfaces. To conduct testing of those interfaces, see SOW section 9.

(R4, tab 1 at 179)

7. AEON submitted its proposal on 1December2003 in which it stated that it had "just completed another successful conversion of MANTIS and SUPRA to CICS COBOL and DB2 with full production implementation .... This proposal will demonstrate how we can achieve the same success for DFAS." (R4, tab 2 at 220, 222-23) AEON's proposal

12 demonstrated its understanding of the government's decision to modernize MOCAS incrementally and to make the Rehosted MOCAS transparent to its users:

The Government is embarking on a long term project to incrementally transition the MOCAS system to a modem integrated business solution. The MOCAS Rehost Project is the first step in that transition. MOCAS will be moved to a modem technical infrastructure without impact to the MOCAS user community as the functionality, look and feel of the system will mirror the current MOCAS environment.

(R4, tab 2 at 220) The proposal also stated:

MOCAS end users will not experience any change in system functionality, data content and quality. The current business processes and workflow will remain unchanged and the functionality, look and feel of the MOCAS Rehosted System will mirror the current system. Therefore, the system changes will be transparent to the user community.

(R4, tab 2 at 221) AEON's proposal continued:

We believe we are uniquely qualified to assist you with this major undertaking because of our:

• Team - Our highly skilled management and technical team with in-depth MANTIS, SUPRA, DB2 and MOCAS knowledge and expertise, complex and large conversion projects, effective testing and extensive project management experiences will reduce the risks inherent to a project of this magnitude.

• Methods, Processes and Best Practices - Our Rapid conversion life cycle approach and process, industry recognized standards of CMM and PMI (Project Management Institute) for our program management, our testing best practices and our ability to properly manage risk, avoid potential project pitfalls will produce high quality, timely deliverables.

13 • NPGen Conversion Tool - Our proven MANTIS and SUPRA specific conversion tool will expedite the conversion process while producing consistent and high quality deliverables.

• Our Extensive Experience - While others may claim that they can do it, we have done it successfully many times.

(R4, tab 2 at 221, 254) AEON listed 11 previous projects, 6 in detail, of which 2 were previous DF AS projects. One in particular, the DF AS SCRT project, was identified by AEON as having multiple similarities to the MOCAS Rehost project. (R4, tab 2 at 222-25, 255-59) AEON proposed to complete the contract work in 24 months at a firm-fixed-price of$14,899,316.00 and was the highest of the bids submitted to the government (R4, tab 2 at 215, 242, tab 3 at 765; tr. 1/68-69, 4/656-58; finding 10). AEON proposed to use "our proven conversion tool, NPGen, a rapid conversion approach" that it represented to be "our proprietary" and "internally-developed" software conversion tool (R4, tab 2 at 220, 227, 229-30, 262, 264-66; tr. l/S0-51, 4/658). AEON's proposal further included key management personnel: John Allwood as Project Manager and Lech Lakomy as Technical Manager6 , as well as a dedicated Program Manager (Dori Overby) to provide additional oversight and an Internal Audit Executive (Shirin Javid) who would spend two days per month for the duration of the project reviewing and validating the project processes (R4, tab 2 at 237-39, 286-90, 300-31, 338-42, 372-76). The government found AEON's proposal to present "strong management plans and had consistent, easily understood, documented processes that appeared repeatable .... With ... strong technical and management qualifications, and several value added features, the Government selected AEon's proposal as representing the best value." (Supp. R4, tab 106 at 4-5; tr. 5/892-93) AEON also proposed to use its "successful automated testing approach," grouped into ten major categories (see finding 55), to provide "more comprehensive testing with fewer people and for a shorter period of time leading to increased testing productivity, consistency, quality and ultimately reducing the conversion risk" (R4, tab 2 at 232-33, 270-72).

6 The proposal also identified Mr. Lakomy as the "sole developer ofNPGen, a highly sophisticated PC based tool suite used to inventory, parse and analyze MANTIS, COBOL and SUPRA/TOTAL which will be the conversion tool used on the MOCAS project" (R4, tab 2 at 238).

14 8. AEON's proposal included an extensive risk analysis and proposed specific means by which AEON intended to manage the risks it identified. The proposal included "several million dollar[s]," stated as a contingency, to cover the various risks identified by AEON (tr. 4/657).

The most significant risk to the MOCAS project is the lack of participation by the MOCAS technical and business users. We will minimize the risk by using [Computer Sciences Corporation] cscPJ resources that bring a wealth of DF AS and MOCAS related experience to the project team in the form of the Functional Manager, QA leader, testers and programmers. We have additional team members who have MOCAS and/or contract management and/or DF AS experience to further minimize the risk. [SJ

(R4, tab 2 at 236, 275)

9. A total of five proposals, including AEON' s, were submitted in response to the solicitation and evaluated by the government (supp. R4, tab 120 at 2; tr. 1/99, 4/656, 5/892).

B. Contract

10. On 1April2004 Contract No. HQ042'.3-04-C-0003 for the MOCAS Rehost Program was awarded to AEON for the firm-fixed-price of $14,899,316.00. "This contract will convert/rewrite all existing MOCAS software programs to a [RDBMS] which will enable DFAS to begin its incremental progression toward a modem, integrated business solution that is compliant with the DoD Business Enterprise Architecture." (R4, tab 3 at 765) Contract line item no. (CLIN) 0001, Rehost MOCAS System, in the amount of $14,849,316.00 (all but $50,000 of the total contract price) was described as:

7 AEON's proposal identified CSC and IBM as "alliance partners" (R4, tab 2 at 220, 253, 261-62). 8 AEON hired employees who had "a lot" of MOCAS experience. A few of them were identified at the hearing as: Dwight Layden, whose nickname was said to be "Mr. MOCAS" (division chief of programming under DLA before DCMA and DF AS were split oft), Sandra Livingston, Don Miller, Ruth Owen (programming supervisor in the financial area), Sheila Gretar (financial analyst and functional analyst in MOCAS), Jim Wheeler (DISA) (tr. 4/782-83, 5/942-43).

15 The contractor shall provide all tasks identified in the statement of work including installation on the test and production platforms of the rehosted MOCAS; delivery of rehosted MOCAS and migration programs, both with full documentation; and sequential migrations of the as-is data to the rehosted MOCAS. This CLIN excludes statement of work tasks for Government directed travel, and the repair and software license options.

(R4, tab 3 at 770) CLIN 0002, Government Directed Travel, was priced in the amount of $50,000 and CLIN 0003, Option-Repair, never exercised (tr. 1111 O; see also finding 71), was priced in the amount of $668,316 (R4, tab 3 at 771-72).

11. The SOW~ 4, Project Management, required AEON to submit as deliverables under CLIN 0001, as well as update throughout contract performance, a Program Management Plan (PMP), 9 Program Quality Assurance Plan (PQAP), Software Development Plan (SDP), Configuration Management Plan (CMP), Software Test Plan (STP) 10 and a Transition Plan that AEON was to use to manage its performance under the contract. "The Government will use these plans, during the course of the contract, to monitor the contractor's progress toward timely and acceptable performance. The Government may determine that deviations from these plans are conditions threatening performance." (R4, tab 3 at 773) AEON was also required to provide a biweekly status report identifying work performed and issues impacting performance, minutes of monthly In Process Review (IPR) meetings, and a single, ongoing document in which each milestone met was documented so that it reflected the total progress of all the milestones identified in the PMP (see, e.g., app. supp. R4, tab 172 at 8; see also findings 21, 24, 49, 63, 65, 70). (R4, tab 2 at 236, tab 3 at 773-74; app. supp. R4, tab 169; tr. 21191, 3/397-99) SOW~ 4 provided that:

The Government expressly reserves the right to observe, shadow, question, make suggestions to, and otherwise interact with the contractor during the performance of the contract. However, the contractor is responsible to notify the Contracting Officer (CO), in writing, if at any time it believes that the communication under this term is interfering with the performance of the contract and provide the Government

9 The PMP was a "living document" that was updated throughout contract performance, the most current version of which was submitted to the government on a regular basis. See R4, tab 25 for what is annotated as the final PMP (Sept 2006). 10 See finding 16.

16 24 hours to evaluate the objection and if appropriate, discontinue the behavior.

(R4, tab 3 at 774)

12. SOW~ 5, As-Is MOCAS, provided:

The contractor, in order to reproduce the current MOCAS functionality in a RDBMS, must ascertain the functionality of the current, as-is MOCAS. The contractor will have: • ... [A] complete copy ofMOCAS systems loaded with a one-time snapshot of full-production data. The boundaries of the as-is MOCAS are contained in section J, attachment 1.7, MOCAS Rehost As-Is Documentation - MOCAS Technical Environment Chart.... [I]nterfaces, applications, or files not designated as part of the as-is MOCAS in that attachment [may not be changed]. • The as-is documentation provided as an attachment to this [contract]. The as-is documentation only represents a high-level approximation ofMOCAS. It is based on incomplete and/or outdated documentation. [I I] • The option of submitting questions, in writing, through the COR. • However, the Government does not guarantee that it will be able to answer any particular question that is submitted because of the incomplete and/or outdated knowledge of MOCAS. • These questions and answers do not relieve the contractor from responsibility for ensuring that it has a thorough and correct understanding of the as-is functionality. • The Government will acknowledge the contractor's requests within two business days.

11 One of the purposes of the contract to rehost MOCAS was to provide updated documentation (tr. 5/1087; see also findings 4, 10, 18, 19, 52, 54, 71, 115).

17 (R4, tab 3 at 774) With respect to the provision of the "one-time snapshot of full-production data":

We provided a -- we went to DISA and asked them that since we knew that this documentation on the MOCAS, was antiquated, we wanted to make sure that they had a system that they could go back to, so that when they were converting on this side, they can go back and test over on the current system to make sure that it was doing the same thing as it was doing over here, and it would be doing the same thing when they converted it.

So we provided them a one time snapshot of all three databases for them to use, which was very costly. [121

We provided [AEON] with a system so that they can compare and they can see how the system was functioning. They could go and do a test and use that so when they were over here, and they were having difficulties, they could go back to the other system to compare .

... [T]hey can get new log-ins, and a new sign-on, and enter data, and go in and see how it works, and basically to see how it was working today, and then when they went and converted it, they could go back and check and see if it was doing the same thing in the old system when they converted it over to the new system.

(Tr. 3/405-07; see also tr. 5/908-09)

13. SOW ~ 6, System Development, provided:

The contractor will - - • update, convert or rewrite MOCAS's MANTIS, COBOL, and all other programs and batch JCL jobs,

12 (See finding 3).

18 • using, on the mainframe, only programming languages, conversion or development tools that are listed as GFP, or that have received a waiver from the CO, • and using, on a workstation connected to the ELAN, only software listed in section J, attachment 2.1, provided as part of the standard DF AS office automation software load, or that has received a waiver from the CO • to execute using a contractor developed/converted database utilizing a Government-furnished, Government-installed RDBMS as identified in section 16 ofthis SOW, • that accommodates the consolidation of the current three physical databases into a single instance with a single set of executable files and JCL, • mapping the as-is MOCAS database file structure to the rehosted MOCAS database, • which shall reside on a Government-provided mainframe, • running a Government-tailored operating system loaded with all software listed in section J, attachment 2 .4. The Government will - - • no later than 90 days after the date of award, provide the contractor test and development environments running a Government-tailored OS-390 operating system loaded with all GFP software, • and on or before September 30, 2004, inform the contractor that a Government-tailored installation package to upgrade to a Z/OS operating system with a list of the Government-provided software that is included in the package is available, • over the course of no longer than 72 hours, install the available installation package within 30 days of the contractor's written request or one week prior to the beginning date for delivery of CLIN 0001, whichever is earlier,

19 Any product used in support of this contract, but not required to be used in the Government testing and production environments may be loaded on a stand-alone workstation.

The Government will maintain and ensure operability of the mainframe hardware and the government-tailored operating system. Ifthere is a failure of the mainframe or government-tailored operating system, the Government will repair or replace it within 48 hours.

Access to the mainframe via PC and ELAN will be available to the contractor 24 hours per day, every day of the year except for up to two 24-hour periods per month. The contractor will not have physical access to the mainframe.

(R4, tab 3 at 774-75)

14. SOW~ 7, Functionality, provided the following:

The contractor shall ensure that the rehosted MOCAS has 100% of the functionality of the as-is MOCAS system. Functionality is: • the ability of the software delivered under this contract to operate on the Government-furnished hardware provided under the terms of this contract • while supporting every one of the same Government business uses that can be performed using the as-is MOCAS system (for example reports, inputs, processes, outputs, screen layouts, interfaces, system accessability to users, windows of availability) without any visibility of a change to the end users • while supporting every technical capability, use, and purpose of the as-is MOCAS system (for example internal controls, edits, screen scrapes, system response times, capacity for ongoing operations, performance characteristics, archive capability, scalability, back-up and restores)

20 • and, while ensuring that the Government is able to retain or obtain the same level of security accreditation as the as-is MOCAS system ....

The contractor shall read the definition of functionality broadly, that is, to be inclusive of features rather than exclusive of features. Functionality includes but is not limited to: • The human-PC interface. The rehosted system will evidence no change to the screen layouts, order of fields, character input, screen resizing capabilities, help buttons, or any other characteristic. For example, if a special key must be struck today, then that same key must be used in the new system. In addition, end users must have access only to that portion of the MOCAS data as they have in the current MOCAS system. The contractor must ensure that the same emulators used today by end users can remain in use in the rehosted system. • System interfaces. The rehosted system must maintain all system interface capability as the as-is MOCAS system, without requiring any changes to non-MOCAS systems. • The contractor must retain all interface functionality. Where any part of a system interface, whether files or programs, are identified as part of the as-is MOCAS, the contractor may change them, while maintaining full functionality. If they are not identified as part of the as-is MOCAS, the contractor may not change them, and as with all interfaces, their functionality must be maintained. The contractor shall notify the COR of any applications not indicated on the MOCAS Technical Environment Diagram as soon as they are identified by the contractor. As with all interfaces: • Any file transferred with a particular file transfer protocol must remain capable of being transferred with that protocol. • Where systems interface with MOCAS via emulators on a PC, the contractor must ensure

21 that the interfaces are maintained using the same emulators. • Reports and queries. All reports and queries will have the same data elements, formats, information, order, distribution (for example reports via the Mechanization of Reports Distribution System (MORDS)) and all other characteristics as generated by the as-is MOCAS system. Specifically, all reports must be based only on the portion of the data from which it is drawn in the as-is MOCAS. For example, if a report in the as-is system is drawn only from the "West" database, it must still only be drawn from that data in the rehosted system. • On-line updates. Any updates performed on-line in the as-is MOCAS system will be performed on-line in the rehosted system. The same on-line edits will be performed in the rehosted system as in the as-is MOCAS system. • Batch updates. Any updates performed in batch in the as-is MOCAS system will be performed in batch in the rehosted system. The same batch edits will be performed in the rehosted system as in the as-is MOCAS system. The system must allow for timing of batch processing (including all pre-cycle and post-cycle maintenance, back-ups and restores), which does not alter the as-is MOCAS system on-line availability for each time zone. • Error messages. Error messages generated by the MOCAS application software will be numbered and worded in the rehosted system the same as they are numbered and worded in the as-is MOCAS system.

The contractor shall, if it determines that any component of the as-is MOCAS code does not perform a function, prepare a written explanation of the rationale, prepare complete documentation of the code, and submit it to the COR for permission prior to making a determination that it is not part of the system functionality. The contractor understands that it is unlikely that the Government will give permission to omit from the rehosted MOCAS code believed to be inactive.

(R4, tab 3 at 775-76) Under this requirement, the rehosted system was to look and operate exactly the same as the As-Is MOCAS system so there was no need to retrain the

22 government users (tr. 1/74-79, 511087-88). DFAS MOCAS Program Manager Castrillo described it as follows:

Q How was the rehosted MOCAS supposed to operate when it was delivered to the government?

A No different than as-is MOCAS. One of the examples I always gave was, because we acknowledged that there's things that MOCAS did that probably wouldn't be correct.. .. I'll give you a high level example. IfMOCAS said 2 plus 2 is 5, if the as-is MOCAS said that, the expectation was that when it's rehosted 2 plus 2 would equal 5. Because there were a couple times that, you know, we got approached, hey we could correct this or, you know, we could correct something, and I would say, no, you've got to make it work, if it's wrong it's wrong. I mean, you know, it just has to do what MOCAS is doing today, don't make it do something [else].

(Tr. 5/1087-88)

15. Contracting Officer (CO) Gladski was identified as a Buyer up to and including the date of contract award. He then became the primary CO on this contract until he retired from DFAS in June 2008 (tr. 1/30). CO Gladski was involved in drafting the terms and conditions of the solicitation and resulting contract (R4, tab 3 at 765; tr. 1/46, 62, 75, 2/267). Both documents, due to minimal existing documentation, made identification of the functionality of the As-Is MOCAS the responsibility of the contractor (tr. 1/73-74, 2/235-36).

The requirement was pretty clear that the rehosted system was basically a form fit function replacement of the as-is, and was to mirror exactly the functionality of the old system as it would have been transported or converted on to a new platform.

(Tr. 1/76)

By limiting the conversion effort to 100% functionality of the As-Is system, the Rehost project was unique in that the test results from the[] rehosted system should exactly match the results of running the same transaction through the original system.

23 (Supp. R4, tab 106 at 16)

16. SOW~ 9, Contractor Testing, provided:

The contractor shall submit, as part of its proposal, and in accordance with the terms of the solicitation, [an STP]. The Government will use the test plan, during the course of the contract, to monitor the contractor's progress toward timely and acceptable performance and to determine whether deviations from this plan are conditions threatening performance. The test plan will include, at a minimum: • unit testing, • integration testing, which includes exception testing, interface testing, and testing the rehosted MOCAS functionality • performance testing, which includes expected level and stress level testing of system availability, volume and response time capability • trial migrations including at least one complete migration of all the data in the as-is MOCAS databases by incrementally migrating one database at a time until all the data is copied into the rehosted MOCAS system on the test platform

The Government may, during the performance period, recommend exception and other testing scenarios that the contractor may consider in its testing process.

Notwithstanding any contractor testing, the Government expressly reserves the right to conduct any testing in order to determine that the rehosted MOCAS complies with all the terms of this contract. No testing by the Government will relieve the contractor from its responsibility to comply with all the terms of this contract.

(R4, tab 3 at 776-77; tr. 4/739-43) (Emphasis added)

24 17. SOW~ 10, System Delivery and Set-up, provided:

The contractor shall deliver, as part of CLIN 0001, all the source code, executable objects and all other development products or programs for the rehosted MOCAS.

The contractor will have included in its Project Plan, the following tasks, task durations, and shall: • No later than the beginning delivery date for CLIN 0001, completely purge the test platform of all data and programmmg. • On the beginning date of delivery for CLIN 0001, in the presence of the COR and any other Government representatives, install the rehosted MOCAS programs and new MOCAS database on the testing platform. • Complete the installation within 24 hours. • Upon completion of the installation, using the ET&L programs provided in paragraph 8, above, migrate the data from one of the three as-is databases to the rehosted MOCAS. • On the ih calendar day after completion of the migration of the first database, migrate the second as-is MOCAS database to the test platform. • On the 7th calendar day after completion of the migration of the second database, migrate the third as-is MOCAS database to the test platform. • The Government will, for each database, no later than 30 days after the third migration, notify the contractor to migrate any government-edited data from the ET &L suspense file to the test platform. • The contractor shall have 24 hours to complete each migration.

(R4, tab 3 at 777-78)

18. SOW~ 11, Acceptance/Rejection, provided:

The Government shall accept or reject CLIN 0001 within 30 days from the final migration of live, legacy production data to the rehosted MOCAS. At any time prior to final acceptance, any discrepancy between the functionality of

25 the rehosted MOCAS and the as-is MOCAS, or any other failure to meet the requirements of this solicitation, may be a basis for rejection. Documentation may be rejected if: (1) there is any instance where the documentation does not reflect the configuration or function of the rehosted MOCAS (2) it does not provide sufficient instructions to operate or maintain any portion of the rehosted MOCAS, and/or (3) it does not comply with any other requirement in this contract.

(R4, tab 3 at 778) (Emphasis added) SOW if 11 also included the following timeline:

Example Timeline

sodays I ••• ••• I 80 Da)"S Government ; TestmglAcccpmncc

CLIN 0003 Renair

Wamllltv

A The due date for the beginning of delivery of CLIN 000 I B Installation for production testing- beginning 90 days after the due date for the beginning of delivery of CLIN 0001. Beginning of option CUN 0003, if exercised. C Deadline for Government's Accentance or Reicction

(R4, tab 3 at 778) The timeline was explained as follows: The delivery of the rehosted MOCAS and documentation defined within the SOW was to occur over 180 days during Government Testing and Acceptance phases. The Government estimated that it would require 90 days to perform (the initial GT &E period of functionality testing]. Upon successfully testing the system [A-->B], the production MOCs would be migrated to the rehosted system over a 90 day I 3 month period [B-->C] in which one of the three MOCs would be migrated each month. The Government would accept or reject the system and documentation within 30 days from the final migration. At the time the SOW was written, the Government felt that this was a reasonable estimate, but it

26 was dependent on the contractor properly testing the system (i.e. unit and system integration testing) to ensure that the rehosted MOCAS had 100% of the functionality of the as-is MOCAS system. Assuming this contract term was met, a 90 day GT &E was more than sufficient for conducting the Government's tests.

(Supp. R4, tab 106 at 3-4; see also findings 2, 5) Program Manager Castrillo described the process as follows:

[GT &E] was the government testing and evaluation, it was the government's opportunity to test and evaluate what was being delivered. This system issues millions upon millions of dollars in payments a year, or in a day I think $20 million. So we didn't want to put it in production and have ... any fatal errors or any problems. So we set aside 90 days in the contract to do whatever testing we wanted or we felt was necessary, and then so that was our period before we put it into production .

... [O]ur evaluation period was actually I believe 180 days, 90 days was to do it outside of production and then 90 days within production.... [W]e go one MOC at a time because again being an old system, you know, you want to be careful about how you proceed .

...[I]t was our full responsibility to determine that the terms of the contract were met, that we had an adequate system, that we had a rehosted system that would fully operate the way as-is MOCAS [operated].

(Tr. 5/1088-89) When asked what AEON's role was to be during GT&E, Castrillo testified that AEON didn't really have a role in GT &E, stating that "their job should have been done" (tr. 5/1089-90).

AEON was responsible for ensuring the system was delivered with 100 percent functionality. So it was a working system.

They were responsible for doing the testing [see finding 16]. Once it was turned over to the Government,

27 AEON's testing of the system is over, and it is Government testing from there. So they would not have an opportunity to test once it is turned over.

So, by default, they have to complete their testing and ensur[ e] 100 percent functionality before they tum it over to us.

(Tr. 4/669; see also 5/894)

19. SOW ii 14, Documentation, provided:

On the date of the beginning of delivery of CLIN 0001, the contractor shall deliver full documentation of both the ET &L programs and the rehosted MOCAS including the final version of all documentation created by the contractor during the performance of the contract. ...

(R4, tab 3 at 779) "Full documentation" included, but was not limited to, a list of 24 reports, manuals, guides and other documents enumerated in the contract (R4, tab 3 at 779).

20. SOW ii 16, Government Furnished Property, required the government to provide to AEON computer workstations loaded with standard DFAS network access, access to printers, copiers, fax machines and email, desk space, telephones, general office supplies, mainframe resources, software listed in Section J of the SOW, attachments 2.4 and 2.5, and other enumerated items (R4, tab 3 at 780). There is no other provision in the contract that required the government to provide items in addition to those specifically listed. In particular, there was no contract requirement for the government to provide the government's GT&E test scripts or test plans to AEON: "[AEON was] supposed to develop their own test plans and project management plans as they were responsible for all the tests of the product before the delivery of the system for our testing" (tr. 4/661; finding 16).

21. For purposes of payment, the MOC AS Rehost contract, CLIN 0001, was structured to identify eight distinct payment events (also referred to as "Milestones" throughout the record (see, e.g., findings 11, 49) associated with CLIN 0001 tasks, the successful completion of which entitled AEON to receive event-based payments. The contract contained the following in full text:

28 Performance Based Payment Events As Implemented By FAR 52.232-32 PERFORMANCE-BASED PAYMENTS (FEB 2002)

1. Placement of purchase orders for vendors, subcontractors, suppliers for labor, travel, supplies and equipment within 30-45 days after contract award.

2. Discovery Phase completion identified by the delivery of the Discovery Findings and implications report and scheduled for the end of the 1st quarter of performance[.]

3. Proof of Concept completion identified by the results of the proof of concept and scheduled for the end of the 2nd quarter of performance.

4. Design Phase completion identified by the completion of database and application (online & batch) design and scheduled for[] the end of the 3rd quarter of performance.

5. Data conversion completion identified by the loading of the database into DB2 and scheduled for the end of the 4th quarter of performance.

6. Conversion completion identified by the successful completion of unit testing and moving all code from the development to the QA/testing environment scheduled for the end of the 5th quarter of performance.

7. QA/Testing Phase completion identified by moving software from QA/Test to User Acceptance environment and scheduled for the end of the 6th quarter of performance.

8. Completion of the delivery and acceptance of CLIN 0001 in the Production environment scheduled for the end of the ?1h quarter of performance.

(R4, tab 3 at 785) The payment events, designed by AEON and contained in its proposal, were designed to track AEON's progress through contract performance and to establish a basis for making progress payments to AEON upon its completion of the enumerated milestones roughly once a quarter (R4, tab 2 at 628-29; tr. 1162-65, 21189-90, 5/1081). The eight payment events/milestones remained in place throughout contract performance;

29 however, the later payment events were subdivided into smaller, more refined segments to provide a basis for making payments to AEON more frequently (findings 49, 63, 65, 70; tr. 3/394-97, 5/1081-85). There is nothing in the payment events identified in the contract or subsequent modifications to indicate that they included any tasks other than those associated with CLIN 0001 (tr. 5/1085). The amount of payment associated with each of the eight (8) payment events was l/8th (or 12.5%) of the total contract price for CLIN 0001 (R4, tab 2 at 628-29). There was no liquidation schedule contained in the contract (tr. 11155-56).

22. FAR 52.232-32, PERFORMANCE-BASED PAYMENTS (FEB 2002), incorporated in the contract by reference, provided:

(c) Approval and payment of requests. (1) The Contractor shall not be entitled to payment of a request for performance-based payment prior to successful accomplishment of the event or performance criterion for which payment is requested. The [CO] shall determine whether the event or performance criterion for which payment is requested had been successfully accomplished in accordance with the terms of the contract. The [CO] may, at any time, require the Contractor to substantiate the successful performance of any event or performance criterion which has been or is represented as being payable.

(2) A payment under this performance-based payment clause is a contract financing payment under the Prompt Payment clause of this contract and not subject to the interest penalty provisions of the Prompt Payment Act.... The payment period will not begin until the [CO] approves the request.

(3) The approval by the [CO] of a request for performance-based payment does not constitute an acceptance by the Government and does not excuse the Contractor from performance of obligations under this contract.

(d) Liquidation of performance-based payments. (1) Performance-based finance amounts paid prior to payment for delivery of an item shall be liquidated by deducting a percentage or a designated dollar amount from the delivery payment. If the performance-based finance payments are on a delivery item basis, the liquidation amount for each such line item shall be the percent of that delivery item price that was

30 previously paid under performance-based finance payments or the designated dollar amount. If the performance-based finance payments are on a whole contract basis, liquidation shall be by either predesignated liquidation amounts or a liquidation percentage.

(e) Reduction or suspension of performance-based payments. The [CO] may reduce or suspend performance-based payments, liquidate performance-based payments by deduction from any payment under the contract, or take a combination of these actions after finding upon substantial evidence any of the following conditions:

(1) The Contractor failed to comply with any material requirement of this contract ....

(2) Performance of this contract is endangered by the Contractor's (i) failure to make progress, or (ii) unsatisfactory financial condition.

U) Special terms regarding default. If this contract is terminated under the Default clause, ( 1) the Contractor shall, on demand, repay to the Government the amount of unliquidated performance-based payments, and (2) title shall vest in the Contractor, on full liquidation of all performance-based payments, for all property for which the Government elects not to require delivery under the Default clause of this contract. The Government shall be liable for no payment except as provided by the Default clause.

(R4, tab 3 at 802-04)

23. Under FAR Subpart 32.10, PERFORMANCE-BASED PAYMENTS, at 32.1001, POLICY, performance-based payments "are the preferred Government financing method" and they "are contract financing payments that are not payment for accepted items." FAR 32.lOOl(a), (b). FAR 32.lOOl(c) provides that performance-based payments are "fully recoverable, in the same manner as progress payments, in the event of default." Further, FAR 32.1004, PROCEDURES, provides:

31 Performance-based payments may be made either on a whole contract or on a deliverable item basis, unless otherwise prescribed by agency regulations. Financing payments to be made on a whole contract basis are applicable to the entire contract, and not to specific deliverable items. Financing payments to be made on a deliverable item basis are applicable to a specific individual deliverable item. (A deliverable item for these purposes is a separate item with a distinct unit price. Thus, a contract line item for 10 airplanes, with a unit price of $1,000,000 each, has 10 deliverable items-the separate planes. A contract line item for 1 lot of 10 airplanes, with a lot price of $10,000,000 has only one deliverable item-the lot.)

(a) Establishing performance bases. (1) The basis for performance-based payments may be either specifically described events (e.g., milestones) or some measurable criterion of performance. Each event or performance criterion that will trigger a finance payment must be an integral and necessary part of contract performance and must be identified in the contract, along with a description of what constitutes successful performance of the event or attainment of the performance criterion .... An event need not be a critical event in order to trigger a payment, but the Government must be able to readily verify successful performance of each such event or performance criterion.

(2) Events or criteria may be either severable or cumulative. The successful completion of a severable event or criterion is independent of the accomplishment of any other event or criterion. Conversely, the successful accomplishment of a cumulative event or criterion is dependent upon the previous accomplishment of another event.... The contracting officer must include the following in the contract:

(i) The contract must not permit payment for a cumulative event or criterion until the dependent event or criterion has been successfully completed.

32 (ii) The contract must specifically identify severable events or criteria.

(iii) The contract must identify ... which events or criteria are preconditions for the successful achievement of each cumulative event or criterion.

(v) If payment of performance-based finance amounts is on a deliverable item basis, each event or performance criterion must be part of the performance necessary for that deliverable item and must be identified to a specific contract line item or subline item.

(b) Establishing performance-based finance payment amounts. (1) The [CO] must establish a complete, fully defined schedule of events or performance criteria and payment amounts when negotiating contract terms ....

(3) The contract must specifically state the amount of each performance-based payment either as a dollar amount or as a percentage of a specifically identified price (e.g., contract price, or unit price of the deliverable item) ....

( d) Liquidating performance-based finance payments. Performance-based amounts must be liquidated by deducting a percentage or a designated dollar amount from the delivery payments. The [CO] must specify the liquidation rate or designated dollar amount in the contract. The method of liquidation must ensure complete liquidation no later than final payment.

(1) If the [CO] establishes the performance-based payments on a delivery item basis, the liquidation amount for each line item is the percent of that delivery item price that was previously paid under performance-based finance payments or the designated dollar amount.

33 (2) If the performance-based finance payments are on a whole contract basis, liquidation is by predesignated liquidation amounts or liquidation percentages.

24. Prior to invoicing the government for any performance-based payment, AEON was required by the contract to submit a Milestone Payment Event Delivery Report (MPEDR) which was a living document to which, before submission for each payment, was added the most recently updated information (see, e.g., app. supp. R4, tab 169; tr. 2/191, 4/716). On each MPEDR AEON indicated the work that had been done to justify the payment requested. The CO authorized the release of performance-based payments only after the DFAS Program Management Office (PM0) 13 verified that the items reported by AEON as completed were the items required to be completed by any particular payment event. (Tr. 1169-70, 2/174-75, 189-90, 3/397, 4/716-19, 511082) The PMO did not perform an independent check or test to determine whether the work reported as completed by AEON was actually completed (tr. 4/719). AEON's MPEDR dated 1December2006 14 included the following statement by AEON:

System Background

1.1.1 Business and System Objectives

The objective of the MOCAS Rehost Project is to perform a technology update, migrate the MOCAS system from the proprietary environment of MANTIS/SUPRA to the non-proprietary software environment of CI CS/COBOL and DB2, and merge the three existing databases into one consolidated database. The rehosted MOCAS system will contain all of the functionality of the current MOCAS system and, from a business and end user perspective, will mirror the current system. Therefore the changes that occur as a result of rehosting the system will be totally transparent to the users.

(App. supp. R4, tab 169 at 12)

13 (See finding 26). 14 This is the report that sought payment through Payment Event 7A-2 (app. supp. R4, tab 169 at 2). There is no evidence in the record that the quoted language was absent or different from any previous iteration of the MPEDR.

34 25. The contract incorporated FAR 52.249-8, DEFAULT (FIXED-PRICE SUPPLY AND SERVICE) (APR 1984) (R4, tab 3 at 787), which provided in pertinent part:

(a)(l) The Government may, subject to paragraphs ( c) and (d) of this clause, by written notice of default to the Contractor, terminate this contract in whole or in part ifthe Contractor fails to-

(i) Deliver the supplies or to perform the services within the time specified in this contract or any extension;

(ii) Make progress, so as to endanger performance of this contract (but see subparagraph (a)(2) below); or

(iii) Perform any of the other provisions of this contract (but see subparagraph (a)(2) below).

(2) The Government's right to terminate this contract under subdivisions (a)(l )(ii) and (1 )(iii) above, may be exercised if the Contractor does not cure such failure within 10 days (or more if authorized in writing by the Contracting Officer) after receipt of the notice from the Contracting Officer specifying the failure.

(f) The Government shall pay contract price for completed supplies delivered and accepted ....

C. Contract Performance

26. The PMO "had the day to day responsibility to ensure that this program was proceeding forward at the anticipated pace that it should, and to ensure that various events and milestones were being achieved" (tr. 1141 ). At all times relevant to this appeal, the DF AS MOCAS Program Manager was Anthony Castrillo. The PMO consisted primarily of Mr. Castrillo, COR Hecker 15 (deputy project manager and the primary COR from

15 COR Hecker was part of the DFAS/DCMA team that wrote the SOW for the Rehosted MOCAS (tr. 4/658-59, 696) and was the lead on the cost evaluation team that reviewed proposals, including AEON's (tr. 4/655, 5/891-92).

35 16 contract award through October 2005) and COR Thrower (the primary COR from October 2005 through the end of the contract). (Tr. 1/4 I, 4/65 I, 4/654, 5/1069-76) The COR was the primary day-to-day contact for AEON (tr. 3/387-88, 400-0I, 506). During GT&E, COR Thrower was the liaison between the CO, AEON and the government testers (tr. 3/393).

27. AEON's MOCAS Rehost Project Plan identified the various phases of the contract work as WBS I-I I (see, e.g., app. supp. R4, tab I 72 at 5-6). WBS I-8 correlated to Payment Events I-8 identified in the contract (finding 2 I).

I. WBS I, PREPARE & INITIATE

28. WBS I correlated to Payment Event 1, the required tasks for which were identified in the contract as "Placement of purchase orders for vendors, subcontractors, suppliers for labor, travel, supplies and equipment within 30-45 days after contract award" (finding 2 I).

29. AEON's 29 December 2006 MOCAS Rehost Project Plan showed that WBS I/Payment Event I was started on 28 May 2004 and completed on 30 August 2004 (app. supp. R4, tab I 72 at 5). AEON was paid for WBS I/Payment Event I on I June 2004 (app. supp. R4, tab I 72 at 8).

30. Shortly after award of the contract the government learned that AEON's proposed Project Manager, John Allwood, and Technical Manager, Lech Lakomy, were not AEON employees and that the NPGen automated conversion tool proposed by AEON to be its proprietary product was actually the property of SOC Software, Inc. (SOC) which was owned by Allwood and Lakomy. Apparently, AEON had not reached an agreement with SOC and, almost immediately upon starting work on the project, AEON and SOC, along with Allwood and Lakomy, parted ways. (Finding 7; supp. R4, tab 106 at 5) On I6 November 2004, eight months into the contract performance period and almost three months after the start of its design process (findings 37, 39), AEON formally requested permission from the government to use conversion tools other than NPGen:

16 COR Thrower was a member of the DF AS/DCMA team involved in the drafting of the SOW, particularly in the area of the description of the As-Is MOCAS (tr. 3/387). At the time of her testimony, Thrower had 25 years of experience with the MOCAS system, I 8 years with the DISA and nearly 7 years with DF AS. While employed by DISA, where the MOCAS system was hosted on a DISA mainframe (tr. 3/384-85; finding 4), one of her responsibilities was to install software changes to MOCAS (tr. 3/377-78). Thrower also participated in the evaluation of AEON's technical proposal (tr. 3/523-24, 4/656).

36 [AEON] performed a risk assessment study focusing on the code conversion toolset. Our goal was to identify the best toolset for the MOCAS Rehost Project .... We identified 13 viable CCT£1 7l vendors and narrowed the list to 2 finalists: NPGen which we originally proposed and TMGi-Transformer toolset from Trinity-Millennium Group, Inc. (TMGi). Our detailed evaluation resulted in TMGi equaling or exceeding the NPGen functionality in every evaluation category. Therefore, we are seeking DF AS approval to amend the MOCAS Rehost Project Contract to replace TMGi CCT and iSAT repository for the NPGen CCT and NPGen Repository that was originally proposed.

Benefits. The TMGi-Transformer CCT and the related iSAT Repository provide excellent capabilities, specifically tailored code conversions to CICS COBOL and DB2 from Mantis and Supra respectively. TMGi also offers technical support services related to both the user of the CCT and the normal activities associated with code conversions. TMGi specializes in IT portfolio modernization and offers extensive documentation services as well as actual code conversion. [AEON] is currently using TMGi's Knowledge Mining services to support our program documentation activities. Adding the TMGi transformation services provides an integrated solution appropriate for the MOCAS Rehost Project.

Impact If No Approval. [AEON] could continue to use the NPGen code conversion tool and repository as originally proposed. However, [AEON]' s recent assessment indicated that the project risks are higher and the CCT capabilities would be less than ifTMGi-Transformer were substituted.

[AEON] would extend the current agreement with TMGi to include code conversion services. From a DFAS perspective there would be little or no change to the [AEON] approach proposed for the MOCAS Rehost Project. The project repository content would continue to be stored on the project

17 We understand this to be an acronym for Code Conversion Tool.

37 servers using SQL Server and MS Visual SourceSafe, a widely-used COTS product for configuration management, would [be] substituted for the proprietary CM[ I SJ capabilities that were to be incorporated into the NPGen Repository. The COTS approach to CM is a less risky approach tha[ n] the custom developed, proprietary approach associated with NPGen. As an added benefit, TMGi delivers an easy to use, browser-based user interface to front-end the iSAT repository that is delivered along with their services.

Cost Impact. None. The proposal to utilize TMGi has an additional cost to the project. However, we believe the breadth of capabilities of the TMGi-Transformer toolset will allow us to accomplish the rehost project objectives with fewer staff. The staff efficiencies associated with the use of TMGi offset the costs of their toolset/services and some of the additional scope/costs identified during the Discovery Phase ....

Team Impact. Minimal. The proposed toolset and associated repository are easier to tailor and use than the approach originally proposed.

(R4, tab 9 at 959-60) The government approved the request on 8 December 2004 (R4, tab 9 at 961) because it "saw benefit" in the use of the TMGi tools and services AEON requested to use in place of the NPGen tool:

[W]hen [AEON] changed to the [TMGi] tool, that tool brought to them a discovery method that would allow you to go in and extract the information from the system, which was a lot more accurate than a handwritten document[ ation]. So they had the opportunity to get [system] information from things that they developed.

{Tr. 5/906-07) The lack of an agreement with SOC for the NPGen conversion tool also meant that key individuals Allwood and Lakomy in AEON's proposed management team

18 Configuration Management (R4, tab 25 at 1187).

38 (finding 7) were no longer going to participate in the project (supp. R4, tab 106 at 5-6; tr. 1/52, 57-60, 2/280-87, 4/738-39).

As a result of these initial changes AEon requested, their whole approach and management structure was changed from their proposal. The number and nature of the changes raised concern with the Government. The main concern being that many of the items (i.e. Management and tool set) being replaced were those items the Government saw as strengths in their proposal and were important reasons for selecting AEon. Despite these concerns, the PMO honored the premise of a Firm Fixed Price Contract, in that the Government should not direct the contractor in how they perform their work; honored the premise that the contractor should be the best judge of their competency and tools required; and in good faith allowed AEon to proceed with their changes.

(Supp. R4, tab 106 at 6)

2. WBS 2, DISCOVERY

31. WBS 2 correlated to Payment Event 2, the required tasks for which were identified in the contract as "Discovery Phase completion identified by the delivery of the Discovery Findings and implications report and scheduled for the end of the 1st quarter of performance" (finding 21). AEON's 29 December 2006 MOCAS Rehost Project Plan showed that WBS 2/Payment Event 2 was started on 16 August 2004 (app. supp. R4, tab 172 at 5).

32. The discovery phase of the contract was considered a significant portion of contract performance (findings 6 (at Questions 33, 74), 12). CO Gladski testified that the government built the discovery phase into the contract so AEON had an opportunity to analyze the As-Is MOCAS:

[U]p front, even before they started to do any coding.. . . And we paid them very well for that particular phase. We considered that probably one of the most critical steps of the program, was for them to know what was inside that [As-Is] MOCAS ....

(Tr. 1199, 4/665; see also tr. 11132-34, 2/235-41; app. supp. R4, tab 169 at 12-13) The government's only role in the discovery phase was to provide the As-Is MOCAS (findings 1, 12) to AEON for its study and analysis (tr. 11100). The discovery phase:

39 [I]s one where you would discover scope issues, as well as complexity issues. I mean, for example, there may have been a lot more code than was originally understood to be there.

The code may be way more complicated than folks had originally expected, and things of that sort.

Because typically when one proposes, there is a certain amount in any program -- well, let's just say uncertainty and over-optimism ... [and the discovery phase helps eliminate that type of problem].

(Tr. 7/1191-92, 1247)

33. In its 15 October 2004 Discovery Findings Report (Version OlA), AEON identified 4, 100 hours of additional work identified during the discovery phase of the contract (R4, tab 7 at 950-51 ). In the 27 October 2004 PMO review of the report, the government acknowledged that some of the source code had been missing and either provided additional information to AEON or expressed that additional research would be done (R4, tab 7 at 949, ~~ 6, 16, 23, at 950-51, 953, ~~ 8, 17-18, 29-32, at 952, ~~ 20, 26; tr. 4/665-67, 743). In response to AEON's request for test data, the government reminded AEON that test data and copies of production interface files were not identified in the solicitation as government-furnished items (R4, tab 7 at 950, ~ 7; see also finding 20). The government further stated in response to AEON' s various requests for test data:

Although the government will try to accommodate any request for copying inbound data sets from production, we will not guarantee these data sets test 100% functionality. Aeon must recognize that it is Aeon's contractual responsibility to develop test data to ensure the rehosted system meets the contract requirements. The Government will not provide test data. The Government provided an as-is snapshot that is a replica of the production environment that is able to process any and all data that the corresponding production database can. There was always a possibility that specific types of data may not be included in the snapshot at the time it was replicated. Test data and copies of production interface files were not identified as government furnished property in the solicitation.

40 (R4, tab 7 at 949-54, iii/ 5, 28, 34, 35; see also findings 6, 12)

34. AEON's 29 December 2006 MOCAS Rehost Project Plan showed that WBS 2/Payment Event 2 was completed on 15 November 2004 (app. supp. R4, tab 172 at 8). AEON was paid for WBS 2/Payment Event 2 on 19 November 2004 (app. br. at 12-16).

35. On 2 December 2004 AEON advised the government that: "The AEON Group, LLC has completed our impact assessment on cost and schedule based on the phase 2 Discovery Report Findings and are pleased to report that there will be no change to price and schedule as a result of these findings" (R4, tab 8) (emphasis added).

3. WBS 3, DESIGN

36. WBS 3 correlated to Payment Event 4, the required tasks for which were identified in the contract as "Design Phase completion identified by the completion of database and application (online & batch) design and scheduled for[] the end of the 3rd quarter of performance" (finding 21).

37. AEON's 29 December 2006 MOCAS Rehost Project Plan showed that WBS 3/Payment Event 4 and WBS 4/Payment Event 3 (see finding 39) were both started on 16 August 2004 (app. supp. R4, tab 172 at 5).

38. AEON's 29 December 2006 MOCAS Rehost Project Plan showed that WBS 3/Payment Event 4 was completed on 31January2005 (app. supp. R4, tab 172 at 5; supp. R4, tab 106 at 8-9). AEON was paid for WBS 3/Payment Event 4 on 18 April 2005 (app. supp. R4, tab 172 at 8).

4. WBS 4, PROOF OF CONCEPT

39. WBS 4 correlated to Payment Event 3, the required tasks for which were identified in the contract as "Proof of Concept completion identified by the results of the proof of concept and scheduled for the end of the 2nd quarter of performance" (finding 21). AEON's 29 December 2006 MOCAS Rehost Project Plan showed that WBS 4/Payment Event 3 and WBS 3/Payment Event 4 (see finding 36) were both started on 16 August 2004 (app. supp. R4, tab 172 at 5). "The conversion process was divided into several concurrent phases to include the conversion of the database, on-line programs, batch programs, SDW interface and Contract Transfers" (supp. R4, tab 106 at 9).

41 40. AEON's 29 December 2006 MOCAS Rehost Project Plan showed that WBS 4/Payment Event 3 was completed on 25 February 2005. AEON was paid for WBS 4/Payment Event 3 on 18 April 2005. (App. supp. R4, tab 172 at 8)

5. WBS 5, CONVERT

41. WBS 5 correlated to Payment Events 5 and 6. The required tasks for Payment Event 5 were identified in the contract as "Data conversion completion identified by the loading of the database into DB2 and scheduled for the end of the 4th quarter of performance." The required tasks for Payment Event 6 were identified in the contract as "Conversion completion identified by the successful completion of unit testing and moving all code from the development to the QA/testing environment scheduled for the end of the 5th quarter of performance." (Finding 21) AEON's 29 December 2006 MOCAS Rehost Project Plan showed that WBS 5/Payment Event 5 was started on 3 January 2005 and continued through 11 October 2006 (app. supp. R4, tab 172 at 5). The record shows that AEON was paid for Payment Event 5 on 21 June 2005 (app. supp. R4, tab 172 at 8).

42. Michael Krajnak became involved in the MOCAS Rehost project during the discovery phase in September 2004 as an employee of CSC (see finding 8), to whom AEON subcontracted certain contract work. His primary work was as the lead on-line programmer responsible for converting the MANTIS code to COBOL. Toward the end of his tenure with the project in 2006 he became the "transition planner" and worked on the MOCAS Rehost project through May 2006 (see finding 51 ). Krajnak had extensive experience with computer programming and testing beginning in 1981. He had previously worked on a project performed by Boeing involving the Shared Data Warehouse (SDW), a separate system linked to the MOCAS (finding 5). (Tr. 4/838-45, 853-55, 860-61, 866-68, 870-73) Krajnak described his duties as oversight of programming and conversion work by AEON and contract employees, as well as working with the AEON testing team (tr. 4/845).

43. In a 13 April 2005 internal email, just four months after its approval (finding 30), AEON identified numerous "issues" with the TMGi conversion tool:

~ Tool Development Issues: o The tool was developed from scratch using VB£ 19l at our expense. o We paid and are paying for it. o The tool that was shown to us originally was a Rex based tool.

19 We understand this to be a reference to Visual Basic, a programming language.

42 o We were led to believe that TMGi has a tool that can convert Mantis to CICS COBOL and SUPRA to DB2. This tool only needed to be customized to the MOCAS unique requirements o We provided all the specs for the development of the VB tool o Chuck [Cotton] spent a great deal of his time debugging the tool and assisting TMGi with tool design, development and improvements o TMGi lacked Mantis, CICS and DB2 knowledge and expertise. We provided these capabilities for TMGi

~ Transformation project performance issues: o The project plan developed by TMGi was not adhered to and no updated plans have been given to Aeon. All to-date pre-production dates have been missed: • The final transformation for the first two online deliverables, due in February, have not occurred yet. We have not been notified of a new date for their delivery. Based on the quality of work we can not assess or assume a delivery date • The other online groups planned for March and April have not been delivered and no new dates have been provided to us. • The batch commitments have not been met. The work on interface transformation has not started • The TMGi missed dates have had a significant negative impact for the delivery of our code to QA. Without significant intervention and addition of new resources by Aeon, this can cause us to miss our commitments to our client by about 6-8 weeks (first major online deliverable, YC02 with 400 programs, was due to move to QA on 4126105 based

43 on its delivery from TMGi to Aeon in February 2005. The new date is 6/17/05) Aeon by [sic].

o The project quality has been inconsistent and poor; • Progress achieved in December and January was considerably deteriorated until the mid March time frame when it started improving. We had 180,000 errors in the first two online groups (YSUOl & YCU02). These errors were subsequently grouped by Aeon into 10 groups for the purpose of discussions with the client. Some of the errors were Aeon related but majority were TMGi. We assume contributing factors to the deterioration are the events that occurred during the role change between Stan and Mike. Mike had been involved in the online and Stan in the batch transformation. During the end of January and early February, Mike handed off the online to Stan and Stan handed off the batch to Clarence. The consolidation of the transformers on Mike and Stan's PCs caused major tool confusion and led to numerous errors. • Work quality on the weekly handoffs from TMGi are very inconsistent. Some weeks the work is good and many weeks the work deteriorates as compared to the previous handoffs. To-date there are 80,000 errors on the above mentioned two online groups. • Considerable overtime charged to Aeon during the period when the hand-off occurred and tool was considerably deteriorated. While we did not support the minimization of Mike's involvement and the handoff of the online to Stan, we expected a smooth transition and did not

44 expect to pay overtime for deteriorating work quality.

o Lack of a development environment at TMGi office to perform the work to produce its committed 100% comp liable code: • While TMGi insisted to work one week onsite and one week [oft] site, TMGi did not have a development environment similar to MOCAS (mainframe) to perform compilation and assess its tool and transformation quality before handoff to Aeon. • Since Aeon was using Micro Focus COBOL for its development environment, Aeon provided TMGi with a thirty day trial Micro Focus COBOL software. Aeon's understanding was that TMGi will procure its own license at the end of the thirty days. We are told that the 30 days trial license has expired and TMGi has not procured its own license. As a result TMGi can no longer compile and test its tool and transformed code prior to hand off to Aeon. This can explain the inconsistent work quality received by Aeon.

? Aeon issues: o Aeon has not been paying TMGi invoices on a timely fashion due to internal process problems. This has been remedied and new processes have been established to avoid the delay o Aeon has not provided some information to TMGi on a timely fashion. Other information needed by TMGi, copy books, has been made available to TMGi and can only be accessed while TMGi is onsite [every other week.]

45 (Supp. R4, tab 52) (Emphasis added) Thereafter, in or around the second quarter of 2005, AEON parted ways with TMGi after experiencing significant problems with the TMGi tool "not converting the anticipated amount of code or MANTIS functionality" (supp. R4, tabs 63, 106 at 9-10). From that point on, the conversion process included much more manual conversion and experienced multiple delays (supp. R4, tab 106 at 10, 13-14; R4, tab 64; tr. 1/88, 4/743, 857-59).

44. In an internal email dated 5 October 2005, and identified as "Updated Situation Analysis," AEON's Program Manager (see R4, tab 25 at 1162), acknowledged that AEON had not disclosed to the government "the poor quality of the TMGi tool" and that AEON "need[ed] some time to address all the deficiencies we have discovered" (supp. R4, tab 63). Also on 5 October 2005, and in apparent preparation of the same "Updated Situation Analysis," AEON contractor employee Krajnak (finding 42) expressed concerns about the ability of AEON to meet the contract delivery dates and functionality requirements:

Need to tell the client that the project will be delayed at least six months and that UAT will not start on Jan 2006 but on July 2006. The government expects both batch and online programs to function properly at the start ofUAT. The 377 unconverted online programs will take 2 months to get ready for QA testing. The online and batch programs will need 4 months to fix defects in order to pass the QA functionality tests. Performance, Interface, and System tests will take an additional 3 months.

(Supp. R4, tab 64)

45. On 5 October 2005 AEON formally requested an extension of just 1Yz months to complete the conversion process (supp. R4, tab 106 at 10), not the six months recommended by Krajnak (finding 44) and, with respect to its QA testing, stated to the PMO:

This is a very complex project that needs continuous management attention. This is the reason that the internal audit function has focused on proactive improvement recommendation rather than periodic statements of assessment. I would also like to explicitly express our QA strategy and approach for the project:

• QA is a five month set of continuous activities that produces a deliverable (fully tested Rehosted MOCAS)

46 at its conclusion. While we have specific tests that we will be conducting at different times during the five months duration, these are internal progress points and QA has a single final deliverable. • The functionality testing to be completed by 12/30/05 is intended to provide enough verification of the functionality that would enable the remainder of our QA (systems testing) activities to be conducted. We recognize and believe that we may have functionality defects that will be identified and corrected throughout the five months QA period.

(Supp. R4, tab 68 at 4) In a 7 October 2005 email, AEON advised the PMO that:

Impact to QA:

It was determined that the time remaining to perform functional testing and defect resolution was insufficient to produce a fully functional quality product ready for system testing. Therefore functional testing was extended from 10/14/05 to 12/30/05 in order to achieve that objective.

(R4, tab 65) AEON also stated in the email that "some lines of code were dropped during the transformation process" when the "transformation tool was unable to handle specific MOCAS code complexities." Even though the record makes clear that AEON was aware of significant TMGi conversion problems no later than April 2005 (finding 43), it reported to the PMO that this problem with the "transformation tool" was "discovered during QA testing in August [2005] and caused additional work in September [2005]." (Supp. R4, tab 65) The AEON request in early October 2005 for an extension to complete the conversion process was the first indication the government had that AEON's ability to meet the contractual milestone dates was slipping (tr. 3/430-32).

46. On 19 October 2005 AEON contract employee Krajnak reported:

Initial defect rate of the online programs is extremely poor. Zero programs have passed QA testing. YINV has 13 critical defects for 4 programs. YSUl has 16 critical defects for 24 programs. The lack of real unit testingczo1 is a risk to completing the QA functional testing before system I performance test starts on Jan 2006. It is an extremely tight

20 (See findings 16, 47, 55-59).

47 schedule to test and resolve all functional errors by Dec 2005. Suggest adding additional 3 months delay to the schedule to ensure that all known functional errors are resolved before government testing.

(Supp. R4, tab 66) As of 9 November 2005, Krajnak was still reporting significant failures of programs in QA testing (supp. R4, tab 66).

4 7. On 4 November 2005 the government was advised that AEON had removed its QA and Test Manager from the project (supp. R4, tab 69). Despite record evidence of the significant code conversion problems due to the failure of the TMGi tool and the failure of AEON to perform unit testing (findings 43-46), on 9 November 2005 AEON management glossed over the conversion tool problems and insisted to the PMO that, with respect to unit testing:

• We have and will continue to conduct unit testing. • Unit testing is the category of testing that developers perform on a single program. This test is performed against a program specification to ensure that each program performs in accordance with its program specifications. Unit testing is not a user/business functionality testing because usually a single program does not address the full scope of each user function. User functions are usually addressed across several programs. When programs specifications are not available, the unit testing becomes "reasonability" testing. • Unit testing for conversion projects is very different from new development projects. In the new development project business and systems requirements specifications are available. From these specifications, architecture and designs are developed and documented. The design documents are used to create program specifications which in tum enable program development. Programmers develop their programs in accordance with the program specification. When the program is developed the programmer unit tests the program against the program specifications. For conversion projects such as MOCAS Rehost there usually are no business or system requirements and no design or program specifications. Further the programs are partially or

48 fully converted using a tool. Therefore, there are no specifications to use to test the program against and the programmer does not have an in-depth knowledge of the program in order to conduct a comprehensive unit testing. In such cases limited tests are conducted to confirm reasonableness of the converted code. These tests are conducted to verify that each program is compiled correctly, can be executed and run without error. Further, screens are also brought up with representative data to observe that reasonable data appear on them. • The unit testing no matter how comprehensive would not have identified the majority of the defects identified in QA. Many of the defects that caused the numerous hand offs to QA were related to screen field layout which is not a critical problem but for automated testing it stops the test from further execution. These defects can not be discovered during unit testing. They are discovered during the functionality testing.

(Supp. R4, tab 68) The PMO later reported that:

During the Conversion Phase, AEon conveyed that they were streamlining their testing. The streamlining consisted primarily of reducing the amount of unit testing performed .... l 211 [I]t appears that AEon did not meet the objectives defined in their [STP] and [PQAP] as indicated in their certification prior to GT &E. Although the PMO does not have insight into all causes of AEon's non-performance, it is our position that AEon did not perform the level of care in their testing that is required by industry standards and best practices. The PMO believes that the reduced level of care was the primary cause for the lack of quality in their delivered product. The PMO also, believes that by de-scoping their testing requirements and not fully ascertaining the functionality of the As-Is system, AEon did not fulfill their obligation of ensuring that the rehosted system had I 00% functionality of the As-Is system.

21 See finding 46; tr. 4/846-47.

49 (Supp. R4, tab 106 at 11) We find AEON's position that, instead of unit testing, all it could perform in a conversion project such as the one now at issue was "limited [reasonableness] tests" to be contrary to the weight of the record before us. AEON's position is contrary to its own proposal with regard to testing (finding 7), is contrary to the contract requirements (finding 16), is contrary to AEON's own PMP (findings 11, 55), and ignores the significant fact that, in this particular conversion project, AEON was provided with a full copy of the As-Is MOCAS, including production data, that comprised a comprehensive performance specification to which AEON was to design and build the Rehosted MOCAS and against which it could test and compare every aspect of the Rehosted MOCAS (see finding 12).

48. AEON reported that it had successfully completed the conversion process for the on-line and batch programs on 18 November 2005. By 16 December 2005 or soon thereafter the Contract Transfer and SDW interface conversions were also reported as complete and the entire conversion process was reported to be completed by 11 October 2006. (Supp. R4, tab 106 at 10; app. supp. R4, tab 172 at 5) AEON's testing of the conversion effort took nearly two years (see finding 41 ). The PMO later reported:

Due to AEon minimizing issues and continually reassuring the Government that the project was going as planned, the Government does not have insight into what may have caused these defects. We do not know how successful the TMGi tool was at converting the code; how many problems were brought about by the requirement for manual conversion; if AEon' s testing method was insufficient or a combination of these factors lead to the problems found during GT &E.

(Supp. R4, tab 106 at 10)

49. Modification No. (Mod. No.) P00006, dated 9 January 2006, modified the delivery date for the Rehosted MOCAS (CLIN 0001) to 4 May 2006 and subdivided payment events 6 and 7 into 6A, 6B, 7A and 7B with specific tasks under CLIN 0001 identified to each subdivision as follows:

The MOCAS Rehost Project contract defines eight (8) Milestones with their related Performance-based Payments. Beginning with Milestone 6 the contract payments are revised to relate to Payment Events that are Performance-based, each of which includes evidence to support completion of these Performance-Based Payments as shown in the following table ....

50 No. 6A- Code Conversion Event- Evidence for payment per 60% Applications Converted. contract: "Conversion completion identified by the Estimated Payment successful completion of unit Request date l / 16/06 testing and moving all code to ,, the QA/Test environment. ..

... Updated Program Management Plan due 1115/06 .... No. 6B- Functionality Testing Evidence for payment per 40% Event revision to contract[:] "Level I & Level II Functionality Estimated Payment Testing complete and Request date 3/31/06 Documentation Deliverables with various publication dates between January 03 and March 31, 2006. Refer to Extended MOCAS Rehost Project Plan (WBS): • Level I & Level II Functionality Testing complete 0 All automated test scripts completed 0 All database and file compares completed .... No. 7A- User Acceptance Event Evidence for payment per 50% revision to contract: "User Estimated Payment Acceptance event identified by Request date 5/4/06 moving software from QA/Test environment to User Acceptance environment for start of User Acceptance Testing ... and Documentation deliverables with dates as listed below." • User Acceptance includes: ° Functional configuration Audit 0 Operational User Acceptance Test Environment

51 0 Training conducted for computer operations, application programmers and technical support personnel. ... No. 7B User Acceptance Event Evidence for payment per [50%] Complete revision to contract: "User Acceptance event completion Estimated Payment identified by the expiration of Request date 8/4/06 the contractually defined 90-day UAT period within which the following items are delivered: • A complete set of documentation as outlined in Section C 14 of the SOW • Fully tested and debugged MOCAS system .... No. 8 Production Complete Evidence for payment per Event contract: "Completion of the delivery and acceptance of Estimated Payment CLINOO 1 in the Production ,, Request Date 12/1/06 environment ... • Acceptance of CLINOO 1 in the Production environment and completion of all tasks in the SOW including: 0 MOCAS Rehosted System installed in the Production Environment 0 A complete set of final documentation as outlined in Section C 14 ofthe SOW 0 Delivery of the MOCAS Rehosted System and Migration Programs 0 The sequential migration of the three AS-IS MOCAS databases to the new MOCAS Production System

52 0 Signed off Production System 0 Updated Milestone Payment Event Delivery Report ....

(R4, tab 3 at 848, 856-60) Mod. No. P00006 included a mutual release stating that both parties "acknowledge full and final settlement for all past conditions leading to and culminating with the release of this contract modification" (R4, tab 3 at 850).

50. Mod. No. P00005, also dated 9 January 2006, accepted AEON's ECP-1, increased the contract price by $70,633.00 and further extended the contract completion date to 9 June 2006 (R4, tab 3 at 839; see also supp. R4, tab 106 at 9).

51. AEON subcontractor CSC employee Krajnak (finding 42) testified that, at some point in the project, AEON had not paid CSC for seven months of work (see finding 62). As a result, seven CSC employees including Krajnak were notified by CSC that they were free to take employment elsewhere. Krajnak was approached by AEON to become an AEON employee; after considering it over the weekend, on 21 May 2006, Krajnak declined AEON's offer. (Tr. 4/861-66) Instead, he accepted employment with DCMA in support of the MOCAS project (supp. R4, tab 77).

6. WBS 6, DOCUMENTATION

52. WBS 6 correlated to Payment Event 7 A, the required tasks for which included "User Acceptance event identified by moving software from QA/Test environment to User Acceptance environment for start of User Acceptance Testing ... and Documentation" (findings 21, 49). AEON's 29 December 2006 MOCAS Rehost Project Plan showed that WBS 6 was started on 13 September 2004 and the documentation for the Rehosted MOCAS was reported to be 99% complete as of the date of the report (app. supp. R4, tab 172 at 5).

53. On 19 September 2005 CO Gladski notified AEON by letter that: "Aeon is also hereby notified that ... milestone payment 6 will be delayed as milestone payment 6 remains contingent on the delivery of all documentation" (R4, tab 16). Milestone payment 6 was later subdivided and reconfigured numerous times (findings 49, 54, 63, 65, 70).

53 7. WBS 7, AEON'S QA/TEST; DELIVERY OF DOCUMENTATION AND REHOSTED MOCAS FOR GT&E; POST-GT&E DELIVERY COMPLETION

54. WBS 7 correlated to Payment Event 7. AEON's 29 December 2006 MOCAS Rehost Project Plan showed that WBS 7 was started on 19 July 2004 (the official start of the entire project) and was completed on 20 October 2006, a period of 32 months (R4, tab 106 at 1; app. supp. R4, tab 172 at 5). Because of the complexity and length of time required to complete all of these tasks, Payment Event 7 was later subdivided into 7Al, 7A2, 7A3 and 7B (findings 49, 70). Payment Event 7Al required the completion of AEON's QA/Test (except what was specified for completion in Payment Event 7A2 below), delivery of the Rehosted MOCAS for GT &E and delivery of all documentation except that specified to be delivered under Payment Events 7A2 and 7A3 (R4, tab 3 at 921-22). Payment Event 7A2 required delivery of the Software Design Description (SDD) documentation and Completion of AEON's Level II Functionality Testing for Contract Transfers, LUW 16 (R4, tab 3 at 923). Payment Event 7A3 required delivery of remaining documentation (id.). Payment Event 7B required that, by the end of the 180-day GT&E government testing period (finding 18), AEON had migrated all three MOCAS databases (i.e. MOCs) into production and had delivered a ''[f]ully tested and debugged MOCAS system" with complete updated documentation (R4, tab 3 at 924; tr. 3/411, 417).

a. AEON'S QA/TEST

55. AEON's PMP included the following section pertaining to testing:

2.9 Test and Evaluation Management To provide comprehensive testing and deliver high quality results, testing has been grouped into [the] following ten major categories:

• Unit Testing - The objective of unit testing is to ensure that each program is fully tested by the conversion team prior to handoffto the test team.

• Functional Testing- The objective of the functional testing is to ensure that the rehosted MOCAS System with the converted databases on the new hardware environment has 100% of the functionality (screen emulation, screen layout, order of fields, edits, error messages, help button, reports, and interfaces) of the current MOCAS System including the online, batch and the database.

54 • Technical System Testing- The objective of technical testing is to ensure that the rehosted MOCAS System is in 100% compliance with the relevant MOCAS technical and architectural characteristics, internal control, etc.

• Performance Testing- The objective of performance testing is to ensure that the rehosted system will have the same or improved system response time, batch windows, capacity for ongoing operations, performance under high transaction volumes and other performance characteristics as compared to the current MOCAS System. Further, users who access the system from various locations worldwide can continue to do the same with the rehosted system, with the same or improved performance[.]

• Security Testing- The objective of the security testing is to ensure that the rehosted system will have the same security accreditation as the current MOCAS System which is Certification and Accreditation Level 2, in accordance with DoDI 5200.40, DoD Information Technology Security and Accreditation Process and DoDD 5200.28, Security Requirement for Automated Information.

• Conversionffrial Migration Testing - The objective of trial migration testing is to test the conversion of the three "as-is" MOCAS databases to the one "target" database test environment to ensure that all the data is converted, the conversion processes are optimized and will take place well within the prescribed conversion time frame.

• Regression Testing - The objective of regression testing is to provide fast, automated and high quality means of re-testing the software after corrections have been applied to software problem fixes. Regression files are created from test cases and used for final functionality verification.

55 • Integration/End-to-End Testing - The objective of integration/end-to-end testing is to ensure that the rehosted MOCAS System with the converted databases on the new hardware environment correctly integrates all MOCAS System components to perform an end-to-end system transaction in exactly the same manner as the current MOCAS System. Specifically, the new system can perform a business transaction from its inception on the rehosted MOCAS System through the internal and external interfaces and provide the same results as obtained with the current MOCAS system.

The test plans will be initially executed against the baseline system. The test plans will then be re-executed in the QA target region. The baseline results will be compared to the target results, corrections made and tests re-executed as appropriate. Refer to the Software Test Plan for the details associated with all the testing to be performed. The fully tested target chunk will then be moved to the staging environment. The Repository is updated with test completion and staging activity completion dates. A final reconciliation of the Repository and the actual components by chunk take place to reconfirm that all life cycle activities have taken place.

AEON is sensitive to the Government's performance expectations that were defined in the MOCAS Rehost As-Is Documentation, MOCAS Rehost As-Is Attachments. When we are ready to execute performance testing, we will create a "production-like" environment with the same priority level as production. We will run tests against the baseline environment, rerun the same tests against the target environment, compare the results, make adjustments and rerun as appropriate until the same or better performance is received in the target environment.

(R4, tab 25 at 1191-92)

56 56. Unit testing is "fundamental" (tr. 7/1202) and "is the most intense testing performed" (tr. 5/902).

[E]ach individual program is tested by itself, and then it gets further integrated into kind of a group of programs that will perform their function, which is integration testing. And then that rolls up to even greater as the whole, the system testing .... and then user acceptance testing.

(Tr. 4/662)

57. The record reflects that, by 8 June 2005, AEON management had made "a change in direction to skip unit testing" and that some of AEON's employees were "questioning [AEON's] intent to deliver a functional system" (supp. R4, tabs 55, 56). AEON's lead programmer, CSC subcontract employee Krajnak (findings 42, 46), testified that:

[AEON' s] initial direction with the unit testing was that the programmers were allowed to use normal processes to work through the code, and to basically bring it up to the state where it should be given over to the testers for testing.

[To skip unit testing] was a change in direction and the staff was pretty upset about it, and that they were then told that they could no longer look at the logic of the old programs.

That they had to just take the programs and get them compiled cleanly, and send them over the fence to the testing unit, basically bypassing what I would expect the normal unit testing by the programmers [to be].

In my understanding [normal unit testing] would be when the program has been looked at and run through some preliminary test scenarios so that the programmer knows that this program is going to fulfill the function that it was written for, and that it will initiate and not end, and do the correct database points.

57 It is not an in-depth program that is going to test all the functionality, but it is basically a check on the critical nature of the program so that it is close enough so that it can be sent for rigorous testing by the testers.

That was our instruction, [that the unit testing was not going to be done], not at the time to effectively unit test the programs, and like I stated earlier, we were told to just get the programs compiled cleanly out of the back end of the translator, and to make sure that they could be started without ending, and then give those over to the testing team for quality testing.

You take the old program, and you run that through a test, where you look at the screen from the database calls, and you see what behavior it exhibits, and you test that versus what the new program does, and you compare the results, and you expect it to behave the same way.

It is also involved with something called system testing, which is the integration of individual programs, and that is a later phase, that all the programs interact with each other correctly so that the whole application works properly.

[Unit testing] is on a program by program basis .... [Quality testing is a] more functional test. ... [Integration testing] is where you take large units of programs and you verify that they will all play well together.

I don't know for sure [why unit testing was skipped], but it appeared that the schedule was in jeopardy, and that this was a way to get us back on schedule with the work plan that would say that we had so many programs done by X-amount of time ....

58 ... AEON was under contract to convert the MOCAS system. There is a work schedule put out, and by we, I meant the programming staff was instructed to convert so many programs per week to get this done to meet the schedule.

And we were behind schedule, and my understanding is that this was an attempt to get them back on schedule, but in doing so, you are going to lose the quality of the programs, and it is going to take more testing time in the QA area.

So you might meet the numbers, in terms of getting the correct number of programs compiled, and over to the test team, but it lessens the likelihood that the programs will pass testing .

... [I]t needs to pass both the functional and the integration testing. So I was suggesting that because this was rushed, what that basically did is that it made more pressure on the test team, and in my estimation, more risk to the whole project .

...What we were asked to do was sidestepping the normal process.

It was a hurried up approach, and I felt that it had great risk, and that is why I was so outspoken about it.

(Tr. 4/845-50, 853, 855-56; see also R4, tab 38 at 1268-71; finding 46) COR Hecker testified:

I believe at some point, and it might have been trying to save some time in testing, [AEON] abandoned the formal sense of unit testing, and after the code was converted, instead of having unit testing, I think they sent it straight to their quality assurance group for testing.

59 .. .I think early on that their test plan called for unit testing, and I believe they followed it. They did the unit testing, but later on either they felt it wasn't necessary through their experience, or they decided that they didn't need it.

... Unit testing is normally done by a programmer, and ... at some point, they decided to not have the programmer do the unit testing, and send the program straight over to the [quality assurance] test team to test.

They did more of what I would call an integrated test or almost a system test. More of a functional test.... They were testing a group of programs at that point, like a contract input function, or an input of a DD-250, and the inputting process of a DD-250, a shipping and acceptance document.

It is at a higher level than a unit test in the program. They are testing an integrated product at that point.

(Tr. 4/662-64) CM/SEI's Foreman, the only witness offered by AEON at the hearing, (findings 94, 110, 122), testified that a common factor to "troubled programs" is a decision by the developer to "make up ... time" by failing to perform unit testing (tr. 7/1202).

Because if you skip unit testing, what you end up doing is that you are going to be doing integration testing at the next level. Well, if I don't know that the small pieces work, how am I going to have any traceability or tracking to where the errors may be if I am testing at a larger component level ... ?

So now I have jammed together a bunch of modules and units, and I am testing against those, and I am getting errors and crazy things going on, et cetera, et cetera, that may actually affect other parts of the system.

Where ... do I figure out where in that composite do I have the problem[?]

(Tr. 7/1248-49)

60 58. On 23 June 2005, Krajnak included the following in his weekly status report internal to AEON:

Issues/Problems/Concerns (include suggested resolution -- if known)

* Dysfunctional management team. Employees have lost faith that the project will be completed on time and are starting to look for other employment. The resolution is install a new onsite manager that the client and employees trust. ... * Lack of communication among team members. Have weekly staff meetings were [sic] issues are discussed. * The PSR should stop presenting falsehoods and show the project as at risk (yellow). We will not be able to deliver working programs and documentation by 12/31/05. Resolution is to delay UAT for 3 months.

(Supp. R4, tab 57; tr. 4/850-52, 874-76)

59. On 15 July 2005 Krajnak sent an email to the AEON test team supervisor:

I am seeing many defects for the online QA testing that have to do with programs not properly transferring to each other. Many of these should be caught and fixed before being sent up for QA testing. This is caused by the lack of integration testing between the programs created by different programmers. Each programmer tests only his program and does not test the flow to all the other programs in the group.

This is a waste of the QA testers time and prevents any real logic testing (since the program abends [see n.29] before doing anything productive). It is simple to solve if we would be allowed to do integration testing.

I suggest that someone (maybe the team leader) do integration testing between all the programs in a group before sending the programs to QA for testing. How do we get Shirin to allow this?

(Supp. R4, tab 59) At the hearing he testified that:

61 The purpose of this document was basically to report what I saw in terms of the on-line programs for failing and going over to the QA side. As I indicated here, I thought that many of these things should have been caught prior to sending these programs over to be tested.

And what we are basically seeing is what I am calling or what I stated as chum, is that we would prematurely send programs over to the testing team. They would send them through their automated scripts. They would fail.

They would then come back to the programming staff with defects, and then the programming team would then have to fix those defects one at a time, and send them back over the fence to the testing team.

What I thought should have happened, and what my experience shows me, is that if you spend more time up front with making sure that you have quality code, and that you are doing a robust unit testing prior to giving it over to, to do the more functional tests, that these errors would not be occurring, and that you would get results better.

(Tr. 4/856-57; see also findings 46, 47)

60. On 24 February 2006 AEON reported being 100% complete with Level I testing of five modules. On 3 March 2006, in accordance with FAR 52.246-4, Inspection of Services, the government exercised its right to inspect and test the services required by the contract to be performed by AEON. On 10 March 2006 CO Gladski notified AEON that the government's inspection had "involved a simple testing of the commonly used functions in [one] module" and raised concerns about the adequacy of AEON's testing. CO Gladski listed 8 specific examples of "problems" identified during the government's inspection and:

As a result of our small sample, we are very concerned as to the adequacy of Aeon's Testing and Quality Assurance programs to detect these anomalies. Further, deepening the concern was the [government] testers were unable to perform even the most rudimentary business functions of entering an invoice, entering a disbursement, or editing a contract payment notice.

62 Based on the unsatisfactory Government findings during this review, Aeon is requested to provide access to, and submit for Government review all modules as they are identified as being 100% complete with Level 1 or Level 2 testing. The authority for this request is found in section nine of the Statement Of Work and FAR 52-246.4(c) [sic]. In addition, due to the concerns raised by this review as to the adequacy of Aeon's Testing and Quality assurance programs and the status of testing being reported, Aeon is hereby notified that acceptance of the services associated with achieving the events tied to milestone payment [6B] may be delayed while the Government performs inspection of the converted software modules as outlined by FAR 52-246.4 [sic] and section four of the SOW. Toward this end, the Government is willing to consider any changes you have made or alternatively, any changes you plan to make to your Testing and Quality Assurance programs to prevent reoccurrence of problems with the adequacy of testing in the future, so as to shorten the time it would take the Government to complete this task.

(R4, tab 20)

61. After reporting to the government that it was 100% complete with functional testing, AEON advised in a 17 March 2006 email that:

AEON has successfully performed thousands of tests on the rehosted MOCAS program code meaning that a lot of the system operates as expected... . We do not deny that the rehosted system is not yet fully tested and that there are many bugs to be discovered and fixed. This is business as usual in a systems project especially one of this nature when the underlying technologies are so vastly different from the legacy environment.

(Supp. R4, tab 74) The government responded:

Government testing at this stage is to independently verify what is being reported as having been completed by Aeon. We are not performing 100% structured testing of any items, we are performing ad-hoc testing of the logical units of work

63 Aeon reports as being 100% complete with functional testing. The Government does not want this testing to be a 'life-long proposition' and if Aeon knows that the functionality associated with these modules is not fully tested, than [sic] they should not be reported as being 100% complete.

(Supp. R4, tab 74) In particular, the government inspection testing:

[W]as just ad hoc testing and broad based just to get a feel. [The tester, John,l2 2l] wasn't testing any one particular function, one particular process. He was just trying to get a feel that ... these systems are out there, and the input screens are out there. The stuff is starting to work .

. . .He would just say that I am having problems, or often times he would say I am having lots of problems, and I would say just make sure that you are reporting them to AEON so they can fix them.

(Tr. 4/671-75, see also tr. 5/934-35, 941-47)

62. In the spring of2006 DFAS requested a DCAA audit to determine AEON's financial well-being after it was reported that AEON had missed a payroll and had not paid its subcontractors (see finding 51 ). The resulting audit found no evidence that AEON was financially unable to complete the MOCAS Rehost project. (Supp. R4, tab 106 at 21)

63. Mod. No. P00007 dated 5 May 2006 further subdivided Payment Event 6B, determined to be "highly complex and lengthy in terms of time to complete," into 6B-l, 6B-2 and 6B-3 to permit faster payments to AEON during the performance of tasks associated with Payment Event 6B (R4, tab 3 at 861-76). In the process of approving the subdivision of Payment Event 6B the PMO commented that the subdivision was requested due to "possible government caused delays" resulting in delayed payments and financial difficulty for AEON (id. at 869). The modification made reference to ongoing negotiations of an REA (finding 64) and included "[b]y signing this modification, the Contractor does not waive any claims that arose after 08 January 2006" (id. at 861 ).

22 John Sharer was a DFAS functional systems analyst with 29 years experience with the MOCAS system (tr. 5/937-39).

64 64. On 14 April 2006 AEON submitted a Request for Equitable Adjustment and Schedule Extension Proposal (REA). Thereafter AEON submitted several revisions to the REA which were audited by DCAA (R4, tab 22; supp. R4, tab 106 at 13-14). On 23 May 2006 AEON submitted a final revised REA seeking compensation in time (9 weeks) and dollars ($978,3 86) for various alleged government-caused delays to the critical path of its performance under the contract in the period from 9 January 2006 through 17 March 2006 and to provide additional time in the QA/Test Phase schedule. 23 The cost reimbursement sought was for:

• Added calendar work time to make up for the AEON team's lost productivity associated with work on the project's critical path tasks. The lost productivity is directly attributable to the ( 1) instability of the mainframe development and testing environments (including loss of environment due to erroneous lay down of data), (2) downtime related to the upgrading of PC workstations under the Desktop Management Initiative (DMI), and (3) unavailability of the TestDirector software, the AEON testing tool, during the above timeframe, and

• Additional time needed to address the increasing level of program code complexity.

(R4, tab 21at1063, see also R4, tab 21at1082) The requested costs of$978,386 were broken down as $620,093 for "Environmental Instability," $291,808 for "Increased Code Complexity" and $66,485 for "Other Costs" (R4, tab 21 at 1064). The requested nine-week schedule extension of the QA/Test Phase was:

• To accomplish the work that was delayed due to the impact of the mainframe availability/usability, DMI upgrade problems, unavailability of test management system (TestDirector), and changes in the support levels due to revised security policies and procedures, and

23 The DCAA audit notes that there was another subsequent REA submission dated 12 June 2006 that sought the increased amount of $992,378 (R4, tab 22 at 1103), but it is not in the record before us.

65 • For expanded QA/Test and defect management activities due to higher than planned complexity of the MOCAS System program code.

• To complete the technical documentation work that is dependent on the completion of the QA/Test Phase activities.

(R4, tab 21at1063, see also R4, tab 21at1067-79, 1083-97) The parties reached a negotiated agreement on 8 August 2006 (R4, tab 24; tr. 1/93) which was memorialized in Mod. No. P00012 (finding 67).

65. Mod. No. P00009, dated 12 June 2006, further amended the subdivision of Payment Event 6B from three subdivisions to four subdivisions (6B-l through 6B-4) (R4, tab 3 at 880-92). The record shows that AEON was paid for Payment Event 6A on 9 January 2006, Payment Event 6Bl on 28 April 2006, Payment Event 6B2 on 15 June 2006 and Payment Event 6B3 on 8 September 2006 (app. supp. R4, tab 172 at 8).

66. Mod. No. POOO 10, dated 20 June 2006, extended the contract completion date to allow time for an audit and negotiation of AEON's REA (finding 64) (R4, tab 3 at 892-96, tab 78). On 5 July 2006 Mod. No. POOOl l (R4, tab 3 at 897-01) obligated funds in the amount of $300,000.00:

[A]s partial equitable adjustment under FAR 52.242-17 for what the Government considers to be a 3 .5-week Government delay of work involving certain "Environmental Instabilities" as asserted in [AEON's REA], as revised May 23, 2006. This [amount] is granted solely with respect to elements of "Environmental Instabilities" delay assertions in the revised REA for the period of January 9 through March 17, 2006. This partial equitable adjustment represents a good faith action on the part of [DF AS] that provides cash flow to [AEON] to meet immediate expenses. The Government does not concede that entitlement to adjustment exists for the "Complexity Factor" elements of the REA, or for all of the "Environmental Instabilities" sub-elements set forth in the REA. Final equitable adjustment cannot be made until the Principal [CO] receives the requested DCAA audit report of the REA proposal. Fact finding and negotiation of the REA proposal between the Government and [AEON] will occur after receipt of the DCAA audit report.

66 (R4, tab 3 at 899; see also supp. R4, tab 106 at 13-14, 18)

67. Mod. No. P00012, dated 18 August 2006, reflected the parties' negotiated settlement of AEON's 14 April 2006 REA (finding 64). Specifically:

4. An $825,000.00 negotiated settlement of the REA was reached on August 08, 2006. That settlement, implemented herein, adjusts compensation and schedule for Government-caused delays and Environmental Instabilities and disruptions from January 9, 2006 to March 17, 2006. That settlement includes additional monetary compensation that the Government will provide in consideration of AEON's release of the Government from further equitable adjustments and claims under the contract based on the "complexity" of the as-is MOCAS code, with the exception that AEON has not released the Government from rights to equitable adjustment or additional compensation involving changes and/or additions to the as-is MOCAS code which occur or may have occurred after March 17, 2006, that increase code complexity.

5. In considering the REA, the Government found that AEON's REA and subsequent REA negotiations did not establish entitlement for the MOCAS code complexity contentions set forth in the REA. However, the Government offered to provide, and AEON accepted, additional monetary compensation in exchange for the limited release described above.

6. This negotiated settlement includes other costs including travel, software, and Facility cost of capital from January 9, 2006 to March 17, 2006.

7. This negotiated settlement includes adjustment of the delivery of the following CLIN dates to September 10, 2006: a. CLIN 0001 AA b. CLIN 0004

8. In good faith, DFAS, agreed to make a partial payment on this REA to help alleviate AEON's financial issues.

67 DFAS obligated $300,000.00 in POOOl 1 [finding 66] toward a partial equitable adjustment of this REA. Thus, DFAS has already paid $300,000 of the $825,000 leaving a balance of $525,000.00 to be paid. This contract action obligates the remaining $525,000.00 for a total settlement obligation of $825,000.00.

(R4, tab 3 at 903-05) The breakdown of the negotiated amount was recorded as:

Cate2orv Proposed Cost Ne2otiated Cost Environmental Instabilities $620,093 $604,590 Code Complexity $291,808 $187,589 Other Direct Costs Travel $16,595 $17,358 Software Licenses $31,729 $10,768 Cost of Money $31,390 $4,695

Total Cost $99 l ,6 l 5L24 l $825,000

(R4, tab 24 at 1151) The modification included the following release language:

CONTRACTOR"S [sic] STATEMENT OF RELEASE: In consideration for the modifications agreed to herein as complete equitable adjustment for AEON's REA, submitted on April 14, 2006, revised on May 23, 2006 and updated on June 12, 2006, and in consideration for additional compensation for that qualified code complexity release from AEON's provided for under paragraph 4 above, AEON hereby releases the Government from any and all liability under this contract for further equitable adjustment:

a. Attributable to such facts and circumstances giving rise to the REA; and

b. Any and all claims or equitable adjustments under the contract based on the "complexity" of the as-is MOCAS code, with the exception that AEON has not released the Government from rights to equitable adjustment or additional compensation for any changes

24 The document does not explain the $763 difference between this proposed amount and the proposed amount of $992,3 78 stated earlier in the same document (see R4, tab 24 at 43).

68 and/or additions to the as-is MOCAS code that increase its complexity which occur or may have occurred after March 17, 2006.

(R4, tab 3 at 904; see also R4, tab 24; tr. 2/259-64)

68. In mid-August 2006, AEON started Interface Testing:

Interface Testing validates that data is passed correctly between two systems and can be processed accurately. As a term of the contract, it was acknowledged by the Government that the contractor would require Government assistance in performing these tests. Although an AEon responsibility, the PMO coordinated testing with AEon and the support organizations for other DFAS systems. Because of the Government involvement, this testing stage provided the Government the first chance to see how AEon was progressing in obtaining I 00% functionality of the As-Is system.

Interface Testing started in mid-August of 2006, at that time, less than a month before GT &E was scheduled to begin. Scheduled to last only four days, AEon was not able to run/complete a batch cycle for ten days, compared to an eight hour window used for production [in the as-is system]. A batch cycle was critical for creating the data files to be passed to the interfacing systems. AEon's delay was due to numerous program problems and JCL errors, which should not have occurred if the system was fully functioning. The length of time required and the number of problems encountered was an indication to the Government that AEon had not previously run a complete cycle, a critical test for Integration Testing. This indication raised significant concern by the Government, due to the point of time within the project. With less than a month before the scheduled GT &E, the Government anticipated that AEon would have had a more mature system and, at a minimum, would have been able to run a [batch] cycle. However, showing good faith, the Government permitted AEon to complete their testing and reserved judgment until after GT&E commenced.

69 Unfortunately, it was not until GT &E commenced that it was realized that AEon had bypassed several jobs that had abnormally terminated, rather than fixing the problems and successfully run the jobs. Instead, the Government entered into GT&E assuming cycles were capable of running to completion without manual intervention. Once GT &E began and the TS0[ 25 l took responsibility for running the cycles, the extent of the problems with the batch cycle was discovered.

(Supp. R4, tab 106 at 19-20)

69. Mod. No. P00013 dated 11 September 2006 extended the delivery date for subCLIN 000 lAA to 25 September 2006 in exchange for consideration from AEON (R4, tab 3 at 908-11; supp. R4, tab 106 at 19).

70. Mod. No. P00014 further subdivided the CLIN 0001 tasks to be completed by AEON to successfully qualify for each payment event after 20 October 2006 (R4, tab 3 at 912-25; tr. 3/394-96). The modification revised the "Event Based Payment Schedule for Payment Events 6B4 and 7A" which were described as "highly complex and lengthy in terms of time to complete" (id. at 914-15). Event 6B4 and Event 7A were removed and replaced with Events 7A-l, 7A-2 and 7A-3 (R4, tab 3 at 921-23). The change "aligns progress of contract deliverable performance and related payment event dates with actual work progress thereby assuring the Government of Contractor's continued viability" (R4, tab 3 at 915).

71. On 22 September 2006, just days before the amended contractual delivery date of25 September 2006 for subCLIN OOOlAA (finding 69), AEON submitted its "Final" Project Management Plan (PMP) (finding 11; R4, tab 25) The PMP stated:

1.4 System Functionality and Scope The rehosted MOCAS System will have all of the functionality, produce the same output and will look, feel and respond to the users exactly as it does today. Therefore the users will not recognize that the system has been touched. In addition, all interfaces will provide the same data in the same format. No obsolete programs or dead code will be removed without the express written permission of the [COR] ....

The scope of the effort also includes the development of all technical, project and user documentation as defined in

25 Technical Services Office (finding 79).

70 Section C, Descriptions and Specifications, item 14, Documentation. The repair services of the rehosted MOCAS System are an optional scope item beginning with installation of the rehosted MOCAS System on the production platform and continuing for one year thereafter. DFAS intends to make a decision on this optional scope item at a later date.

(R4, tab 25 at 1159)

72. In a 22 September 2006 letter CO Gladski expressed concern about AEON's performance of the contract and requested "reasonable assurances" that AEON would be able to complete the contract. In particular, CO Gladski expressed concern about "the quality and completeness of your QA test and automated test scripts." (R4, tab 26; tr. 1/93-94) AEON responded in a letter dated 26 September 2006:

We are at the end of the project. The QA/test is 99% complete. With very few exceptions - all other tasks are complete. Therefore, we were very confused and disappointed by your letter. We have consistently taken every step to assure DF AS that AEON is fully capable of and committed to completing the MOCAS Rehost project.

While this project continues to be more complex than originally expected, we feel confident that we will complete the project with the highest quality possible for a project with its unique attributes.

1. Schedule Issue - Start of GT &E schedule changed from 9/25/06 to 10/2/06

[AEON explained that the requested one-week extension to the delivery date for subCLIN 0001 AA was due to DFAS/DCMA's recent provision of long-requested information on 8/31/06, 916106, 9112106]

2. Technical Performance Issues

We are not aware of any technical performance issues. To

71 the best of our knowledge the technical performance of the project has been successfully presented and accepted. The performance under the Rehost is substantially faster than under the current technical environment. If there are other specific concerns, please let us know and we will respond accordingly.

3. Quality and completeness of QA tests and automated scripts as evidenced by inspection results

AEON is totally committed to producing the highest quality MOCAS Rehost product. As you know, MOCAS was a very difficult and complex system to convert due to its age (evolved over more than 40 years), lack of standards and consistency, use of multiple coding techniques for coding the same functions in the same program and lack of documentation to provide explanations. For such a system:

- It is highly unrealistic to expect that a subject matter expert or a knowledgeable system user perform tests on a major system prior to or during the user testing (GT &E) and finds no defects. The purpose of the user acceptance testing is to test the system from a user perspective and correct any defects prior to moving the system into production. The amount of defects discovered during the user acceptance testing is directly proportional to the level of customer involvement throughout the project. The systems with more customer participation will yield less defects during the user acceptance testing than those with little or no customer participation.

The consequence of DFAS and DCMA not actively participating in the project for a system that has no documentation and has gone through 40 years of changes of content as well as ownership is the possibility of discovering more defects during the GT &E. We explicitly identified this fact as a risk for this project in our proposal. Risk# 10 in our Risk

72 Management section highlighted "The stated lack of government involvement throughout the project life cycle" as a "High" probability risk with "High" impacts on "Cost, Schedule and Performance". While we implemented the proposed mitigation plan of management and peer review and hired several team members with MOCAS experience, these actions, as stated in the risk management plan, did not fully eliminate the risk and its impact. Further, we have worked diligently and have asked to receive and execute user test scripts in order to minimize this impact.

A subject matter expert can test a complex system, even an operational system, and can identify defects. This is evidenced by the fact that we were able to identify 19 defects in the current MOCAS system which has been in production for over 40 years. Therefore, the quality of AEON's performance can not be based solely on the lack of defects during Government inspection.

The quality indicator should be based on the severity of the defect as well as how quickly the defect can be corrected during the inspection and GT &E. The defects that were discovered by the TSO team during the inspection process were not numerous and were fixed and resolved immediately. The larger number of defects discovered by the TSO was associated with early testing support that we had requested from TSO and not during inspection testing.

In conclusion, AEON is fully capable and committed to complete the MOCAS Rehost project with high quality. When we started the project our conversion team was not familiar and experienced in the MOCAS code.

Through diligence and hard work the team is now very knowledgeable and experienced and can resolve any problem quickly. We also believe that our team has become even more

73 knowledgeable in the Rehost system than most TSO members.

(R4, tab 27)

73. On 27 September 2006 and 2-13 October 2006, the government performed inspection (see finding 16) in the form of some testing of various areas of the MOCAS rehosted system (R4, tab 38 at 1270-71; tr. 3/432-33, 573).

74. As of 5 October 2006 AEON and the government had agreed to start GT&E on 13 October 2006. However, by email dated 11 October 2006, COR Hecker proposed to delay the start of GT&E until 30 October 2006 due to difficulty in assembling the government test team and also proposed for AEON's consideration further changes in the payment milestones. By reply email the same day, AEON responded:

The proposed GT&E schedule is unacceptable to AEON for the following reasons:

1. The Government has been conducting inspection testing which is very similar to GT &E rather than a high level inspection. We believe there has been sufficient testing and retesting done to assess the start of GT&E. Three DCMA testers and two resources from DF AS have been involved in inspection testing and validation.

2. Per our conversation of Thursday, 10/5/06, we agreed on a plan to start GT&E preparation on Wednesday, 10/11/06 with a GT&E start date of 10/13/06. The following steps were agreed upon:

o AEON would fix all defects by 10/9/06 o Client would input their data on Tuesday, 10/10/06 o AEON would run a cycle with client input on Tuesday night, 10/10106 o Client would verify the results, 10/ 11 /06 o If there were no show stoppers found, GT&E prep would start on Wednesday, 10/11/06

74 3. We were told in the TIPT[261 meeting today that the client did not find any show stoppers that would preclude us from going to GT&E and in fact a key client was very excited about the results of the testing. During today's IPR John Sharer also stated that there were no show stoppers for the start of GT&E.

4. All identified defects with the exception of a few lower priority defects have been fixed. We have demonstrated that we can very quickly resolve any problems encountered.

5. It is commonly understood that defects will be identified during GT &E due [to] the depth of operational knowledge of the client testers. Therefore extending inspection to continue the testing process will not eliminate GT &E test defects.

6. We believe that AEON has met its obligation and has supported the inspection process required prior to the start of GT&E (start date of 10/13/06). Since this is a fixed price contract any further testing prior to GT &Eis an unnecessary hardship on AEON that we cannot accept. If the client wishes to pay for the extension of the start of GT &E to October 30th we would be more than happy to discuss it.

Carl [Hecker]: We are totally committed to this project as evidenced by all personal and business risks that we have gladly accepted in order to have a successful project. However, any delays in the start of GT&E and major changes to our payment schedule are unacceptable to AEON because they would have severe impacts to the company.

(App. supp. R4, tab 151)

75. On 12 October 2006 AEON submitted a second REA ("REA2") in which it sought compensation in the amount of $629,550 for government-caused delays to its performance of contract work from 18 March 2006 through 2 October 2006 (app. supp. R4, tab 152 at 1, 4-5). After multiple revisions, the 15 February 2007 version ofREA2

26 Test Integrated Product Team (gov't br. at 36).

75 sought $548,866 (app. supp. R4, tab 189 at 6-7). The record shows that AEON was paid for Payment Event 7A1 on 20 October 2006 (app. supp. R4, tab 172 at 8).

76. On 20 October 2006 an internal AEON email announced: "Team: All the reports are in balance. All the client defects have been fixed. We are going forward with GT&E!!" (App. supp. R4, tab 155 at 2)

b. GT&E

77. On 23 October 2006 AEON delivered the Rehosted MOCAS database for GT&E (R4, tabs 30, 34, 38), having certified in its 20 October 2006 MOCAS Rehost System Quality Report that to the best of its knowledge the MOCAS system was ready to perform the functions of the As-Is MOCAS (supp. R4, tab 106 at 19, 22, 27). The government approved AEON's report of delivery for GT &E and on 1 December 2006 released to AEON performance-based payments for Payment Event 7A2 (app. supp. R4, tab 172 at 8).

78. GT&E commenced on 24 October 2006. It was the government's expectation that the product delivered for testing should be "99.9 percent capable of performing the function of the as-is MOCAS, and look like the as-is MOCAS, and do everything that the as-is MOCAS was doing" with only a small amount of test failures that would require "minor tweaks" (tr. 1/87, 98, 102-03, 109).

I would say that we expected the system to be delivered with minor cosmetic changes that were needed to be made, whether the screens were not operating properly, or the wording was incorrect.

We did not look for what I would call critical errors or we would not expect critical errors or defects when they delivered the system to us ....

(Tr. 3/418; see also tr. 3/607, 4/804)

79. Specifically, the DFAS Government Test and Evaluation Plan identified the following details of the DF AS' GT &E effort:

SECTION 1 - GENERAL

I. I Test Objective

76 The Defense Finance and Accounting Service (DF AS) Commercial Pay Business Line (CPBL), Chief Information Office (CIO), Central Design Agency-Technical Services Office (TSO), Defense Contract Management Agency (DCMA) Central Design Agency/Technical Information Center (DTIC), Defense Information Systems Agency (DISA) OGDEN and the Contractor (AEON LLC) will jointly coordinate and support a Government Test and Evaluation (GT&E) of the Mechanization of Contract Administration Services (MOCAS) Re-host (DB2 environment) System. Parallel testing will consist of testing all online and batch processes as well as the interfaces functionality developed within the Mechanization of Contract Administration Systems (MOCAS) Re-host (DB2) system environment (MUJ) and MOCAS (SUPRA) production system environment (MUB). Testing will be conducted during the period of 11 Sept06 through 30Nov06.

1.2 Purpose of the Test

This document identifies and defines the requirements that will be tested in parallel systems during the GT&E. And will determine ifthe MOCAS Rehost (DB2) System (MUJ) provides the same level of interface capabilities, functionality and processes that exist in the current production MOCAS (SUPRA) system (MUB). To include validating AEON provided user's manual. Numerous online, batch and interface transactions will be processed through each Logical Partitioning (LPAR). And through comparative analysis performed by the test cadre, a validation of each screen and data field and data field requirement will be performed to ensure the online, batch and interface transactions are mirrored, with results documented to reflect demonstrated functionality or lack thereof. Specifically, this Government Test & Evaluation Plan:

• Confirm MOCAS Rehost (MUJ) system consists of the same screen layouts, interface(s), online input, online input validation and batch functionality as the current MOCAS (MUB) production environment. • Confirm Entitlement Automation System (EAS) interface functionality

77 • Confirm Contract Reconciliation System/Standard Contract Reconciliation Tool (CRS) interface functionality • Confirm Electronic Document Management (EDM) system interface functionality • Confirm Payment Prevalidation Module (PPVM) system interface functionality • Confirm [SDW] system interface functionality • Confirm Wide Area Workflow - Receipt & Acceptance (WA WF-RA) system interface functionality

1.2.1 Assumptions

The MOCAS Rehost DB2 (MUJ) will provide the same screen layouts, interface capabilities, online input, batch functionality and processes that exist in the current production MOCAS (SUPRA) system. And will perform validations consistent with the current MOCAS production environment which supports online and batch processes.

The outbound file transmissions to include all system-generated reports will provide the same format and data from the MOCAS Rehost DB2 (MUJ) system as in the current production MOCAS SUPRA (MUB) system. All DF AS reports will be viewed utilizing the Online Report Viewer (OLRV).

4.3 Test Evaluation

a. All test conditions must process 100°/o as predicted for the GT &E to be accepted and certified. Any test conditions not processing as predicted must be identified and successful resolution agreed to jointly by the contractor and test cadre (if applicable). Test conditions results for which agreement is in dispute will be forwarded to the technical representatives for analysis and resolution. Each MOCAS Rehost

78 region will be tested independently and for its interdependencies.

4.3.1 Test Conclusion

a. The test will conclude when 100°/o of all valid test conditions are adequately tested and found acceptable and outstanding problems are verified as fixed and retested. This will result in a recommendation for either a certification/non-certification.

b. Parallel testing of a single MOCAS region vs. all three (3) will result in a recommendation for certification that must stipulate the following caveat: Certification of the MOCAS Rehost DB2 environment resident on the (MUJ) LPAR was accomplished utilizing only one parallel MOCAS region for comparison, thus ensures operability of each region and not their interoperability.

c. Based on successful completion of test conditions/scenarios and outstanding problems, MOCAS Rehost, [PMO] will coordinate with the Designated Approving Authority (DAA), Information Assurance Officer (IAO) and DF AS Chief Information Officer (CIO) to discuss whether or not any outstanding problem(s) discovered during testing will have an adverse affect/impact ('showstopper') on DFAS and/or DCMA business processes.

(Supp. R4, tab 61 at A009710, A009721) (Emphasis added) The DCMA Government Test and Evaluation Plan was essentially identical and was developed by DCMA test lead Turner (supp. R4, tab 67; tr. 4/795-00, 802-04). With respect to Problem Identification/Resolution, the DF AS and DCMA Test and Evaluation Plans specified the following categories of problems:

79 Category DFAS (4.2.2) DCMA (4.2.3.1)

A Critical/Fix Immediately Must be corrected before test can proceed.

B Major/Fix before Test Completion Must be corrected before end oftest.

c Fix before Deployment Must be corrected before deployment.

D New Requirement(s)/Requires an New Requirement( s)/Requires an Automated Work Request (A WR) Automated Work Request (AWR) /Contract Assessment Form (CAF) Because it significantly changes -Because it significantly changes the management requirement. the management requirement

E Real World Production problems Real World Production problems

F User Defined User Defined

G No Impact to MOCAS/Rehost [not used]

H Reserved [not used]

(Supp. R4, tab 61 at A009720, tab 67 at A009693; tr. 3/536-37, 553-56, 5/954, 1025) With respect to Category E, Real World Production problems:

[The government] recognized that there are some problems in the [As-Is] MOCAS system today [and] the system is still able to function, but they are there, and they are cosmetic.

So if they are there in the system now, they would still be in the system when we converted it.

(Tr. 3/450, see also tr. 5/954-55; finding 72 [19 defects found in As-Is MOCAS])

80. GT&E was performed by 33 government testers, all with decades of experience with the existing As-Is MOCAS (tr. 3/582-84, 604-05, 4/752-54, 828-29, 5/937, 956-63, 982-84, 5/1017-102, 1021, 1038; supp. R4, tab 61 at A009722 (lists 44 names for DFAS), tab 67 at A009695-96 (lists 15 names for DCMA)).

80 We had people from each of the different areas. We had DB2 people there and they were represented, and we had people there that put in invoices every day, and they were represented, and they had people from contract input there, and they were represented, and entitlement, Tier 2. There were individuals from each area that were involved.

From each area, there was probably two to three people, and you have to realize that the data was phased, and so each day you would bring in different people. They wouldn't all be there at one time.

(Tr. 3/435-36)

81. In the first several weeks of GT &E the government testers encountered numerous failures of critical, basic and necessary functions of the Rehosted MOCAS to perform like the As-Is MOCAS (tr. 1/87, 3/584-08, 5/899-00; supp. R4, tabs 95, 123). DF AS test lead Thompson testified that:

In October of 2006 we started, and it was a very trying time, I had our testers in the lab and we were ready to go, but the product itself for a simple task as far as the users logging in and going to a library which holds how you process data, they would get [database] errors. [271 They would try to do simple tasks such as input an invoice and update the database and they would get errors, and it got to a point where it got quite frustrating because simple tasks that have to be done daily were unable to be completed. So I believe we were in it for maybe two to three weeks before we stopped the initial GT&E.

Just to name a few very critical [functions], unable to input invoices and update MOCAS, we would receive [database] errors. Whenever a shipment would come in a

27 Ms. Thompson used the phrase "Oracle errors" in her direct testimony, which she changed on cross-examination to "database errors" as the more correct terminology (tr. 5/1058-59).

81 DD-250 would have to be input into MOCAS, and there were major problems with, it's called a basic PF3 summary edit [in] the system, and for whatever reason it would say that it already existed and it wouldn't allow the person to add that particular document or any document, and this posed a lot of problems. And also with our electronic feeds the majority of our invoices come in electronically, and whenever these would come in they would not update MOCAS correctly, so the general ledger would show that our obligation receipts were never correct, and that is critical in our world.

(Tr. 5/1023-24) Thompson further testified that, in her 10 years of testing software, she had never encountered a product so not ready for testing (tr. 511031-32). Kathleen Schreiber, a DCMA tester with 29Yi years experience with MOCAS and whose regular job involved testing software for DCMA, testified:

Q ... [D]id the rehosted MOCAS system have the same 100 percent functionality as the as-is MOCAS system?

A ... No. We couldn't get the contracts in, and we couldn't move them through their lifecycle, and we couldn't process transactions against them.

We couldn't close them and we couldn't reopen them, and we couldn't get those transactions to our [S]hared [D]ata [W]arehouse successfully, repeatedly, consistently.

Q In your opinion was the rehosted MOCAS system ready for testing, Government test and evaluation?

A In my opinion, no.

Q Why?

A Well, I do test software all the time. . . . When you go to test an application, you don't expect it to be error free. You expect to find things. That's your job.

But you don't expect to find anything major where you can't do your normal basic functionality. You don't expect to find just about everywhere you tum that something doesn't work.

82 Q ... What type of problems did you basically think you would encounter when you started testing?

A Well, like some cosmetic stuff. Maybe some weird error messages on the screen, but I certainly expected that it would have been tested and proven that you could get contracts in, and MODS in, and shipments in, and things like that, and cycles run.

Q How important was it to run your monthly and nightly batch cycles?

A Oh, it was extremely important because the only way we get in electronic documents like contract MODS, shipments, and invoices, is through a batch cycle ....

(Tr. 3/606-07) The DCMA testers summarized the initial GT&E period as:

[U]nsuccessful attempts to complete a monthly cycle along with continued system problems such as inability to Summary Edit contract/modification input, numerous SQL system errors, erroneous rejection of the EDI 850's and 860's transactions, problems with automatic CAR section movement, DD Form 250 processing and SDW not being 100% completed ....

(Supp. R4, tab 113)

[It] happened quite frequently, that we would get a problem back and fixed by AEON, and then we would retest it.

And then you would go on to do your next piece on that particular document that you were working on, and ... , hey, this is broken. This was just working days ago. So it was kind of like unstable, and so you could not rely on it consistently to act the same.

(Tr. 3/597, accord tr. 5/1025-26)

83 The Government personnel went in and started testing. We started writing up about problems, and we provided screen prints, and we gave them to AEON. The first cycle took a lot [of] time for them to run. They had problems with the cycles and programs.

We got through the second cycle, and then I think it was the third cycle where they came to us and said that they were stuck on a program, and they couldn't get it fixed until maybe 4 or 5 days before they could get it fixed.

And at that time that's when the testers were getting upset, and that's when I met with [CO Gladski] at the time, and said that it looks like we are having problems, and a lot of defects in their stuff.

That's when we met, and the final recommendation really, and we met as a group and came to the consensus that we thought it was best to stop GT&E because we couldn't seem to get past the work stoppage, and the program, and continuing to fix things. We couldn't run cycles and we couldn't do any [testing] work.

Well, the program that they had, they had a whole lot of difficulty fixing it, and if I am not mistaken, it was the cash management program that they were stuck with.

And they were having trouble getting it to work, to run in a cycle, and so until they repaired that program, we were unable to continue on because we were just at a work stoppage.

So that was a critical program ....

(Tr. 3/437-38)

84 It was our recommendation based on the number of defects received, and the difficulty that they had with repairing the critical programs that they had to go back and do more testing, more unit testing, or whatever they needed to do to deliver so that it didn't have as many defects as when they first delivered it.

I think it was something like 200. I am not sure of the exact number, but there were quite a few defects .

... [W]e were having trouble getting through the different cycles, and the input that was being entered, we couldn't get through most of the screens.

There were several issues, and that was not a fully functional system. We needed a system that would work at that point, and it was broke at that point, and we could not completely enter contracts.

(Tr. 3/439-40)

82. On 2 November 2006 the government suspended GT&E (supp. R4, tab 106 at 28). From the time of the suspension until 18 December 2006, DFAS testers went back to their regular jobs and DCMA testers maintained contact with AEON to clarify or explain 200 trouble reports submitted prior to the suspension (supp. R4, tabs 113, 123; tr. 3/457, tr. 4/750, 759, 791-92, 813-16, 5/948-49, 1022-23, 1033).

83. At a meeting on 8 November 2006 (R4, tab 28), it became apparent that the parties were in basic disagreement as to the level of functionality required to be present in the Rehosted MOCAS delivered for GT &E. It was AEON's position that the 90-day GT &E period was user acceptance testing in order "to resolve defects" (tr. 3/532). The government insisted that the contract required that the Rehosted MOCAS have 100% functionality when it was delivered for GT &E.

Under CLIN-1 that represented the whole MOCAS program, the rehost. When everything worked correctly, then that CLIN-1 would have been delivered. We had no partial delivery of anything under CLIN-1, and our expectation[] was 100 percent functionality when the system was operating.

85 (Tr. 1/113)

It may have defects, but a defect should not impact the functionality of the system, and in this case the defects did impact the functionality of the system .... But we weren't talking about bugs. We were talking about major defects that did not allow the functionality of the system to be proven out. ...

(Tr. 2/317-18) We expected AEON to deliver a fully functional system, and that is totally different than a defect free system.

To deliver a system where we can input invoices, input shipments, and that means being able to get from - if it takes you five screens, and you have to go from A, B, C, D, and E to completely put in the shipment, we expect to get through all of that.

We don't expect that minor defects with the system, whether like if wording on the screen wordings were incorrect, or anything, we still expected it to be fully functional. Those are the types of defects that we expected to see.

(Tr. 3/441-42)

84. On 15 November 2006 the government formally rejected the Rehosted MOCAS delivered by AEON and suspended GT&E:

The memorandum, however, gave AEon the opportunity to deliver a product that performed basic system functionalities, to include Summary Edit, complete daily/monthly cycles, accurate Automatic Payment of Invoices (API) process, Invoice History updates, full Contingent Liability Record (CLR), accurate financial/invoice updates, etc.

(Supp. R4, tab 106 at 28; tr. 1/104-06, 2/312-14, 3/539; see also R4, tabs 28, 30-31, 38-40, 49)

86 85. In a 29 November 2006 letter, counsel for AEON notified DFAS CO Gomolak28 that AEON considered the government's position to be contrary to contract requirements, arguing that the purpose of GT &E was identification and correction of defects which, he argued, anticipated that the Rehosted MOCAS was not expected to have 100% of the functionality of the As-Is MOCAS at the time it was delivered. Counsel further asserted that the government had no right to suspend GT &E and that the suspension of GT &E was an "attempt[] to revoke its prior acceptance of the MOCAS system." (R4, tab 29)

86. On 28 December 2006, CO Gomolak took issue with AEON counsel's letter in two separate letters to AEON. In the first letter, with the referenced subject of "Government Test & Evaluation Issues," CO Gomolak stated:

On November 15, 2006, AEon was notified that due to deficiencies in the "Rehosted" MOCAS database delivered to the Government, that the Government was rejecting CLIN 0001 and suspending [GT&E]. The letter further stated that until such time as the deficiencies were corrected and the Rehost application meets the 100% "as-is" functionality requirement specified in the contract [SOW], GT &E would remain in a suspended status. Furthermore, we acknowledge receipt of the November 29, 2006 letter written by [AEON's counsel] disputing the Government's right to reject CLIN 0001 and to suspend GT&E ....

However, from reading [counsel's] letter it is evident the parties have a difference of opinion as to what AEON is required to deliver under CLIN 0001. It is AEon' s opinion that the Government should accept a program that can not perform the most basic transactions the old MOCAS system performs and to use the entire GT &E period detailing to AEON what is broken so that those items can be fixed. The Government does not share the same view of AEON's responsibilities under the Contract.

The Government's position concerning the CLIN 0001 delivery is this: the product AEon delivers is required to

28 At the time of his testimony Normand G. Gomolak, Jr., had been a warranted CO with DF AS since August 2006 and had many years of prior corporate and military contracting experience since 1986 (tr. 2/306-09). He first worked on the MOCAS Rehost contract in spring 2006 as CO Gladski's contract specialist (tr. 2/310).

87 comply with the SOW. We have been inspecting the product under our right to inspect as set forth in the inspection clause and we have determined that the product as it currently exists does not comply with the SOW. Specifically, errors have been discovered that reveal your product does not comply with SOW§ 6 (system development), or§ 7 (functionality) etc. It is our position that your obligations undertaken with CLIN 0001 of this Contract are to deliver to DF AS a rehosted MOCAS and migration programs, both with full documentation that can perform exactly like the old MOCAS system. Until such time as your product meets the standards set forth in the contract, you will not have completed your obligations under CLIN 0001 and consequently, the Government will not move into the GT &E phase.

On December 7, 2006, members ofDFAS, DCMA and the DF AS Rehost PMO met to discuss the Rehost application and to determine if, in their opinion, the product currently meets all SOW requirements. Their conclusion is that your product fails to meet specifications required in the Contract. At the request of the PMO, the team has identified the following violations of SOW § 7 functionality requirements and these requirements must be present before CLIN 0001 will be accepted for recommencement of GT &E.

[l] Closed Contract Data Base (CCDB)- There are problems with all aspects ofthe CCDB (e.g., viewing contracts in the CCDB, moving closed contracts into the CCDB, re-opening contracts from the CCDB, etc.).

[2] REOPENs - Reopening contracts both on-line and from the CCDB is not functioning properly.

[3] Program UNAA71 - Contract control data changes (e.g. PIIN I SPIIN changes, CAO org code changes) are not working properly.

[4] Reports - There are many problems applicable to reports such as ( 1) data not appearing, reports not being produced when requested, data appearing the [sic] in wrong format I order etc. These problems are most prevalent in the UYF A04

88 & UYFDO 1 programs, but the problems are widespread across the database.

[5] Section moves - Contracts are not moving properly after month-end cycles are run (e.g., contracts are not moving from CAR Section 5 to Section 8).

[6] DD 250 processing- Not all DD Form 250 actions can be accomplished (such as Quantity corrections without errors). The major DD250 processes impacted are: • The Shipment Weight is not updating properly • Information entered is being incorrectly displayed on the screen after it has been input. • SQL errors are displaying after summary edits

While the above issues are the most prevalent, the entire DD250 process is suspect.

[7] Fall back (YCD4)- This module is not working properly as it does not allow rejected EDI I MILSCAP documents to be processed.

[8] Progress Payments - Files are not reflecting correct amounts (e.g., cumulative progress payments paid) and consequently affect the ability to pay and appropriately monitor them. Both the payment and tracking side of the process must be working.

[9] EDI Contracts (850s)- Transactions are not correctly updated. Incoming data is not populating (i.e., the effective date of the contract and date of signature). Other contract corrections cannot be made until date fields are manually inserted. Error Code "252 - FIC-Appropriation Unmatched" is wrong for a number of the contracts because the data is on the APRs.

[10] ACO Mod Module - interface, Openlink is not working properly as it does not consistently extract all ACRNs for a given PIIN I SPIIN. During the interface test, this problem appeared to be corrected. However, this same problem occurred during the Quality Review period.

89 [11] Shared Data Warehouse -All changes made in MOCAS (i.e. additions, deletes, changes) should be received in the proper order so that SDW data is current and correct. There have been numerous issues with data transfer rates, sequencing (i.e., incorrect sorting) and database records or tables not coming across with SDW.

[12] JCL/Cycles - GT&E Q/A has only executed three cycles - Monthly, Daily and 1st Daily; although the "baseline" cycle, the Daily, is one of the three. To date, no cycle has run uninterrupted from beginning to end without experiencing ABENDS[ 291 requiring program mods, data manipulation, JCL and/or control cards' changes. Additionally, there are multiple "flavors" (i.e., slightly different variations) of the Daily cycle that will need to be tested. These cycles are dependent upon the work day or calendar day of the month- 2nd13r

[13] Month-end Invoice Process - Month-end Invoice Process is not updating the Invoice History (YDF 1) for payments made in the month end cycle.

DFAS contracting and PMO personnel are working closely with AEon to ensure that all contractual requirements of CLIN 0001 are present before restarting GT &E. Specifically, AEon is required to correct the critical defects discussed above and to demonstrate the execution of the required functions stated in the contract.

(R4, tab 31) In the second 28 December 2006 letter, with the referenced subject of "Suspension of Government Test & Evaluation," CO Gomolak stated:

29 A program "ABENDS" when it experiences an abnormal ending caused by a problem or error beyond which it cannot proceed (tr. 2/225, 4/761, 5/949-50; supp. R4, tab 106 at 14). A list of various "ABENDS" that occurred during testing of daily and monthly cycles in the two GT&E periods, compiled by and distributed among the government testers, is contained in the record at supp. Rule 4, tab I 09 and contains 28 cycles (of a total of 32 cycles attempted) that experienced "[ABENDS]," 9 of whic,h could not be completed and were cancelled as a result.

90 The first factual discrepancy ... is the assertion that "the government has attempted to revoke its prior acceptance of the MOCAS system." This statement implies that the Government has accepted the delivery of CLIN 0001 and that has not happened. AEon delivered a product on October 23, 2006 and the Government started testing to determine if the product meets the contractual requirements. As our previous letter indicated, the system currently does not meet contractual requirements and as such, we have rejected the product you delivered in accordance with our right in [SOW ~ 11, Acceptance/Rejection] of the contract.

The second factual discrepancy .. .is the claim DF AS can not suspend and restart GT&E as this would render meaningless an entire section of the MOCAS Contract. In making this argument, [AEON's counsel] appears to equate the [PMP] as being part of the Contract. He implies that the PMP established the Contract's schedule and would have one believe that the PMP submitted with the contractor's proposal (technical volume) would supersede the Contract and modification to the Contract. The PMP is a Contract [requirement in SOW~ 4] and does not in any manner modify the rights and obligations under the contract.

The [PMP], along with all other deliverables required under the Contract [under CLIN 0001] never became part of the Contract. Neither the Contract, nor any modification, ever incorporated AEon's proposal. Furthermore, at the top of page 6 (end of line 8) in our SOW it states, "[t]he above reports (PMP and others) and IPRs do not relieve the contractor from the terms of the contract." Therefore, the idea the rules of contract interpretation give AEon's PMP more weight than the Contract is inaccurate. Our exercise of the right to reject CLIN 0001 is clear and unambiguously contained in [SOW~ 11, Acceptance/Rejection] and nothing in the Contract modifies this right.

The third item ... state[d] is that "the Contract does not require AEon to deliver a defect-free system prior to GT &E." DFAS disagrees with [the] statement. Any interpretation of the contract as allowing AEon to deliver something less than a fully working MoCAS system has no factual basis and is an

91 attempt to unilaterally change AEon' s performance obligations required under the contract.

The fourth assertion .. .is "[t]he contract's [PMP] and Schedule further provide that after the completion of user acceptance, both the production support phase and the repair phase will include the correction of "bugs" by contractor AEON." This assertion is also incorrect. Implicit in [the] argument is the assumption that DF AS is going to accept a MOCAS system that does not completely perform as the old system does. This assumption is inaccurate and brings us back to a point that is persistent in [counsel's] letter.

This point relates back to the invalid premises both AEon and [counsel] have articulated, that AEon can deliver a product that has defects and DF AS has no other right but to accept a defective product and allow AEon to resolve the "bugs" over the next year. This interpretation would render meaningless the fact that CLIN 0003 is an option CLIN. Moreover, the use of the terminology "defect" and "defect free" in describing the performance requirements is a misleading use of words. Those terms should never be used to describe AEon's performance obligations under the contract.

The contract is very clear on AEon' s performance obligation. Under CLIN 0001, AEon must deliver a rehosted MOCAS database that has 100% functionality of the "as-is" database. Using terms such a[s] "defect" has no place in the discussion of AEon's performance obligation. Its use distracts everyone from the true objective and obligation of AEon. That obligation remains a rehosted MOCAS system that mirrors 100% the actions and functionality of the old MOCAS system.

By DF AS pointing out defects to be fixed, we merely were attempting to aid AEon in completing their obligations under the contract. The fact that discrepancies exist between the old system and the rehosted system provides evidenced [sic] that the system AEon delivered with CLIN 0001 has yet to achieve its required performance obligation.

92 As of this date, DFAS still awaits AEon delivery of a fully functional rehosted MOCAS system. DF AS has noted a host of issues that must be fixed or corrected in the rehosted MOCAS system.

For example, in paragraph 14 of the SOW,f3°1 AEon was required to provide a [PMP]. For whatever reason, this has become the [PMP], the last of which (dated September 22, 2006) was delivered to the Government as a final document (v9). Despite this designation as a final document, page 33 indicates that several of the Work Breakdown Structures (WBS) are less than 40% complete.

Yet, the rehosted database was delivered portending to have 100% functionality of the "as-is" database. This discrepancy raises many questions, including how could AEon perform several of the functional tests as part of their Quality Assurance testing when the several WBS are incomplete? In the September 22, 2006 PMP document, Section 6 "Schedule" states, "[t]he Work Breakdown Schedule and Project Plan for all phases of the MOCAS Rehost Project are updated at the end of each phase and as appropriate between the parties." This implies that your WBS is up to date, but less than 40% complete.

DFAS has every right to demand and expect AEon to fulfill the obligations they have incurred to perform this contract. DF AS wrote this contract so that it was clear what the contractor had to do to complete performance. This was not the development of a new computer system, but rather translating an old programming language into a newer programming language. It is AEon's responsibility to produce a rehosted MoCAS that "works." That is, the Rehosted MoCAS must perform exactly the wa[y] the as-is system does.

(R4, tab 30; tr. 2/316-17) (Footnotes omitted)

30 We believe this is a typographical error as the PMP is required by SOW i! 4.

93 87. By letter dated 16 January 2007 counsel for AEON again took issue with CO Gomolak's expressed reasons for halting GT &E. In particular, he reiterated the argument that the contract contemplated that the Rehosted MOCAS delivered for GT&E would contain deficiencies:

Further, the Contract required AEON to deliver a system with 100 percent functionality. The "functionality" requirement applicable to the re-hosted system, however, is not tied to the discrepancies the parties expected the sophisticated Government test experts to identify. Instead, "functionality" examines whether the system AEON delivered for GT&E has the same functions as the original system. Without a definition of functionality in the MOCAS Contract, the parties must rely on industry standard. In this industry, as you know, functionality concerns overall system performance-not the presence or absence of resolvable discrepancies ....

(R4, tab 32; see also supp. R4, tab 121 at A012613-14). We find that the preponderance of the record is directly contrary to counsel's assertion that the contract did not define functionality; in fact the SOW devoted several pages to the specific definition of functionality (finding 14). It is that contractual definition upon which the government solicited proposals, AEON submitted a proposal and AEON executed a contract. Further, AEON's own PMP expressed its understanding that the Rehosted MOCAS was to perform exactly like the As-Is MOCAS (findings 55, 71). We do, however, find counsel's statement that "functionality concerns overall system performance" and not the presence or absence of specific defects or discrepancies to be in accord with the contract and the preponderance of the record (see also finding 87 in this regard). AEON counsel's letter continued to argue that the government's rejection of the Rehosted MOCAS was premature and that:

You have yet to identify a single function contained in the original system that is missing from the rehosted system AEON furnished for GT&E. The reason? The systems have the exact same functionality.£3 11

In any event, AEON has resolved all of the alleged deficiencies. Ms. Shirin Javid notified you by email dated December 29 that AEON has "fixed all client defects and

31 Apparently counsel had not considered CO Gomolak's list of 13 violations of the functionality, i.e. functional failures, required by SOW ,-i 7 (finding 86).

94 there are no 'open' defects." AEON has yet to receive any response to this notice. Your agency has not restarted GT &E. Your agency has not given AEON credit for the days of GT&E conducted by the parties even though the Government successfully completed some of its testing. Moreover, you have not communicated any date at which GT&E will resume or, alternatively, provided any rationale as to why it should not resume immediately. Further, the Government's undertaking of testing resolved defects has been minimal and slow. The MOCAS Contract does not contemplate such unreasonable Government delays, which have forced AEON, a small company, into a position of maintaining its work force in place at considerable cost while it awaits Government action. Your failure to respond constitutes compensable delay for which AEON could submit a [REA].

(R4, tab 32)

88. On 19 January 2007 AEON expressed its desire to complete the MOCAS Rehost project:

[W]e do not want to walk away. We would strongly prefer to complete the Rehost project. We have formed a strong relationship with you, our client. We are dedicated to the work. We feel ownership in the project. We want to see the project to its fruition, which, if well managed and performed, should be only a few months away. To reach this goal, however, we need a commitment from DF AS which demonstrates that DF AS likewise shares the goal that AEON complete what it has started.

As we have discussed, there are three major categories of work which require compensation. First we submitted an REA in October 2006 in the amount of $643,714 [see finding 75]. Second, we have an Engineering Change Proposal [ECP] outstanding, in the amount of $621,514. £321 Third, the work associated with GT&E is valued by the

32 The referenced ECP-2 was proposed by AEON in November 2006. AEON stated in the proposal that "No impact to the current MOCAS Rehost Project effort is expected." (App. supp. R4, tabs 162, 163; see also supp. R4, tab 106 at 23) As such, ECP-2 is irrelevant to the issues before us.

95 MOCAS Rehost Contract at $928,082. These three categories amount to $2,193,310. We believe we are immediately entitled to the entire amount of our REA and the entire amount of our ECP. In addition, had the parties performed GT &E in the manner described in our Contract, AEON would have been entitled to the $928,082 associated with GT&E on the 90th day of that period, which is today (January 19, 2007).l 33 l

Your decision to delay the REA, ECP and GT &E has damaged AEON. Under normal circumstances, we would have been compensated for the REA and ECP. Under normal circumstances, we would have been entitled to invoice $928,082 associated with GT&E on January 19th. In the interests of putting "normal circumstances" behind us and settling these issues, we want to compromise. To compromise, however, we will require immediate action from your agency. You claim not to have the funds to pay us for the REA, ECP or advance any portion of GT&E at this time. We understand that if your agency lacks those funds, you will be in violation of the Anti-Deficiency Act. Accordingly, we will assume you have the funds associated with these "buckets. "l34l

Here is what we propose. We will re-start GT&E on Monday. In return, you agree to fund $386,228.40 of our REA immediately, which [sic] the remainder subject to negotiation. You also agree to fund $372,908.40 of the outstanding ECP immediately, with the remainder subject to negotiation. In addition, you agree to restructure the payments associated with GT &E in such a manner that facilitates payment in the amount of $556,849.20 to AEON now, with the remainder payable at the successful conclusion of GT&E. In order to restart work on Monday, we will require your commitment to pay the amounts listed in this paragraph by February 1, 2007.

33 We note here that AEON would only be entitled to the GT&E payment it seeks here if, at the end of the initial 90-day GT &E functional testing period, the Re hosted MOCAS passed GT &E and was ready to be put into production in the second 90-day GT&E period (see findings 11, 49). 34 There is nothing in the record to corroborate this allegation by AEON.

96 As stated in this letter, we want to continue work in spite of what we consider material breaches. In return, however, we simply ask that the Government treat us fairly. Ifwe reach agreement, we will commence GT&E on Monday. Ifwe do not reach agreement, we reserve all rights.

(R4, tab 33) There is no evidence in the record that the government paid AEON any of the three amounts sought by AEON as a necessary prerequisite to its continued performance under the contract.

89. On 19 January 2007 AEON again certified that the Rehosted MOCAS met contract requirements and was ready for GT&E. The government restarted GT &E on 22 January 2007 (R4, tabs 33, 34, 40, 49).

[T]he Government agreed to resume GT&E due to AEon's assertions that all system problems had been fixed. Results from the Government inspection/validation during the suspension did not support AEon's position that the system quality of the system had matured and it met the requirements of the SOW. The Government acting in good faith resumed GT&E based on AEon's representation.

(Supp. R4, tab 106 at 28; see also R4, tab 35) Taking into account the nine days of GT&E conducted from 24 October 2006 through 2 November 2006 (findings 77, 82), the expiration of the 90-day contractual GT&E functional testing period was now 10 April 2007 (see also findings 95, 99).

90. As of CO Gomolak's 6 February 2007 letter to AEON 15 days after the restart of GT&E, the government testers were still finding problems with critical "must function" modules:

While AEon continues to report that defects have been fixed, government validation testing has determined that the identified defects still exist and additional defects are being found. This situation leads the Government to seriously question the adequacy of AEon's quality assurance testing relative to the correction of these deficiencies. You have indicated you did not run any complete batch cycles during your validation of the corrected deficiencies. Because a number of critical defects depend on a cycle being run to validate their correction, this further demonstrates the

97 Government's beliefthat when addressing defects, AEon is only focusing on correcting the specific problems identified rather than ensuring the overall function works properly.

This issue remains a Government concern due to the fact that when inspecting problems reported as being fixed, DF AS & DCMA testers are unable to test the overall process function. Since the Government has resumed GT&E, there are still enough critical defects that prevent testing the entire end-to-end process. We have not been able to process EDI DD250's which resulted in a cancelled cycle. Progress Payment, SDW, Fallback and Contract Closeout continue to be a problem. There has been some improvement in contract input in which the tester can summary edit a contract, but the process is not consistent. SDW processing is still a problem in that files are not being sent across to the SDW test server. The Government testers have stated they can get beyond the original problem only to immediately have a new problem arise on a subsequent screen. Thus, the Government reiterates its position that AEon has not yet met the conditions specified in the SOW for delivery of CLIN 0001. By this, we mean that Re-hosted MOCAS program must function like the "as-is" program functions.

(R4, tab 35) The letter provided a non-inclusive list of nine "new problems that have been encountered." DCMA test lead Turner described what the testers found upon restarting GT&E:

Well, there was still a lot of problems with the testing, and significant problems with areas such as interface tools, S[D]W, MOCAS, contract closeout as far as movement from section to section.

And by that I mean just like the lifecycle of the contract, and like contract administration reports, and sections describe what phase its in ....

But that wasn't happening, and it was supposed to be a kind of an automatic process, and when you ran a monthly, those things weren't moving the way they should have been.

98 And that was one of the big areas, and you had payment problems, and quality assurance problems, and management information system problems. We had problems with transfers ....

(Tr. 4/769-70, 5/900-01)

91. On 7 February 2007, AEON's President and CEO sent letters to two Ohio Congressional representatives seeking assistance in getting payment from the government. In the letters, AEON characterized the government's suspension and subsequent restart ofGT&E as a failure on the government's part to "fully commit to this phase and ... not provide the resources required to successfully complete it":

The Government's actions ... have exposed AEON financially to over $3M in debt. I have borrowed money and have even obtained a second loan on my home to meet AEON' s financial obligations. Unfortunately, we no longer have the funds to make payroll. We have already missed one payroll and will probably miss the next payroll also. We expect that our employees will leave in the next few days. They will be without a job and be forced to file for unemployment.

In conclusion, the Government through its actions is forcing a competent and qualified woman owned small business into bankruptcy and causing unemployment for Columbus.

(R4, tab 36; see also app. supp. R4, tab 190) There is no evidence in the record of a response to either letter. COR Thrower observed:

In the end, they realized that they were at risk because they had employees that had left, because the employees were working and not getting paid. So they were losing staff.

They only had like maybe five or six people left, and the people that were left were retired government employees, and so they had a good check coming in.

So the ones that left, you know, that didn't have another source of income, they left. They knew that they didn't have enough staff to be able to continue the project at that point in time.

99 (Tr. 3/471-72)

92. In a 14 February 2007 letter AEON denied many of the allegations made in CO Gomolak's 6 February 2007 letter. In particular:

We are very concerned because of the lack of information about the overall GT &E testing process. We do not know the Government's GT &E test plan, test approach, what has been tested, what works ... etc. Since this is a fixed price contract we are entitled to know what the Government is testing, how many tests are conducted daily, what issues exist and what works. The only information that we continuously receive is that nothing works. We have a real problem with this approach.

(R4, tab 37 at 1260-62) AEON again repeated this position in a 19 March 2007 letter in which it took the position that the government's failure to share specifics of the GT &E process with AEON was a breach of its duty of good faith and fair dealing under a firm-fixed-price contract (R4, tab 39). We find nothing in the contract or the concept of a firm-fixed-price contract that obligated the government to share the specifics of its GT&E process with AEON. The GT&E process was a final inspection of delivered product and conducted for the benefit of the government, not AEON and was not intended to be part of AEON's quality assurance program.

93. On 27 February 2007 CO Gomolak responded to the 16 January 2007 letter from AEON's counsel (finding 87):

[T]he contract did not contemplate AEon turning over a system for GT&E that could not perform the most basic and essential processes the "as-is" system could perform. Clause 9 of the SOW requires unit testing, integration testing (which includes testing the rehosted MoCAS functionality), performance testing and a trial migration. The purpose of this testing was to ensure that the Contractor bore the risk and responsibility to deliver a working product. Furthermore, the Contractor was required to certify that their product was working like the "as-is' prior to handing it over to the Government for GT &E.

The deficiencies we identified were of such a magnitude that complete end-to-end cycle testing could not be

100 conducted. For example, the rehosted MoCAS system could not process a DD250 form so as to allow an invoice to be paid. Processing a DD250 is a very basic transaction in MoCAS. Because the system AEon delivered had trouble processing a basic transaction, our testers' time and efforts were unproductively lost. Thus, the Government's decision to return the system to AEon and thereby allow AEon an opportunity to correct the plethora of discrepancies uncovered was a very reasonable course of action.

Moreover, we indicated that as soon as you had corrected the errors we found and were able to provide a fully functioning system, we would restart GT &E. This is a very reasonable approach considering the circumstances. To AEon' s credit, since re-starting GT &E on January 19, 2007, several successful cycles have been completed with minor technical issues (i.e., no abends). However, on January 22 and 24, cycles had to be cancelled in "mid-test" because critical path programs would not run and could not be fixed in a timely manner. Furthermore, some fiscal appropriation data was not aligning properly, if at all, to the contract line item under which the funds were obligated. The system can't automatically transfer data to SDW, which is integral to the system and remains an issue.

These are just a few examples of the critical discrepancies which still exist today that should have been uncovered during AEon's QA testing. The Government is justified in expecting that a properly run QA test would have uncovered such conditions. [AEON]'s decision to collapse testing and do everything in parallel prevented it from properly performing the testing required of it. AEon never ran all cycles in the system during its testing, so it never performed a proper integration testing. Attached to this letter is a memorandum which details more precisely AEon's failure to follow industry standards and contractual requirements during the QA test phase. Because AEon did not conduct proper testing as required in the contract, AEon was unable to deliver a product, which conformed to contractual standards at the start of GT &E. AEon' s failure has lead to the Government uncovering fundamental problems that were not

101 contemplated by the Government to be "discovered" during the 90-day GT&E period.

As to (AEON counsel]'s discussion on functionality, we would agree that the Re-hosted (to-be) database must duplicate the functionality of the "as-is" database. However, our contention is that several critical functions have yet to be tested because the contractually required functionality is not present; i.e., these functions simply do not work. Considering the system did not work, AEon never should have certified it was ready for GT&E and correspondingly AEon's entitlement to payment for milestone 7A. Thus, the Government exercised its right to properly reject the CLIN 0001 delivery until such time as all functionalities of the Rehosted MOCAS database functioned in accordance with the terms of the contract.

As pointed out above, what was delivered by AEon confirms the Government's belief that AEon did not satisfactorily perform all the required steps of their QA test; steps that industry standards would require to be completed. More distressing is the fact that AEon has represented the rehosted system had the functionality and worked like the "as- is" when it certified the system was ready for GT&E. Thus, CLIN 0001 was delivered to the government before the system was performing like the "as-is." It was delivered before AEon had completed required portions of a proper QA testing period.

It's possible we are arguing semantics when it comes to software deficiencies and functionality. (AEON counsel] argues that all the functionality is present, but that there are software deficiencies contemplated under the contract that would be revealed during the "sophisticated" Government testing process. The fact of the matter is there are many, many software deficiencies that have degraded required functionalities to the point that certain functions are not present in the Rehosted MOCAS database. The Government's conclusion, the 100% functionality requirement set forth in paragraph 7 of the SOW, simply stated, has not been met.

102 (R4, tab 38)

94. In early March 2007, about halfway through the re-started 90-day GT&E functional testing period, the PMO contacted four organizations, including Software Engineering Institute at Carnegie Mellon (CM/SEl), 35 and inquired of them as to their interest in providing Independent Verification and Validation (IV& V) Support to DF AS of the Rehosted MOCAS delivered by AEON for GT&E (app. supp. R4, tabs 211, 216, 222-23, 286; tr. 7/1160-62). The PMO described CM/SEI's proposal as "start[ing] out at a very high level and appeared to be focused on management processes. After several discussions with DFAS, they seemed to comprehend the technical nature of the request." (App. supp. R4, tab 223) As of 23 April 2007, after weeks of discussion with the four organizations, the PMO was ready to engage CM/SEI (id.). The initial request from the PMO to CM/SEI was very specific that its request was time-sensitive and that the primary focus was to be on whether the product delivered by AEON was "salvageable," defined as "can the product be repaired to a fully functioning system in a reasonable time period." The request further specifically stated:

Task 3. Follow-on elements: While DF AS is open to any and all recommendations about the project in general and possible future course of action(s), process improvements, etc., DFAS wants to reiterate the immediate and technical nature of this request. DF AS recognizes that management and development strategies will be useful and necessary, but only if the technical assessment determines the product is viable.

(App. supp. R4, tab 290) The "initial items of concentration" were identified by CM/SEI as:

Determine whether the MOCAS re-host project is salvageable and maintainable

Determine ifthe MOCAS re-host project code is adequately functional and useable

Identify areas of the system that may need re-work

35 CM/SEI is a Federally Funded Research and Development Center (FFRDC) chartered in the mid- l 980s to focus on software-related issues for the DoD. CM/SEI provides its services to many Federal agencies, including the DoD and Department of Homeland Security. (Tr. 711150)

103 Determine resources appropriate for completing the MOCAS re-host project and the difficulties that may be encountered

Estimate how long it will take to complete the MOCAS re-host project

(App. supp. R4, tab 258 at 10; tr. 5/1107-08, 7/1163) CM/SEI's proposed Independent Technical Assessment ( ITA) was to take place over a period of time not to exceed two months, at the end of which CM/SEI would present an "annotated briefing which will contain the team's findings and actionable recommendations" to DFAS (app. supp. R4, tab 290; tr. 711162, 1251-52).

An independent technical assessment is a technique that [CM/SEI] uses to look at a program when it has been identified that it is in serious trouble.

Usually those requests for this kind of an examination come from a senior DoD official, usually a very senior program manager or a PEO, which is somebody who has cognizance over many problems, or it comes from a level of the service acquisition executive, who has cognizance over everything.

And basically what we are asked typically to do here is to look at the program, and try and figure out what is wrong, and what could be done to fix the situation, or in some cases, we have actually recommended that a program be terminated.

And the Government uses us in this context from the perspective of being an honest broker, having no skin in the game at all, and trying to provide a programmatic wide perspective, and what I mean by that is that an ITA looks at management. It looks at people. It looks at program offices, and it looks at the technology, and things like that.

And that is the way that we have to approach it, because the program is in trouble, and we are trying to help it get better, or in some cases - I mean, some programs are better off being terminated and restarted.

104 (Tr. 7/1178-79) The record does not indicate when DF AS and CM/SEI reached agreement on the performance of an assessment of the Rehosted MOCAS. CO Gladski was involved in discussions about having an independent assessment performed and was aware that the PMO had contacted CM/SEI but was not involved in the details of the engagement (tr. 1/142-43, 2/165, 168-76).

95. On 22 March 2007, 71 days into the 90-day GT&E functional testing period, CO Gladski issued a Cure Notice in which AEON was notified that the government considered AEON's failure to make adequate progress in correcting code deficiencies during GT&E and AEON's failure to consistently pay its employees as conditions that endangered performance of the contract (R4, tabs 26, 40, 45; tr. 11121-22). The failure to make adequate progress was identified by the government as the failure of AEON to deliver a system with 100% functionality of the "as-is" system as defined in Section 7 of the SOW.

There were so many deficiencies that were discovered, and at that point in time the PMO said that it would be next to impossible for GT &E to be successfully completed.

GT&E testing ... was never successfully completed. The test scripts could never be run from end to end because there always seemed to be another deficiency that would occur in the process, and that was a great, great area of frustration to the testers, because they could never get a full end-to-end.

Something would be identified as a defect, and it would be corrected, and you would get through that, and you may end up having something else fail that had previously been fixed.

And once you got that fixed, something else would happen. So it was just a never ending situation of failure upon failure.

(Tr. 11122, 124) More specifically, COR Thrower described what occurred:

Regression testing is when you have a defect that is reported, and you go in and you test it. And you have a report

105 that Problem A works, and you go in and test A, and it works. You try to go to B. B doesn't work.

And I'm talking about screens, okay? So B doesn't work, but then you report that problem, and they fix B. So you go back in to test, and now A doesn't work, and where it worked the first time.

So every time you go back in, you are testing the same stuff over and so you are regressing testing, and you are not getting further along in your tests.

(Tr. 3/389-91, see also tr. 4/763) Specifically, six MOCAS functions were identified in the Cure Notice as critical and which were not functioning correctly in the Rehosted MOCAS:

• Military Standard Contract Administration Procedures (MILSCAP) and Electronic Document Interchange (EDI) Process:

Contracts received electronically through MILSCAP or EDI are erroneously being rejected for accounting line errors (appropriations errors) when in fact the line of accounting is correct and the appropriation is on the master appropriation file. In addition, electronically received contract modifications, invoices, and receiving and acceptances are also rejecting for erroneous "NO CAD" or "NO PINY" error messages, meaning that No Contract Administration Data is on file or No Contract (PINY) is on file, when in fact the contract has been processed and already resides on the database.

• FallBack Process:

Contracts received electronically through MILSCAP or EDI that are rejected and placed in the FallBack system for manual review and processing can not be processed due to numerous SQL error messages. In addition, in those instances where a contract or modification is successfully processed through FallBack (i.e. successfully Summary Edited), not all the individual

106 contract data elements are updating the database files, resulting in problems with missing data later.

• Material Acceptance and Receiving Report (DD250):

Shipment and acceptance reports received electronically through EDI are being erroneously rejected and placed in the recycle file for manual review and processing because the system is not recognizing that there is a valid contract on file. In addition, the system is erroneously creating, or allowing the creation of, duplicate shipment records resulting in subsequent shipments/acceptances to erroneously reject.

• Automatic Payment of Invoices (API):

The API process disbursed funds against the wrong appropriation, Material Acceptance Account Payable Reports (MAAPRs) show notebook entries which are on the contract, system generates a manual MAAPR, indicating an invoice requires manual review and processing by a voucher examiner, but erroneously continues to try to process the payment automatically; invoices that should pay automatically are being rejected for insufficient funds when sufficient funds are available.

• Progress Payments:

Data elements input during the entry of progress payments are not updating the database properly, which causes erroneous payments and the on-line screens and batch reports to display incorrect dollar amounts.

• Shared Data Warehouse (SDW):

Daily jobs to archive files, build SDW bridge (interface) logs, and update the bridge matrix have failed through most of the GT&E. The problems prevent or delay the sending of transactions to SDW.

107 We have identified these particular critical processes in this Cure Notice from among the numerous deficient processes in the rehosted code previously identified to AEon. Thus, these conditions are materially contributing to AEon' s failure to progress in making timely code corrections during GT &E I Event !Phase 7.

Please be advised that curing these processes alone will not satisfy AEon's ultimate contractual obligation to provide the re-hosted database and code with 100-percent of the functionality of the As-Is MOCAS required by section 7 of the SOW. The purpose of GT &E Event/Phase 7 testing is for the Government to determine whether the code and re-hosted database are contractually acceptable. If, at the end of the GT &E period, AEon still has failed to deliver a code which meets the functionality requirements contained in the SOW, the Government will have "failure to deliver" as an additional ground for termination for default. Based on the 90-day period, this GT &E Event/Phase 7 testing period runs through April 10, 2007 .1

1 Initial Event/Phase 7 testing by the Government in October and November 2006 exposed that the code was not at the maturity level certified by AEon at the conclusion of Event 6. The Government suspended testing events on November 15, 2006, via written notification, because the product could not perform basic system functionalities. In that letter, the Government rejected tender of the re-hosted MOCAS code and advised AEon that it stood ready to recommence testing upon AEon's satisfaction of its contractual responsibility of resolving problems sufficient to establish basic core functionality. In good faith, upon Aeon's affirmation that the system was once again sufficiently mature and ready for testing, the Government during the January 18, 2007 GT &E status meeting elected to accommodate AEon's request to recommence Event/Phase 7 testing. Event/Phase 7 testing recommenced on 22 January 2007. In the period since, AEon continues to fail to make adequate progress through Event/Phase 7 in correcting the MoCAS [sic] code,

108 which remains incapable of being executed as an entire end-to-end process and does not meet contractual requirements.

(R4, tab 40) (Emphasis added) We find CO Gladski's testimony, almost three years after issuance of the Cure Notice and almost two years after his retirement (finding 15), that he understood the list of six "critical functions" in the Cure Notice to be "reflective of every defect that was known at that time" (R4, tabs 26, 40; supp. R4, tab 106 at 25; tr. 1/123, 125) to be inconsistent with the express language of the Cure Notice, quoted and emphasized just above, as well as elsewhere in the contemporaneous record evidence that the six areas identified in the cure notice were "only a few of the numerous deficient processes in the rehosted system" (see also supp. R4, tab 106 at 29). Within just the six categories of functions listed in the Cure Notice, there were a total of 99 specific deficiencies identified by the government and provided to AEON (supp. R4, tabs 96, 97; tr. 11125-26, 2/219-23). AEON was given 20 days within which to cure these six functional failures and the government stated that failure to do so may result in a termination for default of the contract (R4, tab 40; supp. R4, tab 106 at 29).

96. On 3 April 2007 AEON responded to the Cure Notice advising that, of the 99 specific deficiencies provided by the government in a list on 28 March 2007, 96 had been corrected and the remaining 3 would be corrected no later than 9 April 2007 (R4, tab 41 ). There is no indication in the record that, just because the 96, or even 99 deficiencies were allegedly fixed, the functions to which they pertained were then fully operational.

97. DCMA test lead Turner, who had over 25 years experience using the existing MOCAS system, testified that "as far as the contract administration, and payment procedures" the Rehosted MOCAS had "too much missing to be able to function" (tr. 4/780).

Q Overall what was your view of the performance of the rehosted MOCAS?

A I don't think it was ready.

Q And what do you mean by that?

A I don't think we could have used it in a production environment.

Q Do you have any idea as to how close it was to being ready?

109 A I think we had just started scratching the surface. I would say maybe a third.

Q And what do you mean by that, that you had just started scratching the surface?

A We could get to the first phase of doing the function, and we can't get to the next step, and there was areas that we didn't really get to delve into because of some of the problems there were that we found, and in such areas as QA Miss, which was a quality information management system, we needed to hit that a little harder, and we weren't able to do that.

We were able to do internal transfers, which we still have problems with, but we were not able to do an external transfer. The idea initially was that we were going to start off with one MOC and gradually pull in the other two MOCs.

And by that I mean MOCAS is divided up into three different areas. They are a copy of the same thing, but one has contracts for the west region of the United States, and one had them for the northeast, and one has them for the south.

The one that has the south is MOCG, and that has the fewest contracts. So we started using the data for MOCG, and then we were supposed to go to MOCH or something. I deal with doing external transfers, which is a big piece of our business, and we weren't able to do those types at all.

In some of the areas, if you can't set up and stage things, and you find problems between, then you can't get to the next phase of what you are trying to complete.

That's why I am saying that we had just scratched the surface on some things in MOCAS. We didn't get down to the level that we needed to go to.

(Tr. 4/784-86, 790-91, see also tr. 5/1031) AEON insisted that the failures were because the government did not load and retest fixes that AEON had made (R4, tab 39 at 1275). The government responded that: "We continued to test. The reason why so many test

110 cases may not have been tested is because they couldn't get further along in the testing. You can't test the next position if you can't move along in the screen." (Tr. 3/461, 486-88, 506, 524-30, 5/1022-23, 1033) We find that the specific number of critical functions or defects is not indicative of whether the Rehosted MOCAS had 100% of the functionality of the As-Is MOCAS. If the Rehosted MOCAS could not perform exactly like the As-ls MOCAS, regardless of whether there were 6 problems or 60 or 600, the Rehosted MOCAS failed to meet the contract requirement of 100% functionality.

98. On 5 April 2007 AEON submitted to a Congressional representative an "URGENT REQUEST FOR ASSISTANCE" in getting payment of $2.1 million it claimed was due and owing for successful GT &E, as well as its October 2006 REA and its November 2006 ECP (see finding 88) (R4, tab 42). In the submission AEON stated:

AEON is committed to completing the contract and has, until very recently, paid its employees despite DFAS' refusal to make further payments.... DF AS' failure to pay anything this year has put this small business in debt over $3.0 million. Because borrowed funds have now [run] out, AEON has missed four biweekly payrolls. On Friday, March 23, it missed its fifth payroll. The company has never defaulted on its contract with DF AS but simply cannot continue performance without at least a partial payment from the government.

(R4, tab 42) The record contains no evidence of a response to AEON's request.

99. The 90-day GT&E functional testing period ended on 10 April 2007 (supp. R4, tab 103 at A005698; findings 89, 95). The government continued to test fixes uploaded by AEON through the week of 18 April 2007 and wrote up problem reports as late as 27 April 2007 (tr. 3/469-80 [tested for two weeks after AEON stopped making changes], 4/770-72, 834-35, 5/905, 956, 1050; see also, R4, tab 45 [5of6 cure notice issues still a problem]; supp. R4, tabs 106 at 29, 108, 111, 113).

100. On 24 April 2007, two weeks after the end of the 90-day GT &E functional testing period, the DFAS and DCMA testers circulated among themselves their comments on the status of multiple "significant" outstanding "Cure Items" at the close of GT&E (supp. R4, tab 108; tr. 4/779-81 ). On the same date the DF AS MOCAS Rehost - GT &E Final Test Report was issued in which it was reported that only 46% of the total test conditions had been performed "in part due to regression testing [see findings 55, 95] and persistent system problems" (app. supp. R4, tab 224; supp. R4, tab 111 [306 test conditions not even tested]; tr. 51965, 975-76, 1028-29).

111 [W]e still had a large volume of critical A [see finding 79] fixes outstanding ....

Just under 50 percent, maybe like 40 percent or so of [MOCG] the testers were able to test.

If [the rehosted MOCAS] had all the functionality we wouldn't have encountered the numerous errors that we encountered. If we had this product in real world today we would be a mission failure, if we can't input mods and contracts and pay invoices ....

[The total test conditions reported to be completed] [l]ooks like 46 percent. Our concern going forward was MOCG was probably one of the smaller MOCs as far as complexity. We have foreign currency on MOCH, very complex programming, we hadn't even gotten to that point. So even though the numbers look like we're halfway there, there [was] very important testing that we didn't even get to.

(Tr. 511039-43, 1045)

101. The government testers determined that the MOCAS interface with the Shared Data Warehouse (SDW), a critical function for DCMA, was not functional at all. "It would never do anything. It wasn't even able to be tested." (Tr. 3/534-35)

The shared data warehouse is not MOCAS.

It is a different system. The MOCAS interface is what AEON was committed to produce the same interface files that the as-is generated for the shared data warehouse. That was the extent that they needed to develop the same interface files to the share[ d] data warehouse.

112 (Tr. 4/736; see findings 5, 14, 39, 48)

Shared [D]ata [W]arehouse is one of our critical applications in DCMA.... It is refreshed daily through MOCAS sending the notices to SDW.

And it basically is the guts of every web application that we have in DCMA. We rely on that MOCAS data to pass to SDW, and be updated and current. So when SDW doesn't work, our agency is like in deep trouble, because none of our web applications work as well.

And what this problem sheet was saying is that we were having a hard time. We weren't capturing updates. We were not capturing new contracts. We were having a hard time. SDW wasn't functioning basically at all with the new rehost database.

(Tr. 3/598, see also tr. 5/988-96; supp. R4, tab 123-J) DCMA tester Jackson testified that the SDW interface was not functioning correctly:

Oh no, absolutely not. I have been involved in a lot of type tests, and generally we are shaking out the system and you do find some bugs. In this case, it didn't work at all for us, and it was almost as if we were in the development and design stage, it worked not at all. So no, it was not ready in any way, shape, or form.

(Tr. 5/997) Jackson further testified that, even at the end of GT &E:

We still had lots of errors, other than what the ticket sheets show, as you put in a ticket, as things were resolved, more errors were found at different layers, it just seemed to keep cascading. As we would uncover one error and resolve it, you would then have another error or sometimes you'd go back and have an error that you hadn't seen before .... And so the improvement that we saw was, things were lined up, but at that point the errors were deeper into the architecture and it became apparent that the problems were just so deeply embedded we weren't even sure why things were being

113 generated the way it was being generated, there was missing data, it was just kind of unfolding.

[The rehosted MOCAS bridge to the SDW did not work like the as-is MOCAS bridge.] The system as in place is highly dependable, we have extremely high rate and our depend [sic] on the integrity of that system. If we had failures we reload that system, and normally we don't have calls to reload it. In this case it could never have stood up to the rigors and to the users, they would have lost confidence immediately in the system because there were so many inaccuracies, we could have never deployed this as it was at that time.

[Putting the rehosted MOCAS bridge to the SDW into production] would have been disastrous, the number of errors and problems .... So we had data that was incorrect, data that was missing, and we had no way to track back where it was .... And for a[n] information system that people depend on for producing reports of money, of contractor activity, you can't have it in that much error, and the errors were extremely high.

Well I heard [from AEON] that throughout the tests that it was just, you know, a few things to fix, just a few things to fix, and we kept going and going and going, and seeing that the further that we got into it the more problematic. I mean initially when we were curing things, were realigning fields, I was hopeful. When we started seeing problems that we had no idea what was generating, that some of the programs were developed by different people who didn't work the same way, this log analyzer that they were using seemed undependable, seemed to be very buggy maybe, I don't know. It was obvious that this was not going to work no matter what we did.

114 (Tr. 51996-00; see also supp. R4, tab 113) DCMA test lead Turner summarized the SDW issues as:

SDW - The Mocas Rehost process of sending updated transactions from Mocas to SDW continued to be error-ridden. At GT &E conclusion, a percentage of transactions continued to fail the SDW database commit process. The contractor process to identify and send transactions to SDW became operational a few weeks prior to GT &E close, but did not reliably function. Functional testers examining transactions that were successfully relayed and committed to SDW found numerous errors in data and data relationships.

(Supp. R4, tab 108; see also finding 106)

102. The PMO made the determination that:

Based on the number of outstanding critical system problems, inconsistent processing results, and continued challenges in completing nightly cycles, especially monthly cycles, the Government testers could not certify nor recommend deployment of the rehosted MOCAS to production. These results, AEon's failure to deliver a system with functionality mature enough for user testing and AEon' s inability to cure system areas with significant deficiencies, led the PMO to end all Government testing activities. If continued, the PMO determined, with concurrence from the Government testers, that the process in which the Government was required to find the defects for Aeon to resolve (i.e. find and fix process) would continue indefinitely.

(Supp. R4, tab I 06 at 30)

8. WBS 8, GOVERNMENT ACCEPTANCE/REJECTION

103. WBS 8 correlated to Payment Event 8. The required tasks to be completed by AEON for Payment Event 8 were identified in the contract as "Completion of the delivery and acceptance of CLIN 000 I in the Production environment" (finding 21 ). In other words, in order for AEON to qualify for Payment Event 8 the Rehosted MOCAS had to pass the initial 90-day GT &E functional testing process, pass the second 90-day production testing period of GT &E in which the MOCs would be put into full production

115 and, finally, the Rehosted MOCAS had to be accepted by the government. AEON's 29 December 2006 MOCAS Rehost Project Plan showed that WBS 8/Payment Event 8 was started on 11 October 2006 and, as the Rehosted MOCAS was rejected by the government (findings 104, 117, 119) and never accepted, Payment Event 8 was never completed. AEON's own MOCAS Rehost Project Plan reports that WBS 8 was just 14% complete as of 19 January 2007 (app. supp. R4, tab 172 at 5).

104. On 25 April 2007 CO Gladski issued a Show Cause notice advising AEON that it had "failed to perform ... within the time prescribed" and had not successfully cured the conditions endangering performance which were described in the Cure Notice (finding 95). Specifically, CO Gladski determined that as of 11 April 2007 the Rehosted MOCAS database "still does not perform significant basic system functionalities" and that the government was considering termination of the contract for default. AEON was given 10 days within which to respond. (R4, tab 43; see also, supp. R4, tab 106 at 30; R4, tab 45)

105. On 28 April 2007 DF AS secured funding for CM/SEI to perform an evaluation of the Rehosted MOCAS delivered by AEON (app. supp. R4, tab 234 at 2 of 4, tab 255).

106. On 30 April 2007 the DCMA testers issued their GT&E Final Test Report, a copy of which was provided to the PMO:

During the period between 22 Jan 07 and 10 Apr 07, DCMA prepared conditions and expected results for 455 test conditions:

116 conditions passed/closed, 9 canceled, 9 partially tested, 22 failed, and 299 were not tested; 34% completion rate).

However, during the entire testing period from Oct 06 thru Apr 07, DCMA generated and performed regression testing on the following Test Deficiency Report totals:

411 deficiency reports were issued applicable to the GT &E: 204 Category A > Critical/Fix Immediately 191 Category B >Major/Fix before Test Completion 14 Category C > Fix Before Deployment 1 Category D >New Requirement 1 Category E > Problem Exist in Production

116 At GT &E conclusion, the government continued to experience inconsistent test results. For example, there were still problems with contract close-out.. .. There were also problems with the internal transfer .... An external transfer of contracts was not conducted, since only one database was used for GT &E.

The Mocas Rehost interface to SDW never achieved a successful level of accuracy or dependability. DCMA staff assisted AEon on numerous occasions throughout the testing. However, at GT &E closure, a number of transactions continued to fail the SDW commitment process. The numbers and types of transactional errors varied over the course of GT &E, but full success was never accomplished.

The load process which synchronizes the SDW database with [MOCAS] continued to have errors through the last week of GT &E testing. There were findings of erroneous and corrupted data and incomplete data relationships within SDW. At no time did testers conclude the SDW was in complete synchronization with the Rehost Mocas database.

There were only two attempts made to run QAMIS Monthly cycles. Abends in the QA MIS area occurred in multiple cycles. A fix was eventually promoted for cycles to successfully process, but the DCMA Team was not able to sufficiently test QA-MIS.

During GT&E, there were 36 cycle abends and 9 canceled cycles due to program/JCL problems. The DF AS-TSO office processed nightly cycles and confirmed with respect to cycle abends that problems were not due to data used for testing.

Based on the number of outstanding critical system problems, inconsistent processing results, and continued challenges in completing nightly cycles, DCMA does not certify nor recommend deployment ofMOCASR MUJ MOC G to production.

(Supp. R4, tab 113; tr. 4/835-36)

107. On 4 May 2007 AEON responded to the show cause notice. It's first stated response was that there was no valid basis for termination for default. It further argued in

117 the alternative that, even if grounds for default existed, "they are individually and collectively attributable to causes beyond the control and without the fault or negligence of AEon, and therefore excusable" under FAR 52.249-8(c). (R4, tab 44)

108. Sometime after 4 May 2007 the PMO replied to AEON's response to the show cause notice:

It is the government's position that AEon delivered a rehosted MOCAS system with significant discrepancies between the functionality of the rehosted MOCAS and the as-is MOCAS. Additionally, AEon was unable to increase the maturity level of the system significantly enough during the five and a half month time period following the initial delivery, to demonstrate that they have sufficient competency to complete the rehost effort. The GT &E results and a final inspection of the system found numerous and severe discrepancies that warrant the Government's rejection of the delivered system. It is also the Government's position that AEon did not meet earlier Milestone objectives under the contract to include:

~ Ascertain the functionality of the current, as-is MOCAS ~ Ensure that the rehosted MOCAS has 100% of the functionality of the as-is MOCAS system ~ Perform testing to include unit testing and integration. ~ Perform Project Management ~ Higher Level of Quality Assurance as defined by the ISO 9001 standard.

Based on the GT&E results, AEon did not ensure that the rehosted MOCAS had 100% of the functionality of the as-is MOCAS system. Several processes did not function as they do on the as-is system. Therefore, it can be concluded that they did not adequately perform testing. AEon has admitted in several pieces of correspondence and during the In Process Reviews (IPR) that they limited their unit testing to ensuring that the program could run, not if it would function correctly. They also admitted that they performed only representative

118 testing[ 361 during their integration testing. As a result, they missed the opportunity to test the system as a single product. They also did not perform in accordance with industry standards (e.g. ISO 9001) and best practices. In other words, they did not perform complete unit testing or integration as defined by industry standards and best practices to ensure all program changes were fully tested.

Although AEon failed to perform the tasks prior to GT&E and could not cure the system problems during GT &E, it is more important to note that they do not indicate that they have insight into the magnitude of defects in the system; what might have caused them (e.g. conversion process); and, most importantly, what it would take to resolve them. To date, AEon has not presented a "Get Well" Plan that could be used to move the project forward. A Get Well Plan would identify the method in which AEon could move toward achieving the 100% functionality and provide a means for measuring and monitoring their progress.

Instead they assert that it is the Government's responsibility to perform the required testing and identify the defects in the system. They also assert that it is the Government's responsibility to assist in analyzing the defects. Based on their correspondence and actions during GT &E, they see their responsibility as fixing the defects identified by the Government. Therefore, they have indicated that they do not have ownership of achieving objectives of the contract.

Finally, it is the Government's position that AEon does not have the capability to achieve the contract requirements within a reasonable time frame. With the combination of the number and severity of discrepancies between the rehosted MOCAS and as-is MOCAS, and AEon's lack of method for obtaining the MOCAS Rehost contract's objectives, the Government has no other option but to terminate the contract.

36 "Representative testing" was described by government tester Malthaner as "tak[ing] a handful of data and process[ ing] it through the system [so] you would not necessarily have a full range of what the [actual] data may be" (tr. 5/903).

119 (R4, tab 45 at 2-3; tr. 5/901-07; see also supp. R4, tab 106)

109. A CM/SEI Kick-off meeting was held on 9 May 2007 with representatives of CM/SEI and DFAS PMO (app. supp. R4, tab 234; tr. 7/1166-67). Mr. John Foreman, a chief engineer at CM/SEI, was tasked with forming a team to perform the ITA (tr. 7/1153-54, 1157-58; app. supp. R4, tab 258 at 32). On 11May2007 the MOCAS Rehost ITA Weekly Status stated:

9 May- SEI ITA Kick-off meeting held. SEI presented an [ITA] brief followed by DFAS PMO presenting a MOCAS Rehost Program historical background brief. In the afternoon, DF AS CP Operations provided SEI team with a system demonstration followed by an open discussion between SEI, CP Ops, TSO, DCMA, and PMO, including functional and technical staff involved in the GT&E.

SEI presented 3 concerns: ** DFAS PMO's attempt to limit scope to technical code audit may lead to expectations gap. ** Lack of access to AEon personnel may lead to incomplete/skewed evaluation. ** SEI' s use of an automated code analysis tool may not be sufficient and SEI may require additional technical resources.

PMO and TSO both expressed concern that SEI was still indicating the intention to review/evaluate information/evidence that was not necessary (in our opinion) for the desired technical assessment (i.e. review of the Contract/Mods to determine if AEon met the terms of the Contract, review of the Congressional inquiries, etc.) SEI did respond that their output would provide DF AS with enough technical detail as requested to be able to make an informed program decision.

(App. supp. R4, tab 234 at 1-2) On 10 May 2007 the following guidance was provided by DF AS TSO relative to information to be provided to CM/SEI for use in its performance of the ITA:

Below is guidance when providing SEI with documentation, artifacts, or resources for their ITA. If asked to provide something not covered in one of the lists, please let me know

120 or send it through me or [COR Thrower]. Thank you for your help and assistance.

Documentation/Artifact/Resource allowed list:

* All AEon SLCM document deliverables * All AEon IPRIPSR reports and supplemental notes * All (3) TSO code review evaluation reports * Access to DF AS/DCMA functional/technical staff * AEon RFP proposal * Statement of Work *Access to/copy of PM O's TDR tracking database *Access to/copy of CP Ops' Test Logs database *Access to/copy ofDCMA's Test Logs database * Access to SUPRA/MANTIS DB MS/code * Access to DB2/CICS/COBOL RDBMS/code

Documentation/Artifact/Resource not allowed list: (until justification provided or appropriately sanitized)

*All REA related documents/emails *All Congressional inquiry related documents/emails *All Cure/Show Cause related documents/emails * Access to current AEon management staff * Access to current AEon technical staff * Access to former AEon staff: Mike Krajnak, Jim Conerly *Access to former AEon staff: Phil Cramer, Scott Love, Aaron Martin * Access to AEon' s Test Director database * Original Contract and Contract Mods *Access to AEon's Source Safe project repository * Permission to contact: TMGi, NP Gen, CSC

(App. supp. R4, tab 234 at 3) (Emphasis added) With respect to CM/SEl's concerns quoted above, CM/SEl's Foreman testified that:

When we do an independent technical assessment ... we were trying to be an honest broker, which means that we try to look at as many facets of an issue as we possibly can, because that is the charter of SEI and FFRDC, not to be biased one way or the other, and to tell as much truth as we can possibly find.

121 The concern that was being raised here was that nothing other than -- well, one conversation that we had with folks was them trying to understand that we would be broad and to look at issues beyond just the technical code quality into how would the project move ahead, and continue, and those kinds of things.

And then there was times where DF AS seemed that they only wanted to have us look and work on a code audit. Well, if you want the truth as to the quality of the code, you also have to look at how it was developed, and how the teams work together, and how the government was managing it, and a bunch of other things, especially if you are going to ask the question what do I do with this ....

[T]here was some attempt to restrict access to talking to AEON folks, and when we do an ITA, we typically will try to talk with the government folks, as well as the development contractor, because you have to get a total picture of what is gomg on.

[The restriction on access to individuals and documents] is probably where we started to have some [of] our own concerns about this particular [ITA].

(Tr. 7/1168-70)

110. On 22-24 May 2007 CM/SEI conducted 21 staff interviews and began artifact (i.e. documentation, database design, source code, etc.) review and analysis (app. supp. R4, tabs 240, 258 at 2; tr. 7/1179-80, 1236-39).

Interviews were conducted with AP Operations and DCMA testers, TSO and DCMA technical personnel, PMO and AEon personnel. SEI was provided with requested artifacts, to include copies of the MOCAS As-Is and AEon's rehosted code. Their plan is to perform artifact and code review and

122 analysis over the next several weeks with a proposed report date of30 June 2007.

(App. supp. R4, tab 255) Neither CO Gladski nor CO Gomolak were interviewed nor otherwise contacted by CM/SEI in the course of its performance of the ITA (app. supp. R4, tab 242; tr. 2/303-04, 326-27, 711171).

111. On 25 May 2007 the government issued unilateral Mod. No. P00015, a stop work order for 90 days under FAR 52.242-15 (R4, tab 3 at 926-29, tab 46). The attached letter stated:

As indicated in our May 22, 2007, telephone conversation, a stop-work order is a contractual mechanism for addressing interim contractor status prior to a termination decision.

In that same conversation, I extended an opportunity to AEon for DF AS to consider additional matters prior to making a termination decision.

Given the different positions concerning the reasons for the failure to successfully complete the MoCAS Rehost project, before making a final termination decision DF AS is willing to meet with AEon to explore whether an outcome is possible that avoids a protracted dispute between the parties.

(R4, tab 3 at 926-27, tab 46; tr. 1/139, 2/197-99) On 29 May 2007 AEON acknowledged receipt of the stop work order and "accept[ ed the] offer to host a meeting to discuss the different positions of the parties regarding the status of contract performance and the Government's termination considerations" (R4, tab 47). The only evidence in the record on this subject indicates that the meeting was convened but was not attended by AEON; instead an individual characterized as a lobbyist came to the meeting in AEON's place (tr. 2/180-81).

112. The MOCAS Rehost SEI ITA Weekly Status reported that from 11-15 June 2007:

123 [AEON President and CEO] S.Javid contacted SEI and offered to meet with SEI (also offered D.Overby and J.Conerly). After her meeting, she requested to know the nature of SEI's tasking. SEI concurred with the PMO's direction that she has no right or need to this information and is not to provide any information. They will comply.

(App. supp. R4, tab 255) CM/SEI's Foreman testified that whether or not the contents of an ITA are shared with a contractor is entirely the decision of the agency who engaged CM/SEI's services.

When we do an [ITA] the out-brief goes to the sponsor. It does not go to the contractor or anybody else that is involved. It only goes to the sponsor because they are the ones that paid for it.

.. .I think that everybody kind of knows that the rules are that we are not going to show the out-brief to the contractor, unless the sponsor asks for the contractor to be there.

(Tr. 7/1173-74)

113. On 18 June 2007 the PMO determined that AEON's responses to the government's concerns were inadequate, that AEON had demonstrated its inability to deliver the contractually-required Rehosted MOCAS and recommended to the CO that the contract be terminated for default (tr. 5/1104-07; R4, tab 48).

114. On 16 July 2007 CM/SEI presented its ITA (dated 28 June 2007) in the form of a slide briefing to DFAS (app. supp. R4, tabs 258, 264; tr. 7/1156, 1175-76, 1210). 37 The record contains notes (author not identified) of the briefing and states that representatives from "MOCAS Rehost PMO, DF AS Contracting, DF AS General Council [sic], DFAS Operations, TSO, and DCMA were in attendance" (app. supp. R4, tab 264). CO Gomolak was in attendance at the briefing (tr. 2/327-29, 353). CO Gladski testified he was not aware of, nor present for, the briefing by CM/SEI (tr. 1/143, 2/168-76; app. supp. R4, tab 272). However, the record establishes that CO Gladski was aware of the existence of the CM/SEI briefing no later than 19 July 2007 when he requested a

37 Mr. Foreman testified that a few days before this briefing CM/SEI did an out-brief "for an executive committee" ofDFAS in Washington, DC (tr. 7/1176, 1208-09).

124 "soft" copy; he was informed by COR Hecker at that time that the PMO did not have one and that the PMO had "rejected the content" of the briefing and had asked CM/SEI to redo the briefing without the programmatic, as opposed to the technical, findings (app. supp. R4, tabs 272, 283). According to the PMO:

The goal of the [Rehost] program was to simply get MOCAS on a platform that was maintainable, THEN, enhancements could be incrementally introduced by [the government workforce] [see finding 2]. Judgments on why DoD chose this path [were] not within the scope of our SOW [with CM/SEI].

(App. supp. R4, tab 283 at 3) CM/SEI declined to amend its briefing as it considered both technical and programmatic findings inherent in its ITA process (app. supp. R4, tab 283; tr. 7/1220-22, 1232-34). In its ITA, CM/SEI assumed that DFAS would continue the MOCAS rehost project "in some form" (app. supp. R4, tab 258 at 6-7, 21-28, 31), however, from our review of CM/SEI's findings and recommendations it is apparent that CM/SEI believed that the approach to the project going forward should be significantly different from the approach taken in the existing contract. In particular, CM/SEI stated repeatedly that it believed the government should "follow a risk-managed modernization approach to upgrade MOCAS," that included significant involvement by the government throughout the process, rather than the incremental re-host approach taken in the existing contract (app. supp. R4, tab 258 at 30, tab 264 at 1). In CM/SEI's opinion the hands-off approach taken by the government created a lack of collaboration/cooperation in the creation of the Rehosted MOCAS and, because of this position taken by CM/SEI, it stated that the government contributed to the "current ... mess" (app. supp. R4, tab 258 at 30; tr. 7/1205-06, 1211-15). We find that CM/SEI's technical findings and recommendations regarding whether the Rehosted MOCAS delivered by AEON met contract requirements is relevant. However, we find that CM/SEI's recommended programmatic collaborative approach was very different from the rehost contract and fixed-price, hands-off approach the government had specifically decided to take in the existing contract and the approach that AEON specifically proposed to accept based on what it presented as its experience with exactly the work and terms contained in the contract as awarded (findings 7-8). We therefore find that CM/SEI's recommendations of a different approach going forward are irrelevant to our determination of whether AEON was in default of the terms of the contract it executed and which is now at issue.

115. CM/SEI found in its summary that neither the As-Is MOCAS (referred to as the "Legacy System") nor AEON's Rehosted MOCAS were "ready to move into the 21 51 century" (app. supp. R4, tab 258 at 30). The summary included the following chart showing how the As-Is MOCAS compared to AEON's Rehosted MOCAS and how both

125 systems compared to the average of 70 systems previously tested by CM/SEI using its SQAI tool:

~,....

am8ir~ ... 11 . . . . A'llAlllt .............. ............ hdilr cm·•q 65..5'1. M.O'I. 24..0%

......., lld!paldl!ID!

~ 71lA'lo l:l.3'ti ..7..5'1. 13.,5,;,

33.0'I. 7.0'll. G.S'lt ...O'll. 12.0'll. 51!1FD1!5Qiplil BIE!515 65..7'1. 16,5,; 27.0'll. Jmlliily Caflol 53.3' 20.,5,; X.O'll. Ol!5i!Pt Sinpli;il)' 95..n. '2.5,; SZ.O"A. _ . , Allillllllll llllilllilillillliliil/ 6!l1'1o 225,; 32..0"A. E'l'lllWilDilily 72.4'1. 16.,5,; 35.0'll. POdillililr 71.5'1. 16,5,; 35.5% Dl!!ScliplH mess ~ 16.5'1. ,~

(App. supp. R4, tab 258 at 31; tr. 7/1204-05) The summary further stated in response to the government's specific requests when engaging CM/SEI (finding 94):

Determine whether the MOCAS re-host project is salvageable and maintainable

• Portions of the re-host project may be salvageable but this is not recommended

• The re-host project is not maintainable

Determine if the MOCAS re-host project code is adequately functional and usable

• The current re-host configuration renders it unusable due to the differences between the legacy (hierarchical) database and the new relational database

• This renders the re-host system non-functional in its present form

126 Identify areas of the system that may need re-work

• Re-host code naming conventions, data element usage, displays, error handling, and return code errors require Government intervention to resolve issues in system

• A new Integrated Product Team (IPT) should be created

Determine resources appropriate for completing the MOCAS re-host project and the difficulties that may be encountered

• Depends on the modernization approach used and available human and financial resources

• Resources should include IPT members, such as stakeholders, government and developer contractors

• Improved program office insight and oversight

Estimate how long it will take to complete the MOCAS re-host project

• Dependent on the Program Office following recommended technical approach

• Rough estimates show between 24 and 36 months to achieve a transitioned, operational system

• Create a Program Objective Memorandum (DoD PPBS) for out-year funding and continuing modernization

(App. supp. R4, tab 258 at 29-30; tr. 7/1241-44) Project Manager Castrillo testified:

127 [I]t was mainly a tutorial how it could have been done better .

... [W]e were looking at where do we go from here more so than where had we been, and it didn't really give us any, you know, where do we go from here .... To me it was unfortunately just a bunch of interviews and somebody's opinion as to how things could have been done differently.

I don't think it added much value, I mean it didn't really add any value .

.. .I didn't ask for a program management review, I asked for a technical review.

(Tr. 511108-10, 1114, 1120-21) The record contains notes from the CM/SEI briefing, apparently authored by unidentified government personnel, stating:

~ Key observations made by SEI: • Rehost was not built on a mirror image of Production, limiting AEon' s capability to perform integration testing. The PMO commented on the fact that AEon had control over the configuration of the development environment and could have created the appropriate environment. • AEon did not due [sic] an adequate job of code testing and integration testing at the code level (i.e. between programs). • AEon' s test scripts were inadequate. • Testing was schedule driven and not event completion driven. • There was a lack of exit criteria for each phase. DF AS noted that the contract was event driven and that AEon defined the exit criteria. For each Milestone, AEon certified that they had completed all tasks required. This included a certification that the system was ready

128 to enter into GT &E. The Government could not validate AEon's certification until they went into GT&E. • AEon did not utilize the As-Is to get to know the system and fully build an automated test.

---. [CM/SEI's] Recommendation • [CM/SEI] recommends that Rehost be scrapped and the project restarted from scratch. • Outdated Documentation was sited [sic] as a Programmatic Issue. Documentation should have been done first and reviewed to ensure it met the Stakeholders needs. If done in this sequence the project may have been more successful. [CM/SEI] recommends that if the project is redone, Legacy Documentation should be created first. Data flow, functional flow diagrams would be used to ensure it is recreated on Rehost system. The PMO commented that AEon indicated that this information could have been extracted using their conversion tool. • [CM/SEI] commented that Increment 2 of their approach would give you more bang for the buck. The [first] increment would rehost on a new platform, with some improvements (e.g. normalization) made. • SMEs need to be involved in developing the automated testing.

---. [CM/SEI] indicated that it was possible to continue with the current Rehost code. However, it would require an extensive evaluation and they could not comment on how long it would take.

(App. supp. R4, tab 264) (Received in evidence without objection).

Although the information provided in the slides is interesting, it does not show a true assessment of our options. Instead of indicating why we should not continue (i.e. risks), they simply indicate that we should start over.

129 (App. supp. R4, tab 275) We find CM/SEI's recommended different approach going forward to be of little help in our consideration of whether the Rehosted MOCAS delivered by AEON met the terms of the contract it executed (app. supp. R4, tab 258, see also app. supp. R4, tab 264).

D. Termination for Default and Appeal

116. On 7 August 2007 CO Gladski prepared a Determination & Finding (D&F) in which he reduced to writing his analysis of FAR 49.402-3(f) factors and his ultimate decision to terminate the contract for default (supp. R4, tab 120; tr. 11140-42, 2/292-99). CO Gladski testified he did not consider anything from CM/SEI in reaching his decision to terminate the contract because he never received a report from them 38 and the stop work order was going to expire on 23 August 2007 (tr. 11143, 21166-83; findings 111, 114).

117. On 9 August 2007 CO Gladski issued Mod. No. POOO 16 which terminated the contract for default under FAR 52.249-8, DEFAULT (FIXED-PRICE SUPPLY AND SERVICE) (R4, tab 3 at 930-35, tab 49; tr. 1140-41, 143-45, 2/164-65).

The contract's amended delivery schedule ... required completion of performance through payment event 6 by September 25, 2006, to be followed by a 90-day User Acceptance I [GT &E] period .

... DFAS has paid AEon in full the contract's liquidated performance based payment amounts that AEon would be entitled to for acceptable performance by and through payment event 6 code conversion, documentation and functionality testing events. However, the software converted by AEon failed to pass User Acceptance I GT&E during payment event 7, and AEon failed to adequately correct or cure all of the deficiencies identified in the DF AS Cure Notice. Those failures lead to this default termination ....

38 We note that the last information CO Gladski had, according to the record before us, was that the PMO had rejected the content of the 28 June 2007 CM/SEI report and requested an amended briefing with just the technical findings and recommendations (finding 114).

130 Default termination is justified and appropriate because the rehosted MOCAS failed payment event 7 GT&E user acceptance testing due to clear lack of requisite functionality in critical areas. Under this fixed priced contract, the Government is not required to authorize or fund continued performance under payment event 7, nor is it appropriate to authorize initiation of payment event 8 performance. Performance-based payments through payment event 6 have been liquidated.

I conclude that the performance failure was not beyond the control or without AEon's fault or negligence. Default under event 7 is the determinative issue. AEon has received liquidated payments for performance through payment event 6 ....

After thoughtful consideration of all of the pertinent facts in conjunction with FAR 49.402-3(f), I, the undersigned Contracting Officer, hereby find and determine that AEon has failed to complete the requirements of the MOCAS Rehost contract within the time required by the terms of the contract, failed to successfully cure some items identified in my Cure Notice, and that AEon failed to deliver a Rehosted MOCAS database with the requisite functionality of the MOCAS "as-is" database as prescribed by the SOW.

(R4, tab 49, iii! 2, 3, 9-11; tr. 2/184-86) At the time of the termination for default by CO Gladski, the government had approved AEON's performance-based progress payments in the amount of$12,905,117.22 39 (R4, tab 49; tr. 1/153-54; finding 21). CO Gladski further testified that the performance-based progress payment events/milestones were not subCLINs of CLIN 00001 and that, upon AEON's failure to deliver the contractually required CLIN 00001, the previously liquidated progress payments became unliquidated:

If the contractor failed to deliver, then any of those previous items that I had liquidated, after obtaining legal counsel on this, determined that it didn't matter.

39 The parties do not dispute the amount paid to AEON under the contract.

131 That I would be entitled to recover that if the contractor failed to deliver the full system because I was accepting the CLIN on a whole, and not on a piece basis.

(Tr. 11146, 154-56) As of the close of the record before us there had been no reprocurement of the MOCAS Rehost project and the existing As-Is MOCAS was still in use (tr. 2/232-33, 310, 4/687).

118. In a letter dated 13 August 2007 AEON filed its notice of appeal from the termination for default which was docketed as ASBCA No. 56142 (R4, tab 50).

119. On 9 November 2007, three months after the termination for default, CO Gladski issued a second final decision in which he stated:

2. The contract provided for performance-based payments under "Performance-Based Payments," FAR 52.232-32 (FEB 2002). In the event of default, the contractor is obligated to repay payments that were not liquidated based on conforming delivery item performance. Under this contract, all performance based payments were made on a whole contract basis. FAR 52.232-32( d).

3. DFAS has not been delivered a workable rehosted MOCAS System that contains the same functionality of the present MOCAS System. I have determined that, AEon did not successfully complete contract work defined by CLIN 0001 for which they received payments identified in events #I through #7 as delineated in contract HQ0423-04-C-0003. There has been no acceptance of CLIN 0001. Therefore, demand is hereby made upon The AEon Group, LLC, to pay DFAS the sum of$12,905,l 17.22 which represents all payments made to date by DF AS for contract HQ0423-04-C-0003.

(Supp. R4, tab 122; tr. 11146-47)

120. In a letter dated 15 November 2007 AEON filed its notice of appeal from the government's demand for repayment of alleged unliquidated performance payments which was docketed as ASBCA No. 56251.

121. On 5 March 2009 AEON submitted its REA No. 3 in which it sought compensation in the amount of $1,531,701 for government-caused delays to its

132 performance of contract work from 29 September 2006 through 25 May 2007 (app. supp. R4, tab 285). There is no indication in the record that the government provided any sort of response to REA No. 3 and it is not before us in these appeals.

122. During the government's case-in-chief, counsel for appellant promised that the testimony of various witnesses would be offered in its own case-in-chief to rebut certain of the government's evidence. However, appellant offered no testimony from any individual involved in the preparation of AEON's proposal or AEON's performance of the contract (tr. 6/1139). The single witness offered by AEON in its case-in-chief was CM/SEI's Foreman, the head of the CM/SEI ITA team involved after all performance by AEON had stopped and who had no first-hand knowledge of anything that took place during the actual performance of the MOCAS Rehost contract (tr. 7/1254; findings 94, 109).

DECISION

AEON appeals from the government's termination of its contract for default, asking us to hold that the termination was not justified and to convert it to a termination for the convenience of the government (ASBCA No. 56142). AEON further requests that, even if we uphold the termination for default, we find the government is not entitled to the return of performance-based payments made to AEON in the amount of $12,905,117.23 (ASBCA No. 56251).

I. ASBCA No. 56142-Termination for Default

A termination for default is a type of forfeiture and is strictly construed. Lisbon Contractors, Inc. v. United States, 828 F.2d 759, 764 (Fed. Cir. 1987). The government bears the burden of proving that its termination of AEON's contract was justified under the terms of the contract. Ensil International Corp., ASBCA Nos. 57297, 57445, 12-1 BCA if 34,942 at 171,800. If the government has met its burden, the contractor has the burden of going forward to prove any allegations that its default was due to causes beyond its control or without its fault or negligence. ADT Construction Group, Inc., ASBCA No. 55358, 13 BCA if 35,307 at 173,309.

A. Grounds for Termination for Default

The Default clause of the contract, FAR 52.249-8, FIXED-PRICE SUPPLY AND SERVICE (APR 1984), establishes the possible grounds for a termination for default which include failure to deliver by the contractual due date and failure to make progress so as to endanger timely performance (finding 25). In the 9 August 2007 termination for default, CO Gladski articulated the following reasons' for the termination:

133 After thoughtful consideration of all of the pertinent facts in conjunction with FAR 49.402-3(f), I, the undersigned Contracting Officer, hereby find and determine that AEon has failed to complete the requirements of the MOCAS Rehost contract within the time required by the terms of the contract, failed to successfully cure some items identified in my Cure Notice, and that AEon failed to deliver a Rehosted MOCAS database with the requisite functionality of the MOCAS "as-is" database as prescribed by the SOW.

(Finding 117) In a second final decision dated 9 November 2007, CO Gladski restated his determination that AEON had failed to deliver a contractually-compliant Rehosted MOCAS by the contract delivery date and further demanded that AEON return $12,905, 117 .22 in what he determined to be unliquidated performance-based payments (finding 119).

AEON argues that the government has failed to meet its burden of proof as to the grounds for the termination for default which were articulated in the CO's final decisions and, further, that we cannot consider grounds other than those specifically articulated in the final decisions (app. br. at 5, 49-53). We find AEON's argument that we may not consider the government's allegedly later-articulated basis of failure to make progress to be unavailing for two reasons. First, while the CO's final decisions do not specifically use the term "failure to make progress," they do specifically cite FAR 52.249-8 as the authority under which the termination was made. That clause includes both failure to meet the contract's delivery date and failure to make progress so as to endanger timely performance. Further, the CO's final decision terminating the contract for default specifically articulated that a basis for the default was AEON's failure to "successfully cure some items identified in my [22 March 2007] Cure Notice" (findings 95, 117). A Cure Notice is only required to be issued prior to a termination for failure to make progress. FAR 52.249-6(a)(2). It is not required prior to a termination for failure to make timely delivery. Further, the express language of the Cure Notice states:

If, at the end of the GT &E period, AEon still has failed to deliver a code which meets the functionality requirements contained in the SOW, the Government will have "failure to deliver" as an additional ground for termination for default.

(Finding 95) (Emphasis added) Clearly, the Cure Notice put AEON on notice that the government was considering two bases for termination for default: failure to make progress and failure to deliver by the contractual delivery date.

134 Second, even if the government had not articulated two bases for default termination, it is well-established that an unarticulated basis that is supported by the totality of the circumstances existing at the time of the termination is valid.

Our decisions have consistently approved default terminations where the contracting officer's ground for termination was not sustainable if there was another existing ground for a default termination, regardless of whether that ground was known to the contracting officer at the time of the termination. See, e.g., Kelso v. Kirk Bros. Mech. Contractors, Inc., 16 F.3d 1173, 1175 (Fed. Cir. 1994) ("This court sustains a default termination if justified by the circumstances at the time of termination, regardless of whether the Government originally removed the contractor for another reason."); Joseph Morton Co. v. United States, 757 F.2d 1273, 1277 (Fed. Cir. 1985); Pots Unlimited, Ltd. v. United States, 220 Ct.Cl. 405, 600 F.2d 790, 793 (1979) ("[I]t is settled law that a party can justify a termination if there existed at the time an adequate cause, even ifthen unknown."). Thus, the subjective knowledge of the contracting officer .. .is irrelevant, and the government is not required to establish that the contracting officer conducted the analysis necessary to sustain a default under the alternative theory.

Empire Energy Management Systems, Inc. v. Roche, 362 F.3d 1343, 1357 (Fed. Cir. 2004 ). We will therefore consider the totality of the circumstances existing at the time of the termination in reaching our determination of whether the termination of the MOCAS Rehost contract for default was justified.

The express contract terms unambiguously require that delivery of CLIN 0001, Rehost MOCAS System, began when AEON presented the Rehosted MOCAS system to the government for 90 days of GT&E functionality testing and that delivery was not complete until the end of the second 90-day GT&E period in which the Rehosted MOCAS was put into production and passed the government's production testing. Thereafter, the government had 30 days to accept or reject the Rehosted MOCAS that had been delivered (findings 17, 18). 40 The contract also expressly provided that: "At any time prior to final acceptance, any discrepancy between the functionality of the rehosted MOCAS and the as-is MOCAS, or any other failure to meet the requirements of this solicitation, may be a basis for rejection" (finding 18) (emphasis added). The parties

°CLIN 0003, Repairs, was never exercised (finding 10) so any time allotted to it in the 4

contract is irrelevant to the matters before us.

135 disagree as to the level of completion of the Rehosted MOCAS that was required to be delivered at the beginning of GT &E and what was to take place thereafter.

The government takes the position that, while it expected minor issues of a "cosmetic" (finding 78) nature to arise during GT &E functionality testing, AEON was required to deliver for GT&E the Rehosted MOCAS, fully tested and certified by AEON as fully compliant with the contract requirement of 100% functionality, i.e. that the Rehosted MOCAS delivered for GT&E was to perform exactly like the existing As-Is MOCAS (findings 2, 14-15, 55, 71, 86). The record reflects that, at the time it delivered the Rehosted MOCAS for GT&E, AEON certified it to be a Rehosted MOCAS fully compliant with the contract requirements (findings 77, 89, 93, 115). The government contends that, contrary to AEON's certification, the Rehosted MOCAS delivered for GT &E did not perform exactly like the As-Is MOCAS as defined in the contract (finding 14).

AEON disagrees with the government as to what was required by the contract to be delivered for GT&E. First, despite its written words of certification to compliance with the contract definition of 100% functionality, AEON seized upon its own non-contractual definition of 100% functionality, its counsel even claiming the contract did not define functionality (finding 87). By its own non-contractual definition, AEON argues that the Rehosted MOCAS delivered by AEON for GT&E was 100% functional because the system contained every function category. AEON posits that the presence of a function is all that is required, arguing that there could not be defects in a function if the function did not exist in the system, and that whether a function actually worked is irrelevant (findings 85, 87). The government in its brief analogized AEON's definition of "100% functionality" as follows:

[By AEON's definition], the system did not have to "function" at all. All the parts just had to be present. So, for instance, if the Government had been purchasing an automobile instead of a rehosted MOCAS, it would have "100% functionality" if all of its parts were present, engine, drive train, frame and body, even if it could not start or drive. If a test were performed and indicated the pistons were there but could not be made to go up and down, in accordance with Appellant's arguments, the automobile would still have "100% functionality."

(Gov't hr. at 90)

In direct contrast to appellant's arguments in this regard, the contract includes, as did the Solicitation before it, a lengthy definition of the functionality the Rehosted

136 MOCAS was to possess in order to meet contractual requirements. The contractual definition clearly expresses that the Rehosted MOCAS was to perform exactly like the As-Is MOCAS in every way possible and we have so found. (Finding 14) Further, the record contains ample evidence that AEON understood that this was the definition of functionality to which it was required to perform (findings 7-8, 55, 71). We find AEON's arguments in this appeal to the contrary unpersuasive and reject them.

AEON next argues that, regardless of the definition of functionality, it is unreasonable to find that it was required to deliver a Rehosted MOCAS with 100% functionality at the beginning of GT &E (app. br. at 57-59). It is clear to us from the record that GT&E was a final inspection by the governrnent of the Rehosted MOCAS to assure that it met contract requirements by functioning exactly like the As-Is MOCAS before the system was rolled out and put into production for world-wide use by DF AS, DCMA and other governrnent agencies (see, e.g., findings 4, 5, 18, 79, 100, 101, 106). It follows logically that the Rehosted MOCAS delivered at the beginning of GT &E was to be AEON's final product which was certified by it to fully meet contract requirements. Further supporting the interpretation that the delivered Rehosted MOCAS was to perform at 100% functionality compared to the As-Is MOCAS is the contractual requirement that the final documentation for the Rehosted MOCAS was also to be submitted at the beginning ofGT&E (findings 2, 4, 10, 14, 15, 18, 19, 49, 52-55, 71). AEON's arguments that the contract required it to deliver a less-than-100%-functional Rehosted MOCAS would redefine GT &E to nothing more than a testing/QC exercise prior to AEON's completion of the contract requirements. Pre-GT&E testing and QC were specific contract requirements to be completed by AEON, not the governrnent, and they were to have been completed by AEON prior to delivery of the Rehosted MOCAS. (Id.) Submission of defective items to the governrnent for acceptance as a method of a contractor quality control program is not an acceptable practice. Skip Kirchdorfer, Inc., ASBCA Nos. 32637, 35074, 91-1 BCA ~ 23,380 at 117,314, ajf'd, 944 F.2d 912 (Fed. Cir.) (table), cert. denied, 502 U.S. 1033 (1992).

On the basis of the foregoing, we hold that the Rehosted MOCAS delivered for GT&E was required by the express contract terms to be fully tested and certified by AEON to meet contract requirements, including the contract requirement for 100% functionality such that the Rehosted MOCAS delivered for GT &E by AEON was to perform exactly like the As-Is MOCAS, no better and no worse.

AEON delivered the Rehosted MOCAS to the government for GT&E twice: once in October 2006; and, again in January 2007. On 22 September 2006, just before its initial delivery of the Rehosted MOCAS for GT&E, AEON's "final" PMP stated AEON's understanding and intent that the Rehosted MOCAS:

137 [W]ill have all the functionality, produce the same output and will look, feel and respond to the users exactly as it does today. Therefore the users will not recognize that the system has been touched. In addition, all interfaces will provide the same data in the same format.

(Finding 71) (Emphasis added) On 23 October 2006 AEON delivered the Rehosted MOCAS to the government for GT &E functionality testing and certified that the Rehosted MOCAS met contract requirements (finding 77). As had been made known since before contract award, the As-Is MOCAS was used as the benchmark against which the Rehosted MOCAS was tested (finding 6). After just nine (9) days ofGT&E functionality testing, it was apparent to the government testers, individuals from DF AS and DCMA with many years of As-Is MOCAS experience (finding 80), that the Rehosted MOCAS delivered by AEON did not perform like the As-Is MOCAS and GT&E was suspended (findings 81, 82).

AEON argues that the government had no right to suspend GT &E. The government argues that AEON was in technical default of the contract and that it would have been justified in terminating the contract for default at that time (gov't br. at 92-93). As we have already held, the failure of the Rehosted MOCAS to perform exactly like the As-Is MOCAS was a failure to meet contract requirements and the contract's express terms provided for rejection of the Rehosted MOCAS at any time between delivery and final acceptance that it was determined it did not meet contract requirements (finding 18).

Nevertheless, the government gave AEON the opportunity to continue work on the Rehosted MOCAS to make it perform exactly like the As-Is MOCAS. On 19 January 2007 AEON again delivered the Rehosted MOCAS to the government for GT &E functionality testing and again certified that it met contract requirements (finding 89). The government proceeded to continue performance of GT &E, however, the government testers again experienced numerous failures of the Rehosted MOCAS to perform even basic functions like the As-Is MOCAS. At the conclusion of the full 90-day GT&E functional testing period, the government had only been able to test approximately 46% of one database (identified as the least complex of the three databases (MOCs) contained in the Rehosted MOCAS delivered by AEON (finding 100)) and was never able to perform a full end-to-end test of the system (findings 89-90, 93, 95, 97-102). On this basis, we find unpersuasive AEON' s argument that the number of defects identified at the end of the GT&E period was evidence of the functionality of the entire Rehosted MOCAS (app. br. at 59-65). CO Gladski issued the 25 April 2007 Show Cause Notice advising AEON that it had "failed to perform ... within the time prescribed" and that, as of 11 April 2007, the end of the 90-day GT&E functionality testing period, the Rehosted MOCAS database "still does not perform significant basic system functionalities" (finding 104). The independent evaluation of the Rehosted MOCAS performed by CM/SEI after the

138 Show Cause Notice confirmed that the delivered Rehosted MOCAS was not functional, was not maintainable and was "unusable" (finding 115).

AEON also argues that CO Gladski's decision to terminate the contract was arbitrary and capricious because he did not specifically consider the CM/SEI report (findings 114-16; app. br. at 4-5). As we stated above, in reaching our decision as to the propriety of the termination for default we consider the totality of the circumstances existing at the time of the termination, whether the CO had subjective knowledge of them or not. In this regard:

[W]e are less concerned about the label of the contracting officer's action so long as, in fulfilling his duty, the contracting officer exercised reasoned judgment and did not act arbitrarily ....

"[A] court's review of a default justification does not turn on the contracting officer's subjective beliefs, but rather requires an objective inquiry." McDonnell Douglas XII, 323 F.3d at 1016. In this regard, the facts in the record are sufficient for the court, in a de novo review, to sustain the default termination. See Joseph Morton Co. v. United States, 757 F.2d 1273, 1277 (Fed. Cir. 1985) ("It is settled law that a party can justify a termination if there existed at the time an adequate cause, even ifthen unknown.").

McDonnell Douglas Corp. v. United States, 567 F.3d 1340, 1354-55 (Fed. Cir. 2009). The record before us amply supports the government's decision to terminate the contract on the ground that AEON failed to deliver a Rehosted MOCAS that met contract requirements and we find no evidence to support appellant's allegation that the decision was arbitrary and capricious.

On the basis of the foregoing we find that AEON's failure to deliver for GT&E a Rehosted MOCAS that met contract requirements to perform 100% of the functionality of the As-Is MOCAS constituted a failure to make timely delivery under the contract and we find that the termination of the contract for default was justified on this basis. DayDanyon Corporation, ASBCA No. 57611 et al., 14-1BCAiJ35,507 (no contract-compliant delivery by the due date is primafacie evidence of default). We, therefore, need not reach the additional basis of termination for default for failure to make progress such that timely completion was put out of AEON's reach.

139 B. AEON allegations that the default was without its fault or negligence

Having held that AEON was in default, we now tum to arguments made by AEON in support of its allegation that its default was excused because it was without AEON's fault or negligence (app. br. at 65; FAR 52.249-8(c)). Appellant has the burden of proving that its default was actually caused by its alleged excuses. Beekman Industries, Inc., ASBCA No. 30280, 87-3 BCA ~ 20,118.

1. Defective Specifications

AEON argues that it conducted "adequate," "robust and time-consuming testing" and that there is no evidence that it did otherwise. Yet, it also claims the opposite: that it was unable to do adequate testing due to defective specifications. (App. br. at 53-55, 66-69 41 ) The record does not support appellant's allegations on either count.

The government expressed its concerns that the failure of the Rehosted MOCAS to perform exactly like the As-Is MOCAS was apparently due to inadequate contractually-required testing on AEON's part (findings 47, 81, 93, 108; gov't br. at 65-68). We understand the government's argument to be that, had AEON actually done the testing it claims to have done, AEON should have discovered the same problems during its QA/Test that the government discovered during GT&E; problems that AEON then should have corrected before delivering the Rehosted MOCAS for GT&E and certifying that it met the contract requirement of 100% functionality. We note that nowhere in the record before us does AEON claim, much less actually demonstrate, that the problems discovered by the government during GT &E did not occur when AEON performed its own tests. We must conclude then that, for the depth and breadth of problems encountered in GT &E to have occurred as demonstrated in the record before us, AEON either did not adequately test the Rehosted MOCAS before delivering it or it tested it, experienced problems and, desperate for payment (discussed further below), certified and delivered it for GT &E anyway.

Further, contrary to its argument in this appeal (app. br. at 56), the contemporaneous record shows that when AEON made the internal decision to no longer perform unit testing in June 2005, all indications are that it did so to make up for the extended time taken to convert the code after the TMGi tool failed to perform as anticipated (findings 46, 47, 57, 59). It did not notify the government at that time that it was no longer doing the unit testing which was required by the contract (findings 16, 21, 41, 49, 56) and included by AEON in its own PMP (finding 55). Only later, after requesting an extension of time within which to complete its contractually-required

41 We note that AEON's arguments in this portion of its brief contain relatively sparse supporting citations to the record.

140 QA/Test and responding to the government's query as to the reason for the extension, did AEON take its current position that unit testing was impossible without detailed design specs (app. br. at 55). We find this to be in direct contrast to AEON's own demonstrated understanding on 9 November 2005 when it stated in writing to the government that:

For conversion projects such as MOCAS Rehost there usually are no business or systems requirements and no design or program specifications. Further, the programs are partially or fully converted using a tool.

(Supp. R4, tab 68 at 2) (Emphasis added) Even though AEON expressed its understanding in writing that it was not usual to have design or program specifications in a project such as this one, in the case of the Rehosted MOCAS contract, AEON was provided with a copy of the full As-Is MOCAS, including the full production data existing at the point in time the copy was made, as well as a discovery period so AEON could determine the specific functionality of the As-Is MOCAS in order to replicate it in the Rehosted MOCAS. The specification information AEON now claims was missing was exactly the information that AEON proposed, and the contract required and paid AEON, to discern in the discovery period of the contract (findings 6, 12, 21, 31-35, 108).

We have considered the following: (1) AEON's own expressed understanding in projects such as this that the specifications it now claims were missing were not usually provided, nor apparently were they needed where a conversion tool was used like AEON proposed to and did use here; (2) that AEON was provided with a full copy of the As-Is MOCAS and given time and compensation to fully explore it (findings 3, 10, 12, 14); and, (3) that both AEON (for its QA/Test (findings 16, 55)) and the government (for GT&E (finding 6)) intended to use the As-Is MOCAS as the "benchmark" against which the Rehosted MOCAS would be tested. We find no support for AEON' s argument that performing the contractually-required testing was impossible due to defective specifications.

2. Superior Knowledge

AEON argues that the government possessed two categories of information essential to AEON's performance of the contract work that it did not provide to AEON: documentation in the form of detailed existing specifications; and, the government's test plans (app. br. at 69-70). In order to prevail on a claim of superior knowledge AEON must prove the following elements:

( 1) [It undertook] to perform without vital knowledge of a fact that affects performance costs or duration, (2) the government was aware [it] had no knowledge of and had no

141 reason to obtain such information, (3) any contract specification supplied misled [it] or did not put it on notice to inquire, and (4) the government failed to provide the relevant information.

CAE USA, Inc., ASBCA No. 58006, 13 BCA ii 35,323 at 173,390.

With respect to the first category of alleged superior knowledge (documentation in the form of detailed existing specifications), AEON cites to the testimony of John Sharer that he had been "creating design specification changes on a regular basis for 25 years," from which AEON implies that the government possessed detailed specifications for the As-Is MOCAS and knowingly withheld such specifications as part of the documentation of the As-Is MOCAS misleading AEON as to their existence (app. br. at 69). AEON's argument fails to mention, however, that immediately after the testimony it cited, Mr. Sharer continued upon cross-examination by AEON counsel:

Q And you have an understanding then that the detailed specification for MOCAS are current?

A No, the paperwork is not current, the paperwork for MOCAS is not current. The system is basically over 40 years old, and during that time a lot of the changes that were made and everything, the paperwork on them were lost.

Q Right, you understand that DF AS does the best job it can to update its baseline specification, correct?

A As we make changes we try to baseline what changes we are making, but no, as I am right now we do not have a good set of baseline documentation for the whole MOCAS system.

(Tr. 5/984) Mr. Sharer's testimony is consistent with the record evidence of repeated representations made by the government in the solicitation, contract and during contract performance that the existing documentation for the As-Is MOCAS was incomplete (findings 1, 5, 12, 14, 15), that all documentation in the government's possession was provided to AEON (finding 12), and that AEON understood these conditions and based its proposal upon them (findings 7-8). The fact of incomplete/poor existing documentation was why the government provided, at significant expense, a full production copy of the As-Is MOCAS to AEON (finding 3), paid AEON to perform significant discovery of the As-Is MOCAS (findings 10, 12), and paid AEON to provide documentation for the Rehosted MOCAS (findings 10, 19). We find ample support in the

142 record that AEON was aware at the time of its proposal that the existing documentation of the As-Is MOCAS was not something that could be relied upon (findings 7-8). In Bruce E. Zoeller, ASBCA No. 56578, 13 BCA i! 35,353 at 173,521-22, we held that, where the contractor was aware of the risk when it entered into the contract and where it has "failed to show evidence that the contract specifications misled [it] or did not put [it] on notice to inquire, as required by the superior knowledge doctrine," the contractor will not have met its burden of proof. Likewise, we find here that AEON has not met its burden of proof with respect to the first category of alleged superior knowledge.

The second category of superior knowledge alleged by AEON is that the government withheld its GT &E test plans from AEON. Neither the solicitation nor the contract stated that the test plans would be provided to AEON (finding 20). In fact, AEON was specifically on notice that the government's test plans would not be provided (findings 2, 6). Rather, the contract required AEON to perform its own QA/Test and to develop its own test plan and test scripts (finding 16). AEON proposed to do so with the knowledge that the government's test plans would not be provided (findings 7-8). We therefore find that the government's test plans were not vital knowledge necessary to AEON's performance of the contract work and, therefore, AEON has not met its burden of proof with respect to the second category of alleged superior knowledge.

3. Lack of Good Faith and Fair Dealing

Both parties to a contract have a duty of good faith and fair dealing that neither will conduct themselves in a way that will hinder or delay the contractual performance of the other and failure to fulfill that duty constitutes a breach of contract. Metcalf Construction Co. v. United States, 742 F.3d 984, 991 (Fed. Cir. 2014). However, the implied duty may not "expand a party's contractual duties beyond those in the express contract or create duties inconsistent with the contract's provisions." Id.

AEON alleges that the government failed to meet its duty of good faith and fair dealing in several respects: (1) the government did not provide subject matter experts (SMEs) to assist AEON; (2) the government's suspension ofGT&E resulted in financial hardship for AEON; (3) DCMA was not involved in the contract until GT&E; (4) the government allegedly "reneged on its agreement to restart GT&E" as quickly as AEON wanted; (5) the government "violated" its GT &E test plans by not meeting with AEON regularly during GT&E; ( 6) the government failed to provide to AEON an alleged list of "what works" in the Rehosted MOCAS; and, (7) the CM/SEI report found that the lack of a collaborative approach by the government had contributed to AEON' s failure to deliver a contractually-compliant Rehosted MOCAS (app. br. at 70-76).

Allegations (1) and (3)-AEON's post-hearing brief opens with counsel's accusation that the government "[p]reyed on the inexperience and un-sophistication of

143 a small business performing its first federal Government contract" (app. br. at 1). However, in its proposal AEON held itself out as very experienced in exactly the kind of work sought to be performed under this contract and listed 11 previous contracts, six in detail, including several performed for DFAS (finding 7). Later in contract performance, AEON stated that its employees/subcontractors had more depth of understanding of the MOCAS system than DFAS' own TSO (finding 72). Nevertheless, AEON now complains that the government breached its duty of good faith and fair dealing by not providing AEON with SMEs, especially DCMA SMEs, during contract performance. The record shows, however, that AEON and all other prospective bidders were put on notice that they would not have SMEs available to assist in performance of the contract (finding 6) and neither the solicitation nor the contract contain any representation otherwise. AEON's proposal demonstrated its understanding of this fact, analyzed the risk and included "several million dollars" in its proposal to cover this and other risks it had identified. AEON's proposal also specifically stated that it believed it had made staffing decisions that further minimized this risk. (Finding 8)

Allegations (2) and (4}-AEON claims that the government's suspension of GT &E created financial hardship for it. The first instance of financial difficulty reflected in the record is in the spring of 2006 when AEON missed a payroll and was not paying its subcontractors (finding 62). This was approximately six months before GT&E was started in October 2006 and certainly before GT &E was suspended in November 2006. The weight of the record indicates that AEON's financial troubles originated when its TMGi conversion tool proved to not perform as planned, which impacted AEON's scheduled performance and delayed conversion of the code and unit testing which had a domino effect on later performance milestones and payment events which followed conversion (findings 30, 43, 57). AEON proposed the eight performance-based payment events to provide it with a payment of 12.5% of the contract price for CLIN 0001 (or $1,856, 164.50) approximately once every quarter throughout the original two-year performance period. AEON was originally scheduled to complete Payment Event 6 (code conversion and unit testing) and receive payment at the end of the 5th quarter of performance (approximately July 2005). (Finding 21) However, the record shows that, because of the TMGi issues and related delays, the tasks associated with Payment Event 6 took almost two years and were not reported complete until 11 October 2006 (findings 30, 41-49, 59). The government was not responsible for the TMGi issues and the first time AEON notified the government that AEON's schedule was slipping was in October 2005 (finding 45). The delays associated with the code conversion and any unit testing performed (or not performed) caused AEON to be unable to report completion of Payment Event 6. Without completion of the Milestone/Payment Event, AEON could not seek payment for an extended period of time, during which employees and subcontractors were not paid (findings 51, 58, 62), a situation which prompted the government several times to agree to allow the Milestone/Payment Events to be further subdivided in order to get funding to AEON (findings 49, 63, 65, 70). AEON first delivered the Rehosted

144 MOCAS to the government for GT&E functionality testing in October 2006, certified that the Rehosted MOCAS met contract requirements and requested payment for Payment Event 7A2 (finding 77). However, after just nine (9) days of GT&E functionality testing, the government testers determined that the Rehosted MOCAS delivered by AEON had so many significant problems that GT&E was suspended (findings 77, 81-84 ). Nevertheless, the government gave AEON time to correct the deficiencies in the Rehosted MOCAS and re-certify and re-deliver it when AEON determined it to be ready for GT &E to recommence (findings 84). Upon AEON's notification of readiness in January 2007, we find that the government took a reasonable amount of time to gather the government testers to continue GT&E (findings 88-89). While the record shows that the government took responsibility for 3Yz weeks of delay prior to GT &E (finding 66), the vast majority of the many months of delay described above were attributable to AEON, not the government.

Allegation (5}-AEON's arguments in this regard appear to us to take the position that the GT&E process was somehow an extension of the contract's QA/Test phase to be performed by AEON. In this context, AEON argues that the government should have worked with AEON as a testing partner during GT&E, keeping AEON in constant communication as to the tests run and the results on a daily basis. We disagree. AEON's obligation under the QA/Test phase of the contract was to fully test the Rehosted MOCAS against the As-Is MOCAS to make sure the Rehosted MOCAS functioned just like the As-Is MOCAS. This phase was to be completed prior to AEON certifying that the Rehosted MOCAS met the contract requirement of 100% functionality and delivering the Rehosted MOCAS to the government for GT&E functionality testing by experienced government users ofthe As-Is MOCAS. (Finding 16) GT&E was to be performed solely by the government (finding 18) and we find that any testing done by the government under GT&E was in the nature of a final inspection and was for the government's benefit, not AEON's. Therefore, whether the government followed or did not follow its test plans to the letter, the government had no contractual obligation or duty to AEON in that regard. AEON had no contractual role in the GT&E process except to the extent the government elected to make it aware of any results. We find no contractual obligation on the part of the government to permit AEON to attempt correction during the GT&E period of deficiencies discovered in GT&E. To the extent the government did so, we consider it to be reasonable attempts on the government's part to mitigate the impact of AEON's failure to provide a Rehosted MOCAS that performed exactly like the As-Is MOCAS.

Allegation (6}-The record does not contain the "what works" document referenced by AEON. The first mention of the possible existence of such a document was at the hearing and there was no indication at, prior to or since the hearing that AEON requested such a document in discovery or moved to compel the production of such a document, if it even existed. The record contains ample evidence of significant portions

145 of the Rehosted MOCAS that did not work, resulting in a failure of the Rehosted MOCAS to meet the contractual requirement that it perform exactly like the As-Is MOCAS. Because the contractually-required 100% functionality was not achieved, it is immaterial whether 5% or 50% or some other unidentified percentage less than 100% of it did work.

Allegation (7)-We previously found that CM/SEI's programmatic recommendations as to type of contract and conduct of contract administration were inconsistent with the contract now before us and, therefore, irrelevant to our consideration of the rights and obligations of the parties under the contract executed by AEON (finding 114). The government has broad discretion in determining what type of contract will best promote its interests. American Tel. and Tel. Co. v. United States, 307 F .3d 1374, 1379 (Fed. Cir. 2002). Here the government determined that a firm-fixed-price contract would best suit its goals for the Rehosted MOCAS. AEON submitted a firm-fixed-price proposal to perform the solicited work. One of the hallmarks of a firm-fixed-price contract is that the government is not to interfere with a contractor's performance of the contract work, particularly where there are performance specifications (see findings 3, 47) because the method of performance is a factor in cost incurrence which is at the contractor's risk, not the government's:

[I]n a cost-reimbursement contract, the Government retains the right to minimize its risk by supervising closely the contractor's performance. By performing the ... contract on a fixed-price basis, [the contractor] avoided the costs of more intrusive government supervision. These tradeoffs between Government oversight and contractor autonomy are fundamental to any agreement on price or contract type. Moreover, unlike money, these bargained for rights are not reallocable after performance ....

...The proper time ... to have raised the issues ... was at the time of contract [formation], when effective remedy was available.

American Tel. and Tel., 307 F.3d at 1381. As the Court stated in American Tel. and Tel., we are "not inclined to change the rules and the scoring after the game has been played." Id.

146 On the basis of the foregoing, we find that AEON has failed to meet its burden of proving that its default of the contract is excused by any of its seven (7) allegations of a lack of good faith and fair dealing by the government.

4. Alleged Failure to Upload Fixes

AEON argues that it had corrected every defect identified by the government in GT &E, but the government failed or refused to upload the corrections to the Rehosted MOCAS (app. br. at 76-77). The government counters that it was AEON's responsibility to upload any corrections (gov't br. at 42) and that all corrections were loaded and tested for several weeks after the end of the contractual GT&E period which resulted in even more deficiencies (finding 99; gov't reply br. at 26-28). Regardless of who was responsible for uploading corrections near the end of the GT&E period, the weight of the evidence demonstrates that any corrections made were in response to deficiencies identified by the government in GT&E. Since the government was only able to test approximately 46% of the one least complex database of the three databases in the Rehosted MOCAS, we find that any corrections late in the GT&E period would not have changed the fact that the majority of the Rehosted MOCAS had not been able to be tested in GT&E. We further find that there is no basis in the record before us to believe that the untested majority of the Rehosted MOCAS would have somehow miraculously sailed through GT&E without problems.

C. Summary

On the basis of the foregoing, we find that the government was justified in terminating the contract for default for the failure of AEON to deliver a Rehosted MOCAS that met contract requirements and that AEON has failed to meet its burden of proving that its default was excused.

IL ASBCA No. 56251-DF AS Demand for Alleged Unliquidated Performance-Based Payments

In a second final decision dated 9 November 2007, three months after the termination for default, CO Gladski demanded repayment by AEON of all performance-based payments paid to it under the contract in the amount of $12,905,117.22:

2. The contract provided for performance-based payments under "Performance-Based Payment," FAR 52.232-32 (FEB 2002). In the event of default, the contractor is obligated to repay payments that were not liquidated based on conforming delivery item performance. Under this contract, all

147 performance based payments were made on a whole contract basis. FAR 52.232-32(d).

3. DF AS has not been delivered a workable rehosted MOCAS System that contains the same functionality of the present MOCAS System. I have determined that, AEon did not successfully complete contract work defined by CLIN 0001 for which they received payments identified in events # 1 through #7 as delineated in contract HQ0423-04-C-0003. There has been no acceptance of CLIN 0001. Therefore, demand is hereby made upon the AEon Group, LLC, to pay DFAS the sum of $12,905,117.22 which represents all payments made to date by DF AS for contract HQ0423-04-C-0003.

(Finding 119) AEON appeals from the government's demand for the return of all performance-based payments made under the contract. The government has the burden of proving its claim for repayment of alleged unliquidated performance-based payments. Commissioning Solutions Global, LLC, ASBCA Nos. 57429, 57494, 13 BCA ii 35,355 at 173,527.

When a contract is terminated for default, FAR 49.402-2(a) provides that: "the Government is not liable for the contractor's costs on undelivered work and is entitled to the repayment of advance and progress payments, if any, applicable to that work." The Rehosted MOCAS contract provided for advance payments in the form of performance-based payments as proposed by AEON (finding 21). Further, performance-based payments are the preferred method of contract financing. They are "contract financing payments that are not payment for accepted items," and are "fully recoverable, in the same manner as progress payments, in the event of default" (finding 23). FAR 52.232-320) provides that "[b]ecause performance-based payments represent the accomplishment of milestones and not the achievement of CLINs, the Government may demand that the Contractor •repay to the Government the amount of unliquidated-performance[-]based payments"' (app. br. at 78). What the parties dispute is whether the performance-based payments made to AEON were liquidated or unliquidated.

It is the government's position that none of the performance-based payments made to AEON were liquidated because all performance-based payments were made to AEON on a whole contract basis given that CLIN 0001, the Rehosted MOCAS, was the single priced deliverable in the contract (gov't br. at 22-23, 31, 101-07). AEON argues that the performance-based payments made to it were made on a deliverable item basis and were liquidated when paid (app. br. at 80).

148 The FAR defines deliverable items for the purpose of performance-based payments as:

Financing payments to be made on a deliverable item basis are applicable to a specific individual deliverable item. (A deliverable item for these purposes is a separate item with a distinct unit price. Thus, a contract line item for 10 airplanes, with a unit price of $1,000,000 each, has 10 deliverable items-the separate planes. A contract line item for 1 lot of 10 airplanes, with a lot price of $10,000,000 has only one deliverable item-the lot.)

(Finding 23) The MOCAS Rehost contract contained one deliverable, CLIN 0001, with one price. There was no contractual basis for delivery or acceptance of something less than the complete CLIN 0001 (finding 10). Further, the performance-based payments were based on the total contract price for CLIN 0001 which accounted for all but $50,000 (for a non-deliverable CLIN for government-ordered travel) of the $14,849,316.00 contract price. They did not include payment for any tasks other than those identified with CLIN 0001. (Finding 21) Nevertheless, AEON argues that the enumerated tasks associated with the Milestones/Payment Events (see findings 21, 49) were separate deliverables, and therefore the payments were made on a deliverable item basis (app. br. at 77-84). We cannot agree as there was no contractual delivery date, nor contract price associated with the various Milestones/Payment Events. On the basis of the foregoing, we find that the performance-based payments were made on a whole contract basis.

The contract provided that if the performance-based payments were made on a whole contract basis, liquidation was to be by either predesignated liquidation amounts or a liquidation percentage (finding 22). It is undisputed that the contract contained no liquidation schedule (finding 21 ), nor do we find any mention of liquidation anywhere in the solicitation, AEON's proposal or the contract and its modifications. The government argues that no liquidation schedule was required because there was only one deliverable, one delivery date and one item to be accepted or rejected, so there was no basis for liquidation prior to the government's acceptance of CLIN 0001. (Gov't reply br. at 38-42) AEON argues that, in the absence of a liquidation schedule, we must find that, as each performance-based payment was made, there was a commensurate amount of liquidation (app. br. at 79-80). The contract, however, provided in FAR 52.232-32(c)(3) that: "[t]he approval by the [CO] of a request for performance-based payment does not constitute an acceptance by the Government and does not excuse the Contractor from performance of obligations under this contract" (finding 22). Given the absence of something in the contract to demonstrate a meeting of the minds of the parties on the

149 subject of sequenced liquidation as argued by AEON, we find that the only reasonable interpretation is that the payments would not be liquidated until the one deliverable was accepted by the government.

AEON also points out that, in the first CO's final decision terminating the contract for default, CO Gladski stated multiple times that the payments made under the contract were liquidated; but, in the second final decision demanding the return of the payments, CO Gladski specifically stated they were not liquidated. Given the inconsistency, AEON argues that the government should be bound by the first final decision. It is well-established that our findings and determinations are de nova. England v. Sherman R. Smoot Corp., 388 F.3d 844 (Fed. Cir. 2004); Wilner v. United States, 24 F.3d 1397, 1402 (Fed. Cir. 1994) (en bane); Assurance Co. v. United States, 813 F.2d 1202, 1206 (Fed. Cir. 1987). We reject AEON's argument that, presented with the CO's inconsistent determinations of liquidation, that it may pick and choose the one determination it likes.

We are also not persuaded by AEON's final argument that the government is not entitled to the return of performance-based payments made to AEON prior to 9 January 2006 because the release language contained in Mod. No. P00006 closed the door on any claims by either party based on events that occurred prior to that date (app. br. at 83). We have found that the liquidation or non-liquidation of the performance-based payments was dependent upon whether or not the government accepted CLIN 0001. Under the contract, acceptance could not take place prior to the performance of 180 days of GT &E (finding 18), which could not have occurred prior to 90 days after the 10 April 2007 end of the 90-day GT&E functional testing period (findings 18, 89, 99), or 21July2007. However, the Rehosted MOCAS, CLIN 0001, delivered by AEON for GT&E failed to pass the 90 days of GT&E functionality testing and there was no acceptance of CLIN 0001. We find that the earliest possible date the government knew it was not going to accept CLIN 0001, and the performance-based payments were unliquidated, was 10 April 2007. This was the event upon which the government's claim of repayment of performance-based payments was based and it did not occur prior to 9 January 2006. Therefore, the release language in Mod. No. P00006 is irrelevant to the government's claim in ASBCA No. 56251.

On the basis of the foregoing we find that the performance-based payments made to AEON during contract performance were made on a whole contract basis and would be liquidated only upon acceptance of CLIN 0001 by the government. As AEON' s delivery of a Rehosted MOCAS, CLIN 0001, was rejected by the government and there was no acceptance, the government was entitled to demand repayment from AEON of unliquidated performance-based payments in the amount of $12,905, 117 .22.

150 CONCLUSION

AEON's appeal from the termination for default is denied (ASBCA No. 56142). AEON's appeal from the government's demand for repayment ofunliquidated performance-based payments in the amount of $12,905,117.22 is also denied (ASBCA No. 56251).

Dated: 6 August 2014

Adminis ative Judge Armed ervices Board of Contract Appeals

I concur I concur

&MARK~N. ~ ·--~-~ f:f~ -\. . . .JR.Jrf~+ -+- -/1- STEMP~LE~R~ ____ . . +- --... __ MONROE E. FREEMAN, Administrative Judge Administrative Judge Acting Chairman Acting Vice Chairman Armed Services Board Armed Services Board of Contract Appeals of Contract Appeals

I certify that the foregoing is a true copy of the Opinion and Decision of the Armed Services Board of Contract Appeals in ASBCA Nos. 56142, 56251, Appeals of AEON Group, LLC, rendered in conformance with the Board's Charter.

Dated:

JEFFREY D. GARDIN Recorder, Armed Services Board of Contract Appeals