Architectural Options for Multiple Organizational Units or Departments using Microsoft Project Server 2010

In organizations where multiple Organizational Units (OUs) or departments wish to use Microsoft Project Server 2010 to manage their work, the question often arises:

Should each Organizational Unit, Business Unit, or Department use their own Project Server instance, or should they share?

Although some Project Server implementers have strong opinions in this area, I suggest that there is no best option for every situation. Every organization has different needs; some are best served by having separate Project Server instances, and others are best served by a shared Project Server instance. Some organizations may even have a need to install, configure, and maintain a completely separate SharePoint farm for different OUs. Here is my attempt at explaining each option, its implications, and its pros and cons.

Overview and Terminology

A SharePoint Farm is a group of one or more servers, either physical or virtual, that work together to host the SharePoint application and any services running inside that application, including Project Server. A farm may consist of a single server that does all the number crunching and responds to all user requests, or it may consist of several servers that work together to share the workload. The end users are generally oblivious to the number of servers in the farm that are processing their requests, since they simply access the application (i.e. SharePoint, Project Server, etc.) through a single URL (i.e. http://mycompanyportal).

It is generally recommended to set up a SharePoint farm with at least two servers (one holding the databases and another hosting the SharePoint Server & Project Server applications); however, a very small organization may only need a single server, and a larger organization may have several servers in the farm to share the workload of hundreds or thousands of people using the system.

A single-server farm processing requests from people at computer workstations:

A multi-server farm with servers working together to process requests from people at computer workstations:

A Project Server Instance is a web-based application that can store and display projects and resources, communicate task assignments to Team members, capture task progress from them, and perform a wide variety of other functions for people within an organization. If you compare it to another very widely-used web-based application, Facebook, you will see some similarities. For example, a Project Server instance has a web interface accessible via your Internet Explorer web browser, Project Web App (or PWA), as does Facebook (http://www.facebook.com). A Project Server instance also allows you to interact via client applications such as Project Professional, as does Facebook (i.e. mobile apps for your Android tablet, iPhone, or Windows phone). The Facebook web-based system does not run on a single web server, but rather it runs on a farm of many servers working together to handle the heavy workload of hundreds of millions of people around the world.

Similar to how a shared web server may host multiple of web sites on the World Wide Web, a SharePoint farm can host one or more Project Server Instances for an organization. If multiple OUs within an organization (i.e. Engineering, Marketing, IT) wish to use Project Server, then they may share a single Project Server instance or they may each choose to deploy their own unique Project Server instance. Just as a web site on the World Wide Web appears to be completely independent of all other web sites on the web, each Project Server instance appears to be completely independent of any other Project Server instances, even though they may all be hosted within the same SharePoint farm.

Multiple OUs sharing a single Project Server instance:

Each OU using their own independent Project Server instance:

Each Project Server instance has its own PWA web site with its own unique URL (i.e. http://mycompanyportal/pwa, http://mycompanyportal/engineering, http://mycompanyportal/marketing, or http://mycompanyportal/it), its own set of project- and resource-related data (project schedules, resources and users, timesheets, status reports, etc.), and its own unique configuration. Each Project Server instance in a SharePoint farm has its own set of four Project Server databases to store its project and resource-related data, and the instances may share a single SharePoint Content database which stores other project artifacts such as documents, issues, risks, and deliverables, or each instance may have its own SharePoint Content database.

Following are the main three options available for multiple Organizational Units wanting to use Project Server 2010, as well as a list of pros and cons for each; you may encounter the occasional situation where a hybrid approach is necessary, but these options should give you enough information to make your system architectural design decisions:

• Each Organizational Unit or department uses their own Project Server instance.
• All Organizational Units or departments share a single Project Server instance.
• Each Organizational Unit or department uses their own SharePoint Farm

Option 1: Each Organizational Unit or Department Uses Their Own Project Server Instance

As stated previously, this option involves provisioning a separate instance within the SharePoint Farm for each OU.

Pros:

• Each OU can configure their Project Server application separately to meet their unique business requirements.
• Separation of Project Server and SharePoint Content databases for each instance provides better data security between OUs.
• Only someone who administers the system infrastructure, rather than a business user who administers the application, can grant access to data across OUs.
• Because a single Project Server instance does not need to accommodate the security needs of multiple OUs, each instance should have a simpler security configuration.
• Because a single Project Server instance does not need to accommodate business requirements for multiple OUs, each instance should have a simpler overall application configuration.
• Each OU will not be forced to follow the same task statusing and time tracking processes.
• Each OU will not be forced to use the same collection of Enterprise Calendars.
• Each OU will not be forced to share the same set of other application settings such as currency settings, resource capacity settings, PWA interface settings, etc.
• Because the resources from all OUs will not be aggregated into a single Project Server instance, the Enterprise Resource Pool in each instance will be smaller and more manageable.
• Because the Excel Reports from all OUs will not be aggregated into a single Business Intelligence Center, the collection of Excel reports in each instance will be smaller and more manageable.
• Because the Project Professional views, tables, filters, groups, and macros from all OUs will not be aggregated into a single Enterprise Global template, the collection of those items in each instance will be smaller and less cumbersome for the Project Managers in each OU.

Cons:

• Separation of Project Server and SharePoint Content databases for each Project Server instance makes it more difficult to aggregate data across OUs for reporting purposes.
• OUs cannot easily see an overall view of projects across OUs and cannot perform organization-wide portfolio planning.
• OUs cannot easily share common resources on their projects and do not see an overall view of resource capacities and workloads across OUs.
• OUs cannot easily establish inter-project dependencies.
• Because each Project Server instance has its own unique application configuration, there is more overall effort required to configure and administer the Project Server instance for each OU, although the work is typically distributed across all OUs.

Option 2: All Organizational Units or Departments Share a Single Project Server Instance

As stated previously, this option involves provisioning a single shared instance within the SharePoint Farm for all OUs.

Pros:

• Usage of Project Departments and Resource Departments allows consolidation of custom enterprise fields and hiding fields that are irrelevant to a specific OU.
• Usage of Project Departments and Resource Departments allows consolidation of Enterprise Project Types and hiding those that are irrelevant to a specific OU.
• Usage of Project Departments and Resource Departments allows consolidation of OLAP databases and hiding data that is irrelevant to a specific OU.
• Usage of Project Departments and Resource Departments allows consolidation of Business Drivers and Portfolio Analyses and hiding those that are irrelevant to a specific OU.
• Consolidation of Project Server and SharePoint Content databases makes it easier to aggregate data across OUs for reporting purposes.
• OUs can easily see an overall view of projects across OUs and can perform organization-wide portfolio planning.
• OUs can easily share common resources on their projects and see an overall view of resource capacities and workloads across OUs.
• OUs can easily establish inter-project dependencies.
• OUs can easily share Project Management and Resource Management processes and best practices.
• Because there is a single Project Server instance with a single application configuration, there is less overall effort required to configure and administer the application.

Cons:

• Each OU cannot configure their Project Server application separately to meet their unique business requirements.
• Consolidation of Project Server and SharePoint Content databases provides less data security between OUs.
• A business user who administers the application can grant access to any data across OUs.
• Because a single Project Server instance needs to accommodate the security needs of multiple OUs, that instance may have a much more complex security configuration.
• Because a single Project Server instance needs to accommodate business requirements for multiple OUs, that instance may have a more complex overall application configuration.
• Despite the use of Project Departments and Resource Departments, each OU will be forced to follow the same task statusing and time tracking processes.
• Despite the use of Project Departments and Resource Departments, each OU will be forced to use the same collection of Enterprise Calendars.
• Despite the use of Project Departments and Resource Departments, each OU will be forced to share the same set of other application settings such as currency settings, resource capacity settings, PWA interface settings, etc.
• Because the resources from all OUs will be aggregated into a single Project Server instance, the Enterprise Resource Pool in that instance will be larger and less manageable.
• Because the Excel Reports from all OUs will be aggregated into a single Business Intelligence Center, the collection of Excel reports in that instance will be larger and less manageable.
• Because the Project Professional views, tables, filters, groups, and macros from all OUs will be aggregated into a single Enterprise Global template, the collection of those items in that instance will be larger and more cumbersome for the Project Managers in each OU.

Option 3: Each Organizational Unit or Department Uses Their Own SharePoint Farm

I would be remiss if I did not mention this option, although implementers typically do not select it except in somewhat rare cases. This option involves provisioning a separate SharePoint farm with one or more instances for the OUs. This type of system architecture is sometimes used if there are multiple IT groups within an organization, each will manage their own separate farm, and each has a separate set of OU customers that they service.

This type of system architecture may also be used in highly secure environments with completely separate networks within the organization. For example, one farm may be on a highly secure network and another farm may be on a less secure network that personnel with lower levels of security clearance will access (i.e. vendors or personnel who have not been granted higher security clearance). Any data that is transferred between the two systems may need to be copied to a removable drive and physically moved to a machine on the other network!

Pros:

• Every aspect of the system architecture or farm configuration can be unique to meet different sets of IT processes, policies, and best practices.
• Very strict control can be maintained over the security of an entire farm, while allowing other farms to have very different security configurations.
• Software updates and customizations can be isolated to an individual farm without affecting other farms in the organization.

Cons:

• This can easily be the most expensive configuration, especially if each farm runs on separate physical server machines.
• This is the most complex configuration to install, configure, and maintain, and it requires the most effort because there is very little opportunity for reuse.
• Each farm and instance will most likely require its own separate installation, configuration, and maintenance activities.

In Summary...

Please remember that although Option 1 seems to have the best ratio of pros to cons, every organization has different needs. Evaluate your organization's needs, refer to the pros and cons of each option, and make an informed decision for your situation.

Anything to add? Do you have real-world experiences to share? Please tell us by leaving a comment.

Good luck!