"Actual Duration" - behavior!!

[Kenneth]

I have a somewhat philosophical (or perhaps design related) question.

If I spent 3 days last week working on a task, I would expect to see 3 days
worth of ‘Actual Duration’ on the task, summary task as well as at the
project summary level (assuming no other work was done on the project).

However, it appears that ‘Actual Duration’ at Summary Tasks and Project
Summary Task is calculated based on the “% Complete†field. While that may
sound logical, it does create some odd results. For example, if I create a
project with 2 summary tasks each with 2 detailed tasks. Then, track 3 days
of actual duration against my first detailed task, my 3 days of actual
duration on the task translates into 1.67 days at the Summary Task and 1.77
days at the Project Summary Task. In other words, someone looking at the
project level would get the impression that less than 2 days of work was
completed, when that is in fact not the case.

To make matters worse, the numbers will change when I create dependencies on
the project. While I understand the mathematical formula of ‘Actual
Duration’ = ‘Duration’ * ‘% Complete’, I believe it’s a mistake to perform
this calculation on the Summary Tasks and the Project Summary Task,
especially so when I’ve entered ‘Actual Duration’ and not ‘% Complete’.

In my opinion, ‘Actual Duration’ on the Project Summary Task should roll up
similar to how the ‘Duration’ field does.

Any thoughts would be appreciated.

Regards,
Kenneth

PS: On past projects, I’ve always used ‘Fixed Work’, which is why I haven’t
come across this issue before.

 

[Steve House]

It all deals with the definition of 'duration' in the first place as being
'the number of calendar working time units between when work is first
performed on a task and when it is completed." When you look at summaries
and their subtasks, duration is not an additive value and the "duration" of
the summary is actually a weighted effective duration rather than an actual
physically observable metric such as elapsed time.

Just to make it even more interesting, it's not % Complete that is used to
compute the summary tasks Actual Duration and Complete Through date but
rather the % Remaining. The Summary % Complete is computed from the sum of
its subtask's Actual Durations divided by the sum of their Durations and
that is then subtracted from 100 to get Summary % Remaining. This is
multiplied by the Summary Duration to get Summary Remaining Duration and
this is subtracted from the Summary Finish to get the Complete Through date.
That way lags and leads are properly accomodated.

 

[Kenneth]

So, while it might behave as it was designed, I'm still of the opinion that
the design is wrong. It's misleading when the definition of Duration is "the
total span of active working time for a task" (and rolls up properly, I might
add) and then the definition of Actual Duration follows a different
philosophy.

It all deals with the definition of 'duration' in the first place as being
'the number of calendar working time units between when work is first
performed on a task and when it is completed." When you look at summaries
and their subtasks, duration is not an additive value and the "duration" of
the summary is actually a weighted effective duration rather than an actual
physically observable metric such as elapsed time.

Just to make it even more interesting, it's not % Complete that is used to
compute the summary tasks Actual Duration and Complete Through date but
rather the % Remaining. The Summary % Complete is computed from the sum of
its subtask's Actual Durations divided by the sum of their Durations and
that is then subtracted from 100 to get Summary % Remaining. This is
multiplied by the Summary Duration to get Summary Remaining Duration and
this is subtracted from the Summary Finish to get the Complete Through date.
That way lags and leads are properly accomodated.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

I have a somewhat philosophical (or perhaps design related) question.

If I spent 3 days last week working on a task, I would expect to see 3
days
worth of â?~Actual Durationâ?T on the task, summary task as well as at the
project summary level (assuming no other work was done on the project).

However, it appears that â?~Actual Durationâ?T at Summary Tasks and
Project
Summary Task is calculated based on the â?o% Completeâ? field. While
that may
sound logical, it does create some odd results. For example, if I create
a
project with 2 summary tasks each with 2 detailed tasks. Then, track 3
days
of actual duration against my first detailed task, my 3 days of actual
duration on the task translates into 1.67 days at the Summary Task and
1.77
days at the Project Summary Task. In other words, someone looking at the
project level would get the impression that less than 2 days of work was
completed, when that is in fact not the case.

