Diving a little deeper PM audit process as described in the book “Information Technology Control and Audit”, we will look at the audit planning, the actual PM process review, the act of working with the PM and team to identify risk, and the communications necessary to ensure that the audit process is as successful as possible.
The audit plan will detail the objectives and the steps to fulfill the audit objectives. As in any audit, a project management audit will begin with a preliminary analysis of the control environment by reviewing existing standards and procedures. During the audit, these standards and procedures should be assessed for completeness and operational efficiency. The preliminary survey should identify the organization’s strategy and the responsibilities for managing and controlling development.
Project Management Process Review
A project management process review would assess the adequacy of the control environment for managing projects. The review points listed represent checkpoints in the project management process. Auditors can use these checkpoints to determine both the status of the project’s internal control system and the status of the development project itself. These reviews eliminate the necessity of devoting large amounts of audit resources to the development effort. As long as the development process is well controlled, the need for audit involvement is minimized.
Auditors may assist the project manager in identifying project risks and evaluating plans to mitigate and manage risks (e.g., training, devoted resources, management support, and end-user commitment). Auditing can provide management with an independent review of project deliverables (e.g., project charter, task list, schedule, budget). Auditing may also review the project task list and budget to verify that all project tasks are defined and all milestones have a deliverable.
During the planning phase the auditor can facilitate communication between functions and raise issues that may impact the quality or timeliness of the project. In a development project, resources from various departments need to come together to implement an automated process that may affect multiple user functions. Because of various audit projects, auditors develop an overall knowledge of the organization and establish relationships in multiple departments. These relationships are helpful in a development project for making sure information is flowing between the development team and other functionaries. Consider the following groups:
- Primary users
- Secondary users
- Vendors and consultants
- Programmers and analysts
- Database administrators
- Testing teams
- Computer operations
- Interfacing systems
- Implementation team
- Production support (i.e., maintenance programmers)
Verify that adequate resources are assigned responsibility for tasks and have the time to complete assignments. This includes development, computer operations, user, and support functions (e.g., help desk).
The first area to communicate is the auditor’s role in the systems development project. It is very important to make sure that the management and development teams’ expectations of the auditor’s role are understood and communicated to all participants. In order to influence the systems development effort, the auditor must develop an open line of communication with both management and users. If a good relationship between these groups does not exist, information might be withheld from the auditor. This type of situation could prevent the auditor from doing the best job possible. In addition, the auditor must develop a good working relationship with the manager, the analysts, and the programmers. Although the auditor should cultivate good working relationships with all groups that have design responsibilities, he or she must remain independent.
Throughout the development project, the auditor will be making control recommendations. Depending on the organization’s culture, these recommendations may need to be handled informally by reviewing designs with the project team or formally by presenting recommendations to the steering committee. In either case, the auditor must always consider the value of the control recommendation versus the cost of implementing the control. Also, recommendations should be speci?c, identifying the problem and not the symptom. This allows the proper controls to be implemented and tested.
Recommendations are often rejected because of a time and cost factor. Managers may sometimes feel that implementing an auditor’s recommendations will put them behind schedule. The auditor must convince management that if the recommendations are not implemented, more time and money will be spent in the long run. Informing management of the cost of implementing a control now rather than shutting down the system later to repair it or leaving possible exposures open will help convince management of the need to spend time and money now.