Best practice for programs of projects?

[anovak]

We've setup a "program" that consists of a master (blank) project and
the 4 projects that make up the program. There are a total of 5
workspaces, with the master showing the rollup of all 4 projects.

What is best practice for utilizing the workspaces - put everything in
the master and differentiate between the various projects using an
attribute or drop everything into each individual workspace?

Until I hear a different and better way to go, I settled on the later
due to reporting concerns. If you add a custom field to the Issues
list to filter the items by project area, it is not propagated to the
reporting database. To me, you would want to populate content in
each separate project workspace so you could use the master/sub
relationships / project names to produce a segregated SQL Reporting
Services report. Otherwise, you couldn't.

It makes no sense to me be able to see all issues in the master
online, yet NOT be able to produce a report from the reporting
database that contains all of them, grouping accordingly. I'm
encouraging everyone to place content in the Master ONLY if they are
global in nature and impact the entire program.

Is this best practice or some other method?

Thanks,
Andy Novak
UNT

 

[Andrew Lavinsky]

You might also look into using content types for risks and issues in the
program. Then you can aggregate them at the master in SharePoint using the
Content Query Webpart - or some custom code.

 

[anovak]

You might also look into using content types for risks and issues in the
program.  Then you can aggregate them at the master in SharePoint usingthe
Content Query Webpart - or some custom code.

All in all, I'm trying to keep it simple "out of the box" without
programming. I figure if it is possible to provision a workspace as
a sub of the program, then utilizing each sub's workspace is the way
to go.