Best Practice: Project Areas Vs Team Areas
We have an account adopting CLM with Rational Team Concert 3.0.1 as a start. This account will have around 60+ project teams with 700+ users. What would be the best practice on setting up project areas and team areas.
Which of the above two approaches is advisable? Do we have any documents/articles that talk of best practices to be followed for project area setup. Thanks in advance!!
Thanks & Regards
Vinay
One answer
(not as "a place where a single project lives"). Probably a "process
area" would have been a better name, since the main point of a project
area is to define a general process shared by all of the teams working
in that project area (but where a team can customize various aspects of
that process to more closely match their needs).
So I'd recommend Approach A, unless there are good reasons to have
multiple project areas, such as that some projects have a significantly
different process, which cannot be modeled in RTC just as a customized
variant of a shared process.
Cheers,
Geoff
Comments
Thanks Geoff for your reply. My concerns on using multiple Team Areas over Project Areas were as below:
1. Process Template Changes can get tricky as all projects share the same process template in a single project area.
2. Any damage to the process template could impact all projects using the same project area with multiple team areas,
3. Adding new roles to suit specific projects in future can be tough as they share the project area with other projects.
4. User management can become be cumbersome in maintaining a single project area.
Would it be fine to use multi team area single project area approach with the above concern that I have? Please correct me.
Thanks & Regards
Vinay
1 vote
A terminological note ... the process defined in a project area is called the "Process Configuration". A "Process Template" is something else (it is an "exported" form of the process configuration, that can be used to initialize the process configuration of a new project area).
1. The most common problem is for different teams to unnecessarily diverge in their Process Configuration, which makes it hard for those teams to communicate/understand each others process state. In particular, you cannot easily create a custom query that spans multiple project areas. Having one shared Process Configuration avoids that problem.
2. Each revision of the Process Configuration is stored by RTC. So you can easily roll back to the previous version of the Process Configuration (with a few exceptions, such as icon definitions).
3. A team area can add custom roles for just that team area ... this doesn't have to be done at the project area level.
4. What part of user management becomes harder with a single project area? Most user management is done at the team area level, not the project area level.
1 vote
Come back to this question. I am using approach A right now, e.g. all our Curam based application are in one project area. They share the same formal project management process.
Now for the timeline, does the following make sense to you?
CIVRS and Curam are two independent projects. I create two teams in the project area. They work in their own schedules.
And in this case, what does "project timeline" (currently set to "CIVRS Main Development") mean? I mean actually they both run in parallel.
https://jazz.net/forums/viewtopic.php?t=21422&highlight=project+timeline
<img:940c14a668>http://i44.tinypic.com/sy845s.png</img:940c14a668>
1 vote
In your case, the only real meaning for the project timeline is that it is the timeline that a new top level team area is initialized to refer to.
Cheers,
Geoff
1 vote
We've been having this conversation for a set of projects. There are pros and cons to each ...We find doing process configuration at a team to be error prone. As well, my understanding is that the work item definitions/workflows are at a project area. If one team wants to have their own custom work item or add custom attributes, they go to ALL teams in the project area, even if not used.
When discussing this with some people, to make it easy I try to think of it this way: do you want to live in the same house, or just be neighbors? If you live in the same house, you share certain things, the washing machine, the stove/oven, and there are certain things you can configure on your own (the color of the walls in your bedroom). But if someone decides to change the stove, everyone in the house is affected. If you want some amount of isolation, different project areas on the same server/repository can assist. Work items can still fairly-easily be moved around. Queries tend to remain within the project area, so that means teams don't have to do alot of weird things to isolate down to their own work items.
Susan
1 vote
Hello Geoff,
We have almost the same context like mentioned in the question above.
We are trying to set this up for a product division of about 500 people. The basics about project area and team are was read through the blogs already. Project normally has planning people (project coordinators with OEM) and implimention teams. Implimention team consists of people from software, hardware, applciation etc...but situated world wide.
Each of this above team requires different kind of information, there for different fields in the workitem.
We currently think about having the "Plan" area for each OEM as seperate "Project area" and "implimentation" area for each discipline mentioned above also as different project areas. Under these of course we need team area for different functions.
But then definitely need "cross-project" plan so that the planning guys can track the progress from implimentions.
What is your opinion on this? Is that can be still optimised to one "project area"?.
Ratheesh: Yes, I would strongly recommend trying hard to use a single project area for both the planners and the implementers of a project. Information flow between the planners and the implementers should be the highest priority.
If the planners and implementers have some very different information they want to track, then you can create different work item types for them in the shared project area. But try to minimize the number of work item types, and try to minimize the number of fields in a work item type. I often recommend just starting with one of the out-of-the-box process templates, and only start adding fields once you've actually used it for a few months (or at least, weeks).
Susan: ... I strongly recommend not reasoning from analogy (we're building software, not living in a house :-). My experience is that the biggest problem in a software project is lack of effective communication and collaboration, not lack of isolation.
Note: I have moved Karsten's comment to be a separate question: https://jazz.net/forum/questions/124321