Re: Recording Completion when actual work is <> budgeted

Tech-Archive recommends: Fix windows errors by optimizing your registry

Project Management is primarily about Scope, Cost and Time.
It is more about the Tasks and the Durations first, and the Work (Hours) and
Cost follow from that.
Some estimating methods are "quantities based" rather than "Task based".
For example steel structures are often estimated as Hours/tonne, like yours.
This produces a budget for Hours and Costs but does not define the Tasks and
their Durations or any of the scheduling data.
You have still left out some essential information, the estimated Duration.
I can assume (can I?) 80 Hours means 100% of 1 person, 8 hours per day, 10
days.

A.
Status Date = end of Day 5
Planned/estimated/budget/baseline production rate = 8 pages per day
BCWP = 32 pages x $20/page = $640
BCWS = 40 pages x $20/page = $800
ACWP = $800 (you say 50% of Total)
CPI = BCWP/ACWP = 640/800 = 0.8, indicates that what is being achieved is
costing more than the estimate.
SPI = BCWP/BCWS = 640/800 = 0.8, you are behind schedule, ie not having
earned what was planned/estimated/hoped for, for up to the Status Date.
EAC = ACWP + (BAC - BCWP)/CPI
BAC = 80 pages total x $20 per page = $1600
EAC = 800 + (1600 - 640)/(0.8) = $2000
At $40/page Price, your total price would be $3200 and the profit $1600,
except that EAC says that if you carry on like this it will only be $1200.
Your estimated Cost/unit for pages was estimated to be $20 but turned out to
be 800/32 = $25.
Every page you do shaves $5 off your profit which was estimated at $20/page
(Marginal Pain Ratio = 25% (I made that up)).
The estimated production rate was 8 pages per day but in 5 days we achieved
32 pages or 6.4 pages per day.
You now have still to do what was planned (ie Tasks) to be done up to the
Status Date but wasn't, plus all Task which was planned to be done from the
Status Date to completion, by the same old planned completion date unless
you can extend the finish date.
If you are stuck with the same deadline, then achieving it this will be a
challenge if the evidence so far is that the project runs behind schedule
already.
Basically, you have 48 pages to go and if only 5 days to do them in then you
have to immediately get the production rate up to an average 9.6 pages per
day.
If the production rate can be held to the observed 6.4 pages per day then
you need 48/6.4 = 7.5 days, or 2.5 more.
Measure the up to date performance and then re-plan the remaining Duration,
Work, Cost, which amounts to revising your earlier estimates (they were
wrong, performance is what it is, a fact, neither efficient or inefficient).
The great thing about a half time review is that you get to have another go
at the plan for what remains.
Having extracted the necessary data from the past, ignore the past and move
on.

When this project started the CPI and SPI were both 1, but have declined by
0.2 in 5 days. Even holding the CPI and SPI at an unhappy 0.8 for the next 5
days will require something special to be done. In another 5 days they might
follow this "trend" (not really enough data to call this a trend) and be at
0.6 both.

I'll leave the other examples for you. See below.



"J Augenstein" <jga57@xxxxxxxxxxx> wrote in message
news:6A4F3215-9828-4444-82E5-2B9FF70C6830@xxxxxxxxxxxxxxxx
>I think I left out some critical information on my original post. Here are
> all the facts. The task in question is to translate documents from one
> language in to another. For this task, I have bid 80 hours for 80 pages,
> price 40/page, cost is 20/page. I want the translator to record both time
> spent and pages complete because the 2 elements together determine how I
> am
> fairing on the task. So, at the end of week one if:

> A. 32 pages, 40 hours: Cost budget 50% consumed but only 40% of the
> actual
> work is complete.

Sorry, no. Your phrase "40% of the actual work is complete." is incorrect
twice.
40% of the Task (ie 40% of the pages) is complete.
Work is Hours.
The EV acronyms are imperfect in this way too. They should be BCTS, BCTS,
ACTP (substitute "Task" for "Work").
Also, you say "of the actual" work. It isn't "actual". The 40% is 40% of the
total estimated number of pages.
The total "Cost Budget" is $1600 so 50% consumed = $800, yes?

> B. 40 pages, 40 hours: Cost budget 50%, actual work 50%
CPI = 1
SPI = 1
OK

> B. 48 pages, 40 hours: Cost budget 50%, actual work 60%
CPI = 960/800 = 1.2
SPI = 960/800 = 1.2
ie you are getting more done than you estimated and you are paying less for
it than estimated, very OK.

