There are a number of frequently discussed methods of investigating the impact of change on a project when considered after the event. While these methodologies can be fascinating, they do not normally represent the main focus for the project team during works. We will therefore try to concentrate on the evaluation of change whilst the project is in progress.

What the contract says
The first article in this series sets out the common forms of contract to be expected on tunnelling projects: the International Confederation of Consulting Engineers contract (FIDIC) and the third New Engineering Contract (NEC3).

These are very different in their approach to the use of the programme in evaluation and entitlement of change. The change in mind-set required to move from an Institution of Civil Engineers (ICE)/Joint Contracts Tribunal (JCT) contract to an NEC-governed project is considerable.

The other commonly encountered tunnelling contract is the bespoke contract, often as part of a private finance initiative/private public partnership project.

Usually the programme/variation clauses in bespoke forms are based upon a common standard form, though the process of incorporation can occasionally go awry, rendering the change mechanism at best flawed and at worst inoperable. This is a particular risk where lawyers without the relevant jurisdictional dispute experience are responsible for the drafting (e.g., civil law-based lawyers drafting for disputes under common law).

It is therefore important, prior to signature, for a party to consider the operations of the change mechanism in bespoke contracts to ensure that the requirements imposed on them are fully understood and to ensure that the mechanism functions adequately.

Retrospective analysis of change
Retrospective evaluation of both the financial and programming impact of change (when change has not been agreed during the contract) is a luxury available to the parties after the works have been completed. This is the final route for resolution of disputes over the impact of a change (except, arguably, under NEC3 where retrospective options are severely restricted) and requires the parties or their experts, to establish the actual impact caused by the change.

A retrospective evaluation requires investigation of the actual position and the separation of the impact of other changes from the change under consideration. The process can be complex; hence the role of delay and quantum experts, as well as the many pages in periodicals, books and papers dedicated to arguments over the merits of different types of retrospective analysis.

The principles (i.e., the demonstration of the cause and the effect) remain simple but the value of well-maintained, contemporaneous records and realistic, accurate, regularly updated programmes cannot be over-emphasised. Consider the frequently encountered situation that once a dispute arises, the records, timesheets and invoices are not sufficiently detailed to allow allocation of the direct cost to the change, as the records were simply to provide evidence of the overall cost. Once the project runs drastically over budget, the client starts examining the costs in much more detail, as there is an anticipation that ‘surely the 50 per cent increase in cost cannot simply be the result of a few remaining unresolved changes’, but he has difficulty knowing without detailed records.

Prospective/live analysis of change
While the process of retrospectively unpicking strands of cause and effect from the final position can be complex, the parties are at least aware of the final outcome. When considering the impacts of change during a live project, analysis usually requires the retrospective analysis to be combined with a projection of future impact. These dual requirements may be defined in the contract mechanism or may simply be necessary in order to report on the status of the project to stakeholders.

Most forms of contract simplify this process by requiring an initial evaluation but allowing subsequent modification to take into account subsequent impacts of the change not originally apparent. Uniquely, NEC3 requires a party to consider the impact to date and then to project forward the future impact and, effectively, to make a new deal for completion of the works including all impacts of the change (subject to a few limitations).

The NEC provisions, while still controversial in some respects, do provide a framework of prudent steps which enable change to be properly controlled and evaluated.

In summary, the key requirements the parties should know and if possible agree on to effectively manage change are:
a) Where they started and were trying to get
b) Where they were just prior to the change occurring
c) When change occurs the parties should:
i) Identify and notify the change swiftly
ii) Adequately define the change as quickly as practicable
iii) Identify the impacts (time, money)

With the movement towards target cost contracts under the NEC forms, it is becoming difficult enough to ascertain the direct costs associated with a singular change, let alone those considered indirect. When forecasting cost associated with a change under the NEC, calculating the impact upon other trades and activities in a reasonable and sensible manner whilst in full flow is nigh on impossible. Let’s not also forget that loss of productivity can, in turn, create lengthened project duration with extended site and head office overhead costs too!

