Remember that time is ALWAYS part of the start, finish, constraint, etc date
fields whether you display it or not. That task with a Must Start On
constraint of a certain date also has a fixed time on that date, say 8am.
That means it is immovable, even if only to shift it an hour later in the
day from when it's presently scheduled. By putting on the constraint, you
have told Project that the task will start on, say, March 15th at 8am and
that is engraved in granite. If for some reason the meeting is also
immovable, perhaps due to a constraint on it as well (Finish No Later Than
is especially common), then you have tied Project's hands and there's
nothing it can do with it.
I can't say it over enough - the percentage allocation DOES NOT actually
reflect the amount of the resource's workday he devotes to a task. The
allocation percentage is the amount of any arbitrarily selected duration
time interval that is actually reflected in full-time equivalent man-hours
of work accomplished. If the resource does one man-hour of work and spends
one hour of clock time to do it, he's allocated 100% for one hour even if
that's the only thing he is scheduled to do during his entire 8-hour
workday. On the other hand, if he dawdles along and takes a day to do what
he could have got done in 1 hour had he devoted his full attention to it,
he''s allocated 12.5% for one entire day day. But note - the task's start
time will be 8am and its finish 5 pm for a duration of 1 day, NOT 1 hour..
A resource is overallocatied when he's scheduled to do be in two places at
once, even if the overlap is only for one single minute.
You can certainly have more than one task per day ... your guy can work on
his 4-hour task during the morning and go to the meeting in the afternoon.
OR if the meeting is not movable, say it's a staff meeting from 8am to 9am,
you have to ease up on the constraint on the other task and let leveling
make its start shift to later in the day after the meeting is over. If the
resource truly does have to work on two things at once, you can have them
run concurrently by assigning him only 50% on each but then you'll have to
live with the fact that it will take him twice as long to finish each one.
And many things such as meetings rationally CAN'T be anything other than
100% - could he reasonably be expected to be in a meeting discussing
department objectives at the same time he's writing a program or painting a
wall? Not likely.
Try to avoid constraints if at all possible - they have their uses but
should be relatively rare in your project, used only when necessary to model
a physical certainty. For example, if parts needed for a certain task won't
arrive from the vendor before April 15th, it is certainly reasonable to put
a Start No Earlier Than constraint on the task to reflect that reality. In
your example, if the meeting is going to happen at that date and time
regardless of your project's needs or the resource's work schedule an MSO
constraint on the meeting reflects that reality. But for the other 4 hour
task, if you put on the constraint because that's when you want him to work
on it or you think that's a convenient time for him to work on it or even
that's when it ought to happen so the project finishes on time, the MSO
constraint is not justified and should be removed. People often use MSO,
MFO, SNLT, or FNLT in an attempt to force the plan into a schedule they have
predetermined to be the one they want and that is a serious mistake.
Project is not designed to document a schedule you have already determined
elsewhere. It is intended to tell you the dates (and times) that tasks are
able to happen, not reflect the dates and times you want them to happen or
even NEED them to happen, no matter how badly.