To make matters worse, the numbers will change when I create dependencies
on
the project. While I understand the mathematical formula of â?~Actual
Durationâ?T = â?~Durationâ?T * â?~% Completeâ?T, I believe itâ?Ts a
mistake to perform
this calculation on the Summary Tasks and the Project Summary Task,
especially so when Iâ?Tve entered â?~Actual Durationâ?T and not â?~%
Completeâ?T.

In my opinion, â?~Actual Durationâ?T on the Project Summary Task should
roll up
similar to how the â?~Durationâ?T field does.

Any thoughts would be appreciated.

Regards,
Kenneth

PS: On past projects, Iâ?Tve always used â?~Fixed Workâ?T, which is why I
havenâ?Tt
come across this issue before.

 

[Steve House]

Don't fault Microsoft for a flawed design for using that definition - it
comes straight out of the ANSI accepted standards document for professional
practices in Project Management, PMI's PMBOK. And the definition of Actual
Duration is 100% consistent with that. But remember that a summary task
isn't real - it's only a virtual task that serves as a report aggregating
the metrics of the actual performance tasks underneath it. In a properly
designed WBS you should be able to remove all summary tasks as long as you
leave all the lowest level subtasks intact and still get all the work in the
project done. The duration of a summary then becomes the time between when
the earliest starting subtask starts and the last finishing subtask ends -
it is not the total of the subtask durations.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

So, while it might behave as it was designed, I'm still of the opinion
that
the design is wrong. It's misleading when the definition of Duration is
"the
total span of active working time for a task" (and rolls up properly, I
might
add) and then the definition of Actual Duration follows a different
philosophy.

It all deals with the definition of 'duration' in the first place as
being
'the number of calendar working time units between when work is first
performed on a task and when it is completed." When you look at
summaries
and their subtasks, duration is not an additive value and the "duration"
of
the summary is actually a weighted effective duration rather than an
actual
physically observable metric such as elapsed time.

Just to make it even more interesting, it's not % Complete that is used
to
compute the summary tasks Actual Duration and Complete Through date but
rather the % Remaining. The Summary % Complete is computed from the sum
of
its subtask's Actual Durations divided by the sum of their Durations and
that is then subtracted from 100 to get Summary % Remaining. This is
multiplied by the Summary Duration to get Summary Remaining Duration and
this is subtracted from the Summary Finish to get the Complete Through
date.
That way lags and leads are properly accomodated.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

I have a somewhat philosophical (or perhaps design related) question.

If I spent 3 days last week working on a task, I would expect to see 3
days
worth of â?~Actual Durationâ?T on the task, summary task as well as
at the
project summary level (assuming no other work was done on the project).

However, it appears that â?~Actual Durationâ?T at Summary Tasks and
Project
Summary Task is calculated based on the â?o% Completeâ? field.
While
that may
sound logical, it does create some odd results. For example, if I
create
a
project with 2 summary tasks each with 2 detailed tasks. Then, track 3
days
of actual duration against my first detailed task, my 3 days of actual
duration on the task translates into 1.67 days at the Summary Task and
1.77
days at the Project Summary Task. In other words, someone looking at
the
project level would get the impression that less than 2 days of work
was
completed, when that is in fact not the case.

To make matters worse, the numbers will change when I create
dependencies
on
the project. While I understand the mathematical formula of â?~Actual
Durationâ?T = â?~Durationâ?T * â?~% Completeâ?T, I believe itâ?Ts
a
mistake to perform
this calculation on the Summary Tasks and the Project Summary Task,
especially so when Iâ?Tve entered â?~Actual Durationâ?T and not
â?~%
Completeâ?T.

In my opinion, â?~Actual Durationâ?T on the Project Summary Task
should
roll up
similar to how the â?~Durationâ?T field does.

Any thoughts would be appreciated.

Regards,
Kenneth

PS: On past projects, Iâ?Tve always used â?~Fixed Workâ?T, which is
why I
havenâ?Tt
come across this issue before.