Legal: A different kind of model approach

Disruption claims are becoming more challenging as projects become ever larger and more complex (particularly internationally). These large projects usually involve multiple contract packages or, where a single main contractor is appointed, extensive subcontracting. The potential for delay and disruption tends to increase as complexity increases. It is not uncommon for there to be thousands of individual delaying and disrupting events that can impact – directly and indirectly – on many different design disciplines and trades across the project.

However, identifying and proving the full extent of the disruptive impact of such events also becomes more difficult as the complexity of a project increases. This may be further complicated by the fact that disruptive events can interact with each other so that the cumulative impact of a group of events is greater than the sum of its parts. As a result, parties are increasingly looking for ways to analyse time and cost overruns in order to bring claims that assess the aggregated impact of accumulated (and often small) disruptive events.

One such approach is system dynamics modelling. This involves building a computer model of a project using mathematical equations to assess the ripple effect of disruptive events through different parts of the project. The equations reflect assumptions about relationships and interactions that can influence labour productivity. 

Building the model

System dynamics modelling is based on research – including some in respect of construction projects – by business schools into the feedback mechanisms created by the interaction between different parts of a project.

It is important to make sure that the structure of the system dynamics model reflects the project accurately. Model structure includes the work stages of the project, and assumptions about what is needed to complete work in each stage, and what predecessors are needed from upstream work stages in order to enable downstream stages to progress. Failing to pay attention to this can result in a model that reflects a party’s case theory but does not accurately reflect the project as a whole. 

System dynamics models also rely upon input data to generate the parameters in the as-built model. For example, the input data will include the alleged direct impact of delay and disruption events that have been explicitly included in the model.

A system dynamics model aims to be a reliable approximation of the as-built project. Once the as-built model has been constructed, the modeller uses a range of confidence-building tests to attempt to validate it. For example, a key test is whether the cumulative labour hours simulated over time matches the as-built record of labour hours. The theory behind the testing is that, if the model can produce results that match a significant number of as-built data points over time, that should give parties confidence that the model must accurately reflect what really happened on the project. If the testing identifies areas where the model does not produce accurate results, the model is adjusted and/or recalibrated until its simulated outputs are considered sufficiently similar to the as-built data.

Testing assumptions

Once the testing and recalibration process is complete, various “but-for” scenarios can be explored, by changing parameters in the model to simulate the absence of claim events. Each scenario will produce different results, such as different amounts of total labour hours, or different amounts of delay.

Whether a particular system dynamics model is considered useful by a court or tribunal will depend on the quality and relevance of the particular model. This requires an assessment of the structure and assumptions (ie the mathematical equations) of the model, the quality of the input data included in the model (“rubbish-in-rubbish-out”), the sufficiency and accuracy of the as-built data against which the model is tested, the degree of consistency between the model outputs and the as-built data, the reasonableness of the adjustments made to parameters in the but-for simulations and the results of the but-for simulations. Given their complexity, a party intending to use a system dynamics model will need to ensure that all of these aspects of the model are fully auditable by the opposing party and the tribunal or court, and are supported by contemporaneous project records and/or witness evidence.

A system dynamics model will typically produce an assessment of the delay to broad work stages (as well as increased man-hours) caused by claim events. It is unlikely to be sufficiently detailed to support an extension of time claim. Accordingly, a party proposing to use system dynamics may also need to undertake a conventional critical path analysis. In this event, it will be important that these two forms of analysis do not contradict or undermine each other.

The challenges involved in bringing a claim using system dynamics may explain why there are few if any reported cases in which system dynamics models have been tested by the courts, though we know of two arbitrations (and were involved in one) in which they have been evaluated by tribunals as evidence of disruption. To date the more common use of system dynamics models in the context of construction claims has been as a tool to facilitate settlement discussions.