In favor of separating work and duration in tracking

[St Dilbert]

Yes, yes, yes! ;-)... thanks for the passionate reply!

I think we do agree on :"You use the baseline and the current schedule
together to compare the plan as it was expected to unfold THEN to what
has actually happened until NOW so
you can accurately predict and control what is going to happen in the
FUTURE."

But I will not agree with: "To do that successfully you simply must let
the calculating engine
do its job."

Here's an example of what I get in a weekly update: task "A" planned
40h work, planned duration tuesday of last week (we call that the
"reporting week") until monday current week. Friday afternoon the
tracking data is collected and processed on monday. Sample data for
Task "A". 32h actual work, first hours on Monday of reporting week
already, so actual start one day early - great. Still there is no entry
in "re estimate work remaining" and the task isn't set to "complete" so
there is still 8h of work to be done - no trouble so far: MSP will
stick to the finish date of monday current week after entering work.
But wait: there is an entry in "re estimate finish": thursday current
week. So the guy working on task A tells me he can't finish those 8h
work today (sickness, availability of peer review, whatever...). "Now
if I would just "let the calculation engine do its job" I am exactly
NOT comparing real performance to plan - I'm losing valuable
information. After entering the new finish date for task A I'm happy
that MSP will calculate the duration effects in the network downstream
of task A for me. But it just doesn't make sense to stick to the
planning estimate when updating a single task: how would you enter that
a task is on budget but late otherwise? Overwrite the actual cost,
manually change the units? I just find entering actual work and then
updating remaining work or finish (i.e. planned finish, not baseline)
if necessary 1:1 with the values I get from my update sheets the most
straight forward. But I need to tell MSP to keep duration and work
separate to be successful here.

 

[Rod Gill]

For that accuracy you either need to set the Friday to non-working or to use
day by day actual hours. That way Friday has 0h and Monday would have 8h.
Even better have a timesheet system such as provided by Project Server to
automatically update the schedules based on actual booked hours.

 

[Catfish Hunter]

The first thing I do before starting to update a project is turn all task
type to Fixed Work. This is really fixed man-hours. When I ask for updates I
issue a sheet that has the Sart and Fnish columns. I change the names to
Projected Start and Projected Finish. I also add the columns Actial Start and
Actual Finish. I also have the % Complete column. If a task was scheduled to
complete yesterday and for what ever reason it did not, I am given a
Projected Finish Date. This is the date I type in Projects. You can't always
allow Projects to do your thinking for you. I've had situctations where we
were missing a 2" screw on cap, we were 99.9% done with the task & delivery
was 1 week out. Same think.

 

[Steve House]

Actually the scenario you describe does not at all require work and duration
to be disconnected. A 40 man-hour task that has a daily work pattern of
8-8-8-split for 10 days-8-8 does not have a duration of 14 days, it has a
duration of 5 days. The time in the split doesn't count for duration - it's
as if the task went on holiday and those days become non-working time
excluded from the duration just like a normal weekend etc.

I was fine until you said "after entering a new finish date for Task A..."
Well, you CAN'T directly enter a new finish date for the task. Entering a
date in the scheduled Finish field does not set the finish date, it sets a
Finish No Earlier Than constraint, a whole different critter. Instead, you
can revise the duration (implying work is still continuous but there's more
of it required) or you can split the task - splitting is a more accurate
model of reality IMHO. The better approach is to ask the resource what date
he'll be able to resume work and either use that date with the "reschedule
uncompleted work" tool or display the Resume field and enter it there. That
will cause the task to split over the down time days and show the new end
date while keeping the original duration as it should. Remember, duration
and elapsed time are two different measures only roughly related to each
other. In the case of an originally continuous task that actually starts,
has some work, then stops, has some downtime, and then resumes later to
finish, the duration doesn't change but the elapsed time gets longer. When
you're saying you want Project to keep work and duration separate, it
reveals you're equating duration with elapsed time which is something you
really can't do.

Here's another way to update that will do what you need I believe. Create a
task X starting Monday, 5 days duration. Assign Leisure Suit Larry to the
task 100%. Work is 40 hours. In the Resource Usage view, display the
Actual Work row. Enter 8 hours actual work on Mon, Tue, and Wed. Now he
books off sick. Enter 0 actual hours for Thur and Fri. Now you'll see 16
hours push out into the following week, setting a new finish date of the end
of the day Tues. And of course this would push down any successor task's
starts. But the duration is still 5 days and the total work is still 40
hours.

 

[Catfish Hunter]

Steve, When you're working an outage (almost all of my schedules are outage
related) that works 24 hours a day and you are there 12 hours per day and 7
days a week you have to do what is necessary to get the job done so you can
issue your daily reports. Keep in mind 95% of the poeple you deal with are
"craft" people and don't have a clue what you're asking them and really don't
want to update you. So to compensate for this I type the finish date they
provide. There is no resume date when they are working24 hours a day.
As far as actuals: You do not get this during an outage with a 3,000 task
schedule , 150 boiler makers, 75 pipe fitters, 50 electricans, 35 instrument
techs, misc contractors...........
There is something called the "earned man-hour method" that is used to track
what percent complete you are. For this to happen the task needs to keep the
same "work" (man-hours) as when you baselined. Any other task type adds and
subtracts work. If you take your car to a dealer and he quotes you $100 you
expect to pay that amount. Later you go to pick it up and he says it's $200
because Leisure Suit Larry took longer than most people, do you owe the man
$200 - NO. If he says Leisure Suit Larry was really fast I'm only going to
charge you $50. That will never happen either. He can only earn that $100
reguardless of how his productivity was.
Earned man-hours over actual man-hours equals productivity.

Actually the scenario you describe does not at all require work and duration
to be disconnected. A 40 man-hour task that has a daily work pattern of
8-8-8-split for 10 days-8-8 does not have a duration of 14 days, it has a
duration of 5 days. The time in the split doesn't count for duration - it's
as if the task went on holiday and those days become non-working time
excluded from the duration just like a normal weekend etc.

I was fine until you said "after entering a new finish date for Task A..."
Well, you CAN'T directly enter a new finish date for the task. Entering a
date in the scheduled Finish field does not set the finish date, it sets a
Finish No Earlier Than constraint, a whole different critter. Instead, you
can revise the duration (implying work is still continuous but there's more
of it required) or you can split the task - splitting is a more accurate
model of reality IMHO. The better approach is to ask the resource what date
he'll be able to resume work and either use that date with the "reschedule
uncompleted work" tool or display the Resume field and enter it there. That
will cause the task to split over the down time days and show the new end
date while keeping the original duration as it should. Remember, duration
and elapsed time are two different measures only roughly related to each
other. In the case of an originally continuous task that actually starts,
has some work, then stops, has some downtime, and then resumes later to
finish, the duration doesn't change but the elapsed time gets longer. When
you're saying you want Project to keep work and duration separate, it
reveals you're equating duration with elapsed time which is something you
really can't do.

Here's another way to update that will do what you need I believe. Create a
task X starting Monday, 5 days duration. Assign Leisure Suit Larry to the
task 100%. Work is 40 hours. In the Resource Usage view, display the
Actual Work row. Enter 8 hours actual work on Mon, Tue, and Wed. Now he
books off sick. Enter 0 actual hours for Thur and Fri. Now you'll see 16
hours push out into the following week, setting a new finish date of the end
of the day Tues. And of course this would push down any successor task's
starts. But the duration is still 5 days and the total work is still 40
hours.
--

Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Yes, yes, yes! ;-)... thanks for the passionate reply!

I think we do agree on :"You use the baseline and the current schedule
together to compare the plan as it was expected to unfold THEN to what
has actually happened until NOW so
you can accurately predict and control what is going to happen in the
FUTURE."

But I will not agree with: "To do that successfully you simply must let
the calculating engine
do its job."

Here's an example of what I get in a weekly update: task "A" planned
40h work, planned duration tuesday of last week (we call that the
"reporting week") until monday current week. Friday afternoon the
tracking data is collected and processed on monday. Sample data for
Task "A". 32h actual work, first hours on Monday of reporting week
already, so actual start one day early - great. Still there is no entry
in "re estimate work remaining" and the task isn't set to "complete" so
there is still 8h of work to be done - no trouble so far: MSP will
stick to the finish date of monday current week after entering work.
But wait: there is an entry in "re estimate finish": thursday current
week. So the guy working on task A tells me he can't finish those 8h
work today (sickness, availability of peer review, whatever...). "Now
if I would just "let the calculation engine do its job" I am exactly
NOT comparing real performance to plan - I'm losing valuable
information. After entering the new finish date for task A I'm happy
that MSP will calculate the duration effects in the network downstream
of task A for me. But it just doesn't make sense to stick to the
planning estimate when updating a single task: how would you enter that
a task is on budget but late otherwise? Overwrite the actual cost,
manually change the units? I just find entering actual work and then
updating remaining work or finish (i.e. planned finish, not baseline)
if necessary 1:1 with the values I get from my update sheets the most
straight forward. But I need to tell MSP to keep duration and work
separate to be successful here.

 

[Steve House]

You still can't separate work and duration and vary them independently while
holding units constant. That holds as true for tracking as it does for
scheduling - perhaps even more so since tracking involves recording a
history of actual, real-world physical events that took place under clearly
understood natural laws of physics, space, and time which can't be altered
just to keep the accounting department happy <grin>. Joe working at 100%
produces 1 man-hour of work for each hour of time he puts in, no more and no
less. It is physically impossible for one person to produce 2 man-hours of
work for each single hour of time spent. OTOH, if he puts in an hour of
time and only gets half the job done he was supposed to, he wasn't working
at full capacity - he's less than 100% by definition. The only other option
is that you screwed up and over-estimated what his capacity would be given
the conditions under which the work took place, you underestimated the
man-hours that would be required, in other words.

Your auto shop example isn't a violation of the work equation, it is a
change to the effective hourly rate that the work performed costs. Your
"earned man-hour method" is Project's earned value based on hours instead of
currency units. It doesn't separate work and duration - just the opposite,
it mandates the link be retained to be valid as it compares hours actually
worked to a certain time against hours that should have been worked to that
time.

Daily reports issued simply because you need to issue daily reports are of
no value, IMHO. They should be issued only if the information they contain
is accurate and contributes to a model that leads to a valid understanding
of the behaviour of the project. Not to say you shouldn't do everything you
can to get them out daily - just that accuracy needs to trump timeliness.
Don't repeat Worldcom's mistakes <g>.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Steve, When you're working an outage (almost all of my schedules are
outage
related) that works 24 hours a day and you are there 12 hours per day and
7
days a week you have to do what is necessary to get the job done so you
can
issue your daily reports. Keep in mind 95% of the poeple you deal with are
"craft" people and don't have a clue what you're asking them and really
don't
want to update you. So to compensate for this I type the finish date they
provide. There is no resume date when they are working24 hours a day.
As far as actuals: You do not get this during an outage with a 3,000 task
schedule , 150 boiler makers, 75 pipe fitters, 50 electricans, 35
instrument
techs, misc contractors...........
There is something called the "earned man-hour method" that is used to
track
what percent complete you are. For this to happen the task needs to keep
the
same "work" (man-hours) as when you baselined. Any other task type adds
and
subtracts work. If you take your car to a dealer and he quotes you $100
you
expect to pay that amount. Later you go to pick it up and he says it's
$200
because Leisure Suit Larry took longer than most people, do you owe the
man
$200 - NO. If he says Leisure Suit Larry was really fast I'm only going to
charge you $50. That will never happen either. He can only earn that $100
reguardless of how his productivity was.
Earned man-hours over actual man-hours equals productivity.

Actually the scenario you describe does not at all require work and
duration
to be disconnected. A 40 man-hour task that has a daily work pattern of
8-8-8-split for 10 days-8-8 does not have a duration of 14 days, it has a
duration of 5 days. The time in the split doesn't count for duration -
it's
as if the task went on holiday and those days become non-working time
excluded from the duration just like a normal weekend etc.

I was fine until you said "after entering a new finish date for Task
A..."
Well, you CAN'T directly enter a new finish date for the task. Entering a
date in the scheduled Finish field does not set the finish date, it sets
a
Finish No Earlier Than constraint, a whole different critter. Instead,
you
can revise the duration (implying work is still continuous but there's
more
of it required) or you can split the task - splitting is a more accurate
model of reality IMHO. The better approach is to ask the resource what
date
he'll be able to resume work and either use that date with the
"reschedule
uncompleted work" tool or display the Resume field and enter it there.
That
will cause the task to split over the down time days and show the new end
date while keeping the original duration as it should. Remember,
duration
and elapsed time are two different measures only roughly related to each
other. In the case of an originally continuous task that actually
starts,
has some work, then stops, has some downtime, and then resumes later to
finish, the duration doesn't change but the elapsed time gets longer.
When
you're saying you want Project to keep work and duration separate, it
reveals you're equating duration with elapsed time which is something you
really can't do.

Here's another way to update that will do what you need I believe.
Create a
task X starting Monday, 5 days duration. Assign Leisure Suit Larry to
the
task 100%. Work is 40 hours. In the Resource Usage view, display the
Actual Work row. Enter 8 hours actual work on Mon, Tue, and Wed. Now he
books off sick. Enter 0 actual hours for Thur and Fri. Now you'll see
16
hours push out into the following week, setting a new finish date of the
end
of the day Tues. And of course this would push down any successor task's
starts. But the duration is still 5 days and the total work is still 40
hours.
--

Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Yes, yes, yes! ;-)... thanks for the passionate reply!

I think we do agree on :"You use the baseline and the current schedule
together to compare the plan as it was expected to unfold THEN to what
has actually happened until NOW so
you can accurately predict and control what is going to happen in the
FUTURE."

But I will not agree with: "To do that successfully you simply must let
the calculating engine
do its job."

