Are Fixed Duration tasks flawed?

[Jan De Messemaeker]

Hi Dave,

I only looked at one competitive product in this regard and I found PMW's
solution logical. They offer a task type called "meeting" which will be
scheduled only on times all the resources assigned to it have working time
(BTW this si also what Project's leveling does with he appropriate option).
This solves most of the problems we have like man-machine combinations,
craftsman-apprentice or... meetings. Why the mlakers of Project don't think
of it? I have my ideas on that but this is not the place to develop such
theories.

Greetings,

--
Jan De Messemaeker
Microsoft Project MVP
http://users.online.be/prom-ade

What I'm trying to say is that a task with more than one resource assigned
to it is actually multiple tasks. But there is certainly an ambiguity in
that. If I have 2 carpenters and list them in my resource definitions as
Bill Carpenter and Joe Carpenter, each available 100% I have 2 resources.
But if I choose to list them as an aggregate "Carpenters" available 200% I
have only 1 resource. When I have a task and assign two resources defined
as in the first case, it is as if I had two separate tasks. "Fixed
Duration" as defining the constant term in the equation W=D*U still holds
true, but only for each individual resource's task - it does not hold true
for the combination of the two. OTOH, if I have that same task and assign
'Carpenters, 200%' I have 1 task with only 1 resource, NOT 2 resources,
and
Fixed Duration / W=D*U holds true for the whole.

One source of confusion is thinking that the number of resources is equal
to
the number of warm bodies. It's not. One could say that as far as
Project
is concerned, the number of resources assigned to a task is more properly
the number of distinct resource NAMES listed for the task. When Joe and
Bill are each assigned to the same task, that is 2 resources. But when 2
Carpenters are assigned to a task, that is only ONE resource. When viewed
at the overall task level, it appears that 'fixed duration' is behaving
differently in the two cases. In fact, the task types are only
consistently
meaningful when viewed in the context of 1 task == 1 resource's work, the
classic endpoint in the breakdown of a complete, fully decomposed, WBS.
When viewed at a summary level, they may or may not behave the same way.
And as I said in my earlier message, if you assign two resources to a
single
task, that task is no longer a single task but for scheduling purposes
becomes a summary task with 2 independent subtasks. And just like any
other
summary task, when the two subtasks don't run concurrently the total
duration may change when in fact the durations for each of the resource's
piece of the total work does not.

Fixed duration is not the same thing as fixed work because work and
duration
are very different metrics, even for one resource. Work is the amount of
effort expended (measures sweat), units is the rate at which it is
expended
(measures motivation LOL), and duration is the time over which it is
expended (measures time). But as mentioned before, the equation W=D*U
strictly holds true only for a single resource's (or if you prefer, a
single
resource name's) activity. As long as you remember that, the model
becomes
perfectly predictable.

Interesting discussion!

--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visithttp://www.mvps.org/project/faqs.htmfor the FAQs

Steve,

This would be all well and good, but you are essentially saying that
work
is fixed not duration. This is the issue. Some people want duration to
be
fixed. There is already a fixed work task, but now there is no longer a
real fixed duration task. There is a hybrid task that acts differently
under different conditions. Predictability of the model is something I
rely on.

-Jack

In your example where you say that the task violates fixed duration it
really hasn't. Now before you think me mad, here me out <grin>. The
task
is Monday 8am to 5pm, 8 hours in duration, fixed duration. You assign
both Joe and Bill to it. The duration of Bill's work is 8 hours, the
duration of Joe's work is 8 hours. Now Bill has something come up and
he
has to delay his work by one day and we mark off on his resource
calendar
that Monday is, for him, a non-working day but Tuesday is normal. The
task times will now show starting Monday 8am and ending Tuesday 5pm.
So
far, so good? It appears the duration is now 16 hours but actually the
apparent change in duration is an artifact, not real! Why do I say
that?
Because the duration of Joe's work is still 8 hours and the duration of
Bill's work is still 8 hours. The durations that the two independent
pieces of work take place in, as expressed in the equation W=D*U for
each
resource assignment, has not changed at all. All that has changed is
the
two parts of the task that were originally scheduled concurrently are
now
scheduled consecutively. You always have to keep in mind that W=D*U
ONLY
applies to the work performed by a single resource on a single task.
I'll admit that Project is counter-intuitive by not recognizing that
the
task might require the two resources to always work together and could
be
improved in that regard but once you recognize that Project treats one
task with two resources assigned exactly the same way it treats two
independent tasks with one resource assigned to each, it starts to make
sense and is predictable enough to use for detailed schedule planning.
A way to illustrate what I'm saying most clearly is to make up a simple
project file with a normal task A, a summary task B with subtasks B1
and
B2, and a normal task C. A links FS to both B1 and B2, B1 and B2 both
link FS to C, but B1 and B2 are not linked to each other in any way.
Assign Joe to B1 and Bill to B2. Change Bill's resource calendar and
B2
will change accordingly while B1 remains the same (and the duration of
the "summary" B changes to reflect the collective duration between the
start of the earliest subtask task and the finish of the latest
subtask).
Split B2 in the middle and you'll see the duration of "summary" B
change
even though the durations of B1 and B2 remain exactly the same! That's
the exact situation that MS Project is modeling when you assign
multiple
resources to a task, except that you only see the "summary" task B in
the
schedule, showing up there looking as if it was a conventional task,
and
you don't see the "subtasks" at all (unless you look at the task usage
views where you do in fact see them - shall we call them 'virtual
subtasks'? - as two separate rows of hours, a row for each resource).
And that's why I'm saying the change in duration you're talking about
is
an artifact - what you're seeing is the change in duration for the
"summary" task while the actual durations over which each of the
component work activities will take place, the components of the
schedule
where the equation W=D*U is inviolate, haven't changed at all.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visithttp://www.mvps.org/project/faqs.htmfor the FAQs
Steve,
See my response embedded in your reply, below.
:
While there certainly are a number of instances of fixed durations in
the
real world, I stand by my guns that they are relatively rare. Fixed
duration means the time it takes to do a task will not be dependent
either
on how hard the resource who does it is working or on how many
man-hours of
work will be required to achieve the tasks deliverable. If the task
is
to
make widgets and Joe can produce 10 widgets per hour when he's
devoting
his
full attention to it, setting the task to 'fixed duration' would mean
essentially that if we're going to create the 1 day duration task
"Make
Widgets" and put Joe on it, we just don't care how hard he works or
many
widgets he makes - we'll have him work for one day and we'll consider
the
task done regardless of whether there's 1 or 75 widgets produced.
Further,
we'll pay Joe $5 per widget no matter how many he's made at the end
of
that
day. All we care about is that he's at the widget workbench for 8
hours.
While that scenario may sometimes be an accurate description of
reality, I
still maintain it doesn't happen that way very often.
OK, but the problem is that I want Joe to be at that workbench with
his
teammate Frank at the same time! What happens though is that if I one
of
them can not make it to that workbench as we planned it, MS Project
incorectly "assumes" that they work independently. Do you know that
when
leveling, MS Project provides the behaviour I expect from a Fixed
Duration
tasks. I'll I'm asking for is that we extend the same behaviour to
the
Fixed
duration tasks for when we change resource schedule.
As for not having resource calendars, I suggest you actually NEED to
update
resource calendars to produce a meaningful detailed schedule.
Of course, but as I am trying to tell you if I do that I compromise
the
"fixed" duration.
For example,
we have 1 day day task and we put Joe and Bill both on it We need 16
widgets and each man can produce 1 widgets per working hour IF he's
not
distracted with other duties. Thus the 16 widgets requires a total
of
16
man-hours of work, Joe will do 8 and Bill will do 8. If both guys
work
day
shift, this task will begin at 8am and end at 5pm. But if Joe works
days
and Bill works swing, the same task will start at 8am and end at
11pm.
If
Joe takes a holiday on Monday the task will start Monday at 3pm and
end
Tuesday at 5pm. If Bill takes a holiday in Monday the task will
start
Monday at 8am and end Tuesday at 11pm. You only get those detailed
schedule
results if you have different calendars to model Joe and Bill's work

...

read more »- Hide quoted text -

- Show quoted text -

Steve,
I think your explanation of how Project sees a task, the work of a
single resource, is accurate and lucid. OTH, I think this is a major
flaw in Project that should have been corrected many versions back.
Many resources on many kinds of tasks work together. To break down a
project to a one resource per task is simply not acceptable. I've
never heard of this idea in all my years in PM until I came to this
forum. This is simply a major defect of Project, NOT good scheduling
practice. The ability to "bind" resources together should be standard
in any scheduling software, though I don't know if it is.

In project, I can create resources of multiple people. I.e., I can
create a resource called carpenders with 800% availbility if I have 8
carpenders on the project. But this doesn't help if, as in reality,
usually a single carpender works with a single carpender's apprentice.
Of course, we can then create a resource called Carpender Team
composed of one of each. But what about situations where either of
them works, say on a specific task, separately? Or just splits up
temporarily to work on separate tasks? Or I need 3 teams on a one task
for it's duration?

I think Project should have the ability to "bind" resources,
temporarily or permanently together. On some tasks, I could
temporarily bind the Carpender and the Apprentice together for the
duration of the task. On other tasks, assign them separately. On
others, they would be "bound" for part of the task and not "bound" for
the rest of the task. This would also work for other kinds of teams,
like surgical teams or any kind of group whose members may vary from
task to task or project to project.

To have to break projects down to one resource/one task is absurd! It
could easily make a 1,000 task project into a 5,000 task project. I
certainly wouldn't want to have to manage 5,000 tasks when the work is
really 1,000! And it doesn't even accurately represent what is really
happening, that people are frequently working in groups, not solo all
the time.

It's one thing to understand this flaw in Project. It's entirely
another to represent it as good scheduling practice. To quote from
your post,
"In fact, the task types are only consistently meaningful when viewed
in the context of 1 task == 1 resource's work, the classic endpoint in
the breakdown of a complete, fully decomposed, WBS." I'd like to see
some reference in some highly regarded text on PM, like Kerzner or
Lewis, where it says anything like that. I certainly can't recall, in
all my reading and in all the classes I've taken on PM and Scheduling
over the last 30 years, any comment even suggesting that a WBS should
be broken down to one task/one resource level. It's simply an
oversight, at best, or a major flaw, at worst, in Project that it
behaves in this manor.

 

[Steve House]

Does applying the fixed duration attribute to a summary task consisting of
two or more independently scheduled subtasks lock down the subtasks and
prevent any of them from being moved in such a way that might cause the
summary task duration to change? Would it make scheduling sense if it did?
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Steve,

I understand what you are trying to say, but it does not appear that you
understand what I am trying to say.

To put it very simply: Sometimes I want a task to behave like its duration
is fixed no matter WHAT it represents. I do this most often while building
very early schedule models. I am not confused about this. I use it to keep
things simple and understandable for me and the rest of the world. Details
come later.

Changing that capability so that it becomes unpredictable (assuming I
exert minimal mental effort) is not a good thing. Give me both, fixed
duration and the hybrid one which does not yet have a good name.

-Jack

What I'm trying to say is that a task with more than one resource
assigned to it is actually multiple tasks. But there is certainly an
ambiguity in that. If I have 2 carpenters and list them in my resource
definitions as Bill Carpenter and Joe Carpenter, each available 100% I
have 2 resources. But if I choose to list them as an aggregate
"Carpenters" available 200% I have only 1 resource. When I have a task
and assign two resources defined as in the first case, it is as if I had
two separate tasks. "Fixed Duration" as defining the constant term in
the equation W=D*U still holds true, but only for each individual
resource's task - it does not hold true for the combination of the two.
OTOH, if I have that same task and assign 'Carpenters, 200%' I have 1
task with only 1 resource, NOT 2 resources, and Fixed Duration / W=D*U
holds true for the whole.

One source of confusion is thinking that the number of resources is equal
to the number of warm bodies. It's not. One could say that as far as
Project is concerned, the number of resources assigned to a task is more
properly the number of distinct resource NAMES listed for the task. When
Joe and Bill are each assigned to the same task, that is 2 resources.
But when 2 Carpenters are assigned to a task, that is only ONE resource.
When viewed at the overall task level, it appears that 'fixed duration'
is behaving differently in the two cases. In fact, the task types are
only consistently meaningful when viewed in the context of 1 task == 1
resource's work, the classic endpoint in the breakdown of a complete,
fully decomposed, WBS. When viewed at a summary level, they may or may
not behave the same way. And as I said in my earlier message, if you
assign two resources to a single task, that task is no longer a single
task but for scheduling purposes becomes a summary task with 2
independent subtasks. And just like any other summary task, when the two
subtasks don't run concurrently the total duration may change when in
fact the durations for each of the resource's piece of the total work
does not.

Fixed duration is not the same thing as fixed work because work and
duration are very different metrics, even for one resource. Work is the
amount of effort expended (measures sweat), units is the rate at which it
is expended (measures motivation LOL), and duration is the time over
which it is expended (measures time). But as mentioned before, the
equation W=D*U strictly holds true only for a single resource's (or if
you prefer, a single resource name's) activity. As long as you remember
that, the model becomes perfectly predictable.

Interesting discussion!

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

Steve,

This would be all well and good, but you are essentially saying that
work is fixed not duration. This is the issue. Some people want duration
to be fixed. There is already a fixed work task, but now there is no
longer a real fixed duration task. There is a hybrid task that acts
differently under different conditions. Predictability of the model is
something I rely on.

-Jack


In your example where you say that the task violates fixed duration it
really hasn't. Now before you think me mad, here me out <grin>. The
task is Monday 8am to 5pm, 8 hours in duration, fixed duration. You
assign both Joe and Bill to it. The duration of Bill's work is 8
hours, the duration of Joe's work is 8 hours. Now Bill has something
come up and he has to delay his work by one day and we mark off on his
resource calendar that Monday is, for him, a non-working day but
Tuesday is normal. The task times will now show starting Monday 8am
and ending Tuesday 5pm. So far, so good? It appears the duration is
now 16 hours but actually the apparent change in duration is an
artifact, not real! Why do I say that? Because the duration of Joe's
work is still 8 hours and the duration of Bill's work is still 8 hours.
The durations that the two independent pieces of work take place in, as
expressed in the equation W=D*U for each resource assignment, has not
changed at all. All that has changed is the two parts of the task that
were originally scheduled concurrently are now scheduled consecutively.
You always have to keep in mind that W=D*U ONLY applies to the work
performed by a single resource on a single task. I'll admit that
Project is counter-intuitive by not recognizing that the task might
require the two resources to always work together and could be improved
in that regard but once you recognize that Project treats one task with
two resources assigned exactly the same way it treats two independent
tasks with one resource assigned to each, it starts to make sense and
is predictable enough to use for detailed schedule planning.

A way to illustrate what I'm saying most clearly is to make up a simple
project file with a normal task A, a summary task B with subtasks B1
and B2, and a normal task C. A links FS to both B1 and B2, B1 and B2
both link FS to C, but B1 and B2 are not linked to each other in any
way. Assign Joe to B1 and Bill to B2. Change Bill's resource calendar
and B2 will change accordingly while B1 remains the same (and the
duration of the "summary" B changes to reflect the collective duration
between the start of the earliest subtask task and the finish of the
latest subtask). Split B2 in the middle and you'll see the duration of
"summary" B change even though the durations of B1 and B2 remain
exactly the same! That's the exact situation that MS Project is
modeling when you assign multiple resources to a task, except that you
only see the "summary" task B in the schedule, showing up there looking
as if it was a conventional task, and you don't see the "subtasks" at
all (unless you look at the task usage views where you do in fact see
them - shall we call them 'virtual subtasks'? - as two separate rows of
hours, a row for each resource). And that's why I'm saying the change
in duration you're talking about is an artifact - what you're seeing is
the change in duration for the "summary" task while the actual
durations over which each of the component work activities will take
place, the components of the schedule where the equation W=D*U is
inviolate, haven't changed at all.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs



Steve,

See my response embedded in your reply, below.

:

While there certainly are a number of instances of fixed durations in
the
real world, I stand by my guns that they are relatively rare. Fixed
duration means the time it takes to do a task will not be dependent
either
on how hard the resource who does it is working or on how many
man-hours of
work will be required to achieve the tasks deliverable. If the task
is to
make widgets and Joe can produce 10 widgets per hour when he's
devoting his
full attention to it, setting the task to 'fixed duration' would mean
essentially that if we're going to create the 1 day duration task
"Make
Widgets" and put Joe on it, we just don't care how hard he works or
many
widgets he makes - we'll have him work for one day and we'll consider
the
task done regardless of whether there's 1 or 75 widgets produced.
Further,
we'll pay Joe $5 per widget no matter how many he's made at the end
of that
day. All we care about is that he's at the widget workbench for 8
hours.
While that scenario may sometimes be an accurate description of
reality, I
still maintain it doesn't happen that way very often.

OK, but the problem is that I want Joe to be at that workbench with
his
teammate Frank at the same time! What happens though is that if I one
of
them can not make it to that workbench as we planned it, MS Project
incorectly "assumes" that they work independently. Do you know that
when
leveling, MS Project provides the behaviour I expect from a Fixed
Duration
tasks. I'll I'm asking for is that we extend the same behaviour to
the Fixed
duration tasks for when we change resource schedule.


As for not having resource calendars, I suggest you actually NEED to
update
resource calendars to produce a meaningful detailed schedule.

Of course, but as I am trying to tell you if I do that I compromise
the
"fixed" duration.

For example,
we have 1 day day task and we put Joe and Bill both on it We need 16
widgets and each man can produce 1 widgets per working hour IF he's
not
distracted with other duties. Thus the 16 widgets requires a total
of 16
man-hours of work, Joe will do 8 and Bill will do 8. If both guys
work day
shift, this task will begin at 8am and end at 5pm. But if Joe works
days
and Bill works swing, the same task will start at 8am and end at
11pm. If
Joe takes a holiday on Monday the task will start Monday at 3pm and
end
Tuesday at 5pm. If Bill takes a holiday in Monday the task will
start
Monday at 8am and end Tuesday at 11pm. You only get those detailed
schedule
results if you have different calendars to model Joe and Bill's work
hours -
ie, resource calendars and you update them anytime their work hours
change,
regardless of whether they change before or after you assign them to
tasks.
Work only takes place on a task when the resource assigned is there
to do
it - the task's work schedule normally follows the resource schedule
and
it's through updating the resource calendar that you model that
behaviour.
--

Above, you give examples of building widgets for a fixed duration
task.
Why? Who cares! It does not depend on any sort of effort! That's
the
point. I'm looking for a non non-effort driven task regardless of
production
rates/ capabilitis. I'm simply looking to model a deliverable that
requires
the use of some resource(s).

Steve, I don't know why you are not admitting that there are
inconsistancies
at least. Don't get me wrong, I am not attacking MS Project, I really
like
it; I am just trying to make it better.



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


Steve,

I appreciate your input. But I do not think fixed duration
activities are
all that rare. Nevertheless, why bother offering a task task type
called
fixed duration when it is not that at all. So are you saying that
everything
should be set to Fixed Work instead? Same problem! Then don't
bother
updating resource calendars. This means you can only go so far
with
creating
a detailed schedule in MS Project...

See my comments below...


:

I think you are forgetting the technical definition of "duration"
in the
art
of project management is quite different from what one means by
the word
in
everyday speech.

Well, maybe that is part of the problem why people like project
management
poeple who are project managers and not IT folks find using
planning tools
difficult/ frustrating, etc. Tool should always support the
process/
terminology, and not the other way around. I happen to know the
tool well
enough to know that this spells disaster for your schedule.

It is NOT the same thing as elapsed time, ie, the number
of hours between two points on the clock/calendar. Duration is
the
number
of working time units between the start and end times, excluding
any
non-working time. If a task begins Monday at 8am and ends Friday
at 5pm
and
we work 8-12 and 1-5 each day, the task duration is 40 hours.
With those
same start and end times but with a part-time employee who works
Mon,
Tue,
Wed mornings only, then Thur and Fri afternoons only, the duration
is 20
hours. not 40. Think of 'duration' as meaning the number of hours
between
start and end during which work could have been scheduled for the
resource
doing the work, whether it actually was scheduled or not. You see
the
same
thing with a 2 weeks duration task that you split. Try it - enter
a 2
week
task starting Monday. Use the "split task" tool on the toolbar to
add a
1
week gap in the middle of the task. What happens to the duration?
Right,
it stays right at 2 weeks EVEN THOUGH the split task ends a week
later
than
it did before splitting. The reason - the split is non-working
time and
as
far as duration is concerned it doesn't exist.


I know all this. Note, that I love and I accept that Project
levels and
splits task and changes my durations. I do have not problem with
that
kind
of a duration modification. Project's leveling feature gives me
the
"choice" to allow for splits to occur! Changing resource calendars
does
not
give me that choice!

I believe true fixed duration tasks are very rare events, though
they do
exist. If I'm running a burn-in on a new hard drive and it must
run for
24
continuous hours, that's fixed duration. If I pour a concrete
slab that
will take 24 hours to harden, that's fixed duration. A 1 hour
meeting
will
always last 1 hour. But 99.99% of tasks aren't like that -
progress
only
takes place when the resources who do the work are physically
present and
able to do it and so it is logical to use only those clock hours
as the
metric of the required length of time the task will take. Most
of the
time
I think people use fixed duration task types to try to force the
work to
fit
into some preconceived idea of what the schedule ought to look
like or
what
the time-frame is that management thinks people ought to be able
to get
the
work done in. IMHO, that's erroneous thinking, scheduling by time
budget
rather than scheduling through analysis of the work required to
produce
the
deliverables.


I don't think that they are that rare. They are in every project;
we
always
put aside a day here, or a couple of hours there, to (for example)
meet
with
our stakeholders to have a discussion, decision, etc. The problem
is if
we
use duration driven tasks (non-effort driven) to model these
situations
and a
resource takes some time off without going through the proper
chanels, but
Project will not warn us and will mess up the schedule (through the
logical
dependancies that you should set to ensure a dynamic schedule).
This can
happen in a server environment where you have resource managers
updating
calendars of shared resources in the pool.



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


Jack,

This is bad! I don't see any consolation in MS Project behaving
like
it
should with respect to Duration x Units = Work, when as you say
"Work"
changes. In modifying resource availability you are in effect
messing
around
with "Units", so why doesn't it follow through? It should,
right? Or,
have I
lost my mind?

In essence, we should tell users not to use or update the
resource
calendars
while we have projects on-going because you will mess up your
schedule
if
you
are trying to model duration driven tasks. Forget about using
MS
Project
to
develop project schedules that to accommodate resource
schedules. This
is
ludicrous! Why then have resource calendars as a feature?



Jack, don't take it personal... I am just venting... I really
want to
see
this fixed! I hope you have friends on the product management
team you
can
discuss this to see if they can't rectify this. I feel we'll
never
have a
serious project planning tool if we have issues like this.


:

Looks like they are, but some of it is by design.
Microsoft made changes to the fixed duration task behavior in
Microsoft
Office Project 2007. It has changed from previous versions.

Fixed Duration tasks ONLY maintain their duration when
resources
CHANGE.
That is if a resource work changes from 50 hours to 80 hours,
the
units
(rate of work) would change and the duration would be fixed. As
you
have
seen, when you assign a resource to a task, the duration may
collapse.

It seems like this calendar change thing is an unexpected side
effect.

Thanks for the post.

-Jack





I believe that there is a flaw in how Microsoft Project Fixed
Duration
tasks
behave!

The main problem occurs when resources of type Work are
assigned to
a
Fixed
Duration tasks. After such an assignment is in place, if a
change is
made
on
the resource working calendar which conflict with the
assignment
dates,
MS
Project leaves you no choice and adjusts the duration for
those
FIXED
duration and thus forces it to behave like a FIXED Work task.
In
addition,

If there is more than one task that is impacted by an
assigned
resource
that
has had its resource calendar changed in this way, the
warning MS
Project
supplies you will only be for one task and not all affected
tasks,
nor
does
it tell you which resource has caused the change! As such,
you are
not
even
advised that this has occurred beyond one task.

Other anomalies with how Microsoft Project Fixed Duration
tasks
behave
has
to do with how one goes about assigning resource to such
tasks. If
you
were
to use a Task Form like Resource Work or Resource Schedule to
assign
resources, MS Project will go quietly along its way and enter
the
Work
the
resource could provide given their availability. On the
other
hand,
if
you
assign resources using the Assign Resource dialog window
(Alt-F10),
MS
Project responds immediately and informs you that due to the
non
availability
of a resource the Fixed Duration task will adjust to
accommodate the
resource. If you are assigning resources to multiple tasks,
again,
MS
Project will only one tell you about one of them, so you'll
have to
check
if
there are others. At this point you may as well undo the
operation
and
try
assigning the resource(s) task by task to find the problem,
or
better
yet
use
the Available to Work field to proactively assign the
resources!
This
is
the
preferred approach since over-allocations can be avoided.
However,
it
doesn't address the main problem where there change is made
on the
resource
working calendar which conflict with existing assignment
dates!

What one would expect from a Fixed Duration task is that it
behave
like
one
and not like a fixed Work task which is driven by effort,
(e.g., a
meeting
is
typical of a non-effort driven type of event)-it doesn't
matter how
many
people participate (in theory), there should be a finite
start and
Finite

 

[Steve House]

I'll have to find the reference for you but I have seen "task" defined as
the lowest level of the Work Breakdown Structure, describing a work package
to be performed by a single resource or team of resources working as a
single unit (such as your carpenter and his apprentice - neither of them can
work alone so for schedule computation purposes they are one resource even
though they are two individuals). I certainly agree with you that we should
be able to create teams and lock resources together on a given task but for
now we can't. To use it most effectively as it is now we have to accept the
way it is now as just the way it is <grin>.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs




.....
Steve,
I think your explanation of how Project sees a task, the work of a
single resource, is accurate and lucid. OTH, I think this is a major
flaw in Project that should have been corrected many versions back.
Many resources on many kinds of tasks work together. To break down a
project to a one resource per task is simply not acceptable. I've
never heard of this idea in all my years in PM until I came to this
forum. This is simply a major defect of Project, NOT good scheduling
practice. The ability to "bind" resources together should be standard
in any scheduling software, though I don't know if it is.

In project, I can create resources of multiple people. I.e., I can
create a resource called carpenders with 800% availbility if I have 8
carpenders on the project. But this doesn't help if, as in reality,
usually a single carpender works with a single carpender's apprentice.
Of course, we can then create a resource called Carpender Team
composed of one of each. But what about situations where either of
them works, say on a specific task, separately? Or just splits up
temporarily to work on separate tasks? Or I need 3 teams on a one task
for it's duration?

I think Project should have the ability to "bind" resources,
temporarily or permanently together. On some tasks, I could
temporarily bind the Carpender and the Apprentice together for the
duration of the task. On other tasks, assign them separately. On
others, they would be "bound" for part of the task and not "bound" for
the rest of the task. This would also work for other kinds of teams,
like surgical teams or any kind of group whose members may vary from
task to task or project to project.

To have to break projects down to one resource/one task is absurd! It
could easily make a 1,000 task project into a 5,000 task project. I
certainly wouldn't want to have to manage 5,000 tasks when the work is
really 1,000! And it doesn't even accurately represent what is really
happening, that people are frequently working in groups, not solo all
the time.

It's one thing to understand this flaw in Project. It's entirely
another to represent it as good scheduling practice. To quote from
your post,
"In fact, the task types are only consistently meaningful when viewed
in the context of 1 task == 1 resource's work, the classic endpoint in
the breakdown of a complete, fully decomposed, WBS." I'd like to see
some reference in some highly regarded text on PM, like Kerzner or
Lewis, where it says anything like that. I certainly can't recall, in
all my reading and in all the classes I've taken on PM and Scheduling
over the last 30 years, any comment even suggesting that a WBS should
be broken down to one task/one resource level. It's simply an
oversight, at best, or a major flaw, at worst, in Project that it
behaves in this manor.

I'll have to find the reference for you but I have seen "task" defined as a
work package performed by a single resource or team of resources that must
work as a cohesive unit (working together such as a surgical team must work
together even though different members of the team have distinct functions).

 

[Jack Dahlgren]

As far as I know, Summary tasks are exempt from the laws which constrain
ordinary tasks. I don't think that you can set a summary task to be fixed
anything. The option is greyed out.
So the answer to your question is no, you can't do that.

-Jack Dahlgren

Does applying the fixed duration attribute to a summary task consisting of
two or more independently scheduled subtasks lock down the subtasks and
prevent any of them from being moved in such a way that might cause the
summary task duration to change? Would it make scheduling sense if it
did?
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Steve,

I understand what you are trying to say, but it does not appear that you
understand what I am trying to say.

To put it very simply: Sometimes I want a task to behave like its
duration is fixed no matter WHAT it represents. I do this most often
while building very early schedule models. I am not confused about this.
I use it to keep things simple and understandable for me and the rest of
the world. Details come later.

Changing that capability so that it becomes unpredictable (assuming I
exert minimal mental effort) is not a good thing. Give me both, fixed
duration and the hybrid one which does not yet have a good name.

-Jack

What I'm trying to say is that a task with more than one resource
assigned to it is actually multiple tasks. But there is certainly an
ambiguity in that. If I have 2 carpenters and list them in my resource
definitions as Bill Carpenter and Joe Carpenter, each available 100% I
have 2 resources. But if I choose to list them as an aggregate
"Carpenters" available 200% I have only 1 resource. When I have a task
and assign two resources defined as in the first case, it is as if I had
two separate tasks. "Fixed Duration" as defining the constant term in
the equation W=D*U still holds true, but only for each individual
resource's task - it does not hold true for the combination of the two.
OTOH, if I have that same task and assign 'Carpenters, 200%' I have 1
task with only 1 resource, NOT 2 resources, and Fixed Duration / W=D*U
holds true for the whole.

One source of confusion is thinking that the number of resources is
equal to the number of warm bodies. It's not. One could say that as
far as Project is concerned, the number of resources assigned to a task
is more properly the number of distinct resource NAMES listed for the
task. When Joe and Bill are each assigned to the same task, that is 2
resources. But when 2 Carpenters are assigned to a task, that is only
ONE resource. When viewed at the overall task level, it appears that
'fixed duration' is behaving differently in the two cases. In fact, the
task types are only consistently meaningful when viewed in the context
of 1 task == 1 resource's work, the classic endpoint in the breakdown of
a complete, fully decomposed, WBS. When viewed at a summary level, they
may or may not behave the same way. And as I said in my earlier message,
if you assign two resources to a single task, that task is no longer a
single task but for scheduling purposes becomes a summary task with 2
independent subtasks. And just like any other summary task, when the
two subtasks don't run concurrently the total duration may change when
in fact the durations for each of the resource's piece of the total work
does not.

Fixed duration is not the same thing as fixed work because work and
duration are very different metrics, even for one resource. Work is the
amount of effort expended (measures sweat), units is the rate at which
it is expended (measures motivation LOL), and duration is the time over
which it is expended (measures time). But as mentioned before, the
equation W=D*U strictly holds true only for a single resource's (or if
you prefer, a single resource name's) activity. As long as you remember
that, the model becomes perfectly predictable.

Interesting discussion!

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



Steve,

This would be all well and good, but you are essentially saying that
work is fixed not duration. This is the issue. Some people want
duration to be fixed. There is already a fixed work task, but now there
is no longer a real fixed duration task. There is a hybrid task that
acts differently under different conditions. Predictability of the
model is something I rely on.

-Jack


In your example where you say that the task violates fixed duration it
really hasn't. Now before you think me mad, here me out <grin>. The
task is Monday 8am to 5pm, 8 hours in duration, fixed duration. You
assign both Joe and Bill to it. The duration of Bill's work is 8
hours, the duration of Joe's work is 8 hours. Now Bill has something
come up and he has to delay his work by one day and we mark off on his
resource calendar that Monday is, for him, a non-working day but
Tuesday is normal. The task times will now show starting Monday 8am
and ending Tuesday 5pm. So far, so good? It appears the duration is
now 16 hours but actually the apparent change in duration is an
artifact, not real! Why do I say that? Because the duration of Joe's
work is still 8 hours and the duration of Bill's work is still 8
hours. The durations that the two independent pieces of work take
place in, as expressed in the equation W=D*U for each resource
assignment, has not changed at all. All that has changed is the two
parts of the task that were originally scheduled concurrently are now
scheduled consecutively. You always have to keep in mind that W=D*U
ONLY applies to the work performed by a single resource on a single
task. I'll admit that Project is counter-intuitive by not recognizing
that the task might require the two resources to always work together
and could be improved in that regard but once you recognize that
Project treats one task with two resources assigned exactly the same
way it treats two independent tasks with one resource assigned to
each, it starts to make sense and is predictable enough to use for
detailed schedule planning.

A way to illustrate what I'm saying most clearly is to make up a
simple project file with a normal task A, a summary task B with
subtasks B1 and B2, and a normal task C. A links FS to both B1 and
B2, B1 and B2 both link FS to C, but B1 and B2 are not linked to each
other in any way. Assign Joe to B1 and Bill to B2. Change Bill's
resource calendar and B2 will change accordingly while B1 remains the
same (and the duration of the "summary" B changes to reflect the
collective duration between the start of the earliest subtask task and
the finish of the latest subtask). Split B2 in the middle and you'll
see the duration of "summary" B change even though the durations of B1
and B2 remain exactly the same! That's the exact situation that MS
Project is modeling when you assign multiple resources to a task,
except that you only see the "summary" task B in the schedule, showing
up there looking as if it was a conventional task, and you don't see
the "subtasks" at all (unless you look at the task usage views where
you do in fact see them - shall we call them 'virtual subtasks'? - as
two separate rows of hours, a row for each resource). And that's why
I'm saying the change in duration you're talking about is an
artifact - what you're seeing is the change in duration for the
"summary" task while the actual durations over which each of the
component work activities will take place, the components of the
schedule where the equation W=D*U is inviolate, haven't changed at
all.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs



Steve,

See my response embedded in your reply, below.

:

While there certainly are a number of instances of fixed durations
in the
real world, I stand by my guns that they are relatively rare. Fixed
duration means the time it takes to do a task will not be dependent
either
on how hard the resource who does it is working or on how many
man-hours of
work will be required to achieve the tasks deliverable. If the task
is to
make widgets and Joe can produce 10 widgets per hour when he's
devoting his
full attention to it, setting the task to 'fixed duration' would
mean
essentially that if we're going to create the 1 day duration task
"Make
Widgets" and put Joe on it, we just don't care how hard he works or
many
widgets he makes - we'll have him work for one day and we'll
consider the
task done regardless of whether there's 1 or 75 widgets produced.
Further,
we'll pay Joe $5 per widget no matter how many he's made at the end
of that
day. All we care about is that he's at the widget workbench for 8
hours.
While that scenario may sometimes be an accurate description of
reality, I
still maintain it doesn't happen that way very often.

OK, but the problem is that I want Joe to be at that workbench with
his
teammate Frank at the same time! What happens though is that if I
one of
them can not make it to that workbench as we planned it, MS Project
incorectly "assumes" that they work independently. Do you know that
when
leveling, MS Project provides the behaviour I expect from a Fixed
Duration
tasks. I'll I'm asking for is that we extend the same behaviour to
the Fixed
duration tasks for when we change resource schedule.


As for not having resource calendars, I suggest you actually NEED to
update
resource calendars to produce a meaningful detailed schedule.

Of course, but as I am trying to tell you if I do that I compromise
the
"fixed" duration.

For example,
we have 1 day day task and we put Joe and Bill both on it We need
16
widgets and each man can produce 1 widgets per working hour IF he's
not
distracted with other duties. Thus the 16 widgets requires a total
of 16
man-hours of work, Joe will do 8 and Bill will do 8. If both guys
work day
shift, this task will begin at 8am and end at 5pm. But if Joe works
days
and Bill works swing, the same task will start at 8am and end at
11pm. If
Joe takes a holiday on Monday the task will start Monday at 3pm and
end
Tuesday at 5pm. If Bill takes a holiday in Monday the task will
start
Monday at 8am and end Tuesday at 11pm. You only get those detailed
schedule
results if you have different calendars to model Joe and Bill's work
hours -
ie, resource calendars and you update them anytime their work hours
change,
regardless of whether they change before or after you assign them to
tasks.
Work only takes place on a task when the resource assigned is there
to do
it - the task's work schedule normally follows the resource schedule
and
it's through updating the resource calendar that you model that
behaviour.
--

Above, you give examples of building widgets for a fixed duration
task.
Why? Who cares! It does not depend on any sort of effort! That's
the
point. I'm looking for a non non-effort driven task regardless of
production
rates/ capabilitis. I'm simply looking to model a deliverable that
requires
the use of some resource(s).

Steve, I don't know why you are not admitting that there are
inconsistancies
at least. Don't get me wrong, I am not attacking MS Project, I
really like
it; I am just trying to make it better.



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


Steve,

I appreciate your input. But I do not think fixed duration
activities are
all that rare. Nevertheless, why bother offering a task task type
called
fixed duration when it is not that at all. So are you saying that
everything
should be set to Fixed Work instead? Same problem! Then don't
bother
updating resource calendars. This means you can only go so far
with
creating
a detailed schedule in MS Project...

See my comments below...


:

I think you are forgetting the technical definition of "duration"
in the
art
of project management is quite different from what one means by
the word
in
everyday speech.

Well, maybe that is part of the problem why people like project
management
poeple who are project managers and not IT folks find using
planning tools
difficult/ frustrating, etc. Tool should always support the
process/
terminology, and not the other way around. I happen to know the
tool well
enough to know that this spells disaster for your schedule.

It is NOT the same thing as elapsed time, ie, the number
of hours between two points on the clock/calendar. Duration is
the
number
of working time units between the start and end times, excluding
any
non-working time. If a task begins Monday at 8am and ends Friday
at 5pm
and
we work 8-12 and 1-5 each day, the task duration is 40 hours.
With those
same start and end times but with a part-time employee who works
Mon,
Tue,
Wed mornings only, then Thur and Fri afternoons only, the
duration is 20
hours. not 40. Think of 'duration' as meaning the number of
hours
between
start and end during which work could have been scheduled for the
resource
doing the work, whether it actually was scheduled or not. You
see the
same
thing with a 2 weeks duration task that you split. Try it -
enter a 2
week
task starting Monday. Use the "split task" tool on the toolbar
to add a
1
week gap in the middle of the task. What happens to the
duration?
Right,
it stays right at 2 weeks EVEN THOUGH the split task ends a week
later
than
it did before splitting. The reason - the split is non-working
time and
as
far as duration is concerned it doesn't exist.


I know all this. Note, that I love and I accept that Project
levels and
splits task and changes my durations. I do have not problem with
that
kind
of a duration modification. Project's leveling feature gives me
the
"choice" to allow for splits to occur! Changing resource
calendars does
not
give me that choice!

I believe true fixed duration tasks are very rare events, though
they do
exist. If I'm running a burn-in on a new hard drive and it must
run for
24
continuous hours, that's fixed duration. If I pour a concrete
slab that
will take 24 hours to harden, that's fixed duration. A 1 hour
meeting
will
always last 1 hour. But 99.99% of tasks aren't like that -
progress
only
takes place when the resources who do the work are physically
present and
able to do it and so it is logical to use only those clock hours
as the
metric of the required length of time the task will take. Most
of the
time
I think people use fixed duration task types to try to force the
work to
fit
into some preconceived idea of what the schedule ought to look
like or
what
the time-frame is that management thinks people ought to be able
to get
the
work done in. IMHO, that's erroneous thinking, scheduling by
time budget
rather than scheduling through analysis of the work required to
produce
the
deliverables.


I don't think that they are that rare. They are in every project;
we
always
put aside a day here, or a couple of hours there, to (for example)
meet
with
our stakeholders to have a discussion, decision, etc. The problem
is if
we
use duration driven tasks (non-effort driven) to model these
situations
and a
resource takes some time off without going through the proper
chanels, but
Project will not warn us and will mess up the schedule (through
the
logical
dependancies that you should set to ensure a dynamic schedule).
This can
happen in a server environment where you have resource managers
updating
calendars of shared resources in the pool.



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


Jack,

This is bad! I don't see any consolation in MS Project
behaving like
it
should with respect to Duration x Units = Work, when as you say
"Work"
changes. In modifying resource availability you are in effect
messing
around
with "Units", so why doesn't it follow through? It should,
right? Or,
have I
lost my mind?

In essence, we should tell users not to use or update the
resource
calendars
while we have projects on-going because you will mess up your
schedule
if
you
are trying to model duration driven tasks. Forget about using
MS
Project
to
develop project schedules that to accommodate resource
schedules. This
is
ludicrous! Why then have resource calendars as a feature?



Jack, don't take it personal... I am just venting... I really
want to
see
this fixed! I hope you have friends on the product management
team you
can
discuss this to see if they can't rectify this. I feel we'll
never
have a
serious project planning tool if we have issues like this.


:

Looks like they are, but some of it is by design.
Microsoft made changes to the fixed duration task behavior in
Microsoft
Office Project 2007. It has changed from previous versions.

Fixed Duration tasks ONLY maintain their duration when
resources
CHANGE.
That is if a resource work changes from 50 hours to 80 hours,
the
units
(rate of work) would change and the duration would be fixed.
As you
have
seen, when you assign a resource to a task, the duration may
collapse.

It seems like this calendar change thing is an unexpected side
effect.

Thanks for the post.

-Jack





I believe that there is a flaw in how Microsoft Project Fixed
Duration
tasks
behave!

The main problem occurs when resources of type Work are
assigned to
a
Fixed
Duration tasks. After such an assignment is in place, if a
change is
made
on
the resource working calendar which conflict with the
assignment
dates,
MS
Project leaves you no choice and adjusts the duration for
those
FIXED
duration and thus forces it to behave like a FIXED Work
task. In
addition,

If there is more than one task that is impacted by an
assigned
resource
that
has had its resource calendar changed in this way, the
warning MS
Project
supplies you will only be for one task and not all affected
tasks,
nor
does
it tell you which resource has caused the change! As such,
you are
not
even
advised that this has occurred beyond one task.

Other anomalies with how Microsoft Project Fixed Duration
tasks
behave
has
to do with how one goes about assigning resource to such
tasks. If
you
were
to use a Task Form like Resource Work or Resource Schedule
to assign
resources, MS Project will go quietly along its way and
enter the
Work
the
resource could provide given their availability. On the
other
hand,
if
you
assign resources using the Assign Resource dialog window
(Alt-F10),
MS
Project responds immediately and informs you that due to the
non
availability
of a resource the Fixed Duration task will adjust to
accommodate the
resource. If you are assigning resources to multiple tasks,
again,
MS
Project will only one tell you about one of them, so you'll
have to
check
if
there are others. At this point you may as well undo the
operation
and
try
assigning the resource(s) task by task to find the problem,
or
better
yet
use
the Available to Work field to proactively assign the
resources!
This
is
the
preferred approach since over-allocations can be avoided.
However,
it
doesn't address the main problem where there change is made
on the
resource
working calendar which conflict with existing assignment
dates!

What one would expect from a Fixed Duration task is that it
behave
like
one
and not like a fixed Work task which is driven by effort,
(e.g., a
meeting
is
typical of a non-effort driven type of event)-it doesn't
matter how
many
people participate (in theory), there should be a finite
start and
Finite

 

[davegb]

I'll have to find the reference for you but I have seen "task" defined as
the lowest level of the Work Breakdown Structure, describing a work package
to be performed by a single resource or team of resources working as a
single unit (such as your carpenter and his apprentice - neither of them can
work alone so for schedule computation purposes they are one resource even
though they are two individuals). I certainly agree with you that we should
be able to create teams and lock resources together on a given task but for
now we can't. To use it most effectively as it is now we have to accept the
way it is now as just the way it is <grin>.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visithttp://www.mvps.org/project/faqs.htmfor the FAQs


....
Steve,
I think your explanation of how Project sees a task, the work of a
single resource, is accurate and lucid. OTH, I think this is a major
flaw in Project that should have been corrected many versions back.
Many resources on many kinds of tasks work together. To break down a
project to a one resource per task is simply not acceptable. I've
never heard of this idea in all my years in PM until I came to this
forum. This is simply a major defect of Project, NOT good scheduling
practice. The ability to "bind" resources together should be standard
in any scheduling software, though I don't know if it is.

In project, I can create resources of multiple people. I.e., I can
create a resource called carpenders with 800% availbility if I have 8
carpenders on the project. But this doesn't help if, as in reality,
usually a single carpender works with a single carpender's apprentice.
Of course, we can then create a resource called Carpender Team
composed of one of each. But what about situations where either of
them works, say on a specific task, separately? Or just splits up
temporarily to work on separate tasks? Or I need 3 teams on a one task
for it's duration?

I think Project should have the ability to "bind" resources,
temporarily or permanently together. On some tasks, I could
temporarily bind the Carpender and the Apprentice together for the
duration of the task. On other tasks, assign them separately. On
others, they would be "bound" for part of the task and not "bound" for
the rest of the task. This would also work for other kinds of teams,
like surgical teams or any kind of group whose members may vary from
task to task or project to project.

To have to break projects down to one resource/one task is absurd! It
could easily make a 1,000 task project into a 5,000 task project. I
certainly wouldn't want to have to manage 5,000 tasks when the work is
really 1,000! And it doesn't even accurately represent what is really
happening, that people are frequently working in groups, not solo all
the time.

It's one thing to understand this flaw in Project. It's entirely
another to represent it as good scheduling practice. To quote from
your post,
"In fact, the task types are only consistently meaningful when viewed
in the context of 1 task == 1 resource's work, the classic endpoint in
the breakdown of a complete, fully decomposed, WBS." I'd like to see
some reference in some highly regarded text on PM, like Kerzner or
Lewis, where it says anything like that. I certainly can't recall, in
all my reading and in all the classes I've taken on PM and Scheduling
over the last 30 years, any comment even suggesting that a WBS should
be broken down to one task/one resource level. It's simply an
oversight, at best, or a major flaw, at worst, in Project that it
behaves in this manor.

I'll have to find the reference for you but I have seen "task" defined as a
work package performed by a single resource or team of resources that must
work as a cohesive unit (working together such as a surgical team must work
together even though different members of the team have distinct functions).

I heartily agree to that definition: "I have seen "task" defined as
the lowest level of the Work Breakdown Structure, describing a work
package to be performed by a single resource or team of resources
working as a single unit (such as your carpenter and his apprentice -
neither of them can work alone so for schedule computation purposes
they are one resource even though they are two individuals." It
mentions "team of resources". Which Project doesn't really recognize,
unfortunately. The definition doesn't state so, but obviously, that
team is composed of individuals, who may or may not always be on the
team.

In any case, I wanted it clear to others than might be looking here
that a WBS is NOT normally broken down to individuals' efforts. Thank
goodness!

 

[Steve House]

LOL - I knew that. That's what I get for asking rhetorical questions!


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

As far as I know, Summary tasks are exempt from the laws which constrain
ordinary tasks. I don't think that you can set a summary task to be fixed
anything. The option is greyed out.
So the answer to your question is no, you can't do that.

-Jack Dahlgren

Does applying the fixed duration attribute to a summary task consisting
of two or more independently scheduled subtasks lock down the subtasks
and prevent any of them from being moved in such a way that might cause
the summary task duration to change? Would it make scheduling sense if
it did?
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Steve,

I understand what you are trying to say, but it does not appear that you
understand what I am trying to say.

To put it very simply: Sometimes I want a task to behave like its
duration is fixed no matter WHAT it represents. I do this most often
while building very early schedule models. I am not confused about this.
I use it to keep things simple and understandable for me and the rest of
the world. Details come later.

Changing that capability so that it becomes unpredictable (assuming I
exert minimal mental effort) is not a good thing. Give me both, fixed
duration and the hybrid one which does not yet have a good name.

-Jack







What I'm trying to say is that a task with more than one resource
assigned to it is actually multiple tasks. But there is certainly an
ambiguity in that. If I have 2 carpenters and list them in my resource
definitions as Bill Carpenter and Joe Carpenter, each available 100% I
have 2 resources. But if I choose to list them as an aggregate
"Carpenters" available 200% I have only 1 resource. When I have a task
and assign two resources defined as in the first case, it is as if I
had two separate tasks. "Fixed Duration" as defining the constant term
in the equation W=D*U still holds true, but only for each individual
resource's task - it does not hold true for the combination of the two.
OTOH, if I have that same task and assign 'Carpenters, 200%' I have 1
task with only 1 resource, NOT 2 resources, and Fixed Duration / W=D*U
holds true for the whole.

One source of confusion is thinking that the number of resources is
equal to the number of warm bodies. It's not. One could say that as
far as Project is concerned, the number of resources assigned to a task
is more properly the number of distinct resource NAMES listed for the
task. When Joe and Bill are each assigned to the same task, that is 2
resources. But when 2 Carpenters are assigned to a task, that is only
ONE resource. When viewed at the overall task level, it appears that
'fixed duration' is behaving differently in the two cases. In fact,
the task types are only consistently meaningful when viewed in the
context of 1 task == 1 resource's work, the classic endpoint in the
breakdown of a complete, fully decomposed, WBS. When viewed at a
summary level, they may or may not behave the same way. And as I said
in my earlier message, if you assign two resources to a single task,
that task is no longer a single task but for scheduling purposes
becomes a summary task with 2 independent subtasks. And just like any
other summary task, when the two subtasks don't run concurrently the
total duration may change when in fact the durations for each of the
resource's piece of the total work does not.

Fixed duration is not the same thing as fixed work because work and
duration are very different metrics, even for one resource. Work is
the amount of effort expended (measures sweat), units is the rate at
which it is expended (measures motivation LOL), and duration is the
time over which it is expended (measures time). But as mentioned
before, the equation W=D*U strictly holds true only for a single
resource's (or if you prefer, a single resource name's) activity. As
long as you remember that, the model becomes perfectly predictable.

Interesting discussion!

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



Steve,

This would be all well and good, but you are essentially saying that
work is fixed not duration. This is the issue. Some people want
duration to be fixed. There is already a fixed work task, but now
there is no longer a real fixed duration task. There is a hybrid task
that acts differently under different conditions. Predictability of
the model is something I rely on.

-Jack


In your example where you say that the task violates fixed duration
it really hasn't. Now before you think me mad, here me out <grin>.
The task is Monday 8am to 5pm, 8 hours in duration, fixed duration.
You assign both Joe and Bill to it. The duration of Bill's work is 8
hours, the duration of Joe's work is 8 hours. Now Bill has something
come up and he has to delay his work by one day and we mark off on
his resource calendar that Monday is, for him, a non-working day but
Tuesday is normal. The task times will now show starting Monday 8am
and ending Tuesday 5pm. So far, so good? It appears the duration is
now 16 hours but actually the apparent change in duration is an
artifact, not real! Why do I say that? Because the duration of Joe's
work is still 8 hours and the duration of Bill's work is still 8
hours. The durations that the two independent pieces of work take
place in, as expressed in the equation W=D*U for each resource
assignment, has not changed at all. All that has changed is the two
parts of the task that were originally scheduled concurrently are now
scheduled consecutively. You always have to keep in mind that W=D*U
ONLY applies to the work performed by a single resource on a single
task. I'll admit that Project is counter-intuitive by not recognizing
that the task might require the two resources to always work together
and could be improved in that regard but once you recognize that
Project treats one task with two resources assigned exactly the same
way it treats two independent tasks with one resource assigned to
each, it starts to make sense and is predictable enough to use for
detailed schedule planning.

A way to illustrate what I'm saying most clearly is to make up a
simple project file with a normal task A, a summary task B with
subtasks B1 and B2, and a normal task C. A links FS to both B1 and
B2, B1 and B2 both link FS to C, but B1 and B2 are not linked to each
other in any way. Assign Joe to B1 and Bill to B2. Change Bill's
resource calendar and B2 will change accordingly while B1 remains the
same (and the duration of the "summary" B changes to reflect the
collective duration between the start of the earliest subtask task
and the finish of the latest subtask). Split B2 in the middle and
you'll see the duration of "summary" B change even though the
durations of B1 and B2 remain exactly the same! That's the exact
situation that MS Project is modeling when you assign multiple
resources to a task, except that you only see the "summary" task B in
the schedule, showing up there looking as if it was a conventional
task, and you don't see the "subtasks" at all (unless you look at the
task usage views where you do in fact see them - shall we call them
'virtual subtasks'? - as two separate rows of hours, a row for each
resource). And that's why I'm saying the change in duration you're
talking about is an artifact - what you're seeing is the change in
duration for the "summary" task while the actual durations over which
each of the component work activities will take place, the components
of the schedule where the equation W=D*U is inviolate, haven't
changed at all.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs



Steve,

See my response embedded in your reply, below.

:

While there certainly are a number of instances of fixed durations
in the
real world, I stand by my guns that they are relatively rare.
Fixed
duration means the time it takes to do a task will not be dependent
either
on how hard the resource who does it is working or on how many
man-hours of
work will be required to achieve the tasks deliverable. If the
task is to
make widgets and Joe can produce 10 widgets per hour when he's
devoting his
full attention to it, setting the task to 'fixed duration' would
mean
essentially that if we're going to create the 1 day duration task
"Make
Widgets" and put Joe on it, we just don't care how hard he works or
many
widgets he makes - we'll have him work for one day and we'll
consider the
task done regardless of whether there's 1 or 75 widgets produced.
Further,
we'll pay Joe $5 per widget no matter how many he's made at the end
of that
day. All we care about is that he's at the widget workbench for 8
hours.
While that scenario may sometimes be an accurate description of
reality, I
still maintain it doesn't happen that way very often.

OK, but the problem is that I want Joe to be at that workbench with
his
teammate Frank at the same time! What happens though is that if I
one of
them can not make it to that workbench as we planned it, MS Project
incorectly "assumes" that they work independently. Do you know that
when
leveling, MS Project provides the behaviour I expect from a Fixed
Duration
tasks. I'll I'm asking for is that we extend the same behaviour to
the Fixed
duration tasks for when we change resource schedule.


