Work organization by Portfolios (Projects) and Teams
Best practices to plan and assign work to projects and teams: one team – many projects, many projects – one team, etc.
In Targetprocess 3, you can organize your work using Portfolios (Projects) and Teams. You can have a single team that works on multiple portfolios or create a portfolio for a large project with several teams working on it. Targetprocess 3 has flexible features and supports various combinations of teams and portfolios.
The Team has a name, avatar, and a list of team members. When you create a new team, you can add people to the team from the pool of active licenses, or you can invite new people. In this case, a new user is created, and it will take one more active license.
Each project has a name, color, and a list of members. Users can be included in both teams and projects. While it is possible to work without teams, working without a project is not an option.
You can assign work, such as user stories, features, or bugs, to a project or assign it to one or more teams. When you start a new project, you can add user stories and features to the project backlog if you are unsure of the total number of teams. You can manage the specific assignment at a later time.
Teams, Projects, and Work VisibilitySome interesting questions may arise, such as: “OK, so I'm a member of the Alpha team, can I see all the projects related to the Alpha team? Can I create user stories in these projects?” Let me explain how it works.
Suppose, we have a project called “iOS App” and one related team — iOS Team. There are 4 cases to consider (blue shows conditions):
| Project Member | Team Member | iOS App Project access | iOS Team access | Work from Team access | Work from Project access |
| No | No | No | No | No | No |
| Yes | No | See | See | No | See, change |
| No | Yes | See | See | See, change | No |
| Yes | Yes | See | See | See, change | See, change |
A user needs to be assigned to both the Team and the Project to view all of the work. Do not assign a user to a project if you want to limit their access to only team-related tasks.
In the image below there are two teams that work on a single project. Let's say, Teddy is notassigned to the project but just assigned to Team Alpha. In this case, he will see just stories and bugs from Project X that are assigned to Team Alpha (left colored area):
Assume that two teams are working on a single project, Project X, as shown in the illustration below. User Teddy is assigned to team Alpha and not directly assigned to the project itself. As a result, he can only view stories and bugs from Project X that are assigned only to Team Alpha (shown in the left-colored area).
User Tom is assigned directly to Project X. Therefore, he can view all Project X-related stories and bugs.
Ensure that you assign a work item, such as a user story to a Project first and then allocate it to a team. You cannot create a work item without a project.
Add, Edit, and Delete Permissions
Permissions for users to add, edit, and delete entities in Targetprocess are granted based on multiple different settings: type of user account, selected roles, permission settings set per roles, ownership of work items, and assignments to work items. Find more details in the dedicated articles:
- Permissions for Access to Work Items
- How to give a user permission to create Projects, Programs, Teams or Users
Administration and Management
We describe how administrators and power users can manage Project and Team membership in multiple separate articles:
Additional Cases
In some cases, the users can view the entities that do not belong to the Projects and Teams they are members of. Here are the examples:
Service Desk
- Targetprocess users who are Creators or Requesters of a request can open it in a Service Desk, even if the request belongs to project or teams the users are not members of.
- When a request has outbound related items and the request is displayed in Service Desk, then on the detailed page of the request users see related items including numeric IDs, titles, current states even when the items belong to projects or teams the users are not members of.
Visual Reports
- When a Visual Report is configured by some user or Administrator, and the report owner shares the report with other users, then the viewers see data from the configured source such as projects and teams even when they are not members of some of the source projects or teams.
Tags
- When a tag is assigned to an entity in one of the projects or teams, then the tag appears as an available option in the auto-completion suggestions list for all the users in the system, including ones who are not members of the project or the team.
Externally Shared Views
- When a view or a dashboard is shared for external viewers then any person who knows the direct link can see everything displayed on the view. Neither membership in projects and teams nor an active Targetprocess user account is needed for such access. More information: Share View with external users.
Usage Hints and Best Practices
Imagine you're running a design studio called Go4. You have just one development team and many active projects.
It's time to nail down a serious thing. You work in a large company that has many teams and many projects. Sometimes one team works on a single project. Sometimes things are much more complex.