management

1. 1
Unit V: Control and Completion - The Plan-Monitor-Control cycle – Data Collecting and
reporting – Project Control – Designing the control system. Project Evaluation, Auditing and
Termination.
Monitoring and Controlling the Project
Project monitoring and control are, in some ways, simply the opposite sides of project selection
and planning.
Monitoring is the collection, recording, and reporting of project information that is of
importance to the project manager and other relevant stakeholders.
Control uses the monitored data and information to bring actual performance into agreement
with the plan.
The purpose of monitoring is to ensure that all interested parties have
available, when needed, the information required to exercise control over the project. The key
issue in designing an effective monitoring and control system is to create an information system
that gives the project manager and others the information they need to make informed, timely
decisions that will keep project scope as close as possible to the plan.
THE PLAN - MONITOR - CONTROL CYCLE
Managing a project involves continually planning what to do, checking on progress, comparing
progress to plan, taking corrective action to bring progress into agreement with the plan if it is
not, and re-planning when needed.
The fundamental items to be planned, monitored, and controlled are time, cost, and
scope so that the project stays on schedule, does not exceed its budget, and meets its
specifications. This plan- monitor - control cycle constitutes a ―closed- loop‖ process that
continues until the project is completed.
Note that the information flows up the organization and the authority flows down.
When particularly complex, challenging, or uncertain projects are initiated,
the planning - monitoring - controlling effort is minimized so that ―the real work‖ can be done.

2. 2
Example: A retailer won a bid to supply a regional office of a national firm with a computer,
terminals, and software. Due to insufficient planning, the installation was completed far beyond
the due date with very inadequate performance. The project failure disqualified the retailer from
bidding on an additional 20 installations planned by the national firm. Another firm in the
construction industry ran 63 percent over budget and 48 percent over schedule on major project
because the PM had managed similar projects several times before and ―knew what to do without
going into all that detail that no one looks at anyway. ―
 Designing the Monitoring System
The key to setting up a monitoring system is to identify the special characteristics of scope, cost,
and time that need to be controlled in order to achieve the project goals as stated in the project
plan. The exact boundaries within which these characteristics should be controlled must be
determined, as well as the specified performance characteristics for each level of detail in the
project activities. In order to manage for overall project success, control must be exercised at the
detailed work level for each aspect of project performance
The project plan identifies what is being done, when, and the planned level of resource usage for
each task and subtask in the project, so real - time data must be identified to measure
achievement against the plan. Mechanisms to gather and store such data must be designed. In
addition to collection systems for hard data, the monitoring system should include telephone
logs, change tracking/control systems, documentation processes for both formal (e.g., meetings)
and informal communications, and other such softer data collection systems. Once again,
monitoring is the direct connection between project planning and control.
It is essential to spend time up front designing the planning – monitoring controlling
process, especially for more challenging projects. The project plan is the primary document to
guide the design of the monitoring system in terms of the detailed tasks and resources that need
to be controlled in order for the project to achieve its time, cost, and output goals.
 Data Collection and Reporting
Once we have decided on the type of data we want to monitor, the next question is how to collect
these data and turn them into information useful for controlling the project. This is the activity of
data collection and reporting.
Data Collecting
The majority of data to be collected exist in one of the following five formats.
1. Frequency counts A simple tally of the occurrence of an event is common — for example,
days without an accident. Often a count of events per time period or as a fraction of some
standard number is used, such as complaints per month, defects per thousand products, and
fraction of luggage lost.
2. Raw numbers Actual amounts are used, usually in comparison to some expected or planned
amount, such as dollars spent, hours required, and pounds consumed. The comparison to plan
may take the form of variances, that is, differences between planned and actual, or ratios of one
to the other. The ratio format is particularly appealing for reporting on a control chart with

3. 3
predetermined limits. When collecting raw amounts it is important that the basis, time period,
and collection process always be the same.
3. Subjective numeric ratings These are usually subjective estimates of some quality offered by
specialists in the topic, such as ordinal ―rankings‖ of performance. They can be reported in the
same ways as raw numbers, but they often cannot be mathematically processed in the same ways
raw numbers can.
4. Indicators and surrogates When it is especially difficult to find a direct measure of variable,
indicators or surrogates are frequently used. If this approach is taken, it is important that the
indicator or surrogate be as directly related to the variable as possible.
For example, body temperature is an indicator of infection and years of experience can be a
surrogate for expertise.
5. Verbal characterizations Other variables that are difficult to measure, such as team spirit or
client – supplier cooperation, may take the form of verbal characterizations. These forms of data
are acceptable and useful as long as the terminology is limited and is uniformly understood by all
parties.
Data Analysis
Following the collection of the data through the monitoring system, it is frequently necessary to
analyze or process the data in some manner before reporting it for control purposes. This may
take the form of simple aggregation of the data, such as averaging the values, or something as
complex as fitting statistical distribution functions to the data to ascertain relationships, effects,
and trends.
Reporting and Report Types
After the data have been collected and analyzed, they need to be reported in some form. Routine
performance reports include status reports, progress reports, and forecasts. There are also many
other possible report formats, such as time/cost reports, variance reports, update presentations,
and similar documents.
For projects, there are primarily three distinct types of reports:
1. Routine,
2. Exception,
3. Special analysis
Exception reports are primarily intended for special decisions or unexpected situations in which
affected team members and outside managers need to be made aware of a change, and the
change itself needs to be documented.
Special analysis reports are prepared to disseminate the results of a special study in a project
concerning a particular opportunity or problem for the project. They may be distributed to top
management, other project managers who would benefit from the knowledge, functional
managers, or anyone who might be affected or interested. Typical subjects might include studies

4. 4
of new materials, capabilities of new software, and descriptions of the impact of new government
regulations.
In addition to the benefits of reports for the purposes of control, they offer these benefits.
 They provide the mutual understanding between stakeholders in a project regarding the
goals, progress, difficulties, successes, and other ongoing events of importance to the
project.
 They help communicate the need for coordination among those working on the tasks and
subtasks of the project.
 They establish and maintain a communication network for global projects.
 There are often changes to the goals and functioning of projects. Reports can
communicate this information in a timely and appropriate fashion, thus minimizing the
confusion often encountered during such changes.
 They help maintain the visibility of the project, and the project team, to top management,
