It's all about the answers!

Ask a question

one rtc project area for all projects

rushikesh sawant (1133) | asked Nov 07 '12, 1:56 a.m.

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

permanent link
Ralph Schoon (60.9k33643) | answered Nov 07 '12, 2:38 a.m.
How to split projects in RTC needs some considerations. The basic questions from off the top of my head are:

  • Do you need different processes,especially different work item types and attributes?
  • Do you need to restrict access to artifacts such as work items?

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.

rushikesh sawant commented Nov 07 '12, 3:17 a.m.

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

permanent link
Ralph Schoon (60.9k33643) | answered Nov 07 '12, 3:40 a.m.
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.

Ralph Schoon commented Nov 07 '12, 3:41 a.m. | edited Nov 07 '12, 3:41 a.m.

To have multiple projects but share a common process look at the results of this search:

permanent link
Dinesh Kumar B (4.1k413) | answered Nov 07 '12, 3:47 a.m.
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

Register or to post your answer.