locked
Where Project Management Data Lives; Native Sharepoint Sites Versus Project Server and Related Project Sites RRS feed

  • 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.net
    Wednesday, September 1, 2010 7:12 PM

Answers

  • The solution I've typically seen for something like this is to create a full
    on project website using SharePoint functionality and templates, then add
    a tab at the top to point to a secondary site provisioned with Project Server
    Webparts. Only folks who are assigned specific tasks or need to review the
    Gantt would then have access to that tab.
     
    - Andrew Lavinsky
     
     
    Wednesday, September 1, 2010 8:01 PM

All replies

  • The solution I've typically seen for something like this is to create a full
    on project website using SharePoint functionality and templates, then add
    a tab at the top to point to a secondary site provisioned with Project Server
    Webparts. Only folks who are assigned specific tasks or need to review the
    Gantt would then have access to that tab.
     
    - Andrew Lavinsky
     
     
    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.com
    Thursday, September 2, 2010 4:35 AM
  • I think I've done something similar, and I got errors on the page when they
    tried to access. The Project Details Webpart as I recall. Then again, I
    didn't security trim the specific Webpart - it happened when non-PWA users
    tried to hit the site.
     
     
    - Andrew Lavinsky
     
     
    Thursday, September 2, 2010 6:04 PM