Best Practices for Project Areas

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.