Misusing of Master Projects Schedule in Project Server Deployments

BlogArt1.png

Table of Contents


 

My job is a Project Server consultant and often I get called into a failed Project Server implementation back on track. One common issue I see is the misuse of Master Project schedules in project server deployments. The issue quickly comes to my attention when I open Project Center. What I see is one master project schedule that contains all the projects in the PMO; one large master project. At first I was bewildered to see this and then I would have explained to PMO that this is not a good practice.

Believe it or not, but my last three recent consultant gigs had this exact problem. I have recently determined why this had occurred. Each of these sites was a fairly recent new Project Server deployment and each these deployment had recently used project "resource pools". If you are not familiar with this concept then let me explain. Project standards (and professional for that matter) allow project schedules to share a command pool of resources using a "Resource Pool". The resource pool is basically a project schedule that contains all the resources in the organization and project schedule is put on a file share. There are not tasks or task assignment on the schedule. This allows a project schedules to map their resources to this common resource pool. I call it the "Poor man's Project Server". It works well for small number of project schedules and resources and if you cannot afford a project server.

The PMO and deployment team failed to make the connection that project server has a resource pool store in the project server database and that the use of a Master Schedule is no longer required. Linking all projects together in a master schedule is no longer required and that many new resource reports where now built in. I don't blame them for doing this; it's just building on what they already knew and this happen to be a wrong concept to build on.

The purpose of Master Project Schedule is for managing many separate project schedules and building dependencies between them. It has it place and is a valuable tool for managing large projects; however it should not be used as described above.

In conclusion: When deploying project server, be aware of the many differences between project server and standalone project. Brining in experience consultants with a track record can provide a roadmap for smooth deployment and prevent many of these misconfigurations. When you can't afford consultants for full deployment, perhaps invest in a consultant to audit your configuration prior to final release.

Other Languages