Complete percentages & durations changing behind my back

[Diver512]

Hi,

So I have a large project with numerous major sections. The top section,
which we will call "Development" is beginning to be populated with percent
completes and actual start/finish dates. We are updating these every week.
As some tasks are changed in other sections of the plan, percent completes,
durations, and finish dates are shifting in the Development section. One day
Development will be 60% complete and the next day it will all of a sudden be
51% because the tasks in this section are moving around when people edit
other unrelated sections. We would like to be able to update the tasks with
the percentage the developers think it is complete without this unexplained
shift, and not as a percent of the duration complete.

Are my setting for my project wrong? I have Fixed Duration, not effort
driven for all tasks. Also, I do not understand some of the check boxes in
the Calculation tab under Project Options. Do I need to check the "Move to
end..." or "Move to start..." options? "Updating task status updates
resource status"?

On a side note: Are there MS Project Certification classes and do you
suggest a specific teaching group?

Thanks,
Brian

 

[Jim Aksel]

Tasks will change their %Complete if the estimated duration changes. In your
case, it appears the duration increased (more than likely from a FF on a
predecessor or successor). For example, if I start a task and take
60%Complete, the start date will not move. If someone else increases their
duration on a task that is FF to your started task, this is one reason the
%Complete would drop.

As for check boxes... It makes sense to "Move end of completed parts after
the status date bask to the status date" since this helps preclude starting
tasks in the future. The box immediately below it "And move...." is also not
a bad idea. This splits the tasks so that incomplete work is automatically
moved out past the status date.

The next two "Move start of remaining parts before the status data
forward..." I personally don't like that one since I want to key in a real
start date. Same thing with moving completed parts forward .... I can't
think why that is a good idea (But that is my opinion)

From Help:
***********
Updating task status updates resource status Automatically updates
resource status, such as actual and remaining work and cost, whenever you
update task status, such as percent complete, actual duration, or remaining
duration.

For example, if you update a task's percent complete, the % Complete field
for the resource and assignment are automatically calculated to reflect that
task's percent complete.

Selecting this check box also causes the reverse to be true: if you update
resource status, then task status is automatically updated.

If this check box is cleared, you must enter values in the Actual Work field
for resources in order to have an accurate picture of the actual work and
actual cost. By default, this check box is selected.

Whether this check box is selected or cleared, once a task is 100 percent
complete, work on assignments is also marked complete.
********************

Side Note:
Microsoft has a Cetification Exam for MS Project 2007 Configuration on Beta
Test this month, ending (I think) on May 8th. The full exam should release
sometime shortly thereafter (Microsoft will determine the duration of
"shortly").

--
If this post was helpful, please consider rating it.

Jim
It''s software; it''s not allowed to win.

Visit http://project.mvps.org/ for FAQs and more information
about Microsoft Project

 

[Steve House]

You could use % Physical Complete if you want to update based on what % of
the task the developers think is done but be aware that % Physical Complete
does not rollup from the detail lines. "% Complete" is by definition
(ActualDuration/TotalDuration) * 100 and that cannot be altered any more
that the definition of "White" can be altered to mean "the complete absence
of light." Other ways of tracking progress may be useful but anything other
than comparing duration completed versus total to be done can't properly be
called "% Complete." For a summary task, the rolled up % Complete is a
little more complicated. There it is a weighted value computed as the sum
of the actual durations of all the subtasks divided by the sum of the total
durations of all the subtasks.

 

[Diver512]

So conceptually, are we tracking this project improperly? Groups seem to be
giving us Physical % Completes rather than actual % Completes against the
duration. Basically the problem is that the original duration estimates
given in the plan do not hold true. What development project ever has
duration estimates that hold true throughout? How do we show whether we are
ahead or behind schedule when everything is being measured against constant
durations?

Ok correct me if I'm wrong. You update actual duration percent completes as
you feel how far along you are. The durations will actually recalculate
according to that entered percentage. The recalculated durations can then be
measured against the baseline to see if the tasks/project are on schedule.
Sound right? And this is why I asked where I should take an MS Project
Course in my first post.

Thanks again. You guys are MVPs.

Brian

