Project Hierarchies

You can create a project hierarchy by associating a project with a parent project using the Parent Project field, in the same way that you create region A level of hierarchy used in PSA to which other objects belong such as resources, opportunities and projects., practice A level of hierarchy used in PSA to which other objects belong such as resources, opportunities and projects., and group A level of hierarchy used in PSA to which other objects belong such as resources, opportunities and projects. (RPG Abbreviation of region, practice, group.) hierarchies. Data from project business records can roll-up Term used to describe how a lower level figure or transaction is included in a higher level transaction or calculation. to the project's RPG and up the RPG hierarchy. The same data can also roll-up the project A collection of activities and related items to be managed over a defined time range, such as timecards, expenses, milestones and budgets. hierarchy.

Most projects do not have a parent project, so there is no hierarchy. In this case, the project stands alone. Business records for the project may affect the RPG actuals for the project's RPGs and RPG hierarchies. Business records for a project with no parent project only contribute to that project's actuals Totals for a given time period. and not to any other project's actuals.

If a project has a parent project, there is a project hierarchy. This is similar to a RPG hierarchy except that you can create more than one top-level parent project. A top-level parent project, which has the Master Project checkbox selected, is known as the master project. All child projects roll-up to their parent project in the hierarchy. A parent project therefore includes its own amounts and times plus the amounts and times from all child projects down the hierarchy. The master project includes its own amounts and times plus those from all the child projects in that project hierarchy. For information about creating a project hierarchy, see Creating a Child Project and Project Hierarchy.

Scheduled Backlog

Scheduled backlog behaves in a similar way, rolling-up the RPG hierarchies of projects, but also rolling separately up the project hierarchy if one exists.

For instance, if project 1 in the US East region has parent project 2 in the US West region, and both regions have the same parent region United States, the following happens regardless of project hierarchies:

• The US East region reflects actuals such as Bookings and Billings for project 1, as well as scheduled backlog.
• The US West region reflects actuals such as Bookings and Billings for project 2.
• Actuals and backlog for the United States region receive contributions from both regions.

The following happens due to the project hierarchy:

• Project 2 actuals and backlog receive contributions from Project 1 and Project 2.
• Project 1 actuals only receive contributions from Project 1.

Why Use a Project Hierarchy?

You can use project hierarchies to analyze a project's roll-ups as a whole and break up projects based on different attributes.

For example:

• You want to bill in two different currencies for the same overall project. For instance, if some of the work in a project is to be billed to the US division of a customer in USD and some is to be billed to the UK division in GBP.
• If you want different approvers for different parts of a project. For instance, if you turn the PSA trigger on to set the approver for business records such as timecards to be the user of the project manager's user, you can set different approvers for different parts of the project.
• Different parts of the same overall project belong to different regions, practices or groups. For instance, you could set up a master project with the region United States and then create child projects in regions such as UK, Germany or Japan. In this case, business records in the child projects contribute to the RPG Abbreviation of region, practice, group. actuals Totals for a given time period. of their regions and roll-up the RPG hierarchy from there and not to the United States region. Additionally, you may want billing to be in a different currency or want the child projects to be included in billing for their RPG.
  
  Note:

  In this case, project actuals in child projects still roll-up the project hierarchy. The master project contains the combined project actuals from every project in the hierarchy. The actuals in the master project are derived using dated exchange rates when necessary. Scheduled backlog rolls-up in a similar way, separately up the RPG hierarchies from the project hierarchy.
  
  If you change a project hierarchy, projects for which project actuals must be recalculated are flagged with the Actuals: Need Recalc checkbox.