EV Physical%Complete nonsense

[paul]

After searching through the archives for information about %physical
complete, clearly it is an attempt to get around the situation that a
metric based on duration (%Complete) is not always (seldom?) desirable
for earned value calculations. What boggles me is that it seems that
%WorkComplete is the natural choice, but apparently MS disagrees.

Using a painting example by S. House, where the first four days of
work was scheduled for 1 hr/day, with 8 hrs work on day 5.
Duration=5d, Work=12h. At the end of day 4, %WorkComplete=33% and
%Complete=80%. In this situation, it's misleading to take credit
(i.e., the earned value) for 80% of the total cost, but 33% seems
reasonable.

Yet, MS put in this manually entered field of Physical%Complete, which
makes little sense to me. The bricklaying example, with each
successive row requiring more time, clearly illustrates that although
50% of the bricks are laid, more than half of the work and time
remain. Using 50% for the earned value is just silly in this case to
quantify progress against schedule and cost.

So, in the vast majority of cases, IMHO, EV should be based on
%WorkComplete. This is not an option in P2003; has it changed in
P2007? Attempts at using a formula to redefine Physical%Complete have
failed. Is there any way to enable EV calculations within MSP based
on %WorkComplete? Am I off base in my thinking that MS completely
missed the boat on this one?

(The only problem I see is that %WorkComplete can decrease, as
estimates of remaining work are refined. Logically it makes sense to
have less EV then, but it may cause issues when interfacing to
external programs that expect EV to not decrease.)

 

[Jim Aksel]

Food for thought. Yes, many items really do boil down to manhours assigned
to the job, even brick laying. However, it depends on how you are taking
your EV and the cost of the resources. If it is "by Brick" then matters can
(and do) change. Someone may bid a job "by Brick" meaning he makes most of
his profit first, becuae his efficeincy slows as the scaffolding rises.

As for %WorkComplete, it is essentially a subset of %Complete and these two
fields couple in Project2003 & 2007 as long as Tools/Options/Calcuations
(tab) "Updating task status updates resource status" remains checked.
Uncheck the box and they decouple. Hit the help on that for additional
information.

Now something near and dear to my heart. I think you may have missed
something in your analysis, resource costs. Let's assume 2 tasks, five days
each, linked FS. The first task is assigned "Fred" at $25/hr" and the second
task is assigned to Mr. Beasly at $400/hr. The cost of this program is
40(25)+40(400)= $17000. At the end of day 5, we are 50% work complete, using
Physical%Complete, we can only claim 1000/17000 = 6% complete. If the
contract were terminated at day 5, I would only pay you $1000. My reasoning
is that Mr. Beasly adds more value to the program for the work he does.

The advantage to Physical%Complete is that it weights by costs, not work,
not duration.

It all depends on what you are counting. If it is duration%, then you need
to divide two durations. If it is %WorkComplete, you need to divide two
values of work. You already discussed how this can regress either duration
or work %Complete -- this is truly a problem. Physical%Complete allows you
to count anything you want.

IMHO, the best way to go is Physcial%Complete. To be honest, if you load
the resources all at the same work rate (nominally $1/hr) then you have no
difference between the calculated values of %Work and Physical%. However,
you will never regress Physical%Complete.

I am working on a white paper since I have some serious rants on this topic.
Please keep your eye on my website becuase it will (eventually) be posted.
If you care to drop me an e-mail from the site, I hope I will remember and
send you a copy once it is available. I want to have my peers take a good
hard look at it prior to posting.
--
If this post was helpful, please consider rating it.

Jim Aksel, MVP

Check out my blog for more information:
http://www.msprojectblog.com

 

[paul]