functional managers, colleagues, and clients.
 Finally, unless the project is a disaster, status reports help keep the project team
motivated.
EARNED VALUE
If expenditures are lower than expected for a given period, it may be either good or bad,
depending on whether progress is in line with that amount of expenditure. Similarly, if
expenditures are higher than expected, this may be acceptable if progress is sufficiently greater
than planned for that period.
The performance of a task or project cannot be evaluated by considering cost factors alone. The
earned value ( EV ) of a task (or a project) is the budgeted cost of the work actually performed. It
is calculated by multiplying the budgeted cost of the task by the percentage of completion of the
task and summing over all tasks for the project. This process is more difficult. The budgeted
cost of a task is clear, but the percentage of completion is not.
To the best of our knowledge, there is no satisfactory way to measure accurately the
percent of completion of most tasks, let alone to measure accurately the percent of completion of
an entire project.
As a result, three conventions have been adopted for estimating progress on tasks,
The most popular is 50 – 50: the task is listed as 50 percent complete when work on it is
initiated, and the other 50 percent is added when the task is completed. This approach avoids the
difficult problem of trying to estimate progress while the task is being executed. Clearly, this
overstates the EV of tasks that have recently begun, but understates the EV of tasks nearing
completion. In a large project, of course, with multiple on - going tasks starting and stopping at
different times, the overstating and understating may tend to even out resulting in a relatively
accurate portrayal of project progress.

5. 5
Another convention is 100 percent when the task is complete and zero percent before that. This
is a very conservative approach that will only show project progress that is definitely achieved.
Projects, however, will always appear to be ―behind schedule,‖ and upper management will be in
a constant state of worry about the project‘s progress.
The last approach is the common, intuitive one of trying to estimate percentage completion by
using the ratio of cost expended to the total cost budgeted for a task, the ratio of the actual time
elapsed relative to the total scheduled task time, or some combination of both. There is no strong
evidence that either the time or cost ratio is an accurate estimator of percent completion.
These conventions are meant for application only to individual tasks on a project, not to the
project as a whole.
(The earned value completed to date tells the manager whether progress is up to expectation, the
―baseline‖ planned for this point in time. Any difference is called the ―schedule variance,‖ which
shows how much the project is ahead of or behind schedule.)
Earned value represents a way to capture both in - process
performance and cost on a certain date as measured against budget or schedule. Including the
planned costs and actual costs allows the calculation of spending and schedule variances, where
negative values are undesirable. Using these figures, a projection can be made of costs to
completion and total cost for the task or project under consideration. Although percentage
completion makes limited sense for individual tasks and work elements, it has little meaning for
the project as a whole.
Project Control
Project control, the final activity in the planning - monitoring - control cycle, involves taking
action when reality deviates from plan. It includes both mechanistic and human elements, and
because it is closely concerned with human behavior, is one of the most difficult tasks of the PM.
Project control serves two major functions:
a. It ensures regular monitoring of performance
b. It motives project Personnel to strike for achieving projects
 Project Controls encompass the people, processes and tools used to plan, manage and
mitigate cost and schedule issues and any risk events that may impact a project.
 Project control involves a regular comparison of performance against targets, a search for
the causes of deviation and a commitment to check adverse variances.
It is a management action, either planned to achieve the desired result or taken as a corrective
measure prompted by the monitoring process. Project controls are mainly concerned with the
metrics of the project, such as quantities, time, cost and other resources. Apart from these,
project revenues and cash flow can also be part of the project metrics under control.

6. 6
The successful performance of a project depends on appropriate planning. The execution of a
project is based on a robust project plan and can only be achieved through an effective schedule
control methodology. The development of a suitable Project Control system is an important part
of the project management effort. Furthermore, it is widely recognized that planning and
monitoring plays a major role as the cause of project failures. It has been proved time and again
that Project performance can be improved if dedicated Project Controls systems are in place.
The tasks of project controlling are also:
1. The creation of infrastructure for the supply of the right information and its update,
2. The establishment of a way to communicate disparities of project parameters,
3. The development of project information technology based on an intranet or the determination
of a project Key Performance Index (KPI) System,
4. Divergence analyses and generation of proposals for potential project regulation,
5. The establishment of methods to accomplish an appropriate the project structure, project
workflow organization, project control and governance, and
6. Creation of transparency among the project parameters.
Overall project control requires an eye on the future, as this formula shows:
Calculated Present Variance + Estimated Future Variance = Final Project Variance
Maintaining proper control really requires that you consider three parameters: (a) where you are,
compared with where you‘re supposed to be; (b) what lies ahead that can affect you; and (c)
where you‘re going to end up, compared with where you said you would end up.
DESIGNING THE CONTROL SYSTEM
There are three primary mechanisms by which the PM exerts control:
a) Process reviews
b) Personnel assignment
c) Resource allocation
The process review is directed to an analysis of the process of reaching the project
objectives rather than on the results. Because results are largely dependent on the process used to
achieve them, the process can be subjected to control even if the results cannot.
Control can also be exercised through personnel assignments based on past project
productivity. Although it is relatively easy to separate workers in the top and bottom quartiles by
measuring performance or productivity, separating the middle two quartiles is much more
difficult, so this approach should be used carefully.
Controlling resource allocation can be a powerful motivator — and demotivator.
Resources are usually allocated to the more productive or important tasks and this can
significantly influence the attainment of project results

7. 7
 Project Control Process
