Calendars in Project

[Chachi]

I mostly use fixed duration tasks and have noticed that project struggles
with calculating work and or duration when I use calendars. I have setup a
project calendar and associated resource calendars and seem to be able to
confuse project fairly easily if the resource calendar's base calendar does
not match the project's base calendar. If I add in task calendars it seems
to further complicate the matter. So, I guess my question is...are calendars
really intended to be used when you have mostly/all fixed duration tasks?
Any tips I should be aware of when using calendars?

Thanks for any info you can share.

 

[Rod Gill]

You are creating the difficulty with fixed duration. Any assigned work hours
for resources must be able to be completed within the task's duration. If
not, then you automatically create a conflict. You are asking Project to fix
the duration, then you are telling it to accept a resource assignment that
cannot complete within the duration (because of not enough working hours in
the calendar) so of course Project struggles and throws errors!

 

[Steve House [MVP]]

The "duration" describes how many working hours will transpire between when
a task begins and when it's done. The calendar describes WHICH hours out of
the 24 hour day count as working hours. Imagine I have two tasks, both of
which require 8 hours to complete - in other words, each of their durations
is 8 hours. One of those is governed by a calendar that says we work 8
hours a day, from 8am to 5pm with an hour for lunch. The other is governed
by a calendar that says we only work 4 hours a day, from 8am to 12 noon.
Both tasks begin Monday at 8am. The first one will finish Monday at 5pm
after 8 hours of duration have transpired. The other will finish Tuesday at
12 noon, also when 8 working hours of duration have transpired. For the
second task the time between Mon noon and Tues 8am does not count towards
duration because the calendar says those are non-working hours.

Why do you "mostly use fixed duration tasks?" IMHO, a true fixed duration
task is a relatively rare event. A timed test that must run exactly 4
hours, no more and no less, would be an example of a fixed duration task but
things like that don't come up in the real world all that often. Another
example might be a meeting that will take 1 hour regardless of the number of
people attending. But the vast majority of tasks are fixed work tasks, a
totally different critter altogether. If you have 100 square feet to paint
and a painter working at full speed paints 25 square feet per hour, that
task will take 4 painter-hours to do. The duration will change depending on
how many painters you have available to do the work and how hard they work
but it will always take 4 painter-hours .

 

[Chachi]

First I'd like to answer your question, "....why do you mostly use fixed
duration tasks....?" I mostly use fixed duration tasks because all of my
project resources are responsible for ongoing operations and can't dedicate
themselves fully to the project. If a critical operational issue occurs
(i.e. a server crashes), they must fix that first and then go back to working
on the project. I've found that there is too much uncertainty to estimate
work and rely on that to determine the duration. So, I ask my team members
to estimate the number of days to complete a task and not the work to
complete the task. These types of estimates provide a much more accurate
model than if I has them to provide work estimates. Furthermore, the number
of units that a team member can dedicate to a task will vary greatly
depending on operational issues that arise, so I again find that using fixed
work and modifying units is not as accurate as giving a team member a fixed
duration to complete tasks. If you have a better way of solving these issues
I'd love to hear your suggestions.

Now, as for the calendars. I feel that I understand how they work and what
thier purpose are. However, I belive that you can get project confused if
you use multiple calendars that have different base calendars. Maybe my
solution is to quit modeling my scheduls using fixed duration and begin using
fixed work, but most of the time I don't want project modifying the durations
of my tasks.

The "duration" describes how many working hours will transpire between when
a task begins and when it's done. The calendar describes WHICH hours out of
the 24 hour day count as working hours. Imagine I have two tasks, both of
which require 8 hours to complete - in other words, each of their durations
is 8 hours. One of those is governed by a calendar that says we work 8
hours a day, from 8am to 5pm with an hour for lunch. The other is governed
by a calendar that says we only work 4 hours a day, from 8am to 12 noon.
Both tasks begin Monday at 8am. The first one will finish Monday at 5pm
after 8 hours of duration have transpired. The other will finish Tuesday at
12 noon, also when 8 working hours of duration have transpired. For the
second task the time between Mon noon and Tues 8am does not count towards
duration because the calendar says those are non-working hours.

