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
