Project Controls

This section covers:

• Issue management
• Change control
• Version control

Issue management

Throughout the lifecycle of your project things will happen, people will ask questions or make requests, and you will need to work out how to respond to them. This is issue management.

An issue is basically a certainty (compared with a risk). It is something that definitely will happen or has already happened, and can have a positive or negative effect on the project.  It’s sometimes helpful to categorise issues to make it easier to work out how to respond. There are four categories of issue:

• Question
  (What colour will my car be?)
• Statement of Concern
  (I’m worried that my car will be luminous yellow)
• Request for Change
  (Can you make the car blue instead of black?)
• Off Specification
  (The factory doesn’t have any blue or black paint, so we’ll have to paint it white)

Part of your job as project manager is to track issues as they arise and make sure that they are resolved. You either need to decide on what needs to be done, who needs to do it and when it should be done by, or you need to ask the Project Executive or Project or Programme Board for a decision on what needs to be done.

The easiest way of tracking issues is to use an Issues Log. This will record information on:

• The type of issue and what the issue is
• The impact the issue will have on the project
• Who raised it and when
• What action needs to be taken, who’s taking it, and the deadline
• Whether the issue has been resolved and closed

Using an Issues Log to keep track like this means that you don’t forget about issues, and if issues come up again and again you have a record of how they’ve been resolved. (This also will form an important part of the Lessons Learned at the close of the project.)

Download the Issues Log template 

As with the Risk Register, it’s important to take time out to keep the Issues Log up to date.

 

Change Control

It is almost inevitable that something will change during the life of the project. The Change Control process allows you to track these changes by ensuring that all proposed changes are recorded, and assessed to work out the impact they will have on the project.

Having a formal process allows the project manager to ensure that the scope of the project does not gradually 'creep' outwards over time. It also allows the Project Board to make sure that where changes are approved, they don't reduce the viability or value of the project.

The Change Control process is fairly simple:

1.	All change requests should be recorded by the Project Manager, with key information such as: Date raised Originator Criticality (Critical, Nice to have, Cosmetic) Description Impact and Benefits
2.	If the change is within the agreed tolerances, it can be approved by the Project Manager.  Any change requests that go beyond these tolerances should be referred to the Project Board require the approval of the Programme or Project Board are escalated to the Board and discussed as part of the Change Request Report
3.	If the change is approved, the relevant documentation will be updated to reflect the change and the Action Owner will then complete the appropriate actions to carry out the change

Version Control

All projects produce documents and files, either as a hard copy or electronically. To keep track of documentation you should establish version control at the start of the project. This will make sure all stakeholders can easily identify the most up to date (current) version of any document. The version number also identifies whether a document is a draft or final version.

The following is a common way of establishing version control:

Version	No.	Description
First Draft	0.01	Use a zero to show that the document hasn't been signed off. The number after the decimal is the version number for the draft.
First Approved Version	1.00	Use a whole number to inform the reader that this is a signed-off version.
Latest Approved Version	2.00	The highest whole number is the latest signed-off version.
Working Copy	2.06	Use a whole number and a decimal to inform the reader that version 2 is the latest signed-off version and that there have been 6 subsequent drafts. If version 2.06 were to be signed off, it would become version 3.0.