Control is the process of comparing actual performance against plan to identify
deviations, evaluate possible alternative courses of actions, and take appropriate corrective
action. The steps in the project control process for measuring and evaluating project performance
are listed below:
1) Setting a baseline plan.
2) Measuring the actual performance
3) Comparing actual with baseline plans.
4) Taking corrective action.
Step 1: Setting a Baseline Plan
The baseline plan provides with the elements for measuring performance. The baseline is derived
from the cost and duration information found in work breakdown structure (WBS) database; and
time-sequence data are derived from the network and resource scheduling decisions. The WBS
defines the work in discrete work packages that are tied to deliverables and organization units. In
addition, each work package defines the work, duration, and budget. From the WBS, the project
network schedule is used to phase all work, resources, and budgets into a baseline plan.
Step 2: Measuring the Actual Performance
Time and budgets are quantitative measures of performance that readily fit into the integrated
information system. Qualitative measures such as meeting customer technical specifications and
product function are most frequently determined by on-site inspection or actual use.
Measurement of time performance is relatively easy and obvious. Examples: the critical path,
early on schedule or late; is the slack of near critical-paths decreasing to cause new critical
activities, etc. For measuring performance, earned value is necessary to provide a realistic
estimate of performance against a time-phased budget. Earned value (EV) is defined as the
budgeted cost of the work performed
Step 3: Comparing Actual with Baseline Plan
All the baseline plans seldom materialize as expected and hence, it becomes imperative to
measure deviations from plan to determine if action is necessary. Periodic monitoring and
measuring the status of the project allow for comparisons of actual versus expected plans. It is
crucial that the timing of status report be frequent enough to allow for early detection of
variations from plan and early detection of causes. Usually, status reports should take place every
one to four weeks to be useful and allow for proactive correction.
Step 4: Taking Corrective Action
If deviations from plans are significant, corrective actions will be needed to bring the project
back in line with original or revised plan. In some cases, conditions or scope can change, which,
in turn, will require a change in the baseline plan to recognize new information.

8. 8
Problems of Project Control:
Effective control is critical for the realization of project objectives. Control of projects in practice
tends to be ineffective. There are three main reasons for poor control of projects.
Viz.,
1. Characteristics of the project Largeness and complexities , Maintenance of non-routine
activities
2. Co-ordination and communication problem, People problems.
3. Managers do not have required experience & training, Lack of competence and
inclination to control projects.
4. Poor control and information system: Delay in reporting performance. Inappropriate level
of detail un-reliable information.
Project Control Issues
a) Monitoring Time Performance
A major goal of progress reporting is to catch any negative variances from plan as early as
possible to determine if corrective action is necessary. Fortunately, monitoring schedule
performance is relatively easy. The project network schedule, derived from the WBS/OBS,
serves as the baseline to compare against actual performance. Gantt charts (bar charts) and
control charts are the typical tools used for communicating project schedule status.
Gantt Charts
Gantt and control charts serve well as a means for tracking and trending schedule
performance. Their easy-to-understand visual formats make them favorite tools for
communicating project schedule status-especially to top management who do not usually have
time for details. Adding actual and revised time estimates to the Gantt chart gives a quick
overview of project status on the report date. The following figure shows the sample of multi-
color Gantt chart.
Control Charts
Control chart is another tool used to monitor past project schedule performance and
current performance and to estimate future schedule trends. Control charts are also frequently
used to monitor progress toward milestones, which mark events and as such have zero duration.
The following figure shows the sample control chart.
b) Need for an Integrated Information System
There are many customized monitoring and control systems used in practice. The disparity
among monitoring systems is usually found in the lack of connections with a time-phased
baseline plan. Such systems fail to compare actual work completed for any time period against
budgeted scheduled costs for the same time period. Without matching time-phased budgets to
actual cost of work completed, it is impossible to reliably measure cost performance.
Development of an Integrated Cost/Schedule System

9. 9
The earned value cost/schedule system uses several acronyms and equations for analysis.
Following five careful steps ensures that the cost/ schedule system is integrated.
Define the work using a WBS. This step involves developing documents that include the
following information about Scope, Work packages, Deliverables, Organization units, Resources
and Budgets for each package.
➢ Develop work and resource schedules. This is done by scheduling resources to activities and
time-phasing work packages into a network.
➢ Develop a time-phased budget using work packages included in an activity. The cumulative
values of these budgets will become the baseline and will be called the planned time-phased
baseline of the value of the work scheduled (PV).
➢ At the work package level, collect the actual costs for the work performed. These costs will
be called the actual cost of the work completed (AC).
➢ Compute the schedule variance using the formula, Schedule Variance = Earned Value –
Planned time-phased base line of the value of the work scheduled (SV = EV – PV).
➢ Compute the cost variance using the formula, Cost Variance = Earned Value – Actual cost of
the work completed (CV = EV – AC).
Development of Project Baselines
The baseline (PV) serves as an anchor point for measuring performance. The baseline is a
concrete document and commitment; it is the planned cost and expected schedule performance
against which actual cost and schedule are measured. It can also serve as a basis for developing
cash flows and awarding progress payments. Development of the project baseline is part of the
planning process. The baseline is the major input to the cost/schedule system to be described.
Costs to be included in Baselines
The baseline PV is the sum of the cost accounts, and each cost account is the sum of the
work packages on the cost account. Three costs are typically included in baselines, viz., labour,
equipment, and materials. Sometimes project direct overhead costs are also included.
Rules for Placing Costs in Baselines
The major reasons for creating a baseline are to monitor and report progress and to
estimate cash flow. Therefore, it is crucial to integrate the baseline with the performance
measurement system. Costs are placed in the baseline exactly as managers expect them to be
―earned‖.
This approach facilitates tracking costs to their point of origin. In practice, the integration
is accomplished by using the same rules in assigning costs to the baseline as those used to
measure progress using earned value. Percent Complete Rule is the best method for assigning
costs to the baseline in order to establish frequent check points over the duration of the work
package and assign completion percentages in monetary terms.
Methods of Variance Analysis

10. 10
Generally the method for measuring accomplishments centers on two key computations:
Comparing earned value with the expected schedule value;
Comparing earned value with actual costs.
c) Indices to Monitor Progress
In corporate world, project management professionals prefer to use schedule and cost
indices over the absolute values of SV and CV, because indices can be considered as efficiency
ratios. Graphed indices over the project life cycle can be very illuminating and useful. The trends
are easily identified for deliverables and the whole project.
Performance Indexes
There are two indices of performance efficiency. The first index measures cost efficiency
of the work accomplished to date:
Cost Performance Index (CPI) = EV/AC
Scheduling Performance Index (SPI) = EV/PV196
Project Percent Complete Index
There are two project percent complete indices, which are used depending on the nature
of project. The first index assumes the original budget of work complete, which is the more
reliable information to measure project percent complete. The second index assumes the actual
costs-to-date and expected cost at completion, which is the most reliable measure for measuring
project percent complete. These indices compare the up-to-date progress to the end of the
project. The implications underlying the use of these indices are that conditions will not change,
no improvement or action will be taken, and the information in the database is accurate.
Percent Complete Index for Budget = PCIB = EV/BAC
Percent Complete Index for Cost = PCIC = AC/EAC
Technical Performance Measurement
Measuring technical performance is equally important as measuring schedule and cost
performance. The consequences of poor technical performance will be very adverse. Assessing
technical performance of a system, facility, or product is often accomplished by examining the
documents found in the scope statement and/or work package documentation.
Software for Project Cost/Schedule Systems
Software developers have created sophisticated schedule/ cost systems for projects that
track and report budget, actual, earned, committed, and index values. These values can be labour
hours, materials, and/or dollars. This information supports cost and schedule progress,
performance measurements, and cash flow management.
Additional Earned-Values Rules
Although the percent complete rule is the most-used method of assigning budgets to
baselines and for cost control, there are two additional rules that are very useful for reducing the
overhead costs of collecting detailed data on percent complete of individual work packages.

