Answered by:
Where Project Management Data Lives; Native Sharepoint Sites Versus Project Server and Related Project Sites

Question
-
Project Server Forum,
I have a client that is concerned that data in the Project Sites is "captive" (i.e. only accessible to someone with a CAL). They have existing Sharepoint sites that are currently used for Project Management information--and widely accessible to employees. These two things (i.e. Project Sites and native Sharepoint Sites) seem to live in two different worlds--having a wall between them. (I do understand that Project Sites can share some things (e.g. webparts) with other sites, site collections and farms. But data movement is more restrictive in the other direction, as you need a CAL to access the Project Site.)
My own view is that--for Project Server to be effective--all operational-level project management information from throughout the enterprise (i.e. even the native Sharepoint sites) needs to get pulled into Project Server. It could be that high-level information about projects (i.e. strategic-level information) may continue to properly reside in Executive Information Systems (possible fed by Project Server)--and some of these may be native Sharepoint sites.
I am wondering how others have addressed this issue (i.e. how to reconcile existing Sharepoint sites having PM information with the existence of Project Sites--only accessible to those having a CAL). Any case studies, white papers, anecdotal information will be appreciated.
The central issue, I think, is "where does operational-level project management data live?" Is it only in Project Server? Can some continue to live in native Sharepoint sites? (The answer, undoubtedly, is "only in Project Server"--but I want to see what creative ideas others have implemented to deal with this issue.)
Ed
Dr. Edward M. Hanna, PMP President Data Express, Inc. Irvine, CA emhanna@sbcglobal.netWednesday, September 1, 2010 7:12 PM
Answers
-
The solution I've typically seen for something like this is to create a fullon project website using SharePoint functionality and templates, then adda tab at the top to point to a secondary site provisioned with Project ServerWebparts. Only folks who are assigned specific tasks or need to review theGantt would then have access to that tab.- Andrew Lavinsky
- Proposed as answer by Marc Soester [MVP] Thursday, September 2, 2010 4:32 AM
- Marked as answer by Christophe FiessingerMicrosoft employee Thursday, September 2, 2010 2:34 PM
Wednesday, September 1, 2010 8:01 PM
All replies
-
The solution I've typically seen for something like this is to create a fullon project website using SharePoint functionality and templates, then adda tab at the top to point to a secondary site provisioned with Project ServerWebparts. Only folks who are assigned specific tasks or need to review theGantt would then have access to that tab.- Andrew Lavinsky
- Proposed as answer by Marc Soester [MVP] Thursday, September 2, 2010 4:32 AM
- Marked as answer by Christophe FiessingerMicrosoft employee Thursday, September 2, 2010 2:34 PM
Wednesday, September 1, 2010 8:01 PM -
I like your approach Andrew, which is the easiest way to manage it.
Edward, you can also denie access to certain Sharepoint / Project Server Web parts. That means that your users which are not Proejct SErver users can access the Project site but cant see "Risks, Issues, Deliverables etc". If you need them to see the Risks and Issues you will need to make them Project Server users since these are the special Webparts. If a user that is not a Project Server user accesses the lists ,they will get an accesss denied message. If you can life with this than you can simply add the users to your Project Site using the normal SharePoint approach.
Hope this helps
Marc Soester [MVP] http://marcsoester.blogspot.comThursday, September 2, 2010 4:35 AM