Sharing the process of a project area

Edit online

After you create a project area, you can make its process available to other project areas. By sharing a project area process, you can ensure that all project areas across your organization use the same process. You also centralize process maintenance.

When you create a project area, you must specify a process template that will be used to define the initial process for the project area, even if you plan to have that project area use the process from another project area. After you create a project area, you can modify it so that it uses the process from another project area.
Note: For Change and Configuration Management and Quality Management project areas, you should use the Unconfigured Process template to create a project area that will consume process from another project area because that template does not configure any process on its own. Using a template that defines its own process causes the project area that consumes process to override the process it is consuming, which is not usually the behavior that you want.
Note: The inherited settings are not shown in the project area editor of the consuming project area, but they are used at run time.

A project area that consumes the shared process from another project area does not inherit all process elements. The following elements are inherited:

  • Configuration data (applies to Change and Configuration Management and Quality Management only)
  • Iteration types
  • Operation preconditions and follow-up actions (applies to Change and Configuration Management and Quality Management only)
  • Permissions
  • Roles
The following elements are not inherited:
  • Administrators
  • Members and their role assignments
  • Process description
  • Project area artifacts, such as:
    • work items
    • plans
    • plan views
    • reports
    • report folders structure
    • test cases
    • files under source control
  • Project area links
  • Releases
  • Timelines and iterations
  • Work item category associations (applies to Change and Configuration Management and Quality Management only)
Tip: It is a good practice to avoid using the sharing project area as a production project area. The sole purpose of the sharing project area should be to provide process for the consuming project areas. If you store production data, such as work items and plans, in the sharing project area, you might need to customize that project area in ways that make it difficult for consumer project areas to re-use the process.

Allowing project areas and team areas to override process settings

By default, project areas, and child team areas, that consume the process of another project area can customize process settings. However, as project administrator of the sharing project area, you can control which settings can be overridden. For example, in the figure below, the Save Work Item permission setting is selected and Final (ignore customization of this operation in child areas) is selected. In this example, project administrators of consuming project areas and team areas cannot restrict this role from performing Save Work Item operations; although the project administrators can make changes in the editor of the consuming project area, the changes are ignored at run-time.

This picture is a screen capture of the Permissions tab of the project area editor, which shows a checkbox for specifying that child project areas and team areas cannot override the permission setting of the selected action.

Limitations of customizing configuration data

If you customize configuration data in a project area that consumes the process of another project area, all of the configuration data for that category is copied from the sharing project area to the consumer project area, and the consumer project area no longer inherits any of the configuration data for that category. For example, the figure below shows the categories of work items configuration data in the IBM® Engineering Workflow Management (EWM) client for Eclipse IDE. If you customize the Types and Attributes configuration data in the consumer project area, that consumer project area no longer inherits any of the Types and Attributes configuration data from the sharing project area. Unless you are certain that you do not want to inherit any of the data for a configuration data category, do not make any changes to that category of configuration data in the consuming project area.

Screen capture of the Configuration Data section of the project area Process Configuration tab in the EWM client for Eclipse IDE. The Work Items node is expanded, and the Types and Attributes category is selected.
Note: If you add a custom work item attribute to the sharing project area, you must update existing work items so that they contain the new custom attribute. You must also update work items in the consuming project area. For details, see Updating work items with new or modified attributes.

Changing and upgrading the process

A key benefit of using a shared project area is that changes that you make to the process of the sharing project area immediately apply to the project areas and team areas that consume that process. You can change the process for all project areas by configuring the process in the sharing project area. In addition, when a new version of the process template that the sharing project area uses becomes available, you need only update the sharing project area with the new template. In this way, you can control the upgrade of all project areas across your organization from one sharing project area. Consuming project areas and team areas that have customized some process settings retain those customized settings.

Restrictions

The following restrictions apply when using shared project areas:

  • Project areas that share their process cannot configure process for iterations because iterations are not shared.
  • If you configure process for a project area’s timelines or iterations, you cannot make that project area’s process shareable.
  • Project areas that share their process must be visible to all members of the consuming project areas. Therefore, if you restrict read access to the sharing project area, members of the consuming project areas can still access the sharing project area.
  • You can modify a project area that consumes shared process from another project area so that it consumes shared process from a different project area. However, you cannot modify that project area so that it uses a template instead of a process for a shared project area.
  • A project area can share its process or can consume the process of another project area, but it cannot do both.