Why do you "mostly use fixed duration tasks?" IMHO, a true fixed duration
task is a relatively rare event. A timed test that must run exactly 4
hours, no more and no less, would be an example of a fixed duration task but
things like that don't come up in the real world all that often. Another
example might be a meeting that will take 1 hour regardless of the number of
people attending. But the vast majority of tasks are fixed work tasks, a
totally different critter altogether. If you have 100 square feet to paint
and a painter working at full speed paints 25 square feet per hour, that
task will take 4 painter-hours to do. The duration will change depending on
how many painters you have available to do the work and how hard they work
but it will always take 4 painter-hours .

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

I mostly use fixed duration tasks and have noticed that project struggles
with calculating work and or duration when I use calendars. I have setup
a
project calendar and associated resource calendars and seem to be able to
confuse project fairly easily if the resource calendar's base calendar
does
not match the project's base calendar. If I add in task calendars it
seems
to further complicate the matter. So, I guess my question is...are
calendars
really intended to be used when you have mostly/all fixed duration tasks?
Any tips I should be aware of when using calendars?

Thanks for any info you can share.

 

[Wiley]

Chachi,

Forgive me for sounding preachy. Except for the pretty Gantt chart for the
executives, a Fixed Duration plan in Project could be just as easily tracked
in a spreadsheet. I resort to Fixed Duration only if a task is truly a fixed
duration, and very few things in the corporate world fit a fixed duration
definition. As I see it, a fixed duration task would mean an assumption of
no risk to that event being delayed. If one is building a house, waiting on
the concrete foundation to harden might be a fixed duration (which probably
at risk of the weather conditions). One of the essentials of good project
scheduling software is "dynamic scheduling", where a change to Actual
Duration drives a change to the remaining successor tasks' dates. With Fixed
Durations, you lose the dynamic piece. I have never figured out why MS set
the default to Fixed Duration!

Having resources dedicated less than 100% on a project is very common. I
would encourage you to use Fixed Work. I always get 2 estimates from my
resources - hours of effort (Work) AND the # of days it will take to complete
(Duration). I let Project calculate the Units for me. If you enter in the
following manner, it will not change duration.

1. Create task.
2. Add resource and hours of Work.
3. At this point Duration is estimated by Project with a "?". Change the
estimate to YOUR estimated duration. Project will recalc the Units
accordingly to the Work and Duration you have entered.

If you edit Work after this, Project will recalc Duration (based upon Work
and Units), but you can simply change Duration if necessary. And you will
retain the dynamic scheduling. By the way, I have been scheduling this way
for 2 years now, using 2 different resource schedules on the same project,
with it working very well. One of those schedules matches the project
calendar, and one does not.

Unless I am missing something, this should give you a working solution. I
hope it is helpful.

First I'd like to answer your question, "....why do you mostly use fixed
duration tasks....?" I mostly use fixed duration tasks because all of my
project resources are responsible for ongoing operations and can't dedicate
themselves fully to the project. If a critical operational issue occurs
(i.e. a server crashes), they must fix that first and then go back to working
on the project. I've found that there is too much uncertainty to estimate
work and rely on that to determine the duration. So, I ask my team members
to estimate the number of days to complete a task and not the work to
complete the task. These types of estimates provide a much more accurate
model than if I has them to provide work estimates. Furthermore, the number
of units that a team member can dedicate to a task will vary greatly
depending on operational issues that arise, so I again find that using fixed
work and modifying units is not as accurate as giving a team member a fixed
duration to complete tasks. If you have a better way of solving these issues
I'd love to hear your suggestions.

