Monitoring and Control

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.

Creating a Framework

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 and the actual ones.

Replanning may then be needed to bring the project back on target.

Alternatively, the target could have to be revised. 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. It also illustrates the important steps that must be taken after
completion of the project so that the experience gained in any one project can feed into the
planning stages of future projects, thus allowing us to learn from past mistakes.
In practice we are normally concerned with four types of shortfall - delays in meeting target dates,
shortfalls in quality, inadequate functionality, and costs going over target.

Responsibility

The overall responsibility for ensuring satisfactory progress on a project is often the role of the
project steering committee, project management board or, in PRINCE2, Project Board. 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.

With small projects (employing around half a dozen or fewer staff) individual team members
usually report directly to the project manager, but 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.
Reporting may be oral or written, formal or informal, and regular or ad hoc. Informal
communication is necessary and important, but any such informal reporting of project progress
must be complemented by formal reporting procedures.
Assessing Progress

Some information used to assess project progress will be collected routinely, while other information will
be triggered by specific events. Wherever possible, this information should be objective and tangible -
whether or not a particular report has been delivered, for example. Sometimes, however, assessment will
have to depend on estimates of the proportion of the current activity that has been completed.

Setting Checkpoints

It is essential to set a series of checkpoints in the initial activity plan.

Checkpoints may be:

* regular (monthly, for example);

* tied to specific events such as the production of a report or other deliverable.
Taking Snapshots

The frequency of progress reports will 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.

At the level of individual developers, however, strong arguments exist for the formal weekly
collection of information. This ensures that information is provided while memories are still
relatively fresh and provides a mechanism for individuals to review and reflect upon their
environment progress.

If reporting is to be weekly then it makes sense to have basic units of work that last about a week.
Major, or project level, progress reviews will generally take place at particular points
during the life of a project - commonly known as review points or control points. PRINCE2, for
example, designates a series of checkpoints where the status of work in a project or for
a team is reviewed.

At the end of each project Stage, PRINCE2 provides for an End Stage Assessment where an
assessment of the project and consideration of its future are undertaken.
Collecting the data

As a rule, managers will try to breakdown 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. The first successful
compilation of a program, for example, might be considered a milestone even though it is not a
final product.
Partial completion reporting

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.

It is therefore common to adapt or enhance existing accounting data collection systems to meet the
needs of project control.

Weekly timesheets, for example, are frequently adapted by breaking jobs down to activity level
and requiring information about work done in addition to time spent.

Figure shows an example of a report form, in this case requesting information about likely
slippage of completion dates as well as estimates of completeness. Other reporting templates are
possible.

For example, rather than asking for estimates of percentage complete, some managers would
prefer to ask for the number of hours already worked on the task and an estimate of the number of
hours needed to finish the task off.
Red/amber/green (RAG) reporting

One popular way of overcoming the objections to partial completion reporting is to avoid asking
for estimated completion dates, but to ask instead for the team members’ estimates of the
likelihood of meeting the planned target date.

One way of doing this is the traffic-light method. This consists of the following steps:

- identify the key (first level) elements for assessment in a piece of work;

- break these key elements into constituent elements (second level);

- assess each of the second-level elements on the scale green for ‘on target', amber for 'not on
target but recoverable' , and red for 'not on target and recoverable only with difficulty’;

- review all the second-level assessments to arrive at first-level assessments;

- review first- and second-level assessments to produce an overall

Traffic-light assessment highlights only risk of non-achievement; it is not an attempt to
estimate work done or to quantify expected delays.

Following completion of assessment forms for all activities, the project manager uses these as a
basis for evaluating the overall status of the project.

Any critical activity classified as amber or red will require further consideration and often leads to
a revision of the project schedule.

Non-critical activities are likely to be considered as a problem if they are classified as red,
especially if all their float is likely to be consumed.