1. Change control and variations
Change control process
Changes within construction projects are inevitable, but should be kept to a minimum and, when they
do occur, controlled rigorously. For this to happen, there must be an adequate strategy and sufficient
supporting documentation to record and manage the change control process.
Construction project changes - irrespective of their origin - will generally impact on the overall project
cost, either as a decrease or an increase. The early identification of necessary or proposed changes
enables a fuller evaluation in terms of cost, schedule and quality.
With any major construction project, it is important to establish the change control process at an early
point within the feasibility stage. This process is summarised below:
establish the change control strategy;
define the change control process;
document the process as a project-specific procedure;
establish a change control log;
monitor and log changes;
agree with the client or supplier 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.
Establishing the change control strategy for a project
Before any change control process can be developed, a strategic review is required to establish the
most appropriate method for controlling change. Change is not only about cost - schedule and quality
changes need to be considered too. When the scope of a project changes, or the method for building,
then all three areas need consideration. It is the cost manager or quantity surveyor who should
concentrate on the commercial implications of any change, but he or she should consult closely with
the planner, project manager and designer, so that the full impact of the change can be assessed.
Within the strategic review, the following should be considered:
the contract terms with the client and suppliers;
the type of project;
the size of the project;
the complexity of the project;
the tools available (software solutions);
the length of the project;
whether there is multi-supplier access to the process or whether this is controlled by one
supplier;
the availability of resources for the design and implementation of the process.
Defining the change control process
Many clients, consultants and suppliers have developed their own 'in house' change systems. Many
software solutions also exist to define the most appropriate method for controlling change.
With the inception of a new project, the initial team will need to investigate all the possibilities within
the market, or will have to design a process that fits the specific work.
In order to monitor change, a baseline budget will need to be created, along with the baseline
schedule. The project team, by reviewing the brief, will have defined the scope and specification, and

2. the cost and planning teams can use this to create the baseline information. Any changes can then be
reviewed against this baseline. As the project moves from inception to feasibility, through to design
and into production, the team should review any changes to the baseline weekly - or at least monthly.
Potential change can be highlighted from a number of sources, such as:
drawing revisions;
the engineer's instructions;
the architect's instructions;
specification changes;
request for instructions (site);
client changes;
legislative changes; and
opportunity and risk workshops.
All those involved in the project should have the ability to flag up a potential change, in order to allow
the project team to assess the likely outcome. To do so, a formal change request should be raised.
The change request template should include, as a minimum, the following sections:
the change request number;
the date raised;
a description of the change;
the cost and time implications;
justification of the change;
an approval or authorisation section;
a note of the type of change; and
a distribution section.
Regular meetings should be held to review any changes raised in that week or month. 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).
Alternatively, the change may be rejected.
On reaching a decision that a change is to be implemented, the project team will communicate this
message to the project and relevant suppliers. Adjustments will then need to be made to the schedule
and cost reports.
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; and
provide guidance on the system tool to manage change.

3. Establishing a change control log
The change control log should, as a minimum, consist of the items indicated in the table below.
Change control log:
[Project name]
CO Date Description of Cost Cost Latest date for
Action Comments
No. raised change estimate status action
Total
This log should be maintained so that an updated copy can be produced at the regular change control
meetings and a total liability for change assessed.
The 'cost status' shown in the table above will indicate whether the change has been approved or
rejected.
The approved costs will be added to the baseline budget and a current control budget will be
produced, indicating the total liability to the client of the changes raised to date.
Agreeing 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 change is rejected, there may be a requirement for the team to review an alternative proposal,
rework the design or change the method of working.
If a change is approved, then the funding of the change will need to be considered. This usually
follows three main routes:
fund the change from contingency (see Risk and opportunity below);
fund the change by budget transfers from within the project; or
fund the change from a third party.
Risk and opportunity
Within any project, the team will be required to review the initial risks and opportunities during the
early stages of development. Once these have been identified and approved by the client, an
assessment of the contingency levels can be made. On agreement of the contingency amount for the
project, this can be included as a fund for potential changes from within the cost report.
There needs to be a clear understanding within the project team as to how the contingency fund will
be affected by any changes raised. A mechanism needs to be defined that allows funds to be
allocated for scope change or even growth (inflation), as the project proceeds.
Cost reconciliation statement

4. The cost reconciliation statement should be sufficiently detailed to explain all significant movements of
money during the course of the contract, including the funding source for changes. The software
solution chosen to manage change will influence the way the budgets are maintained. All records
should be saved electronically, in order to establish an audit trail for change.
Reporting of change
The reporting of change will most likely be on a weekly and monthly basis. The procedure should
describe the change report format required. It is recommended that the report provides information on
the following:
the number of changes raised in the month;
the value of changes raised in the month;
the funding sources for the change;
the type of change (scope, legislation, and so on);
cumulative changes raised;
the cumulative value of changes;
the amount of changes awaiting approval; and
the time taken to approve a change.
Variations
Upon agreement to a budget change to the baseline, the project team will need to consider how to
communicate or directly instruct the suppliers for the work identified.
On most contracts, a written instruction is presented to the supplier. This has the effect of notifying the
supplier that the work is formally required, providing either an agreed cost and timescale for the work
or an estimate of the budget and time, which may need to be agreed at a later date, subject to the
type of contract.
This variation instruction can have many titles, for example:
site instruction (SI);
project manager's instruction (PMI);
variation order (VO).
Many clients, consultants and contractors will have their own particular version of this instruction,
which may have linkages to their own financial systems.
As a minimum, the standard form should include:
the project title;
the supplier and/or work package title;
the variation number;
information on or details of the instruction;
any attachments supplied with the form;
justification for the issue of variation;
the issuing person, with the date of issue;
an estimate of cost or agreed price (including an estimate of time);
an approval section;
a note on the distribution of the form (electronic or paper).
Of course, within any project, there may be a need for the project manager to issue a variation without
any adjustment to the budget. There are many instances in which this may occur. For example, a
supplier may be formally requested to carry out some work if another supplier has failed to deliver

5. against his or her contract. In this case, it would be expected that the additional costs incurred would
be recovered from the contractor who failed to deliver.
Conclusion
Change control and variation management covers a wide area and affects many people across a
project during its life-cycle. It can be a complicated area and, if not controlled properly, can lead to a
lack of understanding as to the final outcome of a project.