Why it is better to not use Deadline dates

[Michele]

As greatly suggested to me by John Jensen I found a work around to achieve my
objective in scheduling a project using MS project.
While I am convinced that the engine of MS project software is working fine
regarding the backward pass and forward pass, I am convinced, on the
opposite, that associating a deadline date to a task MAY have(ONLY IN CERTAIN
SPECIFIC CASES) bad consequences on the engine of Project, causing illogical
and not correct results.
For anyone who was interested in knowing which are the cases I describe
above I am helpful to write him/her.(Anyway they are mostly related to the
tracking of the tasks)
The work around I found about avoiding to use deadline dates is to
create(one for each task one wants to associate a deadline date, clearly only
if the deadline dates are different)a milestone task(With 0 days of duration)
and link the task u want to associate a deadline date to the milestone task
with Finish-to-Start relation.
In this way all work fine, even and especially when the planner starts
tracking that task.
I hope that this advice can be helpful to anyone of you.
Best regards
Michele

 

[Michele]

I forgot to write that the milestone task must have a constraint equal to
"Must start on" and the constraint date must be the deadline date one wants
to associate to a task.
Best regard
Michele

"Michele" ha scritto:

 

[Jan De Messemaeker]

Hi Michele,

While I too am a user of your "deadline method through milestones" I can't
think of an instance (at least when scheduling from Project start, which I
always always do) where the use of a "deadline" may be harmful, especially
because deadlines do not directly influence the schedule.

HTH

 

[Rod Gill]

The only time deadlines appear to cause "undesirable" behaviour is when the
milestone with a deadline is the last task in the schedule.

I am a firm believer that as many tasks as possible be driven only by their
dates. The more time critical the project the more important this is. With
only links to drive tasks (even if you have to add links to some tasks to
show an arbitrary sequence of tasks for a resource) then you have a good
critical path. This of course is essential for good management on a time
critical project. I would never therefore, consider adding extra milestones
with constraints. This must surely cause more work and confusion maintaining
the schedule than any possible benefits it delivers.

I always have milestones throughout my time frame as mini-targets. These all
have deadlines.

For the final deliverable date, I still leave this unconstrained as I need
Project to tell me when it looks like we will finish given everything we
know now. The deadline date raises a flag if we won't make the target date.

There are almost always tidy up tasks that can happen after the final
task/date so usually the one time a deadline date messes the critical path
(when it's on the last task) has never happened for me before.

 

[Michele]

Hi Jan,
Really thank you for reading me.
When you say that deadlines do not directly influence the schedule I can't
agree with you and to prove my reasons I suggest you to do the next tests:
Test 1

1) Create a new project scheduled from a start date, let’s assume that the
start date of the project is set to be 27/11/05 and then create three tasks,
called a, b, c.
2) Give the three tasks a duration of 1 day.
3) Link a and b (a as a predecessor of b) with Finish-to-Start relation with
2 days of positive lag.
4) The three tasks have the defaulted constraint “As soon as possibleâ€.
5) Now you have the critical chain of the project, made of the two tasks a
and b, and MS Project calculated consequently the finish date of the project
that is 01/12/05.
6) Associate to task c a deadline date equal to 05/12/05 and then change the
constraint of task c into “As late as possibleâ€
7) You will see that MS project will still wrongly indicate you that the
finish date of the project (In project information) is 01/12/05 and
consequently it will still indicate you that task a and b are critical, while
they should have both an amount of total slack equal to 1 day since the task
c is the only one task that determines the finish date of the project, that
is 05/12/05.
8) If, instead of associating to task c a deadline date, you create a
milestone d with 0 days of duration, you associate it a “Must start onâ€
constraint with a constraint date equal to 06/12/05 and you link to milestone
d the task c(c as a predecessor of d with 0 days of lag) leaving the
constraint of c equal to As late as possible you will see the correct
situation, that is a and b are not anymore critical and both have an amount
of total slack equal to 1 day and milestone d and c are both critical like
the way they should correctly be.
Test 2

1) Create a new project scheduled from a finish date, let’s assume that the
finish date of the project is set to be 02/12/05 and then create three tasks,
called a, b, c.
2) Give the three tasks a duration of 1 day.
3) Link a and b (a as a predecessor of b) with Finish-to-Start relation with
2 days of positive lag.
4) The three tasks have the defaulted constraint “As late as possibleâ€.
5) Now you have the critical chain of the project, made of the two tasks a
and b, and MS Project calculated consequently the start date of the project
that is 29/11/05.
6) Associate to task c a deadline date equal to 30/11/05 and leave the
constraint of task c equal to “As late as possibleâ€, Ms project correctly
schedules task c to start 30/11/05 and finish 30/11/05.
7) Associate to task c an actual start date equal to the current scheduled
start date, that is 30/11/05(with 0% of actual work), you will see that MS
project will wrongly make finish the task c on 01/12/05 and it will
consequently indicate you that task c finishes on 01/12/05 which is later
than its deadline on 30/11/05. So ,as you see, in this case the deadline date
does affects the schedule of task c, and that is proved by the fact that, if
you clear the deadline date of c, the schedule of c returns the one you had
at the beginning.
8) If, instead of associating to task c a deadline date, you create a
milestone d with 0 days of duration, you associate it a “Must start onâ€
constraint with a constraint date equal to 01/12/05 and you link to milestone
d the task c(c as a predecessor of d with 0 days of lag) leaving the
constraint of c equal to As late as possible(and clearing its actual start
date) you will see the correct situation that is task c starting 30/11/05 and
finishing 30/11/05 even if, then, I associate to task c an actual start date
equal to the current scheduled start date, that is 30/11/05(with 0% of actual
work), it will still correctly finish on 30/11/05.