Now, as for the calendars. I feel that I understand how they work and what
thier purpose are. However, I belive that you can get project confused if
you use multiple calendars that have different base calendars. Maybe my
solution is to quit modeling my scheduls using fixed duration and begin using
fixed work, but most of the time I don't want project modifying the durations
of my tasks.

The "duration" describes how many working hours will transpire between when
a task begins and when it's done. The calendar describes WHICH hours out of
the 24 hour day count as working hours. Imagine I have two tasks, both of
which require 8 hours to complete - in other words, each of their durations
is 8 hours. One of those is governed by a calendar that says we work 8
hours a day, from 8am to 5pm with an hour for lunch. The other is governed
by a calendar that says we only work 4 hours a day, from 8am to 12 noon.
Both tasks begin Monday at 8am. The first one will finish Monday at 5pm
after 8 hours of duration have transpired. The other will finish Tuesday at
12 noon, also when 8 working hours of duration have transpired. For the
second task the time between Mon noon and Tues 8am does not count towards
duration because the calendar says those are non-working hours.

Why do you "mostly use fixed duration tasks?" IMHO, a true fixed duration
task is a relatively rare event. A timed test that must run exactly 4
hours, no more and no less, would be an example of a fixed duration task but
things like that don't come up in the real world all that often. Another
example might be a meeting that will take 1 hour regardless of the number of
people attending. But the vast majority of tasks are fixed work tasks, a
totally different critter altogether. If you have 100 square feet to paint
and a painter working at full speed paints 25 square feet per hour, that
task will take 4 painter-hours to do. The duration will change depending on
how many painters you have available to do the work and how hard they work
but it will always take 4 painter-hours .

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

I mostly use fixed duration tasks and have noticed that project struggles
with calculating work and or duration when I use calendars. I have setup
a
project calendar and associated resource calendars and seem to be able to
confuse project fairly easily if the resource calendar's base calendar
does
not match the project's base calendar. If I add in task calendars it
seems
to further complicate the matter. So, I guess my question is...are
calendars
really intended to be used when you have mostly/all fixed duration tasks?
Any tips I should be aware of when using calendars?

Thanks for any info you can share.

 

[Chachi]

Thanks for the tips. I've updated all my tasks to fixed work and the project
calendars are working much better now.

Chachi,

Forgive me for sounding preachy. Except for the pretty Gantt chart for the
executives, a Fixed Duration plan in Project could be just as easily tracked
in a spreadsheet. I resort to Fixed Duration only if a task is truly a fixed
duration, and very few things in the corporate world fit a fixed duration
definition. As I see it, a fixed duration task would mean an assumption of
no risk to that event being delayed. If one is building a house, waiting on
the concrete foundation to harden might be a fixed duration (which probably
at risk of the weather conditions). One of the essentials of good project
scheduling software is "dynamic scheduling", where a change to Actual
Duration drives a change to the remaining successor tasks' dates. With Fixed
Durations, you lose the dynamic piece. I have never figured out why MS set
the default to Fixed Duration!

Having resources dedicated less than 100% on a project is very common. I
would encourage you to use Fixed Work. I always get 2 estimates from my
resources - hours of effort (Work) AND the # of days it will take to complete
(Duration). I let Project calculate the Units for me. If you enter in the
following manner, it will not change duration.

1. Create task.
2. Add resource and hours of Work.
3. At this point Duration is estimated by Project with a "?". Change the
estimate to YOUR estimated duration. Project will recalc the Units
accordingly to the Work and Duration you have entered.

If you edit Work after this, Project will recalc Duration (based upon Work
and Units), but you can simply change Duration if necessary. And you will
retain the dynamic scheduling. By the way, I have been scheduling this way
for 2 years now, using 2 different resource schedules on the same project,
with it working very well. One of those schedules matches the project
calendar, and one does not.

Unless I am missing something, this should give you a working solution. I
hope it is helpful.

