It's all about the answers!

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

×42,886
×12,013

question asked: Aug 22 '13, 2:52 a.m.
question was seen: 4,884 times
last updated: Aug 30 '13, 10:54 a.m.

Related questions

How do I set up my project and team areas if every team contributes to every project?

0
Karsten Angstmann (73●1●2●7) | asked Aug 22 '13, 2:52 a.m.
converted to question Aug 23 '13, 1:40 a.m. by Geoffrey Clemm (30.1k●3●30●35)
In question https://jazz.net/forum/questions/61929 it is recommended to use a single project area with a team area for each team.  I would absolutely agree to that recommendation if I can bring all this in ONE hierachy, meaning I have "n" projects consisting of "m" teams each with "o" team members working for that project.

However we have the problem that there is no such clear assignment of persons to projects. For us it is "n" projects and "m" teams, and each team contributing to almost every project.
So it is unclear for me how I could get this n:m relation into a hierarchy in a single project area.

Karsten




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

Can you outline how you handle this situation currently ?   In particular, how does each team figure out what it's work will be for a given iteration?

Karsten Angstmann commented Aug 23 '13, 10:01 a.m.

Unfortunately not much help there.
Currently we only have the "projects side" in Clearquest - with basically a flat list of projects each containing tons of tasks assigned to various individuals.
The teams themselves use a totally unconnected (well, manually synchronized) planning - like single MS project plans etc.
As you can image this is only partially successful in producing a reliable planning. :-/

Karsten Angstmann commented Aug 23 '13, 10:13 a.m.

Hi Geoff,
after some thinking about that, we currently favor some approach like that:


So we would mostly use two project areas:

  • one to hold the project hierarchy - containing mostly plan items (change requests, defects, ...).
  • one to hold the team hierarchy that is responsible for the components that are re-used in all projects - containing basically tasks.

Both are then connected via tracks links.

So far we are quite unsure of the consequences of this - any hints?

Accepted answer

2
permanent link
Geoffrey Clemm (30.1k●3●30●35) | answered Aug 23 '13, 1:00 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
I do not (yet) see any need for two project areas for this ... just create both your Planning Projects and Implementation Projects in a single project area.   This maximizes your ability to share information between the planning teams and the implementation teams.

The way I recommend for deciding how to lay out your RTC project area is to answer the question I raised above, namely, "how do you want a team figure out what work it is going to be doing for the next iteration".   The layout of your project area will follow from your answer to that question. 

For example, one approach for your scenario would be to have each project planning team identify the set of prioritized features they want for its next release (as Story work items, for example).  This would be done in the project planning team areas, and the stories would be filed against the appropriate planning project.  Then to break those stories down into high level tasks that would need to be performed, set the priority of those tasks to be the priority of the parent story, and file those tasks against the appropriate implementation team area.  An implementation team team then has a backlog of tasks.  Each implementation team would then size the high priority tasks, and then identify the set of tasks they think they can get done for their next iteration based on their current capacity.   At this point, there would probably need to be some negotiation between the various project planning teams once they see which of their desired features would be completed (the result of those negotiations would be modifications to the feature/task priorities, resulting in a rework of the implementation team plans).   In addition, there could be negotiations around adjustments to the number of people assigned to each implementation team, which affects how many tasks can be completed by a given implementation team, which in turn affects when a given feature will be available.

Once you have the process defined, you will then be able to identify what kinds of reports, queries, and plans you will use for your planning/development process, which then can be mapped to the planning and implementation team areas.

Karsten Angstmann selected this answer as the correct answer
Comments
Karsten Angstmann commented Aug 26 '13, 3:23 a.m.

Thanks Geoff for that extensive answer. Yes, this is general procedure I also see.

Regarding the "one project area" still two things trouble me:

  1. If I have so many (100+) independently planned "projects" inside one project area, I fear the categories list to assign items to individual "projects" will be so large that it will be quite uncomfortable to use.
  2. I would assume that the "planning projects" and "implementation projects" would have several unique work items, e.g. "customer change requests" only for the "planning projects". Doing that seems easier in two project areas.


Karsten Angstmann commented Aug 26 '13, 3:24 a.m.

"how do you want a team figure out what work it is going to be doing for the next iteration"
Good question: If I consider that:

  • if the answer is "pull", that means that the implementation teams have to "scan" the "planning projects", than I absolutely see the benefit of all in one project area.
  • if the answer is "push", that means the planning projects actively "request" work from the "implementation teams", then they normally do not need to look into the "planning projects" themselfs, so having one project area for the easier overall view is less necessary.

1
Georg Kellner commented Aug 26 '13, 6:02 a.m.

Hi Karsten,

regarding the 100+ categories:
You can use the dependent lists.
1st category Platform or Customer
2nd catgegory ACME or Funny if it is a customer project, low line if it is a platform project.

greetings georg.

Karsten Angstmann commented Aug 26 '13, 7:36 a.m.

Thanks Georg,
this sounds exactly what I want to do, however I quite new with RTC, so can you direct me to some more detailed explanation how to do that?
Thanks, Karsten

sam detweiler commented Aug 26 '13, 8:07 a.m.

Geoff, can u please explain this wording?

" do not (yet) see any need for two project areas for this ... just create both your Planning Projects and Implementation Projects in a single project area.   This maximizes your ability to share information between the planning teams and the implementation teams."

how do you do that?  I don't think you create mutiple projects in a project area.
you can create teams, categories, plans..  but projects?

Geoffrey Clemm commented Aug 26 '13, 10:55 p.m. | edited Aug 26 '13, 10:55 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

