Project Delivery Process D896

D896 - Conduct Final Production / Data Control Review

DEFINITION

Confirm that the production and data control staff are prepared for the implementation of the new system.  Prepare and distribute additional system documentation if necessary.

SUMMARY

The purpose of this activity is to conduct a final review with the production and data control staff focusing on:

• balancing procedures
• data entry procedures
• run request procedures
• retention rules
• run parameter options
• control report frequency, media, volume and distribution requirements.

PATH PLANNING GUIDANCE

Optional - may be included in the work for Decision to go Live - Process D900.

DEPENDENCIES

Prerequisites (Finish-Start):

• Plan, prepare and conduct technical tuning and volume testing - Process D810
• Define, plan and agree handover / cutover - Process D830
• Plan and instigate phased transition to live operation and support and phasing out of Project Team support - Process D870
• Prepare and instigate operators’ instructions, procedures and manual - Process D720
• Implement 'live' client systems - hardware/software - Process D662
• Implement live communications & network - Process D664
• Implement 'live' server systems - hardware / software / database - Process D666
• Set up, transport and verify live configuration - Process D668

Prerequisites (Finish-Finish):

• Plan, prepare and conduct operations training - D770

Dependent procedures (Finish-Start):

• Decision to go live - Process D900

RECEIVABLES

• (none)

DELIVERABLES

• Production / Data Control Final Review

TOOLS

• (none)

DETAILED DESCRIPTION OF TASKS

A final review is conducted with the production and data control staff focusing on:

• balancing procedures
• data entry procedures
• run request procedures
• retention rules
• run parameter options
• control report frequency, media, volume and distribution requirements.

All parties need to accept that the system is sufficiently well implemented to be sustainable during live running.  This does not mean that it must be faultless.  In fact, it is common for there to be many minor flaws in the operational set up and procedures at this time.  The key point is that the system can be operated safely within the anticipated operational requirements and user needs.

Information sources:

• operations management
• system documentation and procedures
• installation standards and procedures
• operations manual
• detailed deployment (migration) plan
• operations staff system final review.

Content of the documentation may include:

• agenda
• presentation/review materials
• results of meeting.

It would normally contain reports, procedures documents, charts, diagrams, and text.

Responsibilities:

Project Mgt	Reviews team members’ work and assists in scheduling technical support review sessions.
User Coord	Reviews team members’ work.
Tech Mgt	Participates in production and data control reviews, recommends additional procedures, activities or documentation necessary to support the production system.
Team/IR	Prepares final review and support materials, conducts system implementation review meetings with technical support staff and assembles, copies and distributes any additional technical support documentation required.

Project Delivery Process D895

D895 - Conduct Final Operations Review

DEFINITION

A final review that the operations staff is ready to take control of the system and that they accept the system as delivered to them.

SUMMARY

The purpose of this activity is to conduct a final review with Operations staff regarding the readiness of operational facilities and procedures such as:

• Jobstream narratives
• Schedules and priorities
• Job setups
• Network procedures
• File cataloguing
• Backup and recovery
• Resolution of any pending issues and open scheduling questions
• Distribution of forms, manuals, and procedures.

PATH PLANNING GUIDANCE

This process is optional.  Operational readiness can be reviewed and agreed as part of the decision to go live (Process D900).

DEPENDENCIES

Prerequisites (Finish-Finish):

• Prepare and instigate operators’ instructions, procedures and manual (D720)
• Plan, prepare and conduct operations training (D770)
• Plan, prepare and conduct technical tuning and volume testing (D810)
• Define, plan and agree handover / cutover (D830)

Dependent procedures (Finish-Finish):

• Decision to go live (D900)

RECEIVABLES

• Operations documentation and procedures
• System documentation and procedures
• Installation standards and procedures
• System Handover Plan (D830)

DELIVERABLES

• Operations Staff System Final Review

TOOLS

DETAILED DESCRIPTION OF TASKS

This task is the final review before going live by the operation staff.  Most aspects will already have been reviewed and accepted during earlier processes. In this process, it is ensured that all necessary aspects have been completed to a reasonable level and are accepted by Operations staff.  Note that acceptance does not require perfection.  In many situations it is reasonable to go live with known deficiencies provided that these do not impact upon the overall business solution and do not impose unreasonable risks.

The review may include the following:

