Resource management vs. resource scheduling

Human resources are the biggest expense in IT. So it's no wonder resource management is getting a lot of attention. Earlier today I asked Paul Ewry, an Innotas' consultants with years of PPM experience, what is the typical way in which he has seen companies determine if they have the resources they need for a project? He laughed: "Funny you should ask, in over 80% of the meetings in which I have asked that question, after a few moments of silence, somebody licks their finger and sticks it up in the air, followed by nervous laughter from everybody."  I'd love to hear other examples. But there has to be a better way.

Unfortunately traditional project management solutions have created the perception that in order to manage resources (capacity and allocation) you need to first create detailed project schedules and assign resources to specific tasks. What a pain! No wonder people fall back to the finger licking method.

So step one is making a clear distinction between resource management and resource scheduling. Resource and portfolio managers do not need a detailed work breakdown structure to figure out how many Java developers are needed for a project and who is available. Of course project manager may want a detailed project plan to track progress and ensure completion, but that's project scheduling, not resource management.

Now back to resource management. Here are the best practices that Paul told me he recommends:

• Manage resource demand at the role level (DBA's, Java programmers...) comparing capacity to allocations.
• Allocate resources at the project level by role in the planning phase.
• When a project becomes active you can allocate specific resources - going from role to individual names (you don't even have to do this, but it helps).
• Track actual time (or percentage of time) against projects (if you want you can get more granular and go to a phase or task level).
• Compare allocations to actuals to make sure you are on track and to gather trends that will help you refine the planning process for new projects.

OK, that sounds a lot better than licking a finger or building detailed work breakdown structures.

What do you think? I really want to know how you are managing resources and what has worked or not worked for you, so please send me your comments.

--Alex Lobba

Comments

[Demian Entrekin]

Another way to think about this puzzle: compare the whole situation to a pipeline. What you might be after is pipeline acceleration. Or perhaps you simply want more throughput, a fatter pipe for more projects.

However, you may be concerned about focus, working only on the right things. More throughput might just create more problems, more noise.

So I boil it down to this. Do you want to accelerate the queue, do you want more throughput but not more speed, or do you want better focus. Personally, I would start with that question.

[Malcolm Savage]

I agree that resource management should be estimated at the project and role level. Typically the detailed resource schedule is fraught with problems, as allocating resources to individual tasks relies on accuracy across a large number of tasks, and also correctly allocating the % utilisation on each task. The alternative is the Critical Chain approach, but again I believe this is more appropriate further down the lifecycle.

[Alex Lobba]

Malcolm: what have you found to be the indicators that an organization is ready to go to the more detailed scheduling and tracking at the task level? Is is size of project or maturity of organization...

[Barry]

I was glad to read an article with a best practice that fully supports my view.

I have been doing resource management for about a year in an organization that is focussed at the schedule and task level. I feel this is inappropriate and too detailed for our level of maturity; and not necessary for effective resource managment anyway.

Focussing at the role and duration level will allow the right amount of data to make effective decisions without being too far down in the weeds.

This article will help me take my viewpoint forward.

thanks.