EVM without Costs?

D

DonL

Has anyone successfully implemented a "quasi"-EVM for tracking schedule (SPI)
only? I am working on a "special program" and not intending to resource-load
my project plans. We do not have resource pools (in MSP), and generally have
to rely on the resources providing an estimate date for completion of their
tasks. I cannot count on the resources being allocated 100%.

I am looking for possibly a "dumbed-down" earned value method that will work
so that I can institute a "Business Intelligence" dashboard that can have
succsinct parameters (e.g., SPI, baseline durations, EV & Control graphs,
others?...), and also be able to provide basic controls for the program I am
on. I am currently thinking of inputting only durations in the Duration
field, a cost per task in $s equal to the duration days, and then baselining.

Thank you in advance for any suggestions or help that you can offer.
 
J

John

DonL said:
Has anyone successfully implemented a "quasi"-EVM for tracking schedule (SPI)
only? I am working on a "special program" and not intending to resource-load
my project plans. We do not have resource pools (in MSP), and generally have
to rely on the resources providing an estimate date for completion of their
tasks. I cannot count on the resources being allocated 100%.

I am looking for possibly a "dumbed-down" earned value method that will work
so that I can institute a "Business Intelligence" dashboard that can have
succsinct parameters (e.g., SPI, baseline durations, EV & Control graphs,
others?...), and also be able to provide basic controls for the program I am
on. I am currently thinking of inputting only durations in the Duration
field, a cost per task in $s equal to the duration days, and then baselining.

Thank you in advance for any suggestions or help that you can offer.

Don,
I'm going to take a departure here, (and potentially rile the ire of
several people), and say that the classical SPI measurement method is
bogus from the get go. In my opinion schedule performance does NOT
always relate to money, but that is how the classical method defines
SPI. I believe a much better method of measuring schedule performance is
to track task completion progress toward an end goal irrespective of the
dollars spent - that's the reason for CPI - to track cost.

Some years ago I wrote a treatise on this subject. It includes an
alternate method for measuring schedule performance in terms of Total
Slack. If you (or anybody else) is interested in reading what I wrote,
contact me direct and I will send it to you.

John
Project MVP
 
S

Steve House [Project MVP]

I'd agree that SPI is not really about money but that doesn't mean it's
bogus. I see the monetary aspect of it as merely establishing a common,
convenient unit of measure - regardless of whatever units you choose to
track, the index is a ratio and whatever unit you choose is canceled out in
the calculation. It's simply a way of tracking the ratio of man-hours
scheduled with man-hours performed. If you used hours for schedule
performance calculations and currency for cost performance, you'd double the
number of data fields you'd need to worry about in the baseline. Since the
resource rate establishes an identity relationship between scheduled
man-hours and scheduled cost, and actual man-hours and actual cost, one can
use currency as a common measure and simplify the reporting process. It
also simplifys extrapolating the "S" curves to determine Estimated
Completion Date and Estimated Cost at Completion.

Tracking duration doesn't cut it because it doesn't take into account the
effort required versus the effort expended. Time is only coincidental to
progress - the real measure is how much useful outpout is required versus
how much has output been achieved. True, output is generated at a rate that
associates it with the passage of time but the reason for doing the project
is not to pass the time, it is to generate the output. Measuring time
doesn't seem like its measuring anything of signifigance in terms of whether
you've gotten any benefits for your efforts.

Not that you said otherwise, but I'd interject the least reliable method of
tracking progress is % Physical Complete because it's such a loosy-goosy
notion. If one is designing an engine, just exactly what objective measure
constitutes "50%"? Half the drawings done? The engine block but still
working on the cylinder head? Fuels system done but still working on the
cooling and electricals? Front half done but still working on the back
half? I just can't wrap my head around why so many people want to use it
since except in very rare circumstances it's something virtually impossible
to measure.
 
J

John