Here's an example of what I get in a weekly update: task "A" planned
40h work, planned duration tuesday of last week (we call that the
"reporting week") until monday current week. Friday afternoon the
tracking data is collected and processed on monday. Sample data for
Task "A". 32h actual work, first hours on Monday of reporting week
already, so actual start one day early - great. Still there is no entry
in "re estimate work remaining" and the task isn't set to "complete" so
there is still 8h of work to be done - no trouble so far: MSP will
stick to the finish date of monday current week after entering work.
But wait: there is an entry in "re estimate finish": thursday current
week. So the guy working on task A tells me he can't finish those 8h
work today (sickness, availability of peer review, whatever...). "Now
if I would just "let the calculation engine do its job" I am exactly
NOT comparing real performance to plan - I'm losing valuable
information. After entering the new finish date for task A I'm happy
that MSP will calculate the duration effects in the network downstream
of task A for me. But it just doesn't make sense to stick to the
planning estimate when updating a single task: how would you enter that
a task is on budget but late otherwise? Overwrite the actual cost,
manually change the units? I just find entering actual work and then
updating remaining work or finish (i.e. planned finish, not baseline)
if necessary 1:1 with the values I get from my update sheets the most
straight forward. But I need to tell MSP to keep duration and work
separate to be successful here.

 

[Catfish Hunter]

Yes you can. Been doing it for 30 years. There is an estimate done on how
many man-hours it takes to complete a task. From there you get duration not
the other way around. Earned man-hour method is what ALL major construction
companies ues. I worked for Halliburton for 25 years and this is what we
used.

It's a shame you have no pratical experience on a large construction site.

It would help you understand how real world schedulers work and what they
really need. End of story!

You still can't separate work and duration and vary them independently while
holding units constant. That holds as true for tracking as it does for
scheduling - perhaps even more so since tracking involves recording a
history of actual, real-world physical events that took place under clearly
understood natural laws of physics, space, and time which can't be altered
just to keep the accounting department happy <grin>. Joe working at 100%
produces 1 man-hour of work for each hour of time he puts in, no more and no
less. It is physically impossible for one person to produce 2 man-hours of
work for each single hour of time spent. OTOH, if he puts in an hour of
time and only gets half the job done he was supposed to, he wasn't working
at full capacity - he's less than 100% by definition. The only other option
is that you screwed up and over-estimated what his capacity would be given
the conditions under which the work took place, you underestimated the
man-hours that would be required, in other words.

Your auto shop example isn't a violation of the work equation, it is a
change to the effective hourly rate that the work performed costs. Your
"earned man-hour method" is Project's earned value based on hours instead of
currency units. It doesn't separate work and duration - just the opposite,
it mandates the link be retained to be valid as it compares hours actually
worked to a certain time against hours that should have been worked to that
time.

Daily reports issued simply because you need to issue daily reports are of
no value, IMHO. They should be issued only if the information they contain
is accurate and contributes to a model that leads to a valid understanding
of the behaviour of the project. Not to say you shouldn't do everything you
can to get them out daily - just that accuracy needs to trump timeliness.
Don't repeat Worldcom's mistakes <g>.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Steve, When you're working an outage (almost all of my schedules are
outage
related) that works 24 hours a day and you are there 12 hours per day and
7
days a week you have to do what is necessary to get the job done so you
can
issue your daily reports. Keep in mind 95% of the poeple you deal with are
"craft" people and don't have a clue what you're asking them and really
don't
want to update you. So to compensate for this I type the finish date they
provide. There is no resume date when they are working24 hours a day.
As far as actuals: You do not get this during an outage with a 3,000 task
schedule , 150 boiler makers, 75 pipe fitters, 50 electricans, 35
instrument
techs, misc contractors...........
There is something called the "earned man-hour method" that is used to
track
what percent complete you are. For this to happen the task needs to keep
the
same "work" (man-hours) as when you baselined. Any other task type adds
and
subtracts work. If you take your car to a dealer and he quotes you $100
you
expect to pay that amount. Later you go to pick it up and he says it's
$200
because Leisure Suit Larry took longer than most people, do you owe the
man
$200 - NO. If he says Leisure Suit Larry was really fast I'm only going to
charge you $50. That will never happen either. He can only earn that $100
reguardless of how his productivity was.
Earned man-hours over actual man-hours equals productivity.

Actually the scenario you describe does not at all require work and
duration
to be disconnected. A 40 man-hour task that has a daily work pattern of
8-8-8-split for 10 days-8-8 does not have a duration of 14 days, it has a
duration of 5 days. The time in the split doesn't count for duration -
it's
as if the task went on holiday and those days become non-working time
excluded from the duration just like a normal weekend etc.

I was fine until you said "after entering a new finish date for Task
A..."
Well, you CAN'T directly enter a new finish date for the task. Entering a
date in the scheduled Finish field does not set the finish date, it sets
a
Finish No Earlier Than constraint, a whole different critter. Instead,
you
can revise the duration (implying work is still continuous but there's
more
of it required) or you can split the task - splitting is a more accurate
model of reality IMHO. The better approach is to ask the resource what
date
he'll be able to resume work and either use that date with the
"reschedule
uncompleted work" tool or display the Resume field and enter it there.
That
will cause the task to split over the down time days and show the new end
date while keeping the original duration as it should. Remember,
duration
and elapsed time are two different measures only roughly related to each
other. In the case of an originally continuous task that actually
starts,
has some work, then stops, has some downtime, and then resumes later to
finish, the duration doesn't change but the elapsed time gets longer.
When
you're saying you want Project to keep work and duration separate, it
reveals you're equating duration with elapsed time which is something you
really can't do.

Here's another way to update that will do what you need I believe.
Create a
task X starting Monday, 5 days duration. Assign Leisure Suit Larry to
the
task 100%. Work is 40 hours. In the Resource Usage view, display the
Actual Work row. Enter 8 hours actual work on Mon, Tue, and Wed. Now he
books off sick. Enter 0 actual hours for Thur and Fri. Now you'll see
16
hours push out into the following week, setting a new finish date of the
end
of the day Tues. And of course this would push down any successor task's
starts. But the duration is still 5 days and the total work is still 40
hours.
--

Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


Yes, yes, yes! ;-)... thanks for the passionate reply!

I think we do agree on :"You use the baseline and the current schedule
together to compare the plan as it was expected to unfold THEN to what
has actually happened until NOW so
you can accurately predict and control what is going to happen in the
FUTURE."

But I will not agree with: "To do that successfully you simply must let
the calculating engine
do its job."

Here's an example of what I get in a weekly update: task "A" planned
40h work, planned duration tuesday of last week (we call that the
"reporting week") until monday current week. Friday afternoon the
tracking data is collected and processed on monday. Sample data for
Task "A". 32h actual work, first hours on Monday of reporting week
already, so actual start one day early - great. Still there is no entry
in "re estimate work remaining" and the task isn't set to "complete" so
there is still 8h of work to be done - no trouble so far: MSP will
stick to the finish date of monday current week after entering work.
But wait: there is an entry in "re estimate finish": thursday current
week. So the guy working on task A tells me he can't finish those 8h
work today (sickness, availability of peer review, whatever...). "Now
if I would just "let the calculation engine do its job" I am exactly
NOT comparing real performance to plan - I'm losing valuable
information. After entering the new finish date for task A I'm happy
that MSP will calculate the duration effects in the network downstream
of task A for me. But it just doesn't make sense to stick to the
planning estimate when updating a single task: how would you enter that
a task is on budget but late otherwise? Overwrite the actual cost,
manually change the units? I just find entering actual work and then
updating remaining work or finish (i.e. planned finish, not baseline)
if necessary 1:1 with the values I get from my update sheets the most
straight forward. But I need to tell MSP to keep duration and work
separate to be successful here.

 

[Steve House]

You have been saying you can separate the estimates of work and the
estimates of duration. Now you're saying you estimate work and it gives you
duration. Which is it? Are they linked or are they independent? I never
said you can't go at the estimating process from either direction, only that
work and duration will always be linked to each other by some constant.
W=D*U always holds true in Project because it always holds true in the
physical world. If the resources commitment stays constant, increasing the
man-hours of work required to complete the task will increase the length of
time it takes to do that task, or vice versa. IF you have reliable man-hour
estimates of the work required for various activities, by all means use them
if you wish. Most people have better historical data about the length of
time a task took than how many man-hours of effort were required but if you
have good history of work required for various tasks go for it. But
estimating work to get duration or using earned value, whether the "value"
be measured in man-hours or dollars, to track progress does NOT require
violating or ignoring the fact that the time required to complete a task is
directly proportional to the man-hours of effort that will be required to
achieve the deliverable, the amount of resources committed to the task being
the constant of proportionality. If by separating the two you mean that in
5 days of duration I might achieve 8 or 16 or 32 or some other number of
man-hours of work you are correct. But they are still locked together by
the level of resource committment applied to the task with the numbers in
the instant case representing 20%, 40%, and 80% of the resource's energy
being utilized respectively. What you are trying to say is that with a
resource committed 100%, 8 hours of constant full-time work by a resource
who works 8 hours per day might take 1 day or 2 days or 3 days, etc and
that's simply not true. I might have budgeted 8 hours a day but not get 8
hours a day, that's another matter. Or I might have budgeted 40 man-hours
to do a task that really will require 80 man-hours, that too is another
matter. If you've been filing progress reports for 30 years based on the
idea that work and duration are completely independent of each other for any
given resource level and 100% effort results in 8 hours of work taking 1, 2,
3, 5, or whatever days, you've been doing it wrong for 30 years.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Yes you can. Been doing it for 30 years. There is an estimate done on how
many man-hours it takes to complete a task. From there you get duration
not
the other way around. Earned man-hour method is what ALL major
construction
companies ues. I worked for Halliburton for 25 years and this is what we
used.

It's a shame you have no pratical experience on a large construction site.

It would help you understand how real world schedulers work and what they
really need. End of story!

You still can't separate work and duration and vary them independently
while
holding units constant. That holds as true for tracking as it does for
scheduling - perhaps even more so since tracking involves recording a
history of actual, real-world physical events that took place under
clearly
understood natural laws of physics, space, and time which can't be
altered
just to keep the accounting department happy <grin>. Joe working at 100%
produces 1 man-hour of work for each hour of time he puts in, no more and
no
less. It is physically impossible for one person to produce 2 man-hours
of
work for each single hour of time spent. OTOH, if he puts in an hour of
time and only gets half the job done he was supposed to, he wasn't
working
at full capacity - he's less than 100% by definition. The only other
option
is that you screwed up and over-estimated what his capacity would be
given
the conditions under which the work took place, you underestimated the
man-hours that would be required, in other words.

Your auto shop example isn't a violation of the work equation, it is a
change to the effective hourly rate that the work performed costs. Your
"earned man-hour method" is Project's earned value based on hours instead
of
currency units. It doesn't separate work and duration - just the
opposite,
it mandates the link be retained to be valid as it compares hours
actually
worked to a certain time against hours that should have been worked to
that
time.

Daily reports issued simply because you need to issue daily reports are
of
no value, IMHO. They should be issued only if the information they
contain
is accurate and contributes to a model that leads to a valid
understanding
of the behaviour of the project. Not to say you shouldn't do everything
you
can to get them out daily - just that accuracy needs to trump timeliness.
Don't repeat Worldcom's mistakes <g>.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


message

Steve, When you're working an outage (almost all of my schedules are
outage
related) that works 24 hours a day and you are there 12 hours per day
and
7
days a week you have to do what is necessary to get the job done so you
can
issue your daily reports. Keep in mind 95% of the poeple you deal with
are
"craft" people and don't have a clue what you're asking them and really
don't
want to update you. So to compensate for this I type the finish date
they
provide. There is no resume date when they are working24 hours a day.
As far as actuals: You do not get this during an outage with a 3,000
task
schedule , 150 boiler makers, 75 pipe fitters, 50 electricans, 35
instrument
techs, misc contractors...........
There is something called the "earned man-hour method" that is used to
track
what percent complete you are. For this to happen the task needs to
keep
the
same "work" (man-hours) as when you baselined. Any other task type adds
and
subtracts work. If you take your car to a dealer and he quotes you $100
you
expect to pay that amount. Later you go to pick it up and he says it's
$200
because Leisure Suit Larry took longer than most people, do you owe the
man
$200 - NO. If he says Leisure Suit Larry was really fast I'm only going
to
charge you $50. That will never happen either. He can only earn that
$100
reguardless of how his productivity was.
Earned man-hours over actual man-hours equals productivity.


:

Actually the scenario you describe does not at all require work and
duration
to be disconnected. A 40 man-hour task that has a daily work pattern
of
8-8-8-split for 10 days-8-8 does not have a duration of 14 days, it
has a
duration of 5 days. The time in the split doesn't count for
duration -
it's
as if the task went on holiday and those days become non-working time
excluded from the duration just like a normal weekend etc.

I was fine until you said "after entering a new finish date for Task
A..."
Well, you CAN'T directly enter a new finish date for the task.
Entering a
date in the scheduled Finish field does not set the finish date, it
sets
a
Finish No Earlier Than constraint, a whole different critter.
Instead,
you
can revise the duration (implying work is still continuous but there's
more
of it required) or you can split the task - splitting is a more
accurate
model of reality IMHO. The better approach is to ask the resource
what
date
he'll be able to resume work and either use that date with the
"reschedule
uncompleted work" tool or display the Resume field and enter it there.
That
will cause the task to split over the down time days and show the new
end
date while keeping the original duration as it should. Remember,
duration
and elapsed time are two different measures only roughly related to
each
other. In the case of an originally continuous task that actually
starts,
has some work, then stops, has some downtime, and then resumes later
to
finish, the duration doesn't change but the elapsed time gets longer.
When
you're saying you want Project to keep work and duration separate, it
reveals you're equating duration with elapsed time which is something
you
really can't do.

Here's another way to update that will do what you need I believe.
Create a
task X starting Monday, 5 days duration. Assign Leisure Suit Larry to
the
task 100%. Work is 40 hours. In the Resource Usage view, display the
Actual Work row. Enter 8 hours actual work on Mon, Tue, and Wed. Now
he
books off sick. Enter 0 actual hours for Thur and Fri. Now you'll
see
16
hours push out into the following week, setting a new finish date of
the
end
of the day Tues. And of course this would push down any successor
task's
starts. But the duration is still 5 days and the total work is still
40
hours.
--

Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


Yes, yes, yes! ;-)... thanks for the passionate reply!