11. 11
These rules are the 0/100 percent rule and the 50/50 rule. These two rules are typically used for
short-duration activities and/or small-cost activities.
Forecasting Final Project Cost
There are basically two methods used to revise estimates of future project costs. In many
cases both methods are used on specific segments of the project. The result is confusion of terms
in texts, in software, and among practitioners in the field.
The first method allows experts in the field to change the original baseline durations and
costs because new information tells them the original estimates are not accurate.
The second method is used in large projects where the original budget is less reliable.
This method uses the actual costs to-date plus an efficiency index, (CPI = EV/AC) applied to the
remaining project work. When estimate for completion uses the CPI as the basis for forecasting
cost at completion, acronym ‗(EAC)‘ - Estimated total cost At Completion‘- is used.
d) Other Control issues
Baseline changes
Changes during the life cycle of projects are inevitable and will occur. Some changes can be very
beneficial to project outcomes; changes having a negative impact are the ones to be avoided.
Careful project definition can minimize the need for changes. The price for poor project
definition can be changes that result in cost overruns, late schedules, low morale and loss of
control. Change comes from external sources or from within. Externally, for example, the
customer may request changes that were not included in the original scope statement and that
will require significant changes to the project and thus, to the baseline.
Contingency Reserve
In reality, plans seldom materialize as per estimates. Identified and unidentified risks
occur, estimates go wrong, and customer wants changes, technology changes. Because, perfect
planning does not exist, some contingency funds should be created before the project commences
to cover the unexpected. The size of the contingency reserve should be related to the
uncertainties and risk of schedule and cost estimate inaccuracies. Contingency reserve is not a
free lunch for all who come. Reserve funds should only be released by the project manager on a
very formal and documented basis. Budget reserve contingency funds are not for scope changes.
Scope changes are covered by management reserve fund.
The Costs and Problems of Data Acquisition
For large projects, there is no substitute for using a percent complete system that depends on data
collected through observation at clearly defined monitoring points.
Scope Creep
Large changes in scope are easily identified. It is the ‗minor refinements‘ that eventually
build to be major scope changes that can cause problems. These small refinements are known in
the field as scope creep.

12. 12
Ways to Deal with Project Control Issues
Having understood the key control issues, setting up appropriate controls will help assure
the project is a success. Following are some of the ways to deal with project control issue:
a) Change management: Request that a member of senior management announce the project
to all stakeholders, why the project has been launched and the impact on those affected.
By involving those affected, there will be a less resistance to change.
b) Schedules: Make sure the project starts on time and that tasks are completed on a timely
basis. To help assure project completes by the planned completion date, employ the
critical path method. This method defines critical and non-critical tasks that impact timely
project completion.
c) Costs: Break down budgeted costs into easy-to-track categories. Make sure costs are
recorded as soon as they are incurred so that there is a clear understanding of actual costs.
Instruct project team members who are responsible for approving bills; otherwise costs
can quickly escalate.
d) Requirements: Use a structured approach for defining requirements so that the delivered
project matches the expectations of project stakeholders. Rather than waiting until the end
of a project to deliver what stakeholders want, provide interim deliverables to make sure
the organization and the stakeholders are in agreement with project progress. Waiting
until the end of the project to share information with users could result in project cost
overruns if changes must be made in what was delivered.
e) Communications: Make sure communications to the project team and stakeholders is clear
and understandable. Breakdowns in communications can quickly derail a project and
impact team members‘ morale.
f) Staffing: Make sure the project is staffed with people who have the required skills to
achieve project objectives. Have weekly meetings with project staff so you can quickly
address any project team or stakeholder problems.
g) Checklist: Prepare a checklist of all areas you need to monitor and control. Decide on what
you will monitor and how often. Do not delay acting on issues that are not under control.
h) Monitoring, Reporting & Control: Monitoring is about assessing what work has been
completed for a Project including costs, risks and issues. In addition the Board will routinely
monitor if the business case continues to be viable in terms of alignment with strategic
objectives. This usually takes the form of the production of documentation and reports at key
stages. Reporting provides the Project Board with a summary of the status of the project at
intervals defined by them.

13. 13
Project Evaluation, Auditing and Termination.
 Project Evaluation
The term ―evaluate‖ means to set the value of or appraise. A project
evaluation appraises the progress and performance relative to the project‘s initial or revised plan.
The evaluation also appraises the project against the goals and objectives set for it during the
selection process amended, of course, by any changes in the goals and objectives made during
the project ‘ s life. In addition, evaluations are sometimes made relative to other similar projects.
 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 finished.
 The primary purpose of evaluation in project management is to assess performance,
reveal areas where the project deviates from goals, and uncover extant or potential
problems so they can be corrected.
Project evaluation appraises the progress and performance of a job compared 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 be considered valid. The primary tool for project evaluation is the
project process review, which is usually conducted at major milestones throughout the life of the
project.
The general reasons for conducting periodic project process reviews.
1. Improve project performance together with the management of the project.
2. Ensure that quality of project work does not take a back seat to schedule and cost concerns.
3. Reveal developing problems early so that action can be taken to deal with them.
4. Identify areas where other projects (current or future) should be managed differently.
5. Keep client(s) informed of project status. This can also help ensure that the completed project
will meet the needs of the client.
6. Reaffirm the organization‘s commitment to the project for the benefit of project team
members.
 Two kinds of evaluation occur in projects.
