one rtc project area for all projects
![]() we have 2 different projects to migrate to RTC , so Is it good to have all projects in one umbrella or should we create different project area based on business units?
|
3 answers
![]()
Ralph Schoon (63.3k●3●36●46)
| answered Nov 07 '12, 2:38 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
How to split projects in RTC needs some considerations. The basic questions from off the top of my head are:
If you answer one of the two with yes, you should look into having separate project areas. If not, then you could probably get away with having more than one project area. You could use Teams within the project area instead.
In general, separate project areas are needed for separate processes so far.
Another consideration would be, are the projects working on the same general thing? If they do, I would not split along the lines of business unit, but rather on the line of what they work on.
Comments Thanks for you quick reply. basically these 2 applications are from our team itself likewise we have other teams too in our dept with there applications/projects to migrate. so by considering 8-10 different applications under one project area what problems we might face in the future? whether it should come under one project area?what need to be taken care? can you please explain. waiting for your reply |
![]()
Ralph Schoon (63.3k●3●36●46)
| answered Nov 07 '12, 3:40 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
I think an answer in the forum in this, without knowing more and talk about things is probably impossible.
There is no right or wrong, there are only tradeoffs. For example it is hard to change the decision later. It is probably easier to move data into another project (split) then moving from several to one. Both approaches will require a lot of manual work, for example moving work items from one project to another. In general you will need streams and components for all the teams for the different applications. The more applications the more you have of these. You will need timelines for teams with different release cycles. All users in this project area will see these. You can change ownership and visibility on streams to limit visibility. In general all work item customization will be common, including enumeration values etc. At some point it might become too much information. You could probably "split" projects then, but, as already mentioned, that is a manual process (move work items). The issue of splitting is always the tradeoff of saving administrative overhead versus how "agile" teams/projects are in terms of administration of their process. Comments ![]() FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
To have multiple projects but share a common process look at the results of this search: https://jazz.net/search_results.jsp?q=process+sharing#page=0&type=type%3DDocument-LibraryItem&q=process%2Bsharing
|
![]()
i second Ralph's inputs. the primary question is if the other teams also follow the same process? if yes, you could create individual team areas under the one larger umbrella called project area.
also to consider are what kind of actions the teams perform and how they would like to visualize their data and go about the daily activities. the dashboards, reports might have to be created accordingly from futuristic aspects, the user load and especially the concurrent users might be a big question to answer. if your teams are small a common project area should suffice and if you expect to have bigger teams, separate project areas will be useful for administration and maintenance. you might want to refer to the sizing guide which gives very good idea about the performance based on the different load conditions. |
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.