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.

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.

Ideas in Oracle Prime:

Use Oracle Prime to create ideas: capture, evaluate, and process the ideas for new initiatives and business endeavors.

Ideas are processed using a submission and approval workflow. Prime Projects provides a default workflow for processing ideas, or you can create a customized workflow. First the idea creator creates an idea and specifies the idea's business case. When an idea contains sufficient information, the creator can submit the idea for further processing by routers and owners.

Manually wading through a schedule and looking for errors is time consuming and prone to human error. Not only that, it's boring. No one wants to do it, but you need to check your schedule for errors!

Even worse then working through your own schedule for errors, is slogging through a contractor's. When you don't know how they have built the schedule, it can take days to make sure things hold together. Some of our clients have several layouts, reports and even special access databases and outside tools to do this which is very time consuming, error prone and boring.

We have all experienced at one point or another how tedious (and time consuming) setting or changing resource availability can be in the P6 resource dictionary. Particularly for an example like the one we will walk through where you are setting up or adjusting turnaround resources and the weekend rule happens to be ½ crews.

P6-Loader can ease the pain of these types of tasks.

You are correct; out-of-the-box P6 does not calculate Earned Value (EV) at the resource assignment level. It only runs EV at the activity level which is fine for a start, but what to do when you need to 'dig deeper' and analyze crew performance? You can't use Global Change to calculate the resource assignment EV because the activity percent complete isn't available in the Global Change list of fields.

A very simple option is to use TAPS to input your schedule updates. TAPS is P6 updating using barcodes (plus additional functionality). By using TAPS, updates are faster and more accurate giving you (and your team) more time for schedule analysis. Yes, TAPS runs EV calculations at the resource level.

When you have a large number of users in your P6 database, it is surprising how quickly that database can get “clogged up” with a lot of unwanted data. This happens even when using Sandbox databases, restricting privileges and every other trick you have thought of; long time P6 users know what I am talking about.

This is part 2 of a series of blogs discussing best practices of P6 archiving. In Part 1 we discussed the question of time:

• How long should you keep a P6 project file?
• How do you track the date to archive your P6 project?

Now we will discuss the question of location.

We get asked on a regular basis what the best way to archive P6 data is.

1. How long should a project file be kept?
2. What should be done with the project files when that time period has expired?
3. Where should they be kept?
4. How can we retrieve if we need them, especially with upgrades?

In this blog series, we’ll look at some of the options available to a P6 user and discuss the question of time.

When working with resources in Primavera P6 Web version 16.x on, there is a new twist: the need to publish data. If you are trying to analyze resources and the following message displays, it's time to publish.

Over the last few years I have worked with many clients on turnaround projects in remote trailers on job sites that didn't have great connectivity. Now I am no techie, so I cannot pinpoint what causes the problem, but I know there is a problem when the coffee maker is the busiest place in the trailer. Now I am talking trailer coffee here folks, that stuff is gut rot at the best of times. If the planning team is hanging around, it is because they have been kicked out of Primavera P6 again!

In the current economy the mere suggestion of financial spends to address system issues are something that will elicit gasps, face palms and shocked facial expressions, let alone a few choice words. But during one of these “extended coffee breaks” I did some number crunching out of curiosity on what the downtime costs really were.