A couple of things. First, if at all possible you should never, ever, enter
the start and/or end dates of the individual tasks. When you do so it
automatically establishes a constraint and it is rarely appropriate to the
task to have one. Of course, there occasionally are times where constraints
are legitimate - a piece of equipment might not be delivered by its supplier
before such and such a date, for example, and so the task to install it
should be constrained to start no earlier than the delivery date, but those
are relatively unusual circumstances compared to the total number of tasks
in a typical project. Ideally you input only ONE date, the Project Start
date (entered in the Project Information window from the Project menu) and
MSP calculates all the individual task start and end dates based on 1: the
durations of the tasks; 2: the logical relationships between the tasks, the
links; 3: the availability of the resources required to do the work. That's
why we use the software, to calculate those estimated schedule dates for us.
Work and Duration are replated mathematically by the percentage of the
resource's time he will be working, his assignment percentage, on the
instant task by the formula W=D*E. You can never have a task that violates
that fundamental identity. You can choose any two of those values to input
and Project will calculate the third for you. Generally speaking, you
usually assign a resource at 100% - if Bob is assigned to wax widgets I'm
going to expect him to devote his full attention to it until they are done.
So when I input the task I'm going to estimate its duration and let Project
calculate the Work. Later I may discover that Bob is tied up elsewhere for
part of his day those days or that I need him to be free some of his time to
work part of his day on some other task I have going on at the same time
that's can't be put off, so I might resduce his assignment to, say, 50%. In
that case, Project's default behavior is to recalculate the duration (in my
example, doubling it). Duration is estmated based on the anticipated
resoruces to be asigned, those resources are then assigned, and Project
calculates the Work (what you are calling "effort") for you.
An alternate way is to enter the tasks and leave their duration at the
default 1d? for now. Assign the resources at the percetnage that they
actually are available. Now enter the amount of work *each* resource will
do on the tasks in the Work column. Here you need to be careful because if
you have a task with 4 resources and you say the task requires 40 man-hours
of work, do you mean 40 hours for EACH resource or do you mean 10 hours for
each resoruces to make 40 hours TOTAL? When you supply the Work, Project
will then calculate the duration based on your work estimate.
The usual approach is to estimate duration and let Project calculate work,
simply because it's often an easier estimate to come up with. "We need to
wax 1000 widgets - last year we had a project where we waxed 100 and my
project archives tell me it took us a week with one guy working on it - if
I've only got one guy for it again this year, it'll probably take us about
10 weeks to do the required 1000 in this new project." So you enter in the
plan "Wax Widgets, Duration 10 weeks, BillyBob@100%" and let MSP calculate
the Work (in this case it'll come out to 400 man-hours if you are using the
default calendars).
IMHO, the training should be split out as individual tasks in their own
right. A task is a physical activity extending over a discrete time that
reults in ONE deliverable output. The entry state for the training is the
people required, students and instructor, for it are available. The
deliverable being constructed is a person who knows how to do XXX. The exit
state for the task is a set of trained individuals. They may USE that
training immediately or they may not use it for months. The resources
required for the training are the students and the instructor. The
resources required to apply the training are just the now-trained students
without the instructor being needed. If all the workers already had those
skills you could do the task itself without training them. Thus IMHO
training someone to polish fids and having them polish 100 fids are two
different tasks linked logically as training->doing because a: the
deliverables are different; b: the required resource skills sets are
different; and c: the time frames are different.
--
Steve House [MVP]
MS Project Trainer/Consultant
Visit
http://www.mvps.org/project/faqs.htm for the FAQs