INEN261: Chapter # 12 Project Auditing Presented by: Jasim Alnahas

Chapter Learning Outcomes If you complete the given assignments for this chapter you will: Understand the purpose of project evaluation Learn what the project review report should contain Understand the critical elements of the audit and the essential conditions for a credible audit 12- 2

Project Audit A formal review of any aspect of a project Audits focus on whatever matters senior management desires  Another type of audit is an ethics audit Evaluate means to set the value of or appraise Project evaluation appraises progress and performance against standard 12- 3

Purpose of Evaluation—Goals of the System Efficiency in meeting both the budget and the schedule Customer impact/satisfaction Business/direct success Future potential 12- 4

The Project Audit The main purpose of an audit is to help achieve the goals of the project All facets of the project are studied A project audit is equivalent to the application of TQM to project management 12- 5

Chapter 12 discusses “Project Audits” Project Audits are “more or less formal inquiry into any aspect of the project” I would prefer to use the term “Project Review”  Less confusion with the term audit as applied to financial evaluations The review is intended to compare the project progress and performance to the planned progress and performance or to similar project progress and performance Answers the question: “How are we doing?” 12- 6

How are we doing compared to what? How are we doing against the goals that we set out for the project The direct goals of any project are pretty straight forward  Performance (What is to be accomplished?)  Schedule (How long will it take to accomplish the performance?)  Budget (How much will it cost to achieve the desired performance?) The S curve or earned value chart depicts these 12- 7

How we are doing against schedule or budget is derived from this kind of review or audit Project Cost Calendar Time Project Start Project Completion Total Project Cost AC EV Cost Variance ScheduleVariance PV 12- 8

However projects also may have additional or “Ancillary Goals” Improved customer satisfaction Project team satisfaction or growth Organizational or enterprise achievement to further a strategic objective There are additional results apart from the direct goals of Performance, Schedule and Budget which can also be reviewed 12- 9

Designing a Project Review Process: What are the key questions in structuring the process? What constitutes project success? (What are the direct and ancillary goals of the project? How deeply should we review the Project? When should we review the Project? Who should perform the Project Review? How should the results of the review be documented? Where should the results of the review be published?

Should the review be limited to the Direct Goals of Performance, Schedule and Budget? Certainly the Direct Goals must be included in every review The criticality of the project to achieving broader organizational goals would determine whether ancillary goals should be added Examples  Client satisfaction may outweigh budget adherence where new markets are being entered  Technical quality may be vitally important when adding a service or product line

How deeply should the Project be reviewed? Project reviews take time and resources ($) to perform  The depth of project review is constrained by these two factors  Obviously the cost and time required for review should be a small fraction of the time and cost required for the project (Perhaps in the 5-30% range)

Project reviews have direct and indirect costs associated with them The direct costs are associated with the review team itself In addition, reviews are a “distraction” for the project team Time, energy and anxiety devoted to the review takes away from the level of effort devoted to project execution The results of the review can have morale damaging potential which can further erode project efficiency

Three levels of review depth: General, Detailed and Technical General review touches lightly on several general areas  The current status of the project  The future status of the project  The status of crucial tasks  An assessment of risk of project failure or financial loss  Lessons learned from the project  Limitations of the review

General Review May consist of reading monthly reports May be covered at routine meetings Review may not get below the stoplight level of evaluation

Problems uncovered via General Review may trigger a Detailed Review A review team is assembled and deployed They are sent in to explore the areas of concern uncovered in the general review The depth of the Detailed Review is a function of the seriousness of the findings from the General

When does it make sense to review a project? If we are reviewing for problems, the sooner they are detected the easier it is to fix. (Therefore the earlier the better particularly for technical reviews.) General reviews should be performed according to some calendar schedule. (Monthly makes sense for significant projects) Detailed reviews should be performed as needed or perhaps on a quarterly basis if done routinely

Who should perform the review? General reviews should be the responsibility of the PM.  The PM or the Project office should provide documented regular status reports of the project  Those reports should be monitored by the general management staff Detailed reviews would involve non-project staff  Look at the project with fresh eyes  Verify that things are going well  Provide assistance for trouble spots

Possible representation on a detailed project review team Project management staff Accounting/finance Technical specialists The client or customer Senior management Legal staff Human resource staff

Typical steps in a detailed project review: Assemble a small team of experienced experts Familiarize the team with the requirements of the project Audit the project on site After the completion, debrief the project’s management

Steps to carry out a review (cont.): Produce a written report according to a pre- specified format Distribute the report to the project manager and project team for their response Follow up to see if the recommendations have been implemented

How should the review be documented? General review formats may be contractual requirements We are trying to compare actual performance to predicted performance We are trying to identify and illuminate surprises We are trying to be constructive The reviews should be accurate and truthful

Typical format for a review or audit report  Introduction and overview  Current Status Cost Schedule Progress Quality  Future Project Status Recommendations for future work  Critical issues to monitor  Major areas of risk or concern  Limitations and assumptions of the review

Where do you publish the results? I generally subscribe to a full disclosure strategy  The best surprise is no surprise  If there is one, get it out early so that it can be addressed To the team To the management To the client

The document should be introduced via discussion Presentations should accompany the report When possible I would inform in the following order:  The project team  The management of the performing organization  The client or customer Inform all without delay

Summary of Chapter 12 The purposes of the evaluation are both goal-directed and also aimed at achieving unspecified ancillary goals The project review report should contain at least the current status of the project, the expected future status, the status of crucial tasks, a risk assessment, information pertinent to other projects, and any caveats and limitations

Summary (Continued) Audit depth and timing are critical elements of the audit A difficult responsibility of the reviewer is to be honest, objective and constructive in presenting the audit results Several essential conditions must be met for a credible audit: a credible audit/evaluation team, sufficient access to records, and sufficient access to personnel