Divorce Acutal Costs from Most Calculations

[Jim Aksel]

I think many of us would like to see this.

It is very challenging to maintain proper Earned Value when Project
continuously adjusts work/remaining work/remaining costs, etc. by Actual
values. Even with allowing Project to Calculate Actuals field turned off,
this is still a problem. There are certain fields that use the Actual Cost
or Actual Work field in later calculations.

Example: A task is scheduled for 80 hours and 10 business days, fixed work,
baselined, worker gets paid $10/hr. On the status date, the worker says "I
am 25% complete, but it has taken me 30 hours to get this far." The problem
is that if I enter 25% complete into project, the Actual Work column changes
to 20 hours. This is incorrect ... his actual work is 30 hours. If I change
Actual work to 30 hours, the %Work Complete changes. Wrong. If I enter an
Actual Cost of $300, the CPI calculates correctly. However, I am being
mislead in that I am inferring that 20 hours of "real work" cost me $300. In
reality, I may have underbid the task and assumed the worker was more
efficeint than actual performance.

It is my opinion that I should be able to take "time card data" or "actuals"
from a separate accounting system and send these to Actual Work/Actual Cost
and have things calculate correctly. Otherwise, I am leaving it up to my
worker to say... "Well, I am 25% complete but I have only been working x% as
effectively as my bid so my ACWP is $300 or 30 hours"

I feel I need a better match between Actual Work and Actual Cost. Actual
Work (to me, time card values) has very little to do with the Work
Completed... work completed is BCWP and it has nothing to do with cost or a
time card entry.

So, please agree or educate me. Thanks

jim

I feel we need to be able to take "time card data" and enter it in to actual
work.

----------------
This post is a suggestion for Microsoft, and Microsoft responds to the
suggestions with the most votes. To vote for this suggestion, click the "I
Agree" button in the message pane. If you do not see the button, follow this
link to open the suggestion in the Microsoft Web-based Newsreader and then
click "I Agree" in the message pane.

http://www.microsoft.com/office/com...afa9-2dea60746828&dg=microsoft.public.project

 

[Rod Gill]

You are on the right line when you said "time card". I believe that to get
accurate earned value you have to update your assignments using hours per
day. So in one of the Usage views, add Actual work to the details and enter
Actual work ideally on a day by day basis. So in your example, the worker
would have 8 hours hopefully on the first day they started the task and so
on. Part of the recording of hours must include remaining hours. Update the
work values (extending duration as necessary). Again in your example, if you
are lucky, current actual hours is 20h and remaining=60h even though worker
has already taken 30h. Obviously if rest of tasks takes 50% more hours you
could be looking at 90h remaining.

Only by doing this do you get accurate earned value. You shouldn't have
fixed work either as work should and must change. Fixed unit is best. Turn

Obviously this is a lot of work. So for reliable, consistent EV calculations
you need a timesheet system that updates project files. Microsoft Project
Server or one of the time sheet systems that update project .mpp files or
databases.

 

[Jim Aksel]

I concurr with all of it... my key point is that the %Work Complete field
shall be divorced from Actual Work. It is certainly possibe that in my
example the worker "did the hard part first" or did it a "new way" that will
make the rest of the task easier (or harder for that matter). As such, I
need to be able to update Actual Work, and Remainging Work without regard to
%Work Complete. %Work Complete should refer only to baseline.

In my world, I cannot rebaseline just becuase the total work will be more
than I bid (assuming no scope creep). If I bid 100 hours to do the work,
then my max BCWP is the $value associated with those hours. What I need to
be able to do is (in this example) say... 80 hours baseline, 25% complete,
Actual Work is 30 hours and it will take me remaiing work 86 hours to finish
the job. The most EV I can get out of this is $800 (80 hours @$10/hr). In
my world, 25% complete refers only to 25% of baseline 80 hours. The fact
that is will take me 86+30 hours=116 applies to exactly one calculation: CPI.
In my case, at the end of the day... no matter what it cost, there was
only 80 hours of work done. If I have a Fixed Price contract, that is all I
can claim to my customer.

 

[Rod Gill]

You are trying to force two incompatible systems to work at the same time.
You cannot have earned value which requires that you show real actual
progress and then limit it to a fixed number of hours. You can over-write
the final actual cost with a fixed cost, but why bother on a fixed price
contract?

You cannot get accurate earned value from Project by updating % complete or
% work complete without major editing of remaining work etc.

I would track Project correctly with earned value, but this is probably only
worthwhile if you use a time sheet system, and use the result for internal
purposes. The customer will get what you charge so there is no need to show
the customer what the work actually costs you. Earned value is therefore for
internal use only.

 

[Jim Aksel]

I believe ANSI 748, and AS4817 support my position. EV can only be taken
against a baseline. I am not allowed to increase baseline or BAC just
because it will take more work to do the job than I baselined. I cannot take
EV against the "added work" it would lead to claiming more EV than planned
work.

Certainly the added effort increased my EAC, but it is not allowed to
increase my BAC. My EAC increases because ACWP increased, not the amount of
work I am allowed to claim for EV. When EV is 100%, it is BAC, not EAC.

My assertion still remains -- we have to divorce %Work Complete & Actual
Work. %Work Complete is EV, Actual work is ACWP. Can anyone show me where
this assertion is wrong?

 

[Rod Gill]

% Work complete, is and can only be, Actual Work / Work. That's built into
Project and will never be changed. So % Work complete is not EV. Actual Work
is not ACWP. ACWP is Actual COST of Work Performed.

 

[St Dilbert]

Short version: I agree.