First I'd like to answer your question, "....why do you mostly use fixed
duration tasks....?" I mostly use fixed duration tasks because all of my
project resources are responsible for ongoing operations and can't dedicate
themselves fully to the project. If a critical operational issue occurs
(i.e. a server crashes), they must fix that first and then go back to working
on the project. I've found that there is too much uncertainty to estimate
work and rely on that to determine the duration. So, I ask my team members
to estimate the number of days to complete a task and not the work to
complete the task. These types of estimates provide a much more accurate
model than if I has them to provide work estimates. Furthermore, the number
of units that a team member can dedicate to a task will vary greatly
depending on operational issues that arise, so I again find that using fixed
work and modifying units is not as accurate as giving a team member a fixed
duration to complete tasks. If you have a better way of solving these issues
I'd love to hear your suggestions.

Now, as for the calendars. I feel that I understand how they work and what
thier purpose are. However, I belive that you can get project confused if
you use multiple calendars that have different base calendars. Maybe my
solution is to quit modeling my scheduls using fixed duration and begin using
fixed work, but most of the time I don't want project modifying the durations
of my tasks.

The "duration" describes how many working hours will transpire between when
a task begins and when it's done. The calendar describes WHICH hours out of
the 24 hour day count as working hours. Imagine I have two tasks, both of
which require 8 hours to complete - in other words, each of their durations
is 8 hours. One of those is governed by a calendar that says we work 8
hours a day, from 8am to 5pm with an hour for lunch. The other is governed
by a calendar that says we only work 4 hours a day, from 8am to 12 noon.
Both tasks begin Monday at 8am. The first one will finish Monday at 5pm
after 8 hours of duration have transpired. The other will finish Tuesday at
12 noon, also when 8 working hours of duration have transpired. For the
second task the time between Mon noon and Tues 8am does not count towards
duration because the calendar says those are non-working hours.

Why do you "mostly use fixed duration tasks?" IMHO, a true fixed duration
task is a relatively rare event. A timed test that must run exactly 4
hours, no more and no less, would be an example of a fixed duration task but
things like that don't come up in the real world all that often. Another
example might be a meeting that will take 1 hour regardless of the number of
people attending. But the vast majority of tasks are fixed work tasks, a
totally different critter altogether. If you have 100 square feet to paint
and a painter working at full speed paints 25 square feet per hour, that
task will take 4 painter-hours to do. The duration will change depending on
how many painters you have available to do the work and how hard they work
but it will always take 4 painter-hours .

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




I mostly use fixed duration tasks and have noticed that project struggles
with calculating work and or duration when I use calendars. I have setup
a
project calendar and associated resource calendars and seem to be able to
confuse project fairly easily if the resource calendar's base calendar
does
not match the project's base calendar. If I add in task calendars it
seems
to further complicate the matter. So, I guess my question is...are
calendars
really intended to be used when you have mostly/all fixed duration tasks?
Any tips I should be aware of when using calendars?

Thanks for any info you can share.

 

[Jan De Messemaeker]

Hi,

Forgive me for smart-assing, but AFAIK the default is Fixed Units, Effort
Driven.
And I hate percentage units... When people work for me I want them to work
with 100% of their brains, or if you like, 60 seconds per minute. I know
these percentages are used commonly but I do not recommend it. Do give me
fixed units!
HTH

--
Jan De Messemaeker, Microsoft Project Most Valuable Professional
http://users.online.be/prom-ade/
For FAQs: http://www.mvps.org/project/faqs.htm

Chachi,

Forgive me for sounding preachy. Except for the pretty Gantt chart for the
executives, a Fixed Duration plan in Project could be just as easily tracked
in a spreadsheet. I resort to Fixed Duration only if a task is truly a fixed
duration, and very few things in the corporate world fit a fixed duration
definition. As I see it, a fixed duration task would mean an assumption of
no risk to that event being delayed. If one is building a house, waiting on
the concrete foundation to harden might be a fixed duration (which probably
at risk of the weather conditions). One of the essentials of good project
scheduling software is "dynamic scheduling", where a change to Actual
Duration drives a change to the remaining successor tasks' dates. With Fixed
Durations, you lose the dynamic piece. I have never figured out why MS set
the default to Fixed Duration!