I think we do agree on :"You use the baseline and the current
schedule
together to compare the plan as it was expected to unfold THEN to
what
has actually happened until NOW so
you can accurately predict and control what is going to happen in
the
FUTURE."

But I will not agree with: "To do that successfully you simply must
let
the calculating engine
do its job."

Here's an example of what I get in a weekly update: task "A" planned
40h work, planned duration tuesday of last week (we call that the
"reporting week") until monday current week. Friday afternoon the
tracking data is collected and processed on monday. Sample data for
Task "A". 32h actual work, first hours on Monday of reporting week
already, so actual start one day early - great. Still there is no
entry
in "re estimate work remaining" and the task isn't set to "complete"
so
there is still 8h of work to be done - no trouble so far: MSP will
stick to the finish date of monday current week after entering work.
But wait: there is an entry in "re estimate finish": thursday
current
week. So the guy working on task A tells me he can't finish those 8h
work today (sickness, availability of peer review, whatever...).
"Now
if I would just "let the calculation engine do its job" I am exactly
NOT comparing real performance to plan - I'm losing valuable
information. After entering the new finish date for task A I'm happy
that MSP will calculate the duration effects in the network
downstream
of task A for me. But it just doesn't make sense to stick to the
planning estimate when updating a single task: how would you enter
that
a task is on budget but late otherwise? Overwrite the actual cost,
manually change the units? I just find entering actual work and then
updating remaining work or finish (i.e. planned finish, not
baseline)
if necessary 1:1 with the values I get from my update sheets the
most
straight forward. But I need to tell MSP to keep duration and work
separate to be successful here.

 

[Catfish Hunter]

I did not even waste my time to read your reply. This site is to help people
with MS Projects problems, not for your personal soap box. Get over it Steve
and grow up.

You have been saying you can separate the estimates of work and the
estimates of duration. Now you're saying you estimate work and it gives you
duration. Which is it? Are they linked or are they independent? I never
said you can't go at the estimating process from either direction, only that
work and duration will always be linked to each other by some constant.
W=D*U always holds true in Project because it always holds true in the
physical world. If the resources commitment stays constant, increasing the
man-hours of work required to complete the task will increase the length of
time it takes to do that task, or vice versa. IF you have reliable man-hour
estimates of the work required for various activities, by all means use them
if you wish. Most people have better historical data about the length of
time a task took than how many man-hours of effort were required but if you
have good history of work required for various tasks go for it. But
estimating work to get duration or using earned value, whether the "value"
be measured in man-hours or dollars, to track progress does NOT require
violating or ignoring the fact that the time required to complete a task is
directly proportional to the man-hours of effort that will be required to
achieve the deliverable, the amount of resources committed to the task being
the constant of proportionality. If by separating the two you mean that in
5 days of duration I might achieve 8 or 16 or 32 or some other number of
man-hours of work you are correct. But they are still locked together by
the level of resource committment applied to the task with the numbers in
the instant case representing 20%, 40%, and 80% of the resource's energy
being utilized respectively. What you are trying to say is that with a
resource committed 100%, 8 hours of constant full-time work by a resource
who works 8 hours per day might take 1 day or 2 days or 3 days, etc and
that's simply not true. I might have budgeted 8 hours a day but not get 8
hours a day, that's another matter. Or I might have budgeted 40 man-hours
to do a task that really will require 80 man-hours, that too is another
matter. If you've been filing progress reports for 30 years based on the
idea that work and duration are completely independent of each other for any
given resource level and 100% effort results in 8 hours of work taking 1, 2,
3, 5, or whatever days, you've been doing it wrong for 30 years.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Yes you can. Been doing it for 30 years. There is an estimate done on how
many man-hours it takes to complete a task. From there you get duration
not
the other way around. Earned man-hour method is what ALL major
construction
companies ues. I worked for Halliburton for 25 years and this is what we
used.

It's a shame you have no pratical experience on a large construction site.

It would help you understand how real world schedulers work and what they
really need. End of story!

You still can't separate work and duration and vary them independently
while
holding units constant. That holds as true for tracking as it does for
scheduling - perhaps even more so since tracking involves recording a
history of actual, real-world physical events that took place under
clearly
understood natural laws of physics, space, and time which can't be
altered
just to keep the accounting department happy <grin>. Joe working at 100%
produces 1 man-hour of work for each hour of time he puts in, no more and
no
less. It is physically impossible for one person to produce 2 man-hours
of
work for each single hour of time spent. OTOH, if he puts in an hour of
time and only gets half the job done he was supposed to, he wasn't
working
at full capacity - he's less than 100% by definition. The only other
option
is that you screwed up and over-estimated what his capacity would be
given
the conditions under which the work took place, you underestimated the
man-hours that would be required, in other words.

Your auto shop example isn't a violation of the work equation, it is a
change to the effective hourly rate that the work performed costs. Your
"earned man-hour method" is Project's earned value based on hours instead
of
currency units. It doesn't separate work and duration - just the
opposite,
it mandates the link be retained to be valid as it compares hours
actually
worked to a certain time against hours that should have been worked to
that
time.

Daily reports issued simply because you need to issue daily reports are
of
no value, IMHO. They should be issued only if the information they
contain
is accurate and contributes to a model that leads to a valid
understanding
of the behaviour of the project. Not to say you shouldn't do everything
you
can to get them out daily - just that accuracy needs to trump timeliness.
Don't repeat Worldcom's mistakes <g>.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


message
Steve, When you're working an outage (almost all of my schedules are
outage
related) that works 24 hours a day and you are there 12 hours per day
and
7
days a week you have to do what is necessary to get the job done so you
can
issue your daily reports. Keep in mind 95% of the poeple you deal with
are
"craft" people and don't have a clue what you're asking them and really
don't
want to update you. So to compensate for this I type the finish date
they
provide. There is no resume date when they are working24 hours a day.
As far as actuals: You do not get this during an outage with a 3,000
task
schedule , 150 boiler makers, 75 pipe fitters, 50 electricans, 35
instrument
techs, misc contractors...........
There is something called the "earned man-hour method" that is used to
track
what percent complete you are. For this to happen the task needs to
keep
the
same "work" (man-hours) as when you baselined. Any other task type adds
and
subtracts work. If you take your car to a dealer and he quotes you $100
you
expect to pay that amount. Later you go to pick it up and he says it's
$200
because Leisure Suit Larry took longer than most people, do you owe the
man
$200 - NO. If he says Leisure Suit Larry was really fast I'm only going
to
charge you $50. That will never happen either. He can only earn that
$100
reguardless of how his productivity was.
Earned man-hours over actual man-hours equals productivity.


:

Actually the scenario you describe does not at all require work and
duration
to be disconnected. A 40 man-hour task that has a daily work pattern
of
8-8-8-split for 10 days-8-8 does not have a duration of 14 days, it
has a
duration of 5 days. The time in the split doesn't count for
duration -
it's
as if the task went on holiday and those days become non-working time
excluded from the duration just like a normal weekend etc.

I was fine until you said "after entering a new finish date for Task
A..."
Well, you CAN'T directly enter a new finish date for the task.
Entering a
date in the scheduled Finish field does not set the finish date, it
sets
a
Finish No Earlier Than constraint, a whole different critter.
Instead,
you
can revise the duration (implying work is still continuous but there's
more
of it required) or you can split the task - splitting is a more
accurate
model of reality IMHO. The better approach is to ask the resource
what
date
he'll be able to resume work and either use that date with the
"reschedule
uncompleted work" tool or display the Resume field and enter it there.
That
will cause the task to split over the down time days and show the new
end
date while keeping the original duration as it should. Remember,
duration
and elapsed time are two different measures only roughly related to
each
other. In the case of an originally continuous task that actually
starts,
has some work, then stops, has some downtime, and then resumes later
to
finish, the duration doesn't change but the elapsed time gets longer.
When
you're saying you want Project to keep work and duration separate, it
reveals you're equating duration with elapsed time which is something
you
really can't do.

Here's another way to update that will do what you need I believe.
Create a
task X starting Monday, 5 days duration. Assign Leisure Suit Larry to
the
task 100%. Work is 40 hours. In the Resource Usage view, display the
Actual Work row. Enter 8 hours actual work on Mon, Tue, and Wed. Now
he
books off sick. Enter 0 actual hours for Thur and Fri. Now you'll
see
16
hours push out into the following week, setting a new finish date of
the
end
of the day Tues. And of course this would push down any successor
task's
starts. But the duration is still 5 days and the total work is still
40
hours.
--

Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


Yes, yes, yes! ;-)... thanks for the passionate reply!

I think we do agree on :"You use the baseline and the current
schedule
together to compare the plan as it was expected to unfold THEN to
what
has actually happened until NOW so
you can accurately predict and control what is going to happen in
the
FUTURE."

But I will not agree with: "To do that successfully you simply must
let
the calculating engine
do its job."

Here's an example of what I get in a weekly update: task "A" planned
40h work, planned duration tuesday of last week (we call that the
"reporting week") until monday current week. Friday afternoon the
tracking data is collected and processed on monday. Sample data for
Task "A". 32h actual work, first hours on Monday of reporting week
already, so actual start one day early - great. Still there is no
entry
in "re estimate work remaining" and the task isn't set to "complete"
so
there is still 8h of work to be done - no trouble so far: MSP will
stick to the finish date of monday current week after entering work.
But wait: there is an entry in "re estimate finish": thursday
current
week. So the guy working on task A tells me he can't finish those 8h
work today (sickness, availability of peer review, whatever...).
"Now
if I would just "let the calculation engine do its job" I am exactly
NOT comparing real performance to plan - I'm losing valuable
information. After entering the new finish date for task A I'm happy
that MSP will calculate the duration effects in the network
downstream
of task A for me. But it just doesn't make sense to stick to the
planning estimate when updating a single task: how would you enter
that
a task is on budget but late otherwise? Overwrite the actual cost,
manually change the units? I just find entering actual work and then
updating remaining work or finish (i.e. planned finish, not
baseline)
if necessary 1:1 with the values I get from my update sheets the
most
straight forward. But I need to tell MSP to keep duration and work
separate to be successful here.

 

[St Dilbert]

This post was intended as a reply to a post in´the thread "Effort,
duration, Resources independently" - for reasons unclear to me Goggle
groups created new threads when I was trying to reply - sorry for the
confusion :-(...

But now that reply works again, I'm pleased to see the lively
response...

 

[St Dilbert]

I need to clarify a bit on
<<[Steve House:] I was fine until you said "after entering a new finish
date for Task A..." Well, you CAN'T directly enter a new finish date
for the task.>>

I agree with that - and I wasn't describing my process accurately. I do
receive new finish dates as data in the sheets for actual data, because
"I will be done on dd-mm-yyyy" just comes more natural than "I will
need x more work periods". But I have a little helper macro converting
the "new finish date" into a remaining duration value and entering that
for me. I'm so used to it, I keep forgetting it's not part of MS
Project. So maybe with that extra information, everything is fine? ;-)

Actually the scenario you describe does not at all require work and duration
to be disconnected. A 40 man-hour task that has a daily work pattern of
8-8-8-split for 10 days-8-8 does not have a duration of 14 days, it has a
duration of 5 days. The time in the split doesn't count for duration - it's
as if the task went on holiday and those days become non-working time
excluded from the duration just like a normal weekend etc.

I was fine until you said "after entering a new finish date for Task A..."
Well, you CAN'T directly enter a new finish date for the task. Entering a
date in the scheduled Finish field does not set the finish date, it sets a
Finish No Earlier Than constraint, a whole different critter. Instead, you
can revise the duration (implying work is still continuous but there's more
of it required) or you can split the task - splitting is a more accurate
model of reality IMHO. The better approach is to ask the resource what date
he'll be able to resume work and either use that date with the "reschedule
uncompleted work" tool or display the Resume field and enter it there. That
will cause the task to split over the down time days and show the new end
date while keeping the original duration as it should. Remember, duration
and elapsed time are two different measures only roughly related to each
other. In the case of an originally continuous task that actually starts,
has some work, then stops, has some downtime, and then resumes later to
finish, the duration doesn't change but the elapsed time gets longer. When
you're saying you want Project to keep work and duration separate, it
reveals you're equating duration with elapsed time which is something you
really can't do.

Here's another way to update that will do what you need I believe. Create a
task X starting Monday, 5 days duration. Assign Leisure Suit Larry to the
task 100%. Work is 40 hours. In the Resource Usage view, display the
Actual Work row. Enter 8 hours actual work on Mon, Tue, and Wed. Now he
books off sick. Enter 0 actual hours for Thur and Fri. Now you'll see 16
hours push out into the following week, setting a new finish date of the end
of the day Tues. And of course this would push down any successor task's
starts. But the duration is still 5 days and the total work is still 40
hours.
--

Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Yes, yes, yes! ;-)... thanks for the passionate reply!

I think we do agree on :"You use the baseline and the current schedule
together to compare the plan as it was expected to unfold THEN to what
has actually happened until NOW so
you can accurately predict and control what is going to happen in the
FUTURE."

But I will not agree with: "To do that successfully you simply must let
the calculating engine
do its job."

Here's an example of what I get in a weekly update: task "A" planned
40h work, planned duration tuesday of last week (we call that the
"reporting week") until monday current week. Friday afternoon the
tracking data is collected and processed on monday. Sample data for
Task "A". 32h actual work, first hours on Monday of reporting week
already, so actual start one day early - great. Still there is no entry
in "re estimate work remaining" and the task isn't set to "complete" so
there is still 8h of work to be done - no trouble so far: MSP will
stick to the finish date of monday current week after entering work.
But wait: there is an entry in "re estimate finish": thursday current
week. So the guy working on task A tells me he can't finish those 8h
work today (sickness, availability of peer review, whatever...). "Now
if I would just "let the calculation engine do its job" I am exactly
NOT comparing real performance to plan - I'm losing valuable
information. After entering the new finish date for task A I'm happy
that MSP will calculate the duration effects in the network downstream
of task A for me. But it just doesn't make sense to stick to the
planning estimate when updating a single task: how would you enter that
a task is on budget but late otherwise? Overwrite the actual cost,
manually change the units? I just find entering actual work and then
updating remaining work or finish (i.e. planned finish, not baseline)
if necessary 1:1 with the values I get from my update sheets the most
straight forward. But I need to tell MSP to keep duration and work
separate to be successful here.

 

