Best Practices for Project Areas
Hi everyone -
This is a pretty fundamental question. How many project areas should we have?
I've seen answers ranging from it depending on the client, to the number of different "processes" are available.
We're using GCM, RQM, and RM, and plan to use this system for nearly 13 different teams. How do we plot our course in the most effective way possible. Are there any resources you can point me to that demonstrate how this is done effectively?
Thanks!
Accepted answer
Hi David,
Unfortunately there's not a formula; it does depend on a number of factors including:
-
# of artifacts the project will contain: over a certain threshold, performance can decline. Performance sizing guides are available on the deployment wiki. Also consider potential for growth and longevity.
-
Access permissions: read access is at the project level (all members of a project can read all that project's content). If you need to restrict read access, that suggests a separate project with its own membership.
-
Process similarities: if teams/projects have radically different processes, they might need their own project area. There is some flexibility to accommodate variance with e.g. multiple workflows, different artifact types or attributes/values.
-
Administration overhead: generally, fewer projects means less admin (adding users, roles, managing process-related items, etc). But sometimes you need more projects to address the factors above.
You mention GCM, so I assume you're using configuration management. That means you can also have multiple components within a single project area, which is another consideration in your project "topology". This article on component strategy discusses some of the decision points related to components.
Are you or your organization already working with anyone from IBM? Adopting GCM comes with a lot of decision points. I'd be happy to chat with you about your plans.
Comments
