Dr.

Sushruta Mishra
Once work schedules have been published and the project is started, attention must
be focused on progress.

This requires monitoring of what is happening, comparison of actual achievement

against the schedule and where necessary, revision of plans and schedules to bring
the project as far as possible back on target.
The Project control cycle

• Exercising control over a project and ensuring

that targets are met is a matter of regular
monitoring – finding out what is happening and
comparing it with targets. There may be a
mismatch between the planned outcomes.

• Figure illustrates a model of the project control

cycle and shows how, once the initial project plan
has been published, project control is a continual
process of monitoring progress against that plan
and, where necessary, revising the plan to take
account of deviations.
Project reporting structures
v The overall responsibility for ensuring satisfactory progress on a project is often the role of the project steering
committee, project management board or Project Board.

v Day-to-day responsibility will rest with the project manager and, in all but the smallest of projects, aspects of this can be
delegated to team leaders.

Figure illustrates the typical

reporting structure found
with medium and large
projects. In most cases team
leaders will collate reports on
their section’s progress and
forward summaries to the
project manager. These, in
turn, will be incorporated into
project-level reports for the
steering committee and, via
them or directly, progress
reports for the client.
Assessing progress

Checkpoints: Predetermined times when progress of a project is checked.

Ø Event driven: Check takes place when a particular event has
been achieved
Ø Time driven: Date of the check is pre-determined

Frequency of reporting depend upon the size and degree of risk of the project. Team leaders, for example,
may want to assess progress daily (particularly when employing inexperienced staff) whereas project
managers may find weekly or monthly reporting appropriate. In general, the higher the level, the less
frequent and less detailed the reporting needs to be
 Collecting progress details
Need to collect data about:
v Achievements
v Costs

A big problem: how to deal with partial completions (99% completion syndrome)
Possible solutions:
• Control of products, not activities
• Subdivide into lots of sub-activities

As a rule, managers will try to break down long activities into more controllable tasks of one or two weeks’ duration.
However, it will still be necessary to gather information about partially completed activities and, in particular, forecasts
of how much work is left to be completed. It can be difficult to make such forecasts accurately.

Where there is a series of products, partial completion of activities is easier to estimate. Counting the number of
record specifications or screen layouts produced, for example, can provide a reasonable measure of progress. In some
cases, intermediate products can be used as in-activity milestones.
Ø Many organizations use standard accounting systems with weekly timesheets to charge staff time to individual jobs.
The staff time booked to a project indicates the work carried out and the charges to the project. It does not,
however, tell the project manager what has been produced or whether tasks are on schedule.
Red/amber/green (RAG) reporting
q i d e nt i f y t h e key ( f i rst l eve l ) e l e m e nt s fo r
assessment in a piece of work;
q Break these key elements into constituent
elements (second level);
q Assess each of the second-level elements on the
scale
v Green for ‘on target’,
v Amber for ‘not on target but recoverable’,
v Red for ‘not on target and recoverable
only with difficulty’;
q Review all the second-level assessments to arrive
at first-level assessments
q Review first- and second-level assessments to
produce an overall assessment.
Review
• Review of work products is an important mechanism for monitoring the progress of a project and ensuring the quality
of the work products.
• Testing is an effective defect removal mechanism.
However, testing is applicable to only executable code.
Review is applicable to all work products.
• Review usually helps to identify any deviation from standards.
• Reviewers suggest ways to improve the work product
• A review meeting often provides learning opportunities to not only the author of a work product, but also the other
participants of the review meeting.
• The review participants gain a good understanding of the work product under review, making it easier for them to
interface or use the work product in their work.

Review roles
Ø Role of the moderator include scheduling and convening meetings, distributing review materials, leading and
moderating the review sessions, ensuring that the defects are tracked to closure.
Ø Role of the recorder is to record the defects found, the time, and effort data.
Ø The review team members review the work product and give specific suggestions to the author about the existing
defects and also point out ways to improve the work product.
Review process Planning: The project manager nominates
a moderator. Moderator selects rest of the
team. Team can have the author of the
preceding work product, member who
would use the work, Peers of the author,
authors of the work products interfaces.

Preparation: Moderator convenes a brief

preparation meeting, author presents a
brief overview of the work product,
reviewers individually carry out review and
record in review logs.

Review Meeting: Reviewers give their

comments based on the logs they have
prepared. Recorder scribes all the defects
and points that the author agrees.

Rework: The author addresses all the

issues raised by the reviewers and
prepares a rejoinder. a final summary
report of the review is prepared.
Project Termination Review
• Project termination reviews provide important opportunities to learn from past mistakes as well as successes.
• Project termination need not necessarily mean project failure or premature abandonment. A project may be
terminated on successful completion

Reasons for Project Termination

Ø Project is completed successfully handed over to the customer.
Ø Incomplete requirements
Ø Lack of resources
Ø Some key technologies used in the project have become obsolete during project execution
Ø Economics of the project has changed, for example because many competing product may
have become available in the market.

Project Termination Process

v Project survey
v Collection of objective information
v Debriefing meeting
v Final project review
v Result publication
Visualization Progress::::
Cost monitoring

• A project could be late because the staff originally committed have not been deployed

• In this case the project will be behind time but under budget

• A project could be on time but only because additional resources have been added and so be over budget

• Need to monitor both achievements and costs

Change control
v Identifying items that need to be subject to change control
v Management of a central repository of the master copies of software and documentation
v Administering change procedures
v Maintenance of access records

Typical change control process

Ø Users perceive the need for a change. User management decide that the change is valid and worthwhile and pass it to
development management.
Ø A developer is assigned to assess the practicality and cost of making the change.
Ø Development management report back to user management on the cost of the change; user management decide
whether to go ahead. One or more developers are authorized to make copies of components to be modified.
Ø Copies modified. After initial testing, a test version might be released to users for acceptance testing
Ø When users are satisfied then operational release authorized – master configuration items updated
Software Configuration Management (SCM)

v SCM is concerned with tracking and controlling changes to a software.

v Development and maintenance environment:
Various work products associated with the software continually change.
Unless a proper configuration management system is deployed, several problems can appear.

Why Use SCM?

o Problems associated with concurrent access
o Undoing Changes
o System accounting
o Handling variants
o Accurate determination project status
o Preventing unauthorized access to the work products
Dr.Sushruta Mishra