Deployment Practices: Configuration >< Process

It is easy for users new to a system like Project Server to see the configuration of fields, views, reports and security as the whole picture of doing a deployment of Project Server. It is also easy to see why there might be this confusion. On the surface it makes sense. You look at the processes in an organization and then you look at security, reports, views, and fields, etc and then configure the tool to match. Easy, right? Not so much.

Doing a deployment of project management software well is not that simple. You need to examine how the tool will be used, how projects get managed, how tasks get estimated by PMs and how resources are assigned. If several PMs define their tasks very tightly (short durations with high resource units) while others define theirs more loosely (longer durations with low resource units) it has an impact on how the data can be analyzed across projects. With the tighter scheduling there can be higher risk of slip but with the looser scheduling the data provides less certainty about where you can put new tasks or projects into the system. I’m not passing judgement on either method there are pros and cons to both. My point here is that this is an example of how the way the tool will be used needs to be taken into account when helping the customer understand how other areas of the tool can be used to make decisions about things like resource allocations or the adding of new projects to the mix. A good configuration is about more than just a few fields and setting up AD sync. It is about having the tool match how the organization works.

This brings up the even bigger part: what if how they do it now is not how they want to be doing it (or even harder, how they want to be doing it but not how they SHOULD be doing it?) Now comes the rough job of helping them understand where changes can be made and how those changes can be broken down into small, more easily digestible changes and road-mapped. More later…