The first thing I always say is:
Don't let the term "project area" cause you to map each of your projects into their own project area. In particular, whenever you see "project area", think "process area", i.e. the place where you define a common process for a set of teams. So unless teams need:
- their plans and work items to be readable only by that team, or
- their own set of custom work item types,
put them all in one project area.

So if a project shouldn't be mapped to a project area, what should it be mapped to? The most common answer is "a plan item" (e.g., an epoch or a story work item). The next most common answer is "a team area".

If each of your projects have a distinct set of people, and you want to plan at the project level (e.g. you want to say things like "Tim works 20% on project X and 30% on project Y), then you'll probably want to have a separate team area for each project.

But more commonly, you have a set of people that work on several projects, and you want to orchestrate the work of that set of people as a single plan (so that people don't allocate a particular amount of their time for a given project, but rather float their time between projects as needed to get all their projects done), then I would model that set of people as a "team", and then create a "project" work item type (inheriting from either "epoch" or "story"). Note that an epoch reports on the progress of its child stories, and a story reports on the progress of its child tasks, so you can track the progress of the "project". Also note that in this case, a team outlasts a single project, with team members being added and removed, and is archived only when that team is fully disbanded.

So in general, when your are modeling your work in Team Concert, decide what are your plans and sub-plans, and make those be teams and sub-teams.

WRT categories, their purpose is to automatically direct work to the right team. So you'll need at least one category per team, and starting with just the names of the teams is simplest.If your stakeholders (that submit requests) aren't familiar with your team naming conventions, rename the categories based on concepts that are more familiar to your stakeholders (and you are always free to define multiple categories that map to the same team). In the case
above where you have a given team work on several projects, if your stakeholders are more familiar with projects than teams, then a good approach is to have a category for each project, and then map the each category to the team that is responsible for that project.