Long version: with the default settings MSP keeps a hard link between
accomplishment and cost for that accomplishment. In earned value
acronyms BCWP and ACWP, while those are in reality completely separate
dimensions. In MSP's help texts on the different % complete fields it
basically says something to the effect that one could use "physical %
complete" and set some options to chose this "different earned value
method". This sounds like quite a euphemism to me: what is described in
connection with "physical % complete" is earned value as documented
e.g. in ANSI748 standard and the default setting is NOT earned value. I
imagine this was the reason to introduce "physical % complete" with
Project2003 in the first place.

The problem isn't completely solved, though: this real earned value
method is not yet fully integrated. e.g. you can't have the progress
lines in the tracking Gantt follow "physical % complete". The
visualization being one of the strong points of MSP it's hard to
convince people to use that relatively new field.
Around me it is preferred to switch off the "Actual costs are always
calculated by MSP" option and stick with %complete. As you said, this
isn't really a full separation of accomplishment and effort - there are
still some calculations linked and I'm trying to pull together a list
of side effects for our internal best practices. Since the help file
description for this calculation option basically says "this option
does what it says" and there would be no obvious reason to introduce
"physical % complete" there might be some deep design issues preventing
a successful implementation of the suggestion.

An alternative route might be to make the "physical % complete" fully
available for the graphical views and not just the calculation and
Excel export. Has there been any progress in this regard with Project
2007?

 

[Jim Aksel]

We've been debating Physical%Complete in the office for quite some time. I
concurr, one of the reasons we don't use it is because it does not show up
visually and there is no change in MSP2007.

Continuing with my "rant" ... Our office discussions have come to a
position that "Actual Work" column represents "Earned Work" since it is
drives (or is driven by) the %Work Complete field. It seems to represent the
hours of value that have been earned against the work. As such it is not a
"Time Card" type field.

I think we need a "Time Card Hours" type field that is used to drive ACWP
and Actual Cost columns. This would leave the Actual Work column as
implemented.

I certainly hope someone from the MSP2007 team is watching this and can
perhaps illuminate this better for us. Anyone know how to send comments to
that team as part of the Beta?

 

[Steve House]

It might not be quite accurate but I like to the think of ACWP as meaning
"actual amount of sweat required to achieve the required output" while BCWP
is the "expected amount of sweat required to achieve the required output."
Neither is a measure of time. If I have a task to build 100 widgets that is
expected to take 40 man-hours to complete and it actually takes 60, @ $1/hr
the budgeted cost of the 100 widgets is $40 and the actual cost of the 100
widgets is $60.

When entering data you can turn off the check box in the options "Updating
task status updates resource status" to disconnect the entry of % complete
from % work complete.

 

[St Dilbert]

"sweat" being a well chosen synonym for "cost" those are accurate
definitions. Just as "time card type" is in my opinion really closer to
cost than time: both submitter and receiver associate timesheets more
with euros/dollars/etc. than with hours or minutes - maybe I'm just
surrounded with greedy people... ;-)

So in summing up this thread so far:

1) When you're interested in modeling the real world with MS Project,
accomplishment (output) should be measured and stored seperately from
effort (sweat).

2) In order to enable this, you should DESELECT both
tools/options/calculation:"updating task status updates resource
status" and "actual costs are always calculated by Microsoft Office
Project"

3) when you query project's help files for "earned value" it will not
mention those options but lead you to the bolted one (less than fully
integrated) "physical % complete field"

4) All those seemingly familiar earned value fields (ACWP, BCWP, BCWS,
SPI, CPI...) are (by default) connected with "%complete" with both
calculation options mentioned above by default selected - this is the
worst possible default combination when trying to do earned value.

5) If anyone ever during the lifetime of the project file selects the
calculation options and performs a recalculation (F9 or automatic), the
link between output and sweat is restored for all activities in
progress (i.e. with actual work >0 and % complete <100%); read: one of
the two seperately entered measures is overuled by calculation and
deselecting the options again doesn't restore (of course...)

6) "sweat and output are different" is intuitive enough and a core
tenent of the earned value concept and incredibly valuable for managing
a project. It's EASY to convey this to PMs in my organization, if they
don't hold this to be self-evident in the first place. I have a really
hard time explaining the steps necessary to make this concept work in
the project management tool MS Project. In my opinion the application
design is really screwed in this regard. I'm disappointed to hear that
Project 2007 didn't improve on this.

It might not be quite accurate but I like to the think of ACWP as meaning
"actual amount of sweat required to achieve the required output" while BCWP
is the "expected amount of sweat required to achieve the required output."
Neither is a measure of time. If I have a task to build 100 widgets that is
expected to take 40 man-hours to complete and it actually takes 60, @ $1/hr
the budgeted cost of the 100 widgets is $40 and the actual cost of the 100
widgets is $60.

When entering data you can turn off the check box in the options "Updating
task status updates resource status" to disconnect the entry of % complete
from % work complete.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

We've been debating Physical%Complete in the office for quite some time.
I
concurr, one of the reasons we don't use it is because it does not show up
visually and there is no change in MSP2007.

Continuing with my "rant" ... Our office discussions have come to a
position that "Actual Work" column represents "Earned Work" since it is
drives (or is driven by) the %Work Complete field. It seems to represent
the
hours of value that have been earned against the work. As such it is not
a
"Time Card" type field.

I think we need a "Time Card Hours" type field that is used to drive ACWP
and Actual Cost columns. This would leave the Actual Work column as
implemented.

I certainly hope someone from the MSP2007 team is watching this and can
perhaps illuminate this better for us. Anyone know how to send comments
to
that team as part of the Beta?