TECHNICAL AND VOCATIONAL TEACHERS’ COLLEGE

PROGRAMME: DIPLOMA IN ICT WITH EDUCATION

COURSE: PAM 230 PROJECT MANAGEMENT

UNIT 5.3: PROJECT CONTROL

5.1 INTRODUCTION

Monitoring is by itself not management, and finding out how things are going is quite
useless unless you are prepared to do something to apply corrective action where it is
needed. This may sound obvious but it is surprising how many project managers are
happy to sit at their computers all day, lovingly capturing in immense detail the
timesheet, financial and quality review data, whilst the project is careering crazily out of
control. This has been described as ‘management by spreadsheet’ but, in reality, it
represents the antithesis of management; it is merely book-keeping.

Project control really has four elements, illustrated in the figure below. The first stage is
to evaluate the current situation in other words what will happen if things continue as
they are? The second is to consider various corrective measures that could be applied and
to assess the pros and cons of adopting each alternative course of action. The third stage
is to select and implement one of the courses of action. And the fourth stage links back
into the monitoring process since you need to check that the control action has had the
desired corrective action on the project.

5.2 EVALUATING THE CURRENT SITUATION

The starting point for this is the information you have gathered through your monitoring
processes, for example:

1
 • Timesheet information showing the effort booked to date on a task, the effort still
to go and the predicted end-date.
• The results of quality reviews showing whether the deliverables are meeting their
defined quality criteria.
• Financial information showing costs accrued so far and expected in the future.

This information is compared with the various plans to find out if there is a problem and,
if so, how big it is likely to be. For effort and timescale information, the important plan to
examine is the network diagram. If a task is — or is expected to get — behind schedule,
is it on the critical path? If it is not, is there sufficient float or slack to accommodate it?
Even if there is, this does not deal with the effort overrun, so can we afford the extra
work that now seems to be involved? If the task is on the critical path, what will be the
knock-on effects?

For information on quality, will the defects discovered affect our ability to deliver a
conformant product at the end? Do we need to rework the deliverables and, if so, have we
the time and resources available to do so? Is the quality failure a one-off or does it
indicate some deeper problem, such as an overall lack of the necessary skills, or a too-
tight timescale, or an imprecise specification? For cost information, is the project likely
to come in over budget at the end? Can we compensate for some increased costs now by
using cheaper or alternative materials or suppliers later?

In carrying out these evaluations, you need to consider what the balance is on this
particular project between the triple constraints of time, cost and quality.

5.3 CORRECTIVE ACTIONS

There are a number of possible corrective actions that might be considered during an IS
project. However, we present here some of the most common project management
responses to problems encountered on IS projects. Incidentally, in trying to identify
control actions, do not forget one of your most valuable sources of ideas: the project team
members.

5.3.1 Doing nothing

This option should always be considered first as it provides the benchmark against which
to evaluate the other possibilities and it may even be the right answer. By doing nothing,
we do not mean failing to act. We mean considering the alternatives and then deciding
that allowing things to continue as they are is the best or perhaps the least bad option.

There are two major dangers associated with the ‘do nothing’ option:
• An indecisive project manager may wish to cover inactivity as a constructive act,
thereby claiming that doing nothing is the best answer when, in fact, some more
vigorous action is needed.
• The desire to be seen to be ‘doing something’ may cause the project manager to
take an action which makes the situation worse, whereas letting things continue

2
 on course for the time being might have been the correct response.

Avoiding these pitfalls requires that the project manager be severely honest with himself
and it also needs considerable strength of character to withstand the pressure to be seen to
be taking some action. It can be helpful if a proper risk assessment is made of the various
options, including doing nothing, so that the decision not to act can be seen to be based
on a full analysis of the situation.

5.3.2 Adding more staff

If the problem is that an activity is getting behind schedule, then one possibility is to
assign more staff to it. This will work only if the task can be partitioned since otherwise
we shall get a situation of ‘too many cooks spoil the broth’. Even if the task can be
partitioned, the need for the additional staff to get up to speed on the work, the need for
the existing staff to brief and guide the newcomers and the need for communication
between the staff will all mean that the overall productivity will be lowered to some
extent. At the limit, adding more staff may actually make the task take longer than if we
had soldiered on with the original people.

5.3.3 Adding different skill

As an alternative to adding more staff, we could consider adding people with different or
greater skills. For example, if we are using an unfamiliar programming language and
creating programs is taking an inordinate time, one possibility might be to recruit an
expert in the language perhaps an external consultant and let them act as a technical
adviser and guide the rest of the team. Alternatively, if the problem is that the staff lack
experience in the general sense, adding a few ‘old hands’ to the team could make all the
difference. There is a noticeable difference in productivity between experienced staff and
new trainees, so a sprinkling of experience could yield great improvements in overall
team efficiency and effectiveness.

