Accumulated % Completed improperly calculated

[Pedro Caetano Barros]

Sirs,

Our PM department have developed a process to generate S Curve of Schedule,
based on Accumulated % Complete values. We used to generate this S Curve
using MS Project 2000 and MS Excel 2000. Data used to generate the curve are
based ONLY on % complete progress, since the PM process maturity does not
allow us to generate S curves based on BCWP, BCWS and ACWP values.

Our organization now needs to update MS Project to 2003 version. However, MS
Project 2003 cannot generate % Complete and Accumulated % Complete throughout
the entire project (it stops exactly in the very timescale point you have two
tasks or two phases, for instance, simultaneously).

This problem can be easily noticed if you open "Task Usage" view, adding
"Accumulated % Complete" in the timesheet section.

I would like to know how to solve this problem, a service pack or add-in, or
another procedure to obtain correctly Accumulated % Complete values to be
able to generate the Schedule S Curve properly.

Thank you for any help.

Regards,

Pedro Caetano Barros
MS EPM Suite 2003 Support Group
São Paulo - SP
(e-mail address removed)
(e-mail address removed)

 

[Steve House [Project MVP]]

What do you mean by "...the PM process maturity does not allow us to
generate S curves based on BCWP, BCWS and ACWP values?" Pushing a bit more
PM maturity into your business process should be straightforward.

I'd be more worried about the validity of your old method of generating S
curves. Remember that "% Complete" in Project refers strictly to the
passage of duration - it conveys no information at all about how well the
work is proceding, if we're working at the rate we thought we'd achieve, or
how the physical progress is coming along. We have a project that lasts 100
days and we're at day 50, having done all the work that was scheduled before
today as we had planned to do it. We are 50% done. We made have only done
10% of the deliverable or 20% of the work required but we're still 50%
done - who knows, maybe we planned on a big push between day 90 and day 100
to put us over the top.

If by this 50% duration point we'd planned to do 25% of the total work (and
it can easily happen that way) and we have really done 25%, we're on
schedule. If at this point we'd planned on doing 25% of the total work but
only have done 10%, we're behind schedule. If at this point we'd planned to
do 25% of the total man-hours but have done 40%, we're ahead of schedule.
But only looking at what % complete today's date represents doesn't tell us
a thing about whether we're on schedule. Only looking at work planned
versus work performed will tell us that - in other words, BWCS and
BCWP/ACWP.

If your statement about "PM maturity" means you're not tracking resource
cost, use a rate of $1 per hour. Now the BCWS, BCWP, and ACWP figures will
stand for man-hours of work (even though they have a $ for their units)
planned to date versus achieved to date and your S curves will be a valid
indicator of progress.

 

[Pedro Caetano Barros]

Steve,

Initially I'd like to thank you very much for your answer and explanations.
Talking about our non-mature PM process, there already is a Project been
executed
to improve PM maturity in the company. Very soon we'll be using SPI and CPI
data and tendencies to analyze projects performance.

In the current moment, however, there is an organizational process that
dictates that the S Curve MUST use Cummulated % Complete to be generated. We
understand that the S Curve based on % Complete doesn't mean completion of
work or project artifacts - we know about it - but the process today says we
should use Cum. % Complete. Moreover, although it is "somekind
old-fashioned", S Curve based on Cummulated % Complete is still a good, valid
method to analyze project progress.

In reality, our problem IS that MS Project 2000 DOES calculate Cum. %
Complete
correctly and MS Project 2002 and 2003 DOES NOT, what is very intriging!
It can be a MS Project bug or something else, but I think that calculated data
have to have the same results no matter the version of the software.

Anyway, we will test and investigate the $1 per hour method for
BCWP/ACWP-based S Curve.
If you or anyone else have more information on how to solve specifically the
Cum. % Complete calculation problem, we'll be very thankful.

Thank you very much again,

Regards,

Pedro Caetano Barros
MS EPM Suite 2003 Support Group
Sao Paulo - SP - Brazil
(e-mail address removed)
(e-mail address removed)

 

[Steve House [Project MVP]]

