Chapter 17
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; Change record (register); Change register; Document-control; Issue management
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 when 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.).
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. Therefore, the watchwords must be: is the change really necessary?
In practice, as soon as a change or variation is 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 Fig. 17.1, which should contain the following information:
• Project or contract no.
• Change of scope no.
• Issue date
• Name of originator of change
• Method of transmission (letter, fax, telephone, e-mail, etc.)
• Description of change
• Date of receipt of change order or instruction
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 still be clearly 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 decide the fate of a project as making profit or losing money.
Change management must not be confused with the 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- or version-control procedure, must be a part of the project-management plan.
In practice, a document-control procedure can either be a single page of A4 or several pages of a spreadsheet as a part of the computerized project management system. The format should, however, feature the following columns:
• Document number
• Document title
• Originator of document
• Original issue date
• Issue code (general or restricted)
• Name of originator (or department) of revision
• Revision (or version) number
• Date of revision (version)
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 its 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 the 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.
Baseline
The three baselines in project management are associated with the three project management criteria, i.e. cost, time and performance. The baselines are set by the project manager at the beginning of the project and are incorporated in the project-management plan. All subsequent data gathered by the project reporting system which affect the cost or duration of the project are compared with the baseline, which can only be changed by agreed variations issued by the client. This is normally shown by a step change in the budget curve (usually straight line) of the earned value set of control curves.
There are instances where the originator of the change to the baseline is the project manager instead of the client. This occurs when the delay or cost overrun is due to an error by the project management team or the contractor. The baseline will be changed, but the cost cannot be passed on to the client. Indeed, if the change delays the completion date, the party responsible may be liable for liquidated damages or other form of compensation payment.
Where the change is originated by the client, the project manager has to issue a change of contract-scope notice as shown in Fig. 17.1.
Baseline Review
The Association for Project Management (APM) published a book titled Guide to Conducting Integrated Baseline Reviews which sets out the procedures necessary for effective baseline management.
As set out in this book, the integrated baseline review (IBR) is a formal procedure carried out at prearranged intervals to assess the status of the project and take remedial action where necessary. The process is divided into four main stages: pre-IBR, preparation, execution and post-review.
Pre-IBR
This is when the need, policy, timing, objectives and acceptance criteria of the IBR are discussed and agreed.
Preparation
This stage includes assessing the competences of and recruiting the IBR team, producing an IBR handbook and collating the required documents.
Execution
In this stage, every facet of the project such as cost, programme and performance is examined and discussed. After collating the discussions and feedback, the results are presented and issued as a final IBR report.
Post-Review
This stage deals with the preparation of an action plan in which all the risks and problems have been identified and logged. A root-cause analysis should be carried out to identify areas which can be improved and remedial actions for this should be assigned to the appropriate members of the IBR team.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.