i’ve always had difficulty explaining the concept of global and project data to new users of primavera p6 in my training courses. it’s a bit too much for some, and why should you even care? you seem to be able to use primavera p6 just fine without any knowledge of global or project data.
you can, but you can also get into trouble once you start moving data around, especially back and forth between databases. if you’ve ever sent or received a primavera p6 .xer file then this guide is for you. it will help you to make sure your primavera p6 project data is making it to it’s destination when you send a file. but it’s also good knowledge to have for any user of primavera p6 professional or eppm.
primavera p6 global & project data
it’s important to remember that primavera p6 was initially designed as an enterprise project management system. even though many of us use primavera p6 as a standalone tool, shunning all of the enterprise bells and whistles, at it’s core is a database initially designed for the enterprise’s needs. if primavera p6 was truly a standalone tool, you’d find it to resemble a tool like microsoft project, where you deal with files only and projects don’t share data between them.
primavera p6, both the professional version and eppm, have a more complex data structure that enables them to be in the realm of enterprise software tools. the goal was to design a system that could be used by an organization’s many departments. so it would have to be flexible enough to be configurable for each department’s needs. but also, the organization would want some over-arching corporate assets that could be set up and available to any department.
with primavera p6, a primary enterprise distinction is that we have this concept of “global” data objects and “project” (or embedded) data objects.
if you consider that any company that sets up primavera p6 will want to reuse and share data objects across their p6 projects, then you have just revealed the difference between global and project objects. global objects can be shared and used on more than one project, while embedded objects cannot.
primavera’s global objects are linked and not embedded in projects
going a bit deeper, we encounter how global data objects are actually shared by multiple projects – it’s a concept i call “linking”. by the way, these concepts exist everywhere in databases, and are not unique to primavera p6….just sayin’.
global objects are p6 constructs that are used on or linked in to a project, but never wholly become part of the project. for example, a global calendar exists in p6’s database where it can be shared and used on multiple projects. thus, a global calendar gets linked to a project and used on activities in that project, but the calendar never becomes wholly owned by the project nor is it embedded inside the project.
the same concept always applies to 世界杯时间比赛时间 . a resource can be assigned to a project’s activities, but the resource (and it’s associated attributes, like price/unit hourly rate) are never embedded into a project. that same resource can always be assigned to the activities of another project at the same time, applying the linking concept or the sharing of 世界杯时间比赛时间 across projects.
when you start to thing about all of the many global objects that can be linked to a large project, the list starts to look like this:
- global calendars
- cost accounts
- global activity codes
- project codes
- 世界杯时间比赛时间
- roles
- shift calendar
- user defined fields
- etc.
qualities of global objects is summarized in this list :
- global objects can be used on the activities of multiple projects.
- global objects exist outside of all projects.
- global objects are not deleted when their associated project(s) are deleted.
- global objects can be left out during an import process.
it’s import to understand primavera p6’s innate data linking concept because it comes into play in a major way when you export and import projects through .xer files. more on that soon.
what is an embedded (project) object?
some of the data objects in the list above can also be created as a “project” object. let’s look at calendars again. a calendar in p6 can be created either as a global calendar (shareable on other projects) or a project calendar, which then becomes embedded inside the project you use it on. project calendars can’t be shared or used on other projects. no embedded object can.
other examples include project layouts or activity codes. here again, you have the option to create either a global activity code, or a project activity code.
embedded object are wholly owned by the project. embedded objects in a project has these qualities:
- embedded objects cannot be used or linked to another project’s activities.
- embedded objects exists only inside the project and can be edited only when the project is open.
- embedded objects are deleted along with the project.
- embedded objects are always imported with the project and cannot be left out.
exporting and importing primavera p6 global objects
this where things can get messy.
if i want to export a project to an .xer or .xml file, and ensure you have a complete record of the project, then during the export, all the bits of linked global objects have to come along for the ride. and that’s why happens. included inside the .xer/.xml file are all of the global 世界杯时间比赛时间 , calendars, activity codes, cost accounts, etc. that are used in the project. so we now have a combination of global data objects and project data objects in the same file. this isn’t really a problem on its own, as during the export this all happens automatically and there is no way to alter what data goes into an export file from primavera p6 professional (well, there is this…).
however, it’s on the importing of data from a .xer or .xml file that many users usually run into trouble.
and that will be the topic of my next post in this series. read the next post now.
i always appreciate comments or opinions on anything i’ve written here. use the comment section below and start a discussion.