As for not having resource calendars, I suggest you actually NEED
to update
resource calendars to produce a meaningful detailed schedule.

Of course, but as I am trying to tell you if I do that I compromise
the
"fixed" duration.

For example,
we have 1 day day task and we put Joe and Bill both on it We need
16
widgets and each man can produce 1 widgets per working hour IF he's
not
distracted with other duties. Thus the 16 widgets requires a total
of 16
man-hours of work, Joe will do 8 and Bill will do 8. If both guys
work day
shift, this task will begin at 8am and end at 5pm. But if Joe
works days
and Bill works swing, the same task will start at 8am and end at
11pm. If
Joe takes a holiday on Monday the task will start Monday at 3pm and
end
Tuesday at 5pm. If Bill takes a holiday in Monday the task will
start
Monday at 8am and end Tuesday at 11pm. You only get those detailed
schedule
results if you have different calendars to model Joe and Bill's
work hours -
ie, resource calendars and you update them anytime their work hours
change,
regardless of whether they change before or after you assign them
to tasks.
Work only takes place on a task when the resource assigned is there
to do
it - the task's work schedule normally follows the resource
schedule and
it's through updating the resource calendar that you model that
behaviour.
--

Above, you give examples of building widgets for a fixed duration
task.
Why? Who cares! It does not depend on any sort of effort! That's
the
point. I'm looking for a non non-effort driven task regardless of
production
rates/ capabilitis. I'm simply looking to model a deliverable that
requires
the use of some resource(s).