How to evaluate impact of a change upon the project
The steps to evaluate the impacts of a change upon a project are:
1) Identify the project programme and budget, which are the most accurate reflections of the agreed contract works at the time and ensure that they have been updated to incorporate the actual status of the project immediately prior to the change occurring.
2) Define the extent of the change itself. Establish an activity or mini programme to describe the change (often referred to as a Fragnet – fragment of a network).
3) Identify the activity or activities within the project programme (item 1 above) that will be interrupted (prevented from finishing), or prevented from starting, or replaced by the change.
4) Impact or apply the fragnet to the project programme. This is likely to require that activities within the project programme are:
a) Deleted – to be replaced by elements of the fragnet.
b) Split – creating two activities to cover work done prior to the change arising, and the work that will be completed after an aspect of the change fragnet has been completed.
c) Unlinked from a predecessor to model the act of the change delaying an activity or group of activities.
5) Examine the updated programme to look for unintended /inaccurate consequences of the change. For example activity chains that have lost their predecessor or successor activities and activities whose sequence have been altered in an unintended way.
6) Time analyse the programme (allow the software to perform its critical path analysis), then compare the impacted programme with the project programme from (1) above and repeat the examination described in (5) above to search for errors and unintended change.
7) Assisted by the above process, prepare a budget for the change as defined by the contract. Typically this will include an estimation of the direct (labour, plant and material) and indirect (fees, head-office overheads, profit, etc) costs identified as resulting from the change as well as any impact upon other elements and activities. The submitted budget for the change will also need to consider the impact upon output levels and resource requirements.
8) Finally, consider the impact upon the key milestones or project completion date between the project programme identified in (1) above and the dates generated from the impacted programme to establish the extent of the impact upon the project key dates.
9) Other changes that have arisen in the same time period as the change under investigation should also be incorporated into the impacted programme to establish whether other sources of impact upon the project dates have also occurred in parallel with the change under consideration.

The extent to which there will be a contractual entitlement to an extension of time or prolongation will depend upon the requirements of the contract and the responsibilities identified for the change and other impacts occurring during the period.

Once the above process is complete, the updated programme and cost submission should be adopted as the most relevant programme and budget (for update with subsequent delays and changes). This may require some modification if the process of agreement of the change requires retrospective modification of the programme presented above (e.g., alteration of the agreed extent of the fragnet programme representing the change).

None of this is exactly rocket science, however failures in the above process are at the root of many disputes.

The extent to which the above are required and the timescales needed for delivery should be defined in the construction contract. It is worth noting that where the parties follow the NEC process for handling change they will not be far from good practice under any circumstances.

Common errors and their sources
Inaccurate baseline
The process of efficiently managing a change is often doomed long before the change has arisen. Commonly this failure occurs in one of two ways (and often in both combined):
1) The original baseline programme or budget is, on investigation, fatally flawed and was never going to be achievable as defined. Therefore, it will not provide a robust basis against which to evaluate the impacts of a change.

2) While the baseline programme or budget may or may not originally have been realistic, the circumstances of the project when the change arose may have diverged from those contracted upon so significantly that the baseline will no longer provide a robust basis for evaluation of the change.

There should be a proverb that states: ‘He who cannot say where he is, can make no use of good directions.’

So, the first step required to recover from an inaccurate baseline is to establish the project status, the actual progress and cost plus any previously agreed change. As most readers who have had the misfortune of being involved with delay experts are probably aware, there are many ways to skin the retrospective analysis cat and even more ways to disagree about the results. Thus the project with either of the problems described above will, by this point, be sliding inexorably towards a dispute.

The lack of an accurate baseline against which to consider change is common because the development and maintenance of a realistic baseline is actually very difficult. It is likely to require a number of project stakeholders to take decisions that they would rather defer or avoid so as to ‘keep their options open’. It also requires a consistent level of effort throughout the duration of the entire project, in circumstances that grow in complexity throughout.

Consider the baseline planning for a road tunnel. When planning the works the planning engineers will have an accurate set of information for size and length of tunnel and rate of excavation. Assuming that the ground conditions are broadly as identified, then this element should be straightforward to plan.

There are, of course, often problems that impact upon the ability of the tunnellers to keep to the programme. These may represent contractor risks or require changes to the contract, however, the initial planning should be straightforward.

