Planning Module

The aim of the Planning Module is to assist in shaping and documenting the scope for a new project and to serve as the baseline as well as a reference for the migration team of the test and delivery status for the different areas within the scope.

It is important to note that the Planning Module is not a project management tool or a test tool. The Item Manager Module can assist the project team in establishing and tracking project management tasks (see Item Manager).

The aim of the Planning Module is to assist the project and management of the scope of a given data migration with a potential, new project. The Planning Module assists the team in tracking any changes to the agreed scope, as well as project/customer sign-off on each area, included in the scope that the area has been tested in accordance with scope/specifications.

The Planning Module is naturally composed of three main parts:

Part	Description
Template	Maintaining all the possible areas of business that may be in scope for the data migration to serve as a template for new Plans.
Plan	Support the setup of new projects by displaying a list/structure of areas to be considered in scope for a specific migration.
Execution	Monitoring the test state of each of the areas in scope for the migration. Discovering and managing new areas not originally included in the scope of the migration (change requests).

Why Use the Planning Module?

Establishing a Scope

The Planning module provides support for a data migration project at the beginning and end of the process, firstly by enabling the documentation of the scope of the data to be migrated and secondly, the definition of the testing that should be carried out to support the sign off of the completed migration.

As with any other project, definitively defining the scope of the data to be migrated is key to a successful migration project. If you are confused about the objective of the migration you cannot possibly measure whether it is complete or successful.

Defining the specific Scope

The definition of scope in the Planning Module is three-dimensional,

• it must identify what data objects are to be migrated
• which attributes of those objects are required
• ... and what is the time frame for history of those objects

Normally of these "what objects" and "what history" are defined first, the detail of the attributes will follow as the mapping work is carried out.

It is better to start with a high-level definition related to the functional areas of the target system than a list of data objects, this can also be more easily related to by the business and will support the testing plans.

Using Templates

To define the scope in the Hopp software you first define a template at the Portal level that can be applied to any Project. This should cover all the areas of the Target System that could be included in an implementation of that system.

The Template can form the basis of many migration projects and so is particularly useful to organizations that repeatedly migrate to the same or similar target systems.

The Template should be defined to be independent of the detail of a Target system or any particular version of a Target system so that it does not need to be reworked if a small change is included in a new release of the target software. It can always be extended in a specific project if there are areas that are encountered in one situation that are not common in most.

Introducing Dimensions

The Dimensions can be used to further categorize the types of project that may be carried out by the customer, group projects by geography, industry, or other differentiator.

The scope of the migration is a three-dimensional puzzle:

• Which data areas should be migrated
• What level of history is required for each of these areas
• What are the data objects for each of the areas

The first two should be settled at the start of the project and form part of the objectives of the project. They are required to enable the Project team to plan the required activities, timelines, resources, etc. that will be needed to achieve a successful migration. They will also be used to define the success criteria for the project and potentially used as a measure for the completeness of the project at intermediate stages.

Based on the success criteria for the project it must be established what constitutes a successful migration, i.e., for each Object what level of defects can be accommodated without preventing the new system supporting the business adequately. This can also be stated as what level of defect can be successfully corrected post go-live in the new system.

The definition of a successful migration must be quantifiable, i.e., it must be possible to count the number of data objects that fail to migrate and the number of errors that have been found (not necessarily the same figure). These metrics are also necessary to measure progress during the data migration project.

The detail of the data objects and their attributes will take time during the development phase of the data migration project to finalize.

Testing using the Planning Module

Once the data has begun to be processed the testing of the migration can begin. This may be separate from the main system testing or rolled up into it. Certainly, UAT should be carried out using migrated data and so should form part of the final sign off of the implementation.

Testing will be complemented by reconciliation. The first is to prove that the data has been migrated correctly, i.e., the data populated in the new system accurately reflects that held in the old. The second is to prove that all the data from the old system has been migrated to the new without any omissions or additions.

The Planning module is designed to be populated at the beginning of the project once the Scope has been agreed and then used at the end to record the results of the testing that has been included in the plan.

See Migration Sign-off to read more about a practical example of how to implement and use the Planning Module in a project.

Project Planning Overview

Adding a plan to a project

To create a plan for a project, there must be one or more Templates defined in the Portal.

To add a plan to a project, you must be able to access the project in the Configuration view. Once the project is open, there is an option called Planning on the main menu, and within that, an option called Manage Plan on the submenu.

If the project does not already have a plan, you can create one using any of the templates set up in the Portal.

Once the plan has been created, it will contain all the areas defined in the template. These can be excluded from the project altogether or just from the current scope of the project.

It is also possible to add areas to this project that are not included in the template, should it be necessary.

The plan is established with a single milestone called Preparation; the title of the milestone can be amended, and/or additional milestones can be added to the plan. The current milestone can be used as a filter in the Testing view of the project.

Scope and Plan

When the project team discuss and scopes a new data migration project, the project enters into a process where Hopp can be used to clearly define and establish the scope of the migration project.

To support this process, a Plan containing the Scope is established using Hopp. The starting point is a copy of a Template. The user can choose to include only a subset of areas relevant to the Country and ProjectType (Dimensions) of the project in question.

To kick off the scoping phase, a ‘scope document’ can be exported from the Planning module. The document will contain the top levels of the hierarchy of business areas as decided by the user by marking the areas to be included.

During the scoping phase, areas that came from the Template may be marked as irrelevant for this particular project (out of scope). For instance, a loan-centric Internet bank may not have any Bank Guarantees at all, etc.

The other way around, discussions with the project/customer may uncover business areas that are not part of the Template. In this case, new business areas can be added to the Plan.

If the decision results in a project, the Planning Extension can freeze a snapshot of the Plan representing the agreed/signed scope. The Planning Extension should be able to freeze a version of the agreed Plan at this point and export it to serve as an appendix to the project contract.

The Plan then enters into a phase of analysis where lower-level business requirements/areas are discussed and analyzed with the project/customer. At the end of this phase, all business areas of the Plan have been marked whether they are part of the migration project or not.

Access

Only authorized members of the migration team can work on a Plan.