Performing Cost-Effective Pre-Implementation Audits
                                   Part 2 of 2
                               By:  Mitchell H. Levine, CISA
                                  Audit Serve, Inc.
 

Traditionally only IT Auditors were involved in pre-implementation audits.  However, with the focus on the business operational controls which formed the basis of an integrated audit, financial and operation auditors need to be involved in the pre-implementation audit.

Determining the scope of the pre-implementation audit is dependent on how much time is allocated to the audit.  Assuming that the budget is limited, it is important to establish a scope which yields the greatest amount of coverage for the project along with identifying issues which could lead to major project failures. 

To obtain the greatest amount of audit coverage, the auditor should focus on areas which will be able to answer the following questions:

1) Does the new system meet the functional requirements of the business?

In order to answer this question, an assessment needs to occur to determine the level of user involvement to define the functional requirements for the new system being deployed.  Since the new system is not intended to be just a rewrite of the old system, it is important for detailed user requirements be established which covers all aspects of the business use of the new system such as data input interfaces, exception handling, and report interfaces.  It is important that the user controls the priority assigned to each user requirement.  Once the IT staff translates the user requirements to proposed system design specifications, which includes a specification of “whether and how” the user requirement will be designed, the user should have the ability to reject the IT staff design offering.  In some cases the user may be willing to accept operational workarounds in the absence of automated functions, but the user must be given the control of this decision. 

2) Are the project tasks defined in sufficient detail which identifies all of the components of the project?

3) Will adequate testing be performed to ensure that the system functions as intended?           

4) Will the data conversion strategy ensure that all data is migrated to the new system with integrity?

It needs to be understood that all data intended to be converted does not flow to reports which can be reconciled between two systems.  If the individual data component does flow to a report in some fashion, it may be consolidated data which would be identified as an out-of-balance condition which would require extensive analysis to disclose the root-cause of the problem.  In order to assess the degree in which converted data flows to the reports used to reconcile the data conversion, the auditor should review the data mapping tables and select a sample number of critical fields and trace them to the reports which would determine whether the data was not properly converted.

In terms of identifying the issues which could lead to major project failures, there are two areas of a system deployment which yields the most project failure; (1) inadequate data mapping and ineffective processes to validate the data conversion and (2) losing control of the reconcilement which supports the parallel test when it in intended to go live after the conclusion of the parallel test with no reconversion of the data prior to the “Go Live” date. 

Using similar reports between the current and new system was always the basis to determine whether the data conversion and parallel (i.e., entering similar transactions in the current and new systems) were successful. The most critical decision for the project is whether the parallel test is to be proceed directly to “Go Live” without a final data conversion.  If this approach is to be used, it is critical that formal reconcilement processes are established to validate that the data was properly converted and the daily transactions are entered correctly on both the current and new systems.  If the balancing and reconcilement is not successfully completed on a daily basis, the project would need to be suspended and a reconversion of data performed along with the restart of the parallel test.  The auditor needs to allocate the time to this critical phase of the project to ensure that control has not been lost during the parallel test.

For environments which have a high volume of transactions, a production parallel may not be possible.  In this case, a partial parallel test is performed using a subset of the daily transactions but the final “Go Live” data would be comprised of a final reconversion of the data.

It was not intended within this two-part the article to cover all aspects of a pre-implementation audit.  The next issue of Audit Vision will include a separate article which includes a compilation of additional tips on how to perform a effective pre-implementation audit.