[St Dilbert]

Now that the laws of physics are brought into play: W=D*U is NOT the
world formula. It is the roughest possible (linear) approximation on
how one could model the way result production in a project will take
place. Even if we accept the fact that we have to work with this
simplistic formula you just supported my point: whichever way you look
at "W=D*U" it says you need TWO values to determine the third one. For
example a value for work and another for duration to calculate units.
Just because MS Project doesn't change unit assignments around doesn't
mean these are by law of nature constant between plan and actual.

Let me illustrate this by going back to the original example and using
the linear approximation:
plan: 40h Work = 5 days (@8h) * 100%;
actual: 40 h work = 9 days (Monday last week - Thursday next week) *
55,6%

So yes in a way the formula is "always true". But can you tell me how
to collect actuals on "unit" in the real world? What I can get is hours
worked on a task and calendar dates when the work started and when it
finished or estimates for those while we're still in the middle of that
task.

Maybe "making units flexible when entering actuals" is a better
description of what I'm trying to do than "separating work and
duration". Again back to the example: I get updates on work (32 hours
worked, 8h work to go) AND duration (started on monday last week and
going to finish this thursday) - I do NOT get an update "On average I'm
putting 55,6% of my availability to work on task A".

My point is: if I "just let the calculation engine do it's job" as
configured in default (task updates resource i.e. %work updates
%duration) I'm throwing away valuable information!
If I just entered %work complete as expected (8h work to go) Project
would tell me to expect the task to be finished on monday (current
week) and this is not correct - it will finish on Thursday.
If I just entered "remaining duration 4 more days (+ 5 actual)" then
Project would tell me the task is expected to cost almost double (54
hours work instead of 40h in line with baseline).

So maybe we can find common ground with this description:
In tracking a plan you need to collect actuals on two different
dimensions to reflect your actual vs. baseline development correctly.
Since collecting actuals on "unit" is rather impractical (at least for
StDilbert) that leaves you with asking for actuals on work (estimated
work remaining) and duration (estimated remaining duration) separately.
You have to tell MSP to not assume that by knowing one value it can
determine two others, just because there is no functionality in there
that will ever change the unit assignment...

You still can't separate work and duration and vary them independently while
holding units constant. That holds as true for tracking as it does for
scheduling - perhaps even more so since tracking involves recording a
history of actual, real-world physical events that took place under clearly
understood natural laws of physics, space, and time which can't be altered
just to keep the accounting department happy <grin>. Joe working at 100%
produces 1 man-hour of work for each hour of time he puts in, no more and no
less. It is physically impossible for one person to produce 2 man-hours of
work for each single hour of time spent. OTOH, if he puts in an hour of
time and only gets half the job done he was supposed to, he wasn't working
at full capacity - he's less than 100% by definition. The only other option
is that you screwed up and over-estimated what his capacity would be given
the conditions under which the work took place, you underestimated the
man-hours that would be required, in other words.

Your auto shop example isn't a violation of the work equation, it is a
change to the effective hourly rate that the work performed costs. Your
"earned man-hour method" is Project's earned value based on hours instead of
currency units. It doesn't separate work and duration - just the opposite,
it mandates the link be retained to be valid as it compares hours actually
worked to a certain time against hours that should have been worked to that
time.

Daily reports issued simply because you need to issue daily reports are of
no value, IMHO. They should be issued only if the information they contain
is accurate and contributes to a model that leads to a valid understanding
of the behaviour of the project. Not to say you shouldn't do everything you
can to get them out daily - just that accuracy needs to trump timeliness.
Don't repeat Worldcom's mistakes <g>.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Steve, When you're working an outage (almost all of my schedules are
outage
related) that works 24 hours a day and you are there 12 hours per day and
7
days a week you have to do what is necessary to get the job done so you
can
issue your daily reports. Keep in mind 95% of the poeple you deal with are
"craft" people and don't have a clue what you're asking them and really
don't
want to update you. So to compensate for this I type the finish date they
provide. There is no resume date when they are working24 hours a day.
As far as actuals: You do not get this during an outage with a 3,000 task
schedule , 150 boiler makers, 75 pipe fitters, 50 electricans, 35
instrument
techs, misc contractors...........
There is something called the "earned man-hour method" that is used to
track
what percent complete you are. For this to happen the task needs to keep
the
same "work" (man-hours) as when you baselined. Any other task type adds
and
subtracts work. If you take your car to a dealer and he quotes you $100
you
expect to pay that amount. Later you go to pick it up and he says it's
$200
because Leisure Suit Larry took longer than most people, do you owe the
man
$200 - NO. If he says Leisure Suit Larry was really fast I'm only going to
charge you $50. That will never happen either. He can only earn that $100
reguardless of how his productivity was.
Earned man-hours over actual man-hours equals productivity.

Actually the scenario you describe does not at all require work and
duration
to be disconnected. A 40 man-hour task that has a daily work pattern of
8-8-8-split for 10 days-8-8 does not have a duration of 14 days, it has a
duration of 5 days. The time in the split doesn't count for duration -
it's
as if the task went on holiday and those days become non-working time
excluded from the duration just like a normal weekend etc.

I was fine until you said "after entering a new finish date for Task
A..."
Well, you CAN'T directly enter a new finish date for the task. Entering a
date in the scheduled Finish field does not set the finish date, it sets
a
Finish No Earlier Than constraint, a whole different critter. Instead,
you
can revise the duration (implying work is still continuous but there's
more
of it required) or you can split the task - splitting is a more accurate
model of reality IMHO. The better approach is to ask the resource what
date
he'll be able to resume work and either use that date with the
"reschedule
uncompleted work" tool or display the Resume field and enter it there.
That
will cause the task to split over the down time days and show the new end
date while keeping the original duration as it should. Remember,
duration
and elapsed time are two different measures only roughly related to each
other. In the case of an originally continuous task that actually
starts,
has some work, then stops, has some downtime, and then resumes later to
finish, the duration doesn't change but the elapsed time gets longer.
When
you're saying you want Project to keep work and duration separate, it
reveals you're equating duration with elapsed time which is something you
really can't do.

Here's another way to update that will do what you need I believe.
Create a
task X starting Monday, 5 days duration. Assign Leisure Suit Larry to
the
task 100%. Work is 40 hours. In the Resource Usage view, display the
Actual Work row. Enter 8 hours actual work on Mon, Tue, and Wed. Now he
books off sick. Enter 0 actual hours for Thur and Fri. Now you'll see
16
hours push out into the following week, setting a new finish date of the
end
of the day Tues. And of course this would push down any successor task's
starts. But the duration is still 5 days and the total work is still 40
hours.
--

Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


Yes, yes, yes! ;-)... thanks for the passionate reply!

I think we do agree on :"You use the baseline and the current schedule
together to compare the plan as it was expected to unfold THEN to what
has actually happened until NOW so
you can accurately predict and control what is going to happen in the
FUTURE."

But I will not agree with: "To do that successfully you simply must let
the calculating engine
do its job."

Here's an example of what I get in a weekly update: task "A" planned
40h work, planned duration tuesday of last week (we call that the
"reporting week") until monday current week. Friday afternoon the
tracking data is collected and processed on monday. Sample data for
Task "A". 32h actual work, first hours on Monday of reporting week
already, so actual start one day early - great. Still there is no entry
in "re estimate work remaining" and the task isn't set to "complete" so
there is still 8h of work to be done - no trouble so far: MSP will
stick to the finish date of monday current week after entering work.
But wait: there is an entry in "re estimate finish": thursday current
week. So the guy working on task A tells me he can't finish those 8h
work today (sickness, availability of peer review, whatever...). "Now
if I would just "let the calculation engine do its job" I am exactly
NOT comparing real performance to plan - I'm losing valuable
information. After entering the new finish date for task A I'm happy
that MSP will calculate the duration effects in the network downstream
of task A for me. But it just doesn't make sense to stick to the
planning estimate when updating a single task: how would you enter that
a task is on budget but late otherwise? Overwrite the actual cost,
manually change the units? I just find entering actual work and then
updating remaining work or finish (i.e. planned finish, not baseline)
if necessary 1:1 with the values I get from my update sheets the most
straight forward. But I need to tell MSP to keep duration and work
separate to be successful here.

 

[Steve House]

Getting better, but the difference between duration and elapsed time is a
crucial concept here - the problem is that a later anticipated finish date
may or may not reflect an increase in duration. If the extended finish is
due to more work being required than was originally estimated, then it is
accompanied by an increase in duration. But if it caused by the resource
being sick, those sick days are non working time which aren't counted in the
duration - alapsed time between start and end gets longer but duration
remains the same. Likewise, if the task was, say, 5 days starting last Mon
and was supposed to finish last Friday and the resource worked Mon and Tue
but was then called away to handle some office emergency and didn't work on
it Wed Thu and Fri as he was supposed to, those dates also become
non-working time. The task should be rescheduled with a split (easy with
the Reschedule Uncompleted Work tool) shoing a gap then resuming on the
first day the resource can come back to it. There too, even though the
elapsed time will increase by 5 days, total elapsed time now 10 calendar
days from start to finish the duration will remain at 5 days with the 3 days
he was supposed to work on it but was unable to and the 2 days of the
weekend now in the middle of the task not counting towards the duration
numbers.

HTH

--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

I need to clarify a bit on
<<[Steve House:] I was fine until you said "after entering a new finish
date for Task A..." Well, you CAN'T directly enter a new finish date
for the task.>>

I agree with that - and I wasn't describing my process accurately. I do
receive new finish dates as data in the sheets for actual data, because
"I will be done on dd-mm-yyyy" just comes more natural than "I will
need x more work periods". But I have a little helper macro converting
the "new finish date" into a remaining duration value and entering that
for me. I'm so used to it, I keep forgetting it's not part of MS
Project. So maybe with that extra information, everything is fine? ;-)

Actually the scenario you describe does not at all require work and
duration
to be disconnected. A 40 man-hour task that has a daily work pattern of
8-8-8-split for 10 days-8-8 does not have a duration of 14 days, it has a
duration of 5 days. The time in the split doesn't count for duration -
it's
as if the task went on holiday and those days become non-working time
excluded from the duration just like a normal weekend etc.

I was fine until you said "after entering a new finish date for Task
A..."
Well, you CAN'T directly enter a new finish date for the task. Entering a
date in the scheduled Finish field does not set the finish date, it sets
a
Finish No Earlier Than constraint, a whole different critter. Instead,
you
can revise the duration (implying work is still continuous but there's
more
of it required) or you can split the task - splitting is a more accurate
model of reality IMHO. The better approach is to ask the resource what
date
he'll be able to resume work and either use that date with the
"reschedule
uncompleted work" tool or display the Resume field and enter it there.
That
will cause the task to split over the down time days and show the new end
date while keeping the original duration as it should. Remember,
duration
and elapsed time are two different measures only roughly related to each
other. In the case of an originally continuous task that actually
starts,
has some work, then stops, has some downtime, and then resumes later to
finish, the duration doesn't change but the elapsed time gets longer.
When
you're saying you want Project to keep work and duration separate, it
reveals you're equating duration with elapsed time which is something you
really can't do.

Here's another way to update that will do what you need I believe.
Create a
task X starting Monday, 5 days duration. Assign Leisure Suit Larry to
the
task 100%. Work is 40 hours. In the Resource Usage view, display the
Actual Work row. Enter 8 hours actual work on Mon, Tue, and Wed. Now he
books off sick. Enter 0 actual hours for Thur and Fri. Now you'll see
16
hours push out into the following week, setting a new finish date of the
end
of the day Tues. And of course this would push down any successor task's
starts. But the duration is still 5 days and the total work is still 40
hours.
--

Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Yes, yes, yes! ;-)... thanks for the passionate reply!

I think we do agree on :"You use the baseline and the current schedule
together to compare the plan as it was expected to unfold THEN to what
has actually happened until NOW so
you can accurately predict and control what is going to happen in the
FUTURE."

But I will not agree with: "To do that successfully you simply must let
the calculating engine
do its job."

Here's an example of what I get in a weekly update: task "A" planned
40h work, planned duration tuesday of last week (we call that the
"reporting week") until monday current week. Friday afternoon the
tracking data is collected and processed on monday. Sample data for
Task "A". 32h actual work, first hours on Monday of reporting week
already, so actual start one day early - great. Still there is no entry
in "re estimate work remaining" and the task isn't set to "complete" so
there is still 8h of work to be done - no trouble so far: MSP will
stick to the finish date of monday current week after entering work.
But wait: there is an entry in "re estimate finish": thursday current
week. So the guy working on task A tells me he can't finish those 8h
work today (sickness, availability of peer review, whatever...). "Now
if I would just "let the calculation engine do its job" I am exactly
NOT comparing real performance to plan - I'm losing valuable
information. After entering the new finish date for task A I'm happy
that MSP will calculate the duration effects in the network downstream
of task A for me. But it just doesn't make sense to stick to the
planning estimate when updating a single task: how would you enter that
a task is on budget but late otherwise? Overwrite the actual cost,
manually change the units? I just find entering actual work and then
updating remaining work or finish (i.e. planned finish, not baseline)
if necessary 1:1 with the values I get from my update sheets the most
straight forward. But I need to tell MSP to keep duration and work
separate to be successful here.

 

[Steve House]

Units are not the percentage of the resource's total work day that are
available for project work, they actually are the rate at which he converts
working time into useful output. If when he works at capacity he can make
10 widget an hour and we assign him to make 100 widgets, it will take him 10
hours to do it IF he works at capacity. Each 10 widgets represents 1
man-hour of work. But if he has other things on his plate that distract
him, he might only actually make 5 widgets per hour and the task will take
him 20 hours to make the 100 widgets - he's working at 50% units because
he's taking 2 hours to make what should take him 1 hour. Viewed another
way, for each hour of time he spends, he only get 1/2 man-hour of useful
work accomplished.

