What do you mean by project audit?

Answer 1

Project Audit

Overview

Projects rarely run through their full life without some surprises. Sometimes the reasons for this are quite reasonable: requirements change, the team learn more about the problem, third-party software turns out not to perform as advertised. But other surprises are symptoms of underlying problems: the technical architecture is flawed, the team structure is making efficient working difficult, the plan is simply much too optimistic, and the project is doomed to cost more than we thought.

It is hard for the customer or project sponsor to work out which situation they are in before it's too late to fix problems economically. That is where a project audit comes in: an independent assessment of some or all aspects of the project's health buys at the least peace of mind, and in other cases can make the difference between problems nipped in the bud and a project whose timescales and costs are out of control.

The primary purpose of a project audit is to find the reasons for uncomfortable symptoms in the project, and answer questions posed by the sponsor or senior manager. These might include:

• Am I being told the truth about the current state of the project?
• Is the project going to deliver something that meets my requirements?
• Is the technical approach being used appropriate?
• Should I believe the project plan?
• Is the project organised appropriately, and are the project processes being followed optimal?
• Is the project following industry best practices?
• What should be changed to improve things?

The output of a project audit should be answers to these questions, giving practical and specific advice on fixing any problems uncovered, and guidance on improving efficiency for the future.

Syntropy normally assigns two consultants to a project audit because pair working greatly speeds up the analysis process, and, for most project audits, time is of the essence. Depending on the project size and the depth and range of the analysis required, the duration of an audit can range from 5 days up to several months, with costs from £6,000 to £75,000 (plus expenses and taxes).

Areas of investigation

The list below spells out the full range of issues that a Syntropy project audit might address. In many cases the symptoms that first sparked the requirement for an audit point to particular areas. In such cases, we normally start by specifying the scope as a subset of this list. We expect to review the work in progress regularly (at least weekly) with the sponsor, and this allows us to shift the focus as the analysis reveals more details about the situation.

Project management

• Does the project communicate effectively with its sponsors and other stakeholders?
• Are decisions taken rationally and quickly?
• Do the management team have appropriate skills and experience?

Project organisation and staffing

• Is the project divided into effective work units (teams)?
• Are the teams located appropriately?
• Are responsibilities clear?
• Is internal and external communication effective?
• Do the staff have appropriate skills and experience?
• Are staff working in a suitable physical environment?

Project processes

• How are tasks identified and allocated?
• How is progress measured?
• How is change handled?
• Is there proper version and configuration management?

Project planning and reporting

• What kind of plan is there?
• Is the level of detail appropriate?
• How is the plan validated?
• How is progress against plan reported?
• Is the project actually at the point where progress reports say it is?
• How feasible is achieving the future goals in the plan?

Technology choice and usage

• What tools and technologies are being used?
• Why were these tools and technologies selected?
• Is the selection in line with industry best practice?

System architecture

• How do the pieces that make up the solution fit together?
• Can the solution meet the quality requirements (speed, load, reliability, etc.)?
• How are technical decisions made? Is there a design authority?
• How are technical decisions recorded?
• How is technical feasibility demonstrated?

Functional requirements

• What is the requirements analysis process?
• Do users feel involved in the process?
• Are the requirements clear, complete and consistent?
• What kind of design documents are produced?

Code quality

• Are coding standards in place and followed?
• Is the code clear, efficient and well-organised?

Testing

• What kinds of testing are carried out?
• Is there a "test first" or "test driven" philosophy?
• Is testing automated?
• How are test cases identified?
• What kinds of test tools are used?

Audit processInitiation

The process of carrying out a project audit starts with initiation. In this activity we meet with the sponsor to agree the scope of the audit, list the questions that need to be answered, and gather basic facts about the

project such as scale, locations, goals, history, and progress to date. The output of the initiation is a proposal for the audit which details the goals of the audit, its timescales and costs. We normally regard initiation as being carried out at Syntropy's expense.

Enquiry and reporting

The twin tasks carried out during the audit are enquiry and reporting. The traditional style of audit involves a lengthy enquiry phase with a final report appearing at the end. This approach has some problems:

• no time is left to redirect the audit's focus in the light of issues raised
• all remedial action has to wait until after the audit is complete
• it is difficult to get the correct balance between time spent identifying problems and time spent devising and syndicating solutions

To address these problems, we prefer to run the enquiry and reporting phases in parallel.

Enquiry tasks

The first step is to understand the project "map" (who is who, what are they doing, where are they doing it) and status (where are they up to). This is normally accomplished by reading background documents and talking to the sponsor and project manager.

The second step is to select interview candidates, and then to carry out

interviews. Some interviews will inevitably raise further questions and lead to subsequent rounds of interviewing, revisiting some people and meeting other sources. Interviewees may be drawn from both in- and outside the project team.

Simultaneously, we would normally acquire and study relevant project documents and files during this process. Where the project includes developed software, it may be appropriate to study this work, both by investigating the operational software and by carrying out reviews of the code.

Reporting schedule

We would expect to produce status reports and briefing papers for the sponsor regularly throughout the review.

Status reports are produced daily for very short reviews, weekly otherwise. They describe the meetings and other work carried out on the project, highlight the most important issues that arise, and record any obstacles to progress encountered. These are invariably accompanied by regular informal communication so that the sponsor is always aware of current "hot topics" in the review.

Briefing papers are produced to discuss problems identified and suggest possible solutions; these are produced irregularly but as soon as possible within the process, to let the sponsor act quickly on each finding.

A first version of the final audit report is generated approximately 75% of the way through the audit process. The content of the audit report will have largely appeared previously in the status reports and briefing papers, and so should not contain any surprises. The report contains both the results of enquiries (i.e. the true state of the project) and recommendations for dealing with problems found.

Final audit report contents

• Summary
• Background
• Quantified risk assessment, showing for each major risk:
• ** o Nature of risk
  • o Risk likelihood
  • o Risk avoidance strategies
  • o Outcomes if risk materialises (with probabilities for best vs. worst cases)