Linda,
I believe I understand the situation and I still think the same. You
are going about this backwards in such a way that you will create a
highly risky project based on what will probably become an unworkable
plan in Project.
You'll be fighting Project now. Project will become non-useful
immediately. You'll start your project with no Project plan that works.
Some of the early tasks will start to slip. If you actually keep
Project up to date during the project, it will start warning you about
how the end date has slipped past the deadline. You'll ignore that
because it is a "hard" deadline and it *will* get done come heaven and
high water. You'll stop using Project as your guide. You'll loose
track of project status. The project will then not have plan that can
help you forecast. Before you know it, the project is late.
I've seen this so many times. There is a better way.
See embedded.
--rms
I hear what you are saying but I don't think you understand my question.
For clarification:
a hard deadline is defined by when the project sponsor needs the final
deliverable of the project's intent.
OK. But that does not mean that is what will happen. To make this
happen you need to develop and execute a project that will provide the
deliverable on or before the deadline date.
In Project: I would make the task a Milestone (duration=0) with
predecessors all the immedediate predecessors that have to be done to
call it done. Put in the "Deadline" field the date you have promised to
the sponsor.
The issue I have is I must meet a specific date and I have resources that
can only start at particular times. Not all of them are available at the same
start date.
That is the essence of the need to have a plan. So .. figure out what
availability you actually have by person. There a number of different
ways to model the project due to availability. One would be doing it
manually by building a strateg/plan which matches the availability. For
example, if George can only be there on his one for the week of August
4, then create a task George can do on his own for the week of August 4
.... and so forth.
Or you could build a project model which is how it *has* to be done
regardles of availabilty, add the resources with their own calendars
which show availability/non-availability, assign the resources to the
tasks. Project will compute the schedule based on that availability.
Setting the project up to start "as soon as possible" doesn't tell me what I
can get done by the required deadline.
Yes it does. When you say "start 1 Aug", and your project has a
computed duration of 27 work days, then the schedule will show a
completion date 27 work days later (sometime in September). If that
completion date is beyond your deadline date (see above), Project will
politely wake up and give you indication of the lateness in the
"indicator" field (has a little "i" in a blue circle on the default
Entry table.
However, to clarify, you start the project on the date you want. Thats
a fixed date in the Project Start Date dialogue box. You want each task
to be constrained to start ASAP (As Soon As Possible). When you
schedule backwards--as you are trying to do--you will get Project
scheduling from ALAP (As Late as Possible). Guaranteed to give you a
project schedule that is likely to fail since it only takes one task to
be late and the whole project is scuppered.
I need to be able to schedule "as late as possible".
OK. But if you do it this way, then you build a schedule that will have
no tolerance for lateness.
Is your goal to execute each task "as late as possible" (and hoping that
each gets done as expected, or is your goal to get done with the project
on or before the date the Project Sponsor wants it? Your choice.
since MS project has the functionality of setting up the project from the
finish date, are you saying it doesn't serve the purpose I thought it was?
yes I guess I couild Hard codie in the final deadline date on the last task
but that really seems like an inefficient workaround.
Inefficient from what perspective. I suppose doing it your way makes it
easy and fast to get a schedule... Whether that is a good schedule and
whether that schedule will help you deliver the project in time is a
completely different matter.
And DO NOT HARD CODE THE final deadline. Let Project compute for you an
end date based on the project model. if you don't like the computed
schedule, then re plan. For that, Project is *extremely efficient*. It
does an outanding job of doing complex schedule calculations.
Never hard code anything unless there is an actual date that will not
for whatever reason move (the only example I can think of right now
would be a solar eclipse). Just because the sponsor "needs" the
deliverable on that date, just because everything thinks they will get
fired if they don't deliver on that date, just because the schedule says
it will be delivered on that date ... none of those are good enough to
actually *make it happen*.
and in either case, why isn't the resource availablity constraints applying
to the schedule regardless if it is :as soon as, or as late as?
I don't quite get your point here. My suggestion is to not think of
resource availability as a "constraint". It's a fact. It's a property
of each resource. You can tell Project the availability of your
resources, and Project will include that in its computations and give
you an end date which you can see if it is good enough.
In general: add no constraints to any plan unless they are REAL and have
a purpose. Constraints are generally externally imposed--things you have
no control over. You have control when the project will get done
because you are doing it.
