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]" <
[email protected]>
wrote
in message news:%
[email protected]...
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
message
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.
