Federation

A federated EPM environment is one in which multiple, individual instances of Project Server repositories exist (perhaps one for each department) and all these repositories integrate at some point or points for various purposes. The most common purpose is consolidated reporting across all repositories for rollup to all-inclusive corporate level reports. This is the simplest form of a federated environment because information for the corporate level reports is read-only, meaning that the department information is collected and aggregated but not changed by corporate. The information flow is unidirectional.

TIP

Microsoft has an excellent introduction to federation for reporting that includes code, available at http://msdn.microsoft.com/library. Search for "Solution Starter: Microsoft Office Project Server Enterprise Reporting."

All other forms of federation are much more complex because they typically require a bidirectional exchange of information between the environments. These bidirectional environments are almost always customized with programming integration points. An example of a business need that would demand a complex bidirectional flow of data is easy to find. The following set of assumptions defines a more complex federation environment:

• Each department has implemented its own EPM environment (one repository per department).

• Department resources typically work multiple projects.

• Resources staff projects run by other departments as well as their own department.

• Resources enter time in a single timesheet.

This federation environment can become amazingly complex as projects that the Department A worker is assigned to in Department B must exist not only in Department B's repository but also in Department A's so that the worker may enter her time in the Department A repository timesheet. Entries must then be propagated to Department B's project. Corporate rollup reporting must also be made to roll up only the Department B project because the Department A project would be a partial duplicate, and this is just the top level.

There are actually multiple ways to meet the four business statements presented previously, but all of them require customization of the tool. Since the first versions of Microsoft Project, Microsoft has provided ways for users to modify or customize the product. In fact, at the demand of the user community, Project was the first Microsoft desktop application to include a macro programming capability. This capability was then added to, enhanced, and evolved in each of the other desktop applications and ended up as Visual Basic for Applications (VBA), which was then, finally, retrofitted back to Project to replace the original macro language that had been the initiator of the concept. The point being is that the project management community was the first to recognize the benefit of having a base platform while understanding that the common base would not fit every need out of the box. This concept continues today as the Microsoft EPM solution is in fact a base set of tools that can be easily modified or tailored for individual company needs.

If your organization requires a federated approach and most especially if it determines that bidirectional flow of information in a federated environment is needed, it is highly recommended that you find a good Microsoft Project Partner to work with you. This will be an enormous time and frustration reducer even in the case of federation for reporting only. Whereas the Project Server database is open, with a published schema, the information saved within the database is still raw information (because the business rules live in the thick client Project Professional), and some of the information is not intuitively producible, as shown in Figure 26.3.

Figure 26.3. Here, multiple Project Server repositories are in use with a central Project Server collecting the information from each of the local repositories for centralized reporting purposes.