Correct Use of %Complete with BCWS

[Jim Aksel]

Just wanted to confirm a few things with my peers here online.

We've been having somewhat a heated discussion at the office regarding the
transfer of %Complete (in some form) between MS Project files and our Earned
Value System (Deltek COBRA).

Of course, most want to use %Complete which is not correct. This is a
Duration Based measure of %Complete and is meaningless to our Earned Value
system. When we tell our customer we are 25% Complete it means BCWP=25% of
it's max value (EAC). It is expressed in dollars. There is no room what so
ever for interpretation.

Using (duration) %Complete does not get us what we want. If a task extends
in duration then %Complete regresses and thsi is not allowable. Further,
even if we force %Complete to remain the same be rekeyng it, this degrades
SPI and CPI in COBRA. That is if we hold %Complete constant, then BCWP does
not change when %Complete is imported to COBRA. However, both ACWP and BCWS
do increase in COBRA from the prior month. This means both CPI and SPI
degrade and I cannot even guarantee the direction of SPI change is in the
correct direction (although usually it will be down).

%Work Complete is also not going to give us a correct answer because BCWP
does not depend solely on hours worked. If I have a two parallel tasks and
one resource assigned to each one at different work rates, I could be 50%
complete on work if the cheap resource finishes their task completely and the
expensive guy does nothing on his. If am not 50% earned at this point even
though 50% of the work hours are expended.

My position is the only real way to do this is to use Physical%Complete,
resource load the Project schedule using proper work rates and use
Physical%COmplete to measure against my established baseline. This means
BCWP in Project will match BCWP in COBRA.

The real issue is we take EV in COBRA against work packages defined in MS
Project. The %Complete in MS Project will be incorrect at the summary task
levels (this is the work packages) unless we use Physical%Complete, a
costed/resource loaded baselne. Recall my definition of %Complete as used by
our customer: %Complete is the fractional value of BCWS at complete that I
have earned. It has nothing to do with work or duration.

So - have any of you experienced something similar and what did you do about
it?

 

[Rod Gill]

My understanding is that any form of % complete on its own is inaccurate.
Accurate EVA requires accurate scheduling of resources and other costs,
saving a baseline then updating progress by entering actual work on a daily
(ideally) or weekly basis and updating remaining work each time. Anything
else is a compromise and causes inaccuracies.

Entering actual hours worked each day defines task start and actual hours
worked. Remaining work updates defines updated total work and how long the
task will take (duration).

--

Rod Gill
Microsoft MVP for Project

Author of the only book on Project VBA, see:
http://www.projectvbabook.com

 

[John]

Just wanted to confirm a few things with my peers here online.

We've been having somewhat a heated discussion at the office regarding the
transfer of %Complete (in some form) between MS Project files and our Earned
Value System (Deltek COBRA).

Of course, most want to use %Complete which is not correct. This is a
Duration Based measure of %Complete and is meaningless to our Earned Value
system. When we tell our customer we are 25% Complete it means BCWP=25% of
it's max value (EAC). It is expressed in dollars. There is no room what so
ever for interpretation.

Using (duration) %Complete does not get us what we want. If a task extends
in duration then %Complete regresses and thsi is not allowable. Further,
even if we force %Complete to remain the same be rekeyng it, this degrades
SPI and CPI in COBRA. That is if we hold %Complete constant, then BCWP does
not change when %Complete is imported to COBRA. However, both ACWP and BCWS
do increase in COBRA from the prior month. This means both CPI and SPI
degrade and I cannot even guarantee the direction of SPI change is in the
correct direction (although usually it will be down).

%Work Complete is also not going to give us a correct answer because BCWP
does not depend solely on hours worked. If I have a two parallel tasks and
one resource assigned to each one at different work rates, I could be 50%
complete on work if the cheap resource finishes their task completely and the
expensive guy does nothing on his. If am not 50% earned at this point even
though 50% of the work hours are expended.

My position is the only real way to do this is to use Physical%Complete,
resource load the Project schedule using proper work rates and use
Physical%COmplete to measure against my established baseline. This means
BCWP in Project will match BCWP in COBRA.

The real issue is we take EV in COBRA against work packages defined in MS
Project. The %Complete in MS Project will be incorrect at the summary task
levels (this is the work packages) unless we use Physical%Complete, a
costed/resource loaded baselne. Recall my definition of %Complete as used by
our customer: %Complete is the fractional value of BCWS at complete that I
have earned. It has nothing to do with work or duration.

So - have any of you experienced something similar and what did you do about
it?

Jim,
A few years ago I wrote a macro for a client that exports accounting
month data from Project to Excel. A year later the client adopted COBRA
and needed to export Project data to a text file that was readable by
COBRA. There was never a requirement to use %Complete, because like Rod
says, %Complete is not a good measure of progress in an earned value
environment. In my client's case, they wanted Work and Baseline Work
along with start, finish and resource data.

I didn't get in to the details of how the client updates progress in
their project plans but they very likely could be using a process
similar to what Rod suggests.

John
Project MVP