Re: Adding a predecessor does not change date?

Tech-Archive recommends: Fix windows errors by optimizing your registry

So, don't publish it to the server until you're resolved all the missed deadlines. In fact, I think there's an even stronger case to be made for NOT using constraints such as you suggest in the Server world - as a PM you are intimately familiar with slack time - how to obtain a report on it and the report's interpretation - but the Executive and others viewing the plan probably lack such technical expertise. You'd not publish the plan until you were very close to transitioning from the planning to the implementation phase of the project lifecycle. In fact, once you publish the plan and commence work is when you *really* want MSP to freely calculate the actual dates that are going to be hit given progress to date. If things aren't going quite right and it means you'll miss your planned finish date, I suggest a glance at the Finsh date column should warn you of that fact by showing the date the present rate of progress is going to put you at. I want to see the Estimated Actual Completion Date, not the Planned or Required completion dates, listed there. Using hard finish constraints makes it ALWAYS look at first glance that you're going to make your objectives even when you're really running late. You have to know to run a slack time report for the future tasks and how to interpret it along with EV reports to get any clue that your project is actually in trouble.

Sure, using slack works well if you know what you're looking at and don't overlook the fact that you MUST tweak the schedule in the planning phase until all the negative slacks go away. But it is far more obvious what is going on in the plan if one sees a nice big red diamond in the indicator column indicating a missed deadline, a date in the Finish column that shows where you really are going to end up if you keep on going on your present path unless you do something to fix it, a pretty green arrow on the Gantt chart itself showing what your requirements are, and task's end or a milestone diamond off to the the right of that arrow glowering at you demanding you figure out a valid way to move it to the left. IMHO, using constraints and slack time to adjust the schedule worked well enough in its day before the turn of the century but since the advent of the deadline field in Project 2000, there has been a better way. Continuing to use the old-fashioned method now is kind of like writing a novel using a quill pen and squid ink instead of a word processor. It works, but there are much better ways now available. <grin>

There's a joke that says the only question you have to ask in the interview when hiring an accountant is "What's two plus two?" The fellow you hire is the one that answers "What would you like it to be?" Well, to my way of thinking using a constraint to make a finish date appear to be on schedule when it's not (and there would be no need ever to bother using the constraint to get it to that date in the first place unless it was being calculated to miss it without putting the constraint on, with the unconstrained task is being placed later in the schedule than you want it to be) is the equivalent of that accountant who tells the boss he's making a profit when the harsh reality is he's losing money by the bucketfull. It'll keep the boss happy until the day where you promised to deliver the completed project and have to go into his office with the news that there's 6 more weeks of work to go. "But look here, that spiffy Gantt chart you gave me for my wall shows it's right on time! What went wrong? Somebody must not have worked the way the plan said they should - heads will roll!" But actually, your plan only appeared to be one that would finish on time when worked the way you outlined it because you used constraints to "fudge" the dates to appear something other than what was actually possible. If you don't use constraints to distort the plan, you'll never have to confront that scenario because you (and your boss) will have known things weren't going right far enough ahead of time to actually do something about it, the red marker on the Gantt task table for the missed deadline having been glowing like the low oil pressure light on your car's dashboard warning you of trouble as soon as the first hints of problems reared their heads.

Oh, and another point - you can still use your favorite slack time methodology even if you use deadlines in stead of constraints. Project's slack time calculations treat deadlines as if they were FNLT or MFO constraints and produces exactly the same results as you're getting with your method. In fact, using deadlines instead of constraints is very similar to using constraints with the "Tasks Always Obey Constraints" option turned off, except that unlike that option, using them doesn't also disable any SNET constraints letting tasks move earlier than they should in the process.

I have to repeat myself - the plan does not exist to document expectations. It exists to tell you if the work schedule you have in mind is going to meet expectations or not. Using constraints forces it to tell you what you want to hear rather than what you need to hear in order to avoid disaster. If the work plan is going to fail to meet requirements, you need to let your tool inform you of that fact in time to change it.

