NEW: Weather modelling in Oracle Primavera Cloud

Oracle Primavera Cloud

Oracle Primavera Cloud (OPC), the tool that we recently praised for its comprehensiveness, also supports schedule risk analysis. We like OPC because it takes project controls out of the expert (or freak) zone and puts it in the center of any organization. Simplicity is one of the key factors to obtain this. But sometimes simple can be considered too simple by professionals. For many of our clients (in offshore projects and construction projects) the risk analysis app in OPC was in that situation. These projects are very prone to bad weather and weather modelling functionalities did not exist in the OPC Risk App. We reported our need for this functionality to Oracle and as usual they were very willing to listen to their long-term partners.

Weather modelling is part of the January 2021 release of OPC. We are very happy with this development and also proud because the algorithm we proposed to Oracle made it to the tool.

How does weather modelling work in OPC?

(Ready to go more technical?)

First, weather is included as a Risk Type in the risk register.

A weather risk can be assigned to a number of activities. Based on the assigned calendar of these activities, the weather risk will add some additional non-working days in the calendar. Whenever an activity is in progress on these non-working days, the elapsed duration of that activity will increase by the length of the weather delay.

Next, the user defines how many non-working days a weather risk generates in a certain period. Here OPC gives two options defined by a parameter called Non-Working Time Definition.

The first option is to set this parameter to Distribution. In this case, OPC will model a number of non-working days for a defined period of time. How much this number is can be defined by a fix number, a uniform distribution or a triangular distribution. In our example, there will be between 1 and 6 non-working days in the month of February. For any iteration, a number of non-working days is generated from the distribution function. Let’s now consider an iteration with three non-working days, which is the most likely value. Then, randomly three of the days in February will be made non-working days. OPC visualizes this nicely in its calendar view for a single iteration:

Given the defined distribution function, almost all iterations in the schedule risk analysis, will have 2, 3, 4 or 5 non-working days in February. For any specific day, the non-working percentage is 12% (i.e. the average of the triangular distribution divided by 28 days).

The above is a simple way to assign weather delays, but in our experience it is not always how weather behaves because of two reasons:

1. The non-working days will be assigned randomly within the period. In reality they will occur much more in series. Yesterday’s weather is a good indicator of today’s weather. While in the algorithm it is virtually impossible (12%*12%*12%) to have three consecutive raining days, in reality it clearly is. Because activities typically consist out of consecutive days, this shortcoming is clearly important.
2. If we look at the total impact on the project, there will be close to 3 days of non-working days in every iteration. That might be a correct average, but when we examine real weather data, the standard deviation on this number of days is mostly very large. We clearly have good winters (0 non-working days) and bad winters (10 non-working days). The convergence to the mean is not always realistic. I hope that readers understand that this is a major shortcoming. Risk analysis is not about generating multiple scenario’s that are almost equal, it is about generating optimistic (P20) and pessimistic scenario’s (P90) and taking these both into account in your robust decision making.

Proove’s algorithm

In the algorithm we developed, we try to overcome the above pitfalls but also to keep the simplicity. To select our algorithm, the Non-Working Time Definition parameter should be set to Percentage. The input we ask for are simply two numbers:

• The non-working percentage states the unconditional percentage that any day in the specified period is a non-working day. Well, that is the 12% calculated above. Please note how easy it is to extract this number from real weather data. Simply count the number of non-working days and divide this number by the number of days.
• The non-working persistence is the probability that a non-working day follows a different non-working day. As we explained above, this can be much higher than 12%, let’s say 80%. Also this one is not difficult to extract from weather data with some Excel skills.

How are these parameters used by the algorithm? Based on the above parameters, we can now, statistically calculate all conditional probabilities of today’s weather based on yesterday’s weather:

These numbers can then be used to simulate weather. We simply look at the previous day and use the percentages to determine whether today is a working day or not as described in the above table.

The simulation result shows that it is now much more plausible that a chain of consecutive non-working days will arise. The resulting distribution function of the number of non-working days in February looks very different than with the Distribution approach:

We directly observe that the spread is much larger and thus that the good / bad winter effect is reflected in the simulation results. In around 50% of the iterations, there is no weather delay in February. Also, the P90 value is 7 days, a value that was not even realizable with the first option. The two shortcomings of the Distribution approach are covered.

The proposed algorithm is also very flexible as very different scenario's can be modeled by changing the two parameters.

Conclusion

Performing a good schedule risk analysis is not an easy task. Oracle Primavera Cloud aims to make it more accessible by introducing simple, but effective algorithms. As schedule risk analysis experts we are happy with the new release of the tool. Moreover, at Proove we are also proud that we could contribute to the development of this tool.