If you are are mandated to use "% complete" you need to be clear *which* "%
complete" you're referring to. Project 2003 tracks 3 separate percentages -
% Complete (duration), % Work Complete (man-hours), and % Physical Complete.
% Complete and % Work Complete are linked by default so that updating one
updates the other but they may be unlinked in the options menu to allow
inpependent entry of each. % Physical Complete is always a manual entry
based on estimated progress (and usually very unreliable because at best
it's a very loosey-goosey concept).

What I find confusing by your method is if you plot duration time along the
X axis and Cummulative % Complete on the Y axis you don't get an "S" curve,
you will get a 45 degree sloped straight line, at least when you're working
according to plan. Our project schedule requires 100 days. We work exactly
according to plan. At day 25 I'll be 25% complete by definition of "%
Complete." On day 50 I'm 50% complete and on day 75 I'm 75% complete. The
only time this plot deviates from a straight line is if we work more or less
duration hours than have elapsed between start date and the reporting date.
If I work LESS, say have some sick days in there where work was scheduled
but no work took place, the curve may bend downward reflecting on day 75
I've only actually worked for 70 days instead of the 75 originally
scheduled. If somehow we get "2'fers" scheduled to do a task in 2 4-hours
days but do it in 1 8-hour day for example, the curve might bend up. Thus a
real-world curve of cumulative % complete might resemble the profile of a
range of foothills ascending towards the edge of a high plateau representing
project finish. But I can't envision any scenario that would cause it to
form a classic "S" curve similar to what you get plotting BCWS other than
purely by accident.

% Complete and % Work Complete are often the same number but just as often
they are not. Example (assuming standard calendars). I have a task to
paint a room, starting Mon 8am and ending Fri 5pm. I assign Joe Painter to
it 100%. Duration is 40 hours, work is 40 man-hours. It's now Thur evening
at 5pm and work has gone according to plan. % Complete = 32/40 = 80% %
Work Complete = 32/40 = 80%. But consider a contoured task ... our painter
is scheduled to do 1 hour prep and seal on Mon, 1 hour applying primer coat
Tue, 1 hour 1st colour coat Wed, 1 hour 2nd colour coat Thu, and 8 hours
finishing detail work Fri. Duration is still 40 hours but this time total
work is 12 man-hours. Again Thur at 5pm and working as planned... %
Complete = 32/40 = 80% BUT % Work Complete = 4/12 = 33%.

When Project calculates the rolled-up Summary % Complete, which at the
Project Summary level would be the Cumulative % Complete, it uses a weighted
average. The duration of a summary task is not the arithmetic sum of the
subtasks but instead is the time between when the earliest starting task
begins and last finishing task ends. The % Complete of a summary task
however is the AVERAGE completion level of its subtasks. When calculating
Summary % Complete, Project sums the scheduled durations of the individual
subtasks, sums the actual durations worked to date of the individual
subtasks (Duration * % Complete), and divides the 2 totals to derive the
Summary % Complete. It subtracts that from 100 to calculate the Summary %
Remaining. It multiples Summary % Remaining by Summary Duration and
subtracts the resulting interval from the Summary Finish to calculate the
effective "completed through" date. (I think it subtracts from finish
rather than adds to start to correctly handle subtask splits and lags.)

Summary % Work Complete is simpler. The total scheduled work on a summary
task is the simple arithmetic sum of the work scheduled for the subtasks.
Total man-hours worked to date / total man-hours scheduled = % Work
Complete.

AFAIK none of this changed between MSP2000 and MSP2003.

Hope this helps you figuring out how to get the results you need.
--
Steve House [MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

 

[Trevor Rabey]

Steve,
Obviously % Complete is just Duration, actual duration/planned duration
% Work Complete is Work (ie man-hours), actual hours/planned hours
% Cost, if it existed, would be actual $/planned $

I think that when people refer to "% Progress", a term that doesn't exist
in the PM lexicon and one that I would stamp out with extreme prejudice,
they mean something like 300 bricks laid out of 1000 bricks, but then they
go ahead and type in 30% at % Complete or at % Work Complete, both mistakes.
People want somewhere in MSP to put % bricks but there isn't one so it goes
in % Complete or at % Work Complete, first mistake and start of more pain to
come.
% Physical Complete isn't connected to anything else so using that doesn't
help.

Thanks

 

[Steve House [Project MVP]]

Agreed. % Physical Complete is so loosey goosey I can't image being able to
accurately estimate it in any but the most unusual circumstances ... I'm
designing an engine - what would 35% Physical Complete look like? Crankcase
done but haven't finished the cylinder head, electrical complete but still
working on fuel, drawings done for the front half???
--
Steve House [MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

 

[Pedro Caetano Barros]

Sirs,

Initially I would like to thank you for your answers on this issue.

Regardless of which method is more or less correct to analyze project
progress,
completion performance or other project data, we understand that MS Project
2002/2003 DOES NOT generate cummulative % complete correctly in very usual
circumstances, since the project schedule analysis is crucial to our PM
support work.

We had the opportunity to contact Microsoft Representatives here in Brazil
to expose the situation. After our explanations they agreeded that THERE IS a
problem
in generating cummulative % complete throuhtout the project in MS Project
2002/2003. Because of that a Service Request was opened at Microsoft in order
to report the occurrence and try to find a solution.

If you want we can send you privately by e-mail the material we produced
(images and mpp files) to document the problem.

Again, thank you very much.

Regards,

Pedro Caetano Barros
MS EPM Suite 2003 Support Group
Sao Paulo - SP - Brazil
(e-mail address removed)
(e-mail address removed)

 

[Steve House [Project MVP]]

I'd like to see your examples, if you don't mind, of the incorrect
calculation and most importantly, an explanation of what you believe to be
the correct method to calculate them, showing how your methods and those
already in MS Project give different results.

Project normally calculates the Cummulative % Complete (that is, the
completion shown for summary tasks up to and including the Project Summary
Task) as a weighted average of the progress on the included performance
tasks. It sums the scheduled durations of the performance tasks, sums the
actual durations of the same tasks and divides the two. If my project has 5
tasks of 2,3,4,5, and 6 days duration respectively and each of those tasks
has had 2 days of work actually achieved, the individual task completions
are: Task A - 2 days required and 2 days worked for 100% complete, Task B -
3 days & 2 days for 66%, Task C - 4 & 2 for 50%, Task D - 5 & 2 for 40%, and
Task E - 6 & 2 for 33%

For the project as a whole, the percent complete is 2+3+4+5+6 for a total of
20 working days scheduled divided by a total of 2+2+2+2+2 or 10 working days
completed for an Cumulative % Complete of 50%. Note that links, lag and lead
times, and task sequencing are irrelevant here - the same numbers obtain
whether the tasks are worked in parallel or in sequence, worked continuously
or have gaps in between. % Complete always refers to the duration as defined
by the working time calendar over which work has actually taken place
divided by the total duration required to complete the task. Where links DO
influence it is in converting that % Complete to an effect Cummulative
Actual Duration and Remaining Duration. The cummulative % Complete is
subtracted from 100% to come up with a "% Incomplete." That is multiplied
by the Summary Duration to come up with a summary Remaining Duration. That
in turn is subtracted from the summary Total Duration to come up with the
summary Actual Duration

In our example the cummulative % Complete is 50% regardless of sequencing.
If the tasks start together the project duration is 6 days, the project's
actual duration is 3 days and remaining duration is also 3 days. But if the
tasks are in sequence, the project duration is 20 days, the actual duration
is 10 days and the remaining duration is 10 days.

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

Sirs,

Initially I would like to thank you for your answers on this issue.

Regardless of which method is more or less correct to analyze project
progress,
completion performance or other project data, we understand that MS
Project
2002/2003 DOES NOT generate cummulative % complete correctly in very usual
circumstances, since the project schedule analysis is crucial to our PM
support work.

We had the opportunity to contact Microsoft Representatives here in Brazil
to expose the situation. After our explanations they agreeded that THERE
IS a
problem
in generating cummulative % complete throuhtout the project in MS Project
2002/2003. Because of that a Service Request was opened at Microsoft in
order
to report the occurrence and try to find a solution.

If you want we can send you privately by e-mail the material we produced
(images and mpp files) to document the problem.

Again, thank you very much.

Regards,

Pedro Caetano Barros
MS EPM Suite 2003 Support Group
Sao Paulo - SP - Brazil
(e-mail address removed)
(e-mail address removed)

Agreed. % Physical Complete is so loosey goosey I can't image being able
to
accurately estimate it in any but the most unusual circumstances ... I'm
designing an engine - what would 35% Physical Complete look like?
Crankcase
done but haven't finished the cylinder head, electrical complete but
still
working on fuel, drawings done for the front half???
--
Steve House [MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Steve,
Obviously % Complete is just Duration, actual duration/planned duration
% Work Complete is Work (ie man-hours), actual hours/planned hours
% Cost, if it existed, would be actual $/planned $

I think that when people refer to "% Progress", a term that doesn't
exist
in the PM lexicon and one that I would stamp out with extreme
prejudice,
they mean something like 300 bricks laid out of 1000 bricks, but then
they
go ahead and type in 30% at % Complete or at % Work Complete, both
mistakes.
People want somewhere in MSP to put % bricks but there isn't one so it
goes in % Complete or at % Work Complete, first mistake and start of
more
pain to come.
% Physical Complete isn't connected to anything else so using that
doesn't
help.

Thanks



"Steve House [Project MVP]" <[email protected]>
wrote in message If you are are mandated to use "% complete" you need to be clear
*which*
"% complete" you're referring to. Project 2003 tracks 3 separate
percentages - % Complete (duration), % Work Complete (man-hours), and
%
Physical Complete. % Complete and % Work Complete are linked by
default
so that updating one updates the other but they may be unlinked in the
options menu to allow inpependent entry of each. % Physical Complete
is
always a manual entry based on estimated progress (and usually very
unreliable because at best it's a very loosey-goosey concept).

What I find confusing by your method is if you plot duration time
along
the X axis and Cummulative % Complete on the Y axis you don't get an
"S"
curve, you will get a 45 degree sloped straight line, at least when
you're working according to plan. Our project schedule requires 100
days. We work exactly according to plan. At day 25 I'll be 25%
complete
by definition of "% Complete." On day 50 I'm 50% complete and on day
75
I'm 75% complete. The only time this plot deviates from a straight
line
is if we work more or less duration hours than have elapsed between
start
date and the reporting date. If I work LESS, say have some sick days
in
there where work was scheduled but no work took place, the curve may
bend
downward reflecting on day 75 I've only actually worked for 70 days
instead of the 75 originally scheduled. If somehow we get "2'fers"
scheduled to do a task in 2 4-hours days but do it in 1 8-hour day for
example, the curve might bend up. Thus a real-world curve of
cumulative
% complete might resemble the profile of a range of foothills
ascending
towards the edge of a high plateau representing project finish. But I
can't envision any scenario that would cause it to form a classic "S"
curve similar to what you get plotting BCWS other than purely by
accident.

% Complete and % Work Complete are often the same number but just as
often they are not. Example (assuming standard calendars). I have a
task to paint a room, starting Mon 8am and ending Fri 5pm. I assign
Joe
Painter to it 100%. Duration is 40 hours, work is 40 man-hours. It's
now Thur evening at 5pm and work has gone according to plan. %
Complete
= 32/40 = 80% % Work Complete = 32/40 = 80%. But consider a
contoured
task ... our painter is scheduled to do 1 hour prep and seal on Mon, 1
hour applying primer coat Tue, 1 hour 1st colour coat Wed, 1 hour 2nd
colour coat Thu, and 8 hours finishing detail work Fri. Duration is
still 40 hours but this time total work is 12 man-hours. Again Thur
at
5pm and working as planned... % Complete = 32/40 = 80% BUT % Work
Complete = 4/12 = 33%.

When Project calculates the rolled-up Summary % Complete, which at the
Project Summary level would be the Cumulative % Complete, it uses a
weighted average. The duration of a summary task is not the
arithmetic
sum of the subtasks but instead is the time between when the earliest
starting task begins and last finishing task ends. The % Complete of a
summary task however is the AVERAGE completion level of its subtasks.
When calculating Summary % Complete, Project sums the scheduled
durations
of the individual subtasks, sums the actual durations worked to date
of
the individual subtasks (Duration * % Complete), and divides the 2
totals
to derive the Summary % Complete. It subtracts that from 100 to
calculate the Summary % Remaining. It multiples Summary % Remaining
by
Summary Duration and subtracts the resulting interval from the Summary
Finish to calculate the effective "completed through" date. (I think
it
subtracts from finish rather than adds to start to correctly handle
subtask splits and lags.)

Summary % Work Complete is simpler. The total scheduled work on a
summary task is the simple arithmetic sum of the work scheduled for
the
subtasks. Total man-hours worked to date / total man-hours scheduled =
%
Work Complete.

AFAIK none of this changed between MSP2000 and MSP2003.

Hope this helps you figuring out how to get the results you need.
--
Steve House [MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs



"Pedro Caetano Barros" <[email protected]>
wrote in message
Steve,

Initially I'd like to thank you very much for your answer and
explanations.
Talking about our non-mature PM process, there already is a Project
been
executed
to improve PM maturity in the company. Very soon we'll be using SPI
and
CPI
data and tendencies to analyze projects performance.

In the current moment, however, there is an organizational process
that
dictates that the S Curve MUST use Cummulated % Complete to be
generated. We
understand that the S Curve based on % Complete doesn't mean
completion
of
work or project artifacts - we know about it - but the process today
says we
should use Cum. % Complete. Moreover, although it is "somekind
old-fashioned", S Curve based on Cummulated % Complete is still a
good,
valid
method to analyze project progress.

In reality, our problem IS that MS Project 2000 DOES calculate Cum.
%
Complete
correctly and MS Project 2002 and 2003 DOES NOT, what is very
intriging!
It can be a MS Project bug or something else, but I think that
calculated data
have to have the same results no matter the version of the software.

Anyway, we will test and investigate the $1 per hour method for
BCWP/ACWP-based S Curve.
If you or anyone else have more information on how to solve
specifically
the
Cum. % Complete calculation problem, we'll be very thankful.

Thank you very much again,

Regards,

Pedro Caetano Barros
MS EPM Suite 2003 Support Group
Sao Paulo - SP - Brazil
(e-mail address removed)
(e-mail address removed)











:

What do you mean by "...the PM process maturity does not allow us to
generate S curves based on BCWP, BCWS and ACWP values?" Pushing a
bit
more
PM maturity into your business process should be straightforward.

I'd be more worried about the validity of your old method of
generating
S
curves. Remember that "% Complete" in Project refers strictly to
the
passage of duration - it conveys no information at all about how
well
the
work is proceding, if we're working at the rate we thought we'd
achieve, or
how the physical progress is coming along. We have a project that
lasts 100
days and we're at day 50, having done all the work that was
scheduled
before
today as we had planned to do it. We are 50% done. We made have
only
done
10% of the deliverable or 20% of the work required but we're still
50%
done - who knows, maybe we planned on a big push between day 90 and
day
100
to put us over the top.

If by this 50% duration point we'd planned to do 25% of the total
work
(and
it can easily happen that way) and we have really done 25%, we're on
schedule. If at this point we'd planned on doing 25% of the total
work
but
only have done 10%, we're behind schedule. If at this point we'd
planned to
do 25% of the total man-hours but have done 40%, we're ahead of
schedule.
But only looking at what % complete today's date represents doesn't
tell us
a thing about whether we're on schedule. Only looking at work
planned
versus work performed will tell us that - in other words, BWCS and
BCWP/ACWP.

If your statement about "PM maturity" means you're not tracking
resource
cost, use a rate of $1 per hour. Now the BCWS, BCWP, and ACWP
figures
will
stand for man-hours of work (even though they have a $ for their
units)
planned to date versus achieved to date and your S curves will be a
valid
indicator of progress.

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


"Pedro Caetano Barros"
<[email protected]>
wrote
in message
Sirs,

Our PM department have developed a process to generate S Curve of
Schedule,
based on Accumulated % Complete values. We used to generate this S
Curve
using MS Project 2000 and MS Excel 2000. Data used to generate the
curve
are
based ONLY on % complete progress, since the PM process maturity
does
not
allow us to generate S curves based on BCWP, BCWS and ACWP values.

Our organization now needs to update MS Project to 2003 version.
However,
MS
Project 2003 cannot generate % Complete and Accumulated % Complete
throughout
the entire project (it stops exactly in the very timescale point
you
have
two
tasks or two phases, for instance, simultaneously).

This problem can be easily noticed if you open "Task Usage" view,
adding
"Accumulated % Complete" in the timesheet section.

I would like to know how to solve this problem, a service pack or
add-in,
or
another procedure to obtain correctly Accumulated % Complete
values
to be
able to generate the Schedule S Curve properly.

Thank you for any help.

Regards,

Pedro Caetano Barros
MS EPM Suite 2003 Support Group
SÃffÃ,£o Paulo - SP
(e-mail address removed)
(e-mail address removed)