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).

The Cloud is a remarkable and innovative tool. It connects people from around the world, allows us to share fun vacation pictures and adorable videos of our pets, and offers a massive network that can process any and all data under the sun.

But as anyone who's ever had to use the back end of a Cloud program can tell you, it can quickly get complicated, leading to far too many headaches and sleepless nights trying to figure out what's going wrong. We could tell many horror stories about hours spent hunched over our computers just begging our systems to work the way we want - and I bet you could too!

So when one of our clients approached us looking to evaluate their options with Cloud software, we knew how they felt. At the time, they had been using on-premise servers, but were looking to upgrade to a database with more features at a reasonable price. They had considered Software as a Service (SaaS), but found the price of such an upgrade to be too steep to be a realistic option.

Luckily, we had previously agonized over the same decision and were able to offer our personal server in the Cloud; EAI hosted by OVH, as an alternative with a much lower price than the SaaS system Oracle offered.

Our client was also in sore need of maintenance services. Before they came to us, they had been operating, maintaining, and repairing their own cloud servers with only a handful of IT specialists who were unfamiliar with Primavera to begin with. As you can imagine it was slow, frustrating work, and when things broke down it could be days before they got everything up and running again. So when we suggested the EAI server, they were quick to take advantage of our services.

Now that they've moved to EAI, our client is able to enjoy the benefits of Cloud without the hassle that comes with sustaining their database. Emerald Associates handles the maintenance, repair, and operation of EAI, and offers on-sight visits and training for our client's entire team so that they will have the familiarity with Primavera that is so crucial in today's business environment. We have been working together with this particular client for the past 3 to 4 years now to keep their servers in the Cloud running smoothly and efficiently, giving them the freedom to spend their time and energy on what really matters - their business.

We've all worked with frustrating, outdated software. It's a pain to try and get everything to work the way you want it to, and the task is usually just too important or time-sensitive to take a break from. Everyone knows where that leads - yelling, cursing, or just slouching down in your chair in defeat, bested by technology once again.

When I first started working with our new client, I started out as a general trainer for the company’s employees. Our work began with typical P6 stuff, nothing new or especially exciting, but it was the start of a longer, more involved relationship with our client. I started helping them with turnarounds back in 2013 and I've been doing turnarounds with them every year since. I recently finished my 6th turnaround with the company - an 11-12 week long process that honestly felt a lot longer than it was. Due to a problem organizing the order of units, we ran overtime, and that was unfortunately just one of the many issues we had to deal with during that turnaround.

As is often the case, a good amount of the complications we faced were unintentionally self-inflicted. Our client runs under an alliance contract umbrella with another organization that controls their project management and general processes. This organization had decided to do a major upgrade to P6 just a few weeks ahead of the turnaround execution. This naturally caused a lot of complications, as the workers involved in the turnaround had to do a lot of scrambling to figure out the bugs in the untested upgrades while simultaneously dealing with the turnaround itself, which was no easy task. On top of this, the upgrade to P6 wasn't just a standard upgrade - it was a move from version 6.2 to version 17, which is a big jump on any given day, but right before a turnaround... It was disastrous. There were all sorts of issues, including considerable trouble upon first-log in, and it created a lot of stress - way more than even on the typical turnaround! Units were in shutdown, people were pulling 12 and a half hour long shifts, the site was an hour away from where most of the personnel were stationed, IT issues were causing immense frustration - it seemed like everything that could go wrong did.

Now, I've been in quite a few panicked, rushed environments over my 8 years of turnaround assistance, and this could easily have been one of them, but luckily the majority of the schedulers dealt with it very well, keeping their heads despite the setbacks we faced. And as for me - I went in with my usual mentality: get it done. So despite the constant uphill battle, we managed to pull everything together and get through the turnaround with our sanity intact. Overall, it wasn't the easiest turnaround I've ever been a part of, but complications are part of the job, and I'm happy to say that another yearly turnaround with our client went by successfully - if maybe a little bumpier than usual!

Before becoming an implementation specialist at Emerald Associates, I was a project manager and P6 administrator in a state government transportation agency for several years. I was responsible for managing 50-60 Primavera P6-EPPM (Web) project schedules and monitoring them to schedule completion. These projects were for the engineering and design of highway projects including tasks such as road maintenance, new road construction, bridge maintenance, and signals upgrades.

