Skip to main content.

Schedule uncertainty in linear developments

Summary

Linear developments such as pipe or cable laying, road or rail building, or tunnelling, present challenges not found in other forms of construction. Analysis of the risk to their schedules may require a different approach from that used for the analysis of general construction projects. In some situations, existing schedule modelling tools lack the means to represent the particular features of linear developments. However, these can be addressed, with appropriate expertise, using two modelling tools and exchanging information between them.

Background

Uncertainty in general construction projects

General construction can usually be planned to address several work fronts at once, with crews from separate disciplines following one another through each area. This allows the simultaneous application of multiple crews or units of plant to the overall job. In this context, uncertainty in activity durations is often well characterised in terms of uncertainty in the productivity of the construction crews, the productivity of plant and the total quantity of work to be completed. It may be useful to deal with productivity or quantity uncertainty for different disciplines and different work areas separately but, apart from that, substantial parts of the work can usually be treated as homogeneous elements in a quantitative risk model.

For work of this kind, it is common for a quantitative model to contain anywhere between fifteen and fifty uncertain factors. Using uncertainty factors breaks down the task of assessing and representing project uncertainty into a moderate number of separate judgements. The number is neither so small that bias or an error in one assessment will undermine the integrity of the whole analysis, nor so large that the analysis becomes inefficient, or complicated by the inadvertent incorporation of correlations and dependencies between elements of a model.

The use of risk factors, such as uncertainty in quantities of materials to be installed or uncertainty in productivity factors, also helps to avoid complicated correlations between elements of a model. By applying these underlying drivers to components of a model, everything they affect can be represented realistically with compounding effects, where multiple factors affect a part of a project, being included simply and transparently.

Uncertainty in linear development projects

In contrast to general construction, linear developments often have only one primary work front: a barge laying a cable or a pipe, earthmoving and paving crews developing a road from one end to the other, or tunnel boring machines and associated plant excavating an underground space from a single portal. In some situations, it may be possible to tackle a linear development from two or more points at once, such as the two ends of a tunnel, but the concentration of labour and other resources at a constrained work front remains. Instead of a large mix of work with uncertainties spread across separate locations and time periods, many sources of uncertainty are concentrated in a single area of activity. The key driver of the development schedule is usually the rate of advance at this work front.

Uncertainty in the rate of advance of a linear development is rarely thought of in terms of more than two or three contributing factors. In the case of cable laying or tunnelling, there might only be one piece of plant at each work front. Progress can be described in terms of uncertainty in the availability of the plant, perhaps expressed as hours of operation per week, and uncertainty in the rate of advance that can be achieved when the plant is available, perhaps expressed in metres per hour. These might be compounded by workforce and equipment productivity uncertainty, possibly driven by restrictions arising from existing operations or environmental conditions, such as wave height constraints on a pipe-laying barge.

It is rare to find a team expressing their uncertainty about the rate of advance of a linear development in terms of more than three or four drivers. There may be numerous sources of uncertainty underlying these few factors, but it is not usually cost-effective to analyse each of them explicitly. For example, an analysis of equipment availability could easily give rise to a very large and complicated model of component reliability and machine failure modes. It might be worthwhile for the equipment vendor but, in general, not for the project team planning to use the equipment.

In addition to the concentration of risk in just a few critical factors, linear developments often differ from general construction in the planned pace of work. A single major activity on a general construction project will probably be allocated a fixed level of resources, in the initial plan at least. The base assumption will be that work is to be completed at a more or less steady rate throughout, apart from ramping up and down at the start and end, which are usually second order effects. Work area managers and supervisors might make day-to-day adjustments to optimise the use of their resources, but the overall tempo of work will be broadly the same for as long as that task lasts.

Because access and congestion at the work front in linear developments often constrain the rate of progress, any opportunities to gain better access, bring more resources to bear or run the existing resources at a higher rate will be included in the project plan. Conversely, environmental conditions or localised access constraints might mean that work is planned to progress more slowly through some stages than others. The timing of changes in the planned rate of development might not be entirely predictable but the fact that the pace will change is a systematic effect, not just a random variation. The project team knows such a change will happen and plans for it. These planned variations in the rate of advance must be included in the associated quantitative risk model.