--
Steve House [MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


"Jan De Messemaeker" <jandemes at prom hyphen ade dot be> wrote in message news:Of75seAmFHA.4056@xxxxxxxxxxxxxxxxxxxxxxx 
Hi Steve,

Just two thoughts to add
1. In this world of consolidations and Project Server the pM sdoes not
decide when the executive looks at his plan. He may do so at any moment.

2. My advice is that rather than on dates, the PM bases his actions on Total
Slack. What he/she has to work on is negative total slack.

Greetings,

--
Jan De Messemaeker
Microsoft Project Most Valuable Professional
http://users.online.be/prom-ade/
+32-495-300 620
"Steve House [Project MVP]" <sjhouse.remove.this@xxxxxxxxxxxxxxxxxxx>
schreef in bericht news:eA1SaK#lFHA.1412@xxxxxxxxxxxxxxxxxxxxxxx
Jan, you'd never, ever present that plan to an executive until whatever
conditions that caused the late date was resolved so that the freely
calculated date meet the required objectives. Only then do you show it to
the executive. Keep it a deep dark seceret until all the scheduling
issues
have been resolved to your satisfaction and the unconstrained plan meets
the
requirements. Only then can you show it to him with some confidence that
it
really is possible to do it the way you have outlined and have it be a
success. If you present the plan while using a constraint to force a taak
to a required date in the schedule when Project wants to put it elsewhere,
you are promising the boss you can deliver on his expectations when the
best
tool you have to predict what is really going to happen in your project is
telling you that it's going to be impossible to do it if you try to work
the
plan as you have outlined it. I say that beause the only time you NEED to
use a constraint to put something on a certain date is when it doesn't
fall 
there of its own accord.  If you DIDN'T have to use a constraint to get
Project to put that task on the "correct" date, you'd be able to make the
requirements without worry.  The simple fact you have to use a constraint
to
get it to come out "right" for the boss is telling you it simply isn't
going 
to work out as it is supposed to and you WILL, without any doubt, go over
schedule and/or over budget.  The act of writing something down in the
plan 
does not insure it will happen that way and the need to put in the
constraint in the first place is telling you it CAN'T happen the way you
want it to.

I feel the plan is not to document what the stakeholders want to see, it
is 
the tool you use to decide how to organize a schedule that gives them the
outcome they expect.  You can only use it that way if you don't force it
to 
fib to you about whether your proposed plan is actually going to be
successful. Otherwise it's like the schoolboy who keeps assuring his
parents 
he's getting all "A"s when in fact he's flunking out.


--
Steve House [MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


"Jan De Messemaeker" <jandemes at prom hyphen ade dot be> wrote in message
news:%23Ohqw84lFHA.3380@xxxxxxxxxxxxxxxxxxxxxxx
> Hi,
>
> I do not have the energy to write as much prose as Steve, just that I
> agree
> with Dave, that when the consequences are dire, you put a constraint
> rather
> than a deadline.
> If you present a plan with a later date to an executive you risk being
> shot
> or beheaded on teh spot.
> The result is the same - you have to work to avoid the dire
consequences. 
> Meanwhile, be optimistioc and show the result you NEED to realize.
> Greetings,
>
> --
> Jan De Messemaeker
> Microsoft Project Most Valuable Professional
> http://users.online.be/prom-ade/
> +32-495-300 620
> "Steve House [Project MVP]" <sjhouse.remove.this@xxxxxxxxxxxxxxxxxxx>
> schreef in bericht news:OtGzCG1lFHA.2920@xxxxxxxxxxxxxxxxxxxxxxx
>> I have to disagree completely that a constraint is the best way to
> schedule
>> the circumstance you describe here.  I suggest that a DEADLINE is the
> better
>> way to show something "needs to occur by that time or the consequences
>> are
>> dire."  A constraint of any sort limits Project's freedom to display
the 
>> tasks where it thinks they should go.  But the reason for using
>> scheduling
>> software instead of simply drawing task bars in Magic Marker on a wall
>> calendar is to have a tool that does exactly that -  calculates
schedules 
>> for us so that we have a tool to use to figure out what we must do in
> order
>> to meet those requirements.  As such, we need to allow Project to
freely
>> calculate the results of our potential decisions - if I put Joe on >> this
>> task, will it move my completion up or set it back? But a constraint
>> says
>> DON'T show me the results of those decisions and instead just show on
>> this
>> date as I dictate whether it actually can happen then or not! If we
put
>> your example of showing up in court at a certain time into our plan
with
> an
>> MSO constraint, it's going to show we're going to make it on time
> regardless
>> of whether it's actually going to be physically possible to do so. >> The
> case
>> could be in 10 minutes, we could be 1000 miles away and on foot, and
yet
> the
>> plan will STILL show that we're going to make it just fine! To me >> that
>> completely defeats the purpose of doing the plan in the first place.
But
>> using a Deadline instead does a couple of very useful things - it
clearly
>> marks the date I need to hit AND more importantly, it shows a) if I'm
> going
>> to make it as the plan now stands, and b) let's me see exactly what >> the
>> effects are going to be of any controls or changes I apply. Now >> that's
> far
>> more useful than a mere pretty Gantt chart of the plan I hope to
> accomplish.
>> Without constraints distorting the plan into painting a false picture
of
>> success (regardless of whether it's workable or not) and lulling me
into
>> a
>> false sense of confidence, I now have a tool I can use to design a >> plan
> that
>> meets the required objectives.
>> --
>> Steve House [MVP]
>> MS Project Trainer & Consultant
>> Visit http://www.mvps.org/project/faqs.htm for the FAQs
>>
>>
>> "davegb" <davegb@xxxxxxxxxxxxxx> wrote in message
>> news:1122933027.003182.154480@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>> >
>> ...
>> > Just giving you a hard time, as usual! <evil grin>
>> > I interpret MSO and MFO a little differently than you do. To me, it
>> > means that the task needs to occur at that time or the consequences
are
>> > dire. This could be showing up at the courthouse on time or the
keynote
>> > speaker stepping up to the podium at 8:00 am Monday morning to start
>> > the conference. There is little or no flexibility. In the first >> > case,
a
>> > warrant may be issued or a hefty fine imposed, in the second, a
couple
>> > of hundred people who paid good money for whatever getting antzy by
the 
>> > minute.
>> ...
>>
>> > Regards,
>> > Dave
>> >
>>
>
>





.

Relevant Pages

  • Re: Proper Leveling Techniques - Rescheduling to start later
    ... Start and Finish are what your schedule calls ... Baseline Start and Finish are your original starting plan ... otherwise to force the tasks to end up on certain dates - leveling has ... I don't know why you're so adament againt using SNET constraints in any ...
    (microsoft.public.project)
  • Re: Fixed end date with flexible start date
    ... What you have is a fixed DEADLINE for task 3, ... Using constraints says that task 3 *will* finish on ... > select "Schedule from End" and set the deadline date. ... > late - no cushion to absorb unforseen delays. ...
    (microsoft.public.project)
  • Re: How do I move an entire group of tasks
    ... and I need to move the start date earlier, I have to adjust each one ... With thousands of tasks and years on the schedule, ... set up the plan is to have a fully linked dynamic schedule. ... Avoid the use of constraints since they defeat the ability of Project to ...
    (microsoft.public.project)
  • Re: Why it is better to not use Deadline dates
    ... I'd pick a date for the project kick-off consistent with the other activities of the firm but well in advance of that latest possible date and plan and assign the work forward from that point. ... Joe needs to show the preliminary drawings at the Board of Directors meeting next week - that's a task deadline for an intermediate task in the project. ... Seeing if the current work schedule places a task finishing before or after its deadline tells you if the work plan as you have currently conceived it is going to serve to meet those objectives or not. ... >> milestone with a deadline is the last task in the schedule. ...
    (microsoft.public.project)
  • Re: Leveling - Resources are not leveled
    ... according to the current plan. ... > The only purpose of showing these very tough constraints at a date they ... The information saying that the schedule is impossible is there ... >> are not MSO in terms of the way they are entered into Project. ...
    (microsoft.public.project)