projectified

Who’s Driving YOUR Bus?!

Resource Leveling. The process of making sure that none of your resources are scheduled to work MORE hours than humanly possible! All PM’s SHOULD do it. Most don’t and the ones that do, don’t enjoy it very much! Project has a Resource Leveling feature that will, by the letter of the definition, do just that: It will make sure that none of your resources are scheduled to work more than their Max Units value says they can for a given time period. It will move assignments out in time to make sure that any assignments that overlap do not cause overallocations. It will even take several different criteria into account when deciding which assignments should be moved. But let’s not forget that it is a formula. It is not smart. It just does what it is told to do.

For what it does it is a fine feature. It is often a good start to a more manual process of leveling your resources. It gives you A solution but likely not THE solution and certainly not the ONLY solution. In my mind relying totally on the built in leveling function is a little like a carpenter relying on his hammer to decide where to drive nails.

Think about the problem. The schedule you have created for your project, as it stands right now, has several of your resources doing more work than is possible according to their Max Units field and their calendar settings. Delaying assignments (moving them OUT in time), which is the only thing that the Resource Leveling feature will do, is only one possible option. Others include ‘compelling’ your resources to work overtime, starting some tasks earlier, replacing the overallocated resource with another one that is not as busy or even assigning more resources to a certain tasks to make it take less time. Technology is great, technology is wonderful, I love technology. But do I trust it to make these kinds of complex decisions for me? No. How would Project even start to know which resource is the best choice to replace the busy one? Sure fields like Outline Codes in Project Server that hold skill information are a start but this is a decision that is best left up to a human brain.

The relationship between people and software/computers is often a strange thing, full of contradictions. I know people that don’t trust Microsoft enough to install the latest hotfixes in Windows but these same people are willing to let the Leveling algorithm in Project decide for them the schedule and resource allocation on their $200,000 project! The OnStar car navigation system is a very cool thing. It has never given me wrong directions when I have used it. But would I let it steer the car for me? Umm, No. Like I said before, the leveling features in Project great for as far as they go and for what they were programmed to do but in all but the most simple projects they are likely NOT going to give you the BEST resource scheduling solution.

I like to say that if Project COULD provide the best solution for resource scheduling then your boss would not need you because the software would be smart enough to do the rest of your job too! Finding the right solution for how to schedule your resources is YOUR job. Project will provide you will TONS of data about what tasks your resources are assigned to, how much work they have to do in a given time period and how over or under allocated they are. It is up to you to use this information to solve your problem. You are driving the bus. You are swinging the hammer. Don’t let the hammer swing you. :-)

Status Methods Can Kill!

OK so maybe that is a little dramatic but which status method you choose can really have an impact on how your Project Server deployment will be accepted by users and how quickly you will be able to get your users to embrace using it. It also, obviously, has an effect on the quality and quantity of information that the status updates from your resource will add to your project.

First off if the resources in your company are not already using some kind of a timesheet system then you can run into cultural issues around "timesheets". Those not used to filling in time will not only have to deal with a new process and an addition to their daily/weekly routine but they may also harbor some resentment about "big brother" watching them. The best way around this kind of issue is to be very up front with the 'Team Member' community within the organization about what will be done with this information and why collecting it is of benefit to them as team members. A common way of approaching this subject is to ask team members if they have ever felt like they were being asked to do more work in a week than was physically possible. Have they ever been assigned to work full time on a project by one project manager and then full time to work on another project by a second project manager in the same week? Have they ever felt like their team was understaffed for the amount of work they were being assigned? They will almost always say "YES" to at least one of these but commonly they were never able to really show management that any of this was more than their opinion. Using Project Server and collecting task status and 'timesheet' type information is the beginning of being able to PROVE all that to management. Bring the benefits of Project Server home to them in a way that shows that it can change their working lives for the better and you will have converts to the cause! If you keep them in the dark and just hit them with new things to do then they will feel that this is just another weight placed upon them by management and they will drag their feet at every turn. Wouldn’t you?

In such an organization it might be advisable to start with the Actual Work/Remaining Work method rather than the “fully blown” timesheet-like method (Actual Work per day/week). The later can be a daunting first glimpse into task statusing and may be overwhelming for your users.

That said it is also important to balance the cultural impact of the method you choose with the kind of data that each method gives you. The sometimes more difficult to swallow “Actual Work per day/week” method provides the project manager and the organization with much higher quality data. It tracks exactly how much work was done on each task by each resource on each day. It will provide the project manager with a much more smooth flow of tracking data Actual work is not delivered in blocks as with the other, less detailed methods. This can help provide a trend for longer tasks as to how accurate your original estimates of how much work would be done per day or week on your tasks.

No matter which method you choose it is important that the choice be looked at from several angles. It is common for the choice to be driven purely by the need of the PM for data. However, as I have covered above the method that provides the best data source for the PM can often have cultural impact that could slow down or even derail the entire deployment. Think about the quality of data the PMs will be getting if a user revolt over timesheet methods ends the deployment! :-)

Project Server Falls Prey to Office's Ease of Use!

All too often I hear comments from people evaluating Project Server that it is impossible to install and configure or that it is too complex a product. I always have the same answer for these people: Project Server is NOT Project 2000. It is not a desktop application where you can run setup and BOOM, ten minutes later you are up and running. Project Server is an enterprise application designed to be able to serve anywhere from 10 users to thousands of users. In order to do this it has to support the ability to be installed on several servers. This can add some complexity to the installation for sure but it is necessary complexity.

On another note they talk about the complexity of Project Server integrating with Windows Sharepoint Services while other enterprise PM apps have this functionality "built in". My only reply to this kind of criticism is that this might be why Project Server is so much less expensive than the all of it's comparable competitors. WHY would Microsoft go and build document management type features from the ground up for Project Server when they already have it sitting there in WSS? Let’s remember that many products that compete with Project Server cost $20K or more just for the server license. Project Server? ~$1200 But I digress. :-)

Anyway, what it all comes down to is the fact that Project Server is designed to handle a complex problem domain: Project and Portfolio Management. It does so in a pretty scalable and configurable way so that it does not force you to do what IT wants. It strives to do what YOU want. Allowing for 1000’s of organizations to do what they all want with the same set of code means that it has to leave much of the configuration up to YOU.

With this said Microsoft DOES make it pretty clear though it’s sales channels and it’s documentation that it would be a pretty good idea to engage a consulting partner with experience in deploying Project Server and NOT to try it on your own. But even if you choose to ignore this good advise Microsoft goes out of it’s way to give you the information and tools you will need to do it yourself. For example:
Configuration Planning Guide
Installation Guide
Application Configuration Guide
Administrators Guide
Disaster Recovery Guide

These are all available for free download at here on the Project Website
All together we are talking about roughly 600 or 700 pages of technical documentation covering planning and deployment topics. I have read all of these docs and they are all VERY complete and very accurate.

Most of the people that have made comments to me about Project Server being hard to install and configure end having never seen any of these documents.

So please, if you plan to do a Project Server deployment on your own go and read these docs FIRST. If it looks like you will not make it based on these docs then find a partner to help you out. You will thank yourself later. ;-)

Intro/First Post

Im hoping that this can be a place to gather ideas and information about Project Server and topics relating to it's deployment and usage. I have been supporting Project since the beta of Project 98 and have done nothing but work with/deploy/write about and think about Project Server since the middle of 2002!

My hope for this blog is that it will gather links to good information about best practices for using and deploying not only Project Server but also project and portfolio management.