Oracle Primavera Risk Analysis (OPRA) has been a mainstay of project risk management for almost two decades.
However, development ceased in 2013, the last patch was released in 2015, and in 2019 Oracle officially demoted OPRA to "Controlled Availability" status, confirming the cessation of development activities.
Naturally, this has had a serious impact on support and created additional risks for users:
1. Questions may get left unanswered
2. Vulnerabilities may be left unpatched
3. Conflicts and incompatibilities may be created with newer software packages or environments
4. Hardware may stop working
5. New functionality will not be added
For those who’ve relied on it for the majority of their career, the prospect of transitioning to a brand-new tool may appear rather intimidating. Yet, as the pace of technological progression quickens, legacy systems like OPRA have become unfit for purpose. To the extent that, by not upgrading to a more modern and innovative alternative like Safran Risk, project managers are putting the success of their projects under threat.
With that in mind, we’ve created a comprehensive knowledge portal to help OPRA users understand the benefits of migrating to Safran Risk, and how moving to our system isn't as time-consuming or problematic as you might think.
The focal point of our knowledge portal are the key features that give Safran Risk the edge over OPRA.
These are based around a series of articles written by Ian Nicholson: VP of Solutions at Emerald Associates and a leading authority on project risk. As well as highlighting the major differences, Ian explains how they help project managers maintain control of their risk environment.
There will be ten articles in total, There will be ten articles in total, with the remaining articles added one week at a time, so check back regularly over the coming weeks.
Alongside the benefits of migrating to Safran Risk, our knowledge portal includes a detailed webinar in which Safran CEO Richard Wood and Linear Project Software co-founder Santosh Bhat explain how integrating data from a third-party application is quick and easy with Safran Risk.
Designed to guide you through every stage of the process, they also address the most common concerns those moving from OPRA to Safran Risk have. Particularly if OPRA is the only risk management system you've used in the past.
You'll find our on-demand webinar below.
When Rusty Johnson, Sarim Kahn, and Glenn Jarrad left Pertmaster (what is now Oracle Primavera Risk Analysis) in 2006, they had a very specific goal in mind: to create a superior breed of risk management tool.
One that went beyond the simple quantification of risk to meet the demands of the modern project manager.
Applying the lessons they’d learned while working on Pertmaster they got to work. And the fruit of their labours was Safran Risk.
Listen to Safran CEO Richard Wood and Rusty Johnson discuss the differences between the two products in the video below. Alternatively, scroll further down and explore Ian Nicholson's in-depth articles.
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.
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.
Each new post in the series will be publisher here, on Safran's knowledge portal. So check back regularly for the latest insights.
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.
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.
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.
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.
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.
In part one, I compared the technology that underpins OPRA with that utilized by Safran Risk. More specifically, I explained that the technology’s inability to support large risk models is the most common criticism levelled at OPRA. However, taking second spot on that list would be the clunky nature of the program’s user interface.
When Pertmaster (OPRA) was re-introduced as a Risk Analysis tool in 2001 — Pertmaster having been a critical path method (CPM) scheduling tool up until that time — it boasted a pretty decent user interface.
It looked like a typical CPM scheduling tool for the most part. The only exception being that it featured an extra “Risk” menu under which inputs were available, while extra items for outputs were included under the “Reports” menu.
OPRA Risk Menu
For most risk users of the time, this UI was more than sufficient because Schedule Risk Analysis (SRA) was still a relatively new and immature concept.
Performed infrequently and by relatively few people, users would gradually learn where to find the required items in the Risk and Reports menus over time. The guiding principle was, essentially, if someone could master P3 or Artemis, Pertmaster should be a walk in the park! Besides, compared to Primavera’s Monte Carlo add-on, Pertmaster offered a significant step forward in terms of usability.
Fast forward to 2020 and these deficiencies have grown into a serious pain point for project managers; especially when it comes to moving reports and layouts from one model to another in order to generate consistent outputs. Suffice it to say, the process has become nothing short of tedious.
OPRA Reports menu
After nearly 20 years of schedule risk analysis, things have changed considerably. We now have defined risk maturity models, while organizations have made SRA part of their project management methodology and project teams routinely build their own risk models. The number of people requiring access to these systems and, more importantly, the knowledge and technical know-how to operate them effectively has grown. It’s therefore imperative that modern risk management tools employ a logical workflow.
When Safran developed Safran Risk, they pulled on the experience of the original Pertmaster developers to modernize the User Interface and make it easier for project managers to understand and learn.
The first step was to change from a menu-based input model, to a sequential, tab-based workflow system. This enables users to navigate from left to right as they build the risk model, delivering a more natural and intuitive process.
Safran Risk tab-based navigation
Additionally, all the functionality of Safran’s scheduling tool is available in the same application — itself one of the main advantages of building the risk engine on top of the scheduling package. Users can create layouts and filters, and share them between users and projects, simplifying the application of standard processes and reports.
The importance of streamlined, more ergonomic UI shouldn’t be underestimated. Not only does it streamline the process of training new users, it decreases the likelihood they’ll miss key steps when navigating a custom risk model or designing a brand-new one from scratch. Speaking for myself, I find the Safran UI makes everything a lot easier.
I still come across the occasional individual for whom the P3 interface was markedly superior to Primavera. Nevertheless, I doubt any of them would want to go back to working with P3 on a daily basis. It’s the equivalent of owning a classic sports car: you might like the idea of having a Triumph TR6 in your garage, but you wouldn’t want to drive one to work in the middle of the Canadian winter!
Join me for my next blog post where I’ll be discussing the benefits of integrated cost and schedule risk analysis.
Many years ago, I was hired by a large multinational oil and gas company. They were about to embark on a new technology project and my role was to conduct a schedule risk analysis in preparation for a go/no-go decision from the board. At the same time, another consultant was tasked with performing a cost risk analysis.
Billions of dollars were at stake, yet the organization in question wanted to review the results of our investigations independently. We were forbidden from discussing our findings with one another.
Nevertheless, having agreed that cost and schedule risk were intrinsically linked, we investigated ways the two analyses could be combined to provide greater insight. We narrowed down our list down to two options:
When faced with similar conundrums in the years since, the oil and gas industry has generally favored option two as the most feasible.
But what we and the industry as a whole needed was a system that would allow us to develop the two models concurrently so that the impact of uncertainties and risks related to both cost and schedule in the Monte Carlo simulations would be visible immediately.
A recent study of Oil and Gas megaprojects in Alberta found that, on average, 19% of projects experienced cost overruns, while 17% experienced schedule overruns.
It’s no coincidence that these numbers are so closely correlated. Yet we continue to make decisions on cost and schedule mitigation strategies without clear insight into the impact changes to one is likely to have on the other.
Figure 1: Integrated Cost and Schedule Risk Process
Often as project managers, we get tunnel vision. We focus too heavily on schedule or cost at the expense of the other. For example, I once worked on a turnaround project that had a budget of $120 million and a 35-day maintenance window. Management communicated that schedule was everything; cost was very much a secondary concern (so much so that it wasn’t even monitored during the project). In response, the project team started burning overtime almost from the first shift to maintain the schedule.
We completed the work on time to great fanfare. But, months later, when all the invoices were in, it was discovered that our success came at a price: $160 million, to be precise. To put it another way, we were $40 million over budget. This caused great distress within the organization. Heads rolled and the company hierarchy abandoned the “Full speed ahead, damn the torpedoes” approach from thereon in.
Schedule pressure dooms more megaprojects than any other single factor – E. W. Merrow
The ideal solution for project managers is a method that allows them to accurately gauge the likelihood of achieving both cost and schedule goals concurrently. This is known as the Joint Confidence Level (JCL) and it helps us to understand the interdependencies that link the two halves of successful project management.
The AACE 57R-09 Integrated Cost and Schedule Risk Analysis Guideline provides a detailed explanation of the process of combining cost and schedule risk analysis. As does Dr. David Hewlitt’s book Integrated Cost-Schedule Risk Analysis.
OK, so now we understand why we need to conduct cost and schedule risk together. But why choose Safran Risk specifically?
Safran Risk is one of the only tools on the market that provides users with the option of evaluating cost and schedule risks together. Costs can also be modelled separately or collectively with activity durations; it’s also possible to apportion part of an estimate line item to a schedule activity while leaving the rest independent. This provides greater flexibility when modeling extant risks on a project and helps project managers avoid the frustration of trying to resource load a traditional critical path method (CPM) schedule to match cost estimates.
In addition, Safran Risk simplifies what-if analysis. While cost vs schedule risk outcomes can be mapped on a scatter plot to create a Joint Confidence Level diagram illustrating the probabilities of hitting cost and schedule targets concurrently.
Figure 2: JCL at 70% confidence – note the deterministic cost and schedule probability (the star shape) is only 17%
With so much to offer, it should come as no surprise to learn that a recent evaluation of commercially available risk management tools boasting integrated cost/schedule risk analysis undertaken by the Energy Facility Contractors Group (EFCOG), chose Safran Risk as the best product for those working with Primavera P6, and the second best for those working with Microsoft Project.
Come back in a few days for part four of our series where I’ll be discussing the subject of analysis by exclusion. Specifically, how Safran's approach is considerably faster and more accurate than OPRA.
I first heard about analysis by exclusion a few years ago while I was helping a large mining company refine their risk processes. Curious, I asked for a demonstration of how it worked in OPRA.
In step one, the existing risk model was run through OPRA with all extant risks attached. Once completed, the team would then rerun the model multiple times, removing risks one at a time and comparing the outputs from each updated model with the initial analysis. The result was that the team were able to more accurately gauge the impact of individual risks on the wider project.
However, it quickly became apparent there were a few drawbacks.
The main issue was time.
To effectively answer the question “What is the impact of this specific risk on the schedule?” and generate usable data, OPRA users would have to:
Additionally, there were issues with quantifying the impact of each risk. Tornado charts ranked activities and risks automatically in OPRA, but they were also based on Pearson’s Product Moment. This meant they were categorized by percentage rankings: something project managers struggle to interpret.
All-in-all, I was informed it would take about a week to perform comprehensive risk analysis by exclusion on a large construction schedule using OPRA; more if the model was subjected to changes during the process.
One of the key tenets of workplace efficiency is that if a process must be repeated time and again, it should be automated.
For starters, this saves time that would otherwise be wasted performing mundane tasks. But it also improves accuracy — which is crucial for risk analysis by exclusion and the process more generally.
Imagine you forgot to turn Risk Factor #9 back on before switching off Risk Factor #10, the results of that iteration of your analysis would be skewed. The team might then act on the wrong Risk Factor, simply because its impact was incorrectly overstated.
This got me thinking about automating the process in OPRA using visual basic. I brought the question to my friend and colleague Russell Johnson — who also happened to be the former CTO of Pertmaster.
His response was interesting. While technically possible, he warned me several big obstacles stood in the way.
These days, the question of manual vs automated analysis by exclusion in OPRA is moot, seeing as Oracle dropped visual basic support years ago. Nevertheless, when developing Safran Risk, Russell Johnson remembered the difficulties experienced by OPRA users and so decided to automate the process.
The results speak for themselves.
Analysis that would have taken 40 hours to complete in OPRA takes mere minutes when conducted via Safran Risk. Moreover, it offers far greater accuracy, reducing the likelihood of mistakes to zero.
To understand how it does this, we need to take a closer look at how analysis by exclusion works in SR.
To begin, Safran Risk allows users to perform analysis in single or multiple passes.
During a single pass, SR runs through each risk once. It then displays an output with each risk individually excluded — essentially, it’s the same exercise my client was performing, only automated.
Below is a diagram displaying the results of a single pass analysis with all risks on a demo ‘Drone’ project included.
Compare that with the diagram below which shows the results when only one risk and opportunity have been removed.
In the examples given here, the black line represents all risks turned on (the “None” line) and the green line represents the same model with only the Testing Overrun risk turned off. This indicates that, at P70, we would save 33 days if we could eliminate the Testing Overrun risk.
However, the cumulative saving of removing multiple risks is not entirely clear in this example. We also have to bear in mind the fact that turning off one risk may mitigate another; particularly if they’re closely correlated. We could get around this by performing the task manually: turning off the top risk, running the analysis, running the next risk, etc. But this only serves to increase the workload.
To truly understand the interaction of the top risks, we must run the same analysis but using multiple passes.
In multiple pass mode, the system runs for a pre-determined number of iterations as specified by the user. With each new iteration, it removes the top risk; with the previous iteration’s risks turned off. This prevents large impact risks from overshadowing lower impact risks, while also displaying the cumulative impact mitigating each additional risk will have on the schedule.
So, in the example below, we turn off the top five risks cumulatively. Pass one turns off Testing Overrun; pass two both Testing Overrun and Design, and so on.
Again, look at the P70 values:
This information is invaluable, as it allows the project team to gauge the impact removing these risks would have on the project. But what about the costs of mitigation vs the cost of the risk itself?
In a previous blog, I wrote about the advantages of integrated cost and schedule risk analysis. Here, thanks to Safran Risk’s integrated model, I can review the same information as before, but on a cost basis.
The final diagram shows what our cost Analysis by Exclusion looks like for every risk: that is cost and schedule. Notice there are a few more risks shown in this display, since there are now cost risks that do not have a schedule impact included.
As you can see, it tells us that by removing the Design Specification risk and ensuring that the Outsource opportunity occurs, we can save 49 days and $295,000. At the same time, any costs associated with the mitigation strategies are also included in the model, ensuring you have direct access to all the information you need from a single dashboard.
Come back in a few days for part five in my series, where I’ll be investigating the features that make modelling risk events and uncertainties so much easier in Safran Risk.
When I began using Pertmaster (as OPRA was known before Oracle acquired it in 2006), all risks were modeled as uncertainties on activities. Usually as three-point estimates.
Activities would be added to the model to simulate and gauge the impact of risk events on the schedule. Task existence would then be used to model the likelihood of occurrence. While this approach worked, it was somewhat tedious; particularly when performing what-if analysis. Specifically, it was impossible to trace the impact of risks that affected multiple activities, since the tornado graph could only show the effect of each activity, not the identity of the risk event that caused triggered the activities in the first place.
To try and improve the process, the Pertmaster team developed a Risk Register. This would allow risk events to be modeled separately from the schedule, after which an impacted risk plan could be generated by creating sub-tasks for each event.
The addition of a Risk Register worked well, as far as what-if analysis was concerned. Changes could be made, and a revised model generated quickly. Similarly, changes to the software’s tornado charts enabled users to observe the impact of risks that applied to multiple activities. But what about uncertainties?
As things stood, we were still required to model activity uncertainties manually in OPRA. If I had an uncertainty that impacted multiple activities, for example, I would have to either input the uncertainty onto multiple activities and calculate the impact durations by hand or use the QuickRisk function to generate the relevant impacts. Though, as anyone who has experience using QuickRisk will know, it was all too easy to inadvertently overwrite existing values without realizing it.
In an effort to solve the problem, the OPRA team developed a module called Risk Factors. Operating on similar principles to the Risk Register, the idea was that users would be able to add multiple uncertainties to multiple activities.
But, Risk Factors was never really completed to a sufficient standard for it to be of any practical use.
The difficulties experienced by OPRA users in regard to modeling risk events and uncertainties helped inform Safran’s approach to the process when work began on SR — just as it had with analysis by exclusion.
They had a clear understanding of the challenges project managers faced and what they required from their risk management software. Ultimately, this led the team to combine the two processes into a purpose-built module called Project Risks.
At the highest level, SR allows users to categorize all “risks” as either risk events or uncertainties. Known collectively as Standard Risks, they can be turned on and off as required and applied to as many activities as the situation demands. Their impact can then be traced back directly to the specific item in the risk module.
By approaching it in this way, Safran was able to make building what-if models considerably easier. However, to reflect the differences between risk events and uncertainties and preserve the integrity of the outputs, the way they’re modeled in SR differs slightly.
To model a risk event in SR, the user sets probability of occurrence at less than 100% and (in most cases) applies an absolute impact value to the event. By contrast, probability is set to 100% exactly when modeling uncertainties, while the impact is typically given a percentage rating relative to the original duration.
Crucially, users can mix and match probability and impact types to build a more precise model for their individual needs. They can also 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.
Additionally, Safran Risk allows users to:
Arguably the greatest feature of Safran Risk is that the total impact of risk events and uncertainties on any activity, prior to running the risk analysis, is available in a fraction of the time. This is vital to finding errors where a risk event or an uncertainty falls outside the range of realistic values. Whereas, in OPRA, it was all too easy to assign risk durations that were out of all proportion to the original task duration using OPRA. Indeed, because of the way ranging worked in the Risk Register model, it was difficult to get accurate durations without a great deal of fiddling.
Ultimately, if you want to develop risk models that incorporate both uncertainties and risk events (and most models do), Safran Risk is the obvious choice — especially if you also need to develop integrated cost and schedule risk models.
I’ll be back in a few days’ time with part six. Be sure to join me then.
Correlation is often crucial to the risk model. It helps analysts understand the often-complex relationships between events and the risks that can affect them. More than that, it plays an integral role in counteracting the effects of the Central Limit Theorem (CLT).
Put simply, in the realm of schedule risk analysis, correlation describes the mutual relationship between one or more events. It indicates the increase or decrease in probability of a particular risk event occurring should a related risk strike.
Think of it this way: if the first piling activity on an earthworks project suffers issues, correlation allows you to gauge the probable impact this will have on subsequent piling activities. Further, it helps you estimate the likelihood that excavation activities as a whole will be affected.
When viewed from that perspective, it’s easy to see why risk managers build correlation into their risk models. But of correlation has another purpose: to counteract the effects of the Central Limit Theorem.
There have been many articles written about CLT, but to summarize the main thrust of the theorem:
If you have several similar duration activities linked together in a series that possess the same uncertainties, should one randomly-sampled activity ‘go long’, another will ‘go short’ – they will effectively cancel each other out. This leads to a loss of extreme values in the probabilistic analysis.
That being the case, some argue that correlation is crucial when it comes to combatting the Central Limit Theorem and its impact on the model. While others claim that, so long as you operate on a high-level schedule, the CLT is a non-issue and thus correlation is not required.
We’ll leave the discussion of which level of schedule risk should be performed and when for another blog, but personally, I prefer working with the project team’s live schedule. These tend to clock in at level three or four, which makes correlation a vital component of the wider model.
Let’s take a look at the impact of the CLT on a one and ten activity schedule.
Figure 1: The effect of Central Limit Theorem on a ‘one and ten activity schedule’ with the same overall deterministic duration and uncertainty distribution. P0 duration is 80 days vs 90 days; P100 duration is 120 days vs 110 days.
As you can see, the CLT has cut ten days off each end of the distribution in the case of the ten-activity model. However, 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 in our one and ten activity schedules.
By applying a correlation to the uncertainties on the ten-activity model specifically, we can closely approximate the one activity model. So, to reflect the risk’s interdependencies and combat the CLT on our model, we need to enter correlation.
But how do OPRA and Safran Risk compare when it comes to correlating risk?
In OPRA, correlation is assigned between activities. This means that to combat the central limit theorem for ten activities, you need to link each of them together in the tool’s correlation module. While this isn’t a particularly complex process, it can be time-consuming – and it only gets worse as additional activities are correlated.
What’s particularly confusing for the user is that they have to decide which activity is the ‘parent’ and which the ‘children’ in the correlation. Which activity takes precedence. Do you choose the first one in the string? The longest? Or something else? But because OPRA documents activities so poorly, it can be difficult to decide which makes the most sense.
Performing multiple correlations between activities, along with several uncertainties or risks, only adds to the complexity. Unless you have a PhD in statistics, chances are you won’t know what to correlate or by how much.
Figure 3: Correlation Assignment in OPRA
Safran Risk takes a different approach…
First and foremost, Safran Risk correlates the risks themselves, not the activities. This makes perfect sense in that, if you have an activity with multiple risks, the correlation applies exclusively to the risk in question and not the entire activity. Similarly, if a risk affects multiple activities, the correlation is applied automatically (although this can be turned off manually, if required).
The biggest advantage Safran Risk has over OPRA is that it offers several ways to handle correlation.
The first, single risk impact correlation, correlates the impact of a single risk on every activity to which it applies. As you can see in the diagram below, unchecking the box will apply 100% correlation to each activity the risk is assigned to:
Figure 4: Safran single risk impact correlation
What if you need to correlate multiple risks? OPRA’s approach to activity correlation makes this almost impossible. By contrast, Safran Risk allows you to correlate risks simultaneously, automatically calculating the appropriate impacts. This is demonstrated in the Safran Risk correlation mapping matrix below:
Figure 5: Safran Risk Correlation Mapping Matrix
Aside from giving you the tools to correlate risks to each other, it enables you to independently correlate the probability of each individual risk’s occurrence and its potential impact on the schedule. Further, the pre and post-mitigated positions can be differently correlated, along with cost risks (not shown above).
All things considered, understanding and applying correlation in Safran Risk is considerably easier.
As we’ve discovered over the course of this article, when incorporated into your risk model, correlation leads to better, more accurate results (not to mention less discussion of the Central Limit Theorem!) And, when correlation is clear and easy, you're more likely to apply it.
Check back in a few days’ time for part 7 in my series. Be sure to read my existing articles if you’re interested in learning more about the differences between OPRA and Safran Risk in the meantime.
During this webinar, Linear Project Software co-founder Santosh Bhat joins Safran CEO Richard Wood to help those thinking of migrating from OPRA to Safran Risk enjoy a fast and effective migration — identifying and unlocking all the additional benefits available in Safran Risk as quickly and easily as possible.
The webinar explores the following topics:
If, after thoroughly exploring our knowledge portal and signing up for one of our learning sessions, you'd like to get some hands-on experience with Safran Risk, we'd recommend signing up for a free trial.
Guided by one of our experts and lasting for a full 30-days, you'll discover how Safran Risk provides the ultimate in schedule confidence, helping you deliver projects on time and within budget.
Now you know what sets Safran Risk apart from OPRA, why you should migrate, and how to go about initiating the process, we'd recommend signing up for a learning session.
Here, you'll receive advice and guidance in the operation of Safran Risk. You'll also have the opportunity to ask any questions you might have about the software or the migration process more generally.