Steve, I don't know why you are not admitting that there are
inconsistancies
at least. Don't get me wrong, I am not attacking MS Project, I
really like
it; I am just trying to make it better.



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


Steve,

I appreciate your input. But I do not think fixed duration
activities are
all that rare. Nevertheless, why bother offering a task task
type called
fixed duration when it is not that at all. So are you saying
that
everything
should be set to Fixed Work instead? Same problem! Then don't
bother
updating resource calendars. This means you can only go so far
with
creating
a detailed schedule in MS Project...

See my comments below...


:

I think you are forgetting the technical definition of
"duration" in the
art
of project management is quite different from what one means by
the word
in
everyday speech.

Well, maybe that is part of the problem why people like project
management
poeple who are project managers and not IT folks find using
planning tools
difficult/ frustrating, etc. Tool should always support the
process/
terminology, and not the other way around. I happen to know the
tool well
enough to know that this spells disaster for your schedule.

It is NOT the same thing as elapsed time, ie, the number
of hours between two points on the clock/calendar. Duration is
the
number
of working time units between the start and end times, excluding
any
non-working time. If a task begins Monday at 8am and ends
Friday at 5pm
and
we work 8-12 and 1-5 each day, the task duration is 40 hours.
With those
same start and end times but with a part-time employee who works
Mon,
Tue,
Wed mornings only, then Thur and Fri afternoons only, the
duration is 20
hours. not 40. Think of 'duration' as meaning the number of
hours
between
start and end during which work could have been scheduled for
the
resource
doing the work, whether it actually was scheduled or not. You
see the
same
thing with a 2 weeks duration task that you split. Try it -
enter a 2
week
task starting Monday. Use the "split task" tool on the toolbar
to add a
1
week gap in the middle of the task. What happens to the
duration?
Right,
it stays right at 2 weeks EVEN THOUGH the split task ends a week
later
than
it did before splitting. The reason - the split is non-working
time and
as
far as duration is concerned it doesn't exist.


