The Resource WAR

Project managers are often faced with limited resources and tight time frames. They are also on the hook for the project success or failure. This often means the covertly degrading of quality to slam in the project just to satisfy the deadlines. However, it is difficult for most project managers to articulate their needs for resources. Therefore, I have come up with an anagram for you to remember how to phrase the discussion to your sponsors to give them options for project deadlines.

If you have ever heard me speak, I often state that the best mindset for a project manager is the one that never says no. I say, "I can absolutely do that, here is what I need." I also teach to ask either/or questions instead of yes/no. So this brings me to the resource WAR:

W - WAIT - We can wait for the resources to become available.
A - AUGMENT or ACQUIRE - We can go hire consultants, a vendor, or get some contractors to do the work
R - REDIRECT - We can redirect the resources from another project to this one.

For every project that is resource constrained, those are your options. The key is to get the data for each of the options so that you can present it to the sponsor appropriately. For example:

W - Find out when the resources will be available. For this example, we will assume October of this year.
A - Find out the cost of the consultant or contractor.
R - Find out which projects the resources are working on.

Once you have the data, it is time to present what you have learned to the sponsor:

PM: Mr. or Ms. Sponsor, in order to deliver the timeframe that you have requested, I will need three more resources or the date could slide to December of this year.
Sponsor: December? We need this to be done by July!
PM: The resources that we need are not available until October. I did find out that we could bring in a consultant for $XX.
Sponsor: We do not have additional budget.
PM: What about diverting the resources from project XX to this one?
Sponsor: We can't stop that project.
PM: It seems our options are to wait until December, hire the consultant, or redirect the resources. What would you like to do?

That may seem over-simplistic, but in reality, what are the other options? Get ready for the resource WAR. Get the data and present it to your sponsors. Good luck out there!

Rick

Why does the team need to see the schedule?

As part of my continuing series of addressing questions posed in my webinar, the next question to address asks:

"Do you have any suggestions for how to help your team of resources (who are untrained in PM concepts) understand what they are seeing in the schedule?"

I get this question quite a bit. In my opinion, I choose to not send the schedule to my team. I think I just heard the collective gasp. Before I get into what I do, let's discuss why I don't. When I am challenged on this thought in my speeches, I always ask, "What do you think happens when you send the full project plan?" Some of you out there may think that as soon as the resource gets the plan, they open it, print it, find their name and tasks, and study it to make sure they are ready to go. Although there are a few team members out there that might do this, the norm is to not even open the file. Most resources simply wait for the status meeting or for the e-mail to come to tell them to get started on their tasks.

So does it make sense to train all of the team members on how to read a project schedule? Also, what type of schedule? Several project managers write linearly based project schedules, meaning that their schedules go from Task 1 to Task 2 in the order in which they are to be performed. These schedules are against project theory as well. True project schedules should be written from WBS's and network diagrams. If this is the case, then many of the schedules are even more difficult to read because the tasks are grouped by deliverable and may increase the complexity of the predecessors.  So what do I suggest? To-do lists.

I send each team member a report of their tasks. It is a simple report that shows the task name, start date, finish date, their estimate, and the actual hours that have been reported. It is sorted by start date and I show all of their tasks for the project. This tells them what they are really interested in, what do I need to do and when do I need to have it done?

Some people object asking, "What about the predecessors? Don't the resources need to see what needs to complete before they can get started?" My general answer is no. Most of the time, the predecessors came from the resource during the WBS/Network Diagramming session anyway. They already know what needs to complete before they can get started.
This approach has been very successful for me. It is simple, effective, and keeps team members focused on what they are supposed to do. I have also written Visual Basic code that automates the creation of Excel spreadsheets as task lists from Project. Another approach is to use the Reports->Assignments->To-Do List report that comes standard with Microsoft Project.

Whatever the format, just make sure that what the team member receives isn't information overload. This will allow you to communicate more effectively with each team member. It also allows you to manage risk and risk dates more efficiently by not revealing all of the dates to all of the resources. This isn't a shady practice or something you are trying to hide. It is simply your information to manage.

At least that is my opinion, please feel free to share yours.

Until next time,

Rick