> So what I am looking for is really a dual measurement: dollars and units
> for
> the same task at the same time and in a time-phased manner. In all of the
> above examples, If I look strictly at the cost side of the project, the
> project looks ok.

Define "OK".

Cost is the same, but when I compare that to actual output,
> in each example, the project has a slightly different outlook.
> I still need to capture the hours, and in fact when my translator submit
> time for the week, I capture the hours but I also ask for the pages.
> Is this better information?
> And thanks all for the submissions.
>
>
> "Trevor Rabey" wrote:
>
>> Steve says such nice things but I re-read my post and spotted some little
>> mistakes, typos and ommissions, including an arithmetic mistake, none of
>> which change the general idea.
>>
>> Here is the ever-so-slightly corrected version:
>>
>> Your problem lies not in the software settings but in the interpretation
>> of
>> the situation and your expectations ("What I want to see").
>>
>> I suggest we avoid saying that you have "completed 50% of the work" since
>> Work = Man-Hours and it is confusing.
>> I suggest instead that we say you have completed 50% of the TASK, which
>> is
>> measured by, say, 500 bricks out of 1000 bricks.
>> Your Status Date is end of Day 5.
>> Planned Total Duration is 10 days.
>> (Every tracking problem should commence with this Status Date
>> information.)
>>
>> You have either been "efficient" or your Duration, Hours and Cost
>> estimates
>> were all just too generous.
>> It is tempting to take credit for "efficiency" but it is undue credit and
>> no
>> great cause for celebration if it is due to the estimating being way off
>> at
>> the start.
>> Of course, good news is good news and it is still a pleasant surprise to
>> have your actuality turn out to be better than your estimates had led you
>> to
>> hope for or expect.
>> If it had gone the other way, which is more common, it would have been a
>> bad
>> surprise, mainly because you would then have a bigger problem to solve,
>> but
>> this would similarly not be a cause for despair and cannot necessarily be
>> called "inefficiency" since, again, it may just be down to sloppy
>> estimating.
>>
>> The estimate was the estimate, the actuality is the facts. They differ,
>> always. There will always be overs and unders budget for the Tasks, their
>> Duration, Cost and their Hours, and really anything associated with the
>> Tasks may turn out different.
>> There may be additional Tasks which arise during execution, which consume
>> Resources but do not (yet) appear in the plan.
>> There may be Tasks done out of sequence, not in accordance with the
>> predecessor relationships.
>> New predecessor relationships may have been encountered which were not
>> previously anticipated.
>> Compared to the last three, which are serious, mere perturbations in
>> Duration, Cost and Hours are trivial.
>> The differences between the plan and actuality must be minimised by
>> thorough
>> estimating to start with and tight execution in working to the plan in
>> order
>> for EV or any progress reporting to make sense.
>>
>> Actual Hours up to the status date = 30
>> Actual Cost of those Hours = $20/Hour x 30 Hours = $600
>>
>> Assume, for the moment, no other Costs in this case but really there will
>> be
>> nearly always
>> Material Costs such as $1/brick for the 500 bricks = $500, and there may
>> be
>> Fixed Costs attached to the Task (independent of any Resource Assignments
>> and Resource Costs).
>>
>> Assume, since you do not say, that Actual Start Date = Planned Start
>> Date,
>> but it could have been otherwise in either direction, and usually is
>> since
>> actuality never matches as-planned, as we know.
>> Again, along with the Status Date and Total planned Duration, this is
>> essential starting point information for this exercise.
>> Sometimes, people try to track progress without being able to collect
>> accurate, contemporaneous actuals data, due to some deficiency in the
>> overall management system, which is futile.
>>
>> When filling in the Tracking fields it is always better to put in the
>> data
>> and let MSP calculate the %s.
>> % anything should always be calculated rather than input.
>>
>> You say "what I would like to see...Work Complete 50%", this is where
>> your
>> mistake is. This is not what you would like to see at all.
>> % Work Complete is 30 Hours actual out of 80 planned = (3/8) x (100/1) =
>> 37.5%
>>
>> Checklist for tracking, updating and re-scheduling in MSP:
>>
>> 1) Set a Status Date
>> 2) Set a Baseline
>> 3) Choose the Tracking Gantt View
>> 4) Choose the Tracking Table
>> 5) Show the Tracking Toolbar
>> 6) Format the gridlines in the Gantt Chart to show the Status Date as a
>> vertical line, a nice red one.
>> 7) Select the Task
>> 8) Input Actual Start Date (which should be one of the columns in the
>> Tracking Table which you have already chosen)
>> 9) Update as Scheduled with the Tracking Toolbar
>> 10) Input Actual Hours
>> 11) Input Actual Cost
>>
>> Now, all of the EV numbers tumble out.
>> Choose the Earned Value Table, make graphs, issue reports.
>> The Variances are Cost and Schedule Variances. The fact that Cost
>> Variance
>> arises from an Hours variance is immaterial. Sure you have saved Hours
>> but
>> this is really a good thing and of any interest only because it results
>> in
>> the saving of Costs.
>> Note that saving Hours, using less than expected, has not shortened the
>> estimated remaining duration and may not, by itself, always save Cost.
>> You might have planned to spend $50 per hour for guys who could do 50% of
>> the Task (500 bricks) in 40 Hours but you might have actually paid
>> $60/hour
>> or whatever for premium guys who only needed 30 Hours for 50% of the
>> Task.
>>
>> After you have calculated your EV numbers you are now faced with the
>> necessity of re-estimating the Remaining Duration, Remaining Work and
>> Remaining Cost.
>> While you're at it, you may want to modify any other part of the plan not
>> yet executed because it is all in the future, including predecessor
>> links,
>> lags, resource assignments, calendars and anything that I have not
>> listed.
>> This will result in a new plan for the remainder of the project from the
>> Status Date to completion.
>> Before you do this you should save the plan as it was when you finished
>> the
>> EV calculation.
>>
>> This new plan, the one which reflects your genuine intentions from the
>> Status Date, may not closely resemble the Baseline that you just measured
>> your EV with.
>> Next month when you measure EV, which Baseline will you use?
>> I suggest that you need to measure this coming month's performance
>> against
>> the plan you will try to work to for that month, ie this new one that you
>> just made.
>> If you measure performance against a Baseline such as the one that you
>> had
>> on Day 1, which may be months old and barely relevant, appropriate or
>> applicable, then most likely the result will be misleading at best and
>> very
>> disapointing performance-wise also.
>> But it doesn't have to be "either or". You can measure EV against the
>> original Baseline plan as well as against a more recent one (last
>> month's),
>> then try to interpret both stes of results.
>> But each "most current" baseline, the new one made each month, is only
>> good
>> for one month.
>>
>> If this Task is something like laying bricks, where bricks, Work and Cost
>> have all been initially estimated to be proportional to Duration, and
>> there
>> is every reason to expect this to remain so, then in this case there is
>> no
>> need to re-estimate the duration. ie you laid 500 bricks in 5 days so you
>> will expect to lay the remaining 500 bricks in 5 days more.
>> Many Tasks do not readily lend themselves to this kind of measurement. Be
>> very careful of "Task % complete" reports about these.
>>
>> Although individual Tasks might/should be very neatly proportional and
>> linear, the overall project is not, because Tasks overlap, hence the S
>> shaped Curves.
>> If individual Tasks are not neatly proportional and linear, chop them up
>> into smaller Tasks until linearity/proportionality is a reasonable
>> approximation.
>>
>> Since 1/2 of the Task was done in 30 Hours the original estimate
>> should have been 60 Hours and the Remaining Work should be 30 Hours
>> distributed over the 5 Remaining Days, and at 6 hours per day would be as
>> good as anything.
>> You can, of course declare the Remaining Duration estimate to be 3 Days
>> at 8
>> Hours each.
>> However, this would contradict what we already know about this Task, that
>> 50% of the Task takes 5 days Duration.
>> Avoid the temptation to shorten a Remaining Duration estimate unless you
>> know for sure you can achieve it.
>>
>> Of course, you are free to re-estimate the Remaining Duration, Remaining
>> Work and Remaining Cost to whatever you think they will be, for whatever
>> reason(s), regardless of the actual production data that you have
>> observed,
>> which is only one of the determinants of the re-estimate, although one
>> that
>> should not be ignored.
>> Once you have this new estimate to completion, you can save it as a new
>> Baseline and next month you can choose to compare you performance in that
>> period to either of both of your Baslines.
>>
>> This illustrative example, with bricks, comes out much more interesting
>> from
>> an updating, EV, re-planning perspective, if your 50% of bricks does not
>> correspond to your Status Date = 50% of planned Duration.
>>
>> Try Status Date = end of Day 6
>> Bricks = 500
>>
>> or
>>
>> Status Date = end of Day 6
>> Bricks = 700
>>
>> and others..
>>
>> Small note: EV is a score for that applicable period of the game and by
>> itself is not predictive. The prediction from the Status Date to project
>> completion, including the individual Task start and finish dates, Costs,
>> Hours etc are contained in the new plan for from now until project
>> completion. 3 straight months of bad EV numbers getting worse do not
>> indicate that next month's EV numbers will be even worse, although very
>> often it is so.
>>
>> Trevor
>>
>>
>>
>>
>>
>>
>> "Steve House [Project MVP]" <sjhouse.remove.this@xxxxxxxxxxxxxxxxxxx>
>> wrote
>> in message news:%23KdMOp5EGHA.1816@xxxxxxxxxxxxxxxxxxxxxxx
>> > Trevor has given you an excellent answer but if I could add a short and
>> > sweet version...
>> >
>> > You're asking Project to violate basic arithmetic in your example. 30
>> > hours work done and 40 hours work remaining totals 70 hours of work
>> > required overall to complete the task. 30 hours done out of 70 hours
>> > required is NOT 50% complete, it's 30/70 or ~43%.
>> >
>> > % Complete == duration worked versus duration required
>> > % Work Complete == man-hours worked versus total man-hours required
>> > % Physical Complete == number of widgets produced versus number of
>> > widgets
>> > required
>> >
>> >
>> > --
>> > Steve House [MVP]
>> > MS Project Trainer & Consultant
>> > Visit http://www.mvps.org/project/faqs.htm for the FAQs
>> >
>> >
>> > "J Augenstein" <J Augenstein@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
>> > message
>> > news:12EAAFB6-750B-470C-AE11-D50774F489E8@xxxxxxxxxxxxxxxx
>> >> Assume that I have a task that is has been budgeted for 80 hours by a
>> >> resource cost of 20/hr, resource is 100% assigned. Also assume task is
>> >> starting on Monday. At the end of the week, I record my time spent of
>> >> 30
>> >> hours, but being efficient, I completed 50% of the work. What I would
>> >> like to
>> >> see when looking at Assignment Information | Tracking is Actual Work =
>> >> 30h, %
>> >> Work Complete 50%, and Remaining Work 40h. Using the screen above, I
>> >> entered
>> >> AW 30h, %WC = 50%, but when I close, the %WC gets set to 38, and
>> >> Remaining
>> >> Work = 50h.
>> >> My goal is to have the Earned Values reflect the positive variance (in
>> >> this
>> >> case).
>> >> I am sure there are setup parameters that may help here but I'm not
>> >> aware
>> >> of
>> >> any that I am missing. Virtually all other settings are default values
>> >> if
>> >> that helps.
>> >> Thanks.
>> >
>>
>>
>>


.

Relevant Pages

  • Re: Recording Completion when actual work is <> budgeted
    ... Planned Total Duration is 10 days. ... You have either been "efficient" or your Duration, Hours and Cost estimates ... Resources but do not appear in the plan. ... When filling in the Tracking fields it is always better to put in the data ...
    (microsoft.public.project)
  • Re: Earned Value Calculation
    ... link in the options page and post duration and work progress completely ... >> Your formulas appear to be using totals, ... >> work the estimated cost and baseline cost of that task are equal and are>> rate*estimated work. ... >> BCWP is not rate*estimated work*%complete nor is the formula for ACWP>> accurate either. ...
    (microsoft.public.project)
  • Re: % Completed vs. % Estimated
    ... expect to be able to have a planned rate per day for Duration, ... and direct labour Cost and Bricks. ... the construction industry it is common contractual practice for a contractor ...
    (microsoft.public.project)
  • Catch-All Task to capture remaining work performed
    ... project plan, using MS-Project. ... and yet I must shoulder 100% of the cost for ... and it has a fixed duration of 14 weeks. ...
    (microsoft.public.project)
  • Re: Recording Completion when actual work is <> budgeted
    ... measured by, say, 500 bricks out of 1000 bricks. ... Planned Total Duration is 10 days. ... Cost and their Hours. ... When filling in the Tracking fields it is always better to put in the data ...
    (microsoft.public.project)