I hope to have been enough clear.
Thank you Jan.
Best regards
Michele




"Jan De Messemaeker" ha scritto:

 

[Michele]

Hi Rod,
thanks a lot for reading me.
I do not agree with you regarding the fact that the only time deadlines
appear to cause "undesirable" behaviour is when the milestone with a deadline
is the last task in the schedule.
I think it's not the only case and i ask you, gently, to look at my answer
to Jan at this link
http://support.microsoft.com/newsgr...5-2823-471b-96ba-3474063dd8ee&sloc=it&sloc=it.
As for the rest, i think that, in facts, deadline dates are really
meaningless because for scheduling a certain task "x" you only should know if
there's some other task you need to finish before starting that task "x"(so
task "x" would be a successor of some other task) or if there's some other
task that can't start if it's not finished task "x"(so task "x" would be a
predecessor of some other task).
If task "x" needs no predecessor and no successor than this means that task
"x" can be accomplished in any period of the project duration(calculated by
the critical path) only according to resources availability.
Best regards
Michele

"Rod Gill" ha scritto:

 

[Rod Gill]

But that has nothing to do with a deadline?? A deadline simply says this
task has a deadline. The Start date reflects when you think the task will
finish given current knowledge. All the Deadline does is flag the task as
time critical and limits its slack time.

Everything else has to be driven by links if you want a realistic critical
path and a flexible schedule.

 

[John Sitka]

Thanks Michele, I appreciate your diligence in scrutinizing this issue.
I observered the same.

 

[Michele]

You are really welcome and kind John.
Best regards
Michele

"John Sitka" ha scritto:

 

[Michele]