I know all this. Note, that I love and I accept that Project
levels and
splits task and changes my durations. I do have not problem with
that
kind
of a duration modification. Project's leveling feature gives me
the
"choice" to allow for splits to occur! Changing resource
calendars does
not
give me that choice!

I believe true fixed duration tasks are very rare events, though
they do
exist. If I'm running a burn-in on a new hard drive and it must
run for
24
continuous hours, that's fixed duration. If I pour a concrete
slab that
will take 24 hours to harden, that's fixed duration. A 1 hour
meeting
will
always last 1 hour. But 99.99% of tasks aren't like that -
progress
only
takes place when the resources who do the work are physically
present and
able to do it and so it is logical to use only those clock hours
as the
metric of the required length of time the task will take. Most
of the
time
I think people use fixed duration task types to try to force the
work to
fit
into some preconceived idea of what the schedule ought to look
like or
what
the time-frame is that management thinks people ought to be able
to get
the
work done in. IMHO, that's erroneous thinking, scheduling by
time budget
rather than scheduling through analysis of the work required to
produce
the
deliverables.


I don't think that they are that rare. They are in every
project; we
always
put aside a day here, or a couple of hours there, to (for
example) meet
with
our stakeholders to have a discussion, decision, etc. The
problem is if
we
use duration driven tasks (non-effort driven) to model these
situations
and a
resource takes some time off without going through the proper
chanels, but
Project will not warn us and will mess up the schedule (through
the
logical
dependancies that you should set to ensure a dynamic schedule).
This can
happen in a server environment where you have resource managers
updating
calendars of shared resources in the pool.



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


Jack,

This is bad! I don't see any consolation in MS Project
behaving like
it
should with respect to Duration x Units = Work, when as you
say "Work"
changes. In modifying resource availability you are in effect
messing
around
with "Units", so why doesn't it follow through? It should,
right? Or,
have I
lost my mind?

In essence, we should tell users not to use or update the
resource
calendars
while we have projects on-going because you will mess up your
schedule
if
you
are trying to model duration driven tasks. Forget about using
MS
Project
to
develop project schedules that to accommodate resource
schedules. This
is
ludicrous! Why then have resource calendars as a feature?



Jack, don't take it personal... I am just venting... I really
want to
see
this fixed! I hope you have friends on the product management
team you
can
discuss this to see if they can't rectify this. I feel we'll
never
have a
serious project planning tool if we have issues like this.


:

Looks like they are, but some of it is by design.
Microsoft made changes to the fixed duration task behavior in
Microsoft
Office Project 2007. It has changed from previous versions.

Fixed Duration tasks ONLY maintain their duration when
resources
CHANGE.
That is if a resource work changes from 50 hours to 80 hours,
the
units
(rate of work) would change and the duration would be fixed.
As you
have
seen, when you assign a resource to a task, the duration may
collapse.

It seems like this calendar change thing is an unexpected
side effect.

Thanks for the post.

-Jack





I believe that there is a flaw in how Microsoft Project
Fixed
Duration
tasks
behave!

The main problem occurs when resources of type Work are
assigned to
a
Fixed
Duration tasks. After such an assignment is in place, if a
change is
made
on
the resource working calendar which conflict with the
assignment
dates,
MS
Project leaves you no choice and adjusts the duration for
those
FIXED
duration and thus forces it to behave like a FIXED Work
task. In
addition,

If there is more than one task that is impacted by an
assigned
resource
that
has had its resource calendar changed in this way, the
warning MS
Project
supplies you will only be for one task and not all affected
tasks,
nor
does
it tell you which resource has caused the change! As such,
you are
not
even
advised that this has occurred beyond one task.

Other anomalies with how Microsoft Project Fixed Duration
tasks
behave
has
to do with how one goes about assigning resource to such
tasks. If
you
were
to use a Task Form like Resource Work or Resource Schedule
to assign
resources, MS Project will go quietly along its way and
enter the
Work
the
resource could provide given their availability. On the
other
hand,
if
you
assign resources using the Assign Resource dialog window
(Alt-F10),
MS
Project responds immediately and informs you that due to
the non
availability
of a resource the Fixed Duration task will adjust to
accommodate the
resource. If you are assigning resources to multiple
tasks, again,
MS
Project will only one tell you about one of them, so you'll
have to
check
if
there are others. At this point you may as well undo the
operation
and
try
assigning the resource(s) task by task to find the problem,
or
better
yet
use
the Available to Work field to proactively assign the
resources!
This
is
the
preferred approach since over-allocations can be avoided.
However,
it
doesn't address the main problem where there change is made
on the
resource
working calendar which conflict with existing assignment
dates!

What one would expect from a Fixed Duration task is that it
behave
like
one
and not like a fixed Work task which is driven by effort,
(e.g., a
meeting
is
typical of a non-effort driven type of event)-it doesn't
matter how
many
people participate (in theory), there should be a finite
start and
Finite

 

[Steve House]

We agree - I should have been clearer when I initially mentioned the idea of
a single resource that that was not synonymous with "single person." That's
why I teach, BTW, that when you have aggregate resources that work different
shifts, they need to be split out into several names. If we have 20
welders, 10 on days, 5 on swing, and 5 on grave we can't list them as
"Welders, 2000%." Instead, there needs to be "Day Welders, 1000%," "Swing
Welders, 500%," and "Grave Welders, 500%." Why? Because the task's
schedule will be different if you put 4 day shift workers on it versus
putting 2 day shift and 2 swing shift. It also relates to my discussion of
the handling of tasks with multiple resources assigned ... in this
definition it's impossible for the different members of the resource
collection on the task to have different calendars because if they are able
to work independently, they aren't a resource team by definition. To be a
true team, if Joe books off on Monday his partner Bill MUST also take Monday
off because Bill can't do any work if Joe isn't also there. We don't need
to break down all the way if they will normally work together but if for
some reason they do need to be scheduled independently (such as the
resources each having differing resource calendars), then the task should
become a summary with subtasks for each individual resource' work package.

 

[SpiroT]

I'll have to find the reference for you but I have seen "task" defined as
the lowest level of the Work Breakdown Structure, describing a work package
to be performed by a single resource or team of resources working as a
single unit (such as your carpenter and his apprentice - neither of them can
work alone so for schedule computation purposes they are one resource even
though they are two individuals). I certainly agree with you that we should
be able to create teams and lock resources together on a given task but for
now we can't. To use it most effectively as it is now we have to accept the
way it is now as just the way it is <grin>.

Excuse me?! There is no way I can accept the way it is now! This is an
obvious fault here! We can't just sweep it under the rug. Besides, even if
we do what you suggest, and leave it as is, there are 2 different behaviours
for the same operation. Ie., Try assigning 2 resources using the Assign
Resource (Alt-F10) and then try doing the same operation via the Task Form
(e.g., Resource Work). Before you assign the resources, make sure that you
set one of the 2 resources to have some non-working time during these Fixed
Duration non-effort driven tasks and see what you get!!!--2 different
scenarios!!! It is absurd!!!

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




.....
Steve,
I think your explanation of how Project sees a task, the work of a
single resource, is accurate and lucid. OTH, I think this is a major
flaw in Project that should have been corrected many versions back.
Many resources on many kinds of tasks work together. To break down a
project to a one resource per task is simply not acceptable. I've
never heard of this idea in all my years in PM until I came to this
forum. This is simply a major defect of Project, NOT good scheduling
practice. The ability to "bind" resources together should be standard
in any scheduling software, though I don't know if it is.

In project, I can create resources of multiple people. I.e., I can
create a resource called carpenders with 800% availbility if I have 8
carpenders on the project. But this doesn't help if, as in reality,
usually a single carpender works with a single carpender's apprentice.
Of course, we can then create a resource called Carpender Team
composed of one of each. But what about situations where either of
them works, say on a specific task, separately? Or just splits up
temporarily to work on separate tasks? Or I need 3 teams on a one task
for it's duration?

I think Project should have the ability to "bind" resources,
temporarily or permanently together. On some tasks, I could
temporarily bind the Carpender and the Apprentice together for the
duration of the task. On other tasks, assign them separately. On
others, they would be "bound" for part of the task and not "bound" for
the rest of the task. This would also work for other kinds of teams,
like surgical teams or any kind of group whose members may vary from
task to task or project to project.

To have to break projects down to one resource/one task is absurd! It
could easily make a 1,000 task project into a 5,000 task project. I
certainly wouldn't want to have to manage 5,000 tasks when the work is
really 1,000! And it doesn't even accurately represent what is really
happening, that people are frequently working in groups, not solo all
the time.

It's one thing to understand this flaw in Project. It's entirely
another to represent it as good scheduling practice. To quote from
your post,
"In fact, the task types are only consistently meaningful when viewed
in the context of 1 task == 1 resource's work, the classic endpoint in
the breakdown of a complete, fully decomposed, WBS." I'd like to see
some reference in some highly regarded text on PM, like Kerzner or
Lewis, where it says anything like that. I certainly can't recall, in
all my reading and in all the classes I've taken on PM and Scheduling
over the last 30 years, any comment even suggesting that a WBS should
be broken down to one task/one resource level. It's simply an
oversight, at best, or a major flaw, at worst, in Project that it
behaves in this manor.

I'll have to find the reference for you but I have seen "task" defined as a
work package performed by a single resource or team of resources that must
work as a cohesive unit (working together such as a surgical team must work
together even though different members of the team have distinct functions).

 

[Jack Dahlgren]

I'm with Spiro T. If the results of the same (effective) action do not have
the same result, then the application is faulty. I'm not talking about
switching order of operation, just doing the same thing in another
supposedly equivalent manner.

-Jack

I'll have to find the reference for you but I have seen "task" defined
as
the lowest level of the Work Breakdown Structure, describing a work
package
to be performed by a single resource or team of resources working as a
single unit (such as your carpenter and his apprentice - neither of them
can
work alone so for schedule computation purposes they are one resource
even
though they are two individuals). I certainly agree with you that we
should
be able to create teams and lock resources together on a given task but
for
now we can't. To use it most effectively as it is now we have to accept
the
way it is now as just the way it is <grin>.

Excuse me?! There is no way I can accept the way it is now! This is an
obvious fault here! We can't just sweep it under the rug. Besides, even
if
we do what you suggest, and leave it as is, there are 2 different
behaviours
for the same operation. Ie., Try assigning 2 resources using the Assign
Resource (Alt-F10) and then try doing the same operation via the Task Form
(e.g., Resource Work). Before you assign the resources, make sure that
you
set one of the 2 resources to have some non-working time during these
Fixed
Duration non-effort driven tasks and see what you get!!!--2 different
scenarios!!! It is absurd!!!

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




.....
Steve,
I think your explanation of how Project sees a task, the work of a
single resource, is accurate and lucid. OTH, I think this is a major
flaw in Project that should have been corrected many versions back.
Many resources on many kinds of tasks work together. To break down a
project to a one resource per task is simply not acceptable. I've
never heard of this idea in all my years in PM until I came to this
forum. This is simply a major defect of Project, NOT good scheduling
practice. The ability to "bind" resources together should be standard
in any scheduling software, though I don't know if it is.

In project, I can create resources of multiple people. I.e., I can
create a resource called carpenders with 800% availbility if I have 8
carpenders on the project. But this doesn't help if, as in reality,
usually a single carpender works with a single carpender's apprentice.
Of course, we can then create a resource called Carpender Team
composed of one of each. But what about situations where either of
them works, say on a specific task, separately? Or just splits up
temporarily to work on separate tasks? Or I need 3 teams on a one task
for it's duration?

I think Project should have the ability to "bind" resources,
temporarily or permanently together. On some tasks, I could
temporarily bind the Carpender and the Apprentice together for the
duration of the task. On other tasks, assign them separately. On
others, they would be "bound" for part of the task and not "bound" for
the rest of the task. This would also work for other kinds of teams,
like surgical teams or any kind of group whose members may vary from
task to task or project to project.

To have to break projects down to one resource/one task is absurd! It
could easily make a 1,000 task project into a 5,000 task project. I
certainly wouldn't want to have to manage 5,000 tasks when the work is
really 1,000! And it doesn't even accurately represent what is really
happening, that people are frequently working in groups, not solo all
the time.

It's one thing to understand this flaw in Project. It's entirely
another to represent it as good scheduling practice. To quote from
your post,
"In fact, the task types are only consistently meaningful when viewed
in the context of 1 task == 1 resource's work, the classic endpoint in
the breakdown of a complete, fully decomposed, WBS." I'd like to see
some reference in some highly regarded text on PM, like Kerzner or
Lewis, where it says anything like that. I certainly can't recall, in
all my reading and in all the classes I've taken on PM and Scheduling
over the last 30 years, any comment even suggesting that a WBS should
be broken down to one task/one resource level. It's simply an
oversight, at best, or a major flaw, at worst, in Project that it
behaves in this manor.