In your example 40 hour work @100% = 5 days duration starting Monday. As I
pointed out in my immmediate previous post, there's only 3 ways the finish
date can move from the original Friday finish to the following Thursday:

1: The total amount of work that is required for the job is more than first
estimated - actual>baseline - and the increased work @100% drives an
increased duration.

2: The resource did not actually do work during as many of the hours that
have passed as he was supposed to. Work is constant, units are constant,
duration is constant, elapsed time increases due to increased intervening
non-working time.

3: The effective rate at which the resource converts working time to output
is lower than 100%. Work remains constant, duration increases, effective
average units decreases but Project doesn't require you to enter them -
posting actual hours into the Resource Usage view on a day-by-day basis will
take care of it - ie, Joe was supposed work exclusively on this task for 8
hours on Monday but he only effectively got 4 done because of other things
on his plate - IOW, his effective rate is 50% for the day. He worked 8
hours but only accomplished what he should have been able to do in 4 -
Updating the actual work to 4 hours on Monday using the usage view will
cause the missing 4 hours to get tacked on to the end of the task,
increasing the duration while holding total work constant.

It almost seems as if you are trying to insure that the actual work reported
never exceeds the baseline work, even in cases where in physical reality it
has. This makes you look good to the boss in that you always meet your
productivity goals but it is, in fact, 'cooking the books' to prevent bad
news from ever seeing the light of day <grin>. IMHO, this is one result of
top-down budgeting - you're allowed 40 man-hours to make the widgets and you
can never report more than that no matter how much it really takes you -
and one of the best reasons I can think of to avoid that if you can.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Now that the laws of physics are brought into play: W=D*U is NOT the
world formula. It is the roughest possible (linear) approximation on
how one could model the way result production in a project will take
place. Even if we accept the fact that we have to work with this
simplistic formula you just supported my point: whichever way you look
at "W=D*U" it says you need TWO values to determine the third one. For
example a value for work and another for duration to calculate units.
Just because MS Project doesn't change unit assignments around doesn't
mean these are by law of nature constant between plan and actual.

Let me illustrate this by going back to the original example and using
the linear approximation:
plan: 40h Work = 5 days (@8h) * 100%;
actual: 40 h work = 9 days (Monday last week - Thursday next week) *
55,6%

So yes in a way the formula is "always true". But can you tell me how
to collect actuals on "unit" in the real world? What I can get is hours
worked on a task and calendar dates when the work started and when it
finished or estimates for those while we're still in the middle of that
task.

Maybe "making units flexible when entering actuals" is a better
description of what I'm trying to do than "separating work and
duration". Again back to the example: I get updates on work (32 hours
worked, 8h work to go) AND duration (started on monday last week and
going to finish this thursday) - I do NOT get an update "On average I'm
putting 55,6% of my availability to work on task A".

My point is: if I "just let the calculation engine do it's job" as
configured in default (task updates resource i.e. %work updates
%duration) I'm throwing away valuable information!
If I just entered %work complete as expected (8h work to go) Project
would tell me to expect the task to be finished on monday (current
week) and this is not correct - it will finish on Thursday.
If I just entered "remaining duration 4 more days (+ 5 actual)" then
Project would tell me the task is expected to cost almost double (54
hours work instead of 40h in line with baseline).

So maybe we can find common ground with this description:
In tracking a plan you need to collect actuals on two different
dimensions to reflect your actual vs. baseline development correctly.
Since collecting actuals on "unit" is rather impractical (at least for
StDilbert) that leaves you with asking for actuals on work (estimated
work remaining) and duration (estimated remaining duration) separately.
You have to tell MSP to not assume that by knowing one value it can
determine two others, just because there is no functionality in there
that will ever change the unit assignment...

You still can't separate work and duration and vary them independently
while
holding units constant. That holds as true for tracking as it does for
scheduling - perhaps even more so since tracking involves recording a
history of actual, real-world physical events that took place under
clearly
understood natural laws of physics, space, and time which can't be
altered
just to keep the accounting department happy <grin>. Joe working at 100%
produces 1 man-hour of work for each hour of time he puts in, no more and
no
less. It is physically impossible for one person to produce 2 man-hours
of
work for each single hour of time spent. OTOH, if he puts in an hour of
time and only gets half the job done he was supposed to, he wasn't
working
at full capacity - he's less than 100% by definition. The only other
option
is that you screwed up and over-estimated what his capacity would be
given
the conditions under which the work took place, you underestimated the
man-hours that would be required, in other words.

Your auto shop example isn't a violation of the work equation, it is a
change to the effective hourly rate that the work performed costs. Your
"earned man-hour method" is Project's earned value based on hours instead
of
currency units. It doesn't separate work and duration - just the
opposite,
it mandates the link be retained to be valid as it compares hours
actually
worked to a certain time against hours that should have been worked to
that
time.

Daily reports issued simply because you need to issue daily reports are
of
no value, IMHO. They should be issued only if the information they
contain
is accurate and contributes to a model that leads to a valid
understanding
of the behaviour of the project. Not to say you shouldn't do everything
you
can to get them out daily - just that accuracy needs to trump timeliness.
Don't repeat Worldcom's mistakes <g>.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


message

Steve, When you're working an outage (almost all of my schedules are
outage
related) that works 24 hours a day and you are there 12 hours per day
and
7
days a week you have to do what is necessary to get the job done so you
can
issue your daily reports. Keep in mind 95% of the poeple you deal with
are
"craft" people and don't have a clue what you're asking them and really
don't
want to update you. So to compensate for this I type the finish date
they
provide. There is no resume date when they are working24 hours a day.
As far as actuals: You do not get this during an outage with a 3,000
task
schedule , 150 boiler makers, 75 pipe fitters, 50 electricans, 35
instrument
techs, misc contractors...........
There is something called the "earned man-hour method" that is used to
track
what percent complete you are. For this to happen the task needs to
keep
the
same "work" (man-hours) as when you baselined. Any other task type adds
and
subtracts work. If you take your car to a dealer and he quotes you $100
you
expect to pay that amount. Later you go to pick it up and he says it's
$200
because Leisure Suit Larry took longer than most people, do you owe the
man
$200 - NO. If he says Leisure Suit Larry was really fast I'm only going
to
charge you $50. That will never happen either. He can only earn that
$100
reguardless of how his productivity was.
Earned man-hours over actual man-hours equals productivity.


:

Actually the scenario you describe does not at all require work and
duration
to be disconnected. A 40 man-hour task that has a daily work pattern
of
8-8-8-split for 10 days-8-8 does not have a duration of 14 days, it
has a
duration of 5 days. The time in the split doesn't count for
duration -
it's
as if the task went on holiday and those days become non-working time
excluded from the duration just like a normal weekend etc.

I was fine until you said "after entering a new finish date for Task
A..."
Well, you CAN'T directly enter a new finish date for the task.
Entering a
date in the scheduled Finish field does not set the finish date, it
sets
a
Finish No Earlier Than constraint, a whole different critter.
Instead,
you
can revise the duration (implying work is still continuous but there's
more
of it required) or you can split the task - splitting is a more
accurate
model of reality IMHO. The better approach is to ask the resource
what
date
he'll be able to resume work and either use that date with the
"reschedule
uncompleted work" tool or display the Resume field and enter it there.
That
will cause the task to split over the down time days and show the new
end
date while keeping the original duration as it should. Remember,
duration
and elapsed time are two different measures only roughly related to
each
other. In the case of an originally continuous task that actually
starts,
has some work, then stops, has some downtime, and then resumes later
to
finish, the duration doesn't change but the elapsed time gets longer.
When
you're saying you want Project to keep work and duration separate, it
reveals you're equating duration with elapsed time which is something
you
really can't do.

Here's another way to update that will do what you need I believe.
Create a
task X starting Monday, 5 days duration. Assign Leisure Suit Larry to
the
task 100%. Work is 40 hours. In the Resource Usage view, display the
Actual Work row. Enter 8 hours actual work on Mon, Tue, and Wed. Now
he
books off sick. Enter 0 actual hours for Thur and Fri. Now you'll
see
16
hours push out into the following week, setting a new finish date of
the
end
of the day Tues. And of course this would push down any successor
task's
starts. But the duration is still 5 days and the total work is still
40
hours.
--

Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


Yes, yes, yes! ;-)... thanks for the passionate reply!

I think we do agree on :"You use the baseline and the current
schedule
together to compare the plan as it was expected to unfold THEN to
what
has actually happened until NOW so
you can accurately predict and control what is going to happen in
the
FUTURE."

But I will not agree with: "To do that successfully you simply must
let
the calculating engine
do its job."

Here's an example of what I get in a weekly update: task "A" planned
40h work, planned duration tuesday of last week (we call that the
"reporting week") until monday current week. Friday afternoon the
tracking data is collected and processed on monday. Sample data for
Task "A". 32h actual work, first hours on Monday of reporting week
already, so actual start one day early - great. Still there is no
entry
in "re estimate work remaining" and the task isn't set to "complete"
so
there is still 8h of work to be done - no trouble so far: MSP will
stick to the finish date of monday current week after entering work.
But wait: there is an entry in "re estimate finish": thursday
current
week. So the guy working on task A tells me he can't finish those 8h
work today (sickness, availability of peer review, whatever...).
"Now
if I would just "let the calculation engine do its job" I am exactly
NOT comparing real performance to plan - I'm losing valuable
information. After entering the new finish date for task A I'm happy
that MSP will calculate the duration effects in the network
downstream
of task A for me. But it just doesn't make sense to stick to the
planning estimate when updating a single task: how would you enter
that
a task is on budget but late otherwise? Overwrite the actual cost,
manually change the units? I just find entering actual work and then
updating remaining work or finish (i.e. planned finish, not
baseline)
if necessary 1:1 with the values I get from my update sheets the
most
straight forward. But I need to tell MSP to keep duration and work
separate to be successful here.

 

[St Dilbert]

Of the three options only #3 (units changed in the sense, that
productivity isn't 100% as expected) would apply as explanation to my
one EXAMPLE. I'm not really happy with the next paragraph where you are
insinuating that my method is made up with the intent to polish
reporting for bosses and suppress reality coming from the team -
nothing could be further from the truth. You may very well assume that
I do know the basics of project management and this was just an example
for a situation where work DID remain constant and duration still
extended. Of course I could add tons of examples for more/less work and
more/less duration and all variations of it. But then the post would be
too long even for Google ;-).... I'm ready to pick up the challenge and
respond in kind (because I really do enjoy this lively exchange of
opinions - no hard feelings ;-)...!)

So since using an example was misleading I'll try to get my point
across with a fully abstract argument:
1. W=D*U [or D=W/U or U=W/D] is an equation where you need two values
to determine a third one - and there is no escaping that (basic math!)
2. It is a simplistic linear approximation - reality in a project's
result production is way more complex and decidedly non-linear (except
maybe for your favorite conveyor-belt-type-widget-polishing-example)
3. The reason to stick with linear is because it's definitely the only
practical approximation - if we went down into detailling plan and
update with precise work contours for every task over the days we would
suffocate in micromanaging
4. Corollary: the reason to stick with the linear approximation is NOT
because it is the best model of reality in a project
5. When you're planning you have to enter two values (any pair of the
triple work, duration, units) and project will calculate the third one
- I hope we do agree that you cannot create a sensible plan if you
would just provide only work or only duration or only units when
setting up tasks?!
6. Updating a plan then is no different: you need TWO values (like an
update on remaining work AND an update on remaining duration) - else
you are just updating one and ASSUMING another one didn't change to
calculate an update for the third value!
7. If you're satisfied with updating only duration and you want your
work updated you automatically assume, that units MUST have stayed the
same between plan and actual.
8. Keeping one value constant by assumption when you can have two
values updated and thinking this is the better way to update is only
true in a fairy-tale land where all tasks are highly linear
"widget-polishing" tasks performed by synchronized robots

I'm adamant that you can't disagree on steps 1, 5 and 6 of this
argument without living in a different universe - please confirm or
discuss these bits first - I'd really like to know.
The other points I would assume you could agree and we were just having
a misunderstanding rooted in usage of terms and the limits of the
Goggle gorup medium - or you really have a totally different
perspective, that I just can't appreciate thus far.

Units are not the percentage of the resource's total work day that are
available for project work, they actually are the rate at which he converts
working time into useful output. If when he works at capacity he can make
10 widget an hour and we assign him to make 100 widgets, it will take him 10
hours to do it IF he works at capacity. Each 10 widgets represents 1
man-hour of work. But if he has other things on his plate that distract
him, he might only actually make 5 widgets per hour and the task will take
him 20 hours to make the 100 widgets - he's working at 50% units because
he's taking 2 hours to make what should take him 1 hour. Viewed another
way, for each hour of time he spends, he only get 1/2 man-hour of useful
work accomplished.

In your example 40 hour work @100% = 5 days duration starting Monday. As I
pointed out in my immmediate previous post, there's only 3 ways the finish
date can move from the original Friday finish to the following Thursday:

1: The total amount of work that is required for the job is more than first
estimated - actual>baseline - and the increased work @100% drives an
increased duration.

2: The resource did not actually do work during as many of the hours that
have passed as he was supposed to. Work is constant, units are constant,
duration is constant, elapsed time increases due to increased intervening
non-working time.

3: The effective rate at which the resource converts working time to output
is lower than 100%. Work remains constant, duration increases, effective
average units decreases but Project doesn't require you to enter them -
posting actual hours into the Resource Usage view on a day-by-day basis will
take care of it - ie, Joe was supposed work exclusively on this task for 8
hours on Monday but he only effectively got 4 done because of other things
on his plate - IOW, his effective rate is 50% for the day. He worked 8
hours but only accomplished what he should have been able to do in 4 -
Updating the actual work to 4 hours on Monday using the usage view will
cause the missing 4 hours to get tacked on to the end of the task,
increasing the duration while holding total work constant.