Evaluation throughout the life cycle for the purpose of guiding the project is called formative
evaluation; it addresses the questions ―What is happening?‖ and ―How is the project
proceeding?‖
Evaluation after the project is completed for the purposes of appraising the project and assessing
the end product or end-results is called summary evaluation; it addresses the questions ―What
happened?‖ and ―What were the results?‖
 Project Formative Evaluation
Project formative evaluation must account for the fact that projects are complex systems: Cost,
schedule, and work performance criteria are interrelated, and interdependent work packages
draw from the same pool of limited resources. As a result, well-intended corrective measures

14. 14
directed exclusively on just one performance criteria can lead to problems in others. Similarly,
attempts directed solely at improving performance in one work area can have detrimental effects
on others. To provide information that realistically portrays the status of the project and enables
the project manager to draw accurate conclusions, project evaluation must incorporate three
performance criteria simultaneously--cost, schedule, and technical performance, and it must
account for the impact that changes in anyone work area will have on other related areas. The
evaluation process must be able to signal potential trouble spots so action can be initiated before
problems materialize. The best kind of evaluation not only reveals problems, it points out
opportunities to reduce costs, speed up work or enhance project outcomes in other ways.
 Methods and Measures
A wide variety of methods, measures, and sources are used to obtain evaluation information
about schedule, cost, and technical performance. These methods and measures should be
specified in the project plan before the project begins. Using a variety of measures and sources
increases the validity of the evaluation, particularly when multiple sources all lead to the same
conclusion.
The primary ways for obtaining and/or conveying project evaluative information are written
reports with charts and tables, oral reports, firsthand observation, and review meetings.
Written reports with charts and tables are the most expeditious way to review cost,
schedule, and work performance information since they reduce large amounts of information into
simple, comprehensible formats. The danger is that they can hide or obscure information, leading
to facile and erroneous conclusions. For example, because project-level measures tend to hide
lower-level problems, conclusions need to be substantiated by a more detailed investigation at
the work package level. Charts and tables alone neither reveal the underlying causes of problems
nor suggest opportunities. Thus, better sources of evaluative information are oral and written
reports, and first-hand observation.
Oral reports about project status are an easy, quick way to obtain information, although
their accuracy and reliability depend on the interpretative and verbal skills of the presenter, and
the number of channels through which the information had to pass to get to the presenter. In
general, the greater the number of channels, the more distorted the message becomes. Because of
this, project managers are seldom in their offices; they walk around the project, making
observations and gathering first-hand information from supervisors and workers.
 PROJECT REVIEW MEETINGS
 Purpose of Review Meetings
Review meetings are one of the most common and important ways to communicate and
assess project evaluative information. The main function of these meetings is to identify
deviations from the project plan and quickly correct them. During the meetings, participants
focus on project progress and current problems, opportunities, and anticipated problems.
(1) Current problems 'with the work, schedule or costs, and how they should be resolved,
(2) Anticipated problems, and (3) opportunities to improve project performance.

15. 15
Review meetings are the managerial equivalent to the "quality circle" (QC) groups used in
production environments. QC groups get the people most closely associated with the job-the
workers-to
(1) identify quality- and production-related as well as opportunities for work improvement,
(2) develop ways to resolve problems and take advantage of opportunities, and
(3) implement them.
Review meetings can be informal and scheduled weekly, or formal and scheduled whenever
needed or according to particular phases of the project. Most large projects require both kinds of
reviews.
 Informal Reviews
Informal reviews are held frequently and regularly, and involve members of the project team.
The reviews (called ― peer reviews ‖ because they are attended by a group of peers) focus on
project status, special problems, emerging issues, and performance of the project. Meeting
participation depends on the phase of the project and issues at hand; only the team members,
customer representatives, functional or line managers, and project managers who need be
involved are invited. Before the meetings, status reports and forecast time and cost-to-complete
are updated. Attendees with assignments are expected to give presentations.
To encourage honesty and candor, the project manager takes on the role of group facilitator.
Because reviews are intended to uncover problems and issues, bad news and problems should be
expected and openly confronted. Finger-pointing, passing blame, or smoothing over of conflict
should be avoided; such behavior wastes time, discourages attendance, and negates the purpose
of the meetings—to identify issues or problems and agree on the course of action.
 Standup Meetings
A variation of the informal review is the ― daily standup meeting. ‖ Intended more as an update
on status than a progress review, the meeting is short (15 minutes) and to-the-point. Usually held
at the start of every day, a small group of team members give a quick run-through of yesterday ‘
s progress and today ‘ s next steps. (The occasional surprise attendance of a prominent person—
senior manager from the contractor or customer—adds spice and helps keep everyone on their
toes.) Problems that require more than a minute ‘ s reflection are deferred for a later meeting.
 Formal Reviews
Formal reviews are scheduled at milestones or critical project stages. In projects that involve
significant design and development effort, two common formal reviews are the preliminary
review and the critical review. The purpose of the preliminary design review is to assess how
well the functional design specifications fit the basic operational requirements. At the critical
design review, details of the hardware and software design are checked for conformance to the
preliminary design specifications.

16. 16
Formal reviews can be a precondition for continuing the project. In the phased project
planning approach, the decision to continue or terminate the project is based upon the results of a
formal review of project performance so far.
1. Preliminary Design Review: The functional design is reviewed to determine whether the
concept and planned implementation fits the basic operational requirements.
2. Critical Design Review: Details of the hardware and software design are reviewed to ensure
that they conform to the preliminary design specifications.
3. Functional Readiness Review: For high-volume products or mass-produced goods, tests are
performed on the first, or early, items to evaluate the efficacy of the manufacturing process.
4. Product readiness review: Manufactured products are compared to specifications and
requirements to ensure that the controlling design documentation produces items that meet
requirements.
Project Audits
The project audit is a thorough examination of the management of a project, its methodology and
procedures, its records, properties, inventories, budgets, expenditures, progress, and so on.
Project audit is a formal and systematic examination of the performance of an
ongoing project as compared to its requirements. It involves measurement against predefined and
relevant standards. It also constitutes and independent and authentic source of information and
critique on the project and might often call for the auditor‘s personal judgment. Without
impinging on enterprise management‘s prerogative and responsibility, it supports management in
diagnosis and decision-making.
Project audits are more than the status reports which check on project performance.
Project audits use performance measures and forecast data. But project audits are more inclusive.
Project audits review why the project was selected. It includes a reassessment of the project‘s
role in the organization‘s priorities. It includes a check on the organizational culture to ensure
that it facilitates the type of project being implemented. It assesses if the project team is
functioning well and it is appropriately staffed. Audits of projects in process should include a
check on external factors that might change where the project is heading on the right path – for
example, technology, government regulations, and competitive products. It includes a review of
all factors relevant to the project and to managing future projects. It can be performed while a
project is in process and after a project is completed. There are only a few minor differences
between these audits.
While audits can be performed at any level of depth, three levels are
common. The first is the general audit, usually constrained by time and cost and limited to a brief
investigation of project essentials. The second is the detailed audit, often initiated if the general
audit finds something that needs further investigation. The third is the technical audit, usually
performed by a person or team with special technical skills.
 In-Process Project Audits