Having resources dedicated less than 100% on a project is very common. I
would encourage you to use Fixed Work. I always get 2 estimates from my
resources - hours of effort (Work) AND the # of days it will take to complete
(Duration). I let Project calculate the Units for me. If you enter in the
following manner, it will not change duration.

1. Create task.
2. Add resource and hours of Work.
3. At this point Duration is estimated by Project with a "?". Change the
estimate to YOUR estimated duration. Project will recalc the Units
accordingly to the Work and Duration you have entered.

If you edit Work after this, Project will recalc Duration (based upon Work
and Units), but you can simply change Duration if necessary. And you will
retain the dynamic scheduling. By the way, I have been scheduling this way
for 2 years now, using 2 different resource schedules on the same project,
with it working very well. One of those schedules matches the project
calendar, and one does not.

Unless I am missing something, this should give you a working solution. I
hope it is helpful.

First I'd like to answer your question, "....why do you mostly use fixed
duration tasks....?" I mostly use fixed duration tasks because all of my
project resources are responsible for ongoing operations and can't dedicate
themselves fully to the project. If a critical operational issue occurs
(i.e. a server crashes), they must fix that first and then go back to working
on the project. I've found that there is too much uncertainty to estimate
work and rely on that to determine the duration. So, I ask my team members
to estimate the number of days to complete a task and not the work to
complete the task. These types of estimates provide a much more accurate
model than if I has them to provide work estimates. Furthermore, the number
of units that a team member can dedicate to a task will vary greatly
depending on operational issues that arise, so I again find that using fixed
work and modifying units is not as accurate as giving a team member a fixed
duration to complete tasks. If you have a better way of solving these issues
I'd love to hear your suggestions.

Now, as for the calendars. I feel that I understand how they work and what
thier purpose are. However, I belive that you can get project confused if
you use multiple calendars that have different base calendars. Maybe my
solution is to quit modeling my scheduls using fixed duration and begin using
fixed work, but most of the time I don't want project modifying the durations
of my tasks.

The "duration" describes how many working hours will transpire between when
a task begins and when it's done. The calendar describes WHICH hours out of
the 24 hour day count as working hours. Imagine I have two tasks, both of
which require 8 hours to complete - in other words, each of their durations
is 8 hours. One of those is governed by a calendar that says we work 8
hours a day, from 8am to 5pm with an hour for lunch. The other is governed
by a calendar that says we only work 4 hours a day, from 8am to 12 noon.
Both tasks begin Monday at 8am. The first one will finish Monday at 5pm
after 8 hours of duration have transpired. The other will finish Tuesday at
12 noon, also when 8 working hours of duration have transpired. For the
second task the time between Mon noon and Tues 8am does not count towards
duration because the calendar says those are non-working hours.

Why do you "mostly use fixed duration tasks?" IMHO, a true fixed duration
task is a relatively rare event. A timed test that must run exactly 4
hours, no more and no less, would be an example of a fixed duration task but
things like that don't come up in the real world all that often. Another
example might be a meeting that will take 1 hour regardless of the number of
people attending. But the vast majority of tasks are fixed work tasks, a
totally different critter altogether. If you have 100 square feet to paint
and a painter working at full speed paints 25 square feet per hour, that
task will take 4 painter-hours to do. The duration will change depending on
how many painters you have available to do the work and how hard they work
but it will always take 4 painter-hours .

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




I mostly use fixed duration tasks and have noticed that project struggles
with calculating work and or duration when I use calendars. I have setup
a
project calendar and associated resource calendars and seem to be able to
confuse project fairly easily if the resource calendar's base calendar
does
not match the project's base calendar. If I add in task calendars it
seems
to further complicate the matter. So, I guess my question is...are
calendars
really intended to be used when you have mostly/all fixed duration tasks?
Any tips I should be aware of when using calendars?

