Issue Management: Management of Migration Issues

This section provides a description of the processes used by our methodology to manage migration issues and how the Hopp Item Manager functionality supports this.

The Data Task Group

One of the tasks required by the methodology during migration preparation is the establishment of a Data Task Group. The membership of the Data Task Group consists of relevant Key Data Stakeholders, including Data Migration Analysts, Business Domain Experts and Technical System Experts. Other Key Data Stakeholders will be invited as required. Data Task Group meetings will be held at least weekly during migration delivery.

The purpose of the Data Task Group meetings will be to decide what actions to take (if any) to address the issues recorded on the Migration Issues Log. They will also need to monitor the progress of the actions being taken. Therefore, the Key Data Stakeholders will need the delegated responsibility to take the necessary decisions (in line with Golden Rules 1 and 2, “Data Migration is a business not a technical issue” and “The business knows best”). The lead data migration analyst should chair the Data Task Group meetings.

The standard agenda for Data Task Group meetings should consist of the following items:

1. Evaluate New Migration Issues
2. Report on progress of current Migration Issues 
3. Re-plan future Releases

The Migration Issue Log can be updated directly in the Hopp Item Manager during Data Task Group meetings, so all Data Task Group members will need to be set up as users of the Portal.

Prioritization and Planning

The Data Task Group will need to prioritize and plan each new Migration Issue presented to them. When the Data Task Group is evaluating new issues, the filters can be used to display these issues on the Items screen during the meeting.

Each issue can now be evaluated in turn. The Data Task Group will need to decide on the priority of the issue.

The methodology requires both the Business Priority (recorded in the Impact field) and the Technical Priority to be considered. Each of these fields has three possible values:

• Critical
• Should Do
• Can Do

The combination of these two priorities is used to decide the overall priority (recorded in the Priority field):

• If both Business and Technical Priorities are ‘Critical’, overall Priority will be ‘Critical’
• If one of Business or Technical Priorities are ‘Critical’, overall Priority can either be ‘Critical’ or ‘High’
• If both Business and Technical Priorities are ‘Should Do’, overall Priority will be ‘High’
• If one of Business or Technical Priorities are ‘Should Do’ and the other is ‘Can Do’, overall Priority can be ‘Medium’ or ‘Low’
• If both Business and Technical Priorities are ‘Can Do’, overall Priority will be ‘Low’

Assigning a priority to each issue helps the Data Task Group to decide where the project’s limited resources need to be focused (in line with Golden Rule 3, “No organisation needs, wants or will pay for perfect quality data”). The three most common options that the Data Task Group will choose are:

• Ignore: These are generally low-level reality issues (such as missing or incorrect telephone numbers) that the business never found caused enough problems for them to be fixed in the legacy system. They will be carried across into the target system due to higher priority issues that need to be addressed.
• Fix in flight: Enriching the data from another source, for example coded transformations such as defaulting a ‘Y’ in a Yes/No field where it is blank or importing from a spreadsheet or alternative data source. This will probably be the second most common plan after ‘Ignore’, and all fixes will be implemented in Hopp.
• Fix in source: This is often the most common first suggestion for any issue. However, it is not always technically possible and where it is, available resources may limit the effectiveness of this solution. If sufficient resource is available, it could tie as the second most common plan.

The generic type of plan can be recorded as a Tag on the Issue Item.

The details of the Data Task Group’s decision should be recorded as a Discussion comment and the users responsible for the issue need to be recorded.

• The ‘Owner’ should be a member of the Data Task Group, who will be responsible for reporting back to the group on progress.
• ‘Assigned To’ is used to record the user who will be responsible for implementing the Data Task Group’s instructions. They do not need to be a member of the Data Task Group.

The Data Task Group also needs to decide when the work should be undertaken. This is done by assigning the Issue to a Release by adding a Link. On the Links tab, click on the Plus icon and select ‘Existing’.

The relevant Release is selected and a comment added to the link.

Finally, the Status of the issue needs to be updated.

If the plan is to Ignore the issue, then the Status will be updated to ‘Closed’ and the Date To will be recorded, otherwise the Status will be updated to ‘Active’.

It should be noted that sometimes the Data Task Group will be unable to decide on a priority and plan until they understand the scale of the issue (in line with Golden Rule 4, “If you can’t count it, it doesn’t count”). Where the issue is already linked to an Event, this should not be a problem. However, where there is no Event, the Data Task Group may decide to add a new Task to the Issue Item from the Links tab.

The new Task Item can then be opened on the Items screen and updated.

• The ‘Owner’ and ‘Assigned to’ needs to be recorded (‘Owner’ should be the same person as the Owner of the parent Issue)
• ‘Date From’ and ‘Date To’ should also be added
• The ‘Status’ should be updated to ‘Active’

Detailed instructions are recorded in the Description field.

Task Items can also be used where the detailed plan to resolve an Issue is complex and requires different actions from various people.

Monitoring Progress

After the Data Task Group has decided the plan for an Issue, it will have been given an Owner, who is a member of the Data Task Group and will be responsible for reporting progress back to them. It will also have been assigned to a User to carry out the necessary work (this may be the same person as the Owner). Where more than one person will be working on and updating an Issue record, they can subscribe to it by clicking on the bell icon.

Subscribing to an Item will allow the user to be notified of any updates to that Item. This can include email notifications, if this has been configured in the Hopp infrastructure. Further details on managing subscriptions and notifications can be found here: Subscription and Notifications, and details of how to configure email notifications are explained here: Setting up Notification and Email.

The second item on the Data Task Group meeting agenda is ‘Report on progress of current Migration Issues’. As shown in the previous section, new Issues that need to be addressed will be assigned to a Release. The current Release can easily be identified on the Timeline screen, as the vertical red line representing the current date will pass through it.

Right-clicking on the Release and selecting either option will open the Item. Expanding the size and clicking on the Links tab will display a list of the Issues that need to be reviewed in the current meeting.

The Issue Items can be updated during the meeting.

• If the Issue has been successfully addressed, the Status can be updated to ‘Resolved’ and the Date To recorded.
• Additional comments can be added in the Discussion tab.
• If the Issue remains open, the Item can be assigned to another Release on the Links tab.