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 -
Take the funds from the contingency
Take the funds by a third party
Take the funds from a different budget within the project
Risk
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