Forgive me Rod but I really can’t understand your answer.
My previous answer to you was strictly related to the concept of deadline
because I think that associating a deadline date to a task is meaningless,
for the reasons I explained to you in that answer.
But while the one above is only my personal opinion, the objective proved
fact is that it is not absolutely true that "All the Deadline does is flag
the task as time critical and limits its slack time" because other than that
the Deadline , in some specific cases(that I describe answering to Jan at
this link
http://support.microsoft.com/newsgr...5-2823-471b-96ba-3474063dd8ee&sloc=it&sloc=it),
generates not correct results.
Best regards
Michele


"Rod Gill" ha scritto:

 

[Steve House [Project MVP]]

I don't understand why you think task deadlines are meaningless. The
project needs to be finished by 1 January - that's a deadline for the last
task in the project. 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. Deadlines are how you express the time
objectives that you are designing the plan to meet. 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. If it does, go with it. If it doesn't,
rework the plan by adding resources, changing the scope, etc.

IMHO, using deadlines and constraints to try to force tasks to be scheduled
in conformity to some a priori notion of the "proper" schedule is putting
the cart before the horse. I submit the best practice is to use MS Project
as a "what if" tool to help you discover what the optimum plan can be given
the assets you have to work with and the deliverables you need to accomplish
It's to discover the best plan, not to illustrate what you already believe
the best plan will be. Once you have discovered that optimum plan, that
becomes your project schedule, and you lock it into as the baseline and
track progress against it.

That's a major drawback of scheduling from finish date backwards - when you
first begin scheduling you really don't have any idea if that date is even
possible. Scheduling backwards from it is postulating as true the very
question you're seeking to answer - that is, "Do we have the resources to
accomplish this objective by the required completion date and if so, how do
we organize them most efficiently to achieve it?" By scheduling backwards
you're simply declaring you *will* finish on that date when you really have
no factual basis for that conclusion. Scheduling forward with a deadline on
the mandated finish date tells you if you can do it and how, what works and
what doesn't.
--

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

 

[John Sitka]

I don't think that is the intent of what Michele is trying to communicate.
The demo illustrates the erractic behaviour of the role of deadlines when
calculating a project planned to start as late as possible. But it's a tough thing
to think about correctly at any stetch. I think there is an addin that eliminates
the poor behaviour so critical chain progress can be properly represented.

Planing to start as late as possible is a sensible way to plan.
It's not like you are just sitting around waiting for the next project to start.
Everybody I know is constanly involved in a "current project".
All of us "That's what we do, That's why they call it work"
If I asked them to start the next thing ASAP I am merely distracting them and
am part of the cause of decreased performance. On a global level this translates
into high WIP counts for a company and that is expensive in so many ways.
Most obvious is the concept of leaving space between cars on a highway. When cars tailgate
and someone taps their brakes the car behind has to slow down just that wee
bit more for safety, mutiply this a thousand times and the chain comes to a standtill
If everybody left enough space so brakes would not need to be used react to
slight rate changes, highways would never gridlock. But the whole world thinks
that local optimization of getting right up close behind the guy in front is going
to get them there faster. Companies believe this as well. It isn't true. And since everybody
believes in that local optimization, gridlock. Just a change in thought would elliminate
slowdowns and make commutes a right enjoyable drive, same with work.
A real sad thing is accountants KNOW that the little extra bit of closeness to the car in
front is an important gain. Thus their KNOWledge cripples the means of production
at their companies.

 

[Jan De Messemaeker]

Hi Michele,

I forgot you are a fan of "As Late As Possible", something which in my
opinion does not work properly in Project, and I definitely will never use
schedule from finish date.
So I'm not arguing in that kind of world.
Project calculates late dates as well as early dates without me having to
use these constraints.

Sorry to have made you lose some time.

 

[Jan De Messemaeker]

Hi John,

Whilst we generally fully agree, her I'm afraid we don't.
In most "intellectual" or "immaterial" projects WIP is not very important,
and being late is definitely costlier.
Greetings,

--
Jan De Messemaeker
Microsoft Project Most Valuable Professional
http://users.online.be/prom-ade/
+32-495-300 620

I don't think that is the intent of what Michele is trying to communicate.
The demo illustrates the erractic behaviour of the role of deadlines when
calculating a project planned to start as late as possible. But it's a tough thing
to think about correctly at any stetch. I think there is an addin that eliminates
the poor behaviour so critical chain progress can be properly represented.

Planing to start as late as possible is a sensible way to plan.
It's not like you are just sitting around waiting for the next project to start.
Everybody I know is constanly involved in a "current project".
All of us "That's what we do, That's why they call it work"
If I asked them to start the next thing ASAP I am merely distracting them and
am part of the cause of decreased performance. On a global level this translates
into high WIP counts for a company and that is expensive in so many ways.
Most obvious is the concept of leaving space between cars on a highway. When cars tailgate
and someone taps their brakes the car behind has to slow down just that wee
bit more for safety, mutiply this a thousand times and the chain comes to a standtill
If everybody left enough space so brakes would not need to be used react to
slight rate changes, highways would never gridlock. But the whole world thinks
that local optimization of getting right up close behind the guy in front is going
to get them there faster. Companies believe this as well. It isn't true. And since everybody
believes in that local optimization, gridlock. Just a change in thought would elliminate
slowdowns and make commutes a right enjoyable drive, same with work.
A real sad thing is accountants KNOW that the little extra bit of closeness to the car in
front is an important gain. Thus their KNOWledge cripples the means of production
at their companies.

I don't understand why you think task deadlines are meaningless. The project needs to be finished by 1 January - that's a deadline
for the last task in the project. 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. Deadlines are how you express the time objectives that you are designing
the plan to meet. 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. If it does, go with it. If it doesn't,
rework the plan by adding resources, changing the scope, etc.

IMHO, using deadlines and constraints to try to force tasks to be scheduled in conformity to some a priori notion of the "proper"
schedule is putting the cart before the horse. I submit the best practice is to use MS Project as a "what if" tool to help you
discover what the optimum plan can be given the assets you have to work with and the deliverables you need to accomplish It's to
discover the best plan, not to illustrate what you already believe the best plan will be. Once you have discovered that optimum
plan, that becomes your project schedule, and you lock it into as the baseline and track progress against it.

That's a major drawback of scheduling from finish date backwards - when you first begin scheduling you really don't have any idea
if that date is even possible. Scheduling backwards from it is postulating as true the very question you're seeking to answer -
that is, "Do we have the resources to accomplish this objective by the required completion date and if so, how do we organize them
most efficiently to achieve it?" By scheduling backwards you're simply declaring you *will* finish on that date when you really
have no factual basis for that conclusion. Scheduling forward with a deadline on the mandated finish date tells you if you can do
it and how, what works and what doesn't.
--

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

http://support.microsoft.com/newsgroups/?dg=microsoft.public.project&mid=427
37055-2823-471b-96ba-3474063dd8ee&sloc=it&sloc=it), http://support.microsoft.com/newsgroups/?dg=microsoft.public.project&mid=427
37055-2823-471b-96ba-3474063dd8ee&sloc=it&sloc=it.

 

[John Sitka]

That's Ok I don't expect a whole lot of agreement.
Hundreds of accounting iterations almost assure it.

But lets pretend for the moment that money didn't matter and we built just for the joy of it.

