Automatically Shrink and Expand the duration of a task

[bocikt]

I don't know how to ask this question other than giving an example.

I have a project management task that should go the duration of the project.
I want the project manager on that task to work 25% of his time. As I work
towards a baseline, I want the project management task to shrink and/or
expand as other tasks effect the duration of the project. The outcome should
be an estimate of the project managers work at the time of baselining.

Is this possible?

 

[bocikt]

Never mind. I found another discussion that described something called a
Hammock Task (http://project.mvps.org/faqs.htm#Hammock Tasks). This is
exactly what I was looking for.

 

[Steve House [Project MVP]]

What do you mean by "the project manager's work at the time of baselineing?"
While saving a baseline will save the values of the PM's task as well as any
others, as the project overall duration changes due to actuals being at
variance with initial estimates, the PM task will also change (the baseline
values remaining the same, however).

 

[dwolf]

Steve,

I believe what you are describing here is a hammock task. A hammock
task ties the beginning of the task to a start date or begining of a
group of tasks and stretches to the last date in the group of tasks.
Knowing this, I believe that there are multiple resources on how to
create one.

Note that these tasks are not recommended by most PM gurus because,
with the automated nature of the increase or decrease in the duration
comes increases and decreases in the cost of this task. It becomes
very easy to forget that this task does that and leaves you clueless as
to why your project jumps in costs. The recommendation is usually made
to make these project-long tasks fixed duration, non-effort driven and
update the duration as necessary.

I hope this helps.

--dwolf

 

[Steve House [Project MVP]]

Yep, a hammock task is what it is. I'd disagree that such things should be
fixed duration, non-effort driven tasks however. First of all, "effort
driven" settings ONLY effect tasks that have multiple resources, governing
what happens when you add or remove bodies from the task after the initial
resource assignment is done. If it's a single resource, like the PM
managing the project, the effort driven or non-effort driven setting has no
effect whatsoever. As to the other, in general I'm very leery of fixed
duration tasks and feel they are vastly overused. A task takes how ever
long it takes to get the required deliverable produced. If you have to
paint 100 square feet of wall, the task will take how ever long it takes to
paint 100 square feet. You don't need to paint 125 square feet and you're
not done if you've only done 75 square feet. "Fixed duration" implies that
it will always take a pre-defined and perfectly predicatable length of time
to complete the deliverable and we either fill the allotted time even if we
finish the deliverable earlier or quit when the allotted time has passed
regardless of whether the deliverable is done or not It implies that if we
allotted 3 days to paint the wall, after three days we walk away even if
it's only half-way done. If we had perfect foresight we might be able to get
away with postulating the time that will be required to complete the
deliverable but in the real world we never do, with very rare exceptions the
duration is always an educated guess at best. Work is a measure of output
required and is far more predictable while units is the most controllable.
Thus of the three, I'd put "fixed duration" at the bottom of the list in
terms of applicability. About the only time I'd say it would always apply
is in the situation of something like a burn-in test for a piece of hardware
that must run for an specific length of time.

Making "fixed duration" the norm means you're going to incorporate the
notion that work expands or contracts to fit the budget allowed for it into
the management culture of the firm and to me that's putting the cart waaaaay
before the horse. IMHO, projects should be budgeted bottom up rather than
top down.