Re: Event Scheduling deadline date

Hi Yani,

Another possibnility is that you are scheduelling from the finish. Check
Project/Project Information.../Schedule from: Project Start Date.


Mike Glen
Project MVP



Steve House [Project MVP] wrote:
That is a very common occurance actually. Consider a simple project
consisting of 5 tasks, each of, say, 5 days duration, all linked one
after the other in a simple sequence like elephants in a circus
parade. All of those tasks will be critical since the delay of any
task will delay the completion date of the project. Remember that
all that's required for a task to be critical is for its slack time
to be zero or less. Slack time in turn is the amount of time the
task can be delayed before it pushes back a successor task start, a
successor task finish is pushed past its deadline, or the project
completion is delayed. But note, if you have two tasks linked FS and
you use a lag time to set the start of the successor at some later
time than the link by itself would cause, that does NOT add slack
time to the predecessor task. A 5 day lag time looks like it should
mean the predecessor has 5 days "grace period" that it could delay
without affecting the sucessor but that's not the case - a X day lag
time means that there is some concrete reason that the successor MUST
NOT start until X days after the predecessor has ended, regardless of
when that is. Adding lag time into a link between tasks will not
cause a critical predecessor to become non-critical.
The way I suggest you handle this sort of situation is first to
pretend that nothing has been done and you've gone backwards in time
to before when the project began. Set the project start date to the
date work was first done and build the plan according to proper PM
principles, letting Project calculate all the task dates and letting
them fall where Project wants to place them. Then bring things
forward to the present day by posting in actual work that has been
done on the dates that the work actually was done using the tracking
tools as if you had been following the plan and posting progress all
along - if you want to be detailed about it, set the "current day"
entry in the project information page to each Friday in turn since
the project started, post in work actually done for that week, and
run the "reschedule uncompleted work" tool to pull uncompleted stuff
forward the following Monday. Once you have worked your way forward
to the present date you'll have a correct, working project plan that
accurately details what has been done to date and a forecast schedule
that you can take to your boss with "... and here's the revised
schedule we need to work from here on out so we can best complete
everything remaining to bring our project in on-time and within
budget."
"inay" <inay@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:E71B28B6-6589-4162-8C7A-CACF9342C61F@xxxxxxxxxxxxxxxx
Hi Steve

I understand that the situation is not ideal. My problem is that the
project has already started and management want reporting on progress
while I
am trying to complete the schedule development process, so, for
current tasks
that have started, I am having to 'make the dates' work. On another
note, I
am finding that most of the tasks (i.e. 90%) are coming up red
(marked as critical path). Have you ever seen this? Can you
suggest what might be causing this?

Thanks,
Yani

"Steve House [Project MVP]" wrote:

Jumoing in - the critical path is the sequence of tasks that drive
the project duration. If tasks are happening in a linear
progression and you've
said task A lasts 5 days and task B will start three days after A
finishes
and B lasts 10 days etc etc, that establishes the timing of the
project as a
whole. If A takes 3 extra days, 8 days, not 5, the lag time says "B
still
starts three days after A finishes so push B's start back three
days" Just something to think about here - You said "you (input) dates
according
to when you've been told the work will be done." That's putting
the cart before the horse. Your resources shouldn't be telling you
when work will be
done for you to then input into Project. Project's job is to
compute when
the work needs to be be done, not merely document when someone else
has decided to do it. You don't make it show predetermined dates
at all, either
directly by inputting them or indirectly by throwing in lags and
leads arbitrarily. You determine how long each task should take
and the way the
various tasks relate to each other and from that Project computes
the dates
that gives an optimum work schedule which you then communicate to
the resources so they can plan to do their work according to what
Project has determined they should be doing. The project plan
tells them when they need
to do their work, they don't tell it when they want to do it or have
decided
they are going to do it.
--
Steve House [MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


"inay" <inay@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:E4BB6D29-D31C-44A5-A824-F292DD079BF0@xxxxxxxxxxxxxxxx
Hi Mike

As you suggested, I have used ASAP constraint and used the
lags/leads to
modify dates according to when I've been told the work will
actually be done
(the project is a WIP). I suspect, however, this is causing
everything to
become a CP activity or is there another possible explanation? I'm
looking
at a schedule where basically everything is on the CP and I don't
know why.

"Mike Glen" wrote:

Hi Inay,

ALAP constraint pushes the task to the end of any slack it may
have, thus
robbing you of any flexibility. Suppose you have a 4 day task with
ALAP
and
it actually takes 5 days - you've lost a day and everything
subsequent to
that will also be a day late. Better to start as soon as you can
and any
delay can be taken up by its slack. However, there must be some
real life
occasions when it may be suitable. I'd try not to use any
constraints,
other than the ASAP, which in practice means no constraint. Others may
hve
different ideas:)