17. 17
In-process project audits allow for corrective changes, if they are needed, on the audited
projects or others in progress. It concentrates on project‘s progress and performance and checks
if conditions have changed.
 Post Project Audits
These audits tend to include more detailed and depth than in-process project audits.
Project audits of completed projects emphasize improving the management of future projects.
These audits are more long term oriented than in-process audits. Post project audits check on the
project performance, but the audit represents a broader view of the project‘s role in the
organization.
OBJECTIVES OF PROJECT AUDIT
The objectives of project auditing can be viewed in terms of the help it renders to the enterprise
management in:
a. Creating awareness among the project staff of the types and magnitude of the problems
that are likely to be encountered in completing the project and producing quality
products, in planned volume and at competitive costs.
b. Providing a clean picture, from time to time, of the actual status of the project.
c. prompt identification of the factors that might cause product quality problems or lead to
time and/or cost overruns

18. 18
d. Timely spotting of a variety of generic problems that are associated with execution of
projects.
e. Enabling the creation of a good information base for a proper estimation and costing of
the project.
f. Assisting in the establishment of appropriate standards and system and recommending
suitable work techniques
g. Identifying the specific training needs with references to the project tasks
h. Formalizing the experience and expertise in project management in order to be able to
provide consultancy services to other enterprises.
 Factors Influencing Audit Depth and Detail
The depth and detail of the project audit depends on many factors:
Organization size
Project importance
Project type
Project risk
Project size
Project problems
 Project Audit Guidelines
The Guidelines for conducting project audits include the following:
a) The philosophy must be that the project audit is not a punishing exercise.
b) Comments about individuals or groups participating in the project should not be revealed.
c) Audit activities should be intensely sensitive to human emotions and reactions.
d) Accuracy of data should be verifiable or noted as subjective or judgmental.
e) Senior management should announce support for the project audit and see that the audit
group has access to all information, project participants and project customers.
f) Objective of the project audit is to learn and conserve valuable organizational resources.
g) The audit should be completed quickly.
h) The audit leader should be given access to senior management above the project managers.
 Project Audit Process
Following the steps in the project audit process:
Step 1: Initiation and Staffing
Initiation of the audit process depends primarily on organization size and project size along with
the other factors. However, every effort should be made to make the project audit a normal
process rather than a surprise notice. In small organizations and project where face to face
contact at all levels is prevalent, an audit may be informal and only represent another staff

19. 19
meeting. But even in these environments, the content of a formal project audit should be
examined and covered with notes made of the lessons learned.
In medium sized organizations that have several projects occurring simultaneously, initiation can
come from a formal project review group, from the project priority team or be automatic. A
major tenet of the project audit is that the outcome must represent an independent, outside view
of the project. Maintaining independence and an objective view is difficult, given that audits are
frequently viewed as negative by project stakeholders.
It is imperative that the audit leader possesses the following characteristics:
No direct involvement or direct interest in the project
Respect of senior management and other project stakeholders
Willingness to listen
Independence and authority to report audit results without fear of recrimination from
special interests.
Perceived as having the best interest of the organization in making decision.
Broad based experience in the organization or industry.
Step 2: Data Collection and Analysis
The traditional content model for a project audit represents two perspectives. One
evaluates the project from the view of the organization. The second perspective represents the
project team‘s evaluative view. The organization perspective is developed by a small group
primarily made up of persons not having a direct interest in the project. The project team
perspective is developed by a group composed primarily of team members along with persons
independent of the project to ensure the evaluation is objective. Each organization and project is
unique. Therefore, many factors need to be considered like the industry, project size, newness of
technology and project experience that can influence the nature of the audit.
Step 3: Reporting
The major goal of the audit report is to improve the way future projects are managed.
Concisely, the report attempts to capture needed changes and lessons learned from a current or
finished project. The report serves as a training instrument for project managers of future
projects. Audit reports needs to be customized to the specific project and organizational
environment. Nevertheless, a generic format for all audit reports and the managers who read and
act on their content. Usually, the following items are included in the reports:
Classification of project based on nature, type, size, number of staff and technology level.
Analysis of information gathered such as project‘s mission, objectives, procedures,
systems and organizational resources used.
Recommendation of positive successes that should be continued and used in future
projects.
Lessons learned to avoid pitfalls in future.
Appendix of data or details of analysis of the project.

20. 20
 Core Constituents to be analyzed during Project Audit
a) Time Management
Time schedule development and control measures
Activity duration analysis in terms, including inter-team dependency
b) Resource Management
Resource planning and control in terms of allocation of resources, criteria for distribution,
analysis of consumption patterns and
Measures to control resource abuse
c) Personnel Management
Allocation of staff and establishment of recruiting policies
Division of responsibilities regarding team development and training needs
d) Information Management
Policies regarding Preparing and Collecting information
Principles used for Classifying and Distributing information
Methods used for Filing, Updating and Retrieving information
The purpose of the audit is not just analyzing various project management resources and
functionalities but also to help the organization understand the performance of each of them. For
this purpose, most audit processes use a grading system to rank each audited project constituent:
Critically Deficient — suggests a serious inability to match project guidelines.
Weak — unable to entirely comply with project objectives.
Satisfactory — basic project management principles are followed but the overall
performance has room for improvement.
Good — the compatibility with the project goals and effectiveness of management tools,
both are appreciable and committed to project goal.
Very Good — the process defines ideal project performance and adheres to
planning/monitoring expectations and performs as per project expectations
 Difficulties In Establishing Audit Purpose And Scope
