Change Management
Abstract
The effects that changes to the specification, scope, or timing can have on a project are highlighted in this chapter. The method of document control and a sample change control form, which clearly shows the items to be recorded, are included. The chapter ends with a section on issue management.
Keywords
Change management; document control; issue management; change register; change record (register)
Chapter Outline
There are very few projects that do not change in some way during their life cycle. Equally there are very few changes that do not affect in some way either (or all) the time, cost, or quality aspects of the project. For this reason it is important that all changes are recorded, evaluated, and managed to ensure that the effects are appreciated by the originator of the change, and the party carrying out the change is suitably reimbursed where the change is a genuine extra to the original specification or brief.
In cases where a formal contract exists between the client and the contractor, an equally formal procedure of dealing with changes (or variations) is essential to ensure that:
1. No unnecessary changes are introduced;
2. The changes are only issued by an authorized person;
3. The changes are evaluated in terms of cost, time, and performance;
4. The originator is made aware of these implications before the change is put into operation (In practice this may not always be possible if the extra work has to be carried out urgently for safety or security reasons. In such a case the evaluation and report of the effect must be produced as soon as possible.); and
5. The contractor is compensated for the extra costs and given extra time to complete the contract.
Unfortunately clients do not always appreciate what effect even a minor change can have on a contract. For example, a client might think that eliminating an item of equipment such as a small pump a few weeks into the contract would reduce the cost. He or she might well find, however, that the changes in the design documentation, data sheets, drawings, bid requests, etc., will actually cost more than the capital value of the pump, so that the overall cost of the project will increase! The watchwords must therefore be: is the change really necessary?
In practice as soon as a change or variation has been requested either verbally or by a change order, it must be confirmed back to the originator with a statement to the effect that the cost and time implications will be advised as soon as possible.
A change of contract scope notice must then be issued to all departments who may be affected to enable them to assess the cost, time, and quality implications of the change.
A copy of such a document is shown in Figure 17.1, which should contain the following information:
When all the affected departments have inserted their cost and time estimates, the form is sent to the originator for permission to proceed or for advice of the implications if the work has had to be started before the form could be completed. The method of handling variations will probably have been set out in the contract documentation but it is important to follow the agreed procedures, especially if there are time limitations for submitting the claims at a later stage.
As soon as a change has been agreed, the cost and time variations must be added to the budget and programme respectively to give the revised target values against which costs and progress will be monitored. However, while all variations have to be recorded and processed in the same way, the project budget can only be changed (increased or decreased) when the variation has been requested by the client. When the change was generated internally, for example, by one of the design departments due to a discovered error, omission, or necessary improvement, it is not possible to increase the budget (and hence the price) unless the client has agreed to this. The extra cost must clearly still be recorded and monitored but will only appear as an increase (or decrease) in the actual cost column of the cost report. The result will be a reduction or increase of the profit, depending on whether the change required more or fewer resources.
The accurate and timely recording and managing of changes could make the difference between a project making a profit or losing money.
Change management must not be confused with management of change, which is the art of changing the culture or systems of an organization and managing the human reactions. Such a change can have far-reaching repercussions on the lives and attitudes of all the members of the organization, from the board level to the operatives on the shop floor. The way such changes are handled and the psychological approaches used to minimize stress and resistance are outside the scope of this book.
Document Control
Invariably a change to even the smallest part of a project requires the amendment of one or more documents. These may be programmes, specifications, drawings, instructions, and, of course, financial records. The amendment of each document is in itself a change, and it is vital that the latest version of the document is issued to all the original recipients. In order to ensure that this takes place, a document control, or version control procedure, must be part of the project management plan.
In practice a document control procedure may be either a single page of A4 or several pages of a spreadsheet as part of the computerized project management system. The format should, however, feature the following columns:
• Issue code (general or restricted)
• Name of originator (or department) of revision
The sheet should also include a list of recipients.
A separate sheet records the date the revised document is sent to each recipient and the date of acknowledgement of receipt.
Where changes have been made to one or more pages of a multi-page document, such as a project management plan, it is only necessary to issue the revised pages under a page revision number. This requires a discrete version control sheet for this document with each clause listed and its revision and date of issue recorded.
Issue Management
An issue is a threat that could affect the objectives or operations of a project. Unlike a risk, which is an uncertain event, an issue is a reality that may have already occurred or is about to occur.
The difference between an issue and a problem is that an issue is a change or potential change of external circumstances outside the control of the project manager. A problem, on the other hand, is a day-to-day adverse event the project manager has to deal with as a matter of routine. An issue therefore has to be brought to the attention of a higher authority such as the project board, steering group, or programme manager, since it may well require additional resources, either human, financial, or physical (material), which require sanctioning by senior management.
As with other types of changes, a register of issues, often called an issue log, must be set up and kept up to date. This not only records the type, source, and date of the issue to be addressed, but also shows to whom it was circulated, the effect in terms of cost, time, and performance it has on the project, and how it was resolved. If the issue is large or complex, it may, as with particular risks, be necessary to appoint an issue owner (or resolution owner) who will be responsible for implementing the agreed actions to resolve the matter.
The way an issue is resolved depends clearly on the size and complexity. Again, as with change requests, other departments that may be affected have to be advised and consulted, and in serious situations, special meetings may have to be convened to discuss the matter in-depth and sufficient detail to enable proposals for a realistic solution to be tabled. Care must be taken not to escalate inevitable problems that arise during the course of a project to the status of an issue, as this would take up valuable management time of the members of a steering group or senior management. As is so often the case with project management, judgement and experience are the key attributes for handling the threats and vicissitudes of a project.