Much like true lessons learned sessions, real project audits are probably rarely conducted.  I’ve actually been involved in quite a few audits in the past – all on one very large government program that I was managing and they were conducted as part of a quarterly review of the program that was performed in conjunction with our customer, the U.S. Department of Education.

Ideally, a project audit should be conducted by an independent examiner, who can remain objective in the assessment of information. In my case, the project audit was performed by our own quality control department, but all results were presented and scrutinized by our government customer and they also – in most cases – participated in the audit process.

The audit must be conducted in a spirit of learning, rather than in a climate of blame and punishment. If people are afraid that they will be “strung up” for problems, then they will hide those problems if at all possible. Such a benign atmosphere, however, is hard to achieve. In many organizations the climate has been punitive for so long that people are reluctant to reveal any less-than-perfect aspects of project performance. When organizations continue ineffective practices because they intend to help individuals avoid embarrassment or are themselves trying to avoid looking bad to the customer what they really end up doing is preventing any organizational learning.  It is said that audits conducted like witch hunts will produce witches.

Simply put, an auditor with a blame-and-punishment mentality is certain to create more problems than solutions.

The Audit Report

Audits come in different styles—comprehensive, partial, and informal and cursory. A formal, comprehensive audit should be followed by a report that, at a minimum, contains:

Current project status

This is best shown by performing an earned value analysis.  However, when earned value analysis is not used, status should still be reported as accurately as possible.

Future status

This is a forecast of what is expected to happen in the project. Are significant deviations expected in schedule, cost, performance, or scope? If so, the nature of such changes should be specified.

Critical tasks

Status of critical tasks

The status of critical tasks, particularly those on the critical path, should be reported. Tasks that have high levels of technical risk should be given special attention, as should those being performed by outside vendors or subcontractors, over which the project manager may have limited control.

Risk assessment

Have any risks been identified that highlight potential for monetary loss, project failure, or other liabilities?

Information relevant to other projects

What has been learned from this audit that can or should be applied to other projects, whether in progress or about to start?

Limitations of the audit

What factors might limit the validity of the audit? Are any assumptions suspect? Are any data missing or suspected of contamination? Was anyone uncooperative in providing information for the audit?