I'd agree that SPI is not really about money but that doesn't mean it's
bogus. I see the monetary aspect of it as merely establishing a common,
convenient unit of measure - regardless of whatever units you choose to
track, the index is a ratio and whatever unit you choose is canceled out in
the calculation. It's simply a way of tracking the ratio of man-hours
scheduled with man-hours performed. If you used hours for schedule
performance calculations and currency for cost performance, you'd double the
number of data fields you'd need to worry about in the baseline. Since the
resource rate establishes an identity relationship between scheduled
man-hours and scheduled cost, and actual man-hours and actual cost, one can
use currency as a common measure and simplify the reporting process. It
also simplifys extrapolating the "S" curves to determine Estimated
Completion Date and Estimated Cost at Completion.

Tracking duration doesn't cut it because it doesn't take into account the
effort required versus the effort expended. Time is only coincidental to
progress - the real measure is how much useful outpout is required versus
how much has output been achieved. True, output is generated at a rate that
associates it with the passage of time but the reason for doing the project
is not to pass the time, it is to generate the output. Measuring time
doesn't seem like its measuring anything of signifigance in terms of whether
you've gotten any benefits for your efforts.

Not that you said otherwise, but I'd interject the least reliable method of
tracking progress is % Physical Complete because it's such a loosy-goosy
notion. If one is designing an engine, just exactly what objective measure
constitutes "50%"? Half the drawings done? The engine block but still
working on the cylinder head? Fuels system done but still working on the
cooling and electricals? Front half done but still working on the back
half? I just can't wrap my head around why so many people want to use it
since except in very rare circumstances it's something virtually impossible
to measure.

Steve,
In my way of thinking schedule and effort are separate entities.
Certainly one can argue that the time to do a task (duration) is
worthless without a resource to accomplish the task (effort) - perhaps.
I certainly agree that SPI in and of itself is not bogus. After all, SPI
is simply a dimensionless ratio. Where I depart is buying into the
process of using work/cost to measure schedule performance. I contend
that duration is relevant to schedule, effort is relevant to efficiency
and cost is relevant to budget. For example, based on history or
educated knowledge I know it takes a certain amount of time to do a
particular task. Resources are applied to that task to actually perform
it and money is allocated (budget) to pay for its completion. In my
mind, a unbiased assessment of completion compared to an end goal
requirement should determine how well the schedule is going. On the
other hand, the amount of effort expended compared to the original
estimate relates to how efficient the task is being worked. Finally, the
money spent relates to how effectively money is being spent. The first
metric should be SPI, the second metric should be EFI (a new term
representing resource efficiency) and the third metric is the standard
CPI. Off the wall thinking - perhaps - but then the original poster did
mention that he wanted some type of SPI measurement that didn't rely on
resource effort.

I agree that the passage of time is not a measure of accomplishing
anything, except in the case of level-of-effort type tasks. Rather I
believe schedule performance is best measured by comparing percent
complete to Total Slack against an end goal (e.g. final project
milestone). Thus the simple passage of time doesn't buy anything (except
a very bad SPI value) because tasks are not being completed in time to
meet the end goal. It doesn't matter how much effort is applied or when
the task was baselined, if the Total Slack is maintained (or increased),
the project is getting performed on time (i.e. favorable SPI). The
efficiency may be lousy and the cost prohibitive, but schedule wise, it
is in good shape.

I don't really have any feelings about % Physical Complete because I've
never studied it or used it. However, from what I have read it seems to
be a positive step in better defining "completion" in some cases. You
mention that % Physical Complete is "loosy-goosy" and virtually
impossible to measure. Measurable metrics are fantastic if they
represent valid data and can be developed at all. However in my
experience meaningful measurable metrics are very hard to come by. More
than once I have seen measurable metrics that weren't worth the paper to
print them on but somehow they were "sold" to the powers that be and are
being used to measure something. Sometimes the best and only valid
assessment is provided by a seasoned individual with tons of experience
and no "axe to grind". Granted, those people are hard to find.

No, I don't have all the answers. It's just that with regard to
calculating SPI, I think there is a better method.

John
Project MVP
 
D

DonL

Jack, John and Steve,

Thank you all for your input! I am happy to hear the different points of
view that have been expressed.

John,

I sent you an email, as I would appreciate learning more regarding your Task
Completion/Slack-based method.

Thanks again!
 
R

Ranjana Mehta