Respectfully, I don't think I missed much with regard to the resource
costs. With your example after 1 week:
EV takes "credit" for some part of the PLANNED amount on a task
basis. The resource costs are, in fact, in that plan. At the status
date, the %WorkComplete for this task is 100%. Thus, the EV of the
first task at the status date is a very fair $1000. (EV for the
entire program is also fair at $1000, since the second task's EV=0.)
I agree that it would be silly to use the rollup of %WorkComplete and
try to milk 50% of the total program value!

Another consideration you might mention (since you're writing the
paper), is that tasks without work (e.g., delay for permit approval)
don't count toward EV. If you want "credit" for this type of task,
you will have to gin up a material or fixed-cost resource for that
task. There's no other way to convey the cost information to MSP. I
think businesses that would employ this sort of billing system (e.g.,
construction payment at initial signing, foundation, framing, and
walkthrough) would keep such billing outside the EV system. EV (if it
was even used), would be strictly an internal measurement.

It now occurs to me that my original question was in terms of earned
value. Your answer is quite a bit more applicable (and my desire to
use %WorkComplete very not applicable, as you point out) if you're not
using that framework.

Paul

 

[Jim Aksel]

Thanks for the feedback.
As for the "permit delay" We do not allow accrual of EV for such tasks. As
you said, no resources assigned either.

This raises another form of EV which would be milestones based. For
example, you could have all the tasks leading up to the Milestone "Permits
Issued." At the time the permit is issued (including its delay), the project
may be able to claim a certain (Phyiscal)%Complete.

In cases like this, we would normally assign a $ value to the milestone.
When that claims 100%, then we get that much EV. However, we should not be
assigning resources or values to milestones in MS Project.

Instead, we identify all tasks leading up to the milestone and declare these
tasks as "0-100) depending on the issue of "permits." [Actually I am in
Aerospace /DoD software development so forgive me...]. When the permits
get issued, we go back and claim 100% for all the contributory tasks. It
prodcues variances along the way, but they are explainable. That does bring
up a weakness in Project, it needs to support more types of EV for tasks.

Now I am back to work. Again, thanks for the comments and discussion ....
this is the type of questions I enjoy discussing online.
--
If this post was helpful, please consider rating it.

Jim Aksel, MVP

Check out my blog for more information:
http://www.msprojectblog.com

 

[Steve House [MVP]]

That's one reason EV is based on dollars budgeted and dollars spent. In the
instant example, updating the task to 80% complate will also update the work
to 33% complete since at least the default setting links the two so updating
the task updates the resource. If the painter gets $10 per hour, the
budgeted cost at completion is $120. When the task is 80% done according to
duration, the BCWS is $40 and the BCWP is also $40. Dollars are based on
work, not duration. The task is on schedule. Now imagine the task finishes
but it takes an extra day. BCWS = $120. BCWP = $120 ACWP = $200 Because
the extra 8 hours are not in the original budget, the BCWP does not include
the overage at task completion. It takes 20 hours of work to get 12 hours
of earned value.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://project.mvps.org/faqs.htm for the FAQs

...> <snip>
Using a painting example by S. House, where the first four days of
work was scheduled for 1 hr/day, with 8 hrs work on day 5.
Duration=5d, Work=12h. At the end of day 4, %WorkComplete=33% and
%Complete=80%. In this situation, it's misleading to take credit
(i.e., the earned value) for 80% of the total cost, but 33% seems
reasonable.

..

 

[Steve House [MVP]]

<snip>

The advantage to Physical%Complete is that it weights by costs, not work,
not duration.

It all depends on what you are counting. If it is duration%, then you
need
to divide two durations. If it is %WorkComplete, you need to divide two
values of work. You already discussed how this can regress either
duration
or work %Complete -- this is truly a problem. Physical%Complete allows
you
to count anything you want.

IMHO, the best way to go is Physcial%Complete. To be honest, if you load
the resources all at the same work rate (nominally $1/hr) then you have no
difference between the calculated values of %Work and Physical%. However,
you will never regress Physical%Complete.

But the big DISADVANTAGE is that it's so damned difficult to sensibly
estimate. If you're painting a wall or laying bricks it's reasonably
straightforward but suppose you're writing a program or designing an engine?
What's 50% physical complete really mean? Finished the crankcase but not
started the cylinder head? Got half the systems done? Half the drawings
done? Half the lines of code written,? Debugged? There's not really
anything that you can physically measure that says unambiguously "THIS, and
only this, defines being 50% physical complete." IMHO, in most cases you
can definitively measure duration and/or work but it's rare that you can
actually observe and measure real physical complete. It often devolves down
to the manager's subjective impressions rather than something real and
objective.

 

[paul]

Trevor writes:
Valuable time spent on crunching EV numbers can be at the expense of
real
productive time and effort being spent on real planning and
effective
execution.

Thus my original issue: EV with %duration is usually crap when
resources are not full-time on a task (which is typical), and Physical
%Complete forces manual entry, which is error prone and takes time
(cut & paste is about the best you can do; there is VB for the
initiated). I really wish that MS would allow the choice of
%WorkComplete in the EV calculation method dropdown -- it seems so
natural. The fact that no one has chimed in that, "You can do that in
P2007" sort of quells my hopes.

 

[Jim Aksel]

The same can be said for duration. "I think we need 5 more days to finish
the drawing of the crankshaft" is still a supervisor's estimate.
--
If this post was helpful, please consider rating it.

Jim Aksel, MVP

Check out my blog for more information:
http://www.msprojectblog.com