Auditor’s Guide to IT Auditing, Second Edition

By Richard E. Cascarino
Copyright © 2012 by Richard E. Cascarino

22
C H A P T E R T W E N T Y- T W O

Audit Role in Feasibility

Studies and Conversions

T
H IS C H A P T ER LO O K S at the auditor’s role in feasibility studies and conver-
sions. These are perhaps the most critical areas of systems implementation, and
audit involvement should be compulsory.
In considering the auditor’s role in feasibility studies and conversions, we must
consider where they fall in the Systems Development Life Cycle (SDLC). The typical SDLC
comprises:

▪ Problem definition and feasibility study

▪ Analysis and design
▪ Language selection
▪ Coding
▪ Testing and debugging
▪ Documentation
▪ Conversion
▪ Implementation

FEASIBILITY SUCCESS FACTORS

As previously noted, acquisition of information systems involves, fi rst, definition of a

computer strategy including evaluation of the organizational requirements. Second,
establishment of the requirements including a thorough examination and evaluation

237

c22.indd 237 1/31/2012 8:56:22 AM

 238 ◾  Systems and Infrastructure Lifecycle Management

of potential alternative courses of action. Third, the precise specification of the require-
ments including interfacing all future systems with existing hardware and software
constraints, conditions of supply, and future modification. Fourth, evaluation of alterna-
tive sources of supply, and finally, the acquisition and installation of the systems. The
second stage is typically carried out via a feasibility study.
Factors to be considered in audit involvement in feasibility studies are those sur-
rounding the probability of a successful outcome. These usually focus on the overall
desirability of a system from a corporate perspective, as well as the likelihood of suc-
cessful implementation. Where the system is to be developed in-house as an option,
the skills required to develop it must be considered and in any event the skill levels
required to run the system will be an obvious factor. Both the cost of development/
acquisition of the systems and the cost of eventual running must be considered. If the
degree of integration with existing systems and with existing hardware is low, there
may be a requirement for special bridges into these systems. This commonly means
that significant parts of the systems being replaced end up being retained indefinitely,
and much of the cost advantage is lost. It is part of the auditor’s role to ensure that
such hidden costs have been considered and that the critical success factors have been
correctly identified.
In order to ensure that internal controls over the process are both efficient and
effective, the auditor must determine that an effective structure exists to ensure
that a proper analysis of the IT requirements can be made and that the acquisition
or development procedures can be effective in ensuring the selection and acquisi-
tion of appropriate hardware and software. The auditor must determine that the
appropriate evaluation criteria have been established in advance of the feasibility
decision and the feasibility process has proceeded in an unbiased manner in order
to ensure that the IT requirements of the organization are met in the most efficient
and effective way.
The feasibility study must cover points such as a clear statement of the business
and information processing requirements that the new or amended system is intended
to cover. In addition, the integration of the new or amended system into the existing
information technology (IT) architecture must be spelled out in order to maximize the
probability of success of the developed or acquired system. Where system alternatives
have been considered, the feasibility study must demonstrate the strengths and weak-
nesses of each alternative considered so that the final decision to proceed or not to pro-
ceed can be clearly understood. Where an in-­house-­developed solution is decided upon,
the feasibility study may be incorporated into the overall systems definition document
but should nevertheless include sections on:

▪▪ Overview of the proposed system in business functionality terms

▪▪ Technological alternatives considered together with the cost-benefit analysis of
each
▪▪ Analysis of the alternative courses of actions compared to the selection criteria
▪▪ Analysis of the costs and benefits associated with each alternative

c22.indd 238 1/31/2012 8:56:22 AM

 Audit Role in Feasibility Studies and Conversions  ◾ 239

▪▪ Operational, security, and control risks associated with each alternative together
with the control structures considered for risk minimization of each
▪▪ Availability of resources internally and externally to carry out the appropriate
development or implementation
▪▪ SDLC methodology to be applied under each alternative including the monitoring
mechanisms to ensure systems delivery on time and within budget

