Re: Recording Completion when actual work is <> budgeted
- From: "Trevor Rabey" <trabey@xxxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 9 Jan 2006 15:15:37 +0800
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.
>
.
- References:
- Re: Recording Completion when actual work is <> budgeted
- From: Steve House [Project MVP]
- Re: Recording Completion when actual work is <> budgeted
- Prev by Date: Re: Is there a site where you can use MS Project online (for a fee)
- Next by Date: Re: Daily "to do" report
- Previous by thread: Re: Recording Completion when actual work is <> budgeted
- Next by thread: Re: Recording Completion when actual work is <> budgeted
- Index(es):
Relevant Pages
|
