Are Fixed Duration tasks flawed?

[SpiroT]

Hi Steve,

Yes, you've captured exactly the behaviour of this Fixed Duration task!
Thank you. Let me add though...

But if the resource has every Tue and Thur marked as
non-working days, he has to work Mon, Wed, and Fri of this week PLUS Mon and
Wed of next week to burn up 40 hours of duration.

Did you know that when you first assign this resource to this 40 hour fixed
duartion task you M-W-F resource will only give you 3 working days worth of
work and not 40 hours? It is only after you introduce more non-working time
that it starts behaving like exactly like a Fixed Work task. Doesn't that
suck!?

The governing calendar is the
Project Calendar when no resources have been assigned and the Resource
Calendars after resources have been assigned.

This is part of what makes the behaviour of this task type seem
inconsistent, isn't it?

I guess there no way I can get a task to be, as you've defined it, an
elapsed duration governed by the project calendar or task calendar regardless
of resource availability (eg. I guess what I'm really hoping for a is task
that is able to "ignore resource calendars" at some point)? Is there any
hope for that?

Would you know why MS Project would choose not warn you about more than one
of the Fixed Duration task that it had to expand to accomodate the fixing of
a resource working time during an editing operation of sorts?

A Fixed Duration task is fixed duration, not fixed elapsed time - they are
entirely different measures of time. Elapsed time is what the clock on the
wall measures, every minute of the day always counts. For duration I have
to go back to its fundamental concept and definition - the number of
(potential) working time minutes between when the task starts and when it
ends. The only minutes that count for duration are those minutes the
governing calendar says are working time minutes. If we have a task that
start today Monday, 02 Apr, at 8am and ends this coming Friday at 5pm
assigned to a regular full-time emplyoyee who works M-F 8 to 5, the task
duration is 40 hours. But if the resource has every Tue and Thur marked as
non-working days, he has to work Mon, Wed, and Fri of this week PLUS Mon and
Wed of next week to burn up 40 hours of duration. We have two different
elapsed times yet the same duration. "Fixed Duration" means the 40 hours of
working time between start and finish is locked down, not that the number of
straight consecutive hours measured by the clock on the wall is fixed. We
have a task's start time and that it will take a certain number of minutes
of duration. The working time calendar that governs the task tells us what
day and time it will be when the duration minutes have been used up. If the
calendar calls for 24 hours per day, 40 hours of duration will be used up in
just under 2 days. If the calendar says the only working time is 1 hour per
day, 5 days a week, it will take around two full calendar months for the
same 40 hours of duration to be used up. The governing calendar is the
Project Calendar when no resources have been assigned and the Resource
Calendars after resources have been assigned.

It will help keep it straight if you can get comfortable with the notion
that without knowing how the working time calendar is set up, simply looking
at the fact a task started 8am this morning and finishes 5pm Fri afternoon
does not, in fact, actually give you any indication at all of what its
duration is beyond the fact that it will be <=105 hours (the total elapsed
clock hours between 8am Mon and 5pm Fri).
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Hi Steve,

I discovered something else the other day that makes this Fixed Duration
behaviour a drag!

I was trying to shorten my project's critical path, but the Fixed Duration
task made it difficult to do so because some of my resources had
non-default
non-working time in their resource calendar which caused such fixed
duration
task they were on to grow and pick up the slack that I was trying to
create
in the first place! Arrggghhh!

When fixed duration tasks encounter situations where their respective
resources have exceptions in their resource calendars, which as you know
is
all to common in planning : ), fixed duration task make a mess of things;
especially when the tool does not give you the complete picture (i.e, if
more
than one of these occurances happens in one of your edits, you only get
warned about one of many tasks that may have had their durations changed
by
project). Do you have a proposal for a work around for this? I know you
proposed working under the hood so to speak via a usage view. That's fine
when you know what needs to be fixed, what about if you don't that fall
through the preverbial crack? Do you think I should use a baseline or
something to catch this sort of bug?

/Spiro.

Oh I agree it would be a very good thing if we could and I too would like
to
have the option. It's just that it's not that hard to work around it the
way things are as long as one is aware how it actually does work now. If
worse comes to worse, there's always the usage views to show one what's
really going on 'under the hood.' By editing in the usage views you can
get
it to do almost anything you want, as long as you don't try to force it
to
violate W=D*U for the individual resource assignments. Perhaps people
would
be less upset if MS had chosen to call 'fixed duration' etc the
'assignment
type setting' instead of 'task types' even though for basic
single-resource
tasks they're the same thing. It would certainly be a more accurate
description of what behaviours those terms actually represent. As I see
it,
getting upset over the fact that the overall duration number displayed
for
the task is an effect of the combination of the individual resource
assignments and their calendars and can change if those calendars change
is
rather akin to getting upset over the fact that a task beginning Wed 8am
and
ending the following Tue at 5pm with the weekend non-working displays a
duration of 5 days instead of 7 days. Both of those behaviours are
implicit
in the definition of "duration" as being the number of working time units
between task start and task finish.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs



"Jan De Messemaeker" <jandemes at prom hyphen ade dot be> wrote in
message
Hi Steve,

Just one reaction to part of your post, quote:

