I would think of your port departure as a "Should" start on rather than a
"Will" start on, which is what I think a Must Start On conveys. MSO to me
means that even if the coast is being battered by a typhoon on that date,
the ship would still sail, heading right out into the storm and it's a
certainty that all your stuff will be on board.
As you said, you need to mobilize all the resources and equipment to be
ready to go on the sailing date. That to me makes it a very strong
deadline, not a constraint. Your business reasons say you absolutely can't
miss the deadline, you absolutely and positively must meet that date under
any circumstances, but even so it's still not a certainty that you will -
the whole reason you're planning is in order to come up with a strategy that
will make it possible to sail then and if you plan incorrectly you won't
make it. If you don't constrain the sailing but instead set the required
departure date as a deadline and let the scheduled sailing date move about
in accordance with Project's calculations, you'll actually see at a glance
whether your present strategy is going to be successful or not. (Obviously
you never show this tentative plan to the powers-that-be until you've
refined it to the point it DOES meet the requirements unless they understand
the exercise.) But an MSO constraint will lock it to that date and Project
will not move it, even if in reality your plan for the tasks leading up to
it makes it totally impossible for it to happen on the date it's scheduled.
Because it's locked to a fixed date, Project will never show you that you
have a problem. IMO, catching such problems before it's too late to do
anything about them is the whole reason for using Project in the first
place. If all you're going to do is mark off some predetermined dates on a
chart and watch as the project proceeds to see if you're on schedule or not,
a calendar and Magic Markers are a lot cheaper <g>. I want first and
foremost for it to confirm whether or not my ideas are going to work as I
think they will and for that purpose it should illustrate the outcome I'm
going to GET if I work according the the plan, not the outcome I WANT. I
want Project to be my reality check. If the proposed schedule for those
preparatory tasks isn't going to result in everthing being ready to go by
the required sailing date, I want to know about it before I get hit with the
5 megabuck penalty and I'm using Project to give me that heads-up by
calculating likely outcomes. If that's to happen, I have to let Project
freely calculate what the sailing date *would* be *if* I worked according to
the present tentative plan. If it doesn't meet the required date, I have to
revise the plan, not just use a constraint to force the sailing date to
appear ok regardless of whether it actually is or not. Yes, I know slack
time can give you that info as well, but the big red indicator beside the
task name, the big green deadline marker on the timescale, and the visual
relationship between the milestone marker and the deadline indicator showing
how close or far away you are from the required solution at the moment is
far more dramatic and clear. And the slack time is calculated on tasks with
a deadline in exactly the same way as it is when the deadline is a
constraint so you don't give up anything.
Just my thoughts ....
--
Steve House [MVP]
MS Project Trainer/Consultant
Visit
http://www.mvps.org/project/faqs.htm for the FAQs
(