Thanks for your reply on this. This actually got postponed until last week and I used your Option 2 which worked well as I they could be treated as separate projects in this particular scenario.
I thought there'd be a far easier solution that I was missing!
You are describing a natural consequence of using multiple calendars in MSP, where...
1. Any "duration" field refers to working time, not calendar time.
2. All durations are stored in minutes. They are converted to days (or weeks/months) using the Project-specific conversion factors found at the top of the Schedule tab in Project Options. (This is unlike P6, which has calendar-specific conversion factors.)
3. As a semi-exception, MSP also includes "elapsed" duration types (e.g. "edays, ewks"), which effectively impose a 24-hour task calendar with their own internal conversion factors (24h/ed, 7ed/ew, 30ed/emon).
Your case is reflecting the default project conversion factor of 8 (working) hours per (working) "day." Thus,
Construction Activity A Duration = 480 minutes = 8 hrs = 1 "day".
1. Continue using the two calendars and accept what Project tells you, but use "hours" as the duration units for all Shutdown activities. Then your Shutdown Activity B above would display "Duration = 24 hrs." If necessary for communications, you can also use a custom text field to convert and display the values you want using a formula.
2. Use elapsed durations for all your shutdown activities. Then your Shutdown Activity B above would display "Duration = 1 eday." Issue: since they are presumed to be independent of working time, elapsed durations don't allow for any exceptions to the 24-hour rule, and resource loading can be problematic.
3. Consider using 2 separate projects, one for Construction (Standard Project Calendar, 8h/d) and one for Shutdown (24-hr Project Calendar, 24h/d) Activities. This works best if there are NO dynamic links between the projects. (Inter-project links introduce a whole bunch of data-management complications that are best avoided.)
In any case, multiple calendars complicate the interpretation of Total Slack and the "Critical" flag, so describing the "Critical Path" might require a bit of hand-waving.
Member for
18 years 11 monthsGlad you got it
Glad you got it sorted.
Question: Which option did you actually implement for Shutdown activities: elapsed durations or completely separate project file?
Member for
6 years 9 monthsHi Tom,Thanks for your reply
Hi Tom,
Thanks for your reply on this. This actually got postponed until last week and I used your Option 2 which worked well as I they could be treated as separate projects in this particular scenario.
I thought there'd be a far easier solution that I was missing!
Thanks again,
Eam
Member for
18 years 11 monthsEam,You are describing a
Eam,
You are describing a natural consequence of using multiple calendars in MSP, where...
1. Any "duration" field refers to working time, not calendar time.
2. All durations are stored in minutes. They are converted to days (or weeks/months) using the Project-specific conversion factors found at the top of the Schedule tab in Project Options. (This is unlike P6, which has calendar-specific conversion factors.)
3. As a semi-exception, MSP also includes "elapsed" duration types (e.g. "edays, ewks"), which effectively impose a 24-hour task calendar with their own internal conversion factors (24h/ed, 7ed/ew, 30ed/emon).
Your case is reflecting the default project conversion factor of 8 (working) hours per (working) "day." Thus,
Construction Activity A Duration = 480 minutes = 8 hrs = 1 "day".
Shutdown Activity B Duration = 1,440 minutes = 24 hrs = 3 "days".
Options:
1. Continue using the two calendars and accept what Project tells you, but use "hours" as the duration units for all Shutdown activities. Then your Shutdown Activity B above would display "Duration = 24 hrs." If necessary for communications, you can also use a custom text field to convert and display the values you want using a formula.
2. Use elapsed durations for all your shutdown activities. Then your Shutdown Activity B above would display "Duration = 1 eday." Issue: since they are presumed to be independent of working time, elapsed durations don't allow for any exceptions to the 24-hour rule, and resource loading can be problematic.
3. Consider using 2 separate projects, one for Construction (Standard Project Calendar, 8h/d) and one for Shutdown (24-hr Project Calendar, 24h/d) Activities. This works best if there are NO dynamic links between the projects. (Inter-project links introduce a whole bunch of data-management complications that are best avoided.)
In any case, multiple calendars complicate the interpretation of Total Slack and the "Critical" flag, so describing the "Critical Path" might require a bit of hand-waving.
Good luck, tom