using calendar days for duration

[Rick LaBorde]

I would like Project to use calendar days for duration as a default
instead of working days.

Is there a switch to do this (without using the DateDiff function)?

Thanks in advance.

 

[Jan De Messemaeker]

Hi,

You can express your durations as edays but there is no way to set this as
default.
But if you make your process calendar 7 workdays a week using days will have
the desired effect.
HTH

--
Jan De Messemaeker
Microsoft Project Most Valuable Professional
+32 495 300 620
For availability check:
http://users.online.be/prom-ade/Calendar.pdf

 

[Steve House]

Project always schedules in minutes as the base units of duration. It
accepts and displays other units as a concession to user convenience. But
internally everything is always in minutes.

There are all sorts of problems associated with using calendar days instead
of legitmate duration units. First and formost, projects only proceed to
their completion by virtue of resources doing work. Thus the only time that
matters is the time that the resources are physically present and able to do
work. The passage of clock time in and of itself fundamentally means nothing
.... it's only the passage of working time that can actually moves the
project forward. If a task starts on at the start of the day on Monday and
finishes then end of the day on Tuesday, that's 2 days, But if it starts
the start of the day on Friday and ends the end of the day Monday, that is 2
working days but 4 calendar days, not two. And yet the amount of work
actually accomplished to drive the project forward in both of those tasks is
exactly the same.

Another issue is when you use elapsed time, the distinction between working
and non-working time disappears. An elapsed day is 24 hours, a duration day
(with the default settings) is 8 hours. You have to schedule the task's
start and end time according to when the resource is there able to work on
it. And since best practice is to detail the tasks down to the level that a
task is an activity performed by a resource, tasks won't proceed 24/7 ...
they'll start and stop and restart again as the resource comes to work and
goes home for the day.

If you used elapsed time and assign Joe to a 3 day task, that means he'll
work continuously at it for a solid 72 hours without a break, without a nap,
without a meal, without a howdy to his kids. People don't ... can't ...
work like that.

To be honest, I can't conceive of any reason to use elapsed times for
anything other than continuous, essentially unattended processes such as a
burn-in period on a piece of electronic hardsware or an automated test
procedure, something like that. For human activities, measuring time in
terms of working time is far more reliable.

 

[Rick LaBorde]

Thank you both for your responses.

I may have another question on a different subject, but will searc
around the forums first

 

[battsman]

Steve House wrote:

-To be honest, I can't conceive of any reason to use elapse
times for anything other than continuous, essentially unattende
processes such as a burn-in period on a piece of electronic hardsware o
an automated test procedure, something like that. For human activities
measuring time in
terms of working time is far more reliable.[/-INDENT]

A similar example of a reason for elapsed times would be contractua
obligations based on calendar days (e.g.: Mandated operationa
availability demonstrations, support periods, etc.). Do you have an
suggestions of how you could "mix and match" duration types within
given project? (i.e. Use actual labor expended minutes (work days) fo
most lines, but calendar / elapsed time for certain lines.) I hav
projects that I track most activities by labor, but require certai
milestones to be tracked strictly based on calendar days.

Thanks,​

 

[Steve House]

Well, for milestones the issue is moot - since they simply flag a single
point in time with a length of zero by definition, there is no distinction
between "duration zero" and "elapsed zero." They mark an instantaneous
event, a state transition in the project, say from a condition of "contract
not signed" to the condition of "contract signed, okay to proceed."
Milestones occur on a date, the date the transition takes place, and very
often carry a deadline, the date by which they are required to take place,
but those dates are perfectly conventional calendar dates and the
distinction between duration and elapsed time is irrelevant.

Likewise, for something like a support period the issue also is moot.
"Support Period" is not a task, it simply the name of a time window. Tasks
are always visible work done by a resource. Your contracted post delivery
support period might be 6 months but if the support person is only makes one
support visit and spends a day with the client, the only TASK involved is
"Support Call," it's duration is 8 hours, and those 8 hours can only occur
during the working time calendar of the resource, hence only working time,
ie, duration, is what matters. If that call comes Friday at noon, he's
probably going to work Friday afternoon, knock off for the weekend, and
finish up Monday morning. Elapsed time says he'd work on Friday night and
in fact not rest for even a minute until the problem is solved. All the rest
of the time during that 6 month period might as well not exist as far as
project work scheduling is concerned, the only thing MS Project is concerned
with scheduling is that one 8 hour period the resource was physically
working on the client's issue.

You can certainly mix and match elapsed time where it is applicable with
conventional durations in the same project - just enter the duration with
"e" prefixed to the unit, ie, "3ed" or "32eh." A task with "24h" in the
duration column will end 24 working time hours after it starts while one
entered as "24eh" will end 24 clock hours after it starts.
--
Steve House
MS Project Trainer & Consultant

Steve House wrote:

-To be honest, I can't conceive of any reason to use elapsed
times for anything other than continuous, essentially unattended
processes such as a burn-in period on a piece of electronic hardsware or
an automated test procedure, something like that. For human activities,
measuring time in
terms of working time is far more reliable.[/-INDENT]

A similar example of a reason for elapsed times would be contractual
obligations based on calendar days (e.g.: Mandated operational
availability demonstrations, support periods, etc.). Do you have any
suggestions of how you could "mix and match" duration types within a
given project? (i.e. Use actual labor expended minutes (work days) for
most lines, but calendar / elapsed time for certain lines.) I have
projects that I track most activities by labor, but require certain
milestones to be tracked strictly based on calendar days.

Thanks,
B


--
battsman
------------------------------------------------------------------------
battsman's Profile: http://forums.techarena.in/members/122220.htm
View this thread: http://forums.techarena.in/microsoft-project/1210963.htm

http://forums.techarena.in
​

​

 

[schichtlja]

I would like Project to use calendar days for duration as a default instead of working days.Is there a switch to do this (without using the DateDifffunction)?Thanks in advance.-- Rick LaBorde ------------------------------------------------------------------------ Rick LaBorde's Profile: http://forums.techarena.in/members/113091.htm View this thread: http://forums.techarena.in/microsoft-project/1210963.htm http://forums.techarena.in

How about if the regulatory clock on my task, as specified by law, is in calendar days? It seems almost nonsensical to me that the designers of MS Project wouldn't anticipate that one would want to use calendar days instead of "work" days.