Thanks for any info you can share.

 

[Steve House [MVP]]

Okay, but what about this scenario. Joe is assigned to work on project task
X and he has told you that working on it full time it will take him 5 days
to finish it. You have it in the plan as 5 days duration, resource assigned
100%. Now that server you mentioned crashes and Joe has to spend 4 hours a
day working on fixing it. As a result he can only devote 50% effort to task
X. If you've made it fixed duration, when you reduce his assignment from
100% to 50% to give him free time to work on the server, the duration of
task X will not change - instead, the required work gets recalculated. That
simply can't be an accurate model of reality, for the required man-hours to
complete task X suddenly to drop from 40 to 20 just because the resource
finds he has other things he has to work on at the same time. What will
really happen is that since he can only devote half of his effort to task X
it will now take him 10 days instead of 5 days to complete it. That's fixed
work behavior, not fixed duration.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

First I'd like to answer your question, "....why do you mostly use fixed
duration tasks....?" I mostly use fixed duration tasks because all of my
project resources are responsible for ongoing operations and can't
dedicate
themselves fully to the project. If a critical operational issue occurs
(i.e. a server crashes), they must fix that first and then go back to
working
on the project. I've found that there is too much uncertainty to estimate
work and rely on that to determine the duration. So, I ask my team
members
to estimate the number of days to complete a task and not the work to
complete the task. These types of estimates provide a much more accurate
model than if I has them to provide work estimates. Furthermore, the
number
of units that a team member can dedicate to a task will vary greatly
depending on operational issues that arise, so I again find that using
fixed
work and modifying units is not as accurate as giving a team member a
fixed
duration to complete tasks. If you have a better way of solving these
issues
I'd love to hear your suggestions.

Now, as for the calendars. I feel that I understand how they work and
what
thier purpose are. However, I belive that you can get project confused
if
you use multiple calendars that have different base calendars. Maybe my
solution is to quit modeling my scheduls using fixed duration and begin
using
fixed work, but most of the time I don't want project modifying the
durations
of my tasks.

The "duration" describes how many working hours will transpire between
when
a task begins and when it's done. The calendar describes WHICH hours out
of
the 24 hour day count as working hours. Imagine I have two tasks, both
of
which require 8 hours to complete - in other words, each of their
durations
is 8 hours. One of those is governed by a calendar that says we work 8
hours a day, from 8am to 5pm with an hour for lunch. The other is
governed
by a calendar that says we only work 4 hours a day, from 8am to 12 noon.
Both tasks begin Monday at 8am. The first one will finish Monday at 5pm
after 8 hours of duration have transpired. The other will finish Tuesday
at
12 noon, also when 8 working hours of duration have transpired. For the
second task the time between Mon noon and Tues 8am does not count towards
duration because the calendar says those are non-working hours.

Why do you "mostly use fixed duration tasks?" IMHO, a true fixed
duration
task is a relatively rare event. A timed test that must run exactly 4
hours, no more and no less, would be an example of a fixed duration task
but
things like that don't come up in the real world all that often. Another
example might be a meeting that will take 1 hour regardless of the number
of
people attending. But the vast majority of tasks are fixed work tasks, a
totally different critter altogether. If you have 100 square feet to
paint
and a painter working at full speed paints 25 square feet per hour, that
task will take 4 painter-hours to do. The duration will change depending
on
how many painters you have available to do the work and how hard they
work
but it will always take 4 painter-hours .

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

I mostly use fixed duration tasks and have noticed that project
struggles
with calculating work and or duration when I use calendars. I have
setup
a
project calendar and associated resource calendars and seem to be able
to
confuse project fairly easily if the resource calendar's base calendar
does
not match the project's base calendar. If I add in task calendars it
seems
to further complicate the matter. So, I guess my question is...are
calendars
really intended to be used when you have mostly/all fixed duration
tasks?
Any tips I should be aware of when using calendars?

Thanks for any info you can share.