A straightforward example of a systematic variation is the effect on an underground tunnel development where fresh access tunnels or underground drives become available, allowing better ventilation or faster removal of spoil and a greater rate of advance. Conversely, where a tunnel is expected to encounter poor ground conditions, the planned rate of advance might be expected to fall as additional ground support is installed in every metre the tunnel is extended.

None of this is inherently difficult to model, but systematic variations in the rate of advance, combined with uncertainty about when the changes take place, requires care if a realistic model of the overall end date is to be created. Existing schedule risk modelling tools are unable to cope with this directly, but it is possible to develop a realistic model by combining a schedule risk modelling tool with a spreadsheet risk-modelling tool.

It is useful to look at three cases of increasing difficulty, developments characterised by:

  • A single planned rate of advance throughout
  • A rate of advance varying at defined physical locations along the alignment
  • A rate of advance varying at uncertain times during the development.

Modelling a single base rate of advance

Very often, for simple linear developments, the rate of advance can be treated as if it is, on average, steady throughout; laying rail track in a greenfield location with no turnouts or road intersections for example.

  • We might be uncertain about the average rate that will be achieved but we can model that and use it to model uncertainty in the duration of the development
  • There might be uncertainty about both the total length of the development, although this is often very well defined, and about the average rate of advance
  • In turn, the average rate of advance might itself be modelled in terms of plant availability and the rate of advance during available hours.

For a single stage of development at a steady average rate, a model of the total development duration need not be very complicated. The relationship at its heart might simply be as shown below, where:

  • ΔL is the variation in length
  • ΔA is the variation in plant availability
  • ΔR is the variation in rate of advance when plant is operating.

This can be implemented in most Monte Carlo simulation schedule modelling tools, using distributions to simulate the three sources of variation from the base. In most of the commonly used tools, all the information required to work out how long the task will take is available to the modelling system during each iteration of the simulation.

Modelling a base rate that varies at defined physical locations

As a tunnel passes the boundary between two geological zones or a cable passes from a continental shelf to deeper water, it might be that the planned rate of advance changes because the rate at which the plant can operate is different from one region to the other. If there are just two zones, even if the length of each one is subject to uncertainty, perhaps because of the risk of having to deviate from the shortest route to avoid obstructions, it is still a simple matter to model the uncertainty in the overall duration.

The duration of work in each zone can be modelled in the same way as the single-stage development described in the previous section. Once again, all the common modelling tools can accommodate this and simulate the duration of an entire project including the linear development activities.

Modelling a base rate that varies at uncertain times

The problem

Modelling is less straightforward when the transition between rates of advance takes place not at defined locations along the alignment but at points defined in time, usually when external events arise or developments elsewhere in the project are completed. It is not difficult to cope with the length of development in a zone being uncertain, but uncertainty about the timing of transition points proves difficult to accommodate in current schedule modelling tools.

An example

An example of a linear development with the rate of advance changing at uncertain times can be seen in one of Broadleaf’s recent assignments. We were engaged to lead the cost and schedule risk analysis of a very large underground mining project. As well as being relevant to an understanding of milestone dates, the schedule analysis had implications for the cost risk analysis through the impact of the project duration on the indirect costs. The schedule model was built in Primavera Risk Analysis (PRA) and the cost model was built in @RISK for Excel. Following common practice for this client, schedule outputs were exported from PRA to use in the cost model as drivers of duration-dependent costs.

The project involved the development of several tunnels. In each tunnel:

  • The total amount of rock to be extracted was uncertain due to uncertainties in length and the extent of overbreak
  • Development was planned to start at a relatively low rate (measured in metres per day), because progress would be restricted by constraints on access and the rate at which spoil could be removed
  • As other parts of the mine were developed concurrently and intersected with the tunnel, the rate of advance was planned to rise significantly, in major steps, because access and ventilation were improved and the rate at which spoil could be removed was increased.

This is illustrated in Figure 1, where R represents a rate, L a developed length of the tunnel and T the elapsed time.

Figure 1: Development progress

