Fixed Duration and Work Hours

[Cole]

Question on something I haven't been able to figure out and it happens
if the task is complete or in progress.

I have set the whole schedule to Fixed Duration but whenever I add or
delete a resource my start and finish dates change.

I thought with type set as Fixed Duration the dates shouldn't change
even if the overall work hours for the task did change.

I know Fixed Work will keep the work the same which should then keep
the date per se in check but I think Fixed Duration will do this job
better until I'm finished resource loading.

Any thoughts?

Cole

 

[JulieS]

Hi Cole,

Is the resource's calendar different (later or earlier working time,
nonworking time, etc.) than the project calendar? When you assign a
resource (even to a Fixed Duration task), the resource may only work
during time defined as working time on his/her calendar. A difference
between the resource's calendar and the project calendar will cause the
change in task start and finish dates.

I hope this helps. Let us know how you get along.

Julie

 

[davegb]

Question on something I haven't been able to figure out and it happens
if the task is complete or in progress.

I have set the whole schedule to Fixed Duration but whenever I add or
delete a resource my start and finish dates change.

I thought with type set as Fixed Duration the dates shouldn't change
even if the overall work hours for the task did change.

I know Fixed Work will keep the work the same which should then keep
the date per se in check but I think Fixed Duration will do this job
better until I'm finished resource loading.

Any thoughts?

Cole

Fixed Duration fixes the duration, not the dates. You have to use
constraints to fix dates.

Hope this helps in your world.

 

[Steve House [MVP]]

I find fixed duration to be very problematical in that to my thinking it
only very rarely consititutes an accurate description of reality. It
suggests that no matter how hard the resources in my project work, their
tasks will always take a specific fixed length of time to accomplish. This
doesn't make sense to me - logic says a painter who's focused and working
like a beaver (100%) will finish a wall faster than a guy who spends half
his time painting and the other half on some other task (50%). Likewise,
does it make sense that it would take the same length of time to paint a
wall regardless of whether you have 1, 2, 3, or 4 painters working on it at
once?

You seem to be uncomfortable with the fact that the dates change but this is
precisely why one uses a tool like Project. Its job is the answer the
question "When will we be able to finish IF we start on this date, have this
many resources, and structure their work in this manner?"

 

[Dave]

I find fixed duration to be very problematical in that to my thinking it
only very rarely consititutes an accurate description of reality.

It is relatively rare, but how about a development leading to a product
which is commissioned and then monitored for 3 weeks (say)? You know
you will monitor it (this isn't the same as having a lag) for a fixed
period before doing any subsequent work on the system or declaring it
fully in service.

 

[Steve House [MVP]]

Yep, that's one of the sorts of things where fixed duration does make sense
(for the monitoring period, but NOT for the development phase). Another is
an automated test that runs for a specific length of time. The problem
comes about when the fixed duration setting is used with other sorts of
tasks in order to try to force the schedule to look like what someone has
decided a priori it ought to look like. What happens too often is that
managers who think that management is an act of will power and determination
will say "We have three months to develop this product" and use fixed
duration task types to force the project to fit into that framework. IMHO
one shouldn't plan a project with the mindset of "It ought to take you two
weeks to write that module, therefore the project schedule has locked in
granite that it WILL take you two weeks."

 

[Cole]

Steve, couldn't agree with you more. Management with PMP's (no
disrespect to PMP) usually think as you describe below and when I
inform them of how to properly schedule all they care is about the
report they need to provide. LOL

So by keeping duration fixed - thanks davegb for your input that helps
- I keep their dates fixed then once the schedule is resource loaded or
in the process of resource loading I inform them of 18 hours they have
planned for in regards to their resources or their need to hire more
workers.

At times when I try to educate them in the beginning it doesn't
compute. LOL. So I have to walk each one thru it everytime one step at
a time.

The only thing harder than this is teaching the individuals who
calculate the earned value portion (not in MS Project of course) why
the schedule needs to meet certain criteria in order to acquire proper
results within EVMS.

Yep, that's one of the sorts of things where fixed duration does make sense
(for the monitoring period, but NOT for the development phase). Another is
an automated test that runs for a specific length of time. The problem
comes about when the fixed duration setting is used with other sorts of
tasks in order to try to force the schedule to look like what someone has
decided a priori it ought to look like. What happens too often is that
managers who think that management is an act of will power and determination
will say "We have three months to develop this product" and use fixed
duration task types to force the project to fit into that framework. IMHO
one shouldn't plan a project with the mindset of "It ought to take you two
weeks to write that module, therefore the project schedule has locked in
granite that it WILL take you two weeks."
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

It is relatively rare, but how about a development leading to a product
which is commissioned and then monitored for 3 weeks (say)? You know you
will monitor it (this isn't the same as having a lag) for a fixed period
before doing any subsequent work on the system or declaring it fully in
service.