Hi,
Since you keep saying "field" I think you do not enter actual work in the
cells of an actual work line in the right part of a Usage view.
Try that, I think youwill se emuch clearer.
HTH
--
Jan De Messemaeker
Microsoft Project Most Valuable Professional
http://users.online.be/prom-ade/
+32-495-300 620
"K Major" <
[email protected]> schreef in bericht
Jan,
I am using the "actual" work field, actual start field, and actual finish
field only.
Is something else causing the bounce?
Kevin
:
Hi,
Do you use an Actual Work LINE in the task usage view or a Work LINR?
When you put all teh work in teh Actual Work line nothing bounces any
more.
Actuals are not reset whtever the task type.
HTH
--
Jan De Messemaeker
Microsoft Project Most Valuable Professional
http://users.online.be/prom-ade/index.htm
32-495-300 620
"K Major" <
[email protected]> schreef in bericht
Steve,
I am entering "actuals" in the task usage view - I am using the task
usage
view in stead of the tracking view because this allows me to see each
resource assigned to each task on a line per line basis (just easier
to
follow in that I have some customized fields I'm working with).
I do understand the difference between duration and work. I am
completely
in synch with you on this - still, just today, I had a task that was
to
take
9 hours by 1 resource from 2/10 to 2/15 and the actual span turned out
to
be
9 hours over 2/10 to 2/18... when I set the actual span MSP bumped the
work
hours to 21 hours? This is a fixed units/non-effort driven task.
Thanks, Kevin
:
Where are you entering the start and finish first of all - are you
entering
in the Start and Finish columns of the Gantt chart Entry table or
are
you
entering in the Actual Start and Actual Finish columns of the
Tracking
table? Also, I'm assuming you are aware of the difference between
duration
hours and work hours. Duration hours are the amount of working time
between
when the task begins and when it ends, whether it was filled with
work
or
not. So if the task began Monday at 8am and finished Tuesday at
5pm,
it's
duration is 16 hours even if the resource only actually performed 2
man-hours of work during that time. So your tracking table entries
should
show:
Actual Start = XXXXXXX
Actual Finish = YYYYYYYY
% Complete = 100%
Actual Duration = 14.5 hours
Remaining Duration = 0 hours
Actual Work = 2 hours
Remaining Work = 0 hours
--
Steve House [MVP]
MS Project Trainer & Consultant
Visit
http://www.mvps.org/project/faqs.htm for the FAQs
Thanks.
I entered some data today in the manner in which we discussed.
I have a resource that worked a total of 2 hours on a task over
SEVERAL
days
(the plan was to do it in ONE day but that did not happen). When
I
try to
enter the actual start and finish span over those days - MSP tries
to
bump
up
the number of work hours from 2 hours to 14.5 hours (I guess to
account
for
the larger range).
Am I doing something wrong?
I appreciate your patience on this - you are really helping me.
Kevin
:
Yes, I'd allow the schedule change. I'd also revisit your link
logic
since
the fact that you even COULD do them out of sequence indicates
that
they
weren't in a true predecessor/successor relationship after all.
This
often
happens when you've used links to try to impose a certain
sequence on
the
schedule. There may be times to do that, of course - it's a
logical
toss-up
whether you work on this report or that presentation first but
the
boss
wants the report ASAP so he can take it to the board meeting -
but
for
the
most part I'd like the links mainly to model physical or logical
necessities, ie, you can't build a prototype until you've first
come
up
with
a design, you can't load the movie camera until you've gone out
and
bought
some film.
I'd just delete the cancelled task unless there is a specific
reason
to
keep
it in the plan. Zeroing it makes it a milestone and that is
rarely
appropriate IMHO.
--
Steve House [MVP]
MS Project Trainer & Consultant
Visit
http://www.mvps.org/project/faqs.htm for the FAQs
Steve,
That did help. Just to confirm, when I enter actuals and MSP
says
that
there is a scheduling conflict (because a task was done earlier
and
out
of
sequence), I should ALLOW the conflict because it is what
ACTUALLY
happened
versus what we PLANNED to happen. Right?
One other question - when we ID a task that we did NOT need at
all...
is
the
best thing to do to zero out the work hours and mark it as
complete
OR
just
delete it?
Thanks, Kevin
:
K - you asked what the difference was between Start and Actual
Start
and
the
answer is part of the root of your problem I suspect. The
data
tables
in
Project are database table "under the hood" and the various
columns
you
see
are fields in those table. When you look at the Entry table
in
the
Gantt
chart (the default standard task list, in other words) you
see,
among
others, the Start, Finish, and Duration fields. (Think of
those
fields
as
being Scheduled Start, Scheduled Finish, and so forth.) But
when
you
change
the table (view, tables menu) to the tracking table you see
columns
labeled
Actual Start, Actual Finish, Actual Duration, Remaining
Duration,
Actual
Work, Remaining Work. Some other table options may show you
Baseline
Start,
Baseline Finish, Baseline Duraion, Baseline Work ... Using
Start
as
an
example to keep the typing down -- Start and Actual Start (and
the
others)
are not the same fields relabeled in different views - they
actually
are
different fields in the database. The Start field is
calculated
by
Project - it represents the planned project as it sits at the
moment.
While
you're planning, Start is a calculated value, Actual Start and
Baseline
start are empty. When you have the plan as you think you'll
perform
it
the
Start field has the expected start dates of tasks, calculated
by
the
network
of links, the expected duration of each task, and the project
start
date.
Hopefully you have NOT actually entered any of those dates by
hand -
you're
not supposed to tell Project when you want Task X to be done -
instead,
it's
supposed to be telling YOU when Task X is going to be able to
be
done.
So Project is now displaying a schedule that it has
calculated -
it
has
looked at the start of the project and what you have told it
about
the
nature of the work and forecast the dates where tasks can
occur.
Mark
the
word "forecast" - it's an important concept and explains some
of
Projects
behavior. The start and finish fields represent the forecast,
the
scheduling of the latter tasks being driven by the scheduling
of
the
early
tasks. Now, the plan is ready and you're going to start work.
You
want
to
preserve the plan you expected to work for future reference so
you
save a
baseline. The values from the Scheduled xxx fields are copied
into
the
corresponding Baseline xxx fields - baselines don't change
unless
you
explicitly force them to while the Scheduled fields will so
you
always
have
a reference point. Now Start = xxx, Baseline Start = xxx,
Actual
Start
=
[empty].
Now we post some actuals - you DO NOT enter the date the task
actually
started in the Start field. Instead, you record that in the
Actual
Start
field. Likewise the Finish. Project does two things - it
records
your
actuals AND it changes the Scheduled Start and Finish fields
(the
plain
Start and Finish, in other words) to be equal to the Actuals.
Why?
Because
the schedule of tasks out in the future is contingent on the
schedule
of
tasks that come before them. If the earlier tasks are worked
at
times
different from what was first planned, the subsequent tasks
whose
schedule
is dependent on them must be revised accordingly. But just
changing
the
Start and Finish fields in the Gantt chart entry table does
NOT
tell
project what you did - it tells it you're changing what you
expect
to
do
but
you haven't done it yet. That fact that those dates you're
entering
are
before today doesn't enter into it because Project doesn't
really
know
what
day it is today. So when you're halfway through the Project,
the
Gantt
chart reflects two types of data - what really did take place
for
work
that
has been done, and a revised forecast for the schedule of
tasks
still
to
come, the revised schedule based on what you've told it is the
actual
start
and finish of those completed tasks. So how do you know what
the
original
plan was? By looking at the Baseline Start, Finish etc
fields.
Because
when you enter Actual Start, Project changes the Scheduled
Start
but
it
does
NOT change the Baseline Start.
HTH
--
Steve House [MVP]
MS Project Trainer & Consultant
Visit
http://www.mvps.org/project/faqs.htm for the FAQs
Thank you.
I still must be missing something.
Some of these folks are doing tasks sooner AND later than
scheduled
(and
even out of order). When they do it sooner, I try to enter
that
actual
start
date but many times it won't allow me, I assume because of a
link
that
exists
(of course, that makes sense). However, the reality is, is
that
the
task
was
done and obviously our link was a bad assumption on our part
in
planning
(or
else the task could not have already been performed).
Is my thought that tracking what we planned to do, versus
what
actually
happened (however dysfuntional that is), is flawed and not a
function
of
Project?
Also, your "remaining work" comment may answer another
question...
Example:
Task = draft report
Jones = 2 hours
Smith = 2 hours
Planned start = 2/21/2005
Planned end = 2/22/2005
At the end of the week on 2/18 (task is worked on earlier
than
expected,
let's say due to a bad link assumption), Jones reports
putting
in 2
hours
over 2/14 to 2/18 but is NOT done. Smith put in 1 hour on
2/18
and
IS
done
with her portion.
If I try to enter the span of dates for Jones, it won't let
me
(I
assume
due
to the link). In that we had 2 hours for each and one
resource
is
done
and
one is not... can I assume the following: I need to update
the
"actual
work"
field for Smith with 1 hour and when "remaining" calculates
to
"1
hour
left",
I should just blank this field and it will update the "work"
field
from
2
hours to 1 hour and her portion is finished? Then, for
Jones, I
need
to
enter the 2 hours as actual work and when "remaining" goes
to "0
hours"
left,
I should update that field with whatever time Jones says he
has
left
(your
remaining work comment)?
Sorry for so many questions, but this is really helping me.
Thanks, Kevin
:
Hi
Your questioon has a simple answer.
Once there is an Actual Start, Start equals actual start.
Start is a value Project calculates.
Project si designed to calculate a planned schedule, not to
change
past
reality as recorded.
That is why Start=Actual Start.
Another piece of advice on tracking.
Always ask for remaining work and enter that when tracking
as
well.
many very good reasons, too long to all explain.
HTH
--
Jan De Messemaeker
Microsoft Project Most Valuable Professional
http://users.online.be/prom-ade/index.htm
32-495-300 620
"K Major" <
[email protected]> schreef in
bericht
Here's where I stand...
1) Tasks entered (all fixed units/non-effort driven),
tasks
linked,
time
estimated, resources assigned at 100%, resources leveled
2) File has been baselined
3) Project has begun
TRACKING IS MY PROBLEM:
My approach is simply to ask each resource to let me know
on
a
weekly
basis
the date they start (on each task), the # of hours per
week
for
that
task,
and the date they finish. Of course some of my tasks
have
multiple
resources
assigned - still, they each report separately and when
they
are
ALL
done,
the
WHOLE task is complete.
THEN THINGS DON'T GO AS PLANNED (as they do in any
project)...
Still, all I want to do is enter the above info as it is
provided
to
me
but
many, many times the dates start playing "tricks" on me.
I had assumed that my baseline would tell me the story of
how
things
didn't
go as planned as compared to actuals.
So, my question is what is the difference between "Start"
and
"Actual
Start"? This seems to be at the core of my problem. I
at
least
know
that
neither of these dates are the "Baseline Date".
Am I missing some basic concept here?
Help! Kevin
