%Work Complete vs. %Complete (Duration) in E.V. Calculations

[David Oliver]

It seems to me that there is a lot of tension between the
concept of duration and the concept of work in MSP. I
imagine that MSP was originally designed to work with
duration only and that work was an afterthought, which
has still never been fully integrated into the product.
MS, for example, allows you to enter and update duration
and % Complete through the Task Information and the
Update Tasks dialog box, but not Work & %WorkComplete!
And MSP uses % Complete to calculate earned value (SPI,
CPI) rather than %WorkComplete, which seems ludicrous. I
really expected that they would use % Work Complete for
this calculation, since earned value is all about WORK:
planned, burned and earned. And %Work Complete can be a
radically different value than the % Complete on projects
at any given point in time. WORK is cumulative (a real
sum) under the project summary task, whereas duration is
not!

As must be apparent, I've got some real frustration about
the way MSP deals with these concepts, so if you know of
any papers that elucidate this problem, I'd love to know
about them. It seems like the MSP team has been avoiding
or patching a problem when they really ought to
completely revamp their approach to statusing projects.
Why can't we enter actual work and remaining work through
the Update Task dbox, for example. Is it that MSP code
won't support it? Why not? Why do they keep asking
about remaining duration instead of remaining work?

I'd be glad to hear anyone's thoughts on the subject, as
well as to hear about any MS white papers or papers from
other sources that clarify what seems like a big problem
to me. I may be wrong, but I smell a rat buried in the
MSP woodwork. It may be that I just haven't grasped it
yet. Very possible. I'm interested in hearing other
ideas on this subject.

Sincerely,
Dave Oliver

 

[Steve House]

I think of it this way...the basic job of the PM is to bring the project in
on time and on budget. All projects are constrained into an Iron Triangle
of time, budget, and quality (or sometimes scope is used interchangeably
with quality.) Rarely is quality or scope a variable - if your project
requires you to pave a road from Here to There 100 km away you don't have
the option of stopping halfway to There. So the trade-off, the balance the
PM must achieve, is to find the optimum mix between time and money that
successfully achieves our business objectives.

You are mistaken about Project being ambiguous about work and duration - it
is very clear, as is formal PM theory. But many *users* on the other hand
habitually mix up the two concepts and find the temptation to interchange
them almost irresistable.

Duration deals with time - it will take us 6 weeks to complete the new
widget prototype. Work actually deals with the budget - I'll need 3
engineers at $1000 a week each and 4 technicians at $750 a week each. If
they work full-time I'm going to have to pay their full salary out of my
project budget. But if I only use them half of their work-day, I'll only
have to pick up part of their salary out of my budget - whoever it is that
uses them the rest of the day has to pick up the balance. That's
oversimplified of course. If I use 1 engineer full time for 10 days or
half-time for 20 days it'll cost me the same. OTOH, if I need to get the
100 widgets done in 8 days instead of 10 and I don't have another resource
available I may need to ask him to do overtime which does increase my cost.

