----------------------------------- -----------------------------------
  Financial Management Line of        
  Business                            

  ----------------------------------- -----------------------------------

Migration Planning Guidance (Version 1)

Section 4.1 Project Schedule Overview

This section provides an overview for the migration Microsoft Project
Schedule template in Section 4.2. It includes an explanation of the
purpose and tasks within each phase and their dependencies. The tasks
and timelines will vary for various phases depending on the complexity
of business process changes and the extent of system customizations.

Table of Contents

**[Introduction to Project Scheduling
[1](#introduction-to-project-scheduling)]{.underline}**

Earned Value Management [1](#earned-value-management)

Additional Resources [2](#additional-resources)

Overview of the Project Schedule Template
[2](#overview-of-the-project-schedule-template)

Scope of the Project Schedule Template
[2](#scope-of-the-project-schedule-template)

Assumptions of the Project Schedule Template
[2](#assumptions-of-the-project-schedule-template)

Additional Notes [4](#additional-notes)

Notes regarding specific phases in the template
[4](#notes-regarding-specific-phases-in-the-template)

Notes regarding the overall template
[4](#notes-regarding-the-overall-template)

Organization of the Microsoft Project Schedule
[5](#organization-of-the-microsoft-project-schedule)

Description of the Phases [6](#description-of-the-phases)

Project Initiation Phase [8](#project-initiation-phase)

Purpose [8](#purpose)

Assumptions [8](#assumptions)

Tasks [9](#tasks)

Concept of Operations Phase [9](#concept-of-operations-phase)

Define Current Environment Sub-Phase
[10](#define-current-environment-sub-phase)

Purpose [10](#purpose-1)

Tasks and Dependencies [10](#tasks-and-dependencies)

Requirements Analysis Sub-Phase [11](#requirements-analysis-sub-phase)

Purpose [11](#purpose-2)

Assumptions [11](#assumptions-1)

Tasks and Dependencies [11](#tasks-and-dependencies-1)

Design Phase [12](#design-phase)

Design/Change Specification Development Sub-Phase
[13](#designchange-specification-development-sub-phase)

Purpose [13](#purpose-3)

Tasks and Dependencies [13](#tasks-and-dependencies-2)

Test Plan Development Sub-Phase [13](#test-plan-development-sub-phase)

Purpose [13](#purpose-4)

Tasks and Dependencies [13](#tasks-and-dependencies-3)

Configuration Approach Development Sub-Phase
[14](#configuration-approach-development-sub-phase)

Purpose [14](#purpose-5)

Tasks and Dependencies [14](#tasks-and-dependencies-4)

Development Phase [14](#development-phase)

Technical Setup Sub-Phase [15](#technical-setup-sub-phase)

Coding Sub-Phase [15](#coding-sub-phase)

Unit Testing Sub-Phase [15](#unit-testing-sub-phase)

Purpose [15](#purpose-6)

Tasks and Dependencies [15](#tasks-and-dependencies-5)

Testing Phase [16](#testing-phase)

Testing Environment Setup Sub-Phase
[17](#testing-environment-setup-sub-phase)

Purpose [17](#purpose-7)

Tasks and Dependencies [17](#tasks-and-dependencies-6)

System Testing/Business Process Testing Sub-Phase
[18](#system-testingbusiness-process-testing-sub-phase)

Purpose [18](#purpose-8)

Tasks and Dependencies [18](#tasks-and-dependencies-7)

Integration/End-to-End Testing Sub-Phase
[18](#integrationend-to-end-testing-sub-phase)

Purpose [18](#purpose-9)

Tasks and Dependencies [18](#tasks-and-dependencies-8)

System Performance Testing (Load Testing) Sub-Phase
[18](#system-performance-testing-load-testing-sub-phase)

Purpose [18](#purpose-10)

Tasks and Dependencies [19](#tasks-and-dependencies-9)

Regression Testing Sub-Phase [19](#regression-testing-sub-phase)

Purpose [19](#purpose-11)

Tasks and Dependencies [19](#tasks-and-dependencies-10)

Conversion Testing Sub-Phase [20](#conversion-testing-sub-phase)

Purpose [20](#purpose-12)

Assumptions [20](#assumptions-2)

Tasks and Dependencies [20](#tasks-and-dependencies-11)

User Acceptance Testing (UAT) Sub-Phase
[21](#user-acceptance-testing-uat-sub-phase)

Purpose [21](#purpose-13)

Tasks and Dependencies [21](#tasks-and-dependencies-12)

Develop User and Training Documents Phase
[21](#develop-user-and-training-documents-phase)

Purpose [21](#purpose-14)

Tasks and Dependencies [21](#tasks-and-dependencies-13)

End User Training Phase [22](#end-user-training-phase)

Training Plan Development Sub-Phase
[22](#training-plan-development-sub-phase)

Purpose [22](#purpose-15)

Tasks and Dependencies [22](#tasks-and-dependencies-14)

Training Logistics Sub-Phase [22](#training-logistics-sub-phase)

Purpose [22](#purpose-16)

Tasks and Dependencies [22](#tasks-and-dependencies-15)

Conduct Training Sub-Phase [23](#conduct-training-sub-phase)

Implementation Phase [23](#implementation-phase)

Migration Planning Sub-Phase [23](#migration-planning-sub-phase)

Purpose [23](#purpose-17)

Tasks and Dependencies [23](#tasks-and-dependencies-16)

Migration Dry-Run Testing Sub-Phase
[23](#migration-dry-run-testing-sub-phase)

Purpose [23](#purpose-18)

Tasks and Dependencies [24](#tasks-and-dependencies-17)

Production Software Cutover Sub-Phase
[24](#production-software-cutover-sub-phase)

Purpose [24](#purpose-19)

Tasks and Dependencies [24](#tasks-and-dependencies-18)

Production Data Conversion Sub-Phase
[24](#production-data-conversion-sub-phase)

Purpose [24](#purpose-20)

Tasks and Dependencies [24](#tasks-and-dependencies-19)

Bring up New Financial System Sub-Phase
[25](#bring-up-new-financial-system-sub-phase)

Migration/Implementation Complete Sub-Phase
[25](#migrationimplementation-complete-sub-phase)

Independent Verification and Validation (IV&V) Phase
[25](#independent-verification-and-validation-ivv-phase)

Migration Checklists [27](#migration-checklists)

1\. Milestone Checklist [27](#milestone-checklist)

2\. Technical Migration Checklist [27](#technical-migration-checklist)

3\. Detailed Implementation Checklists
[27](#detailed-implementation-checklists)

4\. Conversion Checklist [27](#conversion-checklist)

5\. Verification Checklist [28](#verification-checklist)

  --------- -------------------------------------------------------------
  Section   Project Schedule Overview

  4.1       
  --------- -------------------------------------------------------------

This section provides an overview for the migration Microsoft Project
Schedule template in Section 4.2. It includes an explanation of the
purpose and tasks within each phase and their dependencies. The tasks
and timelines will vary for various phases depending on the complexity
of business process changes and the extent of system customizations.

# Introduction to Project Scheduling

Comprehensive project scheduling is critical to the success of a
migration effort, regardless of the scale or complexity of the migration
effort, agency, or the agency's business processes. A comprehensive
project schedule provides the overall project timeline, tasks and
deliverables, dependencies, resources, and milestones. Migrating
agencies and shared service providers (SSPs) can use the project
schedule to communicate with stakeholders, guide their work efforts, and
to manage and control the project execution. The migrating agency and
the SSP should have a disciplined process for managing the systems
migration effort to focus their efforts and reduce risk. It is expected
that project schedules be reasonable and integrated and that both the
migrating agency and the SSP sign-off on the project schedules.

## Earned Value Management

Earned value management (EVM) should be used for implementation and
migration projects to help evaluate and control project risk. EVM is a
management methodology used to objectively measure a project's
performance against schedule and budget (also referred to as cost) by
evaluating variances in dollar value.[^1] Resources for EVM include, but
are not limited to, the Project Management Institute[^2], the Office of
the Under Secretary of Defense for Acquisition, Technology &
Logistics[^3], and the Defense Acquisition University[^4], and the
Office of Management and Budget[^5]. Please also refer to *FAR Case
2004-019, Earned Value Management Systems - Final Rule*[^6].

In addition, an extension to EVM has been emerging, called earned
schedule (ES). ES can be used in conjunction with EVM and measures a
project's performance against schedule and budget by evaluating
variances in time.[^7]

## Additional Resources

The content of this sample project schedule template is based upon best
practice methodologies and lessons learned. Additional resources for
project scheduling include the Financial Systems Integration Office
(FSIO)[^8], the U.S. General Accounting Office (GAO), the Institute of
Electrical and Electronics Engineers (IEEE)[^9], the Project Management
Institute (PMI)[^10], and the Software Engineering Institute (SEI)[^11].

# Overview of the Project Schedule Template

## Scope of the Project Schedule Template 

The scope of this project schedule template includes the activities
*after* the migrating agency has completed its source selection process
and signed a contract with their service provider to migrate their
system to a SSP.

## Assumptions of the Project Schedule Template

The tasks and timelines provided in this migration project schedule
template are based on the following assumptions:

-   The requirements and business processes of the migrating agencies
    are relatively complex.

-   A single migration will occur. The migration will not be phased or
    require parallel operations[^12]. There are numerous migration
    strategies that migrating agencies should consider when migrating to
    an SSP. These strategies include:

-   A single implementation strategy in which the entire organization is
    migrated at once;

-   The phased implementation strategy in which a subset of functions
    for an entire organization are migrated and evaluated before
    migrating the next subset;

-   The staggered implementation strategy in which a portion of the
    organization is migrated to the new system in full and acts as a
    pilot before migrating the entire organization.

    Each agency should assess the pros and cons associated with each
    implementation strategy, keeping in mind the specific requirements
    and needs of their agency, and adapt the project schedule template
    to meet the alternative that best meets their needs with the least
    amount of risk.

-   The gap analysis identifies:

-   A need to modify business processes to the best practices identified
    by the SSP; or

-   A need to perform changes to software and/or develop new software.
    However, OMB does not encourage customization of the financial
    management software.

-   The migration has a "go-live" date of October 1, with user training
    continuing to occur after the go-live date.

-   Each written deliverable includes the delivery of a
    [single]{.underline} draft document that is discussed in sufficient
    detail during a joint review by the service provider and the
    migrating agency such as not to require subsequent drafts, but will
    result in a final document.

-   The SSP will obtain sign-off from the migrating agency for all final
    deliverables.

## Additional Notes

The following notes should be taken into consideration as each agency
customizes its project schedule to meet the specific needs of its
migration:

### Notes regarding specific phases in the template

-   The project schedule template places heavy emphasis on Requirements
    Analysis and Gap Analysis phases. Clear requirements are a necessary
    component to any successful system migration effort and are the
    foundation for business process (re-)engineering, system design,
    development, *and* implementation.

-   The template assumes that a Development Phase is necessary. It is
    assumed that the SSP may perform new development, customizations, or
    extensions to the existing system to accommodate a mission critical
    requirement of the migrating agency that cannot be met by the SSP's
    system or a reengineering of the migrating agency's business
    processes, such as integration with agency-specific feeder systems.
    This phase will need to be removed or modified based on the specific
    requirements of the agency.

-   The proposed timelines for the software development life cycle
    (SDLC) will vary depending on the degree of system customizations
    and/or changes necessary, the size of the agency, and the complexity
    of the agencies current systems and processes. Furthermore, if the
    migrating agencies identify new or missing requirements during
    subsequent phases of the SDLC, the migrating agency and SSP must
    meet to determine cost and schedule impacts.

-   The project schedule template places a heavy emphasis on testing
    throughout the SDLC. There is significant risk that defects or
    missing requirements will not be detected until after the migration
    if comprehensive testing is not conducted.

### Notes regarding the overall template

-   The template does not indicate the resources that must be assigned
    in order to perform the work. Resource planning must accompany the
    development of the project schedule and should be based upon the
    complexity and scope of the migration.

-   The template mentions a risk plan as a project management component,
    but does not detail specific project risk management activities.
    Project risk management includes risk planning, identification,
    analysis, response planning and monitoring and control. To be
    successful, each project must address the management of risk
    proactively and consistently throughout the project lifecycle.

-   The template may require additional levels of detail beyond what is
    provided. For example, each sub-phase under the Concept of
    Operations might be further delineated by business function (i.e.
    Accounts Payable, Accounts Receivable, Funds Management, etc.); or
    phases within the systems development life cycle (SDLC) may be
    further delineated by software.

## Organization of the Microsoft Project Schedule

The columns shown in the Microsoft Project Schedule are as follows:

-   ID -- an automatically-assigned, unique number that indicates the
    order of a task relative to other tasks in the project schedule.

-    -- small icons that represent information for a task or resource.
    The most common icon is the note icon () which indicates that the
    task, resource, or assignment has a note attached to it.

-   WBS -- the work breakdown structure (WBS) is a hierarchical outline
    of a project schedule. A unique code exists for each task, and
    represents the task's position within the hierarchical outline. This
    particular plan includes six WBS levels.

-   Level 1 represents the overall FMLoB Migration

-   Level 2 represents a phase

-   Level 3 represents a sub-phase within a phase

-   Level 4 through 6 represent either task groupings or specific tasks

-   Task Name -- the name of the task

-   Duration -- the number of work days a task is anticipated to require
    for completion. Calculated as the number of work days between the
    start date and the finish date.

-   Start -- the date work is scheduled to begin

-   Finish -- the date work is scheduled to be completed

-   Predecessors -- the task ID number(s) upon which a task depends
    before it can be started or finished.

# Description of the Phases

The following table identifies each of the phases, sub-phases and core
deliverables included in the project schedule. A description is provided
for each phase and sub-phase. The phases for the project schedule
include:

+-----------------+----------------------------+-----------------------+
| **Phase**       | **Sub-Phase**              | **Core Deliverables / |
|                 |                            | Activities**          |
+=================+============================+=======================+
| **Project       |                            | -   Project           |
| Initiation      |                            |     Management Plan   |
| Phase**         |                            |                       |
+-----------------+----------------------------+-----------------------+
| **Concept of    | Define Current Environment | -   "As-Is" Analysis  |
| Operations      | Sub-Phase                  |     and Documentation |
| Phase**         |                            |                       |
+-----------------+----------------------------+-----------------------+
|                 | Requirements Analysis      | -   "To-Be" Analysis  |
|                 | Sub-Phase (Includes        |     and Documentation |
|                 | requirements gathering and |                       |
|                 | gap analysis activities)   | ```{=html}            |
|                 |                            | <!-- -->              |
|                 |                            | ```                   |
|                 |                            | -   Requirements      |
|                 |                            |     Definition        |
|                 |                            |                       |
|                 |                            | -   Enterprise        |
|                 |                            |     Architecture      |
|                 |                            |                       |
|                 |                            | ```{=html}            |
|                 |                            | <!-- -->              |
|                 |                            | ```                   |
|                 |                            | -   Gap Analysis      |
|                 |                            |                       |
|                 |                            | ```{=html}            |
|                 |                            | <!-- -->              |
|                 |                            | ```                   |
|                 |                            | -   Documented gaps   |
|                 |                            |     between SSP       |
|                 |                            |     systems and       |
|                 |                            |     processes and     |
|                 |                            |     current agency's  |
|                 |                            |     existing          |
|                 |                            |     operations        |
|                 |                            |                       |
|                 |                            | -   Documented        |
|                 |                            |     proposed          |
|                 |                            |     configuration,    |
|                 |                            |     software, and     |
|                 |                            |     business          |
|                 |                            |     processes changes |
|                 |                            |     to mitigate gaps  |
|                 |                            |                       |
|                 |                            | -   Documented impact |
|                 |                            |     of changes to     |
|                 |                            |     migrating agency  |
+-----------------+----------------------------+-----------------------+
| **Design        | Design/Change              | -   Functional        |
| Phase**         | Specification Development  |     Architecture      |
|                 | Sub-Phase                  |                       |
|                 |                            | -   System            |
|                 |                            |     Architecture      |
|                 |                            |                       |
|                 |                            | -   Data Structures   |
|                 |                            |                       |
|                 |                            | -   Data conversion   |
|                 |                            |     process           |
|                 |                            |     documentation     |
|                 |                            |                       |
|                 |                            | -   Data Conversion   |
|                 |                            |     Jobs              |
|                 |                            |                       |
|                 |                            | -   Data Cleansing    |
|                 |                            |     Plan              |
|                 |                            |                       |
|                 |                            | -   Application       |
|                 |                            |     Software          |
|                 |                            |                       |
|                 |                            | -   System Interfaces |
|                 |                            |                       |
|                 |                            | -   Job Streams       |
|                 |                            |                       |
|                 |                            | -   Reports           |
+-----------------+----------------------------+-----------------------+
|                 | Test Plan Development      | -   High level test   |
|                 | Sub-Phase                  |     plans including:  |
|                 |                            |                       |
|                 |                            | ```{=html}            |
|                 |                            | <!-- -->              |
|                 |                            | ```                   |
|                 |                            | -   Unit              |
|                 |                            |                       |
|                 |                            | -   System/business   |
|                 |                            |     process           |
|                 |                            |                       |
|                 |                            | -   Integration /     |
|                 |                            |     end-to-end        |
|                 |                            |                       |
|                 |                            | -   System            |
|                 |                            |     performance       |
|                 |                            |     (load)            |
|                 |                            |                       |
|                 |                            | -   Regression        |
|                 |                            |                       |
|                 |                            | -   Conversion        |
|                 |                            |                       |
|                 |                            | -   User acceptance   |
+-----------------+----------------------------+-----------------------+
|                 | Configuration Approach     | -   Configuration     |
|                 | Development Sub-Phase      |     Management Plan   |
|                 |                            |                       |
|                 |                            | -   System/Data       |
|                 |                            |     Configuration     |
|                 |                            |     Document          |
|                 |                            |                       |
|                 |                            | -   System Security   |
|                 |                            |     Plan              |
+-----------------+----------------------------+-----------------------+
| **Development** | Technical Setup Sub-Phase  | -   Hardware/software |
| **Phase**       |                            |     procured, loaded, |
|                 |                            |     configured,       |
|                 |                            |     tuned, and tested |
+-----------------+----------------------------+-----------------------+
|                 | Coding Sub-Phase           | -   Development of    |
|                 |                            |     any custom        |
|                 |                            |     interfaces,       |
|                 |                            |     reports, etc      |
+-----------------+----------------------------+-----------------------+
|                 | Unit Testing Sub-Phase     | -   Final Test        |
|                 |                            |     Scripts and       |
|                 |                            |     Results           |
+-----------------+----------------------------+-----------------------+
| **Testing       | Testing Environment Setup  | -   Agency Test Data  |
| Phase**         | Sub-Phase                  |                       |
|                 |                            | -   Testing Instance  |
|                 |                            |     prepared          |
+-----------------+----------------------------+-----------------------+
|                 | System Testing/Business    | -   Final System      |
|                 | Process Testing Sub-Phase  |     Performance Test  |
|                 |                            |     Scripts and       |
|                 |                            |     Results           |
+-----------------+----------------------------+-----------------------+
|                 | Integration End-to-End     | -   Final             |
|                 | Testing Sub-Phase          |                       |
|                 |                            |    Integration/End-to |
|                 |                            |     End Test Scripts  |
|                 |                            |     and Results       |
+-----------------+----------------------------+-----------------------+
|                 | System Performance Testing | -   Final System      |
|                 | (Load Testing)Sub-Phase    |     Performance Test  |
|                 |                            |     Scripts and       |
|                 |                            |     Results           |
+-----------------+----------------------------+-----------------------+
|                 | Regression Testing         | -   Final Regression  |
|                 | Sub-Phase                  |     Test Scripts and  |
|                 |                            |     Results           |
+-----------------+----------------------------+-----------------------+
|                 | Conversion Testing         | -   Mock Conversion   |
|                 | Sub-Phase                  |     Test Scripts,     |
|                 |                            |     Checklist and     |
|                 |                            |     Results           |
|                 |                            |                       |
|                 |                            | -   Data Cleansing    |
+-----------------+----------------------------+-----------------------+
|                 | User Acceptance Testing    | -   Final UAT Test    |
|                 | (UAT) Sub-Phase            |     scripts, results  |
|                 |                            |     and resolved      |
|                 |                            |     issues            |
+-----------------+----------------------------+-----------------------+
| **Develop User  | Draft and Final            | -   User              |
| and Training    | Documentation Sub-Phase    |     Documentation     |
| Documents       |                            |                       |
| Phase**         |                            | -   Training          |
|                 |                            |     Materials         |
|                 |                            |                       |
|                 |                            | -   Standard          |
|                 |                            |     Operating         |
|                 |                            |     Procedures        |
+-----------------+----------------------------+-----------------------+
| **End User      | Training Plan Development  | -   Training Plan     |
| Training        | Sub-Phase                  |                       |
| Phase**         |                            |                       |
+-----------------+----------------------------+-----------------------+
|                 | Training Logistics         | -   Training Schedule |
|                 | Sub-Phase                  |                       |
+-----------------+----------------------------+-----------------------+
|                 | Conduct Training Sub-Phase | -   Training          |
|                 |                            |     Curriculum        |
+-----------------+----------------------------+-----------------------+
| *               | Migration Planning         | -   Migration Plan    |
| *Implementation | Sub-Phase                  |                       |
| Phase**         |                            | -   Migration         |
|                 |                            |     Checklist         |
+-----------------+----------------------------+-----------------------+
|                 | Migration Dry-Run Testing  | -   Migration Dry-Run |
|                 | Sub-Phase                  |     results           |
+-----------------+----------------------------+-----------------------+
|                 | Production Software        | -   Software Cutover  |
|                 | Cutover Sub-Phase          |     Checklist         |
+-----------------+----------------------------+-----------------------+
|                 | Production Data            | -   Conversion        |
|                 | Conversation Sub-Phase     |     Reconciliation    |
|                 |                            |     Results           |
+-----------------+----------------------------+-----------------------+
| **Independent   | IV&V Audit Sub-Phase       | -   IV&V Results      |
| Verification    |                            |                       |
| and Validation  |                            |                       |
| Phase**         |                            |                       |
+-----------------+----------------------------+-----------------------+

## Project Initiation Phase

### Purpose

The purpose of this phase is to ensure that both parties, the migrating
agency and the service provider, have clarity and alignment on the
scope, approach, governance, project schedule, and risks of the project;
and have agreed on a process for addressing risks, and any changes to
scope and timeframe. The Project Initiation Phase is important in
setting expectations for the entire migration.

### Assumptions

The template assumes that both the migrating agency and the service
provider have prepared for the Project Initiation Phase by documenting
their understanding and ensuring internal alignment within their own
organizations on project scope, approach, governance, project schedules,
and risks.

### Tasks

The output of the Project Initiation Phase should be a documented
project management plan. It is recommended that this plan include the
following information:

-   Project Scope and Approach -- an understanding of the overall scope,
    level of effort/time estimate for the project, and methodologies to
    be used.

-   Project Governance -- a description of the structure of the teams
    that will manage the project both on the migrating agency side and
    the service provider side; definition of how decisions will be made
    and issues escalated, how changes to project cost and timeline will
    be controlled, how configuration management will be performed, and
    how performance will be measured.

-   Project Schedule -- a more detailed definition of the work to be
    performed, deliverables, timeframe, constraints and assumptions, and
    timelines are defined.

-   Resource Plan -- identification of the individual resources
    necessary to perform the work and timeframes outlined in the project
    schedule.

-   Risk Management Plan -- a categorization and description of each of
    the risks applicable to the project, including their probability,
    impact, triggers, and response or fall-back strategies (if the risk
    comes to fruition). For negative risks, the plan should also outline
    strategies for avoidance, transference, and mitigation. For positive
    risks, the plan should outline strategies for taking advantage of
    the risks.

-   Change Management Plan -- an approach for addressing how to help
    stakeholders understand and prepare for the changes associated with
    the migration. A change management plan will likely include a human
    capital plan and a communications plan.

-   IV&V Audit Plan -- an approach for conducting the IV&V audit
    including identification of the following: work products to be
    reviewed/assessed, processes requiring IV&V oversight, quality
    assurance standards, and audit/testing schedule.

Sign-off on the initiation documents ensures that both the SSP and
migrating agency agree on the scope, direction, and outcomes of the
project.

## Concept of Operations Phase

The purpose of the Concept of Operations Phase is to align on the
specific system and business process requirements, and identify the
specific approaches that must be developed to meet those requirements.
During this phase both parties must work closely together, typically
through employing working sessions. If following an iterative approach,
during this phase requirements are gathered, sorted and separated into
releases or change efforts based on sorting or priority.

This migration project schedule assumes that a Concept of Operations has
not been completed by the migrating agency prior to the start of its
migration project. As such, it assumes that the Concept of Operations
Phase will begin only after sign-off has been obtained on the initiation
documentation. It is recommended however, that the migrating agency
performs an "As Is" analysis and/or requirements analysis in house or
issues a Request for Proposal or task order to have an SSP or other
implementation services vendor assist in these tasks. If the "As Is"
analysis and/or requirements are already documented, the SSP will need
to validate the completeness of the documentation for the migration.
This approach may help to compress the overall migration schedule.

As a best practice, it is recommended that the migrating agency, at
least, begin to perform data collection in preparation for the Concept
of Operations Phase, and if possible, begin performing the "As Is" and
"To Be" analysis.

### Define Current Environment Sub-Phase

#### Purpose

The purpose of the Define Current Environment Sub-Phase is to establish
the starting point from which change must begin. The current environment
is documented in an "As Is" document. The "As Is" document should not
only include the "as-is" business processing workflow but also
information about feeder systems, users/user roles, system enhancements,
reports, technical configuration, etc. It is essential for agencies to
understand their current business and technical architecture/environment
in order to assess the impact of business process changes or system
customizations on the migrating agency's operations. The "As Is"
analysis can assist with human capital planning, training plan
development, change management, and communications planning.

#### Tasks and Dependencies

An agency can begin analyzing its own current environment and creating
an "As Is" document as soon as it makes the decision to migrate. If the
SSP defines the migrating agency environment and drafts the "As Is"
documentation, the SSP can begin this analysis and documentation after
receiving sign-off on the Initiation Phase. After a joint review of the
draft "As Is" documentation, the SSP can create and deliver the final
documentation and obtain sign-off.

### Requirements Analysis Sub-Phase

#### Purpose

The purpose of the Requirements Analysis Sub-Phase is to gather the
migrating agency's various migration requirements, define and document
the requirements, identify gaps between the migrating agency's
requirements and the SSP's capabilities, and propose methods for
mitigating the impact of the gaps. The Requirements Analysis Sub-Phase
consists of Requirements Gathering and Gap Analysis.

-   Requirements Gathering: During Requirements Gathering, migrating
    agency requirements for business process, application, feeder
    system/interface, reporting, data, technical (including disaster
    recovery, capacity planning, and performance requirements),
    security, training, and user documentation are gathered. These
    requirements will be documented in a "To Be" document consisting of
    the requirements definition and Enterprise Architecture Blueprint.
    Having a complete set of requirements is necessary in order to
    perform any type of gap analysis with the SSP. These requirements
    should be developed based on the agency's future business processes,
    not on the agency's current system functions. A complete set of
    requirements that maintain traceability throughout the Design,
    Development and Testing phases will contribute to the system's
    success.

-   Gap Analysis: During Gap Analysis, gaps between the migrating
    agency's current operating environment, its requirements, and the
    capabilities of the SSP's financial system or SSP's current business
    processes are identified. The end result will be an identification
    of business processes and/or software that need to be re-engineered
    to align the migrating agency with the SSP, and to the FMLoB
    Standard Business Processes and Common Government-wide Accounting
    Code. During this phase, high level configuration, code, or business
    process changes may be proposed to mitigate the impact of the
    identified gaps.

#### Assumptions

It is assumed that the Enterprise Architecture Blueprint will follow the
guidelines of the agency's overall enterprise architecture plan.

#### Tasks and Dependencies

If the migrating agency has drafted, or is in the process of drafting
the "As Is" documentation, the SSP can begin developing the "To Be"
documentation once the Project Initiation Phase is complete. The "To Be"
documentation includes gathering requirements and drafting the "To Be"
documentation, which includes the requirements analysis and enterprise
architecture documents. Following a joint review of the draft, the SSP
can develop and deliver the final "To Be" documentation and obtain
sign-off. Before finalizing the "To Be" documentation, the SSP should
review the final "As Is" documentation provided by the migrating agency.

If the SSP is drafting the "As Is" documentation, the SSP can begin
gathering requirements and creating draft documents after the joint
draft "As Is" documentation review. The final requirements analysis and
enterprise architecture documents cannot begin until the SSP obtains
sign-off on the final "As Is" document and the SSP and migrating agency
have conducted a joint review of the draft requirements analysis and
enterprise architecture documents.

Once the "As Is" and "To Be" environments are known, the gaps between
the two must be identified. During the Gap Analysis, the migrating
agency and SSP will engage in several joint discussions to determine
changes that will be needed to mitigate the documented gaps. Methods of
mitigating gaps could include the following: new development,
customizations, and/or extensions to the software; reports and/or
interfaces to feeder systems; and business process workarounds or
business process changes. The SSP will provide an estimate for any new
development, customizations, or extensions proposed for the system,
reports, or feeder system interfaces. For any workarounds or business
process changes proposed, the SSP will document the impacts to the
migrating agency's existing operations.

## Design Phase

The purpose of the Design Phase is to establish how the migrating agency
will operate in its new environment by detailing any changes that must
be made to the system and/or business processes to achieve the migrating
agency's requirements and ensuring that changes are implemented
correctly and are understandable to the users. Whenever possible, it is
recommended that agencies realign their business processes to their
SSP's system instead of customizing the SSP's system. This will reduce
costs and inconsistencies for the migrating agency.

During the Design Phase, the SSP establishes its functional architecture
and creates or updates draft and final software design/change
specification documents, test plans, and configuration approach
documentation for each change effort.

The types of test plans will vary depending on whether new development,
customizations or extensions are needed to the system, reports, or
feeder system interfaces. However, the configuration approach
documentation should be a standard.

The proposed timelines in this section will vary depending on the degree
of customizations and/or changes required, the size of the agency, and
the complexity of the agencies current systems and processes. If the
migrating agencies identify new or missing requirements during its
review of design documents, the migrating agency and SSP must meet to
determine cost and schedule impacts. If the SSP and migrating agency
agree to implement the new requirement, all affected system
definition/analysis and design documentation must be updated and changes
tracked according to the Configuration Management Plan (reference
Configuration Approach Development Sub-Phase for description).

### Design/Change Specification Development Sub-Phase

#### Purpose

The purpose of the Design/Change Specification Development Sub-Phase is
to detail the software changes and/or new software needed to satisfy a
requirement and to outline the new enterprise architecture, both
functional and technical.

#### Tasks and Dependencies

During the Design/Change Specification Development Sub-Phase, the
following documents will be created or modified depending on whether the
SSP allows and the migrating agency requires system customization or
extensions. The following system design documents will need to be
drafted or modified: functional architecture, system architecture, data
structures, data conversion process documentation, data conversion jobs,
data cleansing plan, application software, system interfaces, job
streams, and reports. Beginning this Sub-Phase depends on completing the
Concept of Operations Phase. Drafting one design/change specification is
not dependent on drafting another. Several designers can draft the
documents simultaneously, although communication is required to ensure
that all requirements are met.

### Test Plan Development Sub-Phase 

#### Purpose

The purpose of the Test Plan Development Sub-Phase is to detail the
testing objectives, tools, resources, methods, and evaluation criteria
for the various testing Sub-Phases.

#### Tasks and Dependencies

After the design/change specifications are complete, high level test
plans can be drafted or updated. High level unit, system/business
process, integration/end-to-end, system performance (load), regression,
conversion, and user acceptance test plans will be drafted or modified
and delivered to the migrating agency for approval. The SSP can begin
drafting high level test plans as soon as the SSP and migrating agency
have completed joint review of the draft design/change specifications.
The SSP cannot begin drafting the final high level test plans until a
joint review of the draft test plans has been conducted and the SSP has
obtained sign-off on the final design/change specification documents.

### Configuration Approach Development Sub-Phase

#### Purpose

The purpose of the Configuration Approach Development Sub-Phase is to
establish or update the following documents:

-   Configuration Management Plan -- outlines the procedures that will
    be used to make changes to the system throughout the course of the
    migration and post-implementation. Changes include not only software
    changes but also configuration changes.

-   System Security Plan -- details how security should be set up in the
    system for different users and user groups.

-   System/Data Configuration Document -- details how certain tables
    should be configured in the system.

#### Tasks and Dependencies

The SSP can begin drafting/updating the Configuration Management Plan
and the System Security Plan as soon as the SSP and migrating agency
have completed joint review of the draft design/change specifications.
The system/data configuration document, however, is dependent on items
from the Configuration Management Plan and the System Security Plan, and
therefore cannot be drafted/updated until these two documents are
complete. These three configuration approach documents are then
delivered to the migrating agency, and the migration agency and SSP
should conduct a joint review of the documentation.

The SSP cannot begin drafting the final configuration approach documents
until a joint review of the draft configuration approach documents has
occurred, and the SSP has obtained sign-off on the final design/change
specification documents.

## Development Phase

The purpose of the Development Phase is to develop or modify the
necessary software to match the design specifications based on the
complete, signed off requirements.

After the migrating agency has provided final sign-off on design
documentation for the change effort, the Development Phase for the
change effort can officially begin, although the Technical Setup
Sub-Phase *should* begin earlier. The Development Phase consists of
technical setup, coding, and unit testing. The tasks and durations in
this section may vary depending on whether the SSP allows and the
migrating agency requires customizations and/or extensions and the
extent of these customizations/extensions. If the migrating agency
identifies new or missing requirements during its review of unit test
results, the migrating agency and SSP will meet to determine cost and
schedule impacts. If the SSP and migrating agency agree to implement the
new requirement, all affected concept of operations, design, and/or
development documentation must be updated and changes tracked according
to the Configuration Management Plan.

The Development Phase is only necessary if new development,
customizations, or extensions are needed to the system, reports, or
feeder system interfaces.

### Technical Setup Sub-Phase

The purpose of the Technical Setup Sub-Phase is to procure the hardware
and software, load and configure the hardware and software, tune the
database, and test the baseline software. The SSP can procure the
hardware and software required for system implementation (if necessary),
configure servers, and load the baseline software on test and
development servers, after a joint review of the draft design/change
specifications has occurred (most importantly, the system architecture
document). The SSP, however, cannot begin configuring the hardware and
software, tuning the database, and testing the baseline software until
receiving sign-off on the final System/Data Configuration document.

### Coding Sub-Phase

The purpose of the Coding Sub-Phase is to develop any custom interfaces,
reports, tables, code, or extensions and to modify baseline software, if
necessary. The Coding Sub-Phase also includes development or
customization of conversion and conversion reconciliation scripts. This
sub-phase can begin after technical setup is complete, and the SSP has
obtained sign-off on the Design/Change Specifications and Configuration
Approach documents.

### Unit Testing Sub-Phase

#### Purpose

The purpose of the Unit Testing Sub-Phase is to verify that the code
functions as developed.

#### Tasks and Dependencies

Draft unit test preparation materials (drafting or updating unit test
scripts, creating test data, and documenting expected results) can begin
after sign-off has been obtained on the Design Phase. However, the
execution of the unit test script cannot begin until after coding is
complete and the SSP has conducted a joint review with the migrating
agency on the draft unit test preparation materials. The developer will
log any errors found during unit testing into a database, resolve the
errors, and retest. The designers will update the designs/change
specifications if necessary according to the configuration management
plan. The Unit Testing Sub-Phase is complete when the SSP delivers the
final test scripts and test results to the migrating agency, conducts a
joint review, and receives sign-off.

## Testing Phase

The purpose of the Testing Phase is to verify that the application
software functions, as designed and developed, and that the software
aligns with agency future business processes as identified in the
Requirements Analysis and Gap Analysis.

After the Development Phase is complete for a software change effort,
the Testing Phase for that change effort can officially begin, although
some activities may begin earlier. The durations in the project schedule
for drafting test scripts may vary depending on the extent of system
customization and/or the complexity of the migrating agency's business
processes.

If new development, customizations or extensions are needed to the
system, reports, or feeder system interfaces, the Testing Phase will
consist of the following seven testing cycles:

-   System Testing/Business Process Testing -- for implementations
    involving new development, customizations, or extensions, system
    testing/business process testing will include testing the system's
    compliance with the business process requirements and design/change
    specifications documentation. For implementations involving changes
    to the migrating agency's existing business process, system
    testing/business process testing will include testing the system's
    compliance with the new business processes.

-   Integration/End-to-end Testing -- end-to-end testing of the system
    and related interfaces and feeder systems, including security
    testing.

-   System Performance Testing (Load Testing) -- volume and stress
    testing the system.

-   Regression Testing -- for implementations involving new development,
    customizations, or extensions, regression testing includes high
    level re-testing of the system after all system fixes and
    modifications are complete. This high level retesting confirms that
    code or configuration changes made to the system to fix
    requirements, design, software, or configuration problems are
    accurate and that the fix has not introduced or reintroduced new or
    previously discovered problems.  

-   Regression testing is not necessary for implementations that do not
    include new development, customizations, or extensions.

-   Conversion Testing -- testing conversion of existing financial
    system data to the new financial system.

-   User Acceptance Testing (UAT) -- user directed testing of financial
    system compliance with requirements or new business processes.

In addition, the Implementation Phase includes one cycle of testing: the
Migration Dry-Run Testing, which is described in that section of this
document.

The testers will log any issues found during testing. For
implementations involving new development, customizations, or
extensions, the developers and/or designers will resolve the errors. For
implementations that do not include new development, customizations, or
extensions, developers will analyze the issue and resolve any system
defects. After issues are resolved, the software will then be retested
and the design documents will be updated if necessary according to the
configuration management plan. If the migrating agency identifies new or
missing requirements during its review of test results, the migrating
agency and SSP will meet to determine cost and/or schedule impacts. If
the SSP and migrating agency agree to implement the new requirement
through new development, customizations, or extensions, all affected
system definition/analysis, design, development, and/or test
documentation must be updated and changes tracked according to the
Configuration Management Plan. If the SSP and migrating agency decide to
change the migrating agency's business process to resolve the new
requirement, all affected system definition/analysis and test
documentation must be updated and changes tracked according to the
Configuration Management Plan.

### Testing Environment Setup Sub-Phase

#### Purpose

The purpose of the Testing Environment Setup Sub-Phase is to set the
testing environment up with the data from the migrating agency and the
baseline development software in preparation for System/Business
Process, Integration/End-to-End, System Performance (Load), Regression,
Conversion, and User Acceptance Testing.

#### Tasks and Dependencies

After the Design Phase is complete, the SSP can request test data from
the migrating agency in accordance with the test plan. After the SSP
obtains the test data and the Development Phase is complete (i.e. the
SSP obtains sign-off on the unit test results), the developers can
migrate the code from the development environment to the testing
environment (following the Configuration Management procedures), load
the migrating agency's test data, and configure the testing environment
as specified in the System/Data Configuration Plan document.

### System Testing/Business Process Testing Sub-Phase

#### Purpose

The purpose of the System Testing/Business Process Testing Sub-Phase is
to test the system's compliance with design/change specifications and
with the agency's business process requirements or new business
processes. This Sub-Phase also consists of testing the functional
operation of the application (e.g. ensuring that the application updates
tables correctly).

#### Tasks and Dependencies

Draft system test/business process test preparation (drafting or
updating system test/business process test scripts, selecting test data,
and documenting expected results) can begin after sign-off has been
obtained on draft unit test preparation (drafting or updating unit test
scripts, creating test data, and documenting expected results). The
system test/business process test execution can begin only after the
test environment is set up and sign-off has been obtained on the draft
system test/business process test preparation materials. After system
test/business process test is complete, the SSP delivers the results to
the migrating agency, conducts a joint review, and obtains sign-off.

### Integration/End-to-End Testing Sub-Phase

#### Purpose

The purpose of the Integration/End-to-end Testing Sub-Phase is to
perform end-to-end testing of the entire system and all of its external
feeder systems and interfaces. This Sub-Phase includes testing
technical, configuration, and reporting requirements.

#### Tasks and Dependencies

Draft integration/end-to-end test preparation (drafting or updating
integration/end-to-end test scripts, selecting test data, and
documenting expected results) can begin after sign-off has been obtained
on the draft system test/business process test preparation materials
(drafting or updating unit test scripts, selecting test data, and
documenting expected results). The integration/end-to-end test execution
can begin only after sign-off has been obtained on draft
integration/end-to-end test preparation and final system test/business
process test results. After Integration/End-to-End Testing is complete,
the SSP delivers the results to the migrating agency, conducts a joint
review, and obtains sign-off.

### System Performance Testing (Load Testing) Sub-Phase

#### Purpose

The purpose of the System Performance Testing (Load Testing) Sub-Phase
is to volume test and stress test the system to verify that the system
meets agency defined performance requirements.

#### Tasks and Dependencies

During the System Performance Testing (Load Testing) Sub-Phase, volume
and stress tests are executed. Volume testing verifies that the system
can handle a set volume of data within a specified timeframe, as
detailed in the requirements documentation and still meet agency
performance requirements. Stress testing verifies that a set number of
users and processes, as detailed in the requirements documentation, can
access the system at any given time and still meet agency user response
time requirements.

Draft system performance test (load test) preparation (drafting or
updating system performance test (load test) scripts, selecting test
data, and documenting expected results) can begin after sign-off has
been obtained on the draft integration/end-to-end test preparation
(drafting or updating unit test scripts, selecting data, and documenting
expected results). System performance test (load test) and
integration/end-to-end test execution can occur simultaneously. The
system performance test (load test) execution can begin only after
sign-off has been obtained on the draft system performance test (load
test) preparation materials and the final system test/business process
test results. After System Performance Testing (load testing) is
complete, the SSP delivers the results to the migrating agency, conducts
a joint review, and obtains sign-off.

### Regression Testing Sub-Phase

#### Purpose

The purpose of the Regression Testing Sub-Phase is to conduct high level
retesting of the entire system and interfaces to test the impact of any
code or configuration changes made to the system during the previous
testing sub-phases and to verify that new or previously corrected
problems are not introduced or reintroduced. This phase is necessary
only for implementations that involve new development, customizations,
or extensions. If system defects are identified during Conversion or UAT
testing, or through the Independent Validation and Verification (IV&V)
audit, then some portion of the regression tests may need to be
re-executed.

#### Tasks and Dependencies

During the course of System, Integration/End-to-End, or System
Performance (Load) Testing, code or configuration changes may be made to
the system to correct identified problems or meet new requirements. To
ensure that no code changes negatively impact any previously tested
modules, a high level regression test should be conducted on the system
and its related interfaces and feeder systems. Draft regression test
preparation (drafting or updating regression test scripts, selecting
test data, and documenting expected results) can begin after sign-off
has been obtained on draft system performance (load) test preparation
materials (drafting or updating system performance (load) test scripts,
selecting data, and documenting expected results). The regression test
execution can begin only after sign-off has been obtained on draft
regression test preparation materials and final system performance
(load) test and integration/end-to-end test results. After Regression
Testing is complete, the SSP delivers the results to the migrating
agency, conducts a joint review, and obtains sign-off.

### Conversion Testing Sub-Phase

#### Purpose

The purpose of the Conversion Testing Sub-Phase is to test the
conversion of data from the agency's prior financial system to the SSP
financial system. This phase consists of verifying that the converted
data is accessible, accurate, and can be modified, added, or deleted as
specified in the conversion design. During this time, data issues should
be identified and a data cleansing process should be created and tested
for the production conversion.

#### Assumptions

This project schedule template assumes that any issues associated with
conversion will be addressed after conducting two mock conversions.
However, there is a risk that several additional mock conversions may be
necessary. Each agency must assess the level of difficulty of its
conversion when determining how many mock conversions to schedule. Each
agency must also plan for the risk that additional mock conversions
beyond those that have been scheduled may be necessary. Subsequent
phases should not continue until a clean mock conversion is achieved.

#### Tasks and Dependencies

Draft conversion test preparation (drafting or updating conversion test
scripts, drafting a conversion checklist, selecting test data, and
documenting expected results) can begin after sign-off has been obtained
on the regression test preparation materials (drafting or updating
integration/end-to-end test scripts, selecting test data, and
documenting expected results). The conversion test execution can begin
only after regression test sign-off and sign-off on the draft conversion
test preparation materials. In the Conversion Testing Phase, testers
perform two or more mock runs of the conversion. The testers reconcile
the converted data with the original data and verify that the data is
converted and accessible according to the conversion design document.
For any data that the migrating agency agrees cannot or should not be
converted to the new financial system, the conversion test should verify
that the data is accessible in the manner detailed in the conversion
design document (e.g. datamart). During the course of Conversion
Testing, any data issues will be identified and the data will be
cleansed in preparation for production conversion. After Conversion
Testing is completed successfully, the SSP delivers the conversion test
results to the migrating agency for sign-off. It is during the
Conversion Testing that the conversion checklist is developed for use in
the Migration Planning Phase.

### User Acceptance Testing (UAT) Sub-Phase

#### Purpose

The purpose of the UAT Sub-Phase is for users to execute self-defined
tests to verify system functionality.

#### Tasks and Dependencies

UAT can begin after the migrating agency has provided sign-off on the
following test cycles: System/Business Process testing,
Integration/End-to-End testing, System Performance testing (Load
testing), Regression testing, and Conversion testing. In this Sub-Phase,
users from the migrating agencies will create their own test scripts to
test the functionality of the system and verify that the system meets
their business and system requirements and/or new business processes. A
recommended best practice is to create test scripts using a combination
of converted and newly entered data. At the end of UAT, users provide
sign-off on the system functionality.

## Develop User and Training Documents Phase

#### Purpose

Training is an essential element to any successful migration. The
purpose of the Develop User and Training Documents Phase is to develop
documentation user manuals, user documentation, and training methods and
materials to support migration.

#### Tasks and Dependencies

The development or update of draft user documentation cannot begin until
after integration/end-to-end testing is complete because changes may be
made to the system or existing agency business processes during system
testing/business process and/or integration/end-to-end testing to
correct defects or meet new agency requirements. The types of user
documents that will be drafted or updated and delivered to the migrating
agency will be based on the requirements agreed upon in the Requirements
Phase, and may include: user documentation (including process
documentation and FAQs), user training materials, and standard operating
procedures. The final draft of the user documents usually cannot begin
until the SSP has conducted a joint review with the migrating agency on
the draft user documents and the Test Phase is complete (i.e. SSP has
obtained sign-off on System/Business Process, Integration/End-to-End,
Performance Stress (Load), Regression, Conversion, and UAT). However,
during the interim, updates can continue to be made to the user
documentation as system code, configuration, and/or business process
changes are made.

## End User Training Phase

The purpose of the End User Training Phase is to plan for and conduct
the training necessary to prepare users on the use of the system and any
new business processes.

### Training Plan Development Sub-Phase

#### Purpose

The purpose of the Training Plan Development Sub-Phase is to outline a
plan for meeting the training requirements. The Training Plan may
include items such as training techniques; training tools such as
simulations and learning management systems; training methods such as
train-the-trainer, classroom training or computer-based training; course
curriculum; required materials, groups of personnel requiring training;
length of training sessions; and a preliminary training schedule.

#### Tasks and Dependencies

For implementations involving new development, customizations, or
extensions, creating or updating the first draft of the Training Plan
should begin after the SSP has conducted a joint review of all drafts
with the migrating agency, but can begin concurrent with the draft
designs so long as the training impacts of the designs are well-known.
The training program will continue to evolve following the completion of
design/change specification documents, configuration approach documents,
draft user and training documentation, and all Testing phase activities.
For implementations that do not involve new development, customizations,
or extensions, the existing system training plan can be updated or
modified as necessary.

### Training Logistics Sub-Phase

#### Purpose

The purpose of the Training Logistics Sub-Phase is to solidify the
Training Plan with the logistical details necessary to execute training
including a final list of trainees and trainers, the securing of
training venues, length of training sessions, and a specific schedule
for courses and attendees.

#### Tasks and Dependencies

Identifying and scheduling trainees and establishing the training
courses can begin after the Develop User and Training Documents Phase
and the Training Plan Phase are complete. Training sessions may need to
be rescheduled if it is determined that the migration may not meet the
scheduled deadline. The SSP can begin configuring the training database
instance after the Testing Phase and Develop User and Training Documents
Phase are complete.

### Conduct Training Sub-Phase

After the Training Logistics Sub-Phase and the Develop User Training
Documents Phase are complete, the SSP can begin conducting training
sessions according to the final Training Plan. Migrating agencies should
consider training users on basic changes within two weeks of the
migration. The project schedule assumes that training such as advanced
user training and refresher training can continue past the 'go-live'
date for as long as necessary. It is recommended that agencies plan for
ongoing training for new users and refresher courses for existing users.

## Implementation Phase

The purpose of the Implementation Phase is to migrate/implement the
system into production. After obtaining sign-off on all of the testing
results, the Implementation Phase can officially begin (although some
activities may begin earlier). The Implementation Phase consists of
system migration and data migration/conversion.

### Migration Planning Sub-Phase

#### Purpose

The purpose of the Migration Planning Sub-Phase is to begin to create or
update plans and checklists for a smooth migration of operations and to
establish a fallback strategy, should an issue arise with the migration.
The number and type of checklists necessary may be dependent on the
complexity of the migration. For information on the types of checklists
that an agency may use in migration, see the Migration Checklist section
at the end of this chapter.

#### Tasks and Dependencies

The Migration Plan and schedule should typically outline the dates/times
of the migration, estimated timeframes for each step within the
migration, roles and responsibilities during the migration, and the
checklists that will be required. The number and type of checklists
necessary may be dependent on the complexity of the migration. The
development or updating of draft Migration Plans should begin during the
Conversion Testing Sub-Phase to ensure that the migration planning is
complete in time to begin the migration dry-run immediately following
UAT sign-off. The final Migration Plan can begin after the joint draft
Migration Plan review and the completion of the Testing Phase.

### Migration Dry-Run Testing Sub-Phase

#### Purpose

The purpose of the Migration Dry-Run Testing Sub-Phase is to test the
processes and procedures (i.e. migration checklists) associated with the
production migration.

#### Tasks and Dependencies

Migration Dry-Run Testing cannot begin until after the Migration
Planning Sub-Phase and the Testing Phase have been completed. The
migration dry-run consists of verifying that all system related
interfaces, objects, procedures, and packages are migrated successfully
to the production environment. Depending on the integrity of the data in
the existing financial system, data cleansing may need to occur
throughout the entire length of this sub-phase in order to prepare the
data for production migration.

### Production Software Cutover Sub-Phase

#### Purpose

The Production Software Cutover Sub-Phase involves moving all of the
necessary technical components into the correct environment to bring the
financial system into production operations.

#### Tasks and Dependencies

The Production Software Cutover Sub-Phase cannot begin until the
Migration Dry-Run Testing Sub-Phase is complete and the migrating agency
has provided signoff on the IV&V audit results. During this sub-phase,
the software is migrated from the test environment to production. The
technical team will then establish user access and verify the migration.
The migration verification should be performed using the migration
checklist to ensure that all objects, procedures, code, interfaces, and
extensions are migrated to production. Furthermore, verification
activities should include user verification that the software is working
as expected. The SSP will deliver the migration checklist and
verification to the migrating agency for sign-off.

### Production Data Conversion Sub-Phase

#### Purpose

The Production Conversion Sub-Phase involves accurately moving all
necessary data into the new environment.

#### Tasks and Dependencies

After the Production Software Cutover Sub-Phase is complete and the
migrating agency has provided signoff on the IV&V audit results, data
migration/conversion can begin. In this phase, the current system is
brought down and data conversion and conversion reconciliation are
executed. During this sub-phase, a verification team, which usually
consists of members from the migrating agency, typically establishes the
"before conversion" verification of key financial data. This process is
also known as the pre-conversion reconciliation.

Once the pre-conversion reconciliation is complete, the production
database is then exported into the appropriate conversion environment,
and the conversion scripts are then executed against the production
database using a detailed conversion checklist for quality assurance.
The conversion results are analyzed by the verification team using a
verification checklist. Furthermore, verification activities should
include user verification that the software functions properly with the
converted data.

The migrating agency should sign-off on both the conversion checklist
and the verification checklist before the system can be brought up for
processing.

### Bring up New Financial System Sub-Phase

The purpose of the Bring up New Financial System Sub-Phase is to make
the new financial system available for users. A final Go/No Go checklist
that incorporates elements from the checklists used in the previous
Production Software Cutover Sub-Phase and the Production Data Conversion
Sub-Phase can be used as a final sign off before the new system is
brought up.

### Migration/Implementation Complete Sub-Phase

The migration/implementation is complete after the new system is brought
up for users. To minimize risks associated with Annual Close, the new
system should be brought up at the beginning of the new fiscal year on
October 1 or shortly thereafter.

## Independent Verification and Validation (IV&V) Phase

***Purpose***

The purpose of the IV&V Phase is to provide third-party monitoring and
oversight to the project management processes, quality assurance of
deliverables and work products at various stages of the project. During
the Independent Verification and Validation Audit Phase, verification
and validation is performed by an individual or organization that is
technically, managerially, and financially independent of the
development organization.

The IV&V schedule can vary depending on the agreement between the IV&V
provider and the client agency. IV&V auditing may consist of any or all
of the following:

-   Validating that work products meet quality and performance
    guidelines and that the end result satisfies business goals, project
    objectives and requirements.

-   Support quality assurance activities including but not limited to
    requirements traceability, process/product/progress assessment,
    suitability assessment, performance metrics, alignment with vision
    and mission, requirements management, program management support and
    change management oversight.

-   Regression testing the entire financial system (after the SSP has
    obtained sign-off on the entire Testing Sub-Phase).

-   Testing the system to verify compliance with any system changes or
    business process changes made during the course of the Testing
    Sub-Phase.

-   Executing, on a smaller scale, all testing cycles executed by the
    SSP (usually these tests are executed after the SSP has obtained
    sign-off on a cycle).

***Tasks and Dependencies***

IV&V auditing typically occurs throughout the project lifecycle,
typically beginning during the Concept of Operations Phase. During the
IV&V phase, the IV&V vendor reviews work products, conducts IV&V audit
testing, reviews test results with the client, and works with the SSP to
resolve any identified defects. The IV&V vendor must provide signoff on
all work products from design through migration dry-run before
production software cutover can begin. Following the migration dry-run,
IV&V activities can continue through and post cutover as necessary and
required by the migrating agency.

## 

# Migration Checklists

Checklists are useful for the purposes of quickly identifying whether
specific and detailed steps within a task or sub-phase have been
completed. SSPs and agencies may have standard checklist templates for
system implementation and migration projects. However, it is likely that
each checklist will need to be customized to meet the specific needs of
an individual migrating agency. Several examples of checklists are
provided below.

## 1. Milestone Checklist

The Milestone Checklist contains important milestones and deliverables
throughout the system implementation lifecycle such as design
documentation delivery, testing result sign-off, system configuration
completion, and system migration verification. This type of checklist
will enable the SSP and the migrating agencies to track important phases
of the migration, determine the impact of missed deadlines, prioritize
tasks, and measure progress.

## 2. Technical Migration Checklist

The Technical Migration checklist lists all of the system tables,
procedures, objects, and code that should be migrated to the production
server. The technical team responsible for the cutover can follow this
checklist when performing the migration. By requiring sign-off on this
checklist, it can also be used to verify that all items were
successfully migrated to production.

## 3. Detailed Implementation Checklists

Detailed Implementation Checklists specify tasks in the Migration
Project Schedule to a lower level of detail. These types of checklists
are useful in tracking small components of the migration without having
all of this information in the Migration Project Schedule. For example,
an alternative to adding detail by function to the Requirements Analysis
Sub-Phase of the project schedule, is to use a Requirements Analysis
Sub-Phase Checklist that lists the specific types of requirements
analyses to be performed (i.e. system performance requirements,
interface requirements, data accessibility requirements, data storage
requirements, capacity requirements, etc.).

## 4. Conversion Checklist

A Conversion Checklist typically outlines, in the appropriate sequential
order, the specific programs and jobs that need to be executed, manual
data changes that must be made, and other steps that must be performed,
for a data conversion. By requiring sign-off on this checklist, it can
also be used to verify that all steps were successfully executed for the
data conversion.

## 5. Verification Checklist

The migrating agency may wish to maintain a checklist of items it
desires to validate as part of the production software cutover and data
conversion. By requiring sign-off on this checklist, it can also be used
to verify that the software and data were successfully migrated to
production.

[^1]: *A Guide to the Project Management Body of Knowledge (PMBOK®
    Guide) Third Edition © 2004 Project Management Institute (PMI).*
    Additional information on Earned Value Management (EVM) is available
    from the Project Management Institute (PMI).

[^2]: (<http://www.pmi.org/info/default.asp>)

[^3]: (<http://www.acq.osd.mil/pm/>)

[^4]: (https://acc.dau.mil/simplify/ev_en.php)

[^5]: ( http://www.whitehouse.gov/omb/)

[^6]: https://acc.dau.mil/CommunityBrowser.aspx?id=104842

[^7]: http://www.earnedschedule.com/Home.shtml

[^8]: Financial Systems Integration Office, formerly Joint Financial
    Information Management Program, is an office under the U.S. General
    Services Administration (GSA) promoting the improvement of financial
    management practices in the federal government.
    http://www.fsio.gov/fsio/

[^9]: Institute of Electrical and Electronics Engineers, Inc. is a
    non-profit professional association promoting the advancement of
    technology. <http://www.ieee.org/portal/site/iportals>

[^10]: Project Management Institute is a non-profit professional
    association promoting the advancement of the project management
    profession.

[^11]: The Carnegie Mellon Software Engineering Institute (SEI) is a
    federally funded research and development center sponsored by the
    U.S. Department of Defense and operated by Carnegie Mellon
    University with the mandate to advance the state of the practice of
    software engineering and to serve as a national resource in software
    engineering and technology. http://www.sei.cmu.edu/sei-home.html

[^12]: Parallel operations is the process whereby the agency continues
    to operate their old financial system concurrently with the new
    financial management system for a specified period of time or until
    the agency has a level of confidence in the new financial system
    operations. Parallel operations require planning and coordination to
    minimize potential risks. Processing transactions in both systems is
    required and can be a burden on an organization's workforce, however
    it does provide a organization with a level of confidence that a
    restore to the old financial system can be made if necessary.