Subprojects

Subprojects are only available in classic projects. If you convert to an EPP project type, subprojects are converted to summary activities

Subprojects are useful to break down a large project or program into separate pieces that may be managed by and executed by separate teams.

There are a number of limitations in how Windchill handles subproject relationships. It is essential to understand the relationship of plan information in a subproject to parent projects or programs to determine how you can take best advantage of the benefits of a subproject.

From a project or program space or context view, all projects or programs are peers. That is, there is no sharing or inheritance of teams, folders, documents or parts, action items, meetings, resources, or access rights between a parent and any related subprojects.

The only relationship between a project or program and a subproject is through the plan. A node in the parent plan may identify a subproject relationship with the top-level plan node in another project or program.

Plan status, percentage complete, effort, and cost are calculated from the child plan to the subproject plan object in the parent plan to which the child plan is linked.

Precedence relationships cannot be established such that changes in the parent plan propagate down to the child. For example, a propagated change in start dates in the parent plan cannot influence the start date of the child plan. Propagation only occurs from child to the parent. For example, if the child estimated finish date is pushed out and the parent plan includes a precedence constraint on the subproject plan object, then those activities in the parent plan that follow the completion of the child plan cannot start until the child plan is completed.

The child project or program must exist before it can be linked. But you can define a subproject in the parent to act as a placeholder until you are ready to link the child.

If you need to create dependency relationships between parent plan elements and child plan elements, it is best to define and manage the entire plan in the parent. In this case, while no plan is created in the child project or program, it is used as a focused collaboration space with a unique team, folders, action items, and possibly deliverables. A project or program manager in the child space can also be defined in the parent space and can be given responsibility for defining, executing, and editing a portion of the plan in the parent (representing what might have been defined in the child).

You can manage a large plan by assigning responsibility for each node in the parent master plan to the project or program manager of a subproject. The project or program manager can define a hyperlink in the subproject to the plan node in the parent project or program and just expand that node and edit the key plan objects under that node.