Chapter 16: Change Control in Construction Projects
2. Reducing the need for change
4. Change Control Process
5. Governance and Approvals
6. Document Management
Annex A Suggested change request form
Annex B Suggested change control register
1.1 In an ideal world, projects are procured with all the necessary (design and technical) information in place according to the method of procurement. The client gives the main contractor the drawings and/or specifications necessary for them to complete construction and hand over an asset fit for purpose. Sometimes, though, it is necessary to make changes to the plan baselined at the time the contract was tendered. This may be required for a number of reasons including, for example: a change to the business case; a change in market conditions which means that an assumption or decision made is no longer valid; or because of changes to the construction conditions, for example, unexpected ground conditions.
1.2 Change is a realised risk and action must be taken to assess, minimise and manage its impact or, better still, prevent it happening. Prevention is best enabled by sound planning including for example, during risk analysis and management. However, where change is unavoidable it must be actively and deliberately controlled and managed rather than simply being allowed to evolve and run its own course. A well set out and rehearsed system must be in place to mitigate the risk posed by it and to manage it. A change to the design may impact on the ability of the asset to deliver the planned benefits. Therefore, change must be considered in the context of the business case, project brief and the specification.
1.3 Whilst the focus of this guidance is on projects; the process is scalable up to programmes and portfolios and down to parts of projects, for example tasks or phases, if necessary.
Reducing the need for change
2.1 Whilst acknowledging that change is, sometimes, inevitable and necessary it should be minimised and managed. Good project management is at the heart of this and will include:
- Effective and timely project initiation and management including forward planning and future proofing
- Thorough site investigation
- Comprehensive project briefing fully involving and reflecting the needs and commitment of all stakeholders and end users of the asset
- Risk management
- Design development, co-ordination and integration (eg through use of BIM)
- Appropriate procurement strategy and processes.
- Clients/organisations should allow appropriate time for these actions to be programmed and delivered
- Where the procurement route features early contractor involvement, close liaison and collaboration between the authority and the contractor.
2.2 It is important to understand interdependencies with other projects and operations. This will help ensure that relationships are managed and events, whether they occur or impact inside or outside the project, are understood, communicated and managed appropriately. This will include ensuring that there is a mechanism in place to manage the impact on the project of events happening outside it. Similarly, changes to the project should be assessed for impact outside it. Where projects are part of wider programmes, changes to the project should be assessed to consider whether it would also have an effect on the programme. Risk management should consider, therefore, where projects may be impacted by external factors and how those might result in changes to the project being required.
3.1 Any contract which is awarded by a public body is subject to the appropriate legislation set out in Chapter 1 of the Construction Procurement Handbook. If the contract value is above the relevant thresholds then the Public Contract (Scotland) Regulations 2015 apply. Regulation 72 addresses modifications to contracts. Changes will normally constitute a modification to a contract and it should be noted that changes to the contract which are defined as 'substantial' are not possible without a new tender exercise.
Change Control Process
4.1 As noted above, change may be inevitable or necessary but regardless of how it occurs it must be anticipated and managed. A change process aims to get a project from one agreed position to a new one. Change control aims to ensure that this happens with minimum disruption and as efficiently as possible. It ensures that:
- The consequences of the change are fully understood (eg cost, programme impact, specification and stakeholders' needs);
- All those who need to know are informed and consulted;
- All relevant documentation is amended accordingly;
- The process is recorded;
- The change is authorised (or rejected); and
- The change is implemented.
4.2 It must be clear that, as the project progresses, the ability to make changes to it reduces in inverse proportion to the cost of making any changes. See the diagram below.
4.3 Baseline Design Good project management requires that there is a sound understanding of where the design is at any given point in time, this will be anchored to the cost plan and the project programme. Each of these documents must share the same fixed points (which may be a point in time and or a stage in the project, for example the RIBA Plan of Works). Changes must be reflected across all relevant project documentation to ensure consistency and ease of comparison.
4.4 The baseline must be owned by the Project Manager (PM). Changes to it must be made through a change control process, this is part of good document control and management. It is essential, for example, that an interrogation of the cost plan can relate directly to the same version of the design and programme and that everyone is clear which version is the extant version and that everyone is talking about the same thing. A cost plan which is 'as at' a different date or point from the design and programme will immediately raise suspicions around its accuracy and significant work will be required to re-calibrate them to bring them into alignment.
4.5 Consideration of changes to the baseline design must include all consequentials of the change. The original design will have been based on calculations, assumptions and standards. It is, as part of the change process, essential that these are reviewed to ensure that they remain accurate and relevant. For example, does the change compromise air tightness calculations and design decisions taken as a result of them?
4.6 Any instruction constituting a change or variation to the client's requirements, set out in the contract, must be subject to the formal change control approval process. The contract will set out who the Contract Administrator is; although this is normally the PM (the specific term for the person who can issue instructions to the contractor will be set out in the contract). The Contract Administrator is the only person authorised to issue instructions (also known as Contract Administrator's Instructions, Architect's Instructions or Engineers Ordered Variation) that identify variations in accordance with the construction contract. This is to ensure that there is strict control on how the contractor is managed and avoids confusion potentially leading to difficulties in contract management and disputes over performance and delivery. Note that standard forms of contract have specific clauses relating to how contractors are notified of change, how they manage it and pricing of additional costs associated with it. This does not change the requirement for a sound process for managing change within the construction project.
4.7 Responsibility The Change Control process is usually managed by the PM, whilst decision-making will be according to the delegated authority levels set out in the project execution plan. The Project Manager is responsible for co-ordinating and managing all change documentation and activity including maintaining the Change Control Register. Authority levels must be clear and set so that good governance is assured and the client is fully involved. They allow decisions to be made in good time and at the appropriate level. Delays to decision making, particularly during the construction phase, can have a disproportionate impact on time, cost and quality and consequently can impact on the prospect of project success.
4.8 Stages A change should follow a set process and this should include the following steps:
A change request can originate from any person or organisation involved in the project, and sometimes from those outside it. Wherever it originates, it must enter the project by a Change Request Form (see Annex A for a sample Change Request Form) via a specific entry point, this will be specified in the project execution plan and is usually the PM. The Change Request form is the means by which the client, through the Project Manager, is notified that a change to the deliverables is required and by which the PM records and manages the change.
- The request for change is logged in the Change Register noting: the date received, the originator's name and organisation, a description of the change requested and any dependencies including time (a sample Change Register is at Annex B)
- List the type of change, eg contractor, client, design team or site conditions
- Change Requests must never go direct to the contractor without first going through the change control process
- The Change Request Form should contain as much information as possible to allow it to be properly considered and costed. However, this should be balanced against delay and the knowledge that a full review will be conducted by the design team and other consultants. This should include:
- The name and organisation of the originator
- Outline of the change requested
- Reason why the change is necessary
- Any dependencies or other affected works
- Time criticality
- Impact of the changes on costs, specification and health & safety. The form should also be sub-divided into sections for the various stages of the process with sign-off boxes to indicate that it has formally cleared each stage.
A review is conducted to understand the viability of the change to allow the client to make a decision. The following may be involved in the process:
- PM An initial review to confirm that the proposed change is within the scope of the project, has not already been actioned, is generally desirable and would deliver value for money. The PM should involve the following members of the team:
- Design team considers the technical aspects of the change request and develops it, in outline, into a viable scheme. Legislative and other statutory requirements should be considered at this stage. This can then be passed via the PM to the cost consultant
- Cost consultant to work out an indicative cost for the implementation of the change.
- Contractor. At some point prior to the final decision the contractor should be invited to review the change. This should be after as much of the information has been collated and dependant on the type of contract once the design team have worked up an outline design. A design and build contract will not require a client side design team design as this will be worked up by the contractor. Clients may wish to give preliminary approval in outline prior to the change request being passed to the contractor for their review. If this is the case then the change will come back to the PM for finalising and then will progress to the Assess and/or Decide stage. The contractor should be requested to give a price for the change including any additional prelims including those resulting from impact on programme.
Once the review is complete, the PM should collate all the information and summarise the outcome of the review on the Change Request Form. Any supporting documents as appropriate and an indication of whether the change is achievable from a construction point of view should also be included. This collated Change Request is then passed to the client for their consideration. The client should consider the change in the context of:
- The overall project aims and the business case and determine whether it is desirable or not. If the business case does not support the nature of the change, but it is determined that the change is desirable then a review of the business case may be required. Such a change will require to undergo amended business case approval. In pure project management terms a significant change to the business case may technically require the project to be halted and re-initiated although in practice, this is less likely to be achievable in a construction project particularly if contracts have been awarded or the construction phase has commenced. A decision to halt a construction project will carry significant cost and reputational risk as well as risk to the service ultimately planned to be delivered by the built asset.
- The impact of the change on stakeholders and other agencies and this may require direct engagement with them to get their views on the change
- The Risk management plan and the impact on deliverability of the project. This should include consideration of:
- Impacts on the construction programme and of possible delay and disruption claims for additional costs from the contractor.
- How long might it take to complete final design information for the change, including any client or statutory approvals? Allow time for possible re-submissions.
- Will other aspects of the works require design amendments to suit coordination?
- Any requirements for amendments to building warrants or planning consents?
- Will any element of the construction works require to be postponed to accommodate the change? If so, what will be the likely impact?
- Are materials readily available or, if not, what is the delivery period?
- If the proposed change is likely to cause the contractor to be entitled to an extension of time, what is the likely cost?
- What is the client operational impact of a delay to the completion date?
- Note that not all changes will require to be referred to the client, delegated authority levels will be set out in the Project Execution Plan. Similarly some changes may require clearance at a higher level for example at Project Board or Ministerial level. It is though worth ensuring that the delegated authority level is appropriate for the specific change being considered. For example a relatively low cost change may have a larger impact on the business case and whilst the PEP may suggest no referral to the client the business impact might.
Once the assessment is complete, a decision is required. This may be Approve, Reject, Defer or Further information required. A deferral may, for example, be because other dependent activity is pending which may have an impact. For example, future changes to legislation which may make the proposed change redundant. A deferred change will remain on the register and be brought forward at an appropriate time for further consideration. The authoriser may also want more information to inform their decision in which case the Change Request Form is annotated accordingly and returned to the PM who will restart the process at the review stage. Note that a deferral or request for further information can be made at any stage during the process as appropriate.
If the change is authorised, all documentation is updated to take account of the change and the baseline is stepped forward accordingly and version control updated. The change is then notified to all relevant parties and appropriate action taken to implement it. This will include full design development of the change by the design team, amendment to the cost plan and integration of the change into the construction programme by the contractor.
4.9 Fees Fees payable to consultants are normally set out in the contract documentation and the method of calculating them is fixed according to it. The contract will also set out rates of fees for undertaking work additional to the contract, this will include for work on changes. Therefore, changes will incur additional consultant fees. Each consultant should consider and estimate their fee for implementing the change in the event it is approved and for the work undertaken for considering the change request. Note that even a rejected change is likely to incur a fee. Most standard forms of contract have built-in provisions for the contractor to provide an estimate of the time and cost impact of a proposed change. Authorities should use that mechanism but be aware that except for simple changes, firm cost and time implications will only be available once a new design has been produced and approved. Similarly, the change will incur additional cost from the contractor as it is likely to be a variation on the original contract, this will include the cost of the work itself and any prelims required to deliver it. All costs should be estimated through the change control process and used to help determine whether the change is desirable.
4.10 It is imperative that these costs are considered against the current version of the recognised and agreed baseline to which the changes are being made and once made a new version of the baseline must be created and published. This allows a controlled and incremental approach to managing change and ensures that the changes and their impact are known and recorded.
Governance and Approvals
5.1 The procedure for approval of changes should be set out in the Project Execution Plan (PEP) or Project Implementation Document (PID). Besides describing the change control process and its management, it should also define the delegated authority levels and procedures for consideration of changes at each delegated level.
5.2 Decisions regarding changes will normally require authorisation by the Project Sponsor, although these may be escalated to the Senior Responsible Owner or the Project Board depending on the complexity, cost or impact of the change. Authority can also be delegated further down, although this further delegation of authority will normally require to be approved at Project Board level.
5.3 Approval should be conducted at the most appropriate level considering the impact and cost of decisions, whilst ensuring that the process is time effective, this is particularly important during the construction phase when quick decisions are often required. An overly bureaucratic and hierarchical approvals process will be slow and delay decisions and will impact on project cost and programme. Consideration should also be given to the effect of aggregation on delegated authority. For example, a team member who has authority to approve changes up to £10,000 may make ten changes which total £100,000 and that amount may have a significant impact on the project so checks should be put in place to ensure that delegated authority is appropriately managed.
6.1 Changes, and the process to reach a decision about them, must be recorded to a) allow effective management of them and b) provide an audit trail for accountability. Changes can come thick and fast and without an efficient system for recording and monitoring, mistakes and confusion can occur. Effective documentation ensures that everyone is clear about exactly what is being requested, supports accurate decision making and records what has been decided.
6.2 An audit trail also provides an open and transparent record for subsequent enquiries, lessons learned reviews and post project evaluation and ensures that there is a clear record of the decisions made in spending public money. The following documents should be maintained:
- Document control register
- Change Request Form
- Change Control Register
- Cash flow/Cost Plan recording impact of changes on costs
7.1 Change is an inevitable part of construction projects and whilst it should be minimised, the manner in which it is managed is critical and can have a make or break effect on project outcomes. Active and timely management of them is essential with all those with a need to know being involved at the appropriate time and with the appropriate authority to make decisions. It is the client's responsibility, as with everything relating to project delivery, to ensure that a system is in place for managing it before it is needed.
Annex A: Suggested Change Request Form
A copy of the Change Control Form is available in the supported documents section
Annex B: Suggested Change Control Register
A copy of the Change Control Register is available in the supported documents section
There is a problem
Thanks for your feedback