Depending on what controls you have planned to put into place, establishing them will require focus. At the start of the project there will be energy to move into delivery and start to create things and as a consequence there will be plenty of parallel activity, which will need to be controlled.

The focus of the project manager must be to establish control of what is going on. They should avoid the temptation to let things roll and worry about reporting in a month or so. Control is a daily activity not a monthly report. It is recommended that project managers spend at least 10–20% of their time doing management tasks such as logging and tracking issues and risks and recording progress against plan.

This extract has been reproduced with permission from A Practical Guide to Project Planning, TSO 2016. If you’d like to read more you can purchase the copy of the book here.

The key principles of control will be based on the following:

Control of change: This is essential, as changes of any sort will have an impact on one or more of time, cost, quality or stakeholder perception. Therefore, change must be carefully controlled. There must be a formal process in place with an impact assessment for each change request, and these should be approved by the project board. Small, uncontrolled changes are a major risk to the project achieving its objectives.
Timely and accurate information: Information should be relevant to the controls in question and relate to the four areas of control. Lack of or poor quality information about project performance is evidence of lack of control. The information that is collected should be directly valuable to the control process. It is common for projects to provide prescriptive updates on progress explaining what they have achieved. However, you should report statistics against the baseline wherever possible, and focus on the facts.

Evidence-based progress: This means being able to see tangible proof of progress before accepting it has happened. Such proof can range from receiving a draft report to seeing the foundations of a building.
Monitoring as you go: If you monitor as you go this will save time and pain later trying to collect the evidence. Owners of work packages should report to the project on a regular basis; if they are on the critical path it should be weekly at a minimum. The focus is on identifying early warning indicators from the work packages: extinguishing small fires now is easier that fighting large fires later!
Involvement of the team: Involving the team in the process of control is essential. There is a natural resistance to control and reporting, particularly if people don’t understand the relevance, so gaining the team’s commitment is essential. When the team understands the bigger picture of the project, they may well identify issues in their work packages that may be of little interest to them but may be a major threat or opportunity to other parts of the project.

Tip
Team dynamics and performance are a key area to focus on. If a team works and communicates well, the controls will work more effectively.

Technique

The principal technique in this activity is change control. There are a number of steps that all changes should follow to ensure that their impact on the project is understood.

Change control is normally linked to issue management. Changes will tend to result from an issue being raised by someone, so the start of the change process is the issue log.

As with many things in project management, it is small uncontrolled changes that can aggregate to create major problems later, so the earlier control is established the better. The change control process should be defined when the controls are designed.

The basic steps of change control are listed in Table 5.2.

Steps for change control

After the issue has been logged, the next step is to draw up a change request, wherever possible using standard headings (see Table 5.3), as this will make it easier to assess the impacts of the change and record decisions made about it.

Example

In order to control changes and their impacts it is important that each change requested is documented. Table 5.3 is an example of a request for a change from specifying desktop to specifying laptop computers within a project’s plan.

Table 5.3 Example of a change request

Introduction addition addition The Technique addition The Example

On this page