Hello, my name is Ian Nicholson, VP of Solutions at Emerald Associates.
I’ve been working with Oracle Primavera Risk Analysis (OPRA) since 2001 — Emerald being the exclusive Canadian distributor for Pertmaster (as it was then known) until its acquisition by Primavera in 2006.
For a long time, OPRA was the final word in project risk analysis. However, following two decades of technological advancement, the risk management landscape has shifted irrevocably.
So, over the next few weeks, I’ll be publishing a series of articles explaining why I feel OPRA users should wave goodbye to their existing risk management platform and upgrade to Safran Risk.
Part one will analyse the fundamental technological differences between the two products.
The Early Days of Pertmaster
Pertmaster began life as a Critical Path Method (CPM) scheduling tool, before being reintroduced as a risk analysis application in 2001.
At the time, most desktop scheduling tools used flat files to store data. P6 had released only a couple of years prior and had yet to be widely adopted, while P3 ran on a Btrieve database and was pretty much a flat, file-based system. The idea of using a database engine backend to manage key project data was still a relatively novel concept at the time, and so Pertmaster adopted the more common flat, file-based structure.
Even so, for most risk users at the turn of the millennium, this didn’t matter. Schedule Risk Analysis (SRA) was itself comparatively new. It was performed infrequently and only by a limited number of people using schedules that were, generally speaking, built specifically for risk analysis. Therefore, they only had to manage a few hundred activities at most.
Performance was fast enough to satisfy most requirements, while *.rsk output files would only be kept for short periods before being deleted or over-written. It was also extremely unlikely that more than one user would need to access a file at any given time. Everything in the garden was rosy.
Risk Analysis in the Modern Era
Fast forward 20 years and things have changed significantly in the world of schedule risk analysis. For starters, we now have defined risk maturity models.
Organizations have made SRA part of their wider project management methodology and project teams routinely build their own risk models to suit their individual requirements. By contrast, standalone schedules for risk analysis are becoming rarer as multiple users demand the ability to look at several models concurrently.
At the same time, schedules have become larger. An increasing amount of detail is built into the schedule through integration with other systems, necessitating an increase in power of the underlying systems to compensate.
For example, whereas 15 years ago a large shutdown/turnaround (STO) schedule would be comprised of 5,000 activities, in 2020, a large STO schedule measures somewhere in the region of 100k activities. Making a new, dedicated schedule each and every time you run a risk analysis (typically quarterly) is simply no longer realistic.
Scheduling systems have evolved to accommodate these requirements. What we need is an SRA tool that possesses the same enhancements.
Technological Requirements
Today, it's essential for SRA tools to have a backend database that can store projects and risk outputs, alongside user and risk data, to facilitate 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 back in the day, development ceased in 2013; the last patch being issued in 2015. OPRA was never equipped with a database backend or moved to a 64-bit application, meaning the system remains single user and limited to schedules that clock in at under 10,000 activities.
Having already created a world-class platform in Safran Project, Safran had a distinct advantage when developing their Risk module.
Enter Safran Risk Analysis
Running on an SQL Server or Oracle database and featuring a 64-bit application layer that enabled the team to release regular software enhancements, when development began on Safran Risk in 2015, this provided the team with a solid foundation on which to build. Unsurprisingly, Safran Project continues to be considered a direct competitor to P6 in Europe and the Middle East, as people realize the benefits of moving from Pertmaster to Safran Risk.
Safran had one other advantage when it came to developing Safran Risk: they were able to leverage the knowledge and expertise of the original Pertmaster development team. They helped guide development, ensuring that the lessons learned from Pertmaster were incorporated into Safran Risk from the start.
Increased Speed, Improved Scalability
The reality is that the majority of complaints I hear about OPRA are that it’s slow, prone to crashing, and isn’t particularly user friendly. This is especially true when it comes to transferring data in and out of the system.
But if you continue to use OPRA to manage risk analysis across your project portfolio, chances are, you don’t want to change your basic process; you just want a more stable and scalable platform. And that’s exactly what Safran Risk offers.
In my next blog post, I’ll be examining the Safran Risk user interface and why a modern UI is vital to your risk management team.