Magic Company A produces units of joy. They take in pain, fear, loneliness. Through a highly refined
logical structure each resource in turn imparts work on those elements in their own speciallized
way. Each unit of pain, fear, loneliness has zero wait state once it enters or magic company
on it's transformation into the final assembly of joy. We happily pop out one completed joy deliverable per
week on average. Now someone decides we should start more transformation sooner so we can finish more sooner.
They offcourse did not resource level before hand as this company does not understand what the simple limits
of that are and they have no long range capacity visibility either they just believe that the sooner they start the sooner
they can deliver that extra unit of joy.
Now within our magic company we needed to bring in an extra new set of pain, fear, loneliness for processing,; so we can get to
work on that so we can finish sooner. We now have a rouge set of pain, hunger, distress that simply can not be handled
with our resource set as they are already working at the capacity of one completed joy deliverable per week
Thus our company always has extra elements of pain, fear, loneliness that have to be dealt with.
Now substitute materials for pain, overtime for fear and monies owed for distress.

Within the walls of an enterprise

more WIP......

Means more projects on the go, which generally means more starts and stops. Setup, concentration breaks, many humanistic examples of
loss of focus, flow and performance. A fractured team so to speak.

Means the scope of a project has more opportunity to change. Intellectual Projects never suffer from scope creep. no never. ;-)

Means you started sooner rather than later therefore you were not advantaged with the full experience of what your stakeholder's
final definition of deliverable
ie. Monday "I want a red pencil box" Tuesday "Can you make a color change, I want a blue pencil box"
vs Wednesday "Hi just calling to let you know we will be starting your red pencil box today.....What's that, you want blue, no
problem glad I called"
(I'm aware that change billing can be of significant magnitude, still I think seperate proper deliverables represent more customer
value.)

Means you have started some projects without the full body of experience to be gained from adjacent projects which could have been
observered and
experienced to completion.
That is if all four parallel projects are at some intermediary stage and all progressing at a similar rate, a mistake on one is a
mistake on all four as there is no prior
knowledge to avoid it. This just happen to us. Same mistake four times over. Some little local assembly line optimization occured,
everybody said hey nice work
that's really gonna speed us up. Instead of doing one thing incorrect and sending it down the line to be caught we sent four
identical mistakes down the line
to be caught. Which is the bigger screw up. All becasue of an aversion to staggered delivery of a four piece package and the false
belief that local speed equals better for the company.
After all it does make sense to batch four similar things together and do them all at the same time right? Then pass them on to the
next resource right?
Who could argue with this, it's so obvious. There is no point in getting one done obscenely early when all four could finish on
time. That is so obvious in all cases.

Means there is a need to demonstrate Progress to stake holders once they know THEIR project is on the go. As those stake holders are
also often blind
to the demerits of high WIP they set up internal political wrangling as to who should get priority.
Consider this one instance I hire some one to remodel my kitchen. Would you rather they were remodelling 3 other kitchens at the
same time or just yours.
If you have ever hired someone to remodel a kitchen you would gladdly wait a year to have their full attention once they start

Not all the answers I'm sure and probably a zillion perfect arguements to pick each point apart,
but these are some of the ones that I like.

 

[Steve House [Project MVP]]

I can see planning as late as possible as valuable when you are trying to
answer the question "How late could we possibly delay this kick off and
still finish by the required target date." But I'd never schedule and
monitor the actual work using such as a method. 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. To do otherwise is to put all your eggs in one basket with
the assumption nothing will ever go wrong with the plan and the one thing
you can count on is something will ALWAYS go wrong <grin>.
--
Steve House [MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

 

[Jan De Messemaeker]

Hi John,

We re discussing different points.
You are mostly talking portfolio management, I am talking about the effort
of a project leader to end his project in time.

Furthermore, you base quite a lot of your assertions on an assumption that
people are doing a bad job - easy to then say they are doing a bad job. I am
particularly shocked with (quote)

They offcourse did not resource level before hand as this company does not

understand what the simple limits

of that are and they have no long range capacity visibility

Why of course?
When you start by assuming their work is lousy, that will logically come out
as a conclusion.

Now on the value of timeliness.
I think most projects run around the world are about improving processes,
aiming at doing things better (in terms of cost, time to market, better
quality products..) so the conclusion of the project will be that from there
on the company will have better results. After all, that's why they do it in
the first place. So the sooner your project is done, the more profit. Before
you know your competitor comes up with a similar idea and your market is
gone.

In 1995 IBM Corp. was slowly but surely collapsing when they hired a new CEO
from the outside. He had only one message to employees:
"I want you to feel a true sense of urgency"
IBM is again alive and kicking!

And when I'm building a home, and I want to move in February next year, I
won't agree to the kitchen installer who is very sure to install in
September; late is late is late.
Note that I did move into this here house Feb 1, 1985 - exactly the day my
rent stopped at the previous house. I did that by fighting with every
contractor to get his best dates, not by waiting till he was very sure.

Now where we absolutely agree: you shoudn't start a task, let alone a
project, solely for the benefit of telling the sponsor: look, I'm working
for you" when you really don't have the time. Yes, people do that, but that
is not a consequence of aiming at early start dates, but of bad management.
The rule to avoid it is not to plan as late as possible (the least incident
will cause the action to be late and that can be extremely costly) but never
to accept percentages. Nobody works 20% or 50% or 56% of his brain. Start
something (as soon as possible taking into account resource availability),
then work it till it's finished.

Greetings,



--
Jan De Messemaeker
Microsoft Project Most Valuable Professional
http://users.online.be/prom-ade/
+32-495-300 620

That's Ok I don't expect a whole lot of agreement.
Hundreds of accounting iterations almost assure it.

But lets pretend for the moment that money didn't matter and we built just for the joy of it.

Magic Company A produces units of joy. They take in pain, fear,

loneliness. Through a highly refined

logical structure each resource in turn imparts work on those elements in their own speciallized
way. Each unit of pain, fear, loneliness has zero wait state once it enters or magic company
on it's transformation into the final assembly of joy. We happily pop out

one completed joy deliverable per

week on average. Now someone decides we should start more transformation

sooner so we can finish more sooner.

They offcourse did not resource level before hand as this company does not

understand what the simple limits

of that are and they have no long range capacity visibility either they

just believe that the sooner they start the sooner

they can deliver that extra unit of joy.
Now within our magic company we needed to bring in an extra new set of

pain, fear, loneliness for processing,; so we can get to

work on that so we can finish sooner. We now have a rouge set of pain,

hunger, distress that simply can not be handled

with our resource set as they are already working at the capacity of one

completed joy deliverable per week

Thus our company always has extra elements of pain, fear, loneliness that have to be dealt with.
Now substitute materials for pain, overtime for fear and monies owed for distress.

Within the walls of an enterprise

more WIP......

Means more projects on the go, which generally means more starts and

stops. Setup, concentration breaks, many humanistic examples of

loss of focus, flow and performance. A fractured team so to speak.

Means the scope of a project has more opportunity to change. Intellectual

Projects never suffer from scope creep. no never. ;-)