WRT Sam's comment, there is no artifact called a "project" in RTC, primarily because the term "project" is commonly used in software development to refer to very different concepts.  For example, an Eclipse or Visual Studio "project" would be instantiated as part of an RTC component, while a Microsoft Project "project" would be instantiated as an RTC plan.  The "projects" being discussed in this question would be RTC team areas,  so what I said could be rephrased "just create both your Planning Project team areas and Implementation Project team areas in a single project area".
WRT Karsten's comments:
(1) To see how to create nested categories in the Eclipse client, see 2.a. in:
https://pic.dhe.ibm.com/infocenter/clmhelp/v4r0m3/index.jsp?re=1&topic=/com.ibm.team.workitem.doc/topics/t_defining_categories.html
To see how to create nested categories in the Web client, see 3.a in:
https://pic.dhe.ibm.com/infocenter/clmhelp/v4r0m3/index.jsp?re=1&topic=/com.ibm.team.workitem.doc/topics/t_defining_categories_web.html
(2) WRT work item types that are used by one role and not the other, it is true that you can filter that list by project area if there is a separate project area for each role, but this (relatively minor) benefit is usually for outweighed by the admin cost of maintaining the common work item types in both project areas, and the barriers introduced by separating the teams into different project areas.

Karsten Angstmann commented Aug 27 '13, 2:16 a.m.

Thanks Geoff,
we will try this nesting immediately.
Karsten

Ratheesh Madathil commented Aug 27 '13, 10:44 a.m.

Hello Geoffrey,

I dont know whether this is exactly we meant with it. We know in fact to create a nested category. But Karsten point was all this category (whether nester or not) will later then appear as a single big list for users (while creating a work item).

The link you provided did not give any hints on that. i.e in the first field I get the top level heirarchy of teams (planning, implimentation), after selecting the value in the first field we get the second field value populated with the sub-categories of the one above (i.e. categories coming under planning for e.g.)

Thanks.

sam detweiler commented Aug 27 '13, 10:58 a.m.

yes, that is one of the issues with using a single team area definition tree in a single RTC project area structure. All project area authorized users will see the entire team area list

Karsten Angstmann commented Aug 27 '13, 11:28 a.m.

Hello Sam,
thanks for that confirmation. Assuming not two as in the picture but e.g. 100 individual "planning projects" this would then be an hint to split this into more than one project area.

regards, Karsten

sam detweiler commented Aug 27 '13, 11:32 a.m.

correct.. but that leads u back to the original issue.. same set of people working on multiple discreetly labeled work projects, but you want to minimize the context switching the users have to do. (and reporting, and work finding, allocation assignments, allocation consumption, and ... the list goes on).

Geoffrey Clemm commented Aug 27 '13, 10:01 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

As a developer, for work item submission, I always use the Eclipse client, which just shows the top level categories, and allows you to expand the category you select to view the sub-categories.  We need the web client to provide equivalent functionality, as requested in Make display of 'Filed Against' field contents in Web UI similar to Eclipse UI (66768).  I've added a comment to that work item, but anyone who agrees should feel free to add a comment indicating their interest/support.  Until this is implemented, I agree this is an annoyance for the web work item submitter, but as Sam says, the downsides of multiple projects probably outweighs this annoyance.

Karsten Angstmann commented Aug 28 '13, 2:28 a.m.

Hi Sam,
So that more or less leads me back to my picture:

  • the people working on the planning projects almost exclusively work for one customer (e.g. ACME), so there having a separate or even multiple project areas would "only" be an administrative problem to keep the process template in sync etc.
  • the people on the implementation side (distinct from the planning persons) work "shared", so that should be definitively all in one project area.

regards, Karsten

Karsten Angstmann commented Aug 28 '13, 2:34 a.m.

Hi Geoff,
I personally also prefer Eclipse :-). But we have to consider many hardware developers, project managers etc., for those it is the Webclient. And telling them "sorry, but it is better for the SW developers" will not give good karma. ;-)
I added our support to the CR.

So to sum up I would use the strategy:

  1. Prio A: Avoid project context switching for the users, all a single user works on should be in one project area.
  2. Prio B: Balance having as few project areas as possible (to reduce administrative overhead) against having enough to keep the categories manageable.
regards, Karsten

Henning Sternkicker commented Aug 28 '13, 5:54 a.m. | edited Aug 28 '13, 5:57 a.m.
JAZZ DEVELOPER

I strongly recommend to not create a separate Project Area for your real life projects. I have already seen a RTC implementation where they tried to do this and it is an administrative overhead that you do not want to have.
I always see a project area in RTC as the place where I can host my real life projects. Unfortunately there is no "project" handle then, but in RTC it is a combination of iterations, plans, teams and categories, that needs to be well configured.
Before setting up a project area I always recommend to start with setting up a new team area in RTC together with a corresponding category and, if necessary, with a separate timeline, so that you are really able to separate the work items.
If you have "small" projects, something that could be handled in a handful of work items and in a timeframe that is smaller than your iterations, you can also think of building a "project" structure with the work items. Use one of the plan work item types to be the high level "project" item and add other plan and execution items as the child structure. You can see than all of these projects items on one single plan.

Karsten Angstmann commented Aug 30 '13, 10:52 a.m.

Hello Henning,
also an interesting approach, unfortunately our projects are "many" but not "small" :-)

But I will definitively follow the advice "not create a separate Project Area for your real life projects". I really like Geoff's statement there "we should have called it process area" :-).
So we will either use only one or at most two project areas and then a hierarchy of team areas and support the RTC Change Requests to make some of the drop downs more scaleable.

regards, Karsten

Karsten Angstmann commented Aug 30 '13, 10:54 a.m.

At all,
thanks a lot for this discussion and the many helpful insights!

regards, Karsten

showing 5 of 17 show 12 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.