I'll have to find the reference for you but I have seen "task" defined
as a
work package performed by a single resource or team of resources that
must
work as a cohesive unit (working together such as a surgical team must
work
together even though different members of the team have distinct
functions).

 

[SpiroT]

Dave,

Glad to see you join in on the thread. However, I think we have started
getting a off the point. We've gone in now looking at definitions of what a
task is. I don't think this is helping us. Ultimately, we have
"assignments" when we marry a resource to tasks, and MS Project allows us to
have multiple assignments per task which I think is great. Debating if we
should only have one assignment per task because that is how PMI defines a
work package is ludicrous.

Moreover, the problem persists. Do you think we can somehow all bind
together here somehow to inluence Microsoft do something to fix this?

I'll have to find the reference for you but I have seen "task" defined as
the lowest level of the Work Breakdown Structure, describing a work package
to be performed by a single resource or team of resources working as a
single unit (such as your carpenter and his apprentice - neither of them can
work alone so for schedule computation purposes they are one resource even
though they are two individuals). I certainly agree with you that we should
be able to create teams and lock resources together on a given task but for
now we can't. To use it most effectively as it is now we have to accept the
way it is now as just the way it is <grin>.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visithttp://www.mvps.org/project/faqs.htmfor the FAQs


....
Steve,
I think your explanation of how Project sees a task, the work of a
single resource, is accurate and lucid. OTH, I think this is a major
flaw in Project that should have been corrected many versions back.
Many resources on many kinds of tasks work together. To break down a
project to a one resource per task is simply not acceptable. I've
never heard of this idea in all my years in PM until I came to this
forum. This is simply a major defect of Project, NOT good scheduling
practice. The ability to "bind" resources together should be standard
in any scheduling software, though I don't know if it is.

In project, I can create resources of multiple people. I.e., I can
create a resource called carpenders with 800% availbility if I have 8
carpenders on the project. But this doesn't help if, as in reality,
usually a single carpender works with a single carpender's apprentice.
Of course, we can then create a resource called Carpender Team
composed of one of each. But what about situations where either of
them works, say on a specific task, separately? Or just splits up
temporarily to work on separate tasks? Or I need 3 teams on a one task
for it's duration?

I think Project should have the ability to "bind" resources,
temporarily or permanently together. On some tasks, I could
temporarily bind the Carpender and the Apprentice together for the
duration of the task. On other tasks, assign them separately. On
others, they would be "bound" for part of the task and not "bound" for
the rest of the task. This would also work for other kinds of teams,
like surgical teams or any kind of group whose members may vary from
task to task or project to project.

To have to break projects down to one resource/one task is absurd! It
could easily make a 1,000 task project into a 5,000 task project. I
certainly wouldn't want to have to manage 5,000 tasks when the work is
really 1,000! And it doesn't even accurately represent what is really
happening, that people are frequently working in groups, not solo all
the time.

It's one thing to understand this flaw in Project. It's entirely
another to represent it as good scheduling practice. To quote from
your post,
"In fact, the task types are only consistently meaningful when viewed
in the context of 1 task == 1 resource's work, the classic endpoint in
the breakdown of a complete, fully decomposed, WBS." I'd like to see
some reference in some highly regarded text on PM, like Kerzner or
Lewis, where it says anything like that. I certainly can't recall, in
all my reading and in all the classes I've taken on PM and Scheduling
over the last 30 years, any comment even suggesting that a WBS should
be broken down to one task/one resource level. It's simply an
oversight, at best, or a major flaw, at worst, in Project that it
behaves in this manor.

I'll have to find the reference for you but I have seen "task" defined as a
work package performed by a single resource or team of resources that must
work as a cohesive unit (working together such as a surgical team must work
together even though different members of the team have distinct functions).

