When a project task over runs how do I change the end date automa.

[Andy Trow]

When using microsoftproject and a task ends early or overuns how can I get
the project end date to adjust without having to change the dates
automattically ?

 

[John]

When using microsoftproject and a task ends early or overuns how can I get
the project end date to adjust without having to change the dates
automattically ?

Andy,
If your schedule is dynamic, that is if tasks are linked in logical
sequence AND you do not have constraints on the tasks, then the end date
will automatically adjust.

If a task is finished early (or late), the user should enter the actual
completion date into the Actual Finish field. Project will then change
the scheduled finish date (i.e. the normal Finish field) to match the
actual date. WIth the task links in place, the whole plan is rescheduled
and the end date is moved accordingly.

If you are having to manually change task dates each time the plan is
updated, then that tells me you most likely created the schedule by
manually entering start and finish dates for each task. Doing so sets a
constraint on each task and completely defeats the scheduling algorithm
used by Project.

John
Project MVP

 

[Andy Trow]

Thanks. What about directly linking the end date to the % of a task
completed. eg a 4 week task is only 75% complete therefore I am a week behind
schedule, or a 4 week task was completed after 2 weeks ? Is the only way to
actualy change finished date

 

[Steve House]

If the task is in progress but taking longer than originally expected, the
best way to forget entering percentages and enter Actual Duration and
Remaining Duration in the Tracking table. Project will calculate the
percent complete and a new estimated finish date for you.

 

[John]

Thanks. What about directly linking the end date to the % of a task
completed. eg a 4 week task is only 75% complete therefore I am a week behind
schedule, or a 4 week task was completed after 2 weeks ? Is the only way to
actualy change finished date

Andy,
I think you are missing the concept of a dynamically linked schedule. If
a 4 week [duration] task is only 75% complete, that does NOT necessarily
mean the task is a week behind. If the task is only 75% after 4 weeks,
then yes, it is a week behind. But if the task is 75% complete at the
end of 3 weeks, then the task is right on schedule.

Steve suggested working with actual duration and remaining duration
which surprised me because Steve is a effort type of guy. Except in a
very limited number of cases duration doesn't accomplish anything.
Duration is simply the passage of time. Work effort by resources
assigned to the task is where the "rubber hits the road". That is why
the best way to track progress on a task is via % Work Complete. So the
real question to ask is, how many hours of the estimated work content
for a task is actually completed. I suggest you work with the Actual
Work field and the Remaining Work field. As Steve pointed out, doing so
will allow Project to re-calculate your schedule and adjust all dates
accordingly.

John
Project MVP

 

[Steve House]

LOL - there was method to my madness. Firstly, the OP likes "% Complete"
which by definition refer to duration, not work - that's a matter of program
design and not subject to interpretation. But the default setting is that
"Updating task status updates resource status" so in fact entering values
that change the original duration will also change the work estimates and so
it works out. While I agvree completely that man-hours are what really
count, the most intuitively accurate metric people have to work with when
making estimates is usually time rahter than work so the problem become one
of how to correlate estimtes of time remaining with FTE hours of work
remaining. In fact, when someone says "task X will require 47 man-hours of
work" the first thought that pops into my mind is "how in the world can you
really know that as a fact?" You've really got to have detailed human
factors engineering data "A painter will apply 10 square feet of paint per
man-hour of labour and you have 400 square feet to apply" and I just don't
believe you can obtain that kind of information most of the time. Couple
that with the psychological imperative of never looking bad in the eyes of
the boss so as soon as someone starts work on a task, no matter how long or
involved the task and how little they've really done on it, they're likely
to report "Oh, I'm 90% done!" when asked to report progress.

Thanks. What about directly linking the end date to the % of a task
completed. eg a 4 week task is only 75% complete therefore I am a week
behind
schedule, or a 4 week task was completed after 2 weeks ? Is the only way
to
actualy change finished date

Andy,
I think you are missing the concept of a dynamically linked schedule. If
a 4 week [duration] task is only 75% complete, that does NOT necessarily
mean the task is a week behind. If the task is only 75% after 4 weeks,
then yes, it is a week behind. But if the task is 75% complete at the
end of 3 weeks, then the task is right on schedule.

Steve suggested working with actual duration and remaining duration
which surprised me because Steve is a effort type of guy. Except in a
very limited number of cases duration doesn't accomplish anything.
Duration is simply the passage of time. Work effort by resources
assigned to the task is where the "rubber hits the road". That is why
the best way to track progress on a task is via % Work Complete. So the
real question to ask is, how many hours of the estimated work content
for a task is actually completed. I suggest you work with the Actual
Work field and the Remaining Work field. As Steve pointed out, doing so
will allow Project to re-calculate your schedule and adjust all dates
accordingly.

