It's all about the answers!

Ask a question

represent a project in a RTC project area


jeff thomas (542528) | asked Jul 18 '14, 4:10 a.m.
For large organizations, if you create a rtc project area for every new project, there would be thousands of project areas to maintain.  If you store multiple projects in one rtc project areas, what's the best way to represent a project? using a category?  Using a team area?  What are the best practices?

Accepted answer


permanent link
Geoffrey Clemm (30.1k33035) | answered Jul 19 '14, 8:12 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
The term "project" is very ambiguous ... if by "project", you mean a group of people working together to produce one or more deliverables, then yes, you would create a team area for each new project.  On the other hand, if you consider each "release" of a product to be a separate project, then you would commonly create a single team area for that product, and schedule each release of the product for a specific iteration in the timeline of that team area.   In other words, focus your team area and category design on your "teams" that are doing the work (the purpose of "categories" is just to automatically route work items to the right team area).   And don't worry about accumulating a lot of team areas or categories ... just archive the ones you don't need anymore.   WRT who should own those streams and components, the primary purpose of ownership is defining access control.   So normally you either assign a stream/component to the project area (if everyone should be able to see/update the stream/component), or assign it to the team area (if only people on the team should be able to see/update the stream/component).
jeff thomas selected this answer as the correct answer

2 other answers



permanent link
N Z (3622127) | answered Jul 20 '14, 6:18 p.m.
A RTC project area is really a process definition. So the question is, can all your projects (however they are defined) share the same process template? Will the use the same work item types, workflows, approvals, fields, values, automation, access control, etc, etc. If so, then less RTC projects is better, and Geoff has summarised the situation well.

If however, there is some deviation between you projects in the way they work, for whatever reason, then they may not be able to share the same process/project area, and in these cases, they may need separate project areas. Hopefully, this is the exception rather than the norm, and some standards are enforceable.

permanent link
Georg Kellner (840378109) | answered Jul 18 '14, 4:44 a.m.
If we have several projects in one "project area" we use teams to separate them.

greetings georg.

Comments
jeff thomas commented Jul 19 '14, 5:20 p.m.

so you would create a team area for each new project?  And how do you use it?  Do you create a category for the new project so that work items can be filed against it?  Over time, wouldn't you accumulate a lot of categories and team areas?  You wouldn't make these team areas for projects own streams and components, right? Projects come and go.  Then who should own those streams and components?  Do you have teams areas set up for application teams as well?  If so, how do you use those two types of team areas together?  I'd love to see a scenario described for that.


Your answer


Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.