Planning project areas

Edit online

Before you create a project area, you must consider and make several design decisions about it.

Whether to create a lifecycle project

A project area defines the process that developers follow as they work on a software project. You access all project artifacts, such as plans, work items, requirements, test cases, and files under source control within the context of a project area or one of its team areas.

A lifecycle project groups multiple project areas and provides a central location from which you can manage members of the project areas. A lifecycle project also establishes associations between its project areas so that you can link artifacts across those project areas. For example, in a lifecycle project that contains a Requirements Management (RM) project area, a Change and Configuration Management (CCM) project area, and a Quality Management (QM) project area, you can link requirements to the work items that track the work required to implement the requirements, and you can link the requirements and the work items to the test cases that test the implementation.

If you are creating project areas in multiple applications, and you want to link artifacts across those project areas, consider creating a lifecycle project. For details, see Administering lifecycle projects.

Which process template to use

When you create a project area, you must select a process template, which specifies the details of the process that the project area will use. For example, a process template defines the user roles, timelines, iterations, operation behavior, and work item types. Each application includes predefined templates. You can also create new templates and customized versions of existing templates. However, creating process templates is an advanced task. To start working immediately, it is easier to create a project area that is based on a predefined template. You can then customize the process within the project area. See the following topics for descriptions of the predefined templates:

Which timelines and iterations to create

A timeline represents a path of development work that has its own schedule, deliverables, and team areas. Within a timeline, you typically create a hierarchy of iterations where top-level iterations represent releases and child iterations represent milestones within those releases. You can customize the process in each iteration. A mature project might have the following timelines:
  • Main development: For each major release (Version 1.0, Version 2.0, and so on)
  • Maintenance: For updates to major releases (Version 1.0.1, Version 1.0.2, and so on)
  • Exploratory: For early work on potential future releases

For details about creating timelines and iterations, see Creating timelines, iterations, and iteration types.

Whether to create team areas

Team areas are optional. A few developers working on a small project can do all their work within the context of the project area. For projects of moderate or high complexity, team areas provide the following benefits:
  • Process customization: Team areas inherit the process from their project areas; however, each team area can customize its process.
  • Membership: You can assign users as members of specific team areas. Within each team area, you assign roles to members. In this sense, team areas can mirror your organization’s team areas.
  • Participation in a specific timeline: Each timeline has its own set of iterations and schedule. You might have different teams working on different timelines. For example, one group of developers might work on a new release of the product while another group works on a maintenance release of the product. You can have separate team areas for each of those timelines.
  • Individual work item categories: The Filed Against field in the work item editor is populated with the set of work item categories that you define for a project area. You can map work item categories to team areas. This mapping enables work items to be assigned to the specific team that is responsible for addressing them.
  • Individual dashboards: Team leads can add widgets to their team dashboards that display the results of various work item queries. Teams can then refer to the dashboard in scrum meetings to monitor their progress.
  • Ownership of source control streams and components. Every stream and component has an owner, which can be the project area or a team area. You can use ownership to limit visibility and access to streams, components, and their artifacts to members of the owning team area.
  • Nesting. You can create a hierarchy of team areas. Just as a top-level team area inherits the process of its project area, a team area in a team area hierarchy inherits the process of its parent team area. Team area hierarchies can be useful in an enterprise environment where different parts of the enterprise follow different processes.

For details about creating and using team areas, see Creating team areas and associating work item categories.

Which roles to assign to users

When you add a user as a member of a project area or team area, you assign the user one or more roles. Each role is assigned permissions, which determine which operations the user can perform within the context of the project area or team area. The initial set of roles for a project area is derived from the process template that you use to create the project area. For example, the IBM® Engineering Workflow Management (EWM) Scrum template includes the Product Owner, Scrum Master, Team Member, and Stakeholder roles. Team areas inherit the set of roles available in the project area. You can define new roles in the project area or in team areas.

Before you add users to the project area or a team area, familiarize yourself with the permissions assigned to each role. In addition to the process roles, you can assign members of a project area or team area to be Administrators. Administrators are typically responsible for managing the process of a project area or team area, and they have permission to save all changes to the project area or team area.

For details about roles and permissions, see Adding and modifying roles and permissions and Adding and modifying users as members of project areas and team areas.

Whether to assign users to the project area or to team areas