It almost seems as if you are trying to insure that the actual work reported
never exceeds the baseline work, even in cases where in physical reality it
has. This makes you look good to the boss in that you always meet your
productivity goals but it is, in fact, 'cooking the books' to prevent bad
news from ever seeing the light of day <grin>. IMHO, this is one result of
top-down budgeting - you're allowed 40 man-hours to make the widgets and you
can never report more than that no matter how much it really takes you -
and one of the best reasons I can think of to avoid that if you can.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Now that the laws of physics are brought into play: W=D*U is NOT the
world formula. It is the roughest possible (linear) approximation on
how one could model the way result production in a project will take
place. Even if we accept the fact that we have to work with this
simplistic formula you just supported my point: whichever way you look
at "W=D*U" it says you need TWO values to determine the third one. For
example a value for work and another for duration to calculate units.
Just because MS Project doesn't change unit assignments around doesn't
mean these are by law of nature constant between plan and actual.

Let me illustrate this by going back to the original example and using
the linear approximation:
plan: 40h Work = 5 days (@8h) * 100%;
actual: 40 h work = 9 days (Monday last week - Thursday next week) *
55,6%

So yes in a way the formula is "always true". But can you tell me how
to collect actuals on "unit" in the real world? What I can get is hours
worked on a task and calendar dates when the work started and when it
finished or estimates for those while we're still in the middle of that
task.

Maybe "making units flexible when entering actuals" is a better
description of what I'm trying to do than "separating work and
duration". Again back to the example: I get updates on work (32 hours
worked, 8h work to go) AND duration (started on monday last week and
going to finish this thursday) - I do NOT get an update "On average I'm
putting 55,6% of my availability to work on task A".

My point is: if I "just let the calculation engine do it's job" as
configured in default (task updates resource i.e. %work updates
%duration) I'm throwing away valuable information!
If I just entered %work complete as expected (8h work to go) Project
would tell me to expect the task to be finished on monday (current
week) and this is not correct - it will finish on Thursday.
If I just entered "remaining duration 4 more days (+ 5 actual)" then
Project would tell me the task is expected to cost almost double (54
hours work instead of 40h in line with baseline).

So maybe we can find common ground with this description:
In tracking a plan you need to collect actuals on two different
dimensions to reflect your actual vs. baseline development correctly.
Since collecting actuals on "unit" is rather impractical (at least for
StDilbert) that leaves you with asking for actuals on work (estimated
work remaining) and duration (estimated remaining duration) separately.
You have to tell MSP to not assume that by knowing one value it can
determine two others, just because there is no functionality in there
that will ever change the unit assignment...

You still can't separate work and duration and vary them independently
while
holding units constant. That holds as true for tracking as it does for
scheduling - perhaps even more so since tracking involves recording a
history of actual, real-world physical events that took place under
clearly
understood natural laws of physics, space, and time which can't be
altered
just to keep the accounting department happy <grin>. Joe working at 100%
produces 1 man-hour of work for each hour of time he puts in, no more and
no
less. It is physically impossible for one person to produce 2 man-hours
of
work for each single hour of time spent. OTOH, if he puts in an hour of
time and only gets half the job done he was supposed to, he wasn't
working
at full capacity - he's less than 100% by definition. The only other
option
is that you screwed up and over-estimated what his capacity would be
given
the conditions under which the work took place, you underestimated the
man-hours that would be required, in other words.

Your auto shop example isn't a violation of the work equation, it is a
change to the effective hourly rate that the work performed costs. Your
"earned man-hour method" is Project's earned value based on hours instead
of
currency units. It doesn't separate work and duration - just the
opposite,
it mandates the link be retained to be valid as it compares hours
actually
worked to a certain time against hours that should have been worked to
that
time.

Daily reports issued simply because you need to issue daily reports are
of
no value, IMHO. They should be issued only if the information they
contain
is accurate and contributes to a model that leads to a valid
understanding
of the behaviour of the project. Not to say you shouldn't do everything
you
can to get them out daily - just that accuracy needs to trump timeliness.
Don't repeat Worldcom's mistakes <g>.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


message
Steve, When you're working an outage (almost all of my schedules are
outage
related) that works 24 hours a day and you are there 12 hours per day
and
7
days a week you have to do what is necessary to get the job done so you
can
issue your daily reports. Keep in mind 95% of the poeple you deal with
are
"craft" people and don't have a clue what you're asking them and really
don't
want to update you. So to compensate for this I type the finish date
they
provide. There is no resume date when they are working24 hours a day.
As far as actuals: You do not get this during an outage with a 3,000
task
schedule , 150 boiler makers, 75 pipe fitters, 50 electricans, 35
instrument
techs, misc contractors...........
There is something called the "earned man-hour method" that is used to
track
what percent complete you are. For this to happen the task needs to
keep
the
same "work" (man-hours) as when you baselined. Any other task type adds
and
subtracts work. If you take your car to a dealer and he quotes you $100
you
expect to pay that amount. Later you go to pick it up and he says it's
$200
because Leisure Suit Larry took longer than most people, do you owe the
man
$200 - NO. If he says Leisure Suit Larry was really fast I'm only going
to
charge you $50. That will never happen either. He can only earn that
$100
reguardless of how his productivity was.
Earned man-hours over actual man-hours equals productivity.


:

Actually the scenario you describe does not at all require work and
duration
to be disconnected. A 40 man-hour task that has a daily work pattern
of
8-8-8-split for 10 days-8-8 does not have a duration of 14 days, it
has a
duration of 5 days. The time in the split doesn't count for
duration -
it's
as if the task went on holiday and those days become non-working time
excluded from the duration just like a normal weekend etc.

I was fine until you said "after entering a new finish date for Task
A..."
Well, you CAN'T directly enter a new finish date for the task.
Entering a
date in the scheduled Finish field does not set the finish date, it
sets
a
Finish No Earlier Than constraint, a whole different critter.
Instead,
you
can revise the duration (implying work is still continuous but there's
more
of it required) or you can split the task - splitting is a more
accurate
model of reality IMHO. The better approach is to ask the resource
what
date
he'll be able to resume work and either use that date with the
"reschedule
uncompleted work" tool or display the Resume field and enter it there.
That
will cause the task to split over the down time days and show the new
end
date while keeping the original duration as it should. Remember,
duration
and elapsed time are two different measures only roughly related to
each
other. In the case of an originally continuous task that actually
starts,
has some work, then stops, has some downtime, and then resumes later
to
finish, the duration doesn't change but the elapsed time gets longer.
When
you're saying you want Project to keep work and duration separate, it
reveals you're equating duration with elapsed time which is something
you
really can't do.

Here's another way to update that will do what you need I believe.
Create a
task X starting Monday, 5 days duration. Assign Leisure Suit Larry to
the
task 100%. Work is 40 hours. In the Resource Usage view, display the
Actual Work row. Enter 8 hours actual work on Mon, Tue, and Wed. Now
he
books off sick. Enter 0 actual hours for Thur and Fri. Now you'll
see
16
hours push out into the following week, setting a new finish date of
the
end
of the day Tues. And of course this would push down any successor
task's
starts. But the duration is still 5 days and the total work is still
40
hours.
--

Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


Yes, yes, yes! ;-)... thanks for the passionate reply!

I think we do agree on :"You use the baseline and the current
schedule
together to compare the plan as it was expected to unfold THEN to
what
has actually happened until NOW so
you can accurately predict and control what is going to happen in
the
FUTURE."

But I will not agree with: "To do that successfully you simply must
let
the calculating engine
do its job."

Here's an example of what I get in a weekly update: task "A" planned
40h work, planned duration tuesday of last week (we call that the
"reporting week") until monday current week. Friday afternoon the
tracking data is collected and processed on monday. Sample data for
Task "A". 32h actual work, first hours on Monday of reporting week
already, so actual start one day early - great. Still there is no
entry
in "re estimate work remaining" and the task isn't set to "complete"
so
there is still 8h of work to be done - no trouble so far: MSP will
stick to the finish date of monday current week after entering work.
But wait: there is an entry in "re estimate finish": thursday
current
week. So the guy working on task A tells me he can't finish those 8h
work today (sickness, availability of peer review, whatever...).
"Now
if I would just "let the calculation engine do its job" I am exactly
NOT comparing real performance to plan - I'm losing valuable
information. After entering the new finish date for task A I'm happy
that MSP will calculate the duration effects in the network
downstream
of task A for me. But it just doesn't make sense to stick to the
planning estimate when updating a single task: how would you enter
that
a task is on budget but late otherwise? Overwrite the actual cost,
manually change the units? I just find entering actual work and then
updating remaining work or finish (i.e. planned finish, not
baseline)
if necessary 1:1 with the values I get from my update sheets the
most
straight forward. But I need to tell MSP to keep duration and work
separate to be successful here.

 

[St Dilbert]

And exactly because there is this difference between duration and
elapsed time we ask for the new finish date and let Project do the math
to turn that into the number of work periods remaining which the macro
then enters as remaining duration.
Add to that the separate update on whether remaining work runs in line
with original estimate or has changed and Project will calculate what
units we now expect on that task.

If I were interested in more "inner detail" on that single task I would
indeed have to bother with split, resume, custom work contour -
whatever. That way lies micromanagement and I will have none of that.

The usual granularity is tasks worth between 1 and 10 days work. In an
average project I will have a few hundred tasks over a few months. With
a weekly status cycle there is no added value in going into this split
resume detail: 50% of tasks closed in the same reporting period as
started and more than 90% closed after two periods.

Getting better, but the difference between duration and elapsed time is a
crucial concept here - the problem is that a later anticipated finish date
may or may not reflect an increase in duration. If the extended finish is
due to more work being required than was originally estimated, then it is
accompanied by an increase in duration. But if it caused by the resource
being sick, those sick days are non working time which aren't counted in the
duration - alapsed time between start and end gets longer but duration
remains the same. Likewise, if the task was, say, 5 days starting last Mon
and was supposed to finish last Friday and the resource worked Mon and Tue
but was then called away to handle some office emergency and didn't work on
it Wed Thu and Fri as he was supposed to, those dates also become
non-working time. The task should be rescheduled with a split (easy with
the Reschedule Uncompleted Work tool) shoing a gap then resuming on the
first day the resource can come back to it. There too, even though the
elapsed time will increase by 5 days, total elapsed time now 10 calendar
days from start to finish the duration will remain at 5 days with the 3 days
he was supposed to work on it but was unable to and the 2 days of the
weekend now in the middle of the task not counting towards the duration
numbers.

HTH

--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

I need to clarify a bit on
<<[Steve House:] I was fine until you said "after entering a new finish
date for Task A..." Well, you CAN'T directly enter a new finish date
for the task.>>

I agree with that - and I wasn't describing my process accurately. I do
receive new finish dates as data in the sheets for actual data, because
"I will be done on dd-mm-yyyy" just comes more natural than "I will
need x more work periods". But I have a little helper macro converting
the "new finish date" into a remaining duration value and entering that
for me. I'm so used to it, I keep forgetting it's not part of MS
Project. So maybe with that extra information, everything is fine? ;-)

Actually the scenario you describe does not at all require work and
duration
to be disconnected. A 40 man-hour task that has a daily work pattern of
8-8-8-split for 10 days-8-8 does not have a duration of 14 days, it has a
duration of 5 days. The time in the split doesn't count for duration -
it's
as if the task went on holiday and those days become non-working time
excluded from the duration just like a normal weekend etc.

I was fine until you said "after entering a new finish date for Task
A..."
Well, you CAN'T directly enter a new finish date for the task. Entering a
date in the scheduled Finish field does not set the finish date, it sets
a
Finish No Earlier Than constraint, a whole different critter. Instead,
you
can revise the duration (implying work is still continuous but there's
more
of it required) or you can split the task - splitting is a more accurate
model of reality IMHO. The better approach is to ask the resource what
date
he'll be able to resume work and either use that date with the
"reschedule
uncompleted work" tool or display the Resume field and enter it there.
That
will cause the task to split over the down time days and show the new end
date while keeping the original duration as it should. Remember,
duration
and elapsed time are two different measures only roughly related to each
other. In the case of an originally continuous task that actually
starts,
has some work, then stops, has some downtime, and then resumes later to
finish, the duration doesn't change but the elapsed time gets longer.
When
you're saying you want Project to keep work and duration separate, it
reveals you're equating duration with elapsed time which is something you
really can't do.

Here's another way to update that will do what you need I believe.
Create a
task X starting Monday, 5 days duration. Assign Leisure Suit Larry to
the
task 100%. Work is 40 hours. In the Resource Usage view, display the
Actual Work row. Enter 8 hours actual work on Mon, Tue, and Wed. Now he
books off sick. Enter 0 actual hours for Thur and Fri. Now you'll see
16
hours push out into the following week, setting a new finish date of the
end
of the day Tues. And of course this would push down any successor task's
starts. But the duration is still 5 days and the total work is still 40
hours.
--

Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


Yes, yes, yes! ;-)... thanks for the passionate reply!

I think we do agree on :"You use the baseline and the current schedule
together to compare the plan as it was expected to unfold THEN to what
has actually happened until NOW so
you can accurately predict and control what is going to happen in the
FUTURE."

But I will not agree with: "To do that successfully you simply must let
the calculating engine
do its job."

Here's an example of what I get in a weekly update: task "A" planned
40h work, planned duration tuesday of last week (we call that the
"reporting week") until monday current week. Friday afternoon the
tracking data is collected and processed on monday. Sample data for
Task "A". 32h actual work, first hours on Monday of reporting week
already, so actual start one day early - great. Still there is no entry
in "re estimate work remaining" and the task isn't set to "complete" so
there is still 8h of work to be done - no trouble so far: MSP will
stick to the finish date of monday current week after entering work.
But wait: there is an entry in "re estimate finish": thursday current
week. So the guy working on task A tells me he can't finish those 8h
work today (sickness, availability of peer review, whatever...). "Now
if I would just "let the calculation engine do its job" I am exactly
NOT comparing real performance to plan - I'm losing valuable
information. After entering the new finish date for task A I'm happy
that MSP will calculate the duration effects in the network downstream
of task A for me. But it just doesn't make sense to stick to the
planning estimate when updating a single task: how would you enter that
a task is on budget but late otherwise? Overwrite the actual cost,
manually change the units? I just find entering actual work and then
updating remaining work or finish (i.e. planned finish, not baseline)
if necessary 1:1 with the values I get from my update sheets the most
straight forward. But I need to tell MSP to keep duration and work
separate to be successful here.

 

