Why You Should Upgrade From Oracle Primavera Risk Analysis to Safran Risk – Part 6
I’m Ian Nicholson, VP Solutions at Emerald Associates. I have been working with Oracle Primavera Risk Analysis (OPRA) since 2001 when it was Pertmaster, Emerald being the exclusive Canadian distributor for Pertmaster until their acquisition by Primavera in 2006.
In this series of blogs, I will explain why I feel that all OPRA users should upgrade to Safran Risk (SR).
Part 6: Correlation (and the Central Limit Theorem)
Correlation is the mutual relationship between one or more events. In schedule risk analysis, it is used to indicate that one risk’s probability is likely to increase (or decrease) if another risk occurs. For example, if the first piling activity on a project goes badly, chances are that all the piling activities will go badly and there is a further (weaker) chance that all the excavation activities will also go badly. That seems to be pretty obvious and we need the ability to build that into our risk models.
Correlation has another purpose: to counteract a related topic call the Central Limit Theorem (CLT). There have been many articles written regarding the CLT, but to summarize the issue, if you have a number of similar duration activities linked in series that have the same uncertainties, when randomly sampled, if one activity goes long, another will go short and they will cancel each other out, leading to a loss of extreme values in the probabilistic analysis.
Some argue that in order to combat the (CLT) and its impact on the model, correlation is absolutely required while others will argue that so long as you have a high level schedule, the CLT is a non-issue and thus correlation is not required. Personally, I like working with the project team’s live schedule, which tends to be a Level 3 or Level 4 schedule and correlation is often a big issue. We’ll leave the discussion about which level of schedule risk should be performed on for another blog and concentrate on the CLT here.
Figure 1: The effect of Central Limit Theorem on a one activity schedule and a ten day activity schedule with the same overall deterministic duration and uncertainty distribution. The PO duration is 80 days vs 90 days and the P100 duration is 120 days vs 110 days, respectively. The CLT has lopped 10 days off each end of our distribution in the case of the ten activity model.
Applying correlation can correct the impact of the CLT by preventing the cancellation that occurs in a purely random sampling. Applying an 80% correlation between the risks leads to the following result:
Figure 2: The effects of applying correlation to correct the Central Limit Theorem. By applying a correlation to the uncertainties on the ten activity model, we can closely approximate the one activity model.
So, given that we need to enter correlation in our model to reflect risk’s interdependencies and we also need to use correlation to combat the CLT, let’s look at how correlation is performed in OPRA and in Safran Risk.
In OPRA, correlation is assigned between activities. This means that in order to combat the central limit theorem for my 10 activities, I need to link all 10 together in the correlation module. It’s possible but tedious and it gets worse as I have more and more activities to be correlated. What’s confusing for the user is that they have to decide which activity is the parent and which activities are children in the correlation: do I choose the first one in the string or the longest one or something else? It’s not well documented. It gets even more difficult if I have multiple correlations between activities with multiple uncertainties or risks: without a PhD in statistics, how do I know what to correlate and how much should the correlation be?
Figure 3: OPRA Correlation Assignment
SRA takes a different approach – risks are correlated, not activities. This makes a lot of sense in that if you have an activity with multiple risks, the correlation can exist only to the risk in question not to the entire activity. Similarly, if a risk applies to multiple activities, the correlation is also automatically applied (but can be turned off if necessary).
There are actually a couple of ways to handle correlation in Safran Risk.
The first is to correlate the impact of a risk on all of the activities that it applies to – unchecking the box will apply 100% correlation to all of the activities that the risk is assigned to:
Figure 4: Safran single risk impact correlation
But what if we need to correlate multiple risks to each other? In OPRA, the approach of correlating activities makes this almost impossible; how would you figure out to what degree two activities with multiple risks should be correlated? SRA has this covered – by correlating risks together, the appropriate impacts will be calculated automatically.
Figure 5: Safran Risk Correlation Mapping Matrix
Not only does this mapping allow the user to correlate risks to each other but it also allows the probability of occurrence of each risk and the schedule impacts of the risks to be correlated independently. Further, the Pre- and Post-Mitigated positions can be differently correlated. Cost risks can also be correlated (not shown above).
The Safran approach makes understanding and applying correlation much easier. When correlation is clear and easy, the user more likely to apply it, leading to better results (and hopefully less discussion of the Central Limit Theorem).
About the Author
As our VP Solutions and a Lead Risk and Implementation Specialist, Ian leads Emerald’s functional consulting group. With over 20 years of international experience in varied fields and roles from manufacturing, heavy civil construction, pharmaceutical plant construction, hospital projects and oil and gas capital and turnaround projects, Ian brings a wealth of project knowledge to all of our clients.
A visionary in the world of CAPEX, maintenance and turnaround planning processes, Ian has lead many of our large clients through their integration projects between ERP/EAM systems and Primavera products. Some of his integration success stories include Suncor Energy SAP to Primavera integration, BP Maximo to P6 integration, implementation of P6 at the Ontario Power Authority as well as the integration of Primavera Contract Manager with Oracle Financials at Capital Health Authority and Vancouver’s Rapid Transit Project 2000. Other major clients include Milwaukee Metropolitan Sewerage District, Shell Canada and Shell Global Solutions.
Ian has conducted Monte-Carlo risk analysis on CAPEX and turnaround projects for Shell Canada, Suncor Energy, Husky Energy and Bruce Power. He believes that successful Monte Carlo application is a process, not just a tool and has spoken at a number of events on the correct application of risk analysis.
When not assisting clients with their projects, Ian unwinds by riding his BMW motorcycle, listening to music or dragging his kids on long hikes.