Previous Table of Contents Next


Documenting the Application. The systems, operations, and end-user documentation being developed throughout the development project should be finalized once the application is fully implemented. Trying to complete the documentation before that time creates the risk that changes made late in the process will not be reflected in the documentation. Waiting to develop the final documentation also creates the opportunity to include all final changes and corrections as well as a complete understanding of the lessons learned through the final development and implementation activities.

Performing a Post-implementation Application Review. The IT Audit Professional may find that application developers and users believe that the principles of total quality management, continuous improvement, and the like are contradicted by a subsequent review. The IT auditor must find a way to convey the fact that this review is critical if enterprise personnel are to get a chance to learn to do future development activities more effectively.

There is a significant risk that a post-implementation review will become punitive rather than constructive, particularly in the case of an application that has been delivered late or is over budget. The goal of the review, whether done by the IT Audit Professional, someone else, or a team, should only be to determine whether project objectives were met and whether there are any lessons that should be applied in the next development effort.

Failing to keep these reviews both constructive and objective is likely to lead to an environment where no post-implementation reviews are conducted. This situation is clearly not in the best interests of the organization.

The IT Audit Professional should also obtain a clear understanding of the identity and interests of the participants in each development effort. The following sections describe many, if not most, of the potential participants.

PARTICIPANTS IN THE SYSTEMS DEVELOPMENT LIFE CYCLE

The IT Audit Professional is likely to find that every project may have a unique or unusual organization participant, although that is certainly not automatic. Several of the most common participants have been identified below. Along with each identified participant there is an analysis of what responsibilities that specific participant may have in significant stages of the project.

Senior Management. The organization’s senior management will spend the least time involved in any development project, although their participation can easily be the most significant. Senior management is ultimately responsible for the success of the organization, making them responsible for all projects even if they have delegated the ability to make financial commitments such that entire projects are completed without the need for their approval or intervention.

One or more members of senior management may be involved at each stage of a project, if an approval from that level of signing authority is required. Otherwise, senior managers are more likely to be kept aware of the progress of important projects during staff meetings than any other direct participation.

Project Steering Committee. The existence of a steering committee is also likely to be contingent on the magnitude of the project, senior management’s need or desire to delegate authority, and the nature of the project itself. The project steering committee, if it exists, will almost certainly represent the first formal approval of critical project deliverables. This approval may cover some or all of the following:

  Functional requirements deliverable document
  Components of the project plan such as validation, verification, and testing
  Key deliverables from other project stages

The IT Audit Professional should remember that these approvals almost always represent the final step in one of the stages of the systems development life cycle methodology the organization has chosen to follow.

Project Sponsor. The IT Audit Professional can find that the project is sponsored by an individual or a team. The magnitude of the project is likely to determine that nature of the project sponsorship. The project sponsor may be responsible for one or more of the following items:

  Identifies and validates the original need or opportunity
  Develops the needs statement
  Directs the feasibility study and risk analysis
  Prepares the cost/benefit analysis
  Selects a project manager.

The project sponsor will have certain additional responsibilities if some or all of the development project is handled by contractors. If all or part of the life cycle effort is contracted, the project sponsor, in coordination with the project manager, incorporates a preliminary assessment of the need for contracted services in the life cycle stages. The IT auditor should be aware that utilizing the services of a contractor can require a long lead time; thus, the impact on the project schedule must be recognized and understood.

Project Team. The IT Audit Professional will need to determine if there is a project team that is separate from the project sponsor. If there is an independent project team, the team’s responsibilities may include one or more of the following:

  Updating the project plan
  Revising detailed subproject plans
  Developing end-user and other manuals
  Developing and maintaining the project plan and functional and data requirements documents

Information Technology Manager. The IT Audit Professional is not likely to find that the IT manager is a direct participant in every systems development project. The IT manager is too likely to have other commitments that would never permit direct participation in every project. When the IT Manager does participate in a specific project, that person is likely to have a more technical perspective on the related issues than the Project Steering Committee, although the basic responsibilities will be approximately the same.

Security Specialist. The security officer may have the role of security specialist in all projects, or may have designated agents drawn from the information systems or end-user populations. Further, the person or persons responsible for security may keep that responsibility directly, or may provide support so that other persons in the project handle the direct responsibilities.

Some of the possible responsibilities include the following:

  Consultations on security matters
  Reviews key deliverables
  Reviews system and subsystem components
  Evaluates database specifications
  Analyzes planned access controls
  Reviews test plans and related specifications

These reviews can be extended to encompass the end-user manual, operations manual, implementation plan, etc. All of these activities are likely to be focused on the security and internal control components of the items under review.

Internal Auditor. This is more likely to be an IT Audit Professional than a Financial Audit Professional or an Operational Audit Professional, although any of the above may satisfy these responsibilities. It is also possible the Internal Audit role may encompass the responsibilities that might be handled by the security specialist.

The IT Audit Professional should evaluate the need for independence and objectivity whenever there is a request that Internal Audit satisfy the responsibilities of the security specialist. Consistent with all professional activities, the line differentiating recommendations and decisions can become unclear, and responsibilities to the organization may compete with professional standards.

Any such conflicts can only be resolved at the time based on the specific context and issues of the situation. The IT Audit Professional can only be directed to consult with third parties as needed at the time.

Quality Assurance Specialist. The organization may have a separate quality assurance function with a different mission from either the security specialist or the IT auditor. Many of the responsibilities are the same, and the need for duplicate functions, if they exist, is one of the obligations of the IT auditor, even if the review is more operational than control oriented in nature.

The quality assurance specialist may review the project definition, the system design; validation, verification, and testing components and documentation; and the program definition, program code, documentation, and training to ensure compliance with the needs statement and IT standards.


Previous Table of Contents Next