Task Type - Developing versus Track the Schedule

[Darrell]

When creating an assignment (task) I was trained to use the task type for the
variable that I do know and let the program calculate the variable that you
do not know. So, if I know the duration I use “Fixed Duration†and enter the
duration first. I then add either the estimated “work†or “units†based in
what I think I have, and then I allow MS Project to calculate the last
variable for me. I do this to DEVELOP my schedule. Once I have my schedule
developed and I set my baseline, I then change all of the task types to
“Fixed Units†to TRACK my progress because in general I do not want my
resource allocation (units) to change (since they have now accepted ownership
of the assignment) I want either my “duration†or “work†to change so that I
can track variance.

Can anyone provide an argument for TRACKING a schedule using something other
than “Fixed Units�

 

[Rod Gill]

When creating an Assignment, the Task Type does nothing! Enter any two
values and Project calculates the third automatically. Task Type only has an
effect when editing assignments. Fixed Units is the most flexible, but for
individual edits use the ditty:
Edit one, fix one and the third one is calculated.

EG have 20h more work but task mustn't take any longer, so edit the work to
add 20h, fix Duration then Units gets recalculated to show the new
availability you need.

--

Rod Gill
Microsoft MVP for Project

Author of the only book on Project VBA, see:
http://www.projectvbabook.com

 

[Dave]

Yes.

You might have an activity such as monitoring an installation which had
to go on for a fixed period. In such a case I would use a fixed
duration task.

I find fixed work my default task type because I don't want to assume
that my resources do work in that way.

 

[Darrell]

Well I would have to disagree with your initial statement, because if I use a
"fixed duration" task type to create an assignment and I set the duration to
say 20days and then add 3 resources and then enter the estimated work of
40hrs Project will recalculate the units for me leaving the duration at 20
days. It will do the same thing if I enter the duration and then the work and
then the three resources. However, if I use a "fixed units" task type and I
enter my data in the exact same manner (duration, units and then work) I will
get a duration of 1.67 days and if I add the work first I will get a duration
of 6.67days. Therefore, there is a relationship between the task type and
what variable you enter first when creating an assignment. Yes?

My point was that if I know one variable and I do not want it to change I
should create my assignments using that “fixed type†to prevent it from being
changed as I enter the next variable and generate my schedule. Therefore, if
I know mostly durations I can set my default task type to ‘fixed duration†to
develop my schedule. Now, once I have developed my schedule I can change to
“fixed units†so that my assignments do not change during updates, my work or
duration will change instead… since this is what I baselined to watch for
variance and not units.

Darrell

 

[Steve House [MVP]]

The thing is, how do you really "know" your durations? A "Fixed Units" task
behaves as if it is fixed work when you edit units. Let's say you need to
build 100 widget and you know it would take Joe 3 days working full-time on
it to do it. So that's what you put into the schedule with Joe assigned.
But now you learn that Jow isn't available full-time after all - he has
something else on his plate that will take away some of his energy from
building widgets. So you reduce his assignment to 50%. But he still has to
make 100 widgets - using fixed duration to lock the duration to 3 days would
mean he only will be able to make 50 because he's now making them at half
the rate he was before. The work recalculation is the number you see but
work is physically locked to deliverable required so a reduction of work by
50% mean the deliverable produced must also drop by 50%. Or a second
scenario for the same situation, Joe is still available 100% but you realize
that you really don't need so many widgets. So you manually edit the work
and the duration drops to reflect you'll finish the new required deliverable
sooner, the normal fixed units behavior. If you have the task on Fixed
Duration instead of fixed units, the reduction is required deliverable would
mean the task duration stays the same and what drops is Joe's assignment
percentage so he's standing around twiddling his thimbs for half of his
workdays, not a very efficient use of his energy. Why put Joe at 50% and
keep the task at 3 days when you would be better served keeping him at 100%
and dropping the duration to a day and a half, getting the task (and hence
the project) done ASAP? This logic is why I advocate that fixed duration
should be restricted to those special types of tasks like timed reliability
tests that really MUST run for a specifc length of time due to their nature.