resource downtime

[Paul Billings]

Hi all,

I'm looking for some opinions regarding a real-world issue: resource
downtime. Let's say you've gotten your schedule nicely planned and
leveled appropriately. Rather unfortunately, some resources will
likely not have anything to do at times. One example is a slack task:
task T1 is scheduled for M-Th (4 days), T2 is scheduled for M-Tu (2
days), and both are predecessors of T3 (necessarily starting Friday).
T2 is the slack task.

What I see typically is that the resource will take longer than 2 days
to complete T2 (driving up cost), simply because they have nothing
else to do. Seems like the only choices are 1) put the resource on
another project (or company-sponsored "indirect") for W-Th, 2) start
some other task in this project early (which potentially drives up
that cost for the same reason), or 3) suggest that the resource have a
nice "break" -- at the expense of their vacation time :-(.
Additionally, this avoidance of downtime discourages the resource from
completing a task early -- meaning that costs will only ever increase.

Are there any other options I've missed? Is this just the sad truth
of multiple-resource projects?

Paul

 

[Jan De Messemaeker]

Hi Paul,

For me, solution 2 is by far the best. What's done is done, whatn there is
something to be done it's better than nothing. I love the leveling tool, but
I regularly do clear leveling to see what more can be achieved.
HTH

--
Jan De Messemaeker
Microsoft Project Most Valuable Professional
+32 495 300 620
For availability check:
http://users.online.be/prom-ade/Calendar.pdf

 

[Rob Schneider]

Paul,

In my view, the only viable option is (2) with the added instruction
"And do it such that it does not add extra cost to the project and any
impact on future work should only be positive." That, I think, is a
reasonable request as surely the people working the project knows more
about the project than Project doesn.

 

[Paul Billings]

Hi Paul,

For me, solution 2 is by far the best. What's done is done, whatn there is
something to be done it's better than nothing. I love the leveling tool, but
I regularly do clear leveling to see what more can be achieved.
HTH

For the benefit of anyone else reading this, the very network of
dependencies (predecessors) will often cause this. (That is the case
in the simple example I gave.) That said, leveling is a very common
cause (regardless of whether it's automatic or manual).

Paul

 

[Rob Schneider]

Paul,

In my view, the only viable option is (2) with the added instruction
"And do it such that it does not add extra cost to the project and any
impact on future work should only be positive." That, I think, is a
reasonable request as surely the people working the project knows more
about the project than Project does.

 

[Rob Schneider]

Paul,

In my view, the only viable option is (2) with the added instruction
"And do it such that it does not add extra cost to the project and any
impact on future work should only be positive."

That, I think, is a reasonable request as surely the people working the
project knows more about the project than Project does. Slave to the
plan, but don't be a slave to the plan.

 

[Rob Schneider]

Paul,

In my view, the only viable option is (2) with the added instruction
"And do it such that it does not add extra cost to the project and any
impact on future work should only be positive."

That, I think, is a reasonable request as surely the people working the
project knows more about the project than Project does.

Slave to the plan, but don't be a slave to the plan.

 

[Rob Schneider]

Paul,

In my view, the only viable option is (2) with the added instruction
"And do it such that it does not add extra cost to the project and any
impact on future work should only be positive."

That, I think, is a reasonable request as surely the people working the
project knows more about the project than Project does. Slave to the
plan, but don't be a slave to the plan.