You could use % Physical Complete if you want to update based on what % of
the task the developers think is done but be aware that % Physical Complete
does not rollup from the detail lines. "% Complete" is by definition
(ActualDuration/TotalDuration) * 100 and that cannot be altered any more
that the definition of "White" can be altered to mean "the complete absence
of light." Other ways of tracking progress may be useful but anything other
than comparing duration completed versus total to be done can't properly be
called "% Complete." For a summary task, the rolled up % Complete is a
little more complicated. There it is a weighted value computed as the sum
of the actual durations of all the subtasks divided by the sum of the total
durations of all the subtasks.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Hi,

So I have a large project with numerous major sections. The top section,
which we will call "Development" is beginning to be populated with percent
completes and actual start/finish dates. We are updating these every
week.
As some tasks are changed in other sections of the plan, percent
completes,
durations, and finish dates are shifting in the Development section. One
day
Development will be 60% complete and the next day it will all of a sudden
be
51% because the tasks in this section are moving around when people edit
other unrelated sections. We would like to be able to update the tasks
with
the percentage the developers think it is complete without this
unexplained
shift, and not as a percent of the duration complete.

 

[Steve House]

Nope - baselines don't figure into completion percentages at all, regardless
of whether you're measuring % Complete, % Work Complete, or % Physical
Complete. You are correct, though, that durations are a dynamic thing. I
like to think of the plan as displaying two types of info once work has
begun ... historical fact about what has transpired up to the status date
and projected performance of what has not yet been done based on projections
derived from how things have gone so far. The baseline preserves our
original estimates. As an example, we have done 3 days on a task and the
resource doing the work estimates that he will take 9 more days to complete
it. We are 25% Complete on that task ... period. It's irrelevant whether
our original estimate was 2 days, 12 days, 20 days, or 200 days. As we
began work and saw how things were progressing we've learned that it will
probably take 12 days and we've done 3 of them, that task is 25% Complete
because we're 25% of the way along the time from when we started until we
can holler "done!" and walk away from it. To see how that compares to our
original estimates we need to switch over to a metric called 'earned value'
that compares essentially man-hours of work that have been done (current
plan's actuals) to the man-hours that were supposed to have been done
(baseline plan's scheduled) up to the status date, expressed in units of
cost, which is sometimes a hard concept to wrap one's head around.

From a practical standpoint, don't even ask your resources for an update
phrased as "% Complete" - you have no idea what is in their mind when they
say "I'm 30% complete." Instead, ask them how much time they've put in on
it so far and how much more time do they think it will take before they're
done. There's your actual duration and remaining duration and Project will
calculate the new total duration and % completion for you when you enter
them. There's a natural human tendency to over-estimate one's progress in
order to look good in the boss's eyes and odds are that as soon as they take
a first look at the task the resource will report they're 75% done. Pinning
them down to "how much have you done and how much is left to go" goes a long
ways in minimizing that effect.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

So conceptually, are we tracking this project improperly? Groups seem to
be
giving us Physical % Completes rather than actual % Completes against the
duration. Basically the problem is that the original duration estimates
given in the plan do not hold true. What development project ever has
duration estimates that hold true throughout? How do we show whether we
are
ahead or behind schedule when everything is being measured against
constant
durations?

Ok correct me if I'm wrong. You update actual duration percent completes
as
you feel how far along you are. The durations will actually recalculate
according to that entered percentage. The recalculated durations can then
be
measured against the baseline to see if the tasks/project are on schedule.
Sound right? And this is why I asked where I should take an MS Project
Course in my first post.

Thanks again. You guys are MVPs.

Brian

You could use % Physical Complete if you want to update based on what %
of
the task the developers think is done but be aware that % Physical
Complete
does not rollup from the detail lines. "% Complete" is by definition
(ActualDuration/TotalDuration) * 100 and that cannot be altered any more
that the definition of "White" can be altered to mean "the complete
absence
of light." Other ways of tracking progress may be useful but anything
other
than comparing duration completed versus total to be done can't properly
be
called "% Complete." For a summary task, the rolled up % Complete is a
little more complicated. There it is a weighted value computed as the
sum
of the actual durations of all the subtasks divided by the sum of the
total
durations of all the subtasks.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Hi,

So I have a large project with numerous major sections. The top
section,
which we will call "Development" is beginning to be populated with
percent
completes and actual start/finish dates. We are updating these every
week.
As some tasks are changed in other sections of the plan, percent
completes,
durations, and finish dates are shifting in the Development section.
One
day
Development will be 60% complete and the next day it will all of a
sudden
be
51% because the tasks in this section are moving around when people
edit
other unrelated sections. We would like to be able to update the tasks
with
the percentage the developers think it is complete without this
unexplained
shift, and not as a percent of the duration complete.

 

[Mike Glen]

Hi Diver512,

You might like to have a look at my series on Microsoft Project in the
TechTrax ezine, particularly #27 on Progress Data Input, at this site:
http://tinyurl.com/2xbhc or this:
http://pubs.logicalexpressions.com/Pub0009/LPMFrame.asp?CMD=ArticleSearch&AUTH=23
(Perhaps you'd care to rate the article before leaving the site,
Thanks.)

Hope this helps - please let us know how you get on

Mike Glen
MS Project MVP

Nope - baselines don't figure into completion percentages at all,
regardless of whether you're measuring % Complete, % Work Complete, or %
Physical Complete. You are correct, though, that durations are a dynamic
thing. I like to think of the plan as displaying two types of info once
work has begun ... historical fact about what has transpired up to the
status date and projected performance of what has not yet been done based
on projections derived from how things have gone so far. The baseline
preserves our original estimates. As an example, we have done 3 days on
a task and the resource doing the work estimates that he will take 9 more
days to complete it. We are 25% Complete on that task ... period. It's
irrelevant whether our original estimate was 2 days, 12 days, 20 days, or
200 days. As we began work and saw how things were progressing we've
learned that it will probably take 12 days and we've done 3 of them, that
task is 25% Complete because we're 25% of the way along the time from when
we started until we can holler "done!" and walk away from it. To see how
that compares to our original estimates we need to switch over to a metric
called 'earned value' that compares essentially man-hours of work that
have been done (current plan's actuals) to the man-hours that were
supposed to have been done (baseline plan's scheduled) up to the status
date, expressed in units of cost, which is sometimes a hard concept to
wrap one's head around.

From a practical standpoint, don't even ask your resources for an update
phrased as "% Complete" - you have no idea what is in their mind when they
say "I'm 30% complete." Instead, ask them how much time they've put in
on it so far and how much more time do they think it will take before
they're done. There's your actual duration and remaining duration and
Project will calculate the new total duration and % completion for you
when you enter them. There's a natural human tendency to over-estimate
one's progress in order to look good in the boss's eyes and odds are that
as soon as they take a first look at the task the resource will report
they're 75% done. Pinning them down to "how much have you done and how
much is left to go" goes a long ways in minimizing that effect.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

So conceptually, are we tracking this project improperly? Groups seem to
be
giving us Physical % Completes rather than actual % Completes against the
duration. Basically the problem is that the original duration estimates
given in the plan do not hold true. What development project ever has
duration estimates that hold true throughout? How do we show whether we
are
ahead or behind schedule when everything is being measured against
constant
durations?

Ok correct me if I'm wrong. You update actual duration percent completes
as
you feel how far along you are. The durations will actually recalculate
according to that entered percentage. The recalculated durations can
then be
measured against the baseline to see if the tasks/project are on
schedule.
Sound right? And this is why I asked where I should take an MS Project
Course in my first post.

Thanks again. You guys are MVPs.

Brian

You could use % Physical Complete if you want to update based on what %
of
the task the developers think is done but be aware that % Physical
Complete
does not rollup from the detail lines. "% Complete" is by definition
(ActualDuration/TotalDuration) * 100 and that cannot be altered any more
that the definition of "White" can be altered to mean "the complete
absence
of light." Other ways of tracking progress may be useful but anything
other
than comparing duration completed versus total to be done can't properly
be
called "% Complete." For a summary task, the rolled up % Complete is a
little more complicated. There it is a weighted value computed as the
sum
of the actual durations of all the subtasks divided by the sum of the
total
durations of all the subtasks.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


Hi,

So I have a large project with numerous major sections. The top
section,
which we will call "Development" is beginning to be populated with
percent
completes and actual start/finish dates. We are updating these every
week.
As some tasks are changed in other sections of the plan, percent
completes,
durations, and finish dates are shifting in the Development section.
One
day
Development will be 60% complete and the next day it will all of a
sudden
be
51% because the tasks in this section are moving around when people
edit
other unrelated sections. We would like to be able to update the
tasks
with
the percentage the developers think it is complete without this
unexplained
shift, and not as a percent of the duration complete.

 

[Ray Stratton, PMP, EVP]

Nope - baselines don't figure into completion percentages at all, regardless
of whether you're measuring % Complete, % Work Complete, or % Physical
Complete. You are correct, though, that durations are a dynamic thing. I
like to think of the plan as displaying two types of info once work has
begun ... historical fact about what has transpired up to the status date
and projected performance of what has not yet been done based on projections
derived from how things have gone so far. The baseline preserves our
original estimates. As an example, we have done 3 days on a task and the
resource doing the work estimates that he will take 9 more days to complete
it. We are 25% Complete on that task ... period. It's irrelevant whether
our original estimate was 2 days, 12 days, 20 days, or 200 days. As we
began work and saw how things were progressing we've learned that it will
probably take 12 days and we've done 3 of them, that task is 25% Complete
because we're 25% of the way along the time from when we started until we
can holler "done!" and walk away from it. To see how that compares to our
original estimates we need to switch over to a metric called 'earned value'
that compares essentially man-hours of work that have been done (current
plan's actuals) to the man-hours that were supposed to have been done
(baseline plan's scheduled) up to the status date, expressed in units of
cost, which is sometimes a hard concept to wrap one's head around.

From a practical standpoint, don't even ask your resources for an update
phrased as "% Complete" - you have no idea what is in their mind when they
say "I'm 30% complete." Instead, ask them how much time they've put in on
it so far and how much more time do they think it will take before they're
done. There's your actual duration and remaining duration and Project will
calculate the new total duration and % completion for you when you enter
them. There's a natural human tendency to over-estimate one's progress in
order to look good in the boss's eyes and odds are that as soon as they take
a first look at the task the resource will report they're 75% done. Pinning
them down to "how much have you done and how much is left to go" goes a long
ways in minimizing that effect.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visithttp://www.mvps.org/project/faqs.htmfor the FAQs

So conceptually, are we tracking this project improperly? Groups seem to
be
giving us Physical % Completes rather than actual % Completes against the
duration. Basically the problem is that the original duration estimates
given in the plan do not hold true. What development project ever has
duration estimates that hold true throughout? How do we show whether we
are
ahead or behind schedule when everything is being measured against
constant
durations?

Ok correct me if I'm wrong. You update actual duration percent completes
as
you feel how far along you are. The durations will actually recalculate
according to that entered percentage. The recalculated durations can then
be
measured against the baseline to see if the tasks/project are on schedule.
Sound right? And this is why I asked where I should take an MS Project
Course in my first post.

Thanks again. You guys are MVPs.

Brian

You could use % Physical Complete if you want to update based on what %
of
the task the developers think is done but be aware that % Physical
Complete
does not rollup from the detail lines. "% Complete" is by definition
(ActualDuration/TotalDuration) * 100 and that cannot be altered any more
that the definition of "White" can be altered to mean "the complete
absence
of light." Other ways of tracking progress may be useful but anything
other
than comparing duration completed versus total to be done can't properly
be
called "% Complete." For a summary task, the rolled up % Complete is a
little more complicated. There it is a weighted value computed as the
sum
of the actual durations of all the subtasks divided by the sum of the
total
durations of all the subtasks.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visithttp://www.mvps.org/project/faqs.htmfor the FAQs
Hi,
So I have a large project with numerous major sections. The top
section,
which we will call "Development" is beginning to be populated with
percent
completes and actual start/finish dates. We are updating these every
week.
As some tasks are changed in other sections of the plan, percent
completes,
durations, and finish dates are shifting in the Development section.
One
day
Development will be 60% complete and the next day it will all of a
sudden
be
51% because the tasks in this section are moving around when people
edit
other unrelated sections. We would like to be able to update the tasks
with
the percentage the developers think it is complete without this
unexplained
shift, and not as a percent of the duration complete.- Hide quoted text -

- Show quoted text -

Steve's description of EVM is a little off the mark. There are no
financial or staff-hour "actuals" in estimating earned value. It can
not be computed. EV is found from looking at the work done,
physically, and translating that value to its proportion of the tasks
or deliverables budget. Once this is done, then one can look at the
actual costs to determine if what was spent was appropriate (Cost
Performance Index, Cost Variance, or Percent Cost Variance.)