TECHNICAL AND VOCATIONAL TEACHERS’ COLLEGE

PROGRAMME: DIPLOMA IN ICT WITH EDUCATION

COURSE: PAM 230 PROJECT MANAGEMENT

UNIT 5.1: PROJECT PROGRESS AND CONTROL

Aims and objectives

The aims of this lecture are to:

• Consider monitoring techniques for each element of the triple constraint

• discuss the mechanisms needed in order to monitor progress

5.1 INTRODUCTION

The planning of the project that involves establishing what is to be done, by whom, by
when and to what standards can be said to be the easiest part of the project. The more
difficult part is the actual running of the project on a day-to-day basis, monitoring
progress and making changes as necessary to ensure that it keeps on track for the purpose
of delivering its final objectives. After the implementation of the plan, and the project is
up and running, there is now a need for strict monitoring(to see what is really going on)
and control (when the project is not going as planned) of the project in order to ensure its
success.

The project needs to be managed from three perspectives, those of the triple constraint of
time, cost and quality. Sometimes, the management decisions we make will involve a
trade-off between these three elements — we might be able to deliver on time if we
sacrifice some of the performance of the system or guarantee the quality if the costs can
be allowed to rise. These decisions may be outside the project manager’s control and the
project manager may have to get involved with some hard bargaining with the project
board or the customer or their own senior management, before a revised approach can be
agreed.

In this lecture, we examine a number of areas that require monitoring and control within
the project as presented below;

5.2 MONITORING EFFORT

To monitor progress, we need first some mechanism for collecting figures on the
resources used. On IS projects, the major resource element is staff time but there are also
costs to be considered for resources such as machine usage and bought-in hardware and
services.
To gather information on the effort expended, there really is no alternative but to get the
team members to complete timesheets of some sort. Although this is pretty obvious, there

1
can be political difficulties in the way staff, and sometimes trade unions, may see the
completion of timesheets as ‘Big Brother’ spying on them, and others, perhaps the more
senior or experienced people, may resent having their work examined minutely in this
way. In consultancy companies, the use of timesheets is quite usual as they support the
billing process, and the same is also true for in-house IT departments that operate as
profit or value centers. If the project manager is working somewhere where timesheets
are not the norm, then there is a need to practice extreme diplomacy in explaining to the
team why timesheets are so important and how vital they are to proper control of the
project. If there are problems in getting timesheets accepted, one possibility is to use a
design that records only time spent on project work — in other words, you are not
interested in time spent on non-project activities. A number of software solutions are
available to assist the project manager with this aspect of the project e.g. MS Project.

The reasons for any going away from the planned timescale must be examined
thoroughly since corrective action to be taken will depend upon the results of this
important analysis.

We now want to consider the situation where a programmer might be expecting an

estimated ten-day coding task to overrun by two days.

There could be various causes of this including:

• The programmer’s inexperience. In this case, the program may have been too
difficult and the project manager could consider reassigning work so that this
programmer has simpler programs in future.

• Lack of clarity in the program specification. If this is so, the question to be asked
is, ‘does the same apply to the other specifications?

• Lack of access to the development machine. Here, the project manager can ease
things for the team by obtaining greater access.

If the project manager is to take the right action to deal with the matter, it is necessary to
know which of these problems or any others is at the root of the need to overrun.

Having composed information at an individual level, the next step is to summaries it at a

project level to see the overall situation. Project planning packages usually have facilities
to do this, although sometimes they are rather cumbersome to use. Alternatively, the
project manager can set up a spreadsheet to do the same thing.

A major part of a job as Project Manager is to monitor progress, and a list of the data that
would be used within a spreadsheet application to assist in monitoring the progress of the
project will include the following:

• Its current status — not started, in progress or completed.

• The original effort estimate.

2
 • The original cost estimate (effort x daily rate).
• The original start-date.
• The original end-date.
• The actual start-date.
• The effort booked to date.
• The cost booked to date (effort x daily rate).
• The effort estimated still to go.
• The cost estimated still to go (effort x daily rate).
• The current predicted total effort.
• The current predicted total cost (effort x daily rate).
• The current estimated end date.