At this stage the auditor must determine that the detailed requirements of the user
area have been properly identified and agreed on, and the costs and benefit estimates
used in the feasibility study are reasonable and have been derived from the appropriate
sources. Time, resource, and cost budgets must be complete and structured in detail
so that ongoing monitoring and project control can be effected. The auditor should be
alert for information that may be incomplete or inaccurate in selecting among alter-
natives or, indeed, for selected alternatives that are not supported by the information
provided. Where inadequate details have been included regarding the planning, control,
and project management of the system, the auditor must draw this to management’s
attention. While it is not the role of the auditor, at this stage, to evaluate IT skills avail-
ability, nevertheless it is part of the role of the auditor to ensure that such an evaluation
has taken place in order to ensure the required skills are available both from a technical
and business perspective to ensure a successful implementation of the project as well as
the ongoing maintainability of the future system.
As can be seen, the feasibility study document is a critical part of the develop-
ment process in order to ensure a high probability of successful implementation.
Insufficient attention paid to this stage can result in the development or acquisition
of expensive, inappropriate systems that do not fully address the IT requirements of
the organization. At this stage little expenditure has been made but a wrong deci-
sion here can lead to many millions being invested to little effect as well as the loss
of significant amounts of time in gaining strategic advantages. Too many feasibility
studies are conducted as a matter of course, although the go-ahead decision has
already been made and the feasibility study is simply intended to support this deci-
sion whether or not there are clear benefits, tangible or intangible, and whether
or not there are unacceptable risks in either the development process or the imple-
mentation of the intended system. It must be clearly understood by all concerned that
an acceptable finding of the feasibility study could be not to proceed with any systems
development or acquisition.
The typical structure of a feasibility study would normally include:

▪▪ Executive summary of the business objectives, anticipated costs, expected benefits,

and possible risks of the proposed investment
▪▪ Business background and needs or opportunities leading to the desire for interven-
tion in this area including any statutory requirements
▪▪ The service delivery requirements and impacts on existing IT processing as well as
other user functional areas

c22.indd 239 1/31/2012 8:56:22 AM

 240 ◾ Systems and Infrastructure Lifecycle Management

▪ Business disruptions anticipated as a result of the development, conversion, and

implementation process including the acquisition or training of staff within the
user area
▪ Evaluation criteria used to select among alternatives
▪ Alternatives considered as specified previously
▪ Proposed solution in terms of specific deliverables, technical tools required to sup-
port the solution, changes to business processes and organizational structures
required to support the implementation of the eventual system
▪ Project management roles and responsibilities as well as the proposed project orga-
nization; controls; quality assurance strategies; estimated time frame; and the
major project phases, roles, and responsibilities
▪ Cost-benefit analysis proving the viability and desirability of the proposed solution
▪ Ongoing maintenance plan together with costs and resource requirements once
the system has been fully implemented

Once a decision has been made to go ahead based on the feasibility study, systems
development may proceed as detailed in Chapter 18. Once the system is ready to imple-
ment, conversion to the new system must take place. Again, this is a critical phase that
can make or break the successful use and long-term viability of the new system. Audit
involvement at this stage is essential.

CONVERSION SUCCESS FACTORS

Successful systems conversion is not a matter of chance. The roles in the conversion
process must be defi ned at an early stage so that those responsible may identify the
existing sources of data that will be used as well as identifying any new sources of
data required.
An assessment must be done of the quality of data available and any conver-
sion routines required must be identified and specified. Given the one-time nature of
such conversion routines, there is a temptation to minimize the system testing. These
conversion routines will require their own testing cycle to ensure their effectiveness,
but once again this will largely be a factor of the quality of the input data. Rubbish
in—rubbish out!
The auditor must ensure that this has been taken into account and any data-
sanitation programs required have been developed and implemented. The measuring of
the effectiveness of sanitation programs is a management function that may also require
auditor evaluation. The overall conversion effectiveness must ultimately be evaluated
and conversion signoff must be confirmed.
It is critical that the auditor determine how the conversion process will be verified
to ensure the accuracy, completeness, and validity of the data converted.
Conversion audit activities will typically focus on both the planning and implemen-
tation of the operational changes required within the organization as well as the data
conversions of the IT system itself. The conversion project will already have identified

c22.indd 240 1/31/2012 8:56:22 AM

 Audit Role in Feasibility Studies and Conversions  ◾ 241

the various operational and system changes to be implemented and the auditor will
typically review and assess the overall project plan as well as a project management
approach. Tasks for the IT auditor will include:

▪▪ Evaluating management’s project plan as well as the control and measurement

models
▪▪ Evaluating the overall systems and data structure design including access control
▪▪ Reviewing testing plans and evaluating the effectiveness of actual testing carried
out including user-acceptance testing
▪▪ Reviewing data-conversion plans and ensuring the accuracy and completeness of
data converted
▪▪ Reviewing the design of back-out plans intended to recover to current status should
problems be encountered on commencement of the new systems
▪▪ Reviewing management’s control of the actual startup process of the new systems

c22.indd 241 1/31/2012 8:56:22 AM