Delays to tunnelling projects commonly arise in preparing for tunnelling operations or in the installation of systems within the tunnel as and after it is constructed. Consequently these aspects tend to be harder to plan initially and can therefore prevent provision of a useful baseline programme.

The simple fact is that during the preparation of the project baseline programme, the planner will often be unable to accurately estimate the work content for tunnelling enabling work and will not have enough information to accurately or sufficiently plan the systems installation part of the programme. The enabling works aspect usually requires a commercial risk approach to planning such that acceptable level of contingency are provided.

There are some common reasons for failures in baseling planning for tunnel systems:
1) The planner ran out of time before he had finished preparing the baseline so he stuck a bar in at the end labeled ‘signalling, comms and power system installation and commissioning’.
2) There wasn’t anyone available to give the planner programme information so he stuck in a bar entitled ‘signalling, comms, etc’.
3) The systems designers were available to the planner but they weren’t due to finish the design of the systems for another six months, so he had to put in a bar labelled ‘signalling, comms, etc’.

While these examples are exaggerated, the point is that it is difficult enough to prepare an accurate and realistic programme and budget for works that have been clearly defined. To programme and cost works that have not been defined is, at best, crystal ball gazing.

For tunnelling projects, the other crystal ball element is often in relation to the work required to allow tunnelling to commence. The initial excavation to create access shafts and TBM launch pits often identifies the one utility main not previously identified in the surveys, in a manner not unlike military “reconnaissance by fire”. Both processes being similarly noisy, messy and expensive.

Out-of-date baseline
A strength of the NEC contract is its insistence that when a change arises it should be identified, agreed and incorporated into the contract as quickly as possible. In order to deal with this issue, the NEC contract is draconian with regard to the timescales for dealing with compensation events.

That being said, often the reality under NEC or other forms is that neither party has managed to comply with its roles or time limits. Hence, over an often surprisingly short period, the contract mechanisms will have de facto ceased to be meaningful. The element that often manifests this problem is the foundations required for evaluation of change, the updated baseline.

This is the second common failure identified above – the failure to maintain an accurate programme for the works, updated to incorporate actual progress (or the lack thereof) and agreed changes to the scope of the works remaining.

While NEC3 is referred to above as an example, the issue of failure to adequately maintain the project baseline applies equally to the consideration of change under any contract where the incorporation of changes to the works is allowable.

We return to the point that, in order to be able to evaluate a change (actual or potential) the actual status of the project at the time the change is identified must be known. Similarly, the planned route from that point to completion should also be known.

Some forms of contract are not specific that an agreed and up to date project assessment is required in order to establish the likely impact of a change, it is generally accepted (ref 1) that in order to prove the impact of a change, then the impact or likely impact on the previously projected end date for works needs to be demonstrated.

The NEC contract requires that the identified change (via the compensation event mechanism) is evaluated against the current status of the project in order to establish the impact or otherwise of the change upon the predicted completion targets.

Other contracts require a similar projection but will allow a revisit of this estimate after the works are complete in order that the actual impact of the change is fully addressed.

Evaluating the impact of the change
Evaluation of change should be as swift as practicable. There are a number of reasons for this:
1) To allow the project to accommodate the change as quickly as possible.
2) To ensure debate between parties regarding the impact of change is possible while the circumstances are fresh.
3) To limit the impacts of the change itself and avoid ‘disallowed’ costs.

In order to achieve this result the parties will need to identify, define and notify the circumstances of a change clearly. They will then need to establish the details of the change and seek to correctly identify the linkages between the change and the previous programme and to budget for the works. With this information the project team should be able to link the change to the previously accepted programme and budget so as to establish the impacts of the change upon the project programme and anticipated final cost.

In parallel with this process of evaluation, responsibility for the change and its implementation must also be allocated and agreed. If this process has been followed then the change should now have been defined and incorporated within the revised and agreed project programme. The cost and time impacts should also have been agreed and the actions necessary to implement the new project programme should have been allocated.

The change will therefore have been incorporated into the contract works and its impacts allocated contractually. Where the NEC contract is in use this should, in most circumstances, be the conclusion of the issue save any pain/gain share calculations. For non-NEC contracts the actual impact of the change may need to be revisited to ensure that the delay caused by the change did not exceed the originally agreed amount.

