Using Formal Project Management Process Template
Todd Goldstein (76●11●9)
| asked Jun 16 '11, 12:32 p.m.
retagged Jun 17 '13, 6:13 p.m. by Michael Prentice (62●2●9●13)
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
Ralph Schoon (63.5k●3●36●46)
| 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 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. |
Geoffrey Clemm (30.1k●3●30●35)
| 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. |
|
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? |
|
Ralph Schoon (63.5k●3●36●46)
| answered Jun 17 '11, 8:49 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Sounds like a singe PA is the recommended approach. 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. |
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+
|
|
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? |
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 |
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 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 |
|
Ralph Schoon (63.5k●3●36●46)
| 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 think RTC is fairly easy either way. However a project area requires a bit more work since more information is required. |
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.