Why You Should Upgrade From Oracle Primavera Risk Analysis to Safran Risk – Part 5

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 5: Risks and Uncertainties

When I started working with OPRA (then Pertmaster) all risks were modelled as uncertainties on activities, usually as three point estimates. We would add activities to the model to simulate risk events occurring in the schedule, and we would use task existence to model the likelihood of occurrence. This approach, while it worked, was somewhat tedious when performing what-if analysis, and it made it impossible to trace the impact of a risk that impacted multiple activities, since the tornado graph could only show the impact of each activity, not the risk event that caused the activities in the first place.

The Pertmaster development team improved the process by introducing a Risk Register that would allow risk events to be modelled separately from the schedule, and then an impacted risk plan could be generated by creating sub-tasks for each risk event. This worked well for what-if analysis as changes could be made and a revised model generated quickly. The tornado chart was also changed so that a user could see the impact of risks that landed on multiple activities.

But what about uncertainties? We were always stuck with modelling uncertainties on our activities in OPRA. So if I had an uncertainty that impacted multiple activities, I would have to either input the uncertainty onto multiple activities (and manually calculate the impact durations) or use the QuickRisk function to generate the impacts. The problem with using QuickRisk is that it is too easy to overwrite an existing value with the new value and not realize your previous data had been lost.

There was another issue with uncertainties; how could we model an activity that had more than one uncertainty on it? For example, I might have a piling activity that had an uncertainty based on the productivity of the piling crew as well as an uncertainty based on the accuracy of the soils report. As the person building the model, I would have to calculate the combined uncertainty of these items.

The OPRA team, to their credit, did start on development of a module called Risk Factors that worked similarly to the Risk Register and allowed multiple uncertainties to be added to one (or many) activities. Unfortunately, it was never really completed to a level that would make it useful. With Oracle abandoning new development on the tool, this module will never be completed.

In developing Safran Risk (SR), the team decided to combine the modelling of risks events and uncertainties into the module called Project Risks. This simple step makes building a what-if model much easier since all “risks” can be either risk events or uncertainties which can be turned on or off as required. Risk events and uncertainties can be applied to as many activities as required and the impact can be directly traced back to the item in the risk module.

To model a risk event, the probability will be set to less than 100% with (usually) an absolute impact; whereas for uncertainties, the probability will be set to 100% and the impact will be (usually) a relative percentage of the original duration. However, a user can mix and match probability and impact types to build the model as they need. It is also possible to set pre- and post-mitigated positions for all Risk Events and Uncertainties which allows for great flexibility when conducting what-if analysis of mitigation strategies.

In addition to Uncertainties and Risk Events (collectively called Standard Risks in the tool), the Project Risks module also allows the user to configure Estimate Uncertainties and Calendar Risks. Of course each risk can have a cost component that can be modelled within the tool as part of the integrated cost and schedule risk analysis approach that makes SR so powerful.

After Project Risks are entered in the system, the risks can be mapped to the activities using the Risk Mapping module. For anyone who tried to use the Risk Register module in OPRA on a large schedule and struggled with pages and pages of activities, the Risk Mapping module is much easier to use because activity layouts can be used to filter and group activities for easy mapping to the risks.

The really great feature is that SR will quickly show the total impact of risk events and uncertainties on any activity prior to running the risk analysis. This is very useful to find errors where a risk event or an uncertainty is out of range of realistic values. In OPRA, it was very easy to assign a risk duration out of all proportion to the original task duration (in fact, the way that ranging worked in the Risk Register model made it hard to get the durations correct without a great deal of fiddling).

So, what if a user just wants to enter three point estimates on each activity? This can be done one of two ways in Safran Risk:

1. Three point estimates are still supported and can be entered directly on the activity (this is useful if the user plans to import an old OPRA file or just want to continue their old process in newer software).
2. You can create a one-to-one mapping between line items in the risk tab and activities. This is preferred because when the user is ready to incorporate risk events in the model, they can be easily added to the model. Creating this mapping is easier than it sounds because it is so easy to import and export to and from both the Risk and Risk Mapping modules.

Ultimately, if you really want to develop risk models that have both uncertainties and risk events (and most models do), Safran is much easier to use than OPRA. If you also need to develop integrated cost and schedule risk models (covered in my last blog post), Safran is the only game in town.