The purpose of project audit is to clarify the state of the project in certain key areas for the
enterprise management. It is part of a quality control effort. The auditor could often be misled by
wrong information or out of date or incorrect documentation. He should have a system of cross
verification and checks so as not to be led astray. It might sometimes be found that persons who
are to be working on the project are not there and those who are not supposed to be in the project
are there. The auditor will have to report these aberrations indicating their implications for the
project. Difficulties might arise in identifying the baseline contract or work statement set. Work
could be carried out on the basis of verbal agreements without proper contract documentation.

21. 21
Absence of deliverable specifications in the contract baseline and inadequacies in delivery
procedure or acceptance criteria are often problems requiring special attention. The auditor will
have to resolve such ambiguities.
 Team, Team Member and Project Manager Evaluation
Auditing includes performance evaluations of the project team, individual team members, and
the project manager.
Team Evaluation
Some conditions should be established or agreed upon before auditing the project team. Some
conditions include the following:
Whether standards for measuring performance exist? Are the goals clear for the team and
individuals? Challenging? Attainable? Lead to positive consequences?
Whether individual and team responsibilities and performance standards are known to all
team members?
Whether team rewards are adequate? Do they send a clear signal that senior management
believes in synergy of teams?
Whether a clear career path for successful project managers is in place?
Whether the team has discretionary authority to manage short-term difficulties?
Whether there is a relatively high level of trust emanating from the organization culture?
Team evaluation should be beyond time, cost, and specifications. Whether there are any other
conditions beyond these three criteria? The ―characteristics of highly effective teams‖ can easily
be adapted as measurements of team effectiveness. These ―in-place conditions‖ will support any
evaluation approach for teams and their members.
Team‘s project performance should be evaluated in one of two ways:
Team members should evaluate themselves and each other.
Team members should evaluate each other and team leaders should evaluate individual
team members.
Do’s of Team Evaluation
Each team member should also be allowed to evaluate him or herself. To begin with,
team members and leaders use the Project Team Evaluation Templates. Following are the
guidelines for evaluating project teams:
a) Analyze Evaluations - Analyze how individual team members evaluated themselves and
each other to get a better feel for how the team feels as a whole.
b) Analyze the Difficulties - How difficult have team projects been? Were tasks new or
known? In either case did the team rise to the degree of difficulty? If not, why? If you feel

22. 22
the team lacked on certain tasks, instead of berating the team in your evaluations, discuss
a past project where they performed well, point out what was different this time around.
c) Analyze Performance - How well did the team perform? Don‘t confuse performance with
potential. Stick to the actual results of the team.
d) Analyze Achievement - Did the team achieve the project goal? If so, point out
contributions and results.
e) Life Cycle - How well did the team perform within the life cycle of the project? Were
deadlines met? If not, identify overruns. Try to analyze what happened if the life cycle of
the project was longer than anticipated. What could have been done differently?
f) Judge Individuality - By looking at individual evaluations, analyze what each individual
contributed to the project. How well did each team member do? Keep in mind that some
team members succeed in some areas while others succeed in different areas. Did the
individuals perform at a level that was helpful to the team as a whole?
g) Be honest - You probably are pleased with your team most of the time. Don‘t use this as
your guide in evaluating your team. All employees have room for improvement including
teams. Not every project is a job well done. This is by far the hardest part of evaluating
your team. If negatives are identified and must be discussed, start by talking about a past
project that flowed well. Next, discuss past success and compare it to the current project.
How could things have been improved upon?
Do not’s of Team Evaluation
Following are the not to be followed while evaluating project teams:
Don‘t be too lenient. Don‘t be the project manager who says everything is fine when it‘s
not.
Everyone has room to improve. If you don‘t identify these areas, your team will never
improve.
Don‘t judge everything on an ―average‖ basis. Some things worked and some things
didn‘t. If a team feels they are average in performance, what are you really telling them?
Do not judge individuals‘ performance based on their personality
If a team member or the team as a whole did one wrong thing, don‘t make this the focus
of your evaluation. Evaluate performance for the entire project.
Evaluations are not the most popular thing for project managers. Evaluating team project
performance is a key if team has to succeed or improve on future projects. Keep in mind that if
weak areas are not identified, your team may just think everything is fine. If you feel you need

23. 23
help on evaluating your team, talk with mentors, other project managers and human resources
department.
Individual Team Member and Project Manager Evaluation
Team evaluation is crucial, but at some point a project manager is likely to be asked to evaluate
the performance of individual members. Such an evaluation will typically be required as part of
the closure process and will then be incorporated in the annual performance appraisal system of
the organization. These evaluations constitute a major element of an individual‘s personnel file
and often form the basis for making the decisions about promotions, future job assignments,
merit pay increases, and other rewards.
Peer Evaluation
Peer evaluations offer an opportunity for team to comment on the performance of their peers. For
example, the team may ask its members at a midpoint in the project to self-evaluate their
improving team effectiveness. The goal is to provide information during the project that will
allow the participants to modify their behavior for the success of the project. In the recent times,
360 degree feedback is gaining momentum in the organizations. 360 degree feedback is a multi-
rater approach and involves soliciting feedback relating to the performance of team members
from all the stakeholders of the project. This includes not only the project and area managers but
also peers, subordinates and customers.
Project Termination and Closeout
Projects are by definition activities of limited duration; they all come to an end.
When this happens, it is the project manager who ensures that all project-related work has been
completed and formally closed out by a specified date. It is the project manager‘s responsibility
to put an end to the project, which can be a tough assignment, especially when there is no follow-
up project.
The term termination is used for ending of a project before it was planned. If a project ends in a
planned time it is commonly called as project closure.
At closeout the project product or deliverable is handed over to the customer.
Contracts sometimes provide for a first handover at completion as well as a second handover
after a defects liability period (a.k.a. retention period, guarantee period, and maintenance period).
At the first handover the customer should ensure that all patent defects (defects that can readily
be detected by a person qualified in the field) are identified and reported. After the first handover
the contractor is only liable for rectifying latent defects (those that could not be detected through
a reasonable inspection at first handover). If, for instance, it is not raining at the time of the first
handover, a roof that later leaks would be considered a latent defect. The purpose of the second
handover is to afford the customer more time to identify deviations from specifications or
substandard workmanship. After the second handover the contractor is no longer liable for
defects, and any retention fees withheld by the customer to ensure compliance are paid to the
contractor.