[Steve House]

Actually I agree with all 8 of your points. We can assume linearity because
the goal is to deliver the project finish on time and within budget and we
really don't need to micromanage the resources from day to day to do that.
At most all we need to do is look at averages over the duration of each
task, even at the finest level of required granularity.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Of the three options only #3 (units changed in the sense, that
productivity isn't 100% as expected) would apply as explanation to my
one EXAMPLE. I'm not really happy with the next paragraph where you are
insinuating that my method is made up with the intent to polish
reporting for bosses and suppress reality coming from the team -
nothing could be further from the truth. You may very well assume that
I do know the basics of project management and this was just an example
for a situation where work DID remain constant and duration still
extended. Of course I could add tons of examples for more/less work and
more/less duration and all variations of it. But then the post would be
too long even for Google ;-).... I'm ready to pick up the challenge and
respond in kind (because I really do enjoy this lively exchange of
opinions - no hard feelings ;-)...!)

So since using an example was misleading I'll try to get my point
across with a fully abstract argument:
1. W=D*U [or D=W/U or U=W/D] is an equation where you need two values
to determine a third one - and there is no escaping that (basic math!)
2. It is a simplistic linear approximation - reality in a project's
result production is way more complex and decidedly non-linear (except
maybe for your favorite conveyor-belt-type-widget-polishing-example)
3. The reason to stick with linear is because it's definitely the only
practical approximation - if we went down into detailling plan and
update with precise work contours for every task over the days we would
suffocate in micromanaging
4. Corollary: the reason to stick with the linear approximation is NOT
because it is the best model of reality in a project
5. When you're planning you have to enter two values (any pair of the
triple work, duration, units) and project will calculate the third one
- I hope we do agree that you cannot create a sensible plan if you
would just provide only work or only duration or only units when
setting up tasks?!
6. Updating a plan then is no different: you need TWO values (like an
update on remaining work AND an update on remaining duration) - else
you are just updating one and ASSUMING another one didn't change to
calculate an update for the third value!
7. If you're satisfied with updating only duration and you want your
work updated you automatically assume, that units MUST have stayed the
same between plan and actual.
8. Keeping one value constant by assumption when you can have two
values updated and thinking this is the better way to update is only
true in a fairy-tale land where all tasks are highly linear
"widget-polishing" tasks performed by synchronized robots

I'm adamant that you can't disagree on steps 1, 5 and 6 of this
argument without living in a different universe - please confirm or
discuss these bits first - I'd really like to know.
The other points I would assume you could agree and we were just having
a misunderstanding rooted in usage of terms and the limits of the
Goggle gorup medium - or you really have a totally different
perspective, that I just can't appreciate thus far.

Units are not the percentage of the resource's total work day that are
available for project work, they actually are the rate at which he
converts
working time into useful output. If when he works at capacity he can
make
10 widget an hour and we assign him to make 100 widgets, it will take him
10
hours to do it IF he works at capacity. Each 10 widgets represents 1
man-hour of work. But if he has other things on his plate that distract
him, he might only actually make 5 widgets per hour and the task will
take
him 20 hours to make the 100 widgets - he's working at 50% units because
he's taking 2 hours to make what should take him 1 hour. Viewed another
way, for each hour of time he spends, he only get 1/2 man-hour of useful
work accomplished.

In your example 40 hour work @100% = 5 days duration starting Monday. As
I
pointed out in my immmediate previous post, there's only 3 ways the
finish
date can move from the original Friday finish to the following Thursday:

1: The total amount of work that is required for the job is more than
first
estimated - actual>baseline - and the increased work @100% drives an
increased duration.

2: The resource did not actually do work during as many of the hours
that
have passed as he was supposed to. Work is constant, units are constant,
duration is constant, elapsed time increases due to increased intervening
non-working time.

3: The effective rate at which the resource converts working time to
output
is lower than 100%. Work remains constant, duration increases, effective
average units decreases but Project doesn't require you to enter them -
posting actual hours into the Resource Usage view on a day-by-day basis
will
take care of it - ie, Joe was supposed work exclusively on this task for
8
hours on Monday but he only effectively got 4 done because of other
things
on his plate - IOW, his effective rate is 50% for the day. He worked 8
hours but only accomplished what he should have been able to do in 4 -
Updating the actual work to 4 hours on Monday using the usage view will
cause the missing 4 hours to get tacked on to the end of the task,
increasing the duration while holding total work constant.

It almost seems as if you are trying to insure that the actual work
reported
never exceeds the baseline work, even in cases where in physical reality
it
has. This makes you look good to the boss in that you always meet your
productivity goals but it is, in fact, 'cooking the books' to prevent bad
news from ever seeing the light of day <grin>. IMHO, this is one result
of
top-down budgeting - you're allowed 40 man-hours to make the widgets and
you
can never report more than that no matter how much it really takes you -
and one of the best reasons I can think of to avoid that if you can.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Now that the laws of physics are brought into play: W=D*U is NOT the
world formula. It is the roughest possible (linear) approximation on
how one could model the way result production in a project will take
place. Even if we accept the fact that we have to work with this
simplistic formula you just supported my point: whichever way you look
at "W=D*U" it says you need TWO values to determine the third one. For
example a value for work and another for duration to calculate units.
Just because MS Project doesn't change unit assignments around doesn't
mean these are by law of nature constant between plan and actual.

Let me illustrate this by going back to the original example and using
the linear approximation:
plan: 40h Work = 5 days (@8h) * 100%;
actual: 40 h work = 9 days (Monday last week - Thursday next week) *
55,6%

So yes in a way the formula is "always true". But can you tell me how
to collect actuals on "unit" in the real world? What I can get is hours
worked on a task and calendar dates when the work started and when it
finished or estimates for those while we're still in the middle of that
task.

Maybe "making units flexible when entering actuals" is a better
description of what I'm trying to do than "separating work and
duration". Again back to the example: I get updates on work (32 hours
worked, 8h work to go) AND duration (started on monday last week and
going to finish this thursday) - I do NOT get an update "On average I'm
putting 55,6% of my availability to work on task A".

My point is: if I "just let the calculation engine do it's job" as
configured in default (task updates resource i.e. %work updates
%duration) I'm throwing away valuable information!
If I just entered %work complete as expected (8h work to go) Project
would tell me to expect the task to be finished on monday (current
week) and this is not correct - it will finish on Thursday.
If I just entered "remaining duration 4 more days (+ 5 actual)" then
Project would tell me the task is expected to cost almost double (54
hours work instead of 40h in line with baseline).

So maybe we can find common ground with this description:
In tracking a plan you need to collect actuals on two different
dimensions to reflect your actual vs. baseline development correctly.
Since collecting actuals on "unit" is rather impractical (at least for
StDilbert) that leaves you with asking for actuals on work (estimated
work remaining) and duration (estimated remaining duration) separately.
You have to tell MSP to not assume that by knowing one value it can
determine two others, just because there is no functionality in there
that will ever change the unit assignment...


Steve House schrieb:

You still can't separate work and duration and vary them independently
while
holding units constant. That holds as true for tracking as it does
for
scheduling - perhaps even more so since tracking involves recording a
history of actual, real-world physical events that took place under
clearly
understood natural laws of physics, space, and time which can't be
altered
just to keep the accounting department happy <grin>. Joe working at
100%
produces 1 man-hour of work for each hour of time he puts in, no more
and
no
less. It is physically impossible for one person to produce 2
man-hours
of
work for each single hour of time spent. OTOH, if he puts in an hour
of
time and only gets half the job done he was supposed to, he wasn't
working
at full capacity - he's less than 100% by definition. The only other
option
is that you screwed up and over-estimated what his capacity would be
given
the conditions under which the work took place, you underestimated the
man-hours that would be required, in other words.

Your auto shop example isn't a violation of the work equation, it is a
change to the effective hourly rate that the work performed costs.
Your
"earned man-hour method" is Project's earned value based on hours
instead
of
currency units. It doesn't separate work and duration - just the
opposite,
it mandates the link be retained to be valid as it compares hours
actually
worked to a certain time against hours that should have been worked to
that
time.

Daily reports issued simply because you need to issue daily reports
are
of
no value, IMHO. They should be issued only if the information they
contain
is accurate and contributes to a model that leads to a valid
understanding
of the behaviour of the project. Not to say you shouldn't do
everything
you
can to get them out daily - just that accuracy needs to trump
timeliness.
Don't repeat Worldcom's mistakes <g>.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


message
Steve, When you're working an outage (almost all of my schedules are
outage
related) that works 24 hours a day and you are there 12 hours per
day
and
7
days a week you have to do what is necessary to get the job done so
you
can
issue your daily reports. Keep in mind 95% of the poeple you deal
with
are
"craft" people and don't have a clue what you're asking them and
really
don't
want to update you. So to compensate for this I type the finish date
they
provide. There is no resume date when they are working24 hours a
day.
As far as actuals: You do not get this during an outage with a 3,000
task
schedule , 150 boiler makers, 75 pipe fitters, 50 electricans, 35
instrument
techs, misc contractors...........
There is something called the "earned man-hour method" that is used
to
track
what percent complete you are. For this to happen the task needs to
keep
the
same "work" (man-hours) as when you baselined. Any other task type
adds
and
subtracts work. If you take your car to a dealer and he quotes you
$100
you
expect to pay that amount. Later you go to pick it up and he says
it's
$200
because Leisure Suit Larry took longer than most people, do you owe
the
man
$200 - NO. If he says Leisure Suit Larry was really fast I'm only
going
to
charge you $50. That will never happen either. He can only earn that
$100
reguardless of how his productivity was.
Earned man-hours over actual man-hours equals productivity.


:

Actually the scenario you describe does not at all require work and
duration
to be disconnected. A 40 man-hour task that has a daily work
pattern
of
8-8-8-split for 10 days-8-8 does not have a duration of 14 days, it
has a
duration of 5 days. The time in the split doesn't count for
duration -
it's
as if the task went on holiday and those days become non-working
time
excluded from the duration just like a normal weekend etc.

I was fine until you said "after entering a new finish date for
Task
A..."
Well, you CAN'T directly enter a new finish date for the task.
Entering a
date in the scheduled Finish field does not set the finish date, it
sets
a
Finish No Earlier Than constraint, a whole different critter.
Instead,
you
can revise the duration (implying work is still continuous but
there's
more
of it required) or you can split the task - splitting is a more
accurate
model of reality IMHO. The better approach is to ask the resource
what
date
he'll be able to resume work and either use that date with the
"reschedule
uncompleted work" tool or display the Resume field and enter it
there.
That
will cause the task to split over the down time days and show the
new
end
date while keeping the original duration as it should. Remember,
duration
and elapsed time are two different measures only roughly related to
each
other. In the case of an originally continuous task that actually
starts,
has some work, then stops, has some downtime, and then resumes
later
to
finish, the duration doesn't change but the elapsed time gets
longer.
When
you're saying you want Project to keep work and duration separate,
it
reveals you're equating duration with elapsed time which is
something
you
really can't do.

Here's another way to update that will do what you need I believe.
Create a
task X starting Monday, 5 days duration. Assign Leisure Suit Larry
to
the
task 100%. Work is 40 hours. In the Resource Usage view, display
the
Actual Work row. Enter 8 hours actual work on Mon, Tue, and Wed.
Now
he
books off sick. Enter 0 actual hours for Thur and Fri. Now you'll
see
16
hours push out into the following week, setting a new finish date
of
the
end
of the day Tues. And of course this would push down any successor
task's
starts. But the duration is still 5 days and the total work is
still
40
hours.
--

Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


Yes, yes, yes! ;-)... thanks for the passionate reply!

I think we do agree on :"You use the baseline and the current
schedule
together to compare the plan as it was expected to unfold THEN to
what
has actually happened until NOW so
you can accurately predict and control what is going to happen in
the
FUTURE."

But I will not agree with: "To do that successfully you simply
must
let
the calculating engine
do its job."

Here's an example of what I get in a weekly update: task "A"
planned
40h work, planned duration tuesday of last week (we call that the
"reporting week") until monday current week. Friday afternoon the
tracking data is collected and processed on monday. Sample data
for
Task "A". 32h actual work, first hours on Monday of reporting
week
already, so actual start one day early - great. Still there is no
entry
in "re estimate work remaining" and the task isn't set to
"complete"
so
there is still 8h of work to be done - no trouble so far: MSP
will
stick to the finish date of monday current week after entering
work.
But wait: there is an entry in "re estimate finish": thursday
current
week. So the guy working on task A tells me he can't finish those
8h
work today (sickness, availability of peer review, whatever...).
"Now
if I would just "let the calculation engine do its job" I am
exactly
NOT comparing real performance to plan - I'm losing valuable
information. After entering the new finish date for task A I'm
happy
that MSP will calculate the duration effects in the network
downstream
of task A for me. But it just doesn't make sense to stick to the
planning estimate when updating a single task: how would you
enter
that
a task is on budget but late otherwise? Overwrite the actual
cost,
manually change the units? I just find entering actual work and
then
updating remaining work or finish (i.e. planned finish, not
baseline)
if necessary 1:1 with the values I get from my update sheets the
most
straight forward. But I need to tell MSP to keep duration and
work
separate to be successful here.

 

[Steve House]

And exactly because there is this difference between duration and
elapsed time we ask for the new finish date and let Project do the math
to turn that into the number of work periods remaining which the macro
then enters as remaining duration.
Add to that the separate update on whether remaining work runs in line
with original estimate or has changed and Project will calculate what
units we now expect on that task.

If I were interested in more "inner detail" on that single task I would
indeed have to bother with split, resume, custom work contour -
whatever. That way lies micromanagement and I will have none of that.

The usual granularity is tasks worth between 1 and 10 days work. In an
average project I will have a few hundred tasks over a few months. With
a weekly status cycle there is no added value in going into this split
resume detail: 50% of tasks closed in the same reporting period as
started and more than 90% closed after two periods.

