It's all about the answers!

Ask a question

Using Formal Project Management Process Template


Todd Goldstein (76119) | asked Jun 16 '11, 12:32 p.m.
retagged Jun 17 '13, 6:13 p.m. by Michael Prentice (622913)
I am looking to implement RTC for my PMO team using the Formal Project Management process template. I am looking for guidance on a best practice with the project area and/or team area setup. The 2 options I have are

1. Create a project area per project resulting in ~20 project areas
2. Create a single project area with team areas. Each team area would represent a unique project that someone on the team would run.

There are certain administrative requirements with both options and I'm hearing conflicting opinions as to which is a better overall setup. I'm looking for some concrete pros and cons.

Is anyone trying this?

9 answers



permanent link
Ralph Schoon (63.4k33646) | answered Jun 16 '11, 12:41 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
I am looking to implement RTC for my PMO team using the Formal Project Management process template. I am looking for guidance on a best practice with the project area and/or team area setup. The 2 options I have are

1. Create a project area per project resulting in ~20 project areas
2. Create a single project area with team areas. Each team area would represent a unique project that someone on the team would run.

There are certain administrative requirements with both options and I'm hearing conflicting opinions as to which is a better overall setup. I'm looking for some concrete pros and cons.

Is anyone trying this?


A rule of thumb I use is: create as few project areas as possible. Project areas have a bigger administrative overhead than team areas.

Drivers for project areas are:
- Different basic process templates e.g. need for different work item types. Team areas share the basic customization.
- Visibility of artifacts used to be a driver, but with RTC 3.0.1 this seems to be greatly reduced due to read access restrictions you can impose on work items and scm artifacts.

permanent link
Geoffrey Clemm (30.1k33035) | answered Jun 16 '11, 9:19 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
I would strongly suggest that if you are using 3.0.1, that you not
create multiple project areas in this case (i.e. when they are all using
the same process template), unless there is a more compelling reason to
do so than you have identified below. In particular, as Ralph
mentioned, in 3.0.1 you now can control read access to most artifacts
based on the team area, so separate project areas are no longer required
for most read access isolation use cases.

If you are using 2.0, that is a different situation, since read access
in 2.0 is only available at the project area level.

Cheers,
Geoff

On 6/16/2011 4:23 PM, ishibmjazz wrote:
We are on the same boat. We still have not decided.

I am an advocate for multiple projects, using the same template for
the reason of isolating the artifacts.

RTC should be made easy to use either way you configure it.
Does RTC 3.0 have this feature of access restrictions?

rschoonwrote:
I am looking to implement RTC for my
PMO team using the Formal Project Management process template. I am
looking for guidance on a best practice with the project area and/or
team area setup. The 2 options I have are

1. Create a project area per project resulting in ~20 project
areas
2. Create a single project area with team areas. Each team area
would represent a unique project that someone on the team would run.

There are certain administrative requirements with both options and
I'm hearing conflicting opinions as to which is a better overall
setup. I'm looking for some concrete pros and cons.

Is anyone trying this?

A rule of thumb I use is: create as few project areas as possible.
Project areas have a bigger administrative overhead than team areas.

Drivers for project areas are:
- Different basic process templates e.g. need for different work item
types. Team areas share the basic customization.
- Visibility of artifacts used to be a driver, but with RTC 3.0.1 this
seems to be greatly reduced due to read access restrictions you can
impose on work items and scm artifacts.


We are

permanent link
Todd Goldstein (76119) | answered Jun 17 '11, 8:35 a.m.
Sounds like a singe PA is the recommended approach.

From an administrative point of view, do I need to add users to both the project area and then the individual team area they are a part of or is it sufficient to simply add to the team area only and use the permissions there to govern their work?

permanent link
Ralph Schoon (63.4k33646) | answered Jun 17 '11, 8:49 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Sounds like a singe PA is the recommended approach.

From an administrative point of view, do I need to add users to both the project area and then the individual team area they are a part of or is it sufficient to simply add to the team area only and use the permissions there to govern their work?


Hi,

typically only users that require process area wide access would be added on project area level. The build user and the person owning/managing the project area e.g. the process would be on that level. Normal users would rather be added to the team(s) only.

permanent link
Sterling Ferguson-II (1.6k10288273) | answered Jun 17 '11, 9:39 a.m.
We have a fairly large department looking into this exact same thing. Is there a whitepaper/article about project/team area vs multiple projects v3.0.1+

permanent link
Todd Goldstein (76119) | answered Jul 25 '11, 10:35 a.m.
Hi - one problem I'm running into now with the single project area w/multiple team areas is the timeline. Each project has it's own start and stop and my team is struggling to come up with a standard timeline. I created a project timeline with a 6 year timeframe and then broke down year, quarter, month as a universal timeline and gave each PM the flexibility to plan at a high level or down to the monthly level.

After more testing and debate, I saw I was able to create multiple project timelines and as each team area is created, I can specify which timeline the team area is associate to.

What doesn't make sense is that any user can see the entire project area timeline values. The user experience I want is that you can only see the timeline value in the planned for field of a work item for the team area you are part of....similar to how you can restrict the category values in the filed against field.

Is this possible?

permanent link
Robin Parker (32633739) | answered Sep 27 '11, 6:26 a.m.
This is the exact question I currently have.

I have some teams that want all of their work items in a single iteration, some that want to work in quarterly iterations and some that want to work in fortnightly iterations.

I'm just trialling this in a repo on my laptop at the moment. I created a timeline and iteration hierarchy for each requirement above.

When working with the single iteration for example, I select a work item category which assigns the new task to a team on the 'Single' iteration. But then in the planned for field, I can select any iteration from the whole project.

I tried allocating the work item to a iteration on a different timeline from the team, just as an experiment. I could then not get it to show up in any plan (not surprisingly) so there seems a potential for losing work using this method.

Is this how this is supposed to work?

Many Thanks,

Robin

permanent link
Esmael Beydoun (31) | answered Jun 16 '11, 4:17 p.m.
We are on the same boat. We still have not decided.

I am an advocate for multiple projects, using the same template for the reason of isolating the artifacts.

RTC should be made easy to use either way you configure it.
Does RTC 3.0 have this feature of access restrictions?

I am looking to implement RTC for my PMO team using the Formal Project Management process template. I am looking for guidance on a best practice with the project area and/or team area setup. The 2 options I have are

1. Create a project area per project resulting in ~20 project areas
2. Create a single project area with team areas. Each team area would represent a unique project that someone on the team would run.

There are certain administrative requirements with both options and I'm hearing conflicting opinions as to which is a better overall setup. I'm looking for some concrete pros and cons.

Is anyone trying this?


A rule of thumb I use is: create as few project areas as possible. Project areas have a bigger administrative overhead than team areas.

Drivers for project areas are:
- Different basic process templates e.g. need for different work item types. Team areas share the basic customization.
- Visibility of artifacts used to be a driver, but with RTC 3.0.1 this seems to be greatly reduced due to read access restrictions you can impose on work items and scm artifacts.

We are

permanent link
Ralph Schoon (63.4k33646) | answered Jun 17 '11, 8:54 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
We are on the same boat. We still have not decided.

I am an advocate for multiple projects, using the same template for the reason of isolating the artifacts.

RTC should be made easy to use either way you configure it.
Does RTC 3.0 have this feature of access restrictions?



I think RTC is fairly easy either way. However a project area requires a bit more work since more information is required.

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.