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, Emerald being 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 (SR).

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, Emerald being 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 (SR).

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.

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.

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.

In P6, identifying which projects are using each Activity Code in a quick, consolidated, easy to use manner is challenging. Especially when you consider some clients have a LOT of baselines.

But is this is r-e-a-l-l-y information we need to be able to capture? In my experience, there are a number of scenarios where that answer is a resounding “Yes”! One common example – the Activity Codes Dictionary needs to be cleaned up.

When you are working on a project and you move from Project into Support, sometimes it is hard to decide the exact cutoff point for the project team to start charging to the new support project. I had a problem the other day where I needed to decide the end date and cut over. The client selected a date a few weeks before we had thought we were going to cut it off after she checked her budgets and we realized we were going to go over.

So I had to go back to look through the timesheets we had submitted in Team Member to get the time reallocated before sending it into our QuickBooks where we invoice from.