Lag / Lead Time

[JR Winder]

I have a task (A) that will require 7.2 hours of work but is not estimated
to finish for 10 days. Another task (B) has a FS link to task A.

My questions pertains to the best way to account for the estimated 10 days
it will require task A to complete.

Should task B have a FS+10 days lag time? Or am I better off putting a
constraint type of "Finish No Later Than" on task A.

Right now I have task B linked to A with a FS+10 Days, What prompted my
question is that task A is scheduled to start on 8/10/07 and end on 8/11/07
(7.2hrs), when in reality it isn't estimated to end until 8/24/07.

Thanks in advance for your assistance.

JR

 

[Jan De Messemaeker]

Hoi,

No Lag, No constraint.
Task A should have Work=7,2 hrs and Duration=10 days.
Then a normal FS link will do.
About how to do it, read >Julie's post on "enter work to get duration" fo
today.
HTH

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

 

[JR Winder]

Thanks Jan, that makes sense. Would it be possible for you to foward
Julie's post "enter work to get duration"? I can't seem to locate it.

Thanks

 

[JulieS]

Hi JR,

It's likely Jan is off-line right now. I've copied the post Jan
referred to below.
--------------------------------------------------------------
You can create the task and leave the duration at the default of "1day?"
Then create the resource and when you assign the resource to the task,
enter the work. Project will recalculate the duration of the task based
upon the formula:

Work/Unit = Duration.

By default Project will assign the resource at his/her maximum unit that
you set in the Resource Sheet when you created the resource. Without
resource assigned however, entering work will not calculate duration for
you. You may find working with the Task Form at the bottom of the
screen is very useful as you get to manipulate all three pieces of the
relationship. From the Gantt chart view choose Window > Split in the
menu to display the Task form.

As you are new to project, I suggest taking a read of fellow MVP Mike
Glen's excellent series of articles on MS Project. You can find the
link to Mike's articles at:

http://project.mvps.org/mike's_tutorials.htm

--------------------------------------------------

I hope this helps. Let us know how you get along.

Julie
Project MVP

Visit http://project.mvps.org/ for the FAQs and additional information
about Microsoft Project

 

[Steve House]