Means you started sooner rather than later therefore you were not

advantaged with the full experience of what your stakeholder's

final definition of deliverable
ie. Monday "I want a red pencil box" Tuesday "Can you make a color change, I want a blue pencil box"
vs Wednesday "Hi just calling to let you know we will be starting your red

pencil box today.....What's that, you want blue, no

problem glad I called"
(I'm aware that change billing can be of significant magnitude, still I

think seperate proper deliverables represent more customer

value.)

Means you have started some projects without the full body of experience

to be gained from adjacent projects which could have been

observered and
experienced to completion.
That is if all four parallel projects are at some intermediary stage and

all progressing at a similar rate, a mistake on one is a

mistake on all four as there is no prior
knowledge to avoid it. This just happen to us. Same mistake four times

over. Some little local assembly line optimization occured,

everybody said hey nice work
that's really gonna speed us up. Instead of doing one thing incorrect and

sending it down the line to be caught we sent four

identical mistakes down the line
to be caught. Which is the bigger screw up. All becasue of an aversion to

staggered delivery of a four piece package and the false

belief that local speed equals better for the company.
After all it does make sense to batch four similar things together and do

them all at the same time right? Then pass them on to the

next resource right?
Who could argue with this, it's so obvious. There is no point in getting

one done obscenely early when all four could finish on

time. That is so obvious in all cases.

Means there is a need to demonstrate Progress to stake holders once they

know THEIR project is on the go. As those stake holders are

also often blind
to the demerits of high WIP they set up internal political wrangling as to who should get priority.
Consider this one instance I hire some one to remodel my kitchen. Would

you rather they were remodelling 3 other kitchens at the

same time or just yours.
If you have ever hired someone to remodel a kitchen you would gladdly wait

a year to have their full attention once they start

 

[John Sitka]

That's not really what I was trying to say,
A goal may be considered to NOT introduce a load into a system before it is absolutely necessary.
What is absolutely necessary can be as variable as anyones definition but it starts with experience and is refined through
iteration.
I am merely saying most people Think the sooner you start the sooner you finish and that is utterly false in a system with
limited resources, and all resources are limited. I can't begin to describe how ingrained is the idea that sooner start = sooner
finish
is. It appears to me to be intractable(? can't be altered in a person's thought process). Planning as late as possible is the real
solution
as you make sure one of your foremost goals of the plan is not to introduce assignments into the system before it is necessary.
I'm not saying you do not protect yourself from failures and disappointments along the way. This is accomplished after the plan
has been modelled ALAP. But that is a much different thing than conceptualizing a project by multiloading resources just because
they
can be calculated as such. (ie. "We COULD start tomorrow", which translates to, "might as well get a jump on things" thus a plan is
built
to that false advantage) Truely that is the base assumption almost universally, that over a longer period there are "assummed" gaps
or
percentages of attention that those resources can handle.
(Just check what a large percentage of the posts here concern ;-)). Since the base assumption is wrong most plans are extremely poor
models to accomplish anything. But it does perpetuate a project planner industry as it lends support to what is already viewed as an
absolute condition. The sooner we start the sooner we finish. Each feeds of the other.
Start ASAP, destroy productivity. Start ALAP, with a post plan evaluated level of safety, and increase productivity.

 

[John Sitka]

Yes Jan, this is absolutely true.