The relationships between the variables are straightforward (Table 1). The modelling challenge arises from the fact that, while T1 and T2 can be derived from other parts of the schedule, T3 depends not only on progress up to T2, which can be calculated from T1, T2, R1 and R2, with knowledge of the uncertainty affecting them, but also on the total length to be developed (L1+L2+L3) and R3, which are also uncertain.

Table 1: Model parameters

Parameter

Nature

Notes

T1

Variable

From the schedule model

R1

Variable

Estimated

L1

Calculated

L1 = R1 * T1

T2

Variable

From the schedule model

R2

Variable

Estimated

L2

Calculated

L2 = R2 * (T2 - T1)

L

Variable

Total tunnel length, estimated

L3

Calculated

L3 = L - L1 - L2

R3

Variable

Estimated

T3

Calculated

T3 = L3 / R3 + T2

L1 is not fixed: it depends on R1 and T1. Similarly, L2 depends on R2 and (T2 - T1). However, to calculate T3, the end of the tunnelling activity, it is necessary to know not only when stage 3 starts, which is T2, and R3, the rate of advance in this section, both of which are known even if they are subject to some uncertainty, but also L3.

The overall length (L1 + L2 + L3) is known, subject to some overall uncertainty, but to calculate L3 we need to know L1 and L2. Schedule modelling tools can use the end dates of predecessors, such as T2, as the start date of a successor, but the tools currently available do not make available within a simulation the information required to calculate the duration of stage 3. To calculate T3, in addition to (L1 + L2 + L3) and R3, we need the simulated values of L1 and L2 in each iteration of the model. The calculation is simple, but PRA and similar tools do not provide a way to carry it out. They cannot carry forward properties of predecessors or use them to calculate a successor’s duration.

It might be possible to implement the calculation in tools such as @RISK for Microsoft Project (Palisade) or Tamara (Vose Software) but they are not yet widely accepted in heavy engineering environments.

How we overcame the problem

We overcame this limitation by extracting from PRA the distributions for T1 and T2, dictated by activities in other parts of the project such as conveyor construction, and combining them in an @RISK model in Excel with distributions for R1, R2, R3 and the total length (Figure 2). In an Excel model it was a simple matter to simulate progress to T2, that is (L1 + L2), subtract it from the simulated total length and, using the distribution for R3, calculate T3. The distribution for T3 was then exported back into PRA. A check was made to confirm that no correlation relationships were being violated by this approach.

Figure 2: Model interactions

In this assignment, the final stage of tunnel development was a critical driver of uncertainty in the overall project schedule. The PRA model, with distributions imported from the subsidiary @RISK model, generated the durations of the final stage of each tunnel section to provide a realistic simulation of the project schedule. The model took proper account of the interactions between tunnelling rates, the timing of increases in these rates and the overall length of the underground development. By focusing on the real world situation, rather than being blinkered by the modelling mechanisms offered by a particular tool, we were able to include this effect properly in the overall project schedule simulation.

This approach maintained a clear and transparent connection between the terms in which the project team understood and described the uncertainty affecting the tunnel development on the one hand and the model on the other. The team’s expressions of the uncertainty in rates and the total length of the development were used directly without being reinterpreted by the analyst. This maintained confidence in the analysis and the results it produced.

Lessons

Specialist risk modelling tools, such as those based on project schedule networks, simplify the development of models and offer great power to the analyst. However, some projects present requirements that these tools cannot accommodate. It is important to recognise this as a modelling challenge: it is very unwise to try to reinterpret a project in terms dictated by what a particular tool can represent, thereby ‘shoehorning’ the analysis into whatever tools happen to be available.

So long as care is taken to avoid introducing distortions or breaking important linkages such as correlations, it is possible to combine modelling tools to accommodate requirements that a single tool cannot represent.

It is crucial to maintain a clear relationship between the real world phenomena being analysed, the way uncertainty about those phenomena is described by the project team, and the model used to simulate them, as illustrated in Figure 3. Only by doing this can the integrity of a model be demonstrated and confidence in the outcomes of the analysis be assured.

Figure 3: Transparency and coherence

Read a closely-related case study here.