We have been using P6 v18.x with several clients and have seen some differing behavior related to caching. It appears the problem may have started as early as P6 v16.x. These clients are in varying environments; P6 Oracle SaaS, EAI Hosted, and on-premise - In short, anywhere where Oracle Cloud Connect is utilized.

We were excited to see the new form of caching that appeared in v17.x. We have clients with poor internet access and P6Web is not adequate for their needs - they need P6 Client. Everyone knows that P6 Client is very chatty and needs good bandwidth to work properly, so the idea that we can cache data and do heavy lifting on our desktop rather than on the server far away was great.

Remember our good old friend the POBS Table? Well, we have a new friend in town that is introducing itself to our database in the form of the RISKTYPE table. We have discovered numerous clients are importing XER files to their database that include a large number of Risk Categories, sometimes tens of thousands of them. No one knows where they originated, but they are multiplying and wreaking havoc.

The problem comes when an export file is created with unwanted Risk Types and imported into another database, creating more values in the destination database. The destination database then could share their large number of Risk Types to another database. Each time, the RISKTYPE table is passed along, it grows, spreading and infecting more and more databases.

Are you importing schedules into scrubbing databases, taking out all the unwanted data you don't want to pollute your production database, re-exporting the schedule and then importing it into the database where it should have gone in the first place?

Do you have required specifications your contractors need to follow for their schedules, but have a hard time knowing whether those details are missing or incorrect until you've already imported them?

Do you want to ensure you are not importing POBS tables and corrupted RISKTYPE tables?

That's a lot of quality assurance to do! Maintaining your corporate data standards for dashboarding and reporting can be a full time job, especially when project teams have their own coding structures and requirements for their P6 Environment.

Don't worry; there's relief. Emerald has developed a new tool that will do all that work for you! We are now introducing P6-Scrubber.

Are you finding when you are importing or exporting a large number of projects that not all the projects are coming across when they are imported?

While converting a client from P6 V8.3 to V15.2, we found the data was not always transferred completely when we migrated large numbers of projects. Instead, with XER file sizes larger than 100,000 KB not all projects were exported and/or imported. We confirmed this recently on a subsequent project with a different client where we were migrating projects from P6 V7.3 to V17.12 and encountered the same issue.

In the first case, we exported the projects using an XER. Our file was over 300,000 KB. We found 4-5 projects were not exported. When we imported the same file, there were 2-3 additional projects that were not imported to the new database.

We looked at additional files for the same client and found that in XER files with a size larger than approximately 100,000 KB there were several projects in each XER missing when the file was imported.

Once we reduced the number of projects in the exported XER files to keep the file size under 100,000 KB, we found no projects were lost and our data was accurate.

Keep an eye on XER files larger than 100,000 KB when importing and exporting, they may not have complete data in them once they are imported.

While working on a turnaround project where our client was using our EP-datawarehouse and EP-dashboard tools for the first time, we were already showing them green up reports, inspection summary reports, performance curves and productivity curves, but had been tweaking them to fit their needs during the turnaround, which was quite beneficial to their team.

I was providing assistance to the turnaround team and started entering Additional Work Requests (AWR’s) as they came in from the AWR manager. The process required several steps during its life and we found a dashboard would be helpful in keeping track of the process, since we were getting questions about where AWR's were in the process. An AWR entered the process when it was received from the field personnel, assigned a number and entered into a master spreadsheet by the AWR manager. The spreadsheet listed several pieces of information, but the information we needed for the dashboard was the AWR#, Date Submitted, Approval Status, and the Description.

Using Resource Codes has been very helpful on many Turnarounds. Often on a Turnaround (or any large project) you need to report resource availability and requirements in your schedule by Craft (trade) and Company.

But that is often not the way the resource dictionary hierarchy is set up? And you likely are not able to do anything about that since the Administrator probably controls that.

When updates are done from remote locations, it is sometimes hard to know if the scope of work is on track or not. In P6, we have the idea of variances against a baseline, but sometimes it is even more practical to compare variances against the current schedule or the last update.

Wondering how exactly? After your updates have been entered into your schedule, run the P6-QA Tool. This tool performs many checks, including one to track Activities Completed Late.