5.3.4 Using overtime

Overtime is often the cheapest way of buying additional effort. It is cheap since, although
we pay an enhanced hourly rate for it, we do not have to pay additional overheads for
National Insurance, pension, office space and so on. So, to meet a short-term crisis,
overtime is a good answer. However, long-term or consistent use of overtime is a
different proposition. If people are regularly working long hours, their overall
productivity gradually reduces. Also, people come to rely on the income from overtime
and therefore — whether consciously or not — may begin to spin out their tasks in order
to guarantee the overtime payments.
5.3.5 Reassigning task

Without adding anyone new to the team, you can sometimes get better productivity, or
better quality work, by switching the tasks around. For example, if you have someone
who is extremely thorough, they may be very slow in producing anything worthwhile —

3
though it will be of good quality once it appears. If this slowness is a problem, then why
not use this person in a quality control or reviewer role? Some people are good at creative
work, developing ideas from a blank sheet of paper, but not so good at following through
into detailed designs. So use them for the up-front analysis tasks.

5.3.6 Increasing individual supervision

A member of the team may be having productivity or quality problems with their work
and this may be coming to light only when they deliver products. If so, consider
partitioning the tasks and creating some smaller deliverables, so that quality control can
be exercised more frequently. If you have an inexperienced or nervous person on the
team, they will welcome the opportunity to share their difficulties and obtain guidance on
a more regular basis.

5.3.7 Finding improved methods of work

You need to consider whether the methods adopted are the most suitable for the tasks in
hand. For example, you may be involved in the analysis phase of the project and you find
yourselves shuttling back and forth between different users trying to reconcile what seem
to be mutually exclusive requirements. The answer here might be to abandon the con-
ventional analysis techniques and to adopt some sort of Joint Application Development
approach, staging workshops where all the users can come together with the analysts and
thrash out their requirements.

5.3.8 Re-planning the project

Your evaluation of the problems may reveal some fundamental flaws in the way the
project has been planned. This is irritating, as planning is an intensive process and it is
irritating to find that the plan is not working out. However, there is no point in pretending
that a plan is still feasible if some of its assumptions have been proved worthless, and the
only recourse is to go back to square one or at any rate, back far enough to see whether a
more realistic plan can be devised for the rest of the project.

In developing your new plan, remember that the old one gave rise to certain risks; the
new plan may remove or mitigate these risks but it will almost certainly introduce new
ones, so a reassessment of the risks should form part of the replanning process.

5.4 IMPLEMENTING CORRECTIVE ACTIONS

Whatever control actions you decide to take, there are two important things you must do:

• Make sure that everyone knows about the changes you are making and how they
impact on the project as a whole. There is nothing more annoying for team
members, or wasteful of scarce resources, than for someone to be left working on
a deliverable that is no longer wanted, or is wanted in a different form, because of
a change of plan.

4
 • Evaluate, through your normal monitoring system, whether the changes have had
the desired effect.

The effects of the changes should be monitored closely to see whether they are working
or not and, in particular, to see if the risks associated with them are coming to pass. It is
likely that you will have to make further adjustments, and it is a sign of strength, not
weakness, to make these when necessary. However, resist the temptation to keep fiddling
with the plan: if your control actions seem to be having broadly the desired results, leave
things alone unless they are seen to be going adrift again.

5.5 CHANGE CONTROL

During the lifecycle of any IS project, change is inevitable. Project changes can arise for
many reasons, including:

• Change in the business environment in which the customer operates and to which
they must respond — for example, the introduction of a new product or service by
a competitor.
• New personnel coming into the customer organization with different views from
their predecessors, particularly if the sponsors of the project or leading users
change.
• Revised user ideas of what the project should be about, perhaps triggered by the
discussions that have occurred during detailed requirements analysis.
• Suggestions from the development team, based on an improved understanding of
the users’ requirements.
• The availability of new technology, offering different possible system solutions.
• New or revised legislation, imposing additional or different responsibilities on the
customer.
• A straightforward change of mind by the users as to what they want.

The chief problem with changes is that they are not always seen as such by all the parties
involved. Quite often, the developers will classify something as a change which the users
say is merely a clarification of a requirement that was always there. Disagreements of this
sort have always bedeviled IS projects and seem to stem from the inability of users and
developers to find a common means of communication.