Of course, the amount of their workday that I use them on my project also
determines how fast some/most of the tasks in my project will be completed.
If I need to make 100 widgets and 1 man working full-time can make 10
widgets a day, with one man it will take me 10 days. On the other hand, if
I only have him half a day, it will take him 20 days to make that same 100
widgets since he is now only making 5 a day (10 a day is his maximum output
and there's nothing I can do to ever get him to make more than that.) OTOH,
if I can find 10 widget assemblers, I can get all 100 widgets made in 1 day.

Duration is the time to completion. Work is the total output required.
Effort is the rate at which output is produced. In our road example, work
represents the total distance to be paved, effort is the km per day we can
lay pavement, and duration is the time it will take us to complete the road.

You are mistaken on that Earned Value is all about work. It deals with two
basic categories of metrics - schedule performance and budget performance.
Work/Cost is simply a common unit of measure.

SPI is about time - how many work days have we worked up to this date
compared to the number of days we had planned to work. Between the start of
the task and today we'd planned to do 15 days of work but because of a fire
we had to shut down for 5 days, our SPI is < 1 since our Budgeted Cost of
Work Scheduled is $1500, ie 3 weeks of duration was planned at $500/wk but
we've only actually worked 2 weeks and stood down the 3rd for 2 weeks
duration, or $1000 was spent. We're a week late

CPI is about budget - how much have we actually spent to date for the
man-hours of work we've been able to do versus how much did we plan we would
have to spend to get that same amount of work done. Unless you've had to
call in overtime or switch resources after the baseline or blown the
estimate on material cost, CPI will usually be real close to 1. But if I'd
planned to do 10 days of work to build 100 widgets but because my main
senior widget assembler was hit by a truck and instead of getting 10 a day
done I had to substitute 2 junior assemblers who can only do 5 a day each,
then my CPI will be > 1 because it's costing me more than I'd planned to
assemble the same 100 widgets. We're $XX over budget.

For more references I'd suggest reading the PMBOK from Project Management
Institute - MS Project is designed to comply very closely with it as far as
I can tell.

 

[Rod Gill]

Steve,

Great answer. One comment - I believe the iron triangle actually has another
axis: happy customer. A project that's late and over budget can still
produce a very happy customer and a project that's on time and budget can
produce an unhappy customer. The trick is in managing expectations and truck
loads of communication and collaboration to get the preferred mix.

--
For VBA posts, please use the public.project.developer group.
For any version of Project use public.project
For any version of Project Server use public. project.server

Rod Gill
Project MVP
For Microsoft Project companion projects, best practices and Project VBA
development services
visit www.projectlearning.com/

 

[Steve House]

Agreed whole heartedly. When I present the Triangle to classes I usually
also expand on the concept by dropping a line from the vertex down to the
base and labeling it "Confidence, 1/Risk" meaning that for a given length
of the quality side, the more time and money we have at our disposal the
greater the confidence we can have that we can bring the project in
successfully. Minimizing the time and budget sides means the confidence
shrinks and the risk of something going wrong goes up.
--
Steve House [MVP]
MS Project Trainer/Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

 

[Jeff]

Good info but like more clarification on the MS Project
formula used to calculate BCWP. The reference book
states that BCWP = (% Work Complete)*BCWS. This formula
seems to work in most cases. I get confused when trying
to follow how BCWP is calculated at the task level for
certain conditions. The first is when the Status Date is
before the Finish Date (Baseline or Plan) - it seems the
max value MS Project will calculate for BCWP is based on
the maximum number of possible work hours for the time.
For example, I have have a task that is 20 days in
duration with a work effort of 160 hr and my status
period is 15 days into the task. Total baseline budget
for this task is $1,600. The BCWS = $1,200. It appears
the primary input driver for calulating BCWP is %
Complete. In this example if I enter a % Complete
between 0 and 75%, the BCWP will range from 0 to $1,200.
However, if I enter a %COmplete greater than 75%, BCWP
seems to not exceed $1,200. This seems to be related the
maximum possible hours a person can work (if constrained
to 100% or 8 hrs/day), which in this example = 120 hrs.
The calculation also seems hard to follow if I change the
planned work after the task has been baselined and > 0%.

I believe it's my lack of understanding the the business
rules behind the BCWP formula. Any help would be
appreciated.

Thanks

 

[Steve House]

Set up your task, 20 days, 1 resource, $10/hr standard rate and $15/hr OT
and assign him to the task. Save a baseline, then set the task to 75%
complete. Display the earned value table and set the status date at 5 days
into the task. BCWS and BCWP will be equal at $400. Set the status date to
10 days into it and the BCWS/BCWP are both equal at $800. etc. Remember
that both BCWS and BCWP are calculated froim the start of the task up to the
status date. Work scheduled AFTER the status date is ignored in the EV
calculation whether its been done or not. So at our status date 10 days
into the task and you've posted the task as 75% done, Project still behaves
as if it 50% done because it cannot be more than 50% complete AS OF the
status date - we cannot complete 15 days of duration during the 10 days
between task start and the status date. Od course we can do LESS than 10
days but it is impossible to do more.

Posting a % Complete also updates the resource status unless the connection
between the two is disabled in the options menu. W are looking at a 20 day
duration task. So if you have a task that is 20 days duration, 8 hours per
day, and you say we're 75% done, Project shows 15 days actual duration, 5
days remaining duration, AND ALSO 120 hours actual work and 40 hours
remaining work. If we didn't do 120 hours of work in those 15 days, we need
to manually edit the actual work values in the task usage view to correct
it. You've said our status date is 15 days into the task. Further, the
BCWP (which is calculated based on actual work) is correct for values up to
75% complete but caps out there if you post values greater than 75%. But
consider - our status date is 15 days into the task but 75% of 20 days is
also 15 days. It is physically impossible for us to work *more* than 15
days of duration in 15 days of the tasks duration, ie, it is impossible for
us to be more than 75% complete on the task at the 15 day status date unless
you have manually edited the actual work to exceed 120 hours. Take our
example and go to task usage view, display the Actual Work row (which at the
moment should be showing 8 hours per day for the first 3 weeks of the task -
75% complete) and edit the Actual Work for the first 4 days to 10 hours per
day. When you do, Project adjusts your duration from 20 days down to 19
days and increases % complete to 79%. BCWS is still $1200 but BCWP is now
$1263.15 (BAC*79%) and ACWP is $1280.
--
Steve House [MVP]
MS Project Trainer/Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

 

[David Oliver]

Hey Steve:
Thanks for answering and sorry it took so long for me to
read/respond to it. I was on vacation.

I got the feeling you were missing my point. I'm familiar
with spi and cpi and what they tell you about a project.
I'm also familiar with the difference between duration
and work. That is why I am concerned that MSP uses
duration rather than work as a measure when calculating
earned value.

Let's say you have a 1 task project baselined with 40
hours work over 5 days duration and 1 resource assigned
to that task. Let's say that the work is front loaded so
that the resource works 10 hours Monday thru Wed and 5
hours Thursday and Friday. If Wednesday is the status
date and work is done according to schedule, then the %
Complete will be 60%, but the %WorkComplete will be 75%.
Now, if MSP uses %Compl to calculate BCWP, we'd get a
different number than if MSP used %WorkCompl.

In my last posting I was saying that MSP uses %Complete
to calculate BCWP, because that is what the documentation
says: "BCWP = baseline cost * percent complete" quoted
from Microsoft Project 2002 Training Courseware Lesson
19: Earned Value. However, I just set up the above
scenario in MSP and found that MSP calculated the BCWP as
$30 ($1/hr. $40 * x = $30). X = .75, not .60. This
means that MSP actually uses %WorkComplete to calculate
BCWP. If MSP had used %Compl than you would have this:
$40 * .60 = $24 (BCWP). I'm surprised. MSP's
documentation seems to be wrong.

This still doesn't answer the question of why MSP asks
the user for actual and remaining duration rather than
actual and remaining work. As you said, "work" is the
measure used in earned value calculations. Niku
Workbench, for example, deals directly in work, not that
I enjoyed using that software in the least.

 

[Steve House]

You said it yourself - spi and cpi are the two earned value outputs.
Schedule Performance Index and Cost Performance Index. SPI refers to
schedule that you know is not the same thing as scheduled work, work is only
used as a standard unit of measure. Schedule progress is a function of
duration passed, time, not work. % complete is also a function of time, not
work. And that's why (at any rate I think that's why, I wasn't privy to the
design so this is only my educated guess) SPI uses duration % complete
rather than work % complete. We're not concerned with the amount of work,
we're concerned with how much calendar time has passed versus how much we
thought we'd have under our belt at a certain point, the status date.
--
Steve House [MVP]
MS Project Trainer/Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

 

