EPM, Microsoft Project and You

Congratulations to Tanya Foster and Collin Quiring!  Both have attained the Microsoft Certified Trainer (MCT) certification!

By Collin Quiring

Enterprise Global Summary:

In Project Server 2007, the Enterprise Global file is the main file that provides the default settings, tables, required fields, custom fields and views that are used in Project Professional.  It exists so that all the Project Managers that connect to the server will use the same settings.

How does it work?

When the business decides that certain information, processes or settings are required for schedules placed in Project, the Global file is modified to match those needs.  Therefore, only the Administrator should be able to modify the Global file.  This ensures that required fields are filled out prior to the schedule being published on the server.

Whenever a user opens Project Professional with a connection to a server, the Enterprise Global file will be downloaded from the server to the user’s computer.  This happens automatically, in the background, and can’t be stopped by the user.  Every time Project Professional connects with the server, it checks to ensure that the most current Global file is being used.

What’s the catch?

There are two issues to the Global file that Project Manager’s need to be knowledgeable about.  They both are part of the program and the way that Microsoft built the tool.

1.        Since a user needs to have the ability to work without being attached to a server a cached version of the Global file is saved on the user’s computer.  This allows for faster processing while online and for the ability to work offline.  This is also why sometimes the Global file is referred to as the “Enterprise Global file” or “Local Global file” to designate between the two potential versions of the Global file.

a.       The catch here occurs if a person modifies their own Global file, has never connected to any Project Server or is connecting to multiple Project Server instances and then working offline between those connections.  While a rare occurrence it sometimes happens.  Doing any of these can cause the user’s version of the Global file and the server’s Global file to be incongruent.  When the user later connects to the server, the Enterprise Global file will download and if they have any customized views, fields or other modifications in the Local Global file those modifications won’t necessarily be saved to the server.

2.       For some reason, Microsoft decided that only about 95% of the Enterprise Global file would actually download to the user’s computer.  There are some settings (like the option for “Project Summary”) that do not download.  In those cases, the individual Local Global file is used with whatever most recent (or factory default) settings are in that Local Global file.

a.       The solution for this is relatively simple and leads us to the Standard Template.

Standard Template Summary:

While the Enterprise Global file controls views, custom fields, and most other settings the way to ensure that a Project Manager starts with the same settings for every new schedule is to create a Standard Template.  The Standard Template has everything set to the agreed upon settings and can therefore guarantee that everybody is starting out with the exact same starting point. 

One way to differentiate the Enterprise Global file and the Standard Template is to view it like this:  The Enterprise Global file creates the views and fields to use and the Standard Template opens with the view and fields to start an actual schedule.  The Standard Template may or may not have certain tasks in it as well. 

The standard methodology should be that whenever a Project Manager starts a new schedule, they connect to Project Server to get the Enterprise Global file and then they open the Standard Template and begin adding their specific schedule’s information.

By Collin Quiring

Yes, these are very complimentary products with an extremely high amount of integration.  So, why did I use the term “versus” in the title?  Well, this entry is about the differences between the two – and why you would go with one or the other or both.  Let me be clear – both of these products are valuable and can be beneficial in numerous ways to a division of a company or the entire organization.  However, I am often asked what the difference is and when to use each of them and that is what I am going to try to briefly answer.

Definitions (from Microsoft’s site)

Project Server:

“With Microsoft Office Project Server 2007 and its clients, your organization can more effectively manage and coordinate work ranging from one-time projects to complex programs across the entire project life cycle.”

Portfolio Server:

“Microsoft Office Project Portfolio Server 2007 helps your organization realize its potential by identifying, selecting, managing, and delivering portfolios that align with your strategic priorities. Office Project Portfolio Server 2007 is a key component of the Microsoft Office Enterprise Project Management (EPM) Solution and helps ensure that you gain visibility, insight, and control across your project, program, and application portfolios.

Office Project Portfolio Server 2007 integrates with Microsoft Office Project Server 2007 to provide organizations with an end-to-end project portfolio management solution. The bidirectional gateway enables administrators to link multiple Office Project Servers to Office Project Portfolio Server 2007, providing executives with a consolidated view of all projects within the organization.”

Ok, so, what is the main difference?  Level of management and decision making ability is the principal distinction.  Portfolio is to decide WHAT projects to do and Project Server is to do the project.  These two products help with oft-used saying, ‘Choosing the right projects (Portfolio) and doing projects right (Project Server).’

It isn’t uncommon for an organization to want to implement both products at the same time and then use them try to use them both to their maximum potential.  However, I generally recommend against that because the disciplines and the processes that make Portfolio Server valuable to Executive Management is based on the data and work being done in Project Server.  This isn’t a technical issue – installing this products is relatively easy and integrating them isn’t difficult either.  This is a business issue – do you want Executives making decisions based on resource allocation when you have no idea what projects those resources are working on?

I recommend that an organization first becomes proficient at using Project Server – enabling the features that they will use such as Resource Allocation, Calendars, Data Analysis, Templates, Task Definitions, Required Fields or any of the myriad other items that a company might want to use.  Then, when they have that working to a satisfactory level they implement Portfolio Server.  Note that I did NOT say that when they have Project Server working perfectly that they start using Portfolio Server. 

