Determining Calendar Days in MS Porject 2000

[Ron]

Statistics shows me the net working days in a project. If I want to know the
calendar day duration (which would include holidays and weekends) is there a
way to find this without doing a separate calculation, i.e. simply counting
the days?

Thanks in advance for any assistance.

 

[John]

Statistics shows me the net working days in a project. If I want to know the
calendar day duration (which would include holidays and weekends) is there a
way to find this without doing a separate calculation, i.e. simply counting
the days?

Thanks in advance for any assistance.

Ron,
Elapsed days can be determined in a number of ways. One method is to
enter elapsed time directly into the Duration field (e.g. 10ed instead
of 10d). If you want to see both working Duration and elapsed Duration
you can do that also. Just set up a custom field (e.g Duration 1) with
the formula:
Duration1=DateDiff("d",[Start],[Finish])*480

The "480" factor is needed to convert the result "back" to days since a
spare duration field is being used.

Hope this helps.
John
Project MVP

 

[Gérard Ducouret]

Hi John,

It seems that this formula lose one day during the struggle : may be a time
(AM vs PM) issue.
If you add one day, it seems OK :

Duration1=(DateDiff("d",[Start],[Finish])*[Minutes per day] )+[Minutes per
day]

Gérard Ducouret

Statistics shows me the net working days in a project. If I want to know the
calendar day duration (which would include holidays and weekends) is there a
way to find this without doing a separate calculation, i.e. simply counting
the days?

Thanks in advance for any assistance.

Ron,
Elapsed days can be determined in a number of ways. One method is to
enter elapsed time directly into the Duration field (e.g. 10ed instead
of 10d). If you want to see both working Duration and elapsed Duration
you can do that also. Just set up a custom field (e.g Duration 1) with
the formula:
Duration1=DateDiff("d",[Start],[Finish])*480

The "480" factor is needed to convert the result "back" to days since a
spare duration field is being used.

Hope this helps.
John
Project MVP

 

[John]

Hi John,

It seems that this formula lose one day during the struggle : may be a time
(AM vs PM) issue.
If you add one day, it seems OK :

Duration1=(DateDiff("d",[Start],[Finish])*[Minutes per day] )+[Minutes per
day]

Gérard Ducouret

Gerard,
I only tested it on a small file and it worked properly without any
additional "fudge" factor. As a matter of fact, when I use your formula,
the answer is incorrect (i.e. one day too many). So as you say, one of
the formulas is "struggling", I don't know which.

John

 

[Gérard Ducouret]

Hi John,

It seems that this formula lose one day during the struggle : may be a
time
(AM vs PM) issue.
If you add one day, it seems OK :

Duration1=(DateDiff("d",[Start],[Finish])*[Minutes per day] )+[Minutes
per
day]

Gérard Ducouret

Gerard,
I only tested it on a small file and it worked properly without any
additional "fudge" factor. As a matter of fact, when I use your formula,
the answer is incorrect (i.e. one day too many). So as you say, one of
the formulas is "struggling", I don't know which.

John

Hi John,
Did you tried the formula on a task with "standard" duration (vs. elapsed
duration) with or without any splits?

Gérard

 

[John]

Hi John,
Did you tried the formula on a task with "standard" duration (vs. elapsed
duration) with or without any splits?

Gérard

Gerard,
If you reply please start a new thread. I normally have my newsreader
set for 100 messages and this one dropped "below my radar". I had to
remember to check.

The file I used contains "standard" working day duration and no split
tasks. It is just your generic type file, nothing special or unusual. If
the Duration field is already in "edays" there isn't any need for the
formula, right? As far as split tasks, the elapsed duration is still the
difference between Start and Finish. The split simply becomes part of
that time.

By the way I use a standard calendar (U.S. holidays) with 8 hour days
and 40 hour work week. It just doesn't make sense to put an additional
"fudge factor" into the formula without a good reason. So far, I haven't
seen that reason.

John