John
Project MVP

 

[John]

LOL - there was method to my madness. Firstly, the OP likes "% Complete"
which by definition refer to duration, not work - that's a matter of program
design and not subject to interpretation. But the default setting is that
"Updating task status updates resource status" so in fact entering values
that change the original duration will also change the work estimates and so
it works out. While I agvree completely that man-hours are what really
count, the most intuitively accurate metric people have to work with when
making estimates is usually time rahter than work so the problem become one
of how to correlate estimtes of time remaining with FTE hours of work
remaining. In fact, when someone says "task X will require 47 man-hours of
work" the first thought that pops into my mind is "how in the world can you
really know that as a fact?" You've really got to have detailed human
factors engineering data "A painter will apply 10 square feet of paint per
man-hour of labour and you have 400 square feet to apply" and I just don't
believe you can obtain that kind of information most of the time. Couple
that with the psychological imperative of never looking bad in the eyes of
the boss so as soon as someone starts work on a task, no matter how long or
involved the task and how little they've really done on it, they're likely
to report "Oh, I'm 90% done!" when asked to report progress.

Steve,
Boy, it seems that not all that long ago you and I were on opposite
sides of this issue - I was born and raised on fixed duration - chiefly
because that's the way our company used Project.

I agree that if someone is developing a schedule from scratch, then
duration is probably the more natural metric. However, most plans that I
have been involved with were built from historical data (i.e. man-hours)
of similar or at least relatable projects. So no, we don't know for "a
fact" how many man-hours it will take, but we have a much better basis
for those man-hours than we do for the duration.

John

Thanks. What about directly linking the end date to the % of a task
completed. eg a 4 week task is only 75% complete therefore I am a week
behind
schedule, or a 4 week task was completed after 2 weeks ? Is the only way
to
actualy change finished date

Andy,
I think you are missing the concept of a dynamically linked schedule. If
a 4 week [duration] task is only 75% complete, that does NOT necessarily
mean the task is a week behind. If the task is only 75% after 4 weeks,
then yes, it is a week behind. But if the task is 75% complete at the
end of 3 weeks, then the task is right on schedule.

Steve suggested working with actual duration and remaining duration
which surprised me because Steve is a effort type of guy. Except in a
very limited number of cases duration doesn't accomplish anything.
Duration is simply the passage of time. Work effort by resources
assigned to the task is where the "rubber hits the road". That is why
the best way to track progress on a task is via % Work Complete. So the
real question to ask is, how many hours of the estimated work content
for a task is actually completed. I suggest you work with the Actual
Work field and the Remaining Work field. As Steve pointed out, doing so
will allow Project to re-calculate your schedule and adjust all dates
accordingly.

John
Project MVP

:

When using microsoftproject and a task ends early or overuns how can
I
get
the project end date to adjust without having to change the dates
automattically ?

Andy,
If your schedule is dynamic, that is if tasks are linked in logical
sequence AND you do not have constraints on the tasks, then the end
date
will automatically adjust.

If a task is finished early (or late), the user should enter the actual
completion date into the Actual Finish field. Project will then change
the scheduled finish date (i.e. the normal Finish field) to match the
actual date. WIth the task links in place, the whole plan is
rescheduled
and the end date is moved accordingly.

If you are having to manually change task dates each time the plan is
updated, then that tells me you most likely created the schedule by
manually entering start and finish dates for each task. Doing so sets a
constraint on each task and completely defeats the scheduling algorithm
used by Project.

John
Project MVP

 

[Steve House]

Duration is merely the passage of time, true enough. But since the job of
the project manager is to guide the project to a conclusion on time and
within budget, isn't passage of time a vitally important metric, especially
if there's a mandated delivery date in place as is usually the case?

Using duration as the primary means of estimating and "fixed duration" tasks
are two entirely different critters altogether IMHO. Etsimating by duration
means to me "I think it will take X days" - the example I use for classes is
"Last year we upgraded 10 workstations and it took us 10 days so this year
when we have to upgrade 25 workstations it's a reasonable guess it'll take
about 25 days." We may not have the vaguest idea how many man hours were
required but we do know that we started the upgrades on May 1st and finished
them on May 15th. Fixed durations, OTOH implies that the duration can
somehow be established by management fiat and is engraved in granite, that
"I'm going to mandate that the task WILL take X days and expect the
resources to adjust their efforts so it works out that way" and that's just
not true 99.999% of the time. It appears to me that one of the primary
reasons to use a tool like MS Project is to answer the deployment question
"What will happen to the duration if I organize it this way?" and making
fixed duration the normal task type precludes ever being able to answer that
since no matter what you do to the resource assignment, duration doesn't
change.