24. 24
Project closure activities
 Reasons for Termination
Project terminations essentially fall into three categories: achievement of project objectives,
changing environment or intractable problems, or poor customer/ contractor relations.
Even in the first case—when the project is terminated because all work has been completed and
contractual objectives successfully met—it takes a skilled project manager to orchestrate
termination and ensure that no activities or obligations are left uncompleted or unfulfilled. The
seeds of successful termination are sown early in the project. Because termination requires
customer acceptance of the project results, the criteria for acceptance should have been clearly
defined, agreed upon, and documented at the beginning of the project, and any changes made
during the project approved by the contractor and customer.
Some projects never reach successful completion because of factors such as changing market
conditions, skyrocketing costs, depleted critical resources, changing priorities, or other factors.
The decision to abort before completion occurs when the financial or other losses from
termination are considered less than those expected from completing the project. The customer
may simply change his mind and no longer want the project end-item.
Projects sometimes are also halted because of changing market conditions or technology,
unsatisfactory technical performance, poor quality of materials or workmanship, violation of
contract, poor planning and control, bad management, or customer dissatisfaction with the
contractor. Many of these reasons are the fault of the contractor and project management, and
could have been avoided had management exercised better planning and control, showed more
respect for the user, or acted in a more ethical manner. These terminations leave the user with
unmet requirements and cast doubt over the contractor‘s technical competency, managerial
ability, or moral standing.
 Termination and Closeout Responsibilities
As with earlier stages of the project work, the project manager is responsible for planning,
scheduling, monitoring and controlling termination, and closeout activities.
The responsibilities listed by Archibald include:
A. Planning, scheduling, and monitoring closeout activities:
• Obtain and approve termination plans from involved functional managers.
• Prepare and coordinate termination plans and schedules.
• Plan for transfer of project team members and resources to other projects.
• Monitor completion of all contractual agreements.
• Monitor the disposition of any surplus materials and project equipment.
B. Final closeout activities:
• Close out all work orders and approve the completion of all subcontracted work.
• Notify all departments of project completion.

25. 25
• Close the project office and all facilities occupied by the project organization.
• Close project books.
• Ensure delivery of project files and records to the responsible managers.
C. Customer acceptance, obligation, and payment activities:
• Ensure delivery of end-items, side items, and customer acceptance of items.
• Notify the customer when all contractual obligations have been fulfilled.
• Ensure that all documentation related to customer acceptance as required by contract has been
completed.
• Expedite any customer activities needed to complete the project.
• Transmit formal payment and collection of payments.
• Obtain from customer formal acknowledgment of completion of contractual obligations that
release the contractor from further obligation (except warranties and guarantees).
Responsibility for the last group of activities, particularly those relating to payment
and contractual obligations, is shared with the contract administrator or other person responsible
for company-client negotiations and legal contracts. The final activity, obtaining the formal
customer acknowledgment, may involve contractor claims if the customer has failed to provide
agreed-to data or support, or requested items beyond contract specifications. In such cases the
contractor is entitled to compensation.
Before the project is considered closed, the customer reviews the results or end- item with the
contractor to make sure everything is satisfactory. Items still open and in need of attention, and
to which the contractor agrees, are recorded on a list, sometimes called a ―punch list‖. The items
on the list then are checked off by the contractor as they are rectified.
 Types of Project Termination
There are two types of project termination – ―natural termination‖ and ―unnatural termination‖.
―Natural termination‖ reflects the fact that the aims of the project objective have been attained.
―Unnatural termination‖ means that work on the project has stopped because the project
constraints have been violated or the project objective has become irrelevant to the overall goals.
There are four common ways for terminating a project:
a. Extinction
b. Addition
c. Integration
d. Starvation
The following are the most likely reasons for which a project may be terminated:
 By Extinction
The project has successfully completed the planned scope and the client has accepted it.
It has been superseded by the external developments like technological advancement, market
crisis etc.
It has failed to achieve its goal.

26. 26
It no longer has the support of senior management.
 By Addition
Termination by addition occurs when the project team becomes a new part of the parent
organisation. Resources are transferred to the new organizational unit, which is integrated into
the parent organisation. This type of project termination is typical for organizations with a
project structure.
 By Integration
The project is successfully completed. The project product is integrated into the operations of the
client. This is the most common mode and most complex operation. Termination by integration
occurs when the project‘s resources, as well as its deliverables, are integrated into the parent
organization‘s various units. This approach is very common in a matrix organisation because
most people involved in a project are also affiliated with one or more functional units. When the
project terminates, team members are reintegrated into their corresponding units.
 By Starvation
The project is terminated by budget decrement.
It is also known as withdrawal of ―life support‖.
The reason for this termination is generally to shadow the failure to accomplish the goals. This
can save face for the senior management and avoid embarrassment.
Senior management is responsible for the decision to terminate. Before making a
decision senior management should work closely with the project manager who is in charge of
the project. The project manager should know the situation quite well. If he is a good project
manager he works closely with the project team and gets periodic feedback. So he should be able
to give the management advice whether the project should be terminated or not.
 Project Termination Problems
There are some problems caused by project termination. These can be divided into two groups.
The first group covers the emotional problems. These problems can be divided again into two
parts, problems with the staff and problems with the client. The staff might be afraid that they
won‘t have future work. Project termination can also lead to some losses, for example loss of
interest in the remaining task, loss of project- derived motivation or the loss of the team identity.
On the other hand there is the client. After a termination he might change his attitude,
lose interest in the project, or won‘t ask the organisation to take part in further projects. It also
might be that the client will change his personnel: knowing that the project has already failed, the
client might decide that people who worked on the project should change their position. This
could lead to unavailability of key personnel.

27. 27
The second group deals with physical problems. This group can also be divided into two smaller
ones as shown in fig. 7-1.