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
, practice, and group (RPG) hierarchies. Data from project business records can roll-up to the project's RPG and up the RPG hierarchy. The same data can also roll-up the project 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 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 actuals 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.