Project Delivery Process D180

D180 - Data Conversion Strategy

DEFINITION

Analyse the needs for existing data to be converted and the availability of that data, its integrity, needs for supplementing or improving the data etc.  Based upon this, define and agree an approach to data conversion.

SUMMARY

Data from existing systems or business processes is usually required to be converted and transferred to the new system.  The needs for this should be apparent from a review of the overall implementation strategy defined in the Delivery Approach Definition (DAD).  If appropriate, further investigation may be performed to identify the needs for data to be converted.

Data availability and integrity is often wrongly assumed during design work.  In fact, existing data is rarely of good quality and often is insufficient for the needs of the new system.  A study should be made of the availability and integrity of the data.  Recommendations will be made for securing data as required.

PATH PLANNING GUIDANCE

Optional - may be used where existing data will be brought into the new system.

DEPENDENCIES

Prerequisites (Finish-Start):

• Delivery Approach Definition (DAD) or similar high-level definition of the design

Prerequisites (Finish-Finish):

• Definition of the requirements for data in the new system

Dependent procedures (Finish-Start):

• Design and development of conversion and interfacing programs (in Processes D600/D604 and D650/D656/D658)

RECEIVABLES

• Delivery Approach Definition (DAD) or similar definition of high-level design
• Current  Data Dictionary (if any)
• Data dictionary, data definitions or data models supplied with the package (if any)

DELIVERABLES

• Data Conversion Strategy IP (or BIP)
• Revised Segment Plan (if appropriate)

TOOLS

•        None

DETAILED DESCRIPTION OF TASKS

Defining the approach

An Implementation Paper (IP) or Brief Implementation Paper (BIP) should be used to define the requirements, issues and agreed approach.  Where the project is complex with different departments being involved, an IP is to be preferred as it allows full consideration and acceptance of the issues and the decisions.

The Implementation Paper may identify the:

• Requirements for data - data items, quality / accuracy required, extent to which items are mandatory
• Options available, e.g. various sources, ways of supplementing the data, ways of validating and correcting data, ways of converting and/or loading the data etc
• Recommended approach
• Details of how to implement that approach

Requirements and issues

A study may be required to identify key items of data required to meet the various functional requirements and designs.  Very often, this evaluation will need to take place in parallel with the detailed design of the functions.

The study will note the required functional content of the information, requirements for detail and/or summarisation, requirements for timing, likely average/peak volumes, priorities, importance, etc.  The study would normally be based upon information already established during the Requirements and Selection Segment, eg the corporate data model, detailed requirements, the System Vision, the Delivery Approach Definition (DAD), etc.  It is, however, common to find that requirements become further detailed or amended as a result of detailed design tasks.  Accordingly, detail should be kept at a high level unless vital to the conversion strategy.

The requirements should include the extent to which accuracy and completeness of data is necessary.  For example, historic management information may not need to be totally accurate, but the records of employees’ salaries must be absolutely correct.

These requirements for availability, accuracy and completeness of source data should be compared with the actual availability and condition of the data.  This will lead to the identification of requirements to improve, modify or supplement the existing data.

Options

Options to address the requirements for complete accurate data should be established.  These may include:

• Currently available data is acceptable
• Manual validation and correction
• by the user departments
• using outside clerical assistance
• Automated validation / manual correction
• by the user departments
• using outside clerical assistance
• Automated correction (eg postal codes)
• Ignore current data and collect new data from scratch (eg full inventory of assets)
• by the user departments
• using outside clerical assistance
• Convert / supplement data using tables etc.

Options to convert or load the data should be established.  These may include:

• Automated conversion using custom programs
• developed by the project team
• developed by the user organisation’s MIS department
• developed by the package vendor
• developed by a third party contractor
• Automated conversion using package facilities
• Manual data entry using the package
• by the user departments
• using outside clerical assistance
• Manual data entry in some other computer system followed by automated transfer
• by the user departments
• using outside clerical assistance

Recommended Approach

The benefits, costs, risks and timescales for the different options are reviewed and an approach is agreed.  Details of the overall approach will be given.   In many cases these will lead to additional custom programming and/or clerical work.

General details of how the data will be obtained, corrected, supplemented and converted should be stated.  This may include full details of manual procedures.  Detailed technical requirements should be made the subject of separate Technical Implementation Papers - see Processes D600 and/or D604.  The development, testing and implementation of these will then be undertaken - see Process D650 and/or D656/D658.  Where the recommended process is entirely manual, it may subsequently be considered and detailed in a normal Implementation Paper if further detail is necessary - see process D400 or D450.

The overall data conversion strategy should be reviewed and signed off by the project’s sponsor and other relevant managers within the client organisation.

Where necessary, appropriate changes should be made and agreed for the Segment Plan.