Mike Glen
Project MVP



inay wrote:
Thanks Mike.

So I would combine the 'As Soon As Possible' constraint and use
deadlines? Would I use any 'As Late as possible' type
constraints? What is the impact of using this latter type of
constraint should tasks need to be reschedule? I am only
familiar with the 'As Soon As possible' constraint and the use
of lags/leads to push dates around. "Mike Glen" wrote:

Hi Inay,

Welcome to this Microsoft Project newsgroup :)

No contest - use deadlines. In my view, you need to let Project
have free reign to calculate the dates based on your Durations
and Precedence links. I'd create a Finish milestone and apply a
Deadline. Now, as your project changes and you update and
re-schedule it, you can see the relative positions of the
Milestone and the Deadline. If your revised schedule causes
the finish to be later than the deadline, an indicator will
appear in the Indicator column to that effect. You can then
crash the project to bring it back to the required date.

FAQs, companion products and other useful Project information
can be
seen at this web address: http://project.mvps.org/faqs.htm

Hope this helps - please let us know how you get on :)

Mike Glen
MS Project MVP

inay wrote:
Hello

I am developing a schedule for a series of events (part of a
conference). The start date/delivery of the events can not
move. I
want to be able to set dependencies such that:
- the event start/finish dates do not move;
- any other tasks that directly impact the delivery of the
event are
linked such that should slippages in these events cause the
start date of an event to be jeapordised, the lead up
activities will flag
as red (understand that I can set the CP to show as red, are
there other flag/indicators avaialble?); - i can manage the
critical path
and view the changes in slack for tasks on the CP;
- once we are using the tracking gannt, i can use project to
reschedule all other tasks, other than the actual events
themselves,
if there are slippages.


I've researched past posts and am trying to work out the best
approach. Should I:
- create links between critical path activities to the events
and set negative lags (I've started to do this, however, am
finding it doesn't give me the flexibility to start tasks
sooner than the lastest dates required); - use deadlines
(havent' really used these
in the past so don't know how this will 'flag' slippages and
the critical path) - set must finish on constraints (but my
understanding from others is that this is not optimal as it may
not
enable me to make use of project's ability to reschedule tasks
down
the line)

Thanks - it's a long one!



.

Relevant Pages

  • Re: Why it is better to not use Deadline dates
    ... schedule from finish date. ... > 4) The three tasks have the defaulted constraint "As soon as possible". ... > 6) Associate to task c a deadline date equal to 05/12/05 and then change ... > milestone d with 0 days of duration, you associate it a "Must start on" ...
    (microsoft.public.project)
  • Re: Schedule from End Date
    ... Finding the last possible start date that lets you hit a certain finish date is an interesting academic exercise but it is an incredibly risky way to schedule and manage the project. ... With a deadline date entered, you'll also have a marker somewhat later on the timeline to show a reminder of the required date and you can see at a glance how much "cushion" you have between where it looks like you'll finish and where you absolutely, positively HAVE to finish. ... If delays move the finish milestone too close to the deadline for comfort, or G*d forbid, PAST the deadline, you know you need to exercise some management controls - call in overtime, for example - to shorten up some of the predecessor tasks and pull the finish milestone back from the brink. ... That's a major reason I don't like using the "must finish on" constraint - if you do, the plan will always show the milestone on the required date EVEN IF you're running terribly late. ...
    (microsoft.public.project)
  • Re: Schedule from End Date
    ... It's fine to schedule backwards to find the ... When you do, your finish milestone ... If delays move the finish milestone too close to the deadline for ... > this but I'm absolutely NOT a fan of using a "must finish on" constraint on ...
    (microsoft.public.project)
  • Re: Deadlines and Constraints
    ... > "Jan De Messemaeker" wrote: ... >> A deadline DOES NOT as such change the schedule of a task. ... >> Task A has a Finish No Later Than constraint of Wednesday. ...
    (microsoft.public.project)
  • Re: Deadlines and Constraints
    ... With the constraint the task always shows in the schedule as ending by the required date, even if it is physically impossible for it to really happen that way. ... Using a deadline lets the task fall in the schedule where ever the predeccessor links and resource availability will drive it, showing you where you're really going to find it happening if you try to do the work according to the present plan. ... Steve House [Project MVP] ...
    (microsoft.public.project)
Loading