Court Opinion

ID: 2734461
Source: CourtListenerOpinion
Date Created: 2014-09-19 01:21:19.208967+00
Date Added: 2024-06-11T09:46:15.072688
License: Public Domain

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 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

                                            151