Yep, you'll find I've made references to "The 8/80 Rule" many times, meaning
many tasks less than 8 hours is probably indicative you're micromanaging and
over 80 hours indicates you're not breaking down the work into fine enough
detail to effectively manage it.

 

[Steve House]

I do think we probably are on the same track and just had a confusion either
in terms or in assumed workflow. Why I'm so adamant about not separating
work and duration under any circumstance is that the desire often crops up
in a scenario that goes something like this ...

"I have a task that has a duration of 5 days with a resource assigned to it
100% for total work of 40 man-hours that has been base-lined and budgeted
for those figures. When we did the task the resource found it took him 10
days, not 5, to complete it even though he worked full-time on it. Because
we're only budgeted for 40 hours we can't show the work is any more than
that even if if it really took more yet we need to show the duration is 10
days so the rest of the project is scheduled correctly. We also need to
show the resource was working 100% and can't adjust that either. So when I
enter actuals, how do I get Project to let me show a resource with an 8
hour-a-day calendar who worked at 100%, 8 hours a day on just that task,
took 10 days, 80 working hours, to do a 40 man-hour task?" That is
obviously fudging the books and Project won't and shouldn't allow it.

Entering work and duration independently of each other and letting Project
adjust the resource units to keep the equation in balance is another thing
all together and I don't consider that "separating work and duration."
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Of the three options only #3 (units changed in the sense, that
productivity isn't 100% as expected) would apply as explanation to my
one EXAMPLE. I'm not really happy with the next paragraph where you are
insinuating that my method is made up with the intent to polish
reporting for bosses and suppress reality coming from the team -
nothing could be further from the truth. You may very well assume that
I do know the basics of project management and this was just an example
for a situation where work DID remain constant and duration still
extended. Of course I could add tons of examples for more/less work and
more/less duration and all variations of it. But then the post would be
too long even for Google ;-).... I'm ready to pick up the challenge and
respond in kind (because I really do enjoy this lively exchange of
opinions - no hard feelings ;-)...!)

So since using an example was misleading I'll try to get my point
across with a fully abstract argument:
1. W=D*U [or D=W/U or U=W/D] is an equation where you need two values
to determine a third one - and there is no escaping that (basic math!)
2. It is a simplistic linear approximation - reality in a project's
result production is way more complex and decidedly non-linear (except
maybe for your favorite conveyor-belt-type-widget-polishing-example)
3. The reason to stick with linear is because it's definitely the only
practical approximation - if we went down into detailling plan and
update with precise work contours for every task over the days we would
suffocate in micromanaging
4. Corollary: the reason to stick with the linear approximation is NOT
because it is the best model of reality in a project
5. When you're planning you have to enter two values (any pair of the
triple work, duration, units) and project will calculate the third one
- I hope we do agree that you cannot create a sensible plan if you
would just provide only work or only duration or only units when
setting up tasks?!
6. Updating a plan then is no different: you need TWO values (like an
update on remaining work AND an update on remaining duration) - else
you are just updating one and ASSUMING another one didn't change to
calculate an update for the third value!
7. If you're satisfied with updating only duration and you want your
work updated you automatically assume, that units MUST have stayed the
same between plan and actual.
8. Keeping one value constant by assumption when you can have two
values updated and thinking this is the better way to update is only
true in a fairy-tale land where all tasks are highly linear
"widget-polishing" tasks performed by synchronized robots

I'm adamant that you can't disagree on steps 1, 5 and 6 of this
argument without living in a different universe - please confirm or
discuss these bits first - I'd really like to know.
The other points I would assume you could agree and we were just having
a misunderstanding rooted in usage of terms and the limits of the
Goggle gorup medium - or you really have a totally different
perspective, that I just can't appreciate thus far.

Units are not the percentage of the resource's total work day that are
available for project work, they actually are the rate at which he
converts
working time into useful output. If when he works at capacity he can
make
10 widget an hour and we assign him to make 100 widgets, it will take him
10
hours to do it IF he works at capacity. Each 10 widgets represents 1
man-hour of work. But if he has other things on his plate that distract
him, he might only actually make 5 widgets per hour and the task will
take
him 20 hours to make the 100 widgets - he's working at 50% units because
he's taking 2 hours to make what should take him 1 hour. Viewed another
way, for each hour of time he spends, he only get 1/2 man-hour of useful
work accomplished.

In your example 40 hour work @100% = 5 days duration starting Monday. As
I
pointed out in my immmediate previous post, there's only 3 ways the
finish
date can move from the original Friday finish to the following Thursday:

1: The total amount of work that is required for the job is more than
first
estimated - actual>baseline - and the increased work @100% drives an
increased duration.

2: The resource did not actually do work during as many of the hours
that
have passed as he was supposed to. Work is constant, units are constant,
duration is constant, elapsed time increases due to increased intervening
non-working time.

3: The effective rate at which the resource converts working time to
output
is lower than 100%. Work remains constant, duration increases, effective
average units decreases but Project doesn't require you to enter them -
posting actual hours into the Resource Usage view on a day-by-day basis
will
take care of it - ie, Joe was supposed work exclusively on this task for
8
hours on Monday but he only effectively got 4 done because of other
things
on his plate - IOW, his effective rate is 50% for the day. He worked 8
hours but only accomplished what he should have been able to do in 4 -
Updating the actual work to 4 hours on Monday using the usage view will
cause the missing 4 hours to get tacked on to the end of the task,
increasing the duration while holding total work constant.

It almost seems as if you are trying to insure that the actual work
reported
never exceeds the baseline work, even in cases where in physical reality
it
has. This makes you look good to the boss in that you always meet your
productivity goals but it is, in fact, 'cooking the books' to prevent bad
news from ever seeing the light of day <grin>. IMHO, this is one result
of
top-down budgeting - you're allowed 40 man-hours to make the widgets and
you
can never report more than that no matter how much it really takes you -
and one of the best reasons I can think of to avoid that if you can.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Now that the laws of physics are brought into play: W=D*U is NOT the
world formula. It is the roughest possible (linear) approximation on
how one could model the way result production in a project will take
place. Even if we accept the fact that we have to work with this
simplistic formula you just supported my point: whichever way you look
at "W=D*U" it says you need TWO values to determine the third one. For
example a value for work and another for duration to calculate units.
Just because MS Project doesn't change unit assignments around doesn't
mean these are by law of nature constant between plan and actual.

Let me illustrate this by going back to the original example and using
the linear approximation:
plan: 40h Work = 5 days (@8h) * 100%;
actual: 40 h work = 9 days (Monday last week - Thursday next week) *
55,6%

So yes in a way the formula is "always true". But can you tell me how
to collect actuals on "unit" in the real world? What I can get is hours
worked on a task and calendar dates when the work started and when it
finished or estimates for those while we're still in the middle of that
task.

Maybe "making units flexible when entering actuals" is a better
description of what I'm trying to do than "separating work and
duration". Again back to the example: I get updates on work (32 hours
worked, 8h work to go) AND duration (started on monday last week and
going to finish this thursday) - I do NOT get an update "On average I'm
putting 55,6% of my availability to work on task A".

My point is: if I "just let the calculation engine do it's job" as
configured in default (task updates resource i.e. %work updates
%duration) I'm throwing away valuable information!
If I just entered %work complete as expected (8h work to go) Project
would tell me to expect the task to be finished on monday (current
week) and this is not correct - it will finish on Thursday.
If I just entered "remaining duration 4 more days (+ 5 actual)" then
Project would tell me the task is expected to cost almost double (54
hours work instead of 40h in line with baseline).

So maybe we can find common ground with this description:
In tracking a plan you need to collect actuals on two different
dimensions to reflect your actual vs. baseline development correctly.
Since collecting actuals on "unit" is rather impractical (at least for
StDilbert) that leaves you with asking for actuals on work (estimated
work remaining) and duration (estimated remaining duration) separately.
You have to tell MSP to not assume that by knowing one value it can
determine two others, just because there is no functionality in there
that will ever change the unit assignment...


Steve House schrieb:

You still can't separate work and duration and vary them independently
while
holding units constant. That holds as true for tracking as it does
for
scheduling - perhaps even more so since tracking involves recording a
history of actual, real-world physical events that took place under
clearly
understood natural laws of physics, space, and time which can't be
altered
just to keep the accounting department happy <grin>. Joe working at
100%
produces 1 man-hour of work for each hour of time he puts in, no more
and
no
less. It is physically impossible for one person to produce 2
man-hours
of
work for each single hour of time spent. OTOH, if he puts in an hour
of
time and only gets half the job done he was supposed to, he wasn't
working
at full capacity - he's less than 100% by definition. The only other
option
is that you screwed up and over-estimated what his capacity would be
given
the conditions under which the work took place, you underestimated the
man-hours that would be required, in other words.

Your auto shop example isn't a violation of the work equation, it is a
change to the effective hourly rate that the work performed costs.
Your
"earned man-hour method" is Project's earned value based on hours
instead
of
currency units. It doesn't separate work and duration - just the
opposite,
it mandates the link be retained to be valid as it compares hours
actually
worked to a certain time against hours that should have been worked to
that
time.

Daily reports issued simply because you need to issue daily reports
are
of
no value, IMHO. They should be issued only if the information they
contain
is accurate and contributes to a model that leads to a valid
understanding
of the behaviour of the project. Not to say you shouldn't do
everything
you
can to get them out daily - just that accuracy needs to trump
timeliness.
Don't repeat Worldcom's mistakes <g>.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


message
Steve, When you're working an outage (almost all of my schedules are
outage
related) that works 24 hours a day and you are there 12 hours per
day
and
7
days a week you have to do what is necessary to get the job done so
you
can
issue your daily reports. Keep in mind 95% of the poeple you deal
with
are
"craft" people and don't have a clue what you're asking them and
really
don't
want to update you. So to compensate for this I type the finish date
they
provide. There is no resume date when they are working24 hours a
day.
As far as actuals: You do not get this during an outage with a 3,000
task
schedule , 150 boiler makers, 75 pipe fitters, 50 electricans, 35
instrument
techs, misc contractors...........
There is something called the "earned man-hour method" that is used
to
track
what percent complete you are. For this to happen the task needs to
keep
the
same "work" (man-hours) as when you baselined. Any other task type
adds
and
subtracts work. If you take your car to a dealer and he quotes you
$100
you
expect to pay that amount. Later you go to pick it up and he says
it's
$200
because Leisure Suit Larry took longer than most people, do you owe
the
man
$200 - NO. If he says Leisure Suit Larry was really fast I'm only
going
to
charge you $50. That will never happen either. He can only earn that
$100
reguardless of how his productivity was.
Earned man-hours over actual man-hours equals productivity.


:

Actually the scenario you describe does not at all require work and
duration
to be disconnected. A 40 man-hour task that has a daily work
pattern
of
8-8-8-split for 10 days-8-8 does not have a duration of 14 days, it
has a
duration of 5 days. The time in the split doesn't count for
duration -
it's
as if the task went on holiday and those days become non-working
time
excluded from the duration just like a normal weekend etc.

I was fine until you said "after entering a new finish date for
Task
A..."
Well, you CAN'T directly enter a new finish date for the task.
Entering a
date in the scheduled Finish field does not set the finish date, it
sets
a
Finish No Earlier Than constraint, a whole different critter.
Instead,
you
can revise the duration (implying work is still continuous but
there's
more
of it required) or you can split the task - splitting is a more
accurate
model of reality IMHO. The better approach is to ask the resource
what
date
he'll be able to resume work and either use that date with the
"reschedule
uncompleted work" tool or display the Resume field and enter it
there.
That
will cause the task to split over the down time days and show the
new
end
date while keeping the original duration as it should. Remember,
duration
and elapsed time are two different measures only roughly related to
each
other. In the case of an originally continuous task that actually
starts,
has some work, then stops, has some downtime, and then resumes
later
to
finish, the duration doesn't change but the elapsed time gets
longer.
When
you're saying you want Project to keep work and duration separate,
it
reveals you're equating duration with elapsed time which is
something
you
really can't do.

Here's another way to update that will do what you need I believe.
Create a
task X starting Monday, 5 days duration. Assign Leisure Suit Larry
to
the
task 100%. Work is 40 hours. In the Resource Usage view, display
the
Actual Work row. Enter 8 hours actual work on Mon, Tue, and Wed.
Now
he
books off sick. Enter 0 actual hours for Thur and Fri. Now you'll
see
16
hours push out into the following week, setting a new finish date
of
the
end
of the day Tues. And of course this would push down any successor
task's
starts. But the duration is still 5 days and the total work is
still
40
hours.
--

Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


Yes, yes, yes! ;-)... thanks for the passionate reply!

I think we do agree on :"You use the baseline and the current
schedule
together to compare the plan as it was expected to unfold THEN to
what
has actually happened until NOW so
you can accurately predict and control what is going to happen in
the
FUTURE."

But I will not agree with: "To do that successfully you simply
must
let
the calculating engine
do its job."

Here's an example of what I get in a weekly update: task "A"
planned
40h work, planned duration tuesday of last week (we call that the
"reporting week") until monday current week. Friday afternoon the
tracking data is collected and processed on monday. Sample data
for
Task "A". 32h actual work, first hours on Monday of reporting
week
already, so actual start one day early - great. Still there is no
entry
in "re estimate work remaining" and the task isn't set to
"complete"
so
there is still 8h of work to be done - no trouble so far: MSP
will
stick to the finish date of monday current week after entering
work.
But wait: there is an entry in "re estimate finish": thursday
current
week. So the guy working on task A tells me he can't finish those
8h
work today (sickness, availability of peer review, whatever...).
"Now
if I would just "let the calculation engine do its job" I am
exactly
NOT comparing real performance to plan - I'm losing valuable
information. After entering the new finish date for task A I'm
happy
that MSP will calculate the duration effects in the network
downstream
of task A for me. But it just doesn't make sense to stick to the
planning estimate when updating a single task: how would you
enter
that
a task is on budget but late otherwise? Overwrite the actual
cost,
manually change the units? I just find entering actual work and
then
updating remaining work or finish (i.e. planned finish, not
baseline)
if necessary 1:1 with the values I get from my update sheets the
most
straight forward. But I need to tell MSP to keep duration and
work
separate to be successful here.