It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Guidelines | FAQ
Follow this question
Question details

×42,886

question asked: Aug 22 '11, 12:12 p.m.
question was seen: 9,950 times
last updated: Aug 23 '13, 1:42 a.m.

Related questions

Best Practice: Project Areas Vs Team Areas

2
Vinay Kumar AV (179●3●38●37) | asked Aug 22 '11, 12:12 p.m.
Hi all

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.

Approach A: Having a Common Project Area (Portfolio) with sub projects to meet the various initiatives of the account. The sub-projects to be implemented by Team Areas and sub-teams of Team Areas in the RTC repository.

Approach B: Having multiple project areas with a few team areas working towards a common goal of the project.

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

Most liked answers ↑|Newest answers|Oldest answers

2
permanent link
Geoffrey Clemm (30.1k●3●30●35) | answered Aug 22 '11, 1:53 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
edited Aug 20 '13, 6:59 p.m.
I recommend thinking of a project area as "a place where projects live"
(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
1
Vinay Kumar AV commented Aug 23 '11, 9:47 a.m. | edited Aug 20 '13, 7:00 p.m.

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
Geoffrey Clemm commented Aug 23 '11, 2:49 p.m. | edited Aug 21 '13, 10:57 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

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
Jirong Hu commented Dec 16 '11, 4:39 p.m. | edited Aug 20 '13, 7:02 p.m.

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
Geoffrey Clemm commented Dec 16 '11, 5:53 p.m. | edited Aug 20 '13, 7:07 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

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
Susan Hanson commented Aug 20 '13, 9:26 p.m.

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

Ratheesh Madathil commented Aug 21 '13, 12:18 p.m.

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"?.

Geoffrey Clemm commented Aug 21 '13, 11:54 p.m. | edited Aug 21 '13, 11:56 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

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.

Geoffrey Clemm commented Aug 23 '13, 1:42 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

Note: I have moved Karsten's comment to be a separate question: https://jazz.net/forum/questions/124321

showing 5 of 8 show 3 more comments

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.