It’s a rite of passage within every Project Server implementation.  At some point, I sit down with the SharePoint administrator and brief them on what it is exactly that they’ve gotten into it – what exactly they’ll be supporting going forward.  Sometimes it’s part of the demo process.  Sometimes it comes much later.  Here’s the discussion in written form.

Top ten things a SharePoint Administrator should know about Project Server 2010 (in no special order):

1) Project Server schedule data resides in an additional 4 databases for each instance of PWA provisioned.  These databases need to be included in your disaster recovery plan, and are accessible from the Central Administration Farm Backup page.  Collaboration content is stored in your SharePoint content database.  A full backup/restore plan will need to accommodate all 5 databases – more if you plan on deploying multiple Project Server instances.  Note also that search will natively index any site based content, but will require the configuration of External Content Types to index the Project Server databases.

2) Despite its name, the Project Web Application is a site collection.  PWA is the top level site in the site collection.  However, PWA should never be the top level site collection within a Web App.  There should always be a top level site collection within the Web App, even if it’s a simple team site with security blocking anyone from accessing it.

3) The security structure within PWA is separate from the SharePoint security structure. Project Server maintains its own pool of users, which may be drawn from AD or other authentication mechanisms.  That pool is managed in its own interface.  This pool controls access to the main PWA site, and may be used to drive security on the individual project collaboration sites (see the next point).

4) Each project creation event may/may not provision a collaboration site (depending on the Project Server configuration).  The project collaboration site is essentially a plain old team site with the Project Server feature activated.  That site may be hosted within the PWA site collection or, with some configuration, outside of the PWA site collection.  Security on these sites may be automatically managed from within Project Server or that linkage may be turned off and replaced with a traditional SharePoint security model in cases where the organization has policies requiring AD-based security on SharePoint sites.  The same governance discussion that took place around your original farm needs to take place around these sites, i.e. disaster recovery and document retention policies, particularly as these sites are often intended to be transitory sites that get decommissioned at the end of the project.

5) Project collaboration sites may be edited within specific limits.  Most organizations decide to customize the default project site template – which indeed can be mapped to specific project types for the automatic provision of differently branded sites.  Content types do not come provisioned by default but may be easily implemented within the project site.  Four lists/libraries are provisioned as part of the Project Server feature: Deliverables, Issues, Risks and Project Documents.  Those entities may be edited, but do so with caution.  Project Server expects to see specific fields attached to each item within those lists and libraries.  Those fields may be hidden, but not deleted – and additional fields may be added as needed.  The Project Server feature also provisions a number of Web Parts to surface Project Server data.

6) Project Server requires SharePoint Enterprise features (and the concomitant licensing requirements). The upside of this is that Project Server relies on all of the SharePoint reporting tools to report against the Project Server databases.  Excel Services, PerformancePoint and SSRS may all be used, with the Project Server database providing your data source.  Project Server also provides the feature to optionally build OLAP cubes of project and resource data, which may in turn be used to provide additional data to reporting tools.

7) Patches are released on the same frequency as SharePoint patches.  In fact, patches are bundled with the bimonthly Office Server cumulative updates and service packs.  That being said, patching Project Server is a bit more sensitive as you should generally try to ensure that all client installations of Microsoft Project Professional are patched at the same time as Project Server.

8) Users need a client access license (CAL) to access Project Server.  More importantly perhaps, users need a CAL to access Project Server data.  As always, when in doubt about licensing issues, always refer to your Microsoft licensing specialist, but the rule of thumb that I’ve always followed is that if they are accessing real time data from the Project Server database, they need a CAL.  This means that even if you’re surfacing Project Server data via External Content Types into an External List on a non-Project Server farm, you still need a CAL to access that list.  The corollary to that rule that I learned recently is that for the most part, if you need to ask whether or not you need a CAL for a specific scenario….you need a CAL.

9) Project Server may be deployed on the main corporate intranet or within its own farm.  Architecting a Project Server deployment is a discussion that needs to happen early on in the process.  Consider whether the benefits of making Project Server available to the sites on your intranet outweigh the benefits of deploying Project Server to its own isolated farm.  Check online for a number of discussions around this topic.

10) Do not try to implement Project Server on your own.  Always consult with your local Enterprise Project Management implementation partner even if it’s just to put together a couple of roadmapping sessions.  Simply standing up Project Server with a “build it and they will come” approach almost never works.

That’s my list.  What’s on yours?