Portfolio Server requires a lot of pre-thought in relation to the data that Executives want to track, understand or require prior to selecting a project.  Some data items will be required from all projects and then there are the unique projects that are exceptions – and that has to be accounted for as well.  Numerous questions must be answered from the business perspective before Portfolio Server is a valuable tool.  For example, what are the criteria that you use to determine if a project will be done or not?  Is it purely profit?  Is it time to market?  Is it resource availability?  What about governmentally mandated projects?  What about pet projects?  These and numerous other questions need to be answered before diving into Portfolio Server if you want it to be an effective tool. 

Since the level of information that each product requires and provides is the main difference, I think it worthwhile making a list of the key distinctions.  While this is not necessarily a complete list, here are the main pieces of information that each product provides. 

Project Server Information

These all combine to allow the user, Resource Manager, Project Manager and Executive access information from a single task or single user for one schedule or all the scheduled projects on the server.  Schedules can be viewed as a standard list or in a unique view in the Project Center (and drill down on any specific schedule) or all the data available in one or more of the cubes.  The information contained in Project Server is based on what is happening with specific schedules and can be rolled up into summary reports of all the schedules on the server.  This allows for decision making on both the micro and macro level as it pertains to proposed and existing schedules and how those will affect resources, other schedules and any other (including customized) information that is tracked. 

Portfolio Server Information

These all combine to allow for decisions to be made about what projects should be worked on.  Based on the criteria and the information input into the system, Portfolio Server can help recommend which projects fall within your decision matrix of which projects to work on, continue, discontinue or re-prioritize.  It allows for Executives to quickly see the entire portfolio of projects against multiple criteria.

With the combination of the two products, information flows back and forth and can provide very valuable data to make much better decisions.  However, the amount of work before using Portfolio Server must be taken into account.  And, the methodology with which you work with Project Server must be in progress before consistency can be achieved and the current status reports are of any value.

Combined, these tools make for a highly collaborative, standardized and very informative data center that Executives, Project Managers and other key personnel can use to better an organization’s portfolio and project management.

By: Collin Quiring

IDC completed a study on Portfolio Management at the behest of CA.  The study appears to have been about PPM (Project and Portfolio Management) and not specifically tied to software from CA.  That said, they found many interesting facts that I wanted to highlight.

The costs of operations were decreased, resource utilization increased and project redundancy was dramatically reduced or eliminated all together.  There are a number of comments that I can make about the benefits of implementing PPM but I think that the study itself shows numerous benefits so I will just highlight those for now.

Some of the interesting findings:

Time to Market in weeks                          33% improvement

Number of projects managed                   35% increase

Cost per project                                        37% decrease

IT staff productivity                                  14% increase

Payback time                                            7.4 months

This is one more study proving the value of PPM and in tough economic times I would argue that this is even more important than ever!

Source: IDC White Paper, How Project and Portfolio Management Solutions are Delivering Value to Organizations, September 2008

By: Collin Quiring

Why go with Software as a Service (SaaS) for Project Server?  There are numerous reasons but here is a partial list of some of the items to think about, concentrating on the fact that SaaS for Microsoft Project Server is cost effective and allows for faster Return on Investment (ROI). 

Numerous factors affect the overall calculations for ROI and for the Total Cost of Ownership (TCO) of Microsoft Project Server; including, but not limited to:

·         Hardware cost

·         Software cost

·         Licensing fees

·         Installation administration

·         Procurement administration

·         Software upgrade cycles

·         Hardware upgrade cycles

·         Software administration

·         Hardware administration

·         Maintenance training of employees

·         Employee continuance issues

·         Management to coordinate and track support

·         Help Desk or other support functions

·         Data storage cost

·         Dedicated or consumed employee salaries

·         Multiple location coordination (systems and personnel)

·         Administration learning curves

·         IT accounting issues – depreciation, budget allocation

·         Flexibility to easily and quickly expand footprint

In a recent study by InformationWeek titled “Software as a Service Study” when asked what the biggest challenges with on-premise business applications were – 57% responded that the cost of IT staff resources required to support/manage were the largest issue.  Following that were the cost of upgrades and the maintenance costs.

For a tool like Microsoft Project Server, it doesn’t make sense to add headcount to maintain the server.  However, it also can’t be ignored.  This means that the training for and maintenance of the Project Server and its unique challenges are often put on a full-time employee who is most likely already at full capacity.  This tends to result in the “new” work of maintaining the Project Server becoming a secondary and lower priority task and often results in a less than optimized technical environment.  That is another great reason to go with SaaS – the dedication of the people maintaining the technical environment.

Other factors to consider are the size and procedures of the organization.  There are studies that try to predict the best company size where SaaS fits best.  However, I think that while SaaS works very well for smaller companies due to the inability to have internal resources do all the required work I think that the organization’s setup and methods affect the need for SaaS even more.  For an organization looking to maximize ROI and minimize internal ongoing costs, the SaaS model allows for a fast ROI and the ability to concentrate internal resources on existing technologies or other new projects.

While exact dollar figures are always specific to an organization’s environment such as user cost rates, licensing agreements, hardware and software purchasing agreements and numerous other variables, here are some generic ROI numbers based on retail market pricing.  This is an attempt to compare the ROI of SaaS and internal implementation of Project Server.

By these figures, it takes two full years before the ROI of doing an internal implementation matches the ROI from using SaaS.  (Based on the implementation cost difference and then the monthly difference.)  And, as is commonplace with technology, the servers will most likely have to be updated or upgraded or replaced in the meantime, numerous patches will occur and other variables that come with the passage of time will increase the costs of the internal method.  Patches and server updates are costs that are borne by the SaaS provider during the contracted time period.