Bar charts can be used to graphically express this information.

5.3 MONITORING OTHER COSTS

Labour costs are usually the main cost component of an IS project but there are other
costs as well and all have to be kept under review. We now consider how best to do this.

To start with, it is important to distinguish between the cost and the price of something.
The cost is what we have to pay for the resource, be it staff salaries or a piece of
hardware. The price is what we charge for the same thing, and the difference between the
two represents our profit, if we are out to make a profit.

Staff costs are best dealt with by establishing some sort of daily rate for each team
member, probably based on their grade or classification. Staff costs do not just include
the person’s salary; on top of that, there will be costs such as contributions to the pension
fund, the employer’s National Insurance contributions, perhaps a private medical scheme
or company car. And on top of that, there will be overheads to cover things like office
space, heating, lighting and the provision of furniture and equipment. Different firms
calculate these things in different ways and the advice of the finance or accounts
department should be sought. Where contract staff are being used, they will probably
submit a weekly timesheet. Once signed off by the project manager, this will be used by
their agency as the basis for an invoice. That will then be submitted for approval, after
which it will be paid and posted to the project’s accounts

The costs for other bought-in items merit some considerations. If you are buying a piece
of hardware, or perhaps hiring some for the duration of the project, the suppliers’
invoices will probably trail behind the actual goods by quite a period. This can be useful
if you want to take advantage of a favorable cash flow, since you can probably bill your
customer before you have been charged yourself and enjoy the use of the money until the
supplier’s invoice arrives.

There are other expenses that should be considered on projects:

• Project-specific training. Sometimes, costs for general developmental training are

3
 borne centrally, though reflected in the staff costs or charge-out rates, but training
for a project task like learning a specialized programming.

• Accommodation and lodging. If, for instance, your team is big enough to require a
self-contained office, the rental of this space may be charged to the project.

• Travel costs. Whether or not they have to stay away from home, staff may be
entitled to reimbursement of travel costs over and above their normal journey to
work. They may be entitled to travel time as well, usually at something like half
the normal rate.

• Consumables. Such as stationery, diskettes, laser toner cartridges and other items
that can add a surprising amount of cost to a project.

• Insurance. If special safety or other considerations apply, the organization’s

normal public liability and similar insurance may not be adequate and special
arrangements may have to be made and charged to the project.

As with other expenses, there will probably be some delay between the costs being
incurred, being signed off and appearing in the accounts, so the prudent project manager
will keep his or her own record of them.

5.4 MONITORING QUALITY

We now review some techniques that may be employed to check the quality of
deliverables as they are produced.

There are two major phases in the quality control process:

• checking
• reviewing

Work should be checked or reviewed as it is in progress and testing the finished product.
Taking the review process first, it is important to apply checks at sensible points in the
project’s lifecycle. In general, it is not sensible to apply quality control to each item as it
is produced, for example to each module of code — although in the ‘total quality’ climate
we would expect the originators of work to be applying their own checks on a continuous
basis. On the other hand, it is no use waiting until, say, a whole suite of programs has
been developed before checking them and finding that there is some fundamental
problem with all of them. Where there is a clearly defined project lifecycle, there should
be checks at the end of each stage and before the project moves on to the next stage.
Thus, one would review the analysis work before moving on to design and check the
design before starting development.

However, there can sometimes be a case for checking smaller units of work. If, for
example, a new design method is being used or the person doing the work is unfamiliar

4
with the techniques or standards to be used, it would be wise to carry out a check as the
first unit emerges from production. As with many other aspects of project management,
there are no hard-and-fast rules here, but a checklist of decision points at which to apply
quality control would include:

• Having checks at the project milestones defined in the project plan.

• Applying checks when moving from one development phase to the next.
• Checking the operation of new standards after their first application.
• Checking on work involving new techniques or methods.
• Checking the work of inexperienced staff or those newly recruited who may have
worked to different standards elsewhere.

With regard to the testing of finished products, there is a fairly self-evident hierarchy of
tests to be followed:

• Individual components, programs or modules.

• Components are linked together and integration tests check that they work
satisfactorily in combination.
• The complete system is tested to ensure that all the components function together
to deliver what the customer specified.
• Customers conduct an acceptance test to satisfy themselves that the product meets
their requirements.

There may be a need for other checks to ensure that the product can handle large
volumes, or operate in adverse conditions or work reliably over a long period of time.

5.4.1 Methods for Monitoring Quality

Various methods exist for conducting quality control reviews, some rather informal and
others highly structured. In choosing one, the guiding idea should be the suitability.
Whatever approach is taken, the review process must be planned.

Methods for monitoring quality

Methods include:-

• Self-checking.
• Team Leader reviews.
• Peer reviews.
• Walkthroughs.
• Fagan Inspections.
• External Reviews.

Self-checking: This really supports the total quality management (TQM) theme and
relies on the author of the work having a good understanding of the requirement and also
of the skills and techniques needed to meet it. The approach is best suited to more

5
experienced team members who should, as with any other check, formally record their
reviews. The big disadvantage with self-checking is that, if someone has misunderstood
something in, say, a design document, they will continue to labour under the same
misapprehension during the checking process and the defect will not be discovered. For
this reason, one of the other forms of check should be used in areas of known criticality
and occasionally elsewhere to verify the self-checking procedure.

Team Leader reviews: Here, a team member’s supervisor is responsible for checking
that work meets its specification and conforms to any necessary standards. If defects are
identified, corrective work is undertaken and the work is then reinspected. This method is
useful when reviews of work are to be linked to coaching — as will often be the case for
junior staff. The problem is that it is only as effective as the supervisor’s ability to spot
problems and, of course, the team leader may not in fact be as skilled as the author in the
particular discipline or technique involved. In addition, bottlenecks can occur with this
method, as all checking has to be undertaken by one person; this is particularly the case
with projects that are using fast programming methods where programmer productivity
can outstrip the ability of the team leader to review the work.

Peer reviews: This is similar in principle to a team leader review in that one person is
checking the work of another. Team leader review and peer review can be used in cycle,
with the team leader in effect sharing the review work with one of the more experienced
team members. Peer review does, of course, rely on the ability of the reviewer to spot
defects, and some people are better at this than others. There is a special danger for the
project manager to watch for with peer reviews: that of rivalry or one-upmanship
between the author and reviewer. They may need reminding that the objective is not to
score points off each other but to produce a high-quality product. In a multidisciplinary
team, where the team leader does not have expertise in the area to be reviewed, peer
review may be the only practical way of conducting quality control.

Walkthroughs: Conducting a walkthrough, which involves a review by a group of

people, can prove very effective, as the skills, knowledge and eyesight (for spotting
errors) of a number of people are brought to bear. Walkthroughs do, however, require
good organization so that everyone concerned is clear about their objectives and has the
necessary documentation available early enough for proper study. In addition, to keep
review meetings moving forward and to stop them straying from the point, good
chairmanship is essential. It is particularly important in walkthroughs to stick to the
identification of problems and to avoid trying to find solutions.

Fagan Inspections: Fagan inspections are a formalized form of walkthrough, named

after Michael Fagan who devised the technique for IBM. With this method, the author of
a piece of work reports to the project manager that it is complete and ready for checking.
This triggers a six-stage review process:

• Planning
• Overview
• Preparation

6
 • Meeting
• Rework
• Follow-up

External reviews: It may sometimes be a good idea to request a review of work from a
body or individual outside the project team. This could be by a quality assurance
department or simply from an expert in the work being undertaken. The principal
disadvantage of an external review is probably cost, but, on a large project at least, the
plans should allow some margin for it. There is an additional problem in that the reviewer
will not have the same familiarity with the material as will members of the project team,
so an external review is likely to take longer.

Data collected from the above processes can be summaries using the following methods:

• Bar (or Gantt) chart showing actual against schedule.

• “S” curve diagram.
• Earned Value Analysis.
• Summary Spreadsheets.
• Milestone Slip Chart.