With reference to Steve's comments on physical % complete:
I am using physical % complete for Earned Value implementation at my
company. I find it to be a better asset than % complete because unlike %
complete, it is an independant entity. The % complete is known for skewing
work hours and costs thereon; a traditional outlook towards project
management. For e.g. a task budgeted at 10 hrs would show 50% complete if 5
hrs have been utilized. These 5 hrs underlines 100% work efficiency that
could/could not be true. On the other hand, physical % complete, though
subjective, does not affect the "earned value", as it is based on the
performer's experience of a task's completion. % complete negates the whole
basis behind earned value (in Microsoft Project).
 
Y

YLE

Hi John,

I just came across your answer and feel that you are the person to ask. I am
trying to implement "earned hrs method". I would like to use hrs insted of $
in EV formulas. The problem I have is to update actual hrs spent without
affecting the remaining task duration, budget and forcast. Like:
5d task, 8hr/day effort, 100$
 
Y

YLE

Hi John,

I just came across your answer and feel that you are the person to ask. I am
trying to implement "earned hrs method". I would like to use hrs insted of $
in EV formulas. The problem I have is to update actual hrs spent without
affecting the remaining task duration, budget and forcast. Like:
5d task, 8hr/day effort, 100$/hr cost - this is BL. Now I spent 16 hrs
effort in the first day to produce planned 8 hrs of work. How can I do this
in MSP. every time I put 16 hrs remaining changed. I want to track effort
efficiency same as $ efficiency in EV.
So far I can have hrs planed and hrs spent. How can I get hrs earned.

Thanks,

Yakov
 
D

deluth

Hello John,

I agree with your descriptions and am looking for the calculation exactly as
you described here. Unfortunately, my email to you "(e-mail address removed)",
had bounced multiple times. Please let me know how I can contact you.


TDeluth
 
J

John

deluth said:
Hello John,

I agree with your descriptions and am looking for the calculation exactly as
you described here. Unfortunately, my email to you "(e-mail address removed)",
had bounced multiple times. Please let me know how I can contact you.


TDeluth
TDeluth,
Wow, that's a pretty old post you dug up. I don't show my real e-mail to
thwart spammers. My decoded address is below.

What I have is more of a description of a method for calculating SPI.
The "treatise" was a larger proprietary document that covered other
subjects. However, if you are interested, I can send you the method
description part.

John
Project MVP
jensenljatatfastmaildotdotfm
(remove obvious redundancies)
 
D

DJ Huff

John,

I am right there with you on this. I don't like the way EV is calculated in
terms of schedule. As a matter of fact, a basic flaw is that it only tells
you whether you have burned up the hours at the rate is suggests (BCWP), not
whether the task is actually complete. Ex. If I have 40 hours to lay 5
bricks, and I enter 8 hours per day after each day, at the end of the week it
will say I am right on track, yet I may have laid only 4 bricks by that time.
I would then require more hours to complete, which would eventually be
reflected. But if I don't complete my task as I thought I would by the end
of 40 hours, I cna't plan ahead and make an adjustment. EV just says my burn
rate is on target, not that I haven't completed the task.

Anyway, I would be interested in your article.

EV in MSP is very frustrating, particularly with master plans that have
inserted plans. The BCWS zeroes out on the program level wiht no rhyme nor
reason, that I can figure. Also...can you tell me what the relationship is
between baselining a plan and EV? If I baseline a plan, it appears it will
calculate EV using information back to the beginning of the task rather than
to the baseline date, correct? So if I baseline again and the status dates
are the same, will it not still caalculate EV back to the beginning of the
task and not to the baseline1 date? Can't seem to find this in any book or
online help anywhere.

Thanks!
 
J

Jim Aksel [MVP]

Hi DJ
Sorry for the bump in. You can change your EV moethod to
"Physical%Compelte" and then you would count the bricks laid divided by the
baseline number of bricks to be laid. If you reached "Friday" with only 4
bricks laid you are 80% physical % complete. Your duration based % complete
would be 100% until you had to increase duration (causing duration based %
complete to regress).

I too have an article on this type of thing, check my blog
www.msprojectblog.com, select MS Project Tips/Tricks and look for some white
papers on percent complete, and "What % Complete Should I be?"

Jim Aksel, MVP
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top