Scheduling depending on task availability

Admin: sorry for the three posts, this is the good one

Rafael,

I'm biased towards Spider Project so I did not ask for Spider. You may find satisfactory that in Spider I arrived to your same methods. 

I was thinking that this may be a missconception about how to plan. One would think that planning is necessary to avoid resource overallocation and multitasking. Resource overallocation would lead to delayed deliverables and multitasking would cause lost productivity. In this case we are talking about two contracts. The ongoing (1) and the "20 hours @ month" (2)

If the resource has 172 work hours available each month (typical 8 hours, five days a week), why not use them to finish its project early with the maximum quality under the contract (1) budget? Allocating 20 hours to contract (2) would affect the floats for  contract (1) and could cause its delivery date to slip. Not mentioning the lost productivity increases contract (1) cost.

Well, that's what literature tells us. The truth is that a consultor would not let this opportunity go. It's almost as 20 additional free facturable ours each month, ain't it?

I looking forward to find how to do this in MSP. I've been obligated to use MSP lately for small assignments. I find it a very weird PM software, I mean, who come with the brilliant idea to take Float and call it 'Slack' ?

Saludos cordiales,

Carlos.

Carlos,

You got to be more specific as the options are endless.

1. You can use calendar exceptions to define the specific hours you want the resource(s) to work. Can be whole days, partial days, consecutive days, specific days of the week.
2. If you do not know in advance you can use partial assignments,
   1. If using Spider assign 11.6 % workload say 20 hours / ( 21.5 work days/month x 8 hours/work day) = 0.1162
   2. If using P6 to my understanding you enter partial assignments as units/time = h/d = 20 hours / 21.5 work days = 0.93 h/d

There might be other ways but I suspect you want the assignments to follow the jobs. I have a preference on the second method for this specific case and would let the supervisor(s) to make manual monthly distributions. The idea is to make sure you do not overload the resource and that there is available time for the managers to make their allocations. I would recommend assigning 1 h/d the resource to a Buffer activity that will span all jobs, in this way you will have a 21.5 hours/month buffer if for whatever reason the month hours are reduced, it will also provide more room for the managers to make the allocations.

BR,

Rafael

Carlos,

I no longer have MSP. I recall someone suggesting the assignment of quantities of resources using percentages but also recall it is a flawed method that not always yields the correct answer. It is not the same assigning 1 resource 4 hours a day than assigning 1/2 of a resource 8 hours a day, sounds weird, can yield weird results.

If you have 2 units of the same resource available you can assign 2 units 100% of the day for a total of 16 man-hours if an 8 hours day but you cannot assign 4 units 50% of the day even when both add up to the same man-hours as there are only two units available.

Lets say you need 2 resource units to move a dead body working at the same time but 1 resource unit will not be able to do the task in twice the time as it will not be able to lift the body and move it a single inch, not even in 10x the amount of time it takes the 2 resource units to do it.

Good Luck,

Rafael

Rafael Davila wrote:

"Lets say you need 2 resource units to move a dead body working at the same time but 1 resource unit will not be able to do the task in twice the time as it will not be able to lift the body and move it a single inch, not even in 10x the amount of time it takes the 2 resource units to do it."

I'd just like to add that Rafael touches on a very important scheduling concept here: the varying resource elasticity of certain work activities. This is a concept of which every planner is very aware, but to which few are applying metrics.

In my Total Project Control book, the metric I recommend is the Doubled Resource Estimated Duration, or DRED. This is a secondary duration estimate for establishing the resource elasticity of a task. It is established by asking the question:

"If Activity X is estimated to take (20?)D with current resource estimates, how long would it take if we doubled (or could double) the resources?"

Some reasonable answers are:

• 1D (Rare. Perhaps Rafael's "dead body" example. [Could we say "refreigerator" instead? Maybe with a dead body in it?])
• 10D (Said to be "perfectly resource elastic" -- same total resource use, double the daily resources for half the time.)
• 12D (Very common situation -- some "bang for the buck", but not perfect. Slightly more resource usage, but maybe less critical path drag, drag cost and true cost (TC = resource cost + drag cost).
• 17D (Some value, but not huge -- requires rigorous analysis of true cost to be confident in implementing such a change.)
• 20D (Not resource elastic at all.)
• 30D (Negatively resource elastic -- the resources will get in each other's way, like in working in a cockpit.)

I recommend entering the DREDs for each activity in a secondary Duration field and performing true cost analysis on them (if your software has critical path drag, drag cost and true cost computation functionality).

Fraternally in project management,

Steve the Bajan