Monitoring and Controlling in Project Management

Monitoring and Controlling is a major phase in project management practices.

When you have completed this chapter you should be able to demonstrate an understanding of the following:

  • the project control cycle, including project planning, monitoring achievement,
  • identifying variances and taking corrective action;
  • the nature of and purposes for which project information is gathered;
  • how to collect and present progress information;
  • the reporting cycle;
  • how to take corrective action.

Introduction to Monitoring and Controlling in Project Management

Chapter 1 described the typical stages of a project that implements an information system. There we stressed the importance of controlling the project to ensure that it conforms to the plan. In Chapter 2, we explained the way in which the plan for a particular project is created.

This chapter explores the means by which a project is monitored and controlled so that it broadly fulfils its plan. The mechanism for this is the project control cycle.


The project control cycle involves the following sequence of steps:

  • producing a plan for the project to follow;
  • monitoring progress by collecting information about project performance;
  • comparing actual progress with the planned progress;
  • identifying variations from the plan;
  • applying corrective action if necessary.

Corrective action would usually involve changes to parts of the plan. These changes would have to be communicated to the project team and, where necessary, to stakeholders who might be affected by the changes.

All steps are repeated to continue the control cycle, until the project is completed or abandoned.

Imagine a ship’s voyage across the Channel from Dover to Calais as your project. The plan would involve following a certain route, aiming to arrive in Calais at a certain time. As the voyage progressed, the navigator would check the ship’s progress against the planned course. If there was a difference, he or she could then decide that a change of speed or an alteration of course was necessary – this would be corrective action. The process would, of course, continue until the ship arrived at its destination. Without this control cycle, the ship could continue on a fixed course and speed, and would be very unlikely to arrive at the planned destination or at the expected arrival time.


Monitoring progress is less straightforward in an IT project than in the ship example. The first question, which we tackle in the next section, is how to identify things that should be monitored. We usually know what the final objective of the project is, but how do we know how well we are progressing towards that objective?

What should we monitor?

The most obvious thing to monitor is the progress in creating deliverables and other, intermediate, project products, and in reaching milestones or deadlines. Difficulties arise when you want to monitor progress of things that are partially complete. The simple solution is to break the products and deliverables into smaller components that can be assessed as complete at shorter and more frequent intervals of time – for example, software can be broken down into smaller, relatively self-contained modules.

Where this is difficult, an alternative is to assess the percentage completion of an activity or deliverable. This can be problematic. If someone is building a wall, it is easy to see when it is half finished, but, particularly in the case of software, most project products are less obviously visible than with a wall.

The project manager finds that an activity which appears to be completed has in fact delivered a defective product

The project manager often finds that an activity which appears to be completed has in fact delivered a defective product that requires the activity to be reopened to carry out remedial work, which delays project progress. Hence, project control depends on effective quality processes that check the quality of the methods used to carry out each activity and the quality of the deliverables of each activity. This is covered in more detail in Chapter 5 on quality issues.

In Chapter 6, we describe size or effort drivers. These allow us to measure the size of the job to be done. In the case of building the wall, the number of bricks would be an obvious size driver: the bigger the wall, the more bricks it will need. The size/effort driver can be used to monitor progress.

For example, if we know that the bricklayer will need to lay 200 bricks to build the wall but only 50 have been laid so far, then we can assume that the job is about 25 per cent complete.

In the end, the project’s deliverables need to be useful to the people who will have to interact with them. The deliverables also need to enable the hoped-for benefits that motivated the project sponsors to invest in the project. The project will have been planned with this in mind. During the implementation of the project, changes may be made – such as reducing the functionality to be produced – and the impact of this on the benefits of the project must be assessed. This will need the approval of the sponsor.

The use of resources also needs to be monitored, which in IT projects are mostly ‘human resources’ or staff time. Also, financial expenditure should be carefully monitored. In the scenario in Activity 3.1 below, allowing the installer to stay in an hotel between installations in the same region may save on travelling time (and fuel costs) and speed up the installation rate, but it would need to be balanced against the additional cost of accommodation.

Surprisingly, however, financial expenditure on human resources is not always strictly monitored in IT projects if the project team are permanent employees in an IT department and therefore viewed as overheads.


There are 20 boatyards and marinas where Water Holiday Company customers collect and return their hired boats. As part of the new integrated booking system, online customers will be emailed an e-ticket, containing a barcode, which they will be expected to present at the relevant marina at the start of their holiday with evidence of their identity. The e-ticket requires new IT equipment to be installed at each boatyard/marina, and some additional training will be needed in other features of the new system – for example, recording the non-availability of boats for maintenance reasons.It has been estimated that the installer will, on average, need a day to travel to a marina, install the new equipment and show local staff how it is used. Twenty days (or four working weeks) have been allocated for the installation of all the equipment.

However, at the end of the first week only three marinas have in fact been visited.

  1. How long is it likely that the installation programme will now take?
  2. What difference to the figure you have produced in (a) might be made by the following circumstances?

The installer started two days late because some items of equipment had not been delivered.
The installer started with the marinas furthest afield, and needed extra time to travel to the area and back.
As well as scope – essentially the amount of functionality being produced – being reduced to meet a deadline, functionality to be delivered could increase because new requirements are discovered. See requirements change management. If these additions to the work are not monitored and controlled, costs and delivery time will be affected.

Thus time, cost and the scope of deliverables need to be balanced. For example, it may be possible to accelerate the progress of a late project by employing more staff, but this would increase the project cost. On the other hand, it may be possible to meet the deadline within the budgeted cost by reducing features in the application to be delivered – see Section 1.7.2, where timeboxing was described.The systems that bring these different types of project information together for consideration are often referred to as dashboards.

How to do monitoring and controlling

Monitoring involves collecting information about actual project progress. This enables the comparison of actual project performance with what was envisaged in a plan. Formal monitoring methods include the use of written reports, email and progress meetings. The frequency, format and content of these communications should be laid down at the start of a project in the project management plan (see Section 1.8.1). Remember that this activity is mainly defined in waterfall project management and not in incremental and Agile methodologies and work models.

Formal monitoring establishes routines so that people periodically focus on progress and commit themselves in writing. However, preparing reports can be seen as an unproductive overhead. Staff need to be convinced of its value. Thus, timesheets can be effective in establishing the staff effort expended on distinct aspects of projects, but staff need to be persuaded to fill them in conscientiously.

Many phrases can describe informal monitoring: keeping one’s ear to the ground; management by walking about; open door policy. All these make the manager aware of what team members are experiencing. Project managers need ways of maintaining good informal lines of communication with all project staff. This often allows problems to be resolved before they would otherwise appear in a progress report. However, a pitfall to avoid is the alienation of team members by over-supervision.

Leave a Reply

Your email address will not be published. Required fields are marked *