One factor that often decides the intensity of the argument is the perceived cost of
implementing the change. Generally speaking, the earlier the change is identified, the less
will be the costs of incorporating it. If a change is noticed during analysis, then it is likely
that the requirements specification will simply be written a little differently. If it is
identified during the acceptance test, however, then the design will have to be changed,
the programs rewritten and the various tests repeated.

Before a decision can be made on whether to implement a change, a thorough

investigation needs to be conducted to discover:

5
 • The total impact of the change on the development work — time, cost and quality.
• The effect of the change on the users — on their training and implementation
requirements, for example.
• Any implications of the change on the proposed size or configuration of hardware
or communications.
• The consequences of not implementing the change.
• The risks resulting from implementing, and from not implementing, the change.

All changes therefore need to be subjected to proper cost/benefit, impact and risk
analysis. Once this information is available, the project manager and the customer can
have an informed negotiation on the change and, hopefully agree the way in which to
handle it. This will almost certainly involve some change to the plan and quite possibly a
variation to the contract as well.

A saying that the project manager should bear in mind is that there is no such thing as an
“insignificant change” — or at least there is not until you have investigated it thoroughly.
A moment’s reflection will reveal the truth in this assertion. A change that seems at first
sight trivial may, in fact, have very significant consequences. Moreover, the investigation
of a change in itself incurs effort and takes time, so that will have a small impact on the
project if nothing else does.

5.5.1 Change control and configuration management

There is often confusion between change control and configuration management. The
basic distinction is this:

• Change control is the set of procedures that ensure that changes are made only
after due consideration of their impact.
• Configuration management ensures that, if the changes are implemented, then
amendments to each of the affected deliverables are properly controlled and
recorded.

Configuration management is required in all projects, whether or not they ever have any
changes imposed on them, and the evaluation of the effects of a change will be greatly
facilitated if there is a good configuration management regime in place.

5.6 REPORTING PROGRESS

We now examine the ways in which progress is reported. Usually, when we talk of
reporting progress, we are thinking about reporting upwards to our immediate boss, to the
board maybe, to the customer certainly. But for the project manager, there is another
group of people who need to know how we are doing: the project team. You might
imagine that team members would know how they are doing, but it is surprising how
often people feel in the dark about the overall progress of the project, the significance of
their contribution, and their own management’s and the customer’s perception of their
work.

6
Reporting progress to the team can often be a very motivating experience, as team
members can see the importance of their own contribution and the appreciation that
others feel for their efforts. Even when the news is bad, explaining the situation to the
team will help them understand why you may be putting more pressure.

5.7 RECIPIENTS OF PROGRESS REPORTS

Apart from the project team members, mentioned already, who is likely to want to
receive reports on the progress of the project? The situation will differ from project to
project, but recipients are likely to include:

• The project manager’s immediate superior. In an in-house IT department, this

may be a systems development manager or IT manager/director. In a systems
company, this is likely to be a business manager or, for a very large project,
perhaps a board member. There may also, or instead of these, be a project
controller or project director — someone with overall responsibility for all project
work.
• The customer. Where the work is being carried out under a contractual rela-
tionship, the customer will be the person who has commissioned and will pay for
the project, sometimes known as the project sponsor.
• The users. The users may well be different people from the sponsor. In some
organizations, and on some projects, the users may be a large and disparate group,
and generating the paperwork to keep them all informed may involve a regular
assault on the world’s trees!
• The quality assurance department, if there is one.

Each of the above groups will have rather different reporting requirements. The users
will be interested primarily in seeing when they are likely to get their system and when,
perhaps, they will have to start preparing themselves for training or system
implementation. The sponsor will also wish to know these things plus, if the work is
being done on a time-and-materials basis, a summary of the costs to date and the likely
overall cost. The IT manager will want to know when resources will be required for this
project and when they will become available for other work. In the systems company, the
business manager will require predictions on the current and forecast profitability of the
project and will need to know when invoices should be raised for payment. Finally, the
quality assurance people will want to arrange quality audits at appropriate points in the
project. Consequently, depending on the organization in which the project is taking place,
the project manager may have to prepare a variety of reports, each with a slightly
different slant.
5.7.1 FREQUENCY OF REPORTING

Some judgment needs to be exercised in deciding how often to produce the various
reports. if they are too frequent, then their production can become a full-time occupation
to the disadvantage of other project management work. On the other hand, if they are few
and far between, you lose the opportunity to raise important issues and to get decisions

7
made and clarified. Possibly, the major reporting cycles will have been established at
project initiation or mandated in the contract. For internal reporting, a monthly cycle is
common, usually tied to the end of accounting periods.

