Project Evaluation

Project Evaluation: To evaluate a project is to attempt to determine whether the overall status
of the work is acceptable, in terms of intended value to the client once the job is nished. Project
evaluation appraises the progress and performance of a job and compares them to what was
originally planned. That evaluation provides the basis for management decisions on how to
proceed with the project. The evaluation must be credible in the eyes of everyone affected, or
decisions based on it will not
The primary tool for project evaluation is the project process review, which is usually conducted
at major milestones throughout the life of the project.

Purpose of Evaluation:
Sports teams that practice without reviewing performance may get really good at playing very
badly. That is why they review game lmsto see where they need to improve. In other words,
the purpose of a review is to learn lessons that can help the team to avoid doing things that cause
undesired outcomes and to continue doing those that help. The review should be called a lessonslearned or process review.
As Dr. W. Edwards Deming has pointed out, there are two kinds of organizations in this world
todaythose that are getting better and those that are dying. An organization that stands still is
dying. It just doesnt know it yet. The reason? The competition is not sitting by idly. It is doing
new things, some of which may be better than what you are doing. If you arent improving, you
will be passed by, and soon you wont have a market. The same is true of every part of an
organization. You cant sub optimize, improving just manufacturing.
You have to improve every department, and that includes how you run projects. In fact, good
project management can give you a real competitive advantage, especially in product
development. If you are sloppy in managing your projects, you dont have good control of
development costs. That means that you have to either sell a lot of product or charge large
margins to cover your development costs so that the project is worth doing in the rst place. If
you cant sell a lot of widgets, then you have to charge the large margin.
However, such a process review should not be conducted only at the end of the project. Rather,
process reviews should be done at major milestones in the project or every three months,
whichever comes rst, so that learning can take place as the job progresses. Furthermore, if a
project is getting into serious trouble, the process review should reveal the difculty so that a
decision can be made to continue or terminate the work. Following are some of the general
reasons for conducting periodic project process reviews. You should be able to:
Improve project performance together with the management of the project.
Ensure that quality of project work does not take a back seat to schedule and cost
concerns. Reveal developing problems early so that action can be taken to deal with
them.
Identify areas where other projects (current or future) should be managed differently.

 In order to learn, we must have feedback. Furthermore, we tend to learn more from
mistakes than from successes, painful though that may be to admit.
Keep client(s) informed of project status. This can also help ensure that the completed
project will meet the needs of the client.
Reaffirm the organizations commitment to the project for the benefit of project team
members. Some other purposes may also be;
Identify problems earlier
Clarify performance, cost, and time relationships
Improve project performance
Locate opportunities for future technological advances
Evaluate the quality of project management
Reduce costs
Improve the process of risk identication and management
Speed up the achievement of results
Identify mistakes, remedy them, and avoid them in the future
Provide information to the client
Reconrm the organizations interest in and commitment to the project

The Project Audit:

The project audit is a thorough examination of the management of a project, its methodology and
procedures, its records, its properties, its budgets and expenditures, and its degree of completion.
It may deal with the project as a whole, or only with a part of the project. The formal report may
be presented in various formats, but should, at a minimum, contain comments on the following
points:

The Process Review Report

A company may decide to conduct process reviews in varying degrees of thoroughness, from
totally comprehensive, to partial, to less formal and cursory. A formal, comprehensive process
review should be followed by a report. The report should contain as a minimum the following:
Current project status.
The best way to do this is to use earned value analysis. However, when earned value analysis is
not used, the current 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 report should specify the nature of
the changes.
Status of critical tasks.
The report should describe the status of critical tasks, particularly those on the critical path.
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.
The report should mention any identified risks that could lead to monetary loss, project failure,
or other liabilities.
Information relevant to other projects.
The report should describe what has been learned from this process review that can or should be
applied to other projects, whether in progress or about to start.
Limitations of the process review.
The report should mention any factors that may limit the validity of the process review.
Are any assumptions suspect? Are any data missing or perhaps contaminated? Was anyone
uncooperative in providing information for the process review?
As a general comment, the simpler and more straightforward a project process review report, the
better. The information should be organized so that both planned and actual results can be easily
compared. Signicant deviations should be highlighted and explained.
Difference between Financial Audits and Project Audits

Project Auditing Life Cycle