[David Oliver]

"Jeff"
Where did you see the formula BCWP=(% Work Complete)*BCWS?
In the MS Project 2002 Training Courseware, it says that
BCWP = %Complete * BCWS. %Complete=%[Duration]Complete.
So I'm curious where you found a different formula. If
you see this post, please email me at david.oliver@acs-
inc.com. I don't come to this forum very often.
Thanks
Dave

-----Original Message-----
Good info but like more clarification on the MS Project
formula used to calculate BCWP. The reference book
states that BCWP = (% Work Complete)*BCWS. This formula
seems to work in most cases. I get confused when trying
to follow how BCWP is calculated at the task level for
certain conditions. The first is when the Status Date is
before the Finish Date (Baseline or Plan) - it seems the
max value MS Project will calculate for BCWP is based on
the maximum number of possible work hours for the time.
For example, I have have a task that is 20 days in
duration with a work effort of 160 hr and my status
period is 15 days into the task. Total baseline budget
for this task is $1,600. The BCWS = $1,200. It appears
the primary input driver for calulating BCWP is %
Complete. In this example if I enter a % Complete
between 0 and 75%, the BCWP will range from 0 to $1,200.
However, if I enter a %COmplete greater than 75%, BCWP
seems to not exceed $1,200. This seems to be related the
maximum possible hours a person can work (if constrained
to 100% or 8 hrs/day), which in this example = 120 hrs.
The calculation also seems hard to follow if I change the
planned work after the task has been baselined and > 0%.

I believe it's my lack of understanding the the business
rules behind the BCWP formula. Any help would be
appreciated.

Thanks




used time
and money that *users*
on the other hand