Skip to main content

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

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, as Emerald was 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 Analysis (SR).

Part 1: Technology

You might be wondering why I’m starting with such a boring topic. Don’t we really want to discuss bells and whistles and the cool factor items? The reality is that the most common complaints that I hear about OPRA are that it’s slow, it crashes a lot and it’s difficult to move data in and out. So if you’re an OPRA user today, it’s quite possible that you don’t want to change your process but you just need a more stable, more scalable platform.

When OPRA (at the time called Pertmaster) was re-introduced as a Risk Analysis tool in 2001 (it had previously been a CPM scheduling tool), most desktop scheduling tools used flat files to store their data. P6 had come out only a couple of years prior and had yet to be widely adopted; P3 ran on a BTrieve database, which was pretty much a flat file based system. The idea of using a database engine backend was something that was still relatively new, so Pertmaster used the more common flat file based structure.

For most risk users of the time, this didn’t matter because Schedule Risk Analysis (SRA) was a new and relatively immature concept that was performed infrequently by relatively few people on schedules that were generally built specifically for the risk analysis and had only a few hundred activities. Performance of such a system would be fast enough and the *.rsk output files would only be kept for short periods before being deleted or over-written. It was also unlikely that more than one user would need to access the file at a time.

The thing is, this is no longer the case. Over nearly 20 years of SRA, things have changed significantly. We now have defined risk maturity models, organizations have made SRA part of their project management methodology, and project teams build their own risk models. Standalone schedules for risk analyses are becoming rare and multiple users want to look at the model concurrently.

At the same time, schedules have become larger as more detail is built into the schedule through integration with other systems. Scheduling systems have become more powerful to compensate. Where a large Shutdown/Turnaround (STO) schedule 15 years ago would be 5,000 activities, a large STO schedule is now approaching 100k activities. Making a new dedicated schedule each time that a risk analysis is run (often quarterly) is simply no longer realistic.

Scheduling systems have evolved since 2001. What we need is a SRA tool that has the same enhancements. The most important of these is that the SRA tool has a backend database to store the projects, user data, risk data and risk outputs and to allow concurrent multi-user access. A 64-bit application platform is also required for large schedules.

Unfortunately for those of us who used and loved OPRA, development stopped in 2013 and the last patch was issued in 2015. The platform never got a database backend or moved to a 64-bit application, meaning that the system remains single user and is limited to schedules under 10k activities. It simply hasn’t evolved the way it needed to to stay relevant.

Safran had an advantage in developing their new Safran Risk module. They already had a world class scheduling program, Safran Project, available that runs on a SQL Server or Oracle database and a 64 bit application layer. In Europe and the Middle East, Safran Project is considered a competitor to P6. When Safran started development of SR in 2015, the Safran Project platform was a solid place to start and enhancements have been released regularly since.

In order to speed up development of Safran Risk, Safran also had another advantage: they leveraged the knowledge of the original Pertmaster development team to guide the development and ensure that the lessons of Pertmaster were incorporated from the start in Safran Risk.

In the next blog post, we’ll talk about the Safran user interface and why a modern UI is important to your risk team.

No video selected.

About the Author

Ian Nicholson, P.Eng. - VP Solutions

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.

Leave a comment

Please login to leave a comment.