In general, assign users to the area that owns the artifacts that they need to work on. For most users, that will be one or more team areas. For users who are team leads or project leads, assign them to the level of the hierarchy that they oversee.
Note: A user who is assigned to a role in a project area has the permissions associated with that role in the project area and in its child team areas, even if the user is not a member of those child areas. For example, a user who has the Team Member role for a project area has the permissions associated with the Team Member role in all child team areas of that project area.

How to configure read-access control settings

Within a project area, you can control who has read access to the project area, its team areas, and its artifacts, such as work items, iteration plans, test plans, requirements, builds, and files under source control. You can allow access to all users in the repository, or you can limit access to users who are members of the project area hierarchy, meaning the project area or one of its team areas. You can also allow access to only specific users.

In addition, you can restrict access to work items and source control artifacts as follows:

  • You can configure each work item category to be visible to only members of the corresponding team area. You can also configure each category so that work items filed against the category are accessible to only members of the associated team.
  • You can limit access to a stream and components to users who are members of the team area that owns the stream and components.
  • You can limit access to specific work items and source control artifacts to members of an access control list, which you define. The access control list can contain specific users, members of specific team areas, and members of the project area.

For details about using all of these read-access controls, see Restricting read access to project areas, team areas, and artifacts and Tutorial: Control access to project areas and their artifacts.

Which operation behavior (preconditions and follow-up actions) to set to enforce best practices

Operation behavior consists of preconditions and follow-up actions that you set for user operations. Preconditions are conditions that must be met before an operation can be completed. Follow-up actions are events that are generated when an operation is completed. Operation behavior is one mechanism by which you can enforce best practices within your project areas and team areas. IBM Engineering Test Management (ETM) and EWM contain predefined preconditions and follow-up actions, and you can also define your own. For example, you can set the following preconditions:
  • Change sets cannot be delivered if they contain compilation errors
  • Change sets cannot be delivered unless they are associated with work items
  • Test cases with failing results cannot be saved unless they are associated with a defect

You can set preconditions and follow-up actions differently based on role.

For the full list of predefined EWM preconditions and follow-up actions, see Operation preconditions and follow-up actions.

For the full list of predefined ETM preconditions and follow-up actions, see Preconditions for quality management.

Whether to customize permissions and operation behavior for specific iterations

By default, the permissions and operation behavior settings that you specify in the project area apply for all time periods. However, you can customize these settings for each iteration. A good practice among development teams is to apply tighter governance towards the end of a release. For example, you might want to restrict deliveries based on role, or require that change sets be reviewed and approved before they can be delivered.

For details about customizing permissions for a specific iteration, see Customizing permissions for a specific time period.

For details about customizing operation behavior for a specific iteration, see Copying configurations.

Whether to create associations with other project areas

An association is a relationship between two project areas, or between a project area and another artifact container, such as an IBM Rational® ClearQuest® database. After you add an association between two project areas, you can link artifacts across those project areas. For example, you can link requirements in an RM project area to work items in a CCM project area, and you can link requirements and work items to test cases in a QM project area.

If you have not created project areas, and you know that you want to enable this type of artifact linking, consider creating a lifecycle project. When you create a lifecycle project, you select a lifecycle project template that specifies the project areas to create as part of the lifecycle project. The lifecycle project template also specifies the associations to create between those project areas.

For details about adding associations to project areas, see Adding associations.

Whether to share the project area process

In an enterprise environment where you have many project areas, you might want all project areas to follow the same process. One way to accomplish this goal is to identify one project area as the master project area where the common process is maintained. To do this, you modify the project area to indicate that it shares its process. For all other project areas, you indicate that they consume the process of the master, or sharing, project area. Thereafter, changes that you make to the process of the sharing project area become effective for the consumer project areas. In this way, you can centralize process, and the maintenance of that process, in one project area.

Just as team areas can override process settings that they inherit from their project areas, consumer project areas can override the process settings that they inherit from their sharing project areas. Within the sharing project area, you can specify that certain process settings cannot be overridden. This ability means that you can control the amount of process customization for the consumer project areas.

The consumer project areas do not inherit all aspects of process from the sharing project area. For the full list of inherited process elements, and additional details about sharing project area process, see Sharing the process of a project area and Tutorial: Standardize process in your organization by using project area process sharing.