Thus far, we have considered the project audit and project evaluation as if they were one and the
same. In most ways they are. The audit contains an evaluation, and an evaluator must conduct
some sort of audit. Let us now consider the audit as a formal document required by contract with
the client. If the client is the federal government, the nature of the project audit is more or less
precisely dened, as is the audit process. Like the project itself, the audit has a life cycle
composed of an orderly progression of well-dened events. There are six of these events.
1.Project Audit Initiation:
This step involves starting the audit process, dening the purpose and scope of the audit, and
gathering sufcient information to determine the proper audit methodology.
2. Project Baseline Denition
This phase of the cycle normally consists of identifying the performance areas to be evaluated,
determining standards for each area through benchmarking or some other process, ascertaining
management performance expectations for each area, and developing a program to measure and
assemble the requisite information. Occasionally, no convenient standards exist or can be
determined through benchmarking.
For example, a commodity pricing model was developed as part of a large marketing project. No
baseline data existed that could serve to help evaluate the model. Because the commodity was
sold by open bid, the rm used its standard bidding procedures. The results formed baseline data
against which the pricing model could be tested on an as if basis.
3. Establishing Auditing Database
The next step is to create a database for use by the audit team. Depending on the purpose and
scope of the audit, the database might include information needed for an assessment of project
organization, management and control, past and current project status, schedule performance,
cost performance, and output quality, as well as plans for the future of the project.
The required database for project audits should be specied in the project master plan. If this is
done, the necessary information will be available when needed. Nonetheless, it is important to
avoid collecting anything that might be useful, since this can place extraordinary information
collection and storage requirements on the project.
4. Preliminary Analysis of the Project
After standards are set and data collected, judgments are made. Some auditors avoid judgment on
the grounds that such a delicate but weighty responsibility must be reserved to senior
management. But judgment often requires a fairly sophisticated understanding of the technical
aspects of the project, and/or of statistics and probability, subjects that may elude some
managers. In such an event, the auditor must analyze the data and then present the analysis to
managers in ways that communicate the real meaning of the audits ndings.

It is the auditors duty to brief the PM on all ndings and judgments before releasing the audit
report. The purpose of the audit is to improve the project being audited as well as to improve the
entire process of managing projects. It is not intended as a device to embarrass the PM.
5. Audit Report Preparation:
This part of the audit life cycle includes the preparation of the audit report, organized by
whatever format has been selected for use. A set of recommendations, together with a plan for
implementing them, is also a part of the audit report. If the recommendations go beyond normal
practices of the organization, they will need support from the policy-making level of
management. This support should be sought and veried before the recommendations are
published. If support is not forthcoming, the recommendations should be modied until
satisfactory.
6. Project Audit Termination
As with the project itself, after the audit has accomplished its designated task, the audit process
should be terminated. When the nal report and recommendations are released, there will be a
review of the audit process. This is done in order to improve the methods for conducting the
audit. When the review is nished, the audit is truly complete and the audit team should be
formally disbanded.

Performance Measurement:
Measurement is an integral part of the process. Several aspects of a project that should be
measured are obvious and, fortunately, rather easy to measure. For the most part, it is not
difcult to know if and when a milestone has been completed. We can directly observe the fact
that a building foundation has been poured, that all required materials for a corporate annual
report have been collected and delivered to the printer, or that all contracts have been let for the
rehabilitation of an apartment complex.
At times, of course, milestone completion may not be quite so evident. It may be difcult to tell
when a chemical experiment is nished, and it is almost impossible to tell when a complex
computer program is nally bug free. Largely, however, milestone completion can be
measured adequately.
Similarly, performance against planned budget and schedule usually poses no major
measurement problems. We may be a bit uncertain whether or not a nine-day scheduled
completion time should include weekend days, but most organizations adopt conventions to ease
these minor counting problems.
Measuring the actual expenditures against the planned budget is a bit trickier and depends on an
in-depth understanding of the procedures used by the accounting department. It is common to
imbue cost data with higher levels of reality and precision than is warranted. When the objectives
of a project have been stated in terms of prots, rates of return, or discounted cash ows,
measurement problems may be more obstinate. The problem does not often revolve around the
accounting conventions used, though if those conventions have not been clearly established in

advance, there may be bitter arguments about what costs are appropriately assigned to the
individual project being evaluated.
A far more difcult task is the determination of what revenues should be assigned to the project.
Assume, for example, that a drug rm creates a project for the development of a new drug and
simultaneously sets up a project to develop and implement a marketing strategy for the potential
new drug and two existing allied drugs. Assume further that the entire program is successful
and large amounts of revenue are generated. How much revenue should be assigned to the
credit of the drug research project? How much to the marketing project? Within the
marketing project, how much should go to each of the subprojects for the individual drugs? If
the entire program is treated as one project, the problem is less serious; but R & D and
marketing are in different functional areas of the parent organization,