• format and sample of all reports generated from Operations,
• agree and approve all Operations procedures,
• agree and approve the format of all charts, diagrams and any other relevant information in which operation will be reporting on,
• agree and /or recommend additional procedures, activities or documentation necessary to accomplish a successful production cutover,
• final review of the effectiveness of operations training,
• final review of all Operations manuals and any additional operational support documentation,
• review of the adequacy of cutover plans and fallback plans.

Along with the agreement of the reporting and documentation for Operations, it is required that an agreement is reached with Operations that they are ready for live running and that an effective fallback plan is in place in case of system failures.

Project Delivery Process D890

D890 - Acceptance of Start-up Data

DEFINITION

Start-up data for live running should be verified and accepted by the responsible user managers.

SUMMARY

Data conversion and loading processes will have been conducted.  Reports and enquiries will be used to verify the condition of the data.

Responsibilities for validating and accepting the data should  have been agreed in advance as part of the System Handover Plan IP.  It may also be useful to agree in advance the precise tests and acceptance criteria.

PATH PLANNING GUIDANCE

Normal practice

DEPENDENCIES

Prerequisites (Finish-Start):

• System Handover Plan IP

Prerequisites (Finish-Finish):

• Data conversion and data load

Dependent procedures (Finish-Start):

• Decision to go live
• live running

RECEIVABLES

• System Handover Plan IP
• Converted data

DELIVERABLES

• Data Load signoff

TOOLS

• Test Objectives
• Test Definitions
• Test Control Log
• Test Incident Reports
• Test Incident Control Log
• Test Sign offs

DETAILED DESCRIPTION OF TASKS

The conversion and data load of live data will be carried out in Process D880.  Appropriate reports and validation processes are run and the start up position is reviewed.  Based on these tasks, the responsible user managers should formally accept the starting position.

Conducting the Tests

In most cases, control totals can be used to compare the existing data on the old system with the new converted data.  Total values, record counts, hashed-random counts and sampled records can be tested to make sure they match the old system.

Attention should also be paid to cross-checks, particularly where the data has been constructed without the normal processing and validation of the package.  For example, important checks may include:

• account balances are in balance,
• financial totals in other systems match control totals in the general ledger, eg total stock values, total creditors, total debtors,

Some types of data are difficult to validate completely using control totals.  For example, it cannot easily be checked that all employees’ bank account details are correct.  In such cases sampling techniques may be used, or, in the case of critical data, a complete manual check can be made.

It may be appropriate to prepare and agree specific tests in advance.  These can optionally be defined, agreed, controlled and signed off using the same approaches that are defined for normal system testing.

Conversion is usually undertaken while the old system is frozen and no live business is being conducted.  Accordingly it is important to complete the process, verify the data and sign off the start-up data as rapidly as possible.   Appropriate arrangements should be made for the required staff and managers to be available.  Preparation and prior agreement of the approach and tests can be very useful in achieving a timely acceptance of the data.

Error resolution

Data is rarely 100% accurate.  The business risks of some invalid data should be balanced against the costs of obtaining perfect data.  It is important that the start up of the new system is not unreasonably delayed by errors that can be resolved after it is live.  Note should be taken of any non-critical errors that are detected so that they can be addressed as soon as possible after live start up of the system.  If appropriate, the same error notification and resolution procedures can be used as defined for system testing (see Process D800 and test forms 4 and 5).

Signoff

The responsible users should indicate their acceptance of the starting position.  This may be in writing if appropriate.  The Test Sign off form may be used.

Signoff should not require a large number of reviewers or a highly formalised process as this might unreasonably delay the cutover process.

Project Delivery Process D880

D880 - Load Live Start-up Data

DEFINITION

All initial start-up data should be collected, prepared and loaded.  This includes manual or automated preparation and cleanup tasks in addition to the running of conversion suites and manual data entry.

SUMMARY

This process covers the setting up of live start-up data.  Live data includes:

• master file data, including balances etc
• transactions in progress
• historic information if required.

The two primary methods used to load data are manual data entry and the running of automated conversion suites.  Preparatory tasks may also be appropriate, for example to verify, clean up or supplement the old data.  Very often these preparatory tasks may have started months before the final conversion process.  The overall approach will usually have been considered and signed off in preceding Implementation Papers.