LOL - there was method to my madness. Firstly, the OP likes "% Complete"
which by definition refer to duration, not work - that's a matter of
program
design and not subject to interpretation. But the default setting is
that
"Updating task status updates resource status" so in fact entering values
that change the original duration will also change the work estimates and
so
it works out. While I agvree completely that man-hours are what really
count, the most intuitively accurate metric people have to work with when
making estimates is usually time rahter than work so the problem become
one
of how to correlate estimtes of time remaining with FTE hours of work
remaining. In fact, when someone says "task X will require 47 man-hours
of
work" the first thought that pops into my mind is "how in the world can
you
really know that as a fact?" You've really got to have detailed human
factors engineering data "A painter will apply 10 square feet of paint
per
man-hour of labour and you have 400 square feet to apply" and I just
don't
believe you can obtain that kind of information most of the time. Couple
that with the psychological imperative of never looking bad in the eyes
of
the boss so as soon as someone starts work on a task, no matter how long
or
involved the task and how little they've really done on it, they're
likely
to report "Oh, I'm 90% done!" when asked to report progress.

Steve,
Boy, it seems that not all that long ago you and I were on opposite
sides of this issue - I was born and raised on fixed duration - chiefly
because that's the way our company used Project.

I agree that if someone is developing a schedule from scratch, then
duration is probably the more natural metric. However, most plans that I
have been involved with were built from historical data (i.e. man-hours)
of similar or at least relatable projects. So no, we don't know for "a
fact" how many man-hours it will take, but we have a much better basis
for those man-hours than we do for the duration.

John

Thanks. What about directly linking the end date to the % of a task
completed. eg a 4 week task is only 75% complete therefore I am a week
behind
schedule, or a 4 week task was completed after 2 weeks ? Is the only
way
to
actualy change finished date

Andy,
I think you are missing the concept of a dynamically linked schedule.
If
a 4 week [duration] task is only 75% complete, that does NOT
necessarily
mean the task is a week behind. If the task is only 75% after 4 weeks,
then yes, it is a week behind. But if the task is 75% complete at the
end of 3 weeks, then the task is right on schedule.

Steve suggested working with actual duration and remaining duration
which surprised me because Steve is a effort type of guy. Except in a
very limited number of cases duration doesn't accomplish anything.
Duration is simply the passage of time. Work effort by resources
assigned to the task is where the "rubber hits the road". That is why
the best way to track progress on a task is via % Work Complete. So the
real question to ask is, how many hours of the estimated work content
for a task is actually completed. I suggest you work with the Actual
Work field and the Remaining Work field. As Steve pointed out, doing so
will allow Project to re-calculate your schedule and adjust all dates
accordingly.

John
Project MVP

:

When using microsoftproject and a task ends early or overuns how
can
I
get
the project end date to adjust without having to change the dates
automattically ?

Andy,
If your schedule is dynamic, that is if tasks are linked in logical
sequence AND you do not have constraints on the tasks, then the end
date
will automatically adjust.

If a task is finished early (or late), the user should enter the
actual
completion date into the Actual Finish field. Project will then
change
the scheduled finish date (i.e. the normal Finish field) to match
the
actual date. WIth the task links in place, the whole plan is
rescheduled
and the end date is moved accordingly.

If you are having to manually change task dates each time the plan
is
updated, then that tells me you most likely created the schedule by
manually entering start and finish dates for each task. Doing so
sets a
constraint on each task and completely defeats the scheduling
algorithm
used by Project.

John
Project MVP

 

[John]

Duration is merely the passage of time, true enough. But since the job of
the project manager is to guide the project to a conclusion on time and
within budget, isn't passage of time a vitally important metric, especially
if there's a mandated delivery date in place as is usually the case?

Using duration as the primary means of estimating and "fixed duration" tasks
are two entirely different critters altogether IMHO. Etsimating by duration
means to me "I think it will take X days" - the example I use for classes is
"Last year we upgraded 10 workstations and it took us 10 days so this year
when we have to upgrade 25 workstations it's a reasonable guess it'll take
about 25 days." We may not have the vaguest idea how many man hours were
required but we do know that we started the upgrades on May 1st and finished
them on May 15th. Fixed durations, OTOH implies that the duration can
somehow be established by management fiat and is engraved in granite, that
"I'm going to mandate that the task WILL take X days and expect the
resources to adjust their efforts so it works out that way" and that's just
not true 99.999% of the time. It appears to me that one of the primary
reasons to use a tool like MS Project is to answer the deployment question
"What will happen to the duration if I organize it this way?" and making
fixed duration the normal task type precludes ever being able to answer that
since no matter what you do to the resource assignment, duration doesn't
change.