I heartily agree to that definition: "I have seen "task" defined as
the lowest level of the Work Breakdown Structure, describing a work
package to be performed by a single resource or team of resources
working as a single unit (such as your carpenter and his apprentice -
neither of them can work alone so for schedule computation purposes
they are one resource even though they are two individuals." It
mentions "team of resources". Which Project doesn't really recognize,
unfortunately. The definition doesn't state so, but obviously, that
team is composed of individuals, who may or may not always be on the
team.

In any case, I wanted it clear to others than might be looking here
that a WBS is NOT normally broken down to individuals' efforts. Thank
goodness!

 

[Steve House]

Okay, both Spiro and Jack, I did the experiment, precisely as you stated the
problem below.

Scenario

New project file, MS default Standard Calendar as project calendar, project
start date Mon 12 Feb 0800

Two resources, Wally and Beaver, base calendars for each also standard
calendar. Beaver has Wed 14 Feb marked non-working in his resource
calendar.

Single task 'X' entered, 5 day duration, fixed duration, non-effort driven.

Alt-F10 to display the assign resources dialog box. Select task X, select
Beaver, ctrl-click to also select Wally, click [assign]. Result: Task X
remains at exactly 5 days duration, Wally scheduled for 40 hours work,
Beaver scheduled for 32 hours work.

Remove both resources.

Alt-F10 to display assign resources dialog box. Select task. Select Wally,
click [assign]. Select Beaver, click [assign]. Result: Task X 5 days
duration, Wally 40 hours, Beaver 32 hours.

Remove both assignments. Split Screen. Display Resource Work in Task Form

On first line pulldown Wally. On 2nd line pulldown Beaver. Click [OK].
Result: Wally 40 hours, Beaver 32 hours, Task duration 5 days.

Remove both resources, click [OK]

On first line pulldown Wally. Click [OK] Under Wally pulldown Beaver.
Click [OK] Result: Task duration 5 days, Wally 40 hours work, Beaver 32
hours work.

Remove all resources. Set task to Effort Driven. Assign both Wally and
Beave in a single operation by selecting both names in the Assign Resources
dialgo box and click [assign]. Same results as above.

Remove all resource, task still effort-driven. Assign both Wally and Beave
using the pulldown in the task form, pulling both names and lcicking [OK].
Identical results.

Remove all resources. Assign Wally and click [OK]. Select Beave and click
[OK]. Results: Duration STILL remains at 5 days, assignment % for each
drops to 56% from previous value of 100%. The 40 hours of total required
work has been prorated between them as effort driven describes. Wally
scheduled for 22.22 hours work, Beave scheduled for 17.78 hours work. Each
working 4.45 hours per day M, T, T, F. Wally only working 4.45 hr Wed.

Repeat in both 2003 Pro and 2007 Pro. Identical results.

Gentlemen, you can't get more consistent than that!

I'll have to find the reference for you but I have seen "task" defined
as
the lowest level of the Work Breakdown Structure, describing a work
package
to be performed by a single resource or team of resources working as a
single unit (such as your carpenter and his apprentice - neither of them
can
work alone so for schedule computation purposes they are one resource
even
though they are two individuals). I certainly agree with you that we
should
be able to create teams and lock resources together on a given task but
for
now we can't. To use it most effectively as it is now we have to accept
the
way it is now as just the way it is <grin>.

Excuse me?! There is no way I can accept the way it is now! This is an
obvious fault here! We can't just sweep it under the rug. Besides, even
if
we do what you suggest, and leave it as is, there are 2 different
behaviours
for the same operation. Ie., Try assigning 2 resources using the Assign
Resource (Alt-F10) and then try doing the same operation via the Task Form
(e.g., Resource Work). Before you assign the resources, make sure that
you
set one of the 2 resources to have some non-working time during these
Fixed
Duration non-effort driven tasks and see what you get!!!--2 different
scenarios!!! It is absurd!!!

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




.....
Steve,
I think your explanation of how Project sees a task, the work of a
single resource, is accurate and lucid. OTH, I think this is a major
flaw in Project that should have been corrected many versions back.
Many resources on many kinds of tasks work together. To break down a
project to a one resource per task is simply not acceptable. I've
never heard of this idea in all my years in PM until I came to this
forum. This is simply a major defect of Project, NOT good scheduling
practice. The ability to "bind" resources together should be standard
in any scheduling software, though I don't know if it is.

In project, I can create resources of multiple people. I.e., I can
create a resource called carpenders with 800% availbility if I have 8
carpenders on the project. But this doesn't help if, as in reality,
usually a single carpender works with a single carpender's apprentice.
Of course, we can then create a resource called Carpender Team
composed of one of each. But what about situations where either of
them works, say on a specific task, separately? Or just splits up
temporarily to work on separate tasks? Or I need 3 teams on a one task
for it's duration?

I think Project should have the ability to "bind" resources,
temporarily or permanently together. On some tasks, I could
temporarily bind the Carpender and the Apprentice together for the
duration of the task. On other tasks, assign them separately. On
others, they would be "bound" for part of the task and not "bound" for
the rest of the task. This would also work for other kinds of teams,
like surgical teams or any kind of group whose members may vary from
task to task or project to project.

To have to break projects down to one resource/one task is absurd! It
could easily make a 1,000 task project into a 5,000 task project. I
certainly wouldn't want to have to manage 5,000 tasks when the work is
really 1,000! And it doesn't even accurately represent what is really
happening, that people are frequently working in groups, not solo all
the time.

It's one thing to understand this flaw in Project. It's entirely
another to represent it as good scheduling practice. To quote from
your post,
"In fact, the task types are only consistently meaningful when viewed
in the context of 1 task == 1 resource's work, the classic endpoint in
the breakdown of a complete, fully decomposed, WBS." I'd like to see
some reference in some highly regarded text on PM, like Kerzner or
Lewis, where it says anything like that. I certainly can't recall, in
all my reading and in all the classes I've taken on PM and Scheduling
over the last 30 years, any comment even suggesting that a WBS should
be broken down to one task/one resource level. It's simply an
oversight, at best, or a major flaw, at worst, in Project that it
behaves in this manor.

I'll have to find the reference for you but I have seen "task" defined
as a
work package performed by a single resource or team of resources that
must
work as a cohesive unit (working together such as a surgical team must
work
together even though different members of the team have distinct
functions).

 

[Steve House]

As an addendum to my previous experimental results...IF the task is fixed
duration effort driven it does make a difference in the order you assign the
two resources. If you assign Wally first the total work for the task is 40
hours which is prorated between them when you add Beaver. But if you assign
Beaver first, the total work is fixed to 32 hours and that is the value that
is distributed prorata. So in the latter case the assignment units ends up
a different value than the forrmer but the end result duration STILL remains
5 days.

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

I'll have to find the reference for you but I have seen "task" defined
as
the lowest level of the Work Breakdown Structure, describing a work
package
to be performed by a single resource or team of resources working as a
single unit (such as your carpenter and his apprentice - neither of them
can
work alone so for schedule computation purposes they are one resource
even
though they are two individuals). I certainly agree with you that we
should
be able to create teams and lock resources together on a given task but
for
now we can't. To use it most effectively as it is now we have to accept
the
way it is now as just the way it is <grin>.

Excuse me?! There is no way I can accept the way it is now! This is an
obvious fault here! We can't just sweep it under the rug. Besides, even
if
we do what you suggest, and leave it as is, there are 2 different
behaviours
for the same operation. Ie., Try assigning 2 resources using the Assign
Resource (Alt-F10) and then try doing the same operation via the Task Form
(e.g., Resource Work). Before you assign the resources, make sure that
you
set one of the 2 resources to have some non-working time during these
Fixed
Duration non-effort driven tasks and see what you get!!!--2 different
scenarios!!! It is absurd!!!

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




.....
Steve,
I think your explanation of how Project sees a task, the work of a
single resource, is accurate and lucid. OTH, I think this is a major
flaw in Project that should have been corrected many versions back.
Many resources on many kinds of tasks work together. To break down a
project to a one resource per task is simply not acceptable. I've
never heard of this idea in all my years in PM until I came to this
forum. This is simply a major defect of Project, NOT good scheduling
practice. The ability to "bind" resources together should be standard
in any scheduling software, though I don't know if it is.

In project, I can create resources of multiple people. I.e., I can
create a resource called carpenders with 800% availbility if I have 8
carpenders on the project. But this doesn't help if, as in reality,
usually a single carpender works with a single carpender's apprentice.
Of course, we can then create a resource called Carpender Team
composed of one of each. But what about situations where either of
them works, say on a specific task, separately? Or just splits up
temporarily to work on separate tasks? Or I need 3 teams on a one task
for it's duration?

I think Project should have the ability to "bind" resources,
temporarily or permanently together. On some tasks, I could
temporarily bind the Carpender and the Apprentice together for the
duration of the task. On other tasks, assign them separately. On
others, they would be "bound" for part of the task and not "bound" for
the rest of the task. This would also work for other kinds of teams,
like surgical teams or any kind of group whose members may vary from
task to task or project to project.

To have to break projects down to one resource/one task is absurd! It
could easily make a 1,000 task project into a 5,000 task project. I
certainly wouldn't want to have to manage 5,000 tasks when the work is
really 1,000! And it doesn't even accurately represent what is really
happening, that people are frequently working in groups, not solo all
the time.

It's one thing to understand this flaw in Project. It's entirely
another to represent it as good scheduling practice. To quote from
your post,
"In fact, the task types are only consistently meaningful when viewed
in the context of 1 task == 1 resource's work, the classic endpoint in
the breakdown of a complete, fully decomposed, WBS." I'd like to see
some reference in some highly regarded text on PM, like Kerzner or
Lewis, where it says anything like that. I certainly can't recall, in
all my reading and in all the classes I've taken on PM and Scheduling
over the last 30 years, any comment even suggesting that a WBS should
be broken down to one task/one resource level. It's simply an
oversight, at best, or a major flaw, at worst, in Project that it
behaves in this manor.

I'll have to find the reference for you but I have seen "task" defined
as a
work package performed by a single resource or team of resources that
must
work as a cohesive unit (working together such as a surgical team must
work
together even though different members of the team have distinct
functions).

 

[Steve House]

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

I'll have to find the reference for you but I have seen "task" defined
as
the lowest level of the Work Breakdown Structure, describing a work
package
to be performed by a single resource or team of resources working as a
single unit (such as your carpenter and his apprentice - neither of them
can
work alone so for schedule computation purposes they are one resource
even
though they are two individuals). I certainly agree with you that we
should
be able to create teams and lock resources together on a given task but
for
now we can't. To use it most effectively as it is now we have to accept
the
way it is now as just the way it is <grin>.

Excuse me?! There is no way I can accept the way it is now! This is an
obvious fault here! We can't just sweep it under the rug. Besides, even
if
we do what you suggest, and leave it as is, there are 2 different
behaviours
for the same operation. Ie., Try assigning 2 resources using the Assign
Resource (Alt-F10) and then try doing the same operation via the Task Form
(e.g., Resource Work). Before you assign the resources, make sure that
you
set one of the 2 resources to have some non-working time during these
Fixed
Duration non-effort driven tasks and see what you get!!!--2 different
scenarios!!! It is absurd!!!

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




.....
Steve,
I think your explanation of how Project sees a task, the work of a
single resource, is accurate and lucid. OTH, I think this is a major
flaw in Project that should have been corrected many versions back.
Many resources on many kinds of tasks work together. To break down a
project to a one resource per task is simply not acceptable. I've
never heard of this idea in all my years in PM until I came to this
forum. This is simply a major defect of Project, NOT good scheduling
practice. The ability to "bind" resources together should be standard
in any scheduling software, though I don't know if it is.

In project, I can create resources of multiple people. I.e., I can
create a resource called carpenders with 800% availbility if I have 8
carpenders on the project. But this doesn't help if, as in reality,
usually a single carpender works with a single carpender's apprentice.
Of course, we can then create a resource called Carpender Team
composed of one of each. But what about situations where either of
them works, say on a specific task, separately? Or just splits up
temporarily to work on separate tasks? Or I need 3 teams on a one task
for it's duration?

I think Project should have the ability to "bind" resources,
temporarily or permanently together. On some tasks, I could
temporarily bind the Carpender and the Apprentice together for the
duration of the task. On other tasks, assign them separately. On
others, they would be "bound" for part of the task and not "bound" for
the rest of the task. This would also work for other kinds of teams,
like surgical teams or any kind of group whose members may vary from
task to task or project to project.

To have to break projects down to one resource/one task is absurd! It
could easily make a 1,000 task project into a 5,000 task project. I
certainly wouldn't want to have to manage 5,000 tasks when the work is
really 1,000! And it doesn't even accurately represent what is really
happening, that people are frequently working in groups, not solo all
the time.

It's one thing to understand this flaw in Project. It's entirely
another to represent it as good scheduling practice. To quote from
your post,
"In fact, the task types are only consistently meaningful when viewed
in the context of 1 task == 1 resource's work, the classic endpoint in
the breakdown of a complete, fully decomposed, WBS." I'd like to see
some reference in some highly regarded text on PM, like Kerzner or
Lewis, where it says anything like that. I certainly can't recall, in
all my reading and in all the classes I've taken on PM and Scheduling
over the last 30 years, any comment even suggesting that a WBS should
be broken down to one task/one resource level. It's simply an
oversight, at best, or a major flaw, at worst, in Project that it
behaves in this manor.

I'll have to find the reference for you but I have seen "task" defined
as a
work package performed by a single resource or team of resources that
must
work as a cohesive unit (working together such as a surgical team must
work
together even though different members of the team have distinct
functions).

 

[Jack Dahlgren]

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

I'll have to find the reference for you but I have seen "task" defined
as
the lowest level of the Work Breakdown Structure, describing a work
package
to be performed by a single resource or team of resources working as a
single unit (such as your carpenter and his apprentice - neither of them
can
work alone so for schedule computation purposes they are one resource
even
though they are two individuals). I certainly agree with you that we
should
be able to create teams and lock resources together on a given task but
for
now we can't. To use it most effectively as it is now we have to accept
the
way it is now as just the way it is <grin>.

Excuse me?! There is no way I can accept the way it is now! This is an
obvious fault here! We can't just sweep it under the rug. Besides,
even if
we do what you suggest, and leave it as is, there are 2 different
behaviours
for the same operation. Ie., Try assigning 2 resources using the Assign
Resource (Alt-F10) and then try doing the same operation via the Task
Form
(e.g., Resource Work). Before you assign the resources, make sure that
you
set one of the 2 resources to have some non-working time during these
Fixed
Duration non-effort driven tasks and see what you get!!!--2 different
scenarios!!! It is absurd!!!

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




.....
Steve,
I think your explanation of how Project sees a task, the work of a
single resource, is accurate and lucid. OTH, I think this is a major
flaw in Project that should have been corrected many versions back.
Many resources on many kinds of tasks work together. To break down a
project to a one resource per task is simply not acceptable. I've
never heard of this idea in all my years in PM until I came to this
forum. This is simply a major defect of Project, NOT good scheduling
practice. The ability to "bind" resources together should be standard
in any scheduling software, though I don't know if it is.

In project, I can create resources of multiple people. I.e., I can
create a resource called carpenders with 800% availbility if I have 8
carpenders on the project. But this doesn't help if, as in reality,
usually a single carpender works with a single carpender's apprentice.
Of course, we can then create a resource called Carpender Team
composed of one of each. But what about situations where either of
them works, say on a specific task, separately? Or just splits up
temporarily to work on separate tasks? Or I need 3 teams on a one task
for it's duration?

I think Project should have the ability to "bind" resources,
temporarily or permanently together. On some tasks, I could
temporarily bind the Carpender and the Apprentice together for the
duration of the task. On other tasks, assign them separately. On
others, they would be "bound" for part of the task and not "bound" for
the rest of the task. This would also work for other kinds of teams,
like surgical teams or any kind of group whose members may vary from
task to task or project to project.

To have to break projects down to one resource/one task is absurd! It
could easily make a 1,000 task project into a 5,000 task project. I
certainly wouldn't want to have to manage 5,000 tasks when the work is
really 1,000! And it doesn't even accurately represent what is really
happening, that people are frequently working in groups, not solo all
the time.

It's one thing to understand this flaw in Project. It's entirely
another to represent it as good scheduling practice. To quote from
your post,
"In fact, the task types are only consistently meaningful when viewed
in the context of 1 task == 1 resource's work, the classic endpoint in
the breakdown of a complete, fully decomposed, WBS." I'd like to see
some reference in some highly regarded text on PM, like Kerzner or
Lewis, where it says anything like that. I certainly can't recall, in
all my reading and in all the classes I've taken on PM and Scheduling
over the last 30 years, any comment even suggesting that a WBS should
be broken down to one task/one resource level. It's simply an
oversight, at best, or a major flaw, at worst, in Project that it
behaves in this manor.

I'll have to find the reference for you but I have seen "task" defined
as a
work package performed by a single resource or team of resources that
must
work as a cohesive unit (working together such as a surgical team must
work
together even though different members of the team have distinct
functions).

 

[Steve House]

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

:

I'll have to find the reference for you but I have seen "task" defined
as
the lowest level of the Work Breakdown Structure, describing a work
package
to be performed by a single resource or team of resources working as a
single unit (such as your carpenter and his apprentice - neither of
them can
work alone so for schedule computation purposes they are one resource
even
though they are two individuals). I certainly agree with you that we
should
be able to create teams and lock resources together on a given task but
for
now we can't. To use it most effectively as it is now we have to
accept the
way it is now as just the way it is <grin>.

Excuse me?! There is no way I can accept the way it is now! This is an
obvious fault here! We can't just sweep it under the rug. Besides,
even if
we do what you suggest, and leave it as is, there are 2 different
behaviours
for the same operation. Ie., Try assigning 2 resources using the Assign
Resource (Alt-F10) and then try doing the same operation via the Task
Form
(e.g., Resource Work). Before you assign the resources, make sure that
you
set one of the 2 resources to have some non-working time during these
Fixed
Duration non-effort driven tasks and see what you get!!!--2 different
scenarios!!! It is absurd!!!

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




.....
Steve,
I think your explanation of how Project sees a task, the work of a
single resource, is accurate and lucid. OTH, I think this is a major
flaw in Project that should have been corrected many versions back.
Many resources on many kinds of tasks work together. To break down a
project to a one resource per task is simply not acceptable. I've
never heard of this idea in all my years in PM until I came to this
forum. This is simply a major defect of Project, NOT good scheduling
practice. The ability to "bind" resources together should be standard
in any scheduling software, though I don't know if it is.

In project, I can create resources of multiple people. I.e., I can
create a resource called carpenders with 800% availbility if I have 8
carpenders on the project. But this doesn't help if, as in reality,
usually a single carpender works with a single carpender's apprentice.
Of course, we can then create a resource called Carpender Team
composed of one of each. But what about situations where either of
them works, say on a specific task, separately? Or just splits up
temporarily to work on separate tasks? Or I need 3 teams on a one task
for it's duration?

I think Project should have the ability to "bind" resources,
temporarily or permanently together. On some tasks, I could
temporarily bind the Carpender and the Apprentice together for the
duration of the task. On other tasks, assign them separately. On
others, they would be "bound" for part of the task and not "bound" for
the rest of the task. This would also work for other kinds of teams,
like surgical teams or any kind of group whose members may vary from
task to task or project to project.

To have to break projects down to one resource/one task is absurd! It
could easily make a 1,000 task project into a 5,000 task project. I
certainly wouldn't want to have to manage 5,000 tasks when the work is
really 1,000! And it doesn't even accurately represent what is really
happening, that people are frequently working in groups, not solo all
the time.

It's one thing to understand this flaw in Project. It's entirely
another to represent it as good scheduling practice. To quote from
your post,
"In fact, the task types are only consistently meaningful when viewed
in the context of 1 task == 1 resource's work, the classic endpoint in
the breakdown of a complete, fully decomposed, WBS." I'd like to see
some reference in some highly regarded text on PM, like Kerzner or
Lewis, where it says anything like that. I certainly can't recall, in
all my reading and in all the classes I've taken on PM and Scheduling
over the last 30 years, any comment even suggesting that a WBS should
be broken down to one task/one resource level. It's simply an
oversight, at best, or a major flaw, at worst, in Project that it
behaves in this manor.

I'll have to find the reference for you but I have seen "task" defined
as a
work package performed by a single resource or team of resources that
must
work as a cohesive unit (working together such as a surgical team must
work
together even though different members of the team have distinct
functions).

 

[Jan De Messemaeker]

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



:

I'll have to find the reference for you but I have seen "task"
defined as
the lowest level of the Work Breakdown Structure, describing a work
package
to be performed by a single resource or team of resources working as a
single unit (such as your carpenter and his apprentice - neither of
them can
work alone so for schedule computation purposes they are one resource
even
though they are two individuals). I certainly agree with you that we
should
be able to create teams and lock resources together on a given task
but for
now we can't. To use it most effectively as it is now we have to
accept the
way it is now as just the way it is <grin>.

Excuse me?! There is no way I can accept the way it is now! This is
an
obvious fault here! We can't just sweep it under the rug. Besides,
even if
we do what you suggest, and leave it as is, there are 2 different
behaviours
for the same operation. Ie., Try assigning 2 resources using the
Assign
Resource (Alt-F10) and then try doing the same operation via the Task
Form
(e.g., Resource Work). Before you assign the resources, make sure that
you
set one of the 2 resources to have some non-working time during these
Fixed
Duration non-effort driven tasks and see what you get!!!--2 different
scenarios!!! It is absurd!!!

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




.....
Steve,
I think your explanation of how Project sees a task, the work of a
single resource, is accurate and lucid. OTH, I think this is a major
flaw in Project that should have been corrected many versions back.
Many resources on many kinds of tasks work together. To break down a
project to a one resource per task is simply not acceptable. I've
never heard of this idea in all my years in PM until I came to this
forum. This is simply a major defect of Project, NOT good scheduling
practice. The ability to "bind" resources together should be standard
in any scheduling software, though I don't know if it is.

In project, I can create resources of multiple people. I.e., I can
create a resource called carpenders with 800% availbility if I have 8
carpenders on the project. But this doesn't help if, as in reality,
usually a single carpender works with a single carpender's apprentice.
Of course, we can then create a resource called Carpender Team
composed of one of each. But what about situations where either of
them works, say on a specific task, separately? Or just splits up
temporarily to work on separate tasks? Or I need 3 teams on a one task
for it's duration?

I think Project should have the ability to "bind" resources,
temporarily or permanently together. On some tasks, I could
temporarily bind the Carpender and the Apprentice together for the
duration of the task. On other tasks, assign them separately. On
others, they would be "bound" for part of the task and not "bound" for
the rest of the task. This would also work for other kinds of teams,
like surgical teams or any kind of group whose members may vary from
task to task or project to project.

To have to break projects down to one resource/one task is absurd! It
could easily make a 1,000 task project into a 5,000 task project. I
certainly wouldn't want to have to manage 5,000 tasks when the work is
really 1,000! And it doesn't even accurately represent what is really
happening, that people are frequently working in groups, not solo all
the time.

It's one thing to understand this flaw in Project. It's entirely
another to represent it as good scheduling practice. To quote from
your post,
"In fact, the task types are only consistently meaningful when viewed
in the context of 1 task == 1 resource's work, the classic endpoint in
the breakdown of a complete, fully decomposed, WBS." I'd like to see
some reference in some highly regarded text on PM, like Kerzner or
Lewis, where it says anything like that. I certainly can't recall, in
all my reading and in all the classes I've taken on PM and Scheduling
over the last 30 years, any comment even suggesting that a WBS should
be broken down to one task/one resource level. It's simply an
oversight, at best, or a major flaw, at worst, in Project that it
behaves in this manor.

I'll have to find the reference for you but I have seen "task"
defined as a
work package performed by a single resource or team of resources that
must
work as a cohesive unit (working together such as a surgical team must
work
together even though different members of the team have distinct
functions).

 

[Steve House]

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

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



:

I'll have to find the reference for you but I have seen "task"
defined as
the lowest level of the Work Breakdown Structure, describing a work
package
to be performed by a single resource or team of resources working as
a
single unit (such as your carpenter and his apprentice - neither of
them can
work alone so for schedule computation purposes they are one resource
even
though they are two individuals). I certainly agree with you that we
should
be able to create teams and lock resources together on a given task
but for
now we can't. To use it most effectively as it is now we have to
accept the
way it is now as just the way it is <grin>.

Excuse me?! There is no way I can accept the way it is now! This is
an
obvious fault here! We can't just sweep it under the rug. Besides,
even if
we do what you suggest, and leave it as is, there are 2 different
behaviours
for the same operation. Ie., Try assigning 2 resources using the
Assign
Resource (Alt-F10) and then try doing the same operation via the Task
Form
(e.g., Resource Work). Before you assign the resources, make sure
that you
set one of the 2 resources to have some non-working time during these
Fixed
Duration non-effort driven tasks and see what you get!!!--2 different
scenarios!!! It is absurd!!!

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




.....
Steve,
I think your explanation of how Project sees a task, the work of a
single resource, is accurate and lucid. OTH, I think this is a major
flaw in Project that should have been corrected many versions back.
Many resources on many kinds of tasks work together. To break down a
project to a one resource per task is simply not acceptable. I've
never heard of this idea in all my years in PM until I came to this
forum. This is simply a major defect of Project, NOT good scheduling
practice. The ability to "bind" resources together should be standard
in any scheduling software, though I don't know if it is.

In project, I can create resources of multiple people. I.e., I can
create a resource called carpenders with 800% availbility if I have 8
carpenders on the project. But this doesn't help if, as in reality,
usually a single carpender works with a single carpender's
apprentice.
Of course, we can then create a resource called Carpender Team
composed of one of each. But what about situations where either of
them works, say on a specific task, separately? Or just splits up
temporarily to work on separate tasks? Or I need 3 teams on a one
task
for it's duration?

I think Project should have the ability to "bind" resources,
temporarily or permanently together. On some tasks, I could
temporarily bind the Carpender and the Apprentice together for the
duration of the task. On other tasks, assign them separately. On
others, they would be "bound" for part of the task and not "bound"
for
the rest of the task. This would also work for other kinds of teams,
like surgical teams or any kind of group whose members may vary from
task to task or project to project.

To have to break projects down to one resource/one task is absurd! It
could easily make a 1,000 task project into a 5,000 task project. I
certainly wouldn't want to have to manage 5,000 tasks when the work
is
really 1,000! And it doesn't even accurately represent what is really
happening, that people are frequently working in groups, not solo all
the time.

It's one thing to understand this flaw in Project. It's entirely
another to represent it as good scheduling practice. To quote from
your post,
"In fact, the task types are only consistently meaningful when
viewed
in the context of 1 task == 1 resource's work, the classic endpoint
in
the breakdown of a complete, fully decomposed, WBS." I'd like to see
some reference in some highly regarded text on PM, like Kerzner or
Lewis, where it says anything like that. I certainly can't recall, in
all my reading and in all the classes I've taken on PM and Scheduling
over the last 30 years, any comment even suggesting that a WBS should
be broken down to one task/one resource level. It's simply an
oversight, at best, or a major flaw, at worst, in Project that it
behaves in this manor.

I'll have to find the reference for you but I have seen "task"
defined as a
work package performed by a single resource or team of resources that
must
work as a cohesive unit (working together such as a surgical team
must work
together even though different members of the team have distinct
functions).

 

[SpiroT]

Steve,

You are right in that the behaviour of the Assign Resources dialogue versus
splitting the screen and assigning resources via the Task Form Resource Work
screen is consistent. My fault...Sorrry, I give you credit for that.

/Spiro.

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



:

I'll have to find the reference for you but I have seen "task" defined
as
the lowest level of the Work Breakdown Structure, describing a work
package
to be performed by a single resource or team of resources working as a
single unit (such as your carpenter and his apprentice - neither of
them can
work alone so for schedule computation purposes they are one resource
even
though they are two individuals). I certainly agree with you that we
should
be able to create teams and lock resources together on a given task but
for
now we can't. To use it most effectively as it is now we have to
accept the
way it is now as just the way it is <grin>.

Excuse me?! There is no way I can accept the way it is now! This is an
obvious fault here! We can't just sweep it under the rug. Besides,
even if
we do what you suggest, and leave it as is, there are 2 different
behaviours
for the same operation. Ie., Try assigning 2 resources using the Assign
Resource (Alt-F10) and then try doing the same operation via the Task
Form
(e.g., Resource Work). Before you assign the resources, make sure that
you
set one of the 2 resources to have some non-working time during these
Fixed
Duration non-effort driven tasks and see what you get!!!--2 different
scenarios!!! It is absurd!!!

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




.....
Steve,
I think your explanation of how Project sees a task, the work of a
single resource, is accurate and lucid. OTH, I think this is a major
flaw in Project that should have been corrected many versions back.
Many resources on many kinds of tasks work together. To break down a
project to a one resource per task is simply not acceptable. I've
never heard of this idea in all my years in PM until I came to this
forum. This is simply a major defect of Project, NOT good scheduling
practice. The ability to "bind" resources together should be standard
in any scheduling software, though I don't know if it is.

In project, I can create resources of multiple people. I.e., I can
create a resource called carpenders with 800% availbility if I have 8
carpenders on the project. But this doesn't help if, as in reality,
usually a single carpender works with a single carpender's apprentice.
Of course, we can then create a resource called Carpender Team
composed of one of each. But what about situations where either of
them works, say on a specific task, separately? Or just splits up
temporarily to work on separate tasks? Or I need 3 teams on a one task
for it's duration?

I think Project should have the ability to "bind" resources,
temporarily or permanently together. On some tasks, I could
temporarily bind the Carpender and the Apprentice together for the
duration of the task. On other tasks, assign them separately. On
others, they would be "bound" for part of the task and not "bound" for
the rest of the task. This would also work for other kinds of teams,
like surgical teams or any kind of group whose members may vary from
task to task or project to project.

To have to break projects down to one resource/one task is absurd! It
could easily make a 1,000 task project into a 5,000 task project. I
certainly wouldn't want to have to manage 5,000 tasks when the work is
really 1,000! And it doesn't even accurately represent what is really
happening, that people are frequently working in groups, not solo all
the time.

It's one thing to understand this flaw in Project. It's entirely
another to represent it as good scheduling practice. To quote from
your post,
"In fact, the task types are only consistently meaningful when viewed
in the context of 1 task == 1 resource's work, the classic endpoint in
the breakdown of a complete, fully decomposed, WBS." I'd like to see
some reference in some highly regarded text on PM, like Kerzner or
Lewis, where it says anything like that. I certainly can't recall, in
all my reading and in all the classes I've taken on PM and Scheduling
over the last 30 years, any comment even suggesting that a WBS should
be broken down to one task/one resource level. It's simply an
oversight, at best, or a major flaw, at worst, in Project that it
behaves in this manor.

I'll have to find the reference for you but I have seen "task" defined
as a
work package performed by a single resource or team of resources that
must
work as a cohesive unit (working together such as a surgical team must
work
together even though different members of the team have distinct
functions).

 

[SpiroT]

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

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



:

I'll have to find the reference for you but I have seen "task"
defined as
the lowest level of the Work Breakdown Structure, describing a work
package
to be performed by a single resource or team of resources working as
a
single unit (such as your carpenter and his apprentice - neither of
them can
work alone so for schedule computation purposes they are one resource
even
though they are two individuals). I certainly agree with you that we
should
be able to create teams and lock resources together on a given task
but for
now we can't. To use it most effectively as it is now we have to
accept the
way it is now as just the way it is <grin>.

Excuse me?! There is no way I can accept the way it is now! This is
an
obvious fault here! We can't just sweep it under the rug. Besides,
even if
we do what you suggest, and leave it as is, there are 2 different
behaviours
for the same operation. Ie., Try assigning 2 resources using the
Assign
Resource (Alt-F10) and then try doing the same operation via the Task
Form
(e.g., Resource Work). Before you assign the resources, make sure
that you
set one of the 2 resources to have some non-working time during these
Fixed
Duration non-effort driven tasks and see what you get!!!--2 different
scenarios!!! It is absurd!!!

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




.....
Steve,
I think your explanation of how Project sees a task, the work of a
single resource, is accurate and lucid. OTH, I think this is a major
flaw in Project that should have been corrected many versions back.
Many resources on many kinds of tasks work together. To break down a
project to a one resource per task is simply not acceptable. I've
never heard of this idea in all my years in PM until I came to this
forum. This is simply a major defect of Project, NOT good scheduling
practice. The ability to "bind" resources together should be standard
in any scheduling software, though I don't know if it is.

In project, I can create resources of multiple people. I.e., I can
create a resource called carpenders with 800% availbility if I have 8
carpenders on the project. But this doesn't help if, as in reality,
usually a single carpender works with a single carpender's
apprentice.
Of course, we can then create a resource called Carpender Team
composed of one of each. But what about situations where either of
them works, say on a specific task, separately? Or just splits up
temporarily to work on separate tasks? Or I need 3 teams on a one
task
for it's duration?

I think Project should have the ability to "bind" resources,
temporarily or permanently together. On some tasks, I could
temporarily bind the Carpender and the Apprentice together for the
duration of the task. On other tasks, assign them separately. On
others, they would be "bound" for part of the task and not "bound"
for
the rest of the task. This would also work for other kinds of teams,
like surgical teams or any kind of group whose members may vary from
task to task or project to project.

To have to break projects down to one resource/one task is absurd! It
could easily make a 1,000 task project into a 5,000 task project. I
certainly wouldn't want to have to manage 5,000 tasks when the work
is
really 1,000! And it doesn't even accurately represent what is really
happening, that people are frequently working in groups, not solo all
the time.

It's one thing to understand this flaw in Project. It's entirely
another to represent it as good scheduling practice. To quote from
your post,
"In fact, the task types are only consistently meaningful when
viewed
in the context of 1 task == 1 resource's work, the classic endpoint
in
the breakdown of a complete, fully decomposed, WBS." I'd like to see
some reference in some highly regarded text on PM, like Kerzner or
Lewis, where it says anything like that. I certainly can't recall, in
all my reading and in all the classes I've taken on PM and Scheduling
over the last 30 years, any comment even suggesting that a WBS should
be broken down to one task/one resource level. It's simply an
oversight, at best, or a major flaw, at worst, in Project that it
behaves in this manor.

I'll have to find the reference for you but I have seen "task"
defined as a
work package performed by a single resource or team of resources that
must
work as a cohesive unit (working together such as a surgical team
must work
together even though different members of the team have distinct
functions).

 

[Steve House]

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



:

I'll have to find the reference for you but I have seen "task"
defined as
the lowest level of the Work Breakdown Structure, describing a
work
package
to be performed by a single resource or team of resources working
as
a
single unit (such as your carpenter and his apprentice - neither
of
them can
work alone so for schedule computation purposes they are one
resource
even
though they are two individuals). I certainly agree with you that
we
should
be able to create teams and lock resources together on a given
task
but for
now we can't. To use it most effectively as it is now we have to
accept the
way it is now as just the way it is <grin>.

Excuse me?! There is no way I can accept the way it is now! This
is
an
obvious fault here! We can't just sweep it under the rug.
Besides,
even if
we do what you suggest, and leave it as is, there are 2 different
behaviours
for the same operation. Ie., Try assigning 2 resources using the
Assign
Resource (Alt-F10) and then try doing the same operation via the
Task
Form
(e.g., Resource Work). Before you assign the resources, make sure
that you
set one of the 2 resources to have some non-working time during
these
Fixed
Duration non-effort driven tasks and see what you get!!!--2
different
scenarios!!! It is absurd!!!

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




.....
Steve,
I think your explanation of how Project sees a task, the work of a
single resource, is accurate and lucid. OTH, I think this is a
major
flaw in Project that should have been corrected many versions
back.
Many resources on many kinds of tasks work together. To break down
a
project to a one resource per task is simply not acceptable. I've
never heard of this idea in all my years in PM until I came to
this
forum. This is simply a major defect of Project, NOT good
scheduling
practice. The ability to "bind" resources together should be
standard
in any scheduling software, though I don't know if it is.

In project, I can create resources of multiple people. I.e., I can
create a resource called carpenders with 800% availbility if I
have 8
carpenders on the project. But this doesn't help if, as in
reality,
usually a single carpender works with a single carpender's
apprentice.
Of course, we can then create a resource called Carpender Team
composed of one of each. But what about situations where either of
them works, say on a specific task, separately? Or just splits up
temporarily to work on separate tasks? Or I need 3 teams on a one
task
for it's duration?

I think Project should have the ability to "bind" resources,
temporarily or permanently together. On some tasks, I could
temporarily bind the Carpender and the Apprentice together for the
duration of the task. On other tasks, assign them separately. On
others, they would be "bound" for part of the task and not "bound"
for
the rest of the task. This would also work for other kinds of
teams,
like surgical teams or any kind of group whose members may vary
from
task to task or project to project.

To have to break projects down to one resource/one task is absurd!
It
could easily make a 1,000 task project into a 5,000 task project.
I
certainly wouldn't want to have to manage 5,000 tasks when the
work
is
really 1,000! And it doesn't even accurately represent what is
really
happening, that people are frequently working in groups, not solo
all
the time.

It's one thing to understand this flaw in Project. It's entirely
another to represent it as good scheduling practice. To quote from
your post,
"In fact, the task types are only consistently meaningful when
viewed
in the context of 1 task == 1 resource's work, the classic
endpoint
in
the breakdown of a complete, fully decomposed, WBS." I'd like to
see
some reference in some highly regarded text on PM, like Kerzner or
Lewis, where it says anything like that. I certainly can't recall,
in
all my reading and in all the classes I've taken on PM and
Scheduling
over the last 30 years, any comment even suggesting that a WBS
should
be broken down to one task/one resource level. It's simply an
oversight, at best, or a major flaw, at worst, in Project that it
behaves in this manor.

I'll have to find the reference for you but I have seen "task"
defined as a
work package performed by a single resource or team of resources
that
must
work as a cohesive unit (working together such as a surgical team
must work
together even though different members of the team have distinct
functions).