You are mostly talking portfolio management, I am talking about the effort
of a project leader to end his project in time.

And that I guess is the difference, but I can't really think of WIP in any terms other than portfolios,

I basically think any skilled practice of Project management has as a consideration first and
foremost the portfolio, As soon as the conditions exist that resources are shared and limited and
that there is more than one project is going on at the same time. The success of that single Project Manager
is less than the expense to the others in the portfolio. It's not zero sum, it's worse. Because the system
itself (the portfolio) has a limit as to what it can produce. Any optimization by an individual, without direct
accountability to the impact on the whole system will introduce unrecoverables and waste.

You state this yourself

I did that by fighting with every
contractor to get his best dates, not by waiting till he was very sure.

So you came out on top but that gain was a cost somewhere else, invisible to you but not the company
the contractor worked for. Your contractors were totally outside your portfolio,
If you were the Toll Brothers you would have a different view as you would have your own crews.
Even to the point where you may be concerned about outside contractors (beyond your portfolio)
as it may impact their efforts within yours. Obviously this is a GLOBAL view. A strategy. Not a technique
or a practice. With a system global view, Why fight, it accomplishes nothing, just makes work that
little bit worse. I still stand by my reference that you are far better off getting a kitchen remodelled later
rather than sooner. I used to do such work and the quality and speed of that work was much greater
when I had fewer

Too much focus on technique without strategy, As a Software Designer I get this often.

Can you build me something to help me do X.
Why are you doing X?
Because it is the next step in a process that comes from Y.
Y of course is a much simpler automation than X.
So we solve Y and X ceases to exist. That solution is better.

Furthermore, you base quite a lot of your assertions on an assumption that
people are doing a bad job - easy to then say they are doing a bad job. I am
particularly shocked with (quote)

You are correct that was stupid of me to say and it is merely how the broken thought process
of tolerating high WIP values brings out a passionionate arguement.

It's not that they are doing a bad job, They are solving the wrong problem. There goal
should be to help the company, not themselves. and there is a dire lack of understanding that
just becasue you can, dosen't mean you should. This is in reference to WIP.

Hi John,

We re discussing different points.
You are mostly talking portfolio management, I am talking about the effort
of a project leader to end his project in time.

Furthermore, you base quite a lot of your assertions on an assumption that
people are doing a bad job - easy to then say they are doing a bad job. I am
particularly shocked with (quote)

They offcourse did not resource level before hand as this company does not

understand what the simple limits

of that are and they have no long range capacity visibility

Why of course?
When you start by assuming their work is lousy, that will logically come out
as a conclusion.

Now on the value of timeliness.
I think most projects run around the world are about improving processes,
aiming at doing things better (in terms of cost, time to market, better
quality products..) so the conclusion of the project will be that from there
on the company will have better results. After all, that's why they do it in
the first place. So the sooner your project is done, the more profit. Before
you know your competitor comes up with a similar idea and your market is
gone.

In 1995 IBM Corp. was slowly but surely collapsing when they hired a new CEO
from the outside. He had only one message to employees:
"I want you to feel a true sense of urgency"
IBM is again alive and kicking!

And when I'm building a home, and I want to move in February next year, I
won't agree to the kitchen installer who is very sure to install in
September; late is late is late.
Note that I did move into this here house Feb 1, 1985 - exactly the day my
rent stopped at the previous house. I did that by fighting with every
contractor to get his best dates, not by waiting till he was very sure.

Now where we absolutely agree: you shoudn't start a task, let alone a
project, solely for the benefit of telling the sponsor: look, I'm working
for you" when you really don't have the time. Yes, people do that, but that
is not a consequence of aiming at early start dates, but of bad management.
The rule to avoid it is not to plan as late as possible (the least incident
will cause the action to be late and that can be extremely costly) but never
to accept percentages. Nobody works 20% or 50% or 56% of his brain. Start
something (as soon as possible taking into account resource availability),
then work it till it's finished.

Greetings,



--
Jan De Messemaeker
Microsoft Project Most Valuable Professional
http://users.online.be/prom-ade/
+32-495-300 620

That's Ok I don't expect a whole lot of agreement.
Hundreds of accounting iterations almost assure it.

But lets pretend for the moment that money didn't matter and we built just for the joy of it.

Magic Company A produces units of joy. They take in pain, fear,

loneliness. Through a highly refined

logical structure each resource in turn imparts work on those elements in their own speciallized
way. Each unit of pain, fear, loneliness has zero wait state once it enters or magic company
on it's transformation into the final assembly of joy. We happily pop out

one completed joy deliverable per

week on average. Now someone decides we should start more transformation

sooner so we can finish more sooner.

They offcourse did not resource level before hand as this company does not

understand what the simple limits

of that are and they have no long range capacity visibility either they

just believe that the sooner they start the sooner

they can deliver that extra unit of joy.
Now within our magic company we needed to bring in an extra new set of

pain, fear, loneliness for processing,; so we can get to

work on that so we can finish sooner. We now have a rouge set of pain,

hunger, distress that simply can not be handled

with our resource set as they are already working at the capacity of one

