Why Does Safran Risk Give Different Results than Oracle Primavera Risk Analysis?

Why don’t Safran Risk results match Oracle Primavera Risk Analysis (OPRA) results on impacted risk models?

A client recently reached out because they couldn’t get Safran’s results to match those from OPRA. What they have been finding is that occasionally the values from OPRA are significantly longer than those from Safran, particularly above P80 confidence levels.

As both an Oracle certified OPRA instructor/consultant and a Safran Risk certified instructor/consultant, this was of interest to me. I haven’t seen much difference in results between the two tools, and any variance from OPRA is a cause for concern to someone considering moving from OPRA to Safran Risk.

For example, this is the result from an Impacted Risk Model in OPRA:



This is the same result from Safran:



As you can see, while the values up to P80 are similar, there are longer tails in OPRA.

Are you ready for a deep dive into Schedule Risk Analysis theory? Because the cause is quite interesting:

First, let’s look at the Duration distribution in OPRA:



Now the Duration distribution in Safran:



Virtually identical!

So what could cause the Duration distribution to be the same while the Finish Date duration is different? It had me scratching my head…

Let’s go back and look at how OPRA builds an impacted risk model. OPRA converts the original activity to a Hammock, and then creates a new activity to represent the original activity, and additional activities to represent each risk event. Looking at Activity F before the impacted model is built:



With one risk (Risk 9) applied, Activity F becomes this:



OPRA keeps the original predecessor logic to the newly created Activity F (A1012:B). In this example, the existing relationship is a FF relationship with the predecessor being Activity E. It then links the risk event (A1012:Risk9) as a successor to the newly created Activity F (A1012:B) with a FS relationship. Finally, it creates a new link to the original successor from the hammock.

So this:





Becomes this:



As a note, this was a test file from a client; I wouldn’t build this odd combination of an FF predecessor and a SS successor in the real world; I would consider it bad scheduling practice. Ultimately, that odd logic is also why we are seeing the delta between OPRA and Safran.

Why? When OPRA creates the new activities, it still links the predecessor to the original activity. That works great when the predecessor is an FS or SS relationship, but it creates an issue when the predecessor is a FF relationship.

Here is what happens when you have a FS relationship between Activity E and Activity F:



Let’s step back and think about what a Finish to Finish (FF) relationship is – in an FF, the predecessor must finish before the successor can finish. Contrary to what some people think, it doesn’t mean that the activities must finish together.

But what happens if we split Activities E & F the way that OPRA does when the impacted risk plan is built?
This is what occurs when you have a FS relationship between Activity E and Activity F (while the normal convention is to draw the hammock above the activities, I have flipped them to make it easier to read):



If there is a delay in Activity E, either because of uncertainty on the original activity or due to Risk05 firing, the start of New Activity F will be delayed.

But what if there is a FF relationship instead of an FS relationship between Activity E and Activity F? This is where things potentially go wrong. OPRA still links the predecessor to New Activity F.



So, why does this matter? Well, if Activity E gets delayed beyond the finish of New Activity F, it will delay the start of Risk 09. Remember that the original requirement was that Activity E must finish before Activity F finishes, but now the requirement is that it finishes before New Activity F (and, therefore, before Risk 09 starts). That wasn’t the original intent – we only had to finish Activity E before Activity F; now we have to finish Activity E before we’ve barely started F (akin to a large negative lag on the relationship).



Any time that the overall duration of Hammock Activity E exceeds the duration of New Activity F, there will be an increased overall delay to the project because Risk 09 would be delayed from starting. This is clearly not the intent of the original FF relationship.

Here is an example from the OPRA Step Through Analysis:



In our example, that would be represented by these bars on the histogram. This results in a nearly 3.5 month P100 delay.



Let’s look at a classic example where FF relationships are used: I have drywallers and painters working through a commercial building. The painters can’t finish until a few days after the drywallers, so I use an FF relationship with a few days lag. If I create a risk that there will be more drywall required than estimated, along with a similar risk for the painters, the painters won’t be able to work on any of their extra work until all the drywall is completed.

Incidentally, Safran handles this in stride, since the risks are applied directly to the original activity rather than to a separate risk activity, so the FF relationship naturally moves to the end of the activity.

So, OPRA is not handling this scenario correctly, but how can I fix this in OPRA? There isn’t any point in raising an SR with Oracle since OPRA is on extended support and the last patch was issued nearly 10 years ago. One solution is to manually change the FF relationship to link to the end of Risk09, instead of the end of New Activity F.



This should restore the relationship between the original activities. Just be careful not to create any open ends.

Let’s try it. The results are:





Which exactly matches Safran’s results.

Just to make sure that this is the issue, I can duplicate the OPRA Risk Event process in Safran (i.e. three activities: base activity, one impact activity, and one hammock to tie them together):

I get a Finish Date distribution that exactly matches OPRA:



So, is this really an issue? If we take the two curves (one from the original OPRA approach and one from the standard Safran approach) and compare them in the Safran Distribution Comparison, here is how they compare:



As you can see, the variances largely occur between P90 and P100 values (i.e. only the time when the duration of Activity E and Risk 05 exceed the duration of Activity F) but cause a huge amount of delay between P90 and P100.

The ultimate solution is probably to switch to Safran Risk – it’s up to date from a risk theory perspective, offering risk-centric modelling and integrated cost and schedule risk analysis, which OPRA can’t offer. This issue is just another reason to make the shift.