To gain the benefits of plans and processes, projects must follow them properly. People can make mistakes, and under deadline pressures they tend to take shortcuts or expedient measures, often failing to follow processes correctly. To ensure compliance with the defined processes, an active effort is needed. Audits aim to fulfill this need.
The basic objective of audits is to ensure compliance with the defined process and to provide senior management with visibility into the use of processes. To ensure a reasonable degree of compliance, audits must be done regularly. They also must be formal, with a formal notice of noncompliance being issued and later tracked to satisfactory closure. Formality ensures that "personal equations" do not play a major role and that senior management gains visibility into process compliance through summary audit reports.
Who should conduct the audits? Ideally, the auditors should understand the processes of the organization and their importance, and should have the necessary maturity and stature to be able to assess the implementation on a project objectively. The auditors also need to be trained in the process of auditing.
At Infosys, project personnel from other projects perform the audit of a project, with SEPG providing the training. Every month, the audit coordinator announces an audit schedule that specifies which project is to be audited by whom and the focus area for the audit (which aspect of the process the audit should focus on). A team of two people normally conducts the audit.
In the audit, the auditors focus on whether the defined process is being followed in the project, paying greatest attention to the processes in the audit's focus area. They ask questions about how an activity is done, and they look at the evidence or outputs of these activities. They may use audit checklists to determine the questions. These checklists are derived from the approved processes and past experience, and they try to maximize the returns from an audit by concentrating on the key aspects rather than less important or peripheral issues. Here are parts of the checklist for project planning:
Is the project plan documented in the standard project plan template?
Has the project plan been group reviewed?
Has the project plan been approved and baselined, and is it under configuration management?
Is there a signed contract?
Have the commitments to the customer or other groups been reviewed?
Is there an estimated effort for the project that is based on historical data?
Have the effort estimates and the schedule been reviewed?
Is the quality plan complete, and has it been reviewed?
Is the life cycle used in the project identified and documented?
Are personnel identified and the responsibility for each work element defined and tracked?
Are reestimation triggers, such as scope changes and required corrective actions, defined?
Are deliverables to the customer, including user documentation, clearly identified?
Are risks and risk mitigation plans identified and properly documented?
Are reviews, progress reporting, tracking, and approval mechanisms identified?
The audit is considered complete when the audit team has asked all questions and looked at any desired artifacts. A noncompliance report (NCR) is issued if the evidence suggests that the approved processes are not being followed, or that some weaknesses exist in the process that might lead to loss of control or to suboptimality.
A key aspect of auditing (and one that is stressed in training) is that the procedure seeks to audit the compliance to the process and not to audit people. This idea is fundamental to the entire process-oriented approach; the focus should always remain on the process and process improvement, and problems found in a project should be attributed to process factors and not to people. The NCR clearly indicates the type of deviation found.
Identifying noncompliance is the goal of audits (and the analysis of audit results is used to evaluate the effectiveness of processes), but when two software professionals evaluate a project, they are likely to develop some ideas regarding the project's technical or management aspects that might be useful in improving the project. These issues often do not constitute noncompliance, but one would not like to lose this insight. Such observations are therefore recorded on a separate form as the auditors' suggestions. The audit reports, including NCRs and suggestions, are sent to the coordinator of audits.
The submission of the NCR is not the end of the auditing activity. Because the audit's basic purpose is to ensure that projects deploy the organization's approved processes, these reports should be used to make the necessary changes in the project so that any issue raised in the NCR is satisfactorily addressed. This step is called a corrective action. For each NCR, some corrective action must be taken. Once taken, it is recorded on the NCR form itself.
To ensure that the issue raised in the NCR is satisfactorily resolved, the audit coordinator ensures that the action is approved by the auditors. If these personnel are not available, the quality adviser for the project or the audit coordinator may approve the action. Once the action is approved, the NCR is considered closed.
Figure 11.10 gives an example of an NCR and its corrective action. This NCR specifies the project, the date, and the severity of the noncompliance. The severity indicates both the seriousness of the issue and its consequences (major or minor). Project personnel usually take the corrective action. In this case, the issue raised concerned requirements changes, which are handled generally by the project manager, who therefore instituted the corrective action. The date of the corrective action is also mentioned.
Sometimes, the issue is likely to recur, either in the same project or in other projects. In that case, in addition taking a corrective action, the project may need to take a preventive action to ensure that a similar problem does not crop up again. Hence, preventive actions might need to be taken in some situations. The NCR includes a section in which to record the preventive actions taken and who took them. Figure 11.11 shows an example of an NCR that required both corrective and preventive action. The preventive action for this NCR is to upgrade a checklist to ensure that a similar problem does not happen in the future.
At Infosys, an NCR must be closed within 60 days of the audit. Typically, the audit coordinator sends a reminder at the end of one month and another one a week before the time limit expires. NCRs older than 60 days are reported to the senior management for the project. This kind of formal follow-up ensures that audit reports are taken seriously and that the issues raised are addressed properly.