completed joy deliverable per week

Thus our company always has extra elements of pain, fear, loneliness that have to be dealt with.
Now substitute materials for pain, overtime for fear and monies owed for distress.

Within the walls of an enterprise

more WIP......

Means more projects on the go, which generally means more starts and

stops. Setup, concentration breaks, many humanistic examples of

loss of focus, flow and performance. A fractured team so to speak.

Means the scope of a project has more opportunity to change. Intellectual

Projects never suffer from scope creep. no never. ;-)

Means you started sooner rather than later therefore you were not

advantaged with the full experience of what your stakeholder's

final definition of deliverable
ie. Monday "I want a red pencil box" Tuesday "Can you make a color change, I want a blue pencil box"
vs Wednesday "Hi just calling to let you know we will be starting your red

pencil box today.....What's that, you want blue, no

problem glad I called"
(I'm aware that change billing can be of significant magnitude, still I

think seperate proper deliverables represent more customer

value.)

Means you have started some projects without the full body of experience

to be gained from adjacent projects which could have been

observered and
experienced to completion.
That is if all four parallel projects are at some intermediary stage and

all progressing at a similar rate, a mistake on one is a

mistake on all four as there is no prior
knowledge to avoid it. This just happen to us. Same mistake four times

over. Some little local assembly line optimization occured,

everybody said hey nice work
that's really gonna speed us up. Instead of doing one thing incorrect and

sending it down the line to be caught we sent four

identical mistakes down the line
to be caught. Which is the bigger screw up. All becasue of an aversion to

staggered delivery of a four piece package and the false

belief that local speed equals better for the company.
After all it does make sense to batch four similar things together and do

them all at the same time right? Then pass them on to the

next resource right?
Who could argue with this, it's so obvious. There is no point in getting

one done obscenely early when all four could finish on

time. That is so obvious in all cases.

Means there is a need to demonstrate Progress to stake holders once they

know THEIR project is on the go. As those stake holders are

also often blind
to the demerits of high WIP they set up internal political wrangling as to who should get priority.
Consider this one instance I hire some one to remodel my kitchen. Would

you rather they were remodelling 3 other kitchens at the

same time or just yours.
If you have ever hired someone to remodel a kitchen you would gladdly wait

a year to have their full attention once they start

Not all the answers I'm sure and probably a zillion perfect arguements to pick each point apart,
but these are some of the ones that I like.




"Jan De Messemaeker" <jandemes at prom hyphen ade dot be> wrote in message news:[email protected]...

Hi John,

Whilst we generally fully agree, her I'm afraid we don't.
In most "intellectual" or "immaterial" projects WIP is not very important,
and being late is definitely costlier.
Greetings,

--
Jan De Messemaeker
Microsoft Project Most Valuable Professional
http://users.online.be/prom-ade/
+32-495-300 620
"John Sitka" <[email protected]> schreef in bericht
I don't think that is the intent of what Michele is trying to communicate.
The demo illustrates the erractic behaviour of the role of deadlines when
calculating a project planned to start as late as possible. But it's a
tough thing
to think about correctly at any stetch. I think there is an addin that
eliminates
the poor behaviour so critical chain progress can be properly represented.

Planing to start as late as possible is a sensible way to plan.
It's not like you are just sitting around waiting for the next project to
start.
Everybody I know is constanly involved in a "current project".
All of us "That's what we do, That's why they call it work"
If I asked them to start the next thing ASAP I am merely distracting them
and
am part of the cause of decreased performance. On a global level this
translates
into high WIP counts for a company and that is expensive in so many ways.
Most obvious is the concept of leaving space between cars on a highway.
When cars tailgate
and someone taps their brakes the car behind has to slow down just that
wee
bit more for safety, mutiply this a thousand times and the chain comes to
a standtill
If everybody left enough space so brakes would not need to be used react
to
slight rate changes, highways would never gridlock. But the whole world
thinks
that local optimization of getting right up close behind the guy in front
is going
to get them there faster. Companies believe this as well. It isn't true.
And since everybody
believes in that local optimization, gridlock. Just a change in thought
would elliminate
slowdowns and make commutes a right enjoyable drive, same with work.
A real sad thing is accountants KNOW that the little extra bit of
closeness to the car in
front is an important gain. Thus their KNOWledge cripples the means of
production
at their companies.



"Steve House [Project MVP]" <[email protected]>
wrote in message
I don't understand why you think task deadlines are meaningless. The
project needs to be finished by 1 January - that's a deadline
for the last task in the project. 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. Deadlines are
how you express the time objectives that you are designing
the plan to meet. 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. If it does, go with it. If it doesn't,
rework the plan by adding resources, changing the scope, etc.

IMHO, using deadlines and constraints to try to force tasks to be
scheduled in conformity to some a priori notion of the "proper"
schedule is putting the cart before the horse. I submit the best
practice is to use MS Project as a "what if" tool to help you
discover what the optimum plan can be given the assets you have to work
with and the deliverables you need to accomplish It's to
discover the best plan, not to illustrate what you already believe the
best plan will be. Once you have discovered that optimum
plan, that becomes your project schedule, and you lock it into as the
baseline and track progress against it.

