Now that the laws of physics are brought into play: W=D*U is NOT the
world formula. It is the roughest possible (linear) approximation on
how one could model the way result production in a project will take
place. Even if we accept the fact that we have to work with this
simplistic formula you just supported my point: whichever way you look
at "W=D*U" it says you need TWO values to determine the third one. For
example a value for work and another for duration to calculate units.
Just because MS Project doesn't change unit assignments around doesn't
mean these are by law of nature constant between plan and actual.
Let me illustrate this by going back to the original example and using
the linear approximation:
plan: 40h Work = 5 days (@8h) * 100%;
actual: 40 h work = 9 days (Monday last week - Thursday next week) *
55,6%
So yes in a way the formula is "always true". But can you tell me how
to collect actuals on "unit" in the real world? What I can get is hours
worked on a task and calendar dates when the work started and when it
finished or estimates for those while we're still in the middle of that
task.
Maybe "making units flexible when entering actuals" is a better
description of what I'm trying to do than "separating work and
duration". Again back to the example: I get updates on work (32 hours
worked, 8h work to go) AND duration (started on monday last week and
going to finish this thursday) - I do NOT get an update "On average I'm
putting 55,6% of my availability to work on task A".
My point is: if I "just let the calculation engine do it's job" as
configured in default (task updates resource i.e. %work updates
%duration) I'm throwing away valuable information!
If I just entered %work complete as expected (8h work to go) Project
would tell me to expect the task to be finished on monday (current
week) and this is not correct - it will finish on Thursday.
If I just entered "remaining duration 4 more days (+ 5 actual)" then
Project would tell me the task is expected to cost almost double (54
hours work instead of 40h in line with baseline).
So maybe we can find common ground with this description:
In tracking a plan you need to collect actuals on two different
dimensions to reflect your actual vs. baseline development correctly.
Since collecting actuals on "unit" is rather impractical (at least for
StDilbert) that leaves you with asking for actuals on work (estimated
work remaining) and duration (estimated remaining duration) separately.
You have to tell MSP to not assume that by knowing one value it can
determine two others, just because there is no functionality in there
that will ever change the unit assignment...
Steve House schrieb:
You still can't separate work and duration and vary them independently
while
holding units constant. That holds as true for tracking as it does
for
scheduling - perhaps even more so since tracking involves recording a
history of actual, real-world physical events that took place under
clearly
understood natural laws of physics, space, and time which can't be
altered
just to keep the accounting department happy <grin>. Joe working at
100%
produces 1 man-hour of work for each hour of time he puts in, no more
and
no
less. It is physically impossible for one person to produce 2
man-hours
of
work for each single hour of time spent. OTOH, if he puts in an hour
of
time and only gets half the job done he was supposed to, he wasn't
working
at full capacity - he's less than 100% by definition. The only other
option
is that you screwed up and over-estimated what his capacity would be
given
the conditions under which the work took place, you underestimated the
man-hours that would be required, in other words.
Your auto shop example isn't a violation of the work equation, it is a
change to the effective hourly rate that the work performed costs.
Your
"earned man-hour method" is Project's earned value based on hours
instead
of
currency units. It doesn't separate work and duration - just the
opposite,
it mandates the link be retained to be valid as it compares hours
actually
worked to a certain time against hours that should have been worked to
that
time.
Daily reports issued simply because you need to issue daily reports
are
of
no value, IMHO. They should be issued only if the information they
contain
is accurate and contributes to a model that leads to a valid
understanding
of the behaviour of the project. Not to say you shouldn't do
everything
you
can to get them out daily - just that accuracy needs to trump
timeliness.
Don't repeat Worldcom's mistakes <g>.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit
http://www.mvps.org/project/faqs.htm for the FAQs
message
Steve, When you're working an outage (almost all of my schedules are
outage
related) that works 24 hours a day and you are there 12 hours per
day
and
7
days a week you have to do what is necessary to get the job done so
you
can
issue your daily reports. Keep in mind 95% of the poeple you deal
with
are
"craft" people and don't have a clue what you're asking them and
really
don't
want to update you. So to compensate for this I type the finish date
they
provide. There is no resume date when they are working24 hours a
day.
As far as actuals: You do not get this during an outage with a 3,000
task
schedule , 150 boiler makers, 75 pipe fitters, 50 electricans, 35
instrument
techs, misc contractors...........
There is something called the "earned man-hour method" that is used
to
track
what percent complete you are. For this to happen the task needs to
keep
the
same "work" (man-hours) as when you baselined. Any other task type
adds
and
subtracts work. If you take your car to a dealer and he quotes you
$100
you
expect to pay that amount. Later you go to pick it up and he says
it's
$200
because Leisure Suit Larry took longer than most people, do you owe
the
man
$200 - NO. If he says Leisure Suit Larry was really fast I'm only
going
to
charge you $50. That will never happen either. He can only earn that
$100
reguardless of how his productivity was.
Earned man-hours over actual man-hours equals productivity.
:
Actually the scenario you describe does not at all require work and
duration
to be disconnected. A 40 man-hour task that has a daily work
pattern
of
8-8-8-split for 10 days-8-8 does not have a duration of 14 days, it
has a
duration of 5 days. The time in the split doesn't count for
duration -
it's
as if the task went on holiday and those days become non-working
time
excluded from the duration just like a normal weekend etc.
I was fine until you said "after entering a new finish date for
Task
A..."
Well, you CAN'T directly enter a new finish date for the task.
Entering a
date in the scheduled Finish field does not set the finish date, it
sets
a
Finish No Earlier Than constraint, a whole different critter.
Instead,
you
can revise the duration (implying work is still continuous but
there's
more
of it required) or you can split the task - splitting is a more
accurate
model of reality IMHO. The better approach is to ask the resource
what
date
he'll be able to resume work and either use that date with the
"reschedule
uncompleted work" tool or display the Resume field and enter it
there.
That
will cause the task to split over the down time days and show the
new
end
date while keeping the original duration as it should. Remember,
duration
and elapsed time are two different measures only roughly related to
each
other. In the case of an originally continuous task that actually
starts,
has some work, then stops, has some downtime, and then resumes
later
to
finish, the duration doesn't change but the elapsed time gets
longer.
When
you're saying you want Project to keep work and duration separate,
it
reveals you're equating duration with elapsed time which is
something
you
really can't do.
Here's another way to update that will do what you need I believe.
Create a
task X starting Monday, 5 days duration. Assign Leisure Suit Larry
to
the
task 100%. Work is 40 hours. In the Resource Usage view, display
the
Actual Work row. Enter 8 hours actual work on Mon, Tue, and Wed.
Now
he
books off sick. Enter 0 actual hours for Thur and Fri. Now you'll
see
16
hours push out into the following week, setting a new finish date
of
the
end
of the day Tues. And of course this would push down any successor
task's
starts. But the duration is still 5 days and the total work is
still
40
hours.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit
http://www.mvps.org/project/faqs.htm for the FAQs
Yes, yes, yes! ;-)... thanks for the passionate reply!
I think we do agree on :"You use the baseline and the current
schedule
together to compare the plan as it was expected to unfold THEN to
what
has actually happened until NOW so
you can accurately predict and control what is going to happen in
the
FUTURE."
But I will not agree with: "To do that successfully you simply
must
let
the calculating engine
do its job."
Here's an example of what I get in a weekly update: task "A"
planned
40h work, planned duration tuesday of last week (we call that the
"reporting week") until monday current week. Friday afternoon the
tracking data is collected and processed on monday. Sample data
for
Task "A". 32h actual work, first hours on Monday of reporting
week
already, so actual start one day early - great. Still there is no
entry
in "re estimate work remaining" and the task isn't set to
"complete"
so
there is still 8h of work to be done - no trouble so far: MSP
will
stick to the finish date of monday current week after entering
work.
But wait: there is an entry in "re estimate finish": thursday
current
week. So the guy working on task A tells me he can't finish those
8h
work today (sickness, availability of peer review, whatever...).
"Now
if I would just "let the calculation engine do its job" I am
exactly
NOT comparing real performance to plan - I'm losing valuable
information. After entering the new finish date for task A I'm
happy
that MSP will calculate the duration effects in the network
downstream
of task A for me. But it just doesn't make sense to stick to the
planning estimate when updating a single task: how would you
enter
that
a task is on budget but late otherwise? Overwrite the actual
cost,
manually change the units? I just find entering actual work and
then
updating remaining work or finish (i.e. planned finish, not
baseline)
if necessary 1:1 with the values I get from my update sheets the
most
straight forward. But I need to tell MSP to keep duration and
work
separate to be successful here.