Documenting Projects in Confluence

[Martin James]

Within our organisation we could be running 65 projects or more at one time. Each project should contain their own decision logs, sprints, meeting notes, project scope, action logs, support document, etc...

Is it best to create a space for each project or is it better to list every project into a single space?

If we are to list every project into a single space I can see this quickly getting out of hand if our teams want to start giving their documents the same title. I can also see decision logs and meeting notes conflicting with each other. At the same time if we are to create a space for each project, this will overload our system with more spaces.

What do you think is the best solution?

[Robert Reiner _smartics_]

I'd recommend a space per project.

The number of pages will be the same, so we are only talking about the number of first level entry points to the wiki. You can label spaces to organize them and you could add additional pages as entry points for different audiences.

Spaces are handy if you for instance need to archive them, limit searches, or add access rights.

[Nic Brough -Adaptavist-]

I agree with Robert, a space per project is most manageable.  Your users will understand it, as the concept is intuitive and enables them to think and see things in terms of "this project".  They're natural containers for projects in most cases.

I would not wory about having too many spaces.  Confluence handles it fine, as do users.  I've seen well performing Confluence systems which work great for the users with thousands of project spaces and then hundreds more spaces for non-project stuff. 

[Brent]

I've found that smaller projects are burdensome to require their individual Space.  It gives people far too many places to look to find information.  We've found a balance between project size and Confluence Spaces.  Thus, if I was managing 65 projects, perhaps only 30 would have their own space while the other 35 "small" projects would be under a more generic, category-driven, or team-centric Spaces.

[Josie Belliard]

In my opinion, if you create unnecessary spaces, it becomes harder to manage everything. If you use macros you will be able to create a friendly interface for your users. I think the only problem wih Confluence when building large projects is the menu. To compensate for the shortcomings of the navigation capabilities provided by confluence you could by a macro menu, but it can get expensive if you have a large group (each seat pays the fee). On the other hand, if you decide to do it in CSS you might run into other problems, such as security.

[Jonathan Smith]

Martin,

  We have about 60+ active projects in our IT environment. Each is it's own space.

The most important part of these projects is the project status section on the home pages. We wrap this table with the page properties macro so the content will display elsewhere in a nice project dashboard.

Having 60+ projects in one space is do-able, but it would be a page restriction nightmare.

Cheers!

[Kathy Adams]

I'd be interested in what your dashboard tracks and what it looks like.  Is it the widgets from Jira?

[Jonathan Smith]

@Kathy Adams 

  All of our projects are in Confluence currently.

Since we want to keep the table's formatting, it was decided to wrap the table with the excerpt macro, then use the "excerpt include macro" on a project dashboard page. The excerpt include would look for a specific tag within all of the projects and pull in those tables.

This might not be the best method, but it was the best solution at the time for our needs.

[Jonathan Smith]

I know this is an old post, but good to keep it up to date :)

Here is another method of tracking sprints / phases in project spaces.

Wrap page properties macro around both project status tables (if multiple). Page properties report would then expose both tables.

Rename title to Project on page properties report page.