Finally, the change should be continually monitored and recorded in detail throughout the duration of the project for both internal and external purposes, as this may well affect targets and incentive mechanisms. The measured mile and similar other demonstrations of loss have problems finding reference points unless timesheets record sufficient detail to distinguish them from the baseline and ‘disallowed’ costs can be difficult to identify. More commonly we are provided with records of simple monthly payments into ‘salaries’ or such like on the contractor’s cost ledger, rather than accurately detailed records/diaries.

The unresolved change
Any link in the chain that is missed is likely to obstruct the clear evaluation of a change and contribute to disagreement between the parties on the impact of change. Inevitably these difficulties will increase as the lack of agreement causes the impact of the disputed change to magnify while responsibility for the change is unallocated.

Where responsibility for change is unallocated then the project will, to an extent, be lacking agreed project targets. In such circumstances the impacts of a change will remain unrestrained. If the parties have no specific agreed responsibilities to incorporate the change into the project then it is very likely that the time and cost impacts will continue to grow.

Consider a simple example:
A TBM launch pit is delayed by issues including delays to realignment of utilities.

Where responsibility can be identified or allocated, the delivery of the TBM can be re-scheduled. Alternatives for acceleration can be explored and unnecessary acceleration of, say, a client change to a signalling design can be avoided. Further, a contractor’s concrete defect in a reception chamber wall can be resolved without consequential acceleration by the contractor.

Where responsibility cannot be identified the parties will face:
1) a dispute over the delay to the launch chamber,
2) an additional cost for storage of TBM pending completion of launch chamber (added to disputed costs for 1 above),
3) cost to accelerate works associated with the signalling design change unnecessarily (cost to the Client),
4) cost to mitigate the contractor’s receiving chamber concrete defect can be minimised.

Alongside these simple consequences of an unallocated change flow themore subtle consequences that arise froma project limping forward with an extant dispute and without an agreed programme to completion.

Conclusions
The above article should therefore have demonstrated that the process of evaluating the time and cost impacts of a change are comparatively straightforward to describe. However, it should also be clear that the process often fails to yield agreement to the results because there is no suitable baseline or reliable progress record available. This is equally applicable to both time and cost.

This is why all parties to a project are advised to ensure that for all aspects of the project they:
a) ensure that an adequate baseline is established,
b) maintain the baseline incorporating changes and actual costs/progress regularly and accurately,
c) identify and notify the change swiftly,
d) define and agree the change swiftly,
e) identify and agree the impact swiftly.

These are indeed simple steps. However the requirement to start with, and to maintain a realistic and accurate project programme and budget is rarely achieved. Successful control of change is heavily dependent on the parties’ approach to the maintenance of the project programme and cost forecasts. Too often these fail long before the change at issue is ever contemplated.

Inevitably, when the basis for evaluation is lost, successful and timely management and incorporation of change will also be lost.

As to prevention of these failures:
1) Support the team preparing the baseline to ensure that the best information possible is provided to them.
2) Ensure that, where the planning team has been required to make a guess, that the parameters of those guesses have been understood fully and commercially addressed.
3) Ensure that the baseline planning team have a spread of skills to plan the entire project not just the Civils or the Systems.

In terms of cost, undertaking good reporting procedures will help assess the impact once a change is identified. This should include:
1) the identification of the actual cost to date referenced and recorded against actual progress to date when the change occurs,
2) the measurement and identification of these costs against the baseline programme,
3) establishing a separate activity/cost code within cost ledgers/accounting procedures to capture all costs associated with the change,
4) recording cost and progress impact using an Earned Value Management (EVM) technique.

In order to ensure that the programme remains sufficiently current both the contractor and the engineer/project manager must perform. Therefore a process of agreement of progress records is significant, though the contractor should also:
1) allow adequate planning resource for the works,
2) make the reporting and maintenance of programme records a management priority,
3) avoid the temptation to modify the programme as a contractual claims tool (this approach is usually counterproductive as the programme is more likely to be challenged). Simple really…