Once the data load has been completed, the start-up data will be verified and signed off by the responsible user managers - see Process D890.

PATH PLANNING GUIDANCE

Normal practice

DEPENDENCIES

Prerequisites (Finish-Start):

• Data Conversion Strategy IP - Process D180
• Preparation of Data Conversion IPs (either technical IPs - see processes D600 / D604 or normal IPs for manual processes - see processes D400 / D450.

Prerequisites (Finish-Finish):

• conversion programming and testing (see processes D650 / D656)
• system handover plan (see Process D830)

Dependent procedures (Finish-Start):

• sign off of converted data (D890)
• live running (D900)

RECEIVABLES

• Working conversion suites
• Data Conversion Strategy IP - see Process D180
• Data Conversion IPs - see Process D400 / D450 / D600 / D604 as appropriate
• System Handover plan IP - see Process D830

DELIVERABLES

• Start up data

TOOLS

• (none)

DETAILED DESCRIPTION OF TASKS

The preparatory tasks and conversion of live data will be carried out in accordance with the System Handover Plan IP using the techniques agreed in the Data Conversion IPs and the Data Conversion Strategy IP.

Data validation and purification

Well before the final conversion of data, tasks may be undertaken:

• to improve the quality of the data,
• to collect new or supplementary data,
• to validate the current contents of data,
• to archive or delete old unnecessary data.

These tasks are usually handled by the normal administrative staff responsible for the aspect of the business.  In some cases they will be assisted by standard reports from the old system or by custom validation, reporting and extraction programs developed as part of the project.

Whether or not data clean up procedures have been formally defined, the users should be encouraged to improve the quality of the data prior to conversion - it is often invalid data which leads to problems with the conversion process.

Automated Conversion Programs

If appropriate, data conversion suites will have been defined, designed, developed, tested and accepted.  Conversion programs are often only used once for live purposes (although test or dummy conversions may have been made to prove the programs work properly).  In some cases these programs may have been developed to lower standards with less documentation and testing.  Inevitably, there will be concerns about achieving the conversion within the time and resource constraints available.

Conversion suites will often include validation and reporting functions.  These will be used to check that the conversion has been correctly performed.  Auditing needs will normally require that the transfer of data to the new package has been performed correctly.  The transfer of data should be traceable, which means that records should be kept detailing:

• the original data set,
• the conversion routines including program source codes and explanatory descriptions, and
• the resulting data in the new package.

To make the conversion routines auditable, checksums for totals and subtotals for reasonable sort-criteria (eg number items transported or amounts posted in total and per category) should be documented and checked before production starts.  A formal sign-off by the user department that data has been transported correctly into the production system avoids later problems of data integrity after system startup.

Manual Data Load

Manual techniques may be used to enter live start-up data - it may often be more efficient to use this approach than to develop and test a major suite of programs.  This will have been considered and agreed in the appropriate Implementation Papers.

Normally, the package’s standard data entry facilities will be used.  This has the advantage of invoking the package’s full validation routines.  People entering data will require adequate training in using the relevant facilities of the package for manually loading data.  This experience can sometimes act as an excellent consolidation of the training for the people concerned.

In some cases, the normal data entry process will be inappropriate, for example, it may not be possible to backdate the depreciation calculation for a new asset so that an old asset can be entered through the normal facility for new assets.  Most packages, however, provide some automated support for normal types of live data set up.

For very high volumes and high productivity, it may be possible to set up an alternative form of manual entry, for example, using a “key-to-disk” system to set up batch records for processing through the system.  Combined with specialist data-entry staff this can provide a very rapid manual take on of data.

Staff will often be required to work unusual hours or in unfamiliar ways or conditions.  Temporary specialist data-entry staff can often be hired to help.  Such details need to be agreed with the appropriate bodies within the client organisation.

Manual techniques will lead to a significant error rate.  Appropriate measures should be taken to validate the data, to minimise the number of errors and to minimise the impact of those errors.  It is, however,  normal to assume that data is never 100% accurate and the business risks of some invalid data should be balanced against the costs of obtaining perfect data.

Just as in automatic data conversion, audit checks with checksums for totals and subtotals for reasonable sort-criteria should be documented and signed-off to make sure that the data-entry figures correspond to old data.  Adequate records should be kept to preserve the original version of the information and to track the way in which it has been converted and input to the new system.