Just a point to ponder ... if the work only requires 7.2 hours of actual
work (how do you estimate work that precisely, anyway? That's 3% accuracy!)
why are you letting the resource have 10 times that length of time it which
to do it? As PM you should be calling the shots - go to that resource at
tell them "It looks like everything will be ready for you to start that task
Tuesday afternoon or first thing Wednesday morning so can I count on you
having it finished by the end of the day Wednesday?" Now it could be that
there are other things on the resource's plate that mean it'll take him
longer and of course consult with him so as to take that into account, but
my suggestion is to stop thinking in terms of windows of opportunity and
instead focus on how soon you can get your resources to finish the work. As
Larry the Cable Guy says, "Just git 'er done."

 

[Steve House]

Organizational psychologists often describe positions within a hierarchy in
terms of the holder having a mix of position power and personal power. The
CEO's administrative assistant may have little official authority within the
corporate hierarchy but none the less he or she exerts tremendous influence,
they hold the keys to the throne, and as such exercises tremendous personal
power.

Certainly it can be true, as you say, that the PM may have relatively little
position power in the sense of being able to mandate the performance of
resources. But even so, he is the sole individual charged with the ultimate
responsibility for fulfilling the portion of the organization's strategic
plan the project represents. Like the captain of naval ship acting on
orders from the admiral, the PM is the management person responsible for
*making sure* the project is completed in the most efficient manner. The
buck stops with him and it's his butt that gets fired if it doesn't happen.
So if they don't have the position power to mandate the performance from
resources that will make it so, they have to call on personal power -
negotiation skills, argument, calling in favours, astute application of
political relationships, etc - to make it sure it happens the way they have
determined it MUST happen for the project to be a success. The project
manager is not, in my opinion, a beaurocrat monitoring the performance of
resources who might suggest that they behave and prioritize in a certain
way. Rather he is the one that determines what the plan *will be* and then
does whatever it takes to insure that people follow it - He, not the
resources and not the resource's managers, is the one who organizes the
project. While he might have to be very indirect and political about how he
achieves it, the bottom line is it's still his job to tell the resources
what to do and when it has to be done and regardless of exactly how he goes
about it, he needs to keep clear in his own mind that that is his bottom
line responsibility and no one else's. The PM is the one who determines what
must happen and when it must happen in order to bring the project to a
successful conclusion and then exercises both position power, if he has it,
and personal power if he does not, to make certain that it happens in that
manner, just like the captain of the ship always has the final decision as
to its course even if he sometimes listens to the suggestions of the
helmsman.

I don't know why you say a MSO constraint warns you if a negotiated start
date isn't going to be met - it does exactly the opposite and tells Project
to always show that the start will occur as required regardless of what's
going on before it! It doesn't give you a warning at all, on the contrary
it lies and shows all is well and starting on time even when it's definitely
NOT well. (It would be nice to have the option of applying start deadlines
as well as finish deadlines, though.)

I oppose the use of MSO, MFO, and MFNLT constraints because of the way they
cripple the Project scheduling engine. It boils down to why I think one
bothers to use scheduling software in the first place. I already know what
the requirements are and I don't need to document them again. My task, once
I sit down to plan, the task for which I'm using software in the first
place, is to figure out just how I have to organize the work so those
requirements are met. To do that, the software must show me the
consequences of my decisions - will deploying the resources in such and such
a manner lead to success or failure? Applying a fixed date constraint to a
task, that means that no matter what else is happening in the schedule,
Project will NEVER, under any circumstance (unless one disables "tasks
always obey their constraints" in which case why bother with the constraint
in the first place?), show it happening on any other than the specified
date. Nothing can make it move. So the existence of the constraints means
Project will not predict success or failure as it should - instead it always
promises success. While indeed it may be imperative within the mandate
you've been given that they not be allowed to move, that doesn't mean that
reality won't intrude - unless you organize it right, tasks fail to meet
deadlines all the time (unfortunately). A requirement doesn't mean it's
impossible for it to move, only that it ought not move, and we all know of
situations where requirements are not met. I suggest that the primary
purpose of project software having a dynamic schedule calculation engine is
NOT to document the requirements, it's rather to give you a tool to predict
whether the plan as you have organized it is going to achieve those
requirements. Its job is to predict success or failure given a proposed
workflow and resource loading. Fixed dates in the plan mean that you're
using the software as little more than a fancy hi-tech version of a wall
calendar with a big red circle drawn around critical deadlines - forcing the
schedule to always lock those tasks to the designated dates means you have
crippled its ability to predict whether your workflow is actually going to
achieve them. It always promises your plan will be successful even when its
physically impossible for it to actually happen that way because it never
shows your tasks moving away from the dates where they ought to occur.
--
Steve House [Project 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
Hi Steve,

I'm afraid I already wrote this, but are you aware that your image of
project management represents IMHO only a minority of projects?
Most organisations I know run projects in a matrix structure, such that
project leaders have no (like in ZERO, NONE) hierarchic power over those who
perform.
An important part of their job is to negotiate with (internal or external)
subcontractors about when they will perform, or even just when they intend
to deliver. That is not what I call "calling the shots".
This doesn't render the usage of MS Project less important, only different.
For instance once they have agreed with a subcontractor they may well use a
Must Start On constraint, for instance to be warned by Project when a task
leading up to the subcon's agreed date may jeopardize that agreement.
Management in such cases is done far more based on duration and constraints,
and it is typical for that project orhganisation and management.

And BTW, I guess 7,2 hrs of work is just an estimate for 1 day, but as
Project's default for Work is in hours, people may call it that way.

Greetings,

--
Jan De Messemaeker
Microsoft Project MVP
http://users.online.be/prom-ade

Just a point to ponder ... if the work only requires 7.2 hours of actual
work (how do you estimate work that precisely, anyway? That's 3%
accuracy!)
why are you letting the resource have 10 times that length of time it
which
to do it? As PM you should be calling the shots - go to that resource at
tell them "It looks like everything will be ready for you to start that
task
Tuesday afternoon or first thing Wednesday morning so can I count on you
having it finished by the end of the day Wednesday?" Now it could be that
there are other things on the resource's plate that mean it'll take him
longer and of course consult with him so as to take that into account, but
my suggestion is to stop thinking in terms of windows of opportunity and
instead focus on how soon you can get your resources to finish the work.
As
Larry the Cable Guy says, "Just git 'er done."
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

I have a task (A) that will require 7.2 hours of work but is not estimated
to finish for 10 days. Another task (B) has a FS link to task A.

My questions pertains to the best way to account for the estimated 10
days
it will require task A to complete.

Should task B have a FS+10 days lag time? Or am I better off putting a
constraint type of "Finish No Later Than" on task A.

Right now I have task B linked to A with a FS+10 Days, What prompted my
question is that task A is scheduled to start on 8/10/07 and end on
8/11/07 (7.2hrs), when in reality it isn't estimated to end until
8/24/07.

Thanks in advance for your assistance.

JR

 

[Jan De Messemaeker]

Hi,

Wow, what a reaction.
Prioritisation is not only a mùatter of dates, I mostly use Total Slack to
determine priorities.
And when on a futuire intervention of a subcontractor I have a SNET
constraint, Project won't alert me if I'm getti,ng late on tasks leading up
to that intervention.
To the contrary when I set an MSO constraint, slack in the tasks leading up
to it will alert me correctly if I slip on these tasks.
So then Project predicts success based on what I have to do right now!

When any action is agreed upon solemnly between parties, it becomes MSO.
Commitment is commitment.
Greetings,

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

Organizational psychologists often describe positions within a hierarchy
in terms of the holder having a mix of position power and personal power.
The CEO's administrative assistant may have little official authority
within the corporate hierarchy but none the less he or she exerts
tremendous influence, they hold the keys to the throne, and as such
exercises tremendous personal power.

Certainly it can be true, as you say, that the PM may have relatively
little position power in the sense of being able to mandate the
performance of resources. But even so, he is the sole individual charged
with the ultimate responsibility for fulfilling the portion of the
organization's strategic plan the project represents. Like the captain of
naval ship acting on orders from the admiral, the PM is the management
person responsible for *making sure* the project is completed in the most
efficient manner. The buck stops with him and it's his butt that gets
fired if it doesn't happen. So if they don't have the position power to
mandate the performance from resources that will make it so, they have to
call on personal power - negotiation skills, argument, calling in favours,
astute application of

political relationships, etc - to make it sure it happens the way they
have determined it MUST happen for the project to be a success. The
project manager is not, in my opinion, a beaurocrat monitoring the
performance of resources who might suggest that they behave and prioritize
in a certain way. Rather he is the one that determines what the plan
*will be* and then does whatever it takes to insure that people follow
it - He, not the resources and not the resource's managers, is the one who
organizes the project. While he might have to be very indirect and
political about how he achieves it, the bottom line is it's still his job
to tell the resources what to do and when it has to be done and regardless
of exactly how he goes about it, he needs to keep clear in his own mind
that that is his bottom line responsibility and no one else's. The PM is
the one who determines what must happen and when it must happen in order
to bring the project to a successful conclusion and then exercises both
position power, if he has it, and personal power if he does not, to make
certain that it happens in that manner, just like the captain of the ship
always has the final decision as to its course even if he sometimes
listens to the suggestions of the helmsman.

I don't know why you say a MSO constraint warns you if a negotiated start
date isn't going to be met - it does exactly the opposite and tells
Project to always show that the start will occur as required regardless of
what's going on before it! It doesn't give you a warning at all, on the
contrary it lies and shows all is well and starting on time even when it's
definitely NOT well. (It would be nice to have the option of applying
start deadlines as well as finish deadlines, though.)

I oppose the use of MSO, MFO, and MFNLT constraints because of the way
they cripple the Project scheduling engine. It boils down to why I think
one bothers to use scheduling software in the first place. I already know
what the requirements are and I don't need to document them again. My
task, once I sit down to plan, the task for which I'm using software in
the first place, is to figure out just how I have to organize the work so
those requirements are met. To do that, the software must show me the
consequences of my decisions - will deploying the resources in such and
such a manner lead to success or failure? Applying a fixed date constraint
to a task, that means that no matter what else is happening in the
schedule, Project will NEVER, under any circumstance (unless one disables
"tasks always obey their constraints" in which case why bother with the
constraint in the first place?), show it happening on any other than the
specified date. Nothing can make it move. So the existence of the
constraints means Project will not predict success or failure as it
should - instead it always promises success. While indeed it may be
imperative within the mandate you've been given that they not be allowed
to move, that doesn't mean that reality won't intrude - unless you
organize it right, tasks fail to meet deadlines all the time
(unfortunately). A requirement doesn't mean it's impossible for it to
move, only that it ought not move, and we all know of situations where
requirements are not met. I suggest that the primary purpose of project
software having a dynamic schedule calculation engine is NOT to document
the requirements, it's rather to give you a tool to predict whether the
plan as you have organized it is going to achieve those requirements. Its
job is to predict success or failure given a proposed workflow and
resource loading. Fixed dates in the plan mean that you're using the
software as little more than a fancy hi-tech version of a wall calendar
with a big red circle drawn around critical deadlines - forcing the
schedule to always lock those tasks to the designated dates means you have
crippled its ability to predict whether your workflow is actually going to
achieve them. It always promises your plan will be successful even when
its physically impossible for it to actually happen that way because it
never shows your tasks moving away from the dates where they ought to
occur.
--
Steve House [Project 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
Hi Steve,

I'm afraid I already wrote this, but are you aware that your image of
project management represents IMHO only a minority of projects?
Most organisations I know run projects in a matrix structure, such that
project leaders have no (like in ZERO, NONE) hierarchic power over those
who perform.
An important part of their job is to negotiate with (internal or external)
subcontractors about when they will perform, or even just when they intend
to deliver. That is not what I call "calling the shots".
This doesn't render the usage of MS Project less important, only
different.
For instance once they have agreed with a subcontractor they may well use
a Must Start On constraint, for instance to be warned by Project when a
task leading up to the subcon's agreed date may jeopardize that agreement.
Management in such cases is done far more based on duration and
constraints, and it is typical for that project orhganisation and
management.

And BTW, I guess 7,2 hrs of work is just an estimate for 1 day, but as
Project's default for Work is in hours, people may call it that way.

Greetings,

--
Jan De Messemaeker
Microsoft Project MVP
http://users.online.be/prom-ade

Just a point to ponder ... if the work only requires 7.2 hours of actual
work (how do you estimate work that precisely, anyway? That's 3%
accuracy!)
why are you letting the resource have 10 times that length of time it
which
to do it? As PM you should be calling the shots - go to that resource at
tell them "It looks like everything will be ready for you to start that
task
Tuesday afternoon or first thing Wednesday morning so can I count on you
having it finished by the end of the day Wednesday?" Now it could be
that
there are other things on the resource's plate that mean it'll take him
longer and of course consult with him so as to take that into account,
but
my suggestion is to stop thinking in terms of windows of opportunity and
instead focus on how soon you can get your resources to finish the work.
As
Larry the Cable Guy says, "Just git 'er done."
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

I have a task (A) that will require 7.2 hours of work but is not
estimated
to finish for 10 days. Another task (B) has a FS link to task A.

My questions pertains to the best way to account for the estimated 10
days
it will require task A to complete.

Should task B have a FS+10 days lag time? Or am I better off putting a
constraint type of "Finish No Later Than" on task A.

Right now I have task B linked to A with a FS+10 Days, What prompted my
question is that task A is scheduled to start on 8/10/07 and end on
8/11/07 (7.2hrs), when in reality it isn't estimated to end until
8/24/07.

Thanks in advance for your assistance.

JR

 

[Steve House]

Yes, of course commitment is commitment. But have things unforeseen never
caused you to miss a commitment you have made, for instance, ever made
payment a day or so late? Project's displayed dates are not, IMHO, intended
to document the commitments that have been made. IMHO, the reason to use
software instead of just a pencil and paper to-do list is to create a "What
If" analytic tool to predict whether the commitments that have been made
will actually be achieved and if not, how late (or early, for that matter)
they will be. It is first and foremost a forecasting tool and for it to
take performance to date and from that forecast when future Task X will be
able to take place, you can't prevent the task's free movement by
constraining it. To do so is exactly as if you created a "What If" profit
optimization model in Excel and somehow managed to constrain it so that it
would never go negative to show that some pricing structures would result in
a loss. Let's see, we should not exceed a total of 10 ... 5+3=8, 5+4=9,
5+5=10, 5+6=10, 5+7=10, 5+8=10 ... that's exactly what a constraint (in this
case a FNLT) does in a project's schedule model and the forecast of
achievable project progress one obtains in such as case is just a fallacious
as is my arithmetic here. As long as the forecast is acceptable the
calculations are correct. But as soon as you get into trouble, and
predicting trouble is the only reason to bother with the exercise in the
first place, it no longer works. It fails you in what you need it most to
do, keeping you out of trouble. Using a MSO or MSNLT or MFNLT to indicate
an agreed upon start or delivery date means your plan will never warn you if
that commitment is not going to be met, it always will promise on-time
performance.

I know you like to use the numerical slack values and look for negative
slack but frankly, scanning down a column of numbers to find those slacks
that don't look right would drive me nuts. Give me a model showing me where
things are predicted to end up if we keep on our present course along with
nice red flags if the predicted result are not where it ought to be. But
show me what I'm GOING to get unless I change direction instead of what I
OUGHT to get. I know where I ought to be, I'm using the software to find
out if I'm going to make it or not and if not, to figure out what I can do
about it. To do that, it must show me the results that would be obtained
for each option I might consider.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Hi,

Wow, what a reaction.
Prioritisation is not only a mùatter of dates, I mostly use Total Slack to
determine priorities.
And when on a futuire intervention of a subcontractor I have a SNET
constraint, Project won't alert me if I'm getti,ng late on tasks leading
up to that intervention.
To the contrary when I set an MSO constraint, slack in the tasks leading
up to it will alert me correctly if I slip on these tasks.
So then Project predicts success based on what I have to do right now!

When any action is agreed upon solemnly between parties, it becomes MSO.
Commitment is commitment.
Greetings,

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

Organizational psychologists often describe positions within a hierarchy
in terms of the holder having a mix of position power and personal power.
The CEO's administrative assistant may have little official authority
within the corporate hierarchy but none the less he or she exerts
tremendous influence, they hold the keys to the throne, and as such
exercises tremendous personal power.

Certainly it can be true, as you say, that the PM may have relatively
little position power in the sense of being able to mandate the
performance of resources. But even so, he is the sole individual charged
with the ultimate responsibility for fulfilling the portion of the
organization's strategic plan the project represents. Like the captain
of naval ship acting on orders from the admiral, the PM is the management
person responsible for *making sure* the project is completed in the most
efficient manner. The buck stops with him and it's his butt that gets
fired if it doesn't happen. So if they don't have the position power to
mandate the performance from resources that will make it so, they have to
call on personal power - negotiation skills, argument, calling in
favours, astute application of

political relationships, etc - to make it sure it happens the way they
have determined it MUST happen for the project to be a success. The
project manager is not, in my opinion, a beaurocrat monitoring the
performance of resources who might suggest that they behave and
prioritize in a certain way. Rather he is the one that determines what
the plan *will be* and then does whatever it takes to insure that people
follow it - He, not the resources and not the resource's managers, is the
one who organizes the project. While he might have to be very indirect
and political about how he achieves it, the bottom line is it's still his
job to tell the resources what to do and when it has to be done and
regardless of exactly how he goes about it, he needs to keep clear in his
own mind that that is his bottom line responsibility and no one else's.
The PM is the one who determines what must happen and when it must happen
in order to bring the project to a successful conclusion and then
exercises both position power, if he has it, and personal power if he
does not, to make certain that it happens in that manner, just like the
captain of the ship always has the final decision as to its course even
if he sometimes listens to the suggestions of the helmsman.

I don't know why you say a MSO constraint warns you if a negotiated start
date isn't going to be met - it does exactly the opposite and tells
Project to always show that the start will occur as required regardless
of what's going on before it! It doesn't give you a warning at all, on
the contrary it lies and shows all is well and starting on time even when
it's definitely NOT well. (It would be nice to have the option of
applying start deadlines as well as finish deadlines, though.)

I oppose the use of MSO, MFO, and MFNLT constraints because of the way
they cripple the Project scheduling engine. It boils down to why I think
one bothers to use scheduling software in the first place. I already
know what the requirements are and I don't need to document them again.
My task, once I sit down to plan, the task for which I'm using software
in the first place, is to figure out just how I have to organize the work
so those requirements are met. To do that, the software must show me the
consequences of my decisions - will deploying the resources in such and
such a manner lead to success or failure? Applying a fixed date
constraint to a task, that means that no matter what else is happening in
the schedule, Project will NEVER, under any circumstance (unless one
disables "tasks always obey their constraints" in which case why bother
with the constraint in the first place?), show it happening on any other
than the specified date. Nothing can make it move. So the existence of
the constraints means Project will not predict success or failure as it
should - instead it always promises success. While indeed it may be
imperative within the mandate you've been given that they not be allowed
to move, that doesn't mean that reality won't intrude - unless you
organize it right, tasks fail to meet deadlines all the time
(unfortunately). A requirement doesn't mean it's impossible for it to
move, only that it ought not move, and we all know of situations where
requirements are not met. I suggest that the primary purpose of project
software having a dynamic schedule calculation engine is NOT to document
the requirements, it's rather to give you a tool to predict whether the
plan as you have organized it is going to achieve those requirements.
Its job is to predict success or failure given a proposed workflow and
resource loading. Fixed dates in the plan mean that you're using the
software as little more than a fancy hi-tech version of a wall calendar
with a big red circle drawn around critical deadlines - forcing the
schedule to always lock those tasks to the designated dates means you
have crippled its ability to predict whether your workflow is actually
going to achieve them. It always promises your plan will be successful
even when its physically impossible for it to actually happen that way
because it never shows your tasks moving away from the dates where they
ought to occur.
--
Steve House [Project 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 Hi Steve,

I'm afraid I already wrote this, but are you aware that your image of
project management represents IMHO only a minority of projects?
Most organisations I know run projects in a matrix structure, such that
project leaders have no (like in ZERO, NONE) hierarchic power over those
who perform.
An important part of their job is to negotiate with (internal or
external) subcontractors about when they will perform, or even just when
they intend to deliver. That is not what I call "calling the shots".
This doesn't render the usage of MS Project less important, only
different.
For instance once they have agreed with a subcontractor they may well use
a Must Start On constraint, for instance to be warned by Project when a
task leading up to the subcon's agreed date may jeopardize that
agreement.
Management in such cases is done far more based on duration and
constraints, and it is typical for that project orhganisation and
management.

And BTW, I guess 7,2 hrs of work is just an estimate for 1 day, but as
Project's default for Work is in hours, people may call it that way.

Greetings,

--
Jan De Messemaeker
Microsoft Project MVP
http://users.online.be/prom-ade

Just a point to ponder ... if the work only requires 7.2 hours of actual
work (how do you estimate work that precisely, anyway? That's 3%
accuracy!)
why are you letting the resource have 10 times that length of time it
which
to do it? As PM you should be calling the shots - go to that resource
at
tell them "It looks like everything will be ready for you to start that
task
Tuesday afternoon or first thing Wednesday morning so can I count on you
having it finished by the end of the day Wednesday?" Now it could be
that
there are other things on the resource's plate that mean it'll take him
longer and of course consult with him so as to take that into account,
but
my suggestion is to stop thinking in terms of windows of opportunity and
instead focus on how soon you can get your resources to finish the work.
As
Larry the Cable Guy says, "Just git 'er done."
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


I have a task (A) that will require 7.2 hours of work but is not
estimated
to finish for 10 days. Another task (B) has a FS link to task A.

My questions pertains to the best way to account for the estimated 10
days
it will require task A to complete.

Should task B have a FS+10 days lag time? Or am I better off putting a
constraint type of "Finish No Later Than" on task A.

Right now I have task B linked to A with a FS+10 Days, What prompted my
question is that task A is scheduled to start on 8/10/07 and end on
8/11/07 (7.2hrs), when in reality it isn't estimated to end until
8/24/07.

Thanks in advance for your assistance.

JR

 

[Jan De Messemaeker]

Hi,

Two details here.
Scanning for negative slack is extremely simple (make a filter or simply use
the auto filter)
And a project manager is not the top of the world. If you have to present
your project to the board of directors on September 2nd f.i., it doesn't
make sense to plan that activity on September 7 (nor on August 30, for that
matter), whatever the other tasks may say: an appointment is an appointment,
you shouldn't pin any other date on it, that is fooling yourself.

--
Jan De Messemaeker
Microsoft Project MVP
http://users.online.be/prom-ade

Yes, of course commitment is commitment. But have things unforeseen never
caused you to miss a commitment you have made, for instance, ever made
payment a day or so late? Project's displayed dates are not, IMHO,
intended to document the commitments that have been made. IMHO, the
reason to use software instead of just a pencil and paper to-do list is to
create a "What If" analytic tool to predict whether the commitments that
have been made will actually be achieved and if not, how late (or early,
for that matter) they will be. It is first and foremost a forecasting
tool and for it to take performance to date and from that forecast when
future Task X will be able to take place, you can't prevent the task's
free movement by constraining it. To do so is exactly as if you created a
"What If" profit optimization model in Excel and somehow managed to
constrain it so that it would never go negative to show that some pricing
structures would result in a loss. Let's see, we should not exceed a
total of 10 ... 5+3=8, 5+4=9, 5+5=10, 5+6=10, 5+7=10, 5+8=10 ... that's
exactly what a constraint (in this case a FNLT) does in a project's
schedule model and the forecast of achievable project progress one obtains
in such as case is just a fallacious as is my arithmetic here. As long as
the forecast is acceptable the calculations are correct. But as soon as
you get into trouble, and predicting trouble is the only reason to bother
with the exercise in the first place, it no longer works. It fails you in
what you need it most to do, keeping you out of trouble. Using a MSO or
MSNLT or MFNLT to indicate an agreed upon start or delivery date means
your plan will never warn you if that commitment is not going to be met,
it always will promise on-time performance.

I know you like to use the numerical slack values and look for negative
slack but frankly, scanning down a column of numbers to find those slacks
that don't look right would drive me nuts. Give me a model showing me
where things are predicted to end up if we keep on our present course
along with nice red flags if the predicted result are not where it ought
to be. But show me what I'm GOING to get unless I change direction
instead of what I OUGHT to get. I know where I ought to be, I'm using the
software to find out if I'm going to make it or not and if not, to figure
out what I can do about it. To do that, it must show me the results that
would be obtained for each option I might consider.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Hi,

Wow, what a reaction.
Prioritisation is not only a mùatter of dates, I mostly use Total Slack
to determine priorities.
And when on a futuire intervention of a subcontractor I have a SNET
constraint, Project won't alert me if I'm getti,ng late on tasks leading
up to that intervention.
To the contrary when I set an MSO constraint, slack in the tasks leading
up to it will alert me correctly if I slip on these tasks.
So then Project predicts success based on what I have to do right now!

When any action is agreed upon solemnly between parties, it becomes MSO.
Commitment is commitment.
Greetings,

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

Organizational psychologists often describe positions within a hierarchy
in terms of the holder having a mix of position power and personal
power. The CEO's administrative assistant may have little official
authority within the corporate hierarchy but none the less he or she
exerts tremendous influence, they hold the keys to the throne, and as
such exercises tremendous personal power.

Certainly it can be true, as you say, that the PM may have relatively
little position power in the sense of being able to mandate the
performance of resources. But even so, he is the sole individual
charged with the ultimate responsibility for fulfilling the portion of
the organization's strategic plan the project represents. Like the
captain of naval ship acting on orders from the admiral, the PM is the
management person responsible for *making sure* the project is completed
in the most efficient manner. The buck stops with him and it's his butt
that gets fired if it doesn't happen. So if they don't have the position
power to mandate the performance from resources that will make it so,
they have to call on personal power - negotiation skills, argument,
calling in favours, astute application of

political relationships, etc - to make it sure it happens the way they
have determined it MUST happen for the project to be a success. The
project manager is not, in my opinion, a beaurocrat monitoring the
performance of resources who might suggest that they behave and
prioritize in a certain way. Rather he is the one that determines what
the plan *will be* and then does whatever it takes to insure that people
follow it - He, not the resources and not the resource's managers, is
the one who organizes the project. While he might have to be very
indirect and political about how he achieves it, the bottom line is it's
still his job to tell the resources what to do and when it has to be
done and regardless of exactly how he goes about it, he needs to keep
clear in his own mind that that is his bottom line responsibility and no
one else's. The PM is the one who determines what must happen and when
it must happen in order to bring the project to a successful conclusion
and then exercises both position power, if he has it, and personal power
if he does not, to make certain that it happens in that manner, just
like the captain of the ship always has the final decision as to its
course even if he sometimes listens to the suggestions of the helmsman.

I don't know why you say a MSO constraint warns you if a negotiated
start date isn't going to be met - it does exactly the opposite and
tells Project to always show that the start will occur as required
regardless of what's going on before it! It doesn't give you a warning
at all, on the contrary it lies and shows all is well and starting on
time even when it's definitely NOT well. (It would be nice to have the
option of applying start deadlines as well as finish deadlines, though.)

I oppose the use of MSO, MFO, and MFNLT constraints because of the way
they cripple the Project scheduling engine. It boils down to why I
think one bothers to use scheduling software in the first place. I
already know what the requirements are and I don't need to document them
again. My task, once I sit down to plan, the task for which I'm using
software in the first place, is to figure out just how I have to
organize the work so those requirements are met. To do that, the
software must show me the consequences of my decisions - will deploying
the resources in such and such a manner lead to success or failure?
Applying a fixed date constraint to a task, that means that no matter
what else is happening in the schedule, Project will NEVER, under any
circumstance (unless one disables "tasks always obey their constraints"
in which case why bother with the constraint in the first place?), show
it happening on any other than the specified date. Nothing can make it
move. So the existence of the constraints means Project will not
predict success or failure as it should - instead it always promises
success. While indeed it may be imperative within the mandate you've
been given that they not be allowed to move, that doesn't mean that
reality won't intrude - unless you organize it right, tasks fail to meet
deadlines all the time (unfortunately). A requirement doesn't mean it's
impossible for it to move, only that it ought not move, and we all know
of situations where requirements are not met. I suggest that the
primary purpose of project software having a dynamic schedule
calculation engine is NOT to document the requirements, it's rather to
give you a tool to predict whether the plan as you have organized it is
going to achieve those requirements. Its job is to predict success or
failure given a proposed workflow and resource loading. Fixed dates in
the plan mean that you're using the software as little more than a fancy
hi-tech version of a wall calendar with a big red circle drawn around
critical deadlines - forcing the schedule to always lock those tasks to
the designated dates means you have crippled its ability to predict
whether your workflow is actually going to achieve them. It always
promises your plan will be successful even when its physically
impossible for it to actually happen that way because it never shows
your tasks moving away from the dates where they ought to occur.
--
Steve House [Project 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 Hi Steve,

I'm afraid I already wrote this, but are you aware that your image of
project management represents IMHO only a minority of projects?
Most organisations I know run projects in a matrix structure, such that
project leaders have no (like in ZERO, NONE) hierarchic power over those
who perform.
An important part of their job is to negotiate with (internal or
external) subcontractors about when they will perform, or even just when
they intend to deliver. That is not what I call "calling the shots".
This doesn't render the usage of MS Project less important, only
different.
For instance once they have agreed with a subcontractor they may well
use a Must Start On constraint, for instance to be warned by Project
when a task leading up to the subcon's agreed date may jeopardize that
agreement.
Management in such cases is done far more based on duration and
constraints, and it is typical for that project orhganisation and
management.

And BTW, I guess 7,2 hrs of work is just an estimate for 1 day, but as
Project's default for Work is in hours, people may call it that way.

Greetings,

--
Jan De Messemaeker
Microsoft Project MVP
http://users.online.be/prom-ade
"Steve House" <sjhouse at hotmail dot com> wrote in message
Just a point to ponder ... if the work only requires 7.2 hours of
actual
work (how do you estimate work that precisely, anyway? That's 3%
accuracy!)
why are you letting the resource have 10 times that length of time it
which
to do it? As PM you should be calling the shots - go to that resource
at
tell them "It looks like everything will be ready for you to start that
task
Tuesday afternoon or first thing Wednesday morning so can I count on
you
having it finished by the end of the day Wednesday?" Now it could be
that
there are other things on the resource's plate that mean it'll take him
longer and of course consult with him so as to take that into account,
but
my suggestion is to stop thinking in terms of windows of opportunity
and
instead focus on how soon you can get your resources to finish the
work. As
Larry the Cable Guy says, "Just git 'er done."
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


I have a task (A) that will require 7.2 hours of work but is not
estimated
to finish for 10 days. Another task (B) has a FS link to task A.

My questions pertains to the best way to account for the estimated 10
days
it will require task A to complete.

Should task B have a FS+10 days lag time? Or am I better off putting
a
constraint type of "Finish No Later Than" on task A.

Right now I have task B linked to A with a FS+10 Days, What prompted
my
question is that task A is scheduled to start on 8/10/07 and end on
8/11/07 (7.2hrs), when in reality it isn't estimated to end until
8/24/07.

Thanks in advance for your assistance.

JR

 

[Steve House]

Of course it doesn't make sense to have it in the plan for any date other
than 02 Sept. But the dates that items in a plan will be able to happen are
driven by predecessor relationships and resource availability. The ONLY way
you can present your plan to the board on 02 Sept is if all the things that
go into preparing the presentation are ready by that date. You can't just
declare it so and expect all the predecessors to automatically fall into
place. The way I see Project most effectively used in the planning process
is through a series of iterations ... "If I order the slides from the
graphics artists on Tuesday, what date will that let me deliver the
presentation? How about Thursday? Could I hold off ordering until the
20th? What about the 22nd?" Each trial gives me a forecast "ready to
deliver" date and I keep trying different options and workflow organizations
until I get the one that lands "Deliver to Board" on 02 Sept. What's
crucial to me is the answer to the question "if I order the slides on the
20th, will that let me be ready in time and if not, what date would that
have put it on?" I don't know that yet - I have to plug the data into
Project and let it freely calculate the "deliver" date so I can find out if
my idea of a plan will work or not. If it doesn't, it's back to the drawing
board. You don't HAVE a plan until all the computed dates are meeting their
"must hit" dates. The rough draft is not the plan - locking tasks to fixed
dates with constraints while trying various interim plans prevents you from
seeing if things get better or worse on the next iteration. Similarly,
locking tasks down with constraints in the final plan prevents you from
seeing how actual performance deviating from planned performance is going to
negatively impact your "must hit" dates once you start tracking actual
progress. If they're constrained MSO, MFO, or MFNLT, they'll always show as
being on time no matter what happens with their predecessors. If Joe comes
to me and says the graphics won't be ready until the 25th, I want to see on
the Gantt chart that his delay to the 25th means the presentation won't be
ready to deliver until 15 Sept! That's why I'm using the computer - to tell
me exactly that fact. If the "presentation" task is constrained to 02 Sept,
that's the date it shows occuring REGARDLESS of what Joe says will be
delivery date for the graphics, hardly an effective early warning system of
impending trouble. A deadline (instead of a constraint) of 02 Sept tells
me, on the other hand, it has to occur the 2nd but with Joe's delay it can't
occur until the 15th, so I better figure out a plan B for getting those
graphics - okay, if I send him a helper what will that do to the forecast
"ready to deliver" date? - or start rewriting my presentation now so I don't
need 'em.

As I've said before, IMHO the project plan is not just a calendar to record
the dates that you do know - all you need is a file-o-fax or Outlook to do
that. It is more of a tool to help you predict the dates that you DON'T
know.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Hi,

Two details here.
Scanning for negative slack is extremely simple (make a filter or simply
use the auto filter)
And a project manager is not the top of the world. If you have to present
your project to the board of directors on September 2nd f.i., it doesn't
make sense to plan that activity on September 7 (nor on August 30, for
that matter), whatever the other tasks may say: an appointment is an
appointment, you shouldn't pin any other date on it, that is fooling
yourself.

--
Jan De Messemaeker
Microsoft Project MVP
http://users.online.be/prom-ade

Yes, of course commitment is commitment. But have things unforeseen
never caused you to miss a commitment you have made, for instance, ever
made payment a day or so late? Project's displayed dates are not, IMHO,
intended to document the commitments that have been made. IMHO, the
reason to use software instead of just a pencil and paper to-do list is
to create a "What If" analytic tool to predict whether the commitments
that have been made will actually be achieved and if not, how late (or
early, for that matter) they will be. It is first and foremost a
forecasting tool and for it to take performance to date and from that
forecast when future Task X will be able to take place, you can't prevent
the task's free movement by constraining it. To do so is exactly as if
you created a "What If" profit optimization model in Excel and somehow
managed to constrain it so that it would never go negative to show that
some pricing structures would result in a loss. Let's see, we should not
exceed a total of 10 ... 5+3=8, 5+4=9, 5+5=10, 5+6=10, 5+7=10, 5+8=10 ...
that's exactly what a constraint (in this case a FNLT) does in a
project's schedule model and the forecast of achievable project progress
one obtains in such as case is just a fallacious as is my arithmetic
here. As long as the forecast is acceptable the calculations are
correct. But as soon as you get into trouble, and predicting trouble is
the only reason to bother with the exercise in the first place, it no
longer works. It fails you in what you need it most to do, keeping you
out of trouble. Using a MSO or MSNLT or MFNLT to indicate an agreed upon
start or delivery date means your plan will never warn you if that
commitment is not going to be met, it always will promise on-time
performance.

I know you like to use the numerical slack values and look for negative
slack but frankly, scanning down a column of numbers to find those slacks
that don't look right would drive me nuts. Give me a model showing me
where things are predicted to end up if we keep on our present course
along with nice red flags if the predicted result are not where it ought
to be. But show me what I'm GOING to get unless I change direction
instead of what I OUGHT to get. I know where I ought to be, I'm using
the software to find out if I'm going to make it or not and if not, to
figure out what I can do about it. To do that, it must show me the
results that would be obtained for each option I might consider.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Hi,

Wow, what a reaction.
Prioritisation is not only a mùatter of dates, I mostly use Total Slack
to determine priorities.
And when on a futuire intervention of a subcontractor I have a SNET
constraint, Project won't alert me if I'm getti,ng late on tasks leading
up to that intervention.
To the contrary when I set an MSO constraint, slack in the tasks leading
up to it will alert me correctly if I slip on these tasks.
So then Project predicts success based on what I have to do right now!

When any action is agreed upon solemnly between parties, it becomes MSO.
Commitment is commitment.
Greetings,

--
Jan De Messemaeker
Microsoft Project Most Valuable Professional
+32 495 300 620
For availability check:
http://users.online.be/prom-ade/Calendar.pdf
"Steve House" <sjhouse at hotmail dot com> wrote in message
Organizational psychologists often describe positions within a
hierarchy in terms of the holder having a mix of position power and
personal power. The CEO's administrative assistant may have little
official authority within the corporate hierarchy but none the less he
or she exerts tremendous influence, they hold the keys to the throne,
and as such exercises tremendous personal power.

Certainly it can be true, as you say, that the PM may have relatively
little position power in the sense of being able to mandate the
performance of resources. But even so, he is the sole individual
charged with the ultimate responsibility for fulfilling the portion of
the organization's strategic plan the project represents. Like the
captain of naval ship acting on orders from the admiral, the PM is the
management person responsible for *making sure* the project is
completed in the most efficient manner. The buck stops with him and
it's his butt that gets fired if it doesn't happen. So if they don't
have the position power to mandate the performance from resources that
will make it so, they have to call on personal power - negotiation
skills, argument, calling in favours, astute application of

political relationships, etc - to make it sure it happens the way they
have determined it MUST happen for the project to be a success. The
project manager is not, in my opinion, a beaurocrat monitoring the
performance of resources who might suggest that they behave and
prioritize in a certain way. Rather he is the one that determines what
the plan *will be* and then does whatever it takes to insure that
people follow it - He, not the resources and not the resource's
managers, is the one who organizes the project. While he might have to
be very indirect and political about how he achieves it, the bottom
line is it's still his job to tell the resources what to do and when it
has to be done and regardless of exactly how he goes about it, he needs
to keep clear in his own mind that that is his bottom line
responsibility and no one else's. The PM is the one who determines what
must happen and when it must happen in order to bring the project to a
successful conclusion and then exercises both position power, if he has
it, and personal power if he does not, to make certain that it happens
in that manner, just like the captain of the ship always has the final
decision as to its course even if he sometimes listens to the
suggestions of the helmsman.

I don't know why you say a MSO constraint warns you if a negotiated
start date isn't going to be met - it does exactly the opposite and
tells Project to always show that the start will occur as required
regardless of what's going on before it! It doesn't give you a warning
at all, on the contrary it lies and shows all is well and starting on
time even when it's definitely NOT well. (It would be nice to have the
option of applying start deadlines as well as finish deadlines,
though.)

I oppose the use of MSO, MFO, and MFNLT constraints because of the way
they cripple the Project scheduling engine. It boils down to why I
think one bothers to use scheduling software in the first place. I
already know what the requirements are and I don't need to document
them again. My task, once I sit down to plan, the task for which I'm
using software in the first place, is to figure out just how I have to
organize the work so those requirements are met. To do that, the
software must show me the consequences of my decisions - will deploying
the resources in such and such a manner lead to success or failure?
Applying a fixed date constraint to a task, that means that no matter
what else is happening in the schedule, Project will NEVER, under any
circumstance (unless one disables "tasks always obey their constraints"
in which case why bother with the constraint in the first place?), show
it happening on any other than the specified date. Nothing can make it
move. So the existence of the constraints means Project will not
predict success or failure as it should - instead it always promises
success. While indeed it may be imperative within the mandate you've
been given that they not be allowed to move, that doesn't mean that
reality won't intrude - unless you organize it right, tasks fail to
meet deadlines all the time (unfortunately). A requirement doesn't
mean it's impossible for it to move, only that it ought not move, and
we all know of situations where requirements are not met. I suggest
that the primary purpose of project software having a dynamic schedule
calculation engine is NOT to document the requirements, it's rather to
give you a tool to predict whether the plan as you have organized it is
going to achieve those requirements. Its job is to predict success or
failure given a proposed workflow and resource loading. Fixed dates in
the plan mean that you're using the software as little more than a
fancy hi-tech version of a wall calendar with a big red circle drawn
around critical deadlines - forcing the schedule to always lock those
tasks to the designated dates means you have crippled its ability to
predict whether your workflow is actually going to achieve them. It
always promises your plan will be successful even when its physically
impossible for it to actually happen that way because it never shows
your tasks moving away from the dates where they ought to occur.
--
Steve House [Project 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 Hi Steve,

I'm afraid I already wrote this, but are you aware that your image of
project management represents IMHO only a minority of projects?
Most organisations I know run projects in a matrix structure, such that
project leaders have no (like in ZERO, NONE) hierarchic power over
those who perform.
An important part of their job is to negotiate with (internal or
external) subcontractors about when they will perform, or even just
when they intend to deliver. That is not what I call "calling the
shots".
This doesn't render the usage of MS Project less important, only
different.
For instance once they have agreed with a subcontractor they may well
use a Must Start On constraint, for instance to be warned by Project
when a task leading up to the subcon's agreed date may jeopardize that
agreement.
Management in such cases is done far more based on duration and
constraints, and it is typical for that project orhganisation and
management.

And BTW, I guess 7,2 hrs of work is just an estimate for 1 day, but as
Project's default for Work is in hours, people may call it that way.

Greetings,

--
Jan De Messemaeker
Microsoft Project MVP
http://users.online.be/prom-ade
"Steve House" <sjhouse at hotmail dot com> wrote in message
Just a point to ponder ... if the work only requires 7.2 hours of
actual
work (how do you estimate work that precisely, anyway? That's 3%
accuracy!)
why are you letting the resource have 10 times that length of time it
which
to do it? As PM you should be calling the shots - go to that resource
at
tell them "It looks like everything will be ready for you to start
that task
Tuesday afternoon or first thing Wednesday morning so can I count on
you
having it finished by the end of the day Wednesday?" Now it could be
that
there are other things on the resource's plate that mean it'll take
him
longer and of course consult with him so as to take that into account,
but
my suggestion is to stop thinking in terms of windows of opportunity
and
instead focus on how soon you can get your resources to finish the
work. As
Larry the Cable Guy says, "Just git 'er done."
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


I have a task (A) that will require 7.2 hours of work but is not
estimated
to finish for 10 days. Another task (B) has a FS link to task A.

My questions pertains to the best way to account for the estimated 10
days
it will require task A to complete.

Should task B have a FS+10 days lag time? Or am I better off putting
a
constraint type of "Finish No Later Than" on task A.

Right now I have task B linked to A with a FS+10 Days, What prompted
my
question is that task A is scheduled to start on 8/10/07 and end on
8/11/07 (7.2hrs), when in reality it isn't estimated to end until
8/24/07.

Thanks in advance for your assistance.

JR