Steve,
For someone with a broken heart or someone coming out of surgery, I
agree, the passage of time is vitally important. In either case there is
nothing that can be "done" to make things heal faster. But for a
schedule, I don't think so. A schedule is based on the accomplishment of
something (actually many things) in order to achieve an end goal. And
you can't deliver anything with just the passage of time.

With regard to your example of the workstation upgrade. I think a more
important question to ask is, how many manhours were there in the 10
days it took to upgrade the stations last year. Was it one guy working
full time for 80 hours or was it 5 guys working full time for 400 hours
- big difference. If nobody has the vaguest idea of how many hours it
actually took last year then I submit that something is very wrong with
the accounting system. Especially for similar tasks that have been done
before, that historical data has to be available and if it is not used
to help plan the new project, somebody is missing the boat.

I agree with you wholeheartedly about trying to used fixed duration to
meet a mandate by upper management or a customer. The plan is not a
schedule, it is simply political maneuvering (i.e. not worth squat).

John
Project MPV

LOL - there was method to my madness. Firstly, the OP likes "% Complete"
which by definition refer to duration, not work - that's a matter of
program
design and not subject to interpretation. But the default setting is
that
"Updating task status updates resource status" so in fact entering values
that change the original duration will also change the work estimates and
so
it works out. While I agvree completely that man-hours are what really
count, the most intuitively accurate metric people have to work with when
making estimates is usually time rahter than work so the problem become
one
of how to correlate estimtes of time remaining with FTE hours of work
remaining. In fact, when someone says "task X will require 47 man-hours
of
work" the first thought that pops into my mind is "how in the world can
you
really know that as a fact?" You've really got to have detailed human
factors engineering data "A painter will apply 10 square feet of paint
per
man-hour of labour and you have 400 square feet to apply" and I just
don't
believe you can obtain that kind of information most of the time. Couple
that with the psychological imperative of never looking bad in the eyes
of
the boss so as soon as someone starts work on a task, no matter how long
or
involved the task and how little they've really done on it, they're
likely
to report "Oh, I'm 90% done!" when asked to report progress.

Steve,
Boy, it seems that not all that long ago you and I were on opposite
sides of this issue - I was born and raised on fixed duration - chiefly
because that's the way our company used Project.

I agree that if someone is developing a schedule from scratch, then
duration is probably the more natural metric. However, most plans that I
have been involved with were built from historical data (i.e. man-hours)
of similar or at least relatable projects. So no, we don't know for "a
fact" how many man-hours it will take, but we have a much better basis
for those man-hours than we do for the duration.

John

Thanks. What about directly linking the end date to the % of a task
completed. eg a 4 week task is only 75% complete therefore I am a week
behind
schedule, or a 4 week task was completed after 2 weeks ? Is the only
way
to
actualy change finished date

Andy,
I think you are missing the concept of a dynamically linked schedule.
If
a 4 week [duration] task is only 75% complete, that does NOT
necessarily
mean the task is a week behind. If the task is only 75% after 4 weeks,
then yes, it is a week behind. But if the task is 75% complete at the
end of 3 weeks, then the task is right on schedule.

Steve suggested working with actual duration and remaining duration
which surprised me because Steve is a effort type of guy. Except in a
very limited number of cases duration doesn't accomplish anything.
Duration is simply the passage of time. Work effort by resources
assigned to the task is where the "rubber hits the road". That is why
the best way to track progress on a task is via % Work Complete. So the
real question to ask is, how many hours of the estimated work content
for a task is actually completed. I suggest you work with the Actual
Work field and the Remaining Work field. As Steve pointed out, doing so
will allow Project to re-calculate your schedule and adjust all dates
accordingly.

John
Project MVP

:

When using microsoftproject and a task ends early or overuns how
can
I
get
the project end date to adjust without having to change the dates
automattically ?

Andy,
If your schedule is dynamic, that is if tasks are linked in logical
sequence AND you do not have constraints on the tasks, then the end
date
will automatically adjust.

If a task is finished early (or late), the user should enter the
actual
completion date into the Actual Finish field. Project will then
change
the scheduled finish date (i.e. the normal Finish field) to match
the
actual date. WIth the task links in place, the whole plan is
rescheduled
and the end date is moved accordingly.

If you are having to manually change task dates each time the plan
is
updated, then that tells me you most likely created the schedule by
manually entering start and finish dates for each task. Doing so
sets a
constraint on each task and completely defeats the scheduling
algorithm
used by Project.

John
Project MVP