top of page

Change control process

Updated: Feb 7

Changes or variations within a project are inevitable, but a high level control is required for when they do occur. At the start of every project the Project Manager should lay out the change control procedure, this will sufficiently lay out the process of recording and managing change controls.

To ensure that changes or a variations are kept to a minimum, a thorough project brief should be undertaken at the start of the project to ensure the whole project has been captured. This is covered in this post.

Variations to the project will impact on the

  • Cost of the project whether that be from adding extra work or omitting work.

  • And possibly time of the project from adding or taking away time on the programme.

Post contract, these are dealt with accordingly under the various contracts (JCT, NEC etc)

Establishing robust change control procedures at the start of the project can be as follows:

  • Establish the change control strategy

  • Document the process as a project-specific procedure

  • Establish a change control log

  • Monitor and log changes

  • Agree with the client as to whether the changes logged are acceptable or should be rejected

  • Produce a cost reconciliation statement, summarising where the changes are included

  • Report overall costs with agreed changes

Documenting the process as a project-specific procedure

On agreement of the above process with the relevant parties, a formal project procedure can be written. This should, as a minimum:

  • Provide an overview of the process

  • State the key principles adopted

  • Define who is accountable and responsible

  • Prescribe who will approve changes

  • Define the financial authority limits within the organisation

  • Define the process in detail and provide worked examples

  • List the forms and logs to be used

  • Define the change control reports

  • Provide guidance on the system tool to manage change.

Defining the change control process

Software solutions such as ESTA and others are most appropriate method for controlling change. This would be the most efficient way to undertake the process as there is a fully auditable platform where communication is in one centralised view with other elements within the project.

In order to monitor change, a budget will need to be established by the client, along with the baseline schedule. The project team, by reviewing the brief, will have defined the scope and specification, and the cost and planning teams can use this to create the baseline information. Any changes can then be reviewed against this baseline. Potential change can be highlighted from a number of sources, such as:

  • Revised drawings

  • Contract Administrators/PM instruction

  • Architect's instructions

  • Specification changes

  • Request for instructions (RFI)

  • Client Variations

  • Legislation changes

  • Risk workshops.

Project members should be encouraged to flag up any potential change as soon as possible to give sufficient time to implement the procedure. To do so, a formal change request should be raised. The change request template should include, as a minimum, the following sections:

  • Reference number

  • Date raise

  • Description of the change

  • Time and cost implications

  • Justification of the change

  • An approval section

  • A tag of the type of change

  • A distribution section.

Regular meetings are required to review any changes. A decision can be made as to whether to approve each change as having:

  • a financial impact (where the scope of the project has changed and resulted in an additional cost or saving to the overall budget); or

  • no financial impact (for example, at a cost to the contractor or a change in the methodology of working practices).

On reaching a decision that a change is to be implemented, the project team will communicate this message to the project team. Adjustments will then need to be made to the schedule, cost reports and contract via an instruction. In contrast the change can be rejected.

Status of change

Approve or reject The project team will be required to approve or reject each change formally logged within the process. If a proposed change is rejected then an different proposal may have to be put forward. If in the event that the change is agreed, then there are three main routes that can be undertaken -

  1. Take the funds from the contingency

  2. Take the funds by a third party

  3. Take the funds from a different budget within the project


As with any project, there will be risk within the project even if they are low. The team are required to explore and clarify the risks at the inception stage of the project. This will allow an accurate level of contingency to be made. The contingency can be silent and expressed. Clear instruction needs to be laid out to the project team to how the contingency will be utilised if required.

Reporting change The reporting of change control should be on a regular basis. This should provide information on the following but can include more -

  • Number of changes raised in the month

  • Overall value of changes raised in the month

  • Funding sources for the change

  • Type of changes and what they relate to i.e client variation

  • Cumulative changes raised

  • Cumulative value of changes

  • Amount of changes awaiting approval

302 views0 comments


bottom of page