That's a major drawback of scheduling from finish date backwards - when
you first begin scheduling you really don't have any idea
if that date is even possible. Scheduling backwards from it is
postulating as true the very question you're seeking to answer -
that is, "Do we have the resources to accomplish this objective by the
required completion date and if so, how do we organize them
most efficiently to achieve it?" By scheduling backwards you're simply
declaring you *will* finish on that date when you really
have no factual basis for that conclusion. Scheduling forward with a
deadline on the mandated finish date tells you if you can do
it and how, what works and what doesn't.
--

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



Forgive me Rod but I really canâ?Tt understand your answer.
My previous answer to you was strictly related to the concept of
deadline
because I think that associating a deadline date to a task is
meaningless,
for the reasons I explained to you in that answer.
But while the one above is only my personal opinion, the objective
proved
fact is that it is not absolutely true that "All the Deadline does is
flag
the task as time critical and limits its slack time" because other than
that
the Deadline , in some specific cases(that I describe answering to Jan
at
this link

http://support.microsoft.com/newsgroups/?dg=microsoft.public.project&mid=427
37055-2823-471b-96ba-3474063dd8ee&sloc=it&sloc=it),
generates not correct results.
Best regards
Michele


"Rod Gill" ha scritto:

But that has nothing to do with a deadline?? A deadline simply says
this
task has a deadline. The Start date reflects when you think the task
will
finish given current knowledge. All the Deadline does is flag the task
as
time critical and limits its slack time.

Everything else has to be driven by links if you want a realistic
critical
path and a flexible schedule.

--

Rod Gill
Project MVP
Visit www.msproject-systems.com for Project Companion Tools and more


Hi Rod,
thanks a lot for reading me.
I do not agree with you regarding the fact that the only time
deadlines
appear to cause "undesirable" behaviour is when the milestone with a
deadline
is the last task in the schedule.
I think it's not the only case and i ask you, gently, to look at my
answer
to Jan at this link

http://support.microsoft.com/newsgroups/?dg=microsoft.public.project&mid=427
37055-2823-471b-96ba-3474063dd8ee&sloc=it&sloc=it.
As for the rest, i think that, in facts, deadline dates are really
meaningless because for scheduling a certain task "x" you only
should know
if
there's some other task you need to finish before starting that task
"x"(so
task "x" would be a successor of some other task) or if there's some
other
task that can't start if it's not finished task "x"(so task "x"
would be a
predecessor of some other task).
If task "x" needs no predecessor and no successor than this means
that
task
"x" can be accomplished in any period of the project
duration(calculated
by
the critical path) only according to resources availability.
Best regards
Michele

"Rod Gill" ha scritto:

The only time deadlines appear to cause "undesirable" behaviour is
when
the
milestone with a deadline is the last task in the schedule.

I am a firm believer that as many tasks as possible be driven only
by
their
dates. The more time critical the project the more important this
is.
With
only links to drive tasks (even if you have to add links to some
tasks to
show an arbitrary sequence of tasks for a resource) then you have a
good
critical path. This of course is essential for good management on a
time
critical project. I would never therefore, consider adding extra
milestones
with constraints. This must surely cause more work and confusion
maintaining
the schedule than any possible benefits it delivers.

I always have milestones throughout my time frame as mini-targets.
These
all
have deadlines.

For the final deliverable date, I still leave this unconstrained as
I
need
Project to tell me when it looks like we will finish given
everything we
know now. The deadline date raises a flag if we won't make the
target
date.

There are almost always tidy up tasks that can happen after the
final
task/date so usually the one time a deadline date messes the
critical
path
(when it's on the last task) has never happened for me before.

--

Rod Gill
Project MVP
Visit www.msproject-systems.com for Project Companion Tools and
more


I forgot to write that the milestone task must have a constraint
equal
to
"Must start on" and the constraint date must be the deadline date
one
wants
to associate to a task.
Best regard
Michele

"Michele" ha scritto:

As greatly suggested to me by John Jensen I found a work around
to
achieve my
objective in scheduling a project using MS project.
While I am convinced that the engine of MS project software is
working
fine
regarding the backward pass and forward pass, I am convinced, on
the
opposite, that associating a deadline date to a task MAY
have(ONLY IN
CERTAIN
SPECIFIC CASES) bad consequences on the engine of Project,
causing
illogical
and not correct results.
For anyone who was interested in knowing which are the cases I
describe
above I am helpful to write him/her.(Anyway they are mostly
related to
the
tracking of the tasks)
The work around I found about avoiding to use deadline dates is
to
create(one for each task one wants to associate a deadline date,
clearly
only
if the deadline dates are different)a milestone task(With 0 days
of
duration)
and link the task u want to associate a deadline date to the
milestone
task
with Finish-to-Start relation.
In this way all work fine, even and especially when the planner
starts
tracking that task.
I hope that this advice can be helpful to anyone of you.
Best regards
Michele