Hi Jan,
perhaps because he wants to measure how much of the Task is complete (ie %
Task Complete), such as how many bricks have been laid out of the total
number of bricks that are planned to be laid in a given Task.
I like to think of Tasks, which can be measured in this way, as being
"ideally measurable", Tasks like "Lay 10000 bricks" or "pour 50m3 of
concrete" or "shoot 1000 pigeons" or "walk 100 km", in which the stuff being
done is planned to be directly, linearly proportional to Duration, Hours and
Cost, eg "lay 10000 bricks at 1000 bricks per day for 10 days for 8 hours
per day by one guy in 80 Hours of Work at a cost of $1 per brick for bricks
and $50 per hour for the bricklayer (80 x 50 = $1600).
The bricks and pigeons and m3 are independent of planned/actual Duration,
Work, and Cost.
Of course, it makes sense at a Task level but interpretation at Summary
level is problematic, if not meaningless nonsense.
eg:
100 Build House (% Done?)
101 pour 50m3 of concrete (50% of Task done)
102 lay 10000, Bricks (25% of Task Done)
I have used spare fields to compare actual bricks at Day 6 (eg 3000) to
planned bricks by day 6 (6000), to re-estimate Remaining Duration at 14 Days
(if nothing else changes and the observed production rate is expected to
stay the same).
However, it is very common in the construction business and others, for an
observed 3000 bricks out of 10000 to be typed into the % Complete field as
30% (ie 3 days) and RD = 7 days, ie not re-estimated.
I find this scary, and usually done by those who do not know that % Complete
is about Duration.
It saves builders from having to extend the finish date of the Task and all
of its successors and the overall finish date.
Where did those missing 3 days and 3000 bricks go?
How can 7000 bricks get laid in the remaining 7 days if the observed
production rate, which is a fact and has to be better data than the "hoped
for" estimate, is only 500 bricks per day?
Trevor
