Are EPS Level Activity Codes Worth the Hassle?

EPS level activity codes can be created in Primavera P6 to be available to projects under a designated EPS. While this can help with the amount of activity codes at the Global level, you may want to carefully consider whether you want to add activity codes at the EPS level, as they can pose problems for you down the line.

We once had a client who wanted to reorganize their business units. This client had EPS codes for different business unit EPS nodes. When they altered their business unit structure and started moving projects from one EPS to another, we found that instead of moving the EPS codes under the new EPS, P6 was demoting those codes down to the project level. This maintained the code assignment in the project, but did not make the new code available to other users in the new EPS. To maintain those EPS codes at that level, the activity codes need to be created in the new EPS node and those values reassigned to each of the new projects. That is a lot of work for what should be a painless copy and paste.

Another problem that arose after reassigning the EPS codes to the newly created ones under the proper EPS, is that all the layouts and filters that referenced the original EPS codes were now “broken”. This required going into each layout and filter where the old code was referenced and replacing it with the newly created EPS code. Yet another time consuming task.

We also worked on a project for a client where we combined three databases into one shared database. Their EPS structure was set up to accommodate the cleanup and security for the new database. When the projects with EPS codes were imported to the new EPS structure, we ran across the same issue of the EPS codes being demoted to the project level, even though we had created the new EPS level codes prior to importing the projects. The P6 import process does not recognize the existing EPS codes as a match to the newly created EPS codes, since the EPS structure name was not the same. This client had thousands of project level layouts that referenced the original EPS code, which now not only needed to be updated in the projects, but in the layouts that referenced the original EPS code. Their layouts included many references in their chart settings to the EPS codes assigning colors based on the filter in the chart. Since there were so many layouts that would have been broken, we ultimately used a copy of the original database with the EPS codes as the basis for the new database, but it took many hours of research to come to this conclusion.

Unfortunately, promoting EPS codes to the Global level will land you in the same situation of reassigning the EPS codes and fixing the layouts, so this is not an ideal solution, either.

The moral of the story is to be careful when you decide to use EPS level activity codes. It may seem like a good idea, but consider what the implications could be down the road if those codes need to be moved. Ultimately, we recommend not using EPS level activity codes. Make the activity codes Global and save yourself the headache later on if anything changes with your EPS.

A secondary, but just as important lesson that we learned from this was to not make your layouts project level layouts if you use them across multiple projects. We discovered the same layout and filter definitions in several hundred projects, which exponentially increased the number of layouts that required “fixing” when data elements were changed. You can change the data element while a layout is open and it will update the currently applied layout, but will not update any other layouts with the same elements.