Module 13

Project Auditing and Termination

Some of us have been audited by the IRS. Here's how it goes: The tax collectors have examined our tax return and determined that an audit is required. Sometimes a computer called our return to their attention because some numbers were not what the computer expected and sometimes the return was selected at random. The first step in the audit is for the IRS auditor go through the return and determine what records the taxpayer needs to supply. After the auditor receives the records, he will review them and "close" the audit, proposed an adjustment which will close the audit, or call a meeting. Sometimes the matter will go on from there and get very complicate and unpleasant. An IRS audit is one example of a financial audit. All major businesses go through periodic audits by accounting firms so that the accountants can attest that the financial reports of the firm are sound. No one likes to be audited by the IRS or an accounting firm. The auditor is looking for mistakes and will always find some. These financial audits are required by law or the financial institutions that lend money to our business or insure them.

Between the financial audit and the project audit Chapter 12 treat, some firms and the federal government have audits that are somewhat broader then financial audits. They relate to the integrity and management issues that are not financial or at least not directly reducible to dollars. They'll check on dollars too. Say we rent a car for our project office. A through "management" audit might check:

Did we go through the proper purchasing procedures when we rented the car? Seek competitive offers?

Has the car in fact been used for company business and not personal use?

Is there a car at all? (It is easy to print receipts to phony companies for services and supplies never received.)

Is the car still needed?

Have we been paying the rental bills? (We could have been making our current cash look good, by not paying our bills.)

 

Your author's treatment of project audits is quite good, although the reasons for the audits might vary considerably. The "project status" audit is really just an extension of the financial audit for firms that are on the accrual method of financial reporting, most construction companies for example. They have to express the "percent compete" of each project. For a brick and mortar construction project, this is usually straight forward. For a R & D project it is much more convoluted. And for a creative project, it may be much more difficult. Nonetheless upper management wants to know how much value the project has generated. Usually the cost to date can be ascertained at least roughly. The work complete versus the schedule can be more complicated. For example, on a construction project, if the owner has inspected the project and "accepted" portions of it, that work can be assume completed (usually). If the project involves delivering a whole machine or software package to the client, we may not know until later in the project if what we have done to date will work at all. The project team might have definite opinions about the work's status, but the client may have very different ideas. Hence auditing of these deliverables will take an audit team that has technical knowledge as well as insight into the client's needs.

For companies that have ongoing projects, the project audit might serve a "lessons learned" function for that project as well as similar projects by the firm. Lastly, the audit, as a management consultant, might be called in to make hard and unpleasant decision for the management, such as terminate the project or fire the project management. For this later role, the integrity of the audit team is crucial. Often upper management will firmly give the auditor the idea that upper management wants the auditor to conclude and report certain things. The auditor goes to the project and determines that the fault lays elsewhere. My advice for prospective auditors is to report what you find, even if the people who hired you want to hear something else.

Your author goes into details of audit procedures. These are good, but in practice these will be highly dependent on the institution You should, as you read, pay close attention to the human relations aspects of the audit. The auditor will be dreaded at best, yet cannot do his or her job unless the project people cooperate. This will take time and will likely happen in stages, if it is to happen at all. The last part of the chapter, A Note to the Auditor/ Evaluator, discussing "permission to enter the system" has some of the best personal advice I have seen in a textbook and it applies to much more than auditing.

With regard to project termination, all good things must come to an end. Bad things, however, might hang around for a long, long time. Good or bad, projects are never really complete, they approach completion asymptotically. At some point, however, the personnel must be laid-off or reassigned, the accounts must close, and "no one will be allowed to use that cost code on their time sheets." For some types of projects, termination is advisable before completion. For these a "decision to terminate" must be made. This may be a trivial matter of changing directions and giving a project a new name, or it may be a difficult decision, like the supercollider or some other project you are probably familiar with. As in several other chapters, your book does a good job of illustrating the human relations aspects of termination.

Module 13 Index

ESM 609 Home