"I really don't understand why that behaviour arouses such
negative passions. Because it is consistent, dealing with it should be
a
no-brainer as long as one remains alert to it."

Well I do.
The fact that you don't have the choice, that except for the leveling
option you cannot force resources to work together creates a lot of
frustration, and that is a very negative feeling (close to passion)

Greetings,


--
Jan De Messemaeker
Microsoft Project MVP
http://users.online.be/prom-ade
It took so many words because the allegation was made that one would
obtain different results if one assigned resources through the Assign
Resources dialogue versus splitting the screen and assigning resources
via the Task Form Resource Work screen. I demonstrated that that was
not
true. If I didn't spell out how I'd covered all the bases, I'd have
been
condemned for glossing over a "major flaw" and leaving out the case
that
demonstrates it. Damned if I do and damned if I don't.

I agree it would be very convenient to have a task level setting,
perhaps
similar to the "...can adjust individual assignments..." setting in
leveling, that states whether the assigned resources must work
together
or can be scheduled separately. When the two resources are the
company
plane and its pilot it certainly would make a lot of sense. But in
situations such as where Joe and Bill each have to do 40 man-hours of
work on a task such as painting a room and actually can work
separately -
like Joe paints the south wall of the room while Bill paints the north
wall - I don't have a problem with Project saying the duration of the
collective task 'Paint Walls" is 5 days if they can both work on it
together this week but 10 days if Joe works in his assigned wall this
week and Bill does his wall next week. With the task set to 'fixed
duration' the individual work packages really will be fixed in
duration
and the 'task' whose duration is fixed in that case is not the
aggregate
of all the individual resource work packages but rather the duration
of
each individual component work activity. Why is it a violation of the
idea of fixed duration if a task that describes two or more
independent
activities like that changes its *total* duration dependent on the
specific interactions of each resource's calendar, as long as each
individual work package duration doesn't change?

IMHO, contrary to what you said I never did demonstrate that 'fixed
duration really isn't fixed duration' because task type settings only
apply to individual work packages and never apply to summary tasks.
In
every single instance I posted duration was fixed and remained fixed,
even in the one case where it appeared otherwise! In that one case
where
it *appeared* to violate the fixed duration setting, the violation was
an
illusion caused by the fact that a task with two distinct resource
names
on it is always treated as a summary task for computation purposes,
treated as if it is really not a single task at all but in fact is
actually two independent tasks (north wall, south wall) masquerading
as a
single task. Most of the time that is a completely accurate
description
of the real world - Joe and Bill really can work on their own and the
total time from start to finish for painting the room is the result of
the interaction of their two independent work schedules, extending
from
whenever Joe starts until whenever Bill ends (assuming Joe starts
first).
I agree it would be very convenient and beneficial to be able to
choose
whether that is the way such collective tasks should behave or not,
but
as long as one understands how it presently operates and stays on the
alert so as to avoid being fooled by such afrementioned illusions, it
is
already completely controllable and predictable. I really don't
understand why that behaviour arouses such negative passions. Because
it
is consistent, dealing with it should be a no-brainer as long as one
remains alert to it.

Hear ye, hear ye! The task type designations 'fixed duration,' 'fixed
units,' or 'fixed work' only have meaning when editing a resource
assignment's parameters within the context of a single work package
assigned to a single resource name! If there is more than one
resource
name on a task, there is always more than one work package and more
than
one assignment involved. The task type setting applies to each
assignment individually but does not convey any information about the
behaviour of the collective task item taken as a whole.

That behaviour doesn't bother me so much because I guess I don't see
the
best goal of 'managment' as being so much the imposition of an *a
priori*
structure on the project from without but instead as being more of an
organic process of discovery of the natural forms inherent within the
project itself, like carving a stone elephant by cutting away
everything
that's not elephant <grin>. The illusion of a constantly changing
duration doesn't bother me because that's the way I expect the world
normally to behave anyway.

--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


Steve,

The fact that it took three posts and several hundred words only to
come
to the conclusion that fixed duration tasks do not actually have a
fixed
duration is evidence that the behavior is not for the faint of heart.
I
like fixed to mean fixed.

-Jack


Further addendum. If we Wally and the Beave's calendar initially
show
the they're working the full week when we assign them to the task
and
then later post in the fact that Beave is booking off on Wednesday,
there is, in fact, an apparent duration change for the fixed
duration
task. The overall duration of the task changes from 5 days to 6
days.
But it is an artifact because W=D*U applies to each resource
individually. When assigned to the task before any exception days
off
are posted to The Beaves calendar, both resources have the same work
to
do - 40 hours each in the case of non-effort driven fixed duation.
Each resource must work 5 working days to do their 40 hours. Now
the
Beave books off for his birthday on Wednesday ... but he doesn't get
forgiven the 8 hours he was supposed to work that day. He still has
to
do 40. But now, with the 1 day interruption he has to add an
additional
day at the the end, ie, the following Monday. Wally does 40
mh/5d/100%
Beave does 40mh/5d/100%. The Prime Directive work equation is
satisfied
for them both. But because of Beave's missing day in the middle,
the
overall duration of the task as measured from the moment any work is
performed by any resource until the moment all work by any resource
is
completed becomes 6 days.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs



: