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.
On every Turnaround there are Pre-Turnaround activities that do not get done prior to the actual Turnaround and need to be moved into the Turnaround phase of the schedule.
The challenge is how to record actual hours earned in the PRE phase vs the TA phase, since a large number of these activities already have earned hours associated with them. Simply moving the activities would decrease the reporting of hours in PRE and create earned hours in TA for work that was actually done in PRE.
This can be done simply and quickly with P6-Loader.
Whenever we have a client that is interested in TAPS, we always get the question about how an activity is updated to reflect that it has been cancelled. So, how does TAPS cancel activities?
Cancelled work is work that you have decided not to perform. Typically the turnaround (TA) team doesn’t want to delete the activity because that would change the baseline hours. On the other hand, they also don’t want to progress the activity which would earn hours.
Automate the Process of Updating Cancelled Activities in Primavera P6 with our Barcode Updating Technology
When planning a turnaround project you want to make sure you include all the tasks that will happen and even those that might happen. This is a great strategy in the planning phase because during the actual turnaround, you don't have time to add all of the “potential” activities that become necessary.
Now the dilemma becomes, how to cancel the tasks that your team doesn't need after all.
You could process the updates for cancelled activities using manual data entry, dealing with logic, manhours, and baselines, but if you handle a lot of these it becomes time consuming, tedious and frustrating. Lets face it, during a Turnaround that is just not a good idea. You might think that dissolving is good enough, but is it?
On a previous assignment I worked on a 6 week turnaround project with 500,000 man-hours. After each shift update we needed to get Earned Value reports to management. It was hard enough completing updates within a 2 hour time period along with getting the next shift's reports out, but having to do full earned value was even harder.
The unexpected happens during a Turnaround project - Let TAPS help
“No battle plan survives contact with the enemy” - Helmuth von Moltke
When you are a scheduler on a Turnaround project you cannot expect everything to go as planned. Often at the end of your shift, when entering progress, you’ll find out something unexpected has happened in the schedule. For example, activities have been marked as completed while their predecessors are not yet started. There are different reasons for this:
- Was progress of the predecessor(s) missed?
- Were the progressed activities reported incorrectly?
- Has something changed in the activity’s logic?
How to Quickly and Effectively Develop S-Curves With Primavera P6 Project Data
I was working on TA project and was asked to provide S-Curve (Units and Cost) reporting for every morning management meeting. The client wanted to observe project trends from a schedule and cost perspective for each unit, piece of equipment and also for various contractors.
How the P6-Loader Makes Life Easy When Working With P6 Resource Assignments and Resource Dictionaries
Working with P6 resource assignments and resource dictionaries can be extremely time-consuming. The task becomes especially tedious when it comes to planning a turnaround project with multiple daily shifts and varying crew sizes on day and night shifts, or a capital project where you have rotating work shifts with crews overlapping on the back shift.
Adjusting Primavera P6 Settings and Structures with the P6-Loader
We recently had a support call from a client that started having performance issues with their P6 database during the pre-work phase of their turnaround. We looked at the Oracle 126.96.36.199 enterprise database and found a massive amount of archive logs being chewed up. In fact, it was on a scale of 1-2 GB of logs within 2-5 minutes on average. With that kind of volume it would not take long for a server to receive the dreaded Oracle error message ORA-00257: archiver error. When this happens the database usually needs more space on the device where the archive log files are stored, which results in the database not allowing any more transactions until the issue is corrected.
Working in the field is such an amazing and rewarding experience. I recently returned from a large turnaround project that was implemented by one of Emerald’s largest customers in Fort McMurray.
The proper management of resources on a turnaround project is vital to its success. Levelling functionality of Primavera P6 is heavily utilized by planners and schedulers to make sure the deadlines set by the turnaround (TA) management are met and resources are utilized in the optimum way.
A turnaround is a very large undertaking. The first and foremost priority must be safety. Always keeping that in mind, the team must address all aspects of the in scope (known work) as well as found work (which has the potential for a few surprises!). Scheduling of such an event is a must!