Reports should, at the least, be prepared at the end of project phases or stages, or perhaps
keyed to project milestones. This gives everyone an opportunity to take stock, review the
project and decide if any changes of direction are needed. If the project has a very long
stage — requirements specification often falls into this category — some mid-stage
report may be advisable.

5.7.2 REPORT CONTENT AND FORMAT

The reporting requirements should be established at the start of the project. When the
contract is being agreed or the project plans are being developed. That way, the project
manager can include effort for report preparation in the plans. In addition, the format and
structure of the reports should be agreed and documented.

The usual recommendation is to aim for a system of reporting ‘by exception’. What this
means is that, instead of hurrying out a long list of things which have gone according to
plan, we highlight only, or at any rate, mainly those activities that for some reason or
other are not going according to plan. Assuming the project is running reasonably
smoothly, this form of reporting should lessen the work involved for the project manager
and enable everyone to concentrate on those areas that are not going quite so well and
hence require more management attention.

There is, however, quite a significant drawback to exception reporting, especially if the
project manager is trying to sustain the enthusiasm and commitment of sponsor and users.
The problem is that exception reporting, by its very nature, tends to concentrate on failure
— missed deadlines, cost overruns, staffing problems and so on — and this can bring
about a negative view of how the project is going.

Reports are normally provided in writing, as this enables them to be circulated easily and
gives the recipients time to read and digest the information. Often, though, the report will
be supplemented by a progress meeting where the project manager will present a
summary of the report and deal with any comments or questions that arise from it.

The reports to the various parties will usually take the formats that follow.

5.7.2.1 Reports to the customer will contain:

• A report identifier — project name, report sequence number, date of report.

• A short narrative review of progress since the last report.
• Milestones achieved, with dates and comparison with planned dates.
• Problems encountered — ideally with solutions used or proposed.
• Current predicted project end-date and dates for other significant events such as
system implementation.

8
 • Change requests — details of new ones, status of existing ones.
• Costs to date and estimated outturn.

In addition to the above, the report may also contain an updated version of the project
plan, perhaps at a high level — showing only the main phases of the project — and
highlighting any variations from the previous version.

5.7.2.2 The user reports will contain:

• A report identifier — project name, report sequence number, date of report.

• A short narrative review of progress since the last report.
• Milestones achieved, with dates and comparison with planned dates.
• A revised schedule of user interface activities — such as review meetings, pro-
totyping demonstrations, training and implementation dates.

In writing this report, the project manager needs to remember that one responsibility is to
sustain the interest and commitment of the users and to ensure that they are able to play
their full part in the project.

5.7.2.3 Reports to IT and business management should include:

• A report identifier — project name, report sequence number, date of report.

• A short narrative review of progress since the last report.
• Milestones achieved, with dates and comparison with planned dates.
• Problems encountered — ideally with solutions used or proposed.
• Current predicted end-date and dates for other significant events such as system
implementation.
• Change requests — details of new ones, status of existing ones.
• Costs to date and estimated outturn.
• Significant customer interface issues encountered — for example, any dis-
agreements over the scope or specification of the work.
• Opportunities for additional work or follow-on business.

These reports should be completely frank and open and should be written to ensure that
senior management is fully apprised of the true current state of the project. This frankness
can sometimes create difficulties for project managers who work in closed cultures or
where their managers do not want to hear about problems. Project managers have to tread
a fine line between keeping information to themselves, in which case they will probably
take all the blame for any subsequent disasters, or seeming to do nothing but report
problems.

5.8 REPORT PRESENTATIONS

The written report will be followed by a presentation to the following:

9
 • project sponsor
• project steering committee
• user group
• senior IT management
• Team briefing.

Although some people dislike speaking at such gatherings, presentations do provide an

opportunity to inject some more animation into the reporting process and to rekindle the
enthusiasm and commitment of the audience. So, the project manager needs to prepare
carefully for the presentation.

The main thing not to do is to use the presentation to read through the written reports.
This is a waste of an opportunity and an insult to the audience after all; they can read for
themselves, Instead, prepare a short, effective presentation, ideally illustrated with slides
or overheads, focusing on the main issues. These should include:

• The objectives of the project and its expected benefits. It is always worth restating
these, especially when the project has been running for some time, everyone is up
to their ears in its difficulties and interest is beginning to flag.
• The achievements to date. Starting here helps stimulate a positive view of the
project, whatever comes next.
• The problems. Be frank but do not seek to apportion blame. Problems happen and
they need to be dealt with, so identify the possible solutions and engage the
audience’s commitment to getting the problems out of the way.
• The vision of the future — where the project is going and when it will get there.

If the project is not going too well — and, at times, most projects are not going too well
the project manager can expect to suffer a fair amount of criticism at a meeting.

10