Buffer or lag periods

[SR]

Hi,

I am working in a functional unit projs where resources work in multiple
projs. My prob is, when i create my plan, i only know the estimated hrs for
each task and the % of resource availability. So it is really difficult for
me to schedule the exact dates that a particular task is going to finish. The
way I am doing is, take resource as 100% available and keep some buffer days
(lag) for the next task to start. this i do by adding lags for the next task.
e.g - if a 16 effort hrs task starts on 7/3. my schd will have an end date
for this task 7/4 and with a lag of 5 days, next task will start 7/12.
Problem here is - when the task finishes on 7/10 with no effort variance, the
start date for next task automatically set to 7/18 for 5 lag days. I then
have to remove this lag to start on 7/11.

Saying that - cann't put date contraints as actually do not have any
- duration available for the proj is always much higher
than estmated hours.
- should not vary from the baseline dates for main tasks as
the resource are blocked for the baseline dates for other functional groups.

Does any one has any idea how to fix this problem or a better solution to
schedule the task.

 

[John]

Hi,

I am working in a functional unit projs where resources work in multiple
projs. My prob is, when i create my plan, i only know the estimated hrs for
each task and the % of resource availability. So it is really difficult for
me to schedule the exact dates that a particular task is going to finish. The
way I am doing is, take resource as 100% available and keep some buffer days
(lag) for the next task to start. this i do by adding lags for the next task.
e.g - if a 16 effort hrs task starts on 7/3. my schd will have an end date
for this task 7/4 and with a lag of 5 days, next task will start 7/12.
Problem here is - when the task finishes on 7/10 with no effort variance, the
start date for next task automatically set to 7/18 for 5 lag days. I then
have to remove this lag to start on 7/11.

Saying that - cann't put date contraints as actually do not have any
- duration available for the proj is always much higher
than estmated hours.
- should not vary from the baseline dates for main tasks as
the resource are blocked for the baseline dates for other functional groups.

Does any one has any idea how to fix this problem or a better solution to
schedule the task.

SR,
Your scenario is very typical - you have an estimate for the number of
hours required to do a task and you know who you want to work on it. The
problem I see in what you have described is that you appear to be
"forcing" the schedule, perhaps even doing something you should not and
that is to directly entering start and finish dates for tasks.

The whole reason for using Project is to allow it to schedule your
project based on some basic inputs - task description, estimated
duration, schedule logic (links), estimated work, and resource
assignments. Is your plan going to be perfect? No, it never is. Remember
most of the data is estimated so the initial schedule is a best guess
estimate of how the plan will unfold. As the plan is executed, it is
updated and modified as necessary to reflect newer information.

It is also not clear if you understand the difference between duration
time and work time. Duration is the time during which a task will be
completed. It is expressed in working time as the difference between the
Start and Finish fields. Work on the other hand is the amount of time
one or more resources will expend actually performing the task. If a
single resource is assigned at 100%, then duration and work will be the
same. However it is also very common to have a duration time that is
longer than the work time. For example, painting a room may take 5 days
but the estimated work to paint the room may only be 30 hours.

It is very rare that you will have all the resources you want/need to
complete your plan. It is also very rare that there is actually enough
time to execute the plan as you would like. Those are the realities of
the business world. Your job is to create the most reasonable but
realistic plan with the assets available to you. If you truly can't get
there from here, then you need to make your case to your management for
more time and/or resources.

John
Project MVP

 

[SR]

Thank John but may be i was not clear earlier.

I do not at all touch the start & finish date. that is why to adjust the
date i put this lag.
lets say I have Task A - efft hrs 16 hrs & Task B - eff hr - 32 but the dur
i don't know and hv one resource (not 100%) actual %ge not available.

If i simply schd B after A with Start-Finish, it will finish in 6 days with
no lag. But then since the resource is not available 100%, A is not going to
finish in 2 days. So what i do I keep "TaskAFS+5 days" in predecessor col.
that gives me 5 days and i can maitain my baseline dates. but if the takes 4
days and when i enter the actual finish date, it automatically adds another 5
ds for Task B to start. I have to manually go and reduce the lag days to 2 so
that the next task start can start on time.

What I am asking here is, is there any way to have this buffer so that i
don't deviate from baseline dates and also keep some extra room for each task

 

[Steve House]

As you've discovered, lags aren't the same as a buffer. A lag time of,
say, 3 day between tasks means that there MUST be a 3 day delay between
the completion of the first task and the start of the second. For
example, perhaps you'll always need 3 days of curing time between
pouring concrete in the first task before starting to paint it in the
second task. No matter what date task 1 ends, task 2 should not start
until 3 days later.

Frankly, the best way to use the buffers is to include them in the
task's duration estimate. You say you don't know duration but you can
estimate it. If you think work will require 40 man-hours and you knw
you can have your resource full time, the duration will probably be 40
hours as well (5 days). So to add a 25% buffer set the duration to 50
hours. Or if you don't want to disturb the work estimate, set the
duration to 50 hours and assign the resource at 75% - work will be 40
hours.

 

[SR]

Thanks Steve. Out of the three solution yu provided, i can only apply one
(reducing the resource usage). I tried this option before. It used to take a
lot of time to calculate this and for a project with around 1000 tasks, it is
very time cosuming. That is why I started using Lag days. But now I realize
may be the resource usage is a better option. but do let me know if you have
any other alternatives. I cann't increase the effort as i track the cost and
my budget will go up.

I used to adjust the usage % by hit & trial, keeping in mind the date i am
targeting. my effort hrs are not always whole numbers nor multiple of 8. May
be any alternate simple way to do this will also help.

 

[John]

Thank John but may be i was not clear earlier.

I do not at all touch the start & finish date. that is why to adjust the
date i put this lag.
lets say I have Task A - efft hrs 16 hrs & Task B - eff hr - 32 but the dur
i don't know and hv one resource (not 100%) actual %ge not available.

If i simply schd B after A with Start-Finish, it will finish in 6 days with
no lag. But then since the resource is not available 100%, A is not going to
finish in 2 days. So what i do I keep "TaskAFS+5 days" in predecessor col.
that gives me 5 days and i can maitain my baseline dates. but if the takes 4
days and when i enter the actual finish date, it automatically adds another 5
ds for Task B to start. I have to manually go and reduce the lag days to 2 so
that the next task start can start on time.

What I am asking here is, is there any way to have this buffer so that i
don't deviate from baseline dates and also keep some extra room for each task

sr,
Guess what, nobody ever knows the duration of a task. They are all just
estimates - until they are completed - only then do you know how long it
took.

It sounds like you are still "forcing" the schedule (i.e. "...I can
maintain my baseline dates."). Baseline dates simply represent the
original plan. It is OK to "miss" the baseline dates - that's reality.
It is extremely (I mean EXTREMELY) rare that a plan will be developed
and executed such that the actual performance matches the baseline.

If a schedule starts to deviate from the baseline by an unacceptable
amount, one of two things is in play. Either the original plan wasn't
that good and hence the baseline is off, or things have changed (e.g.
contract deviation, major issues affecting the schedule, etc.) and a new
baseline may be in order.

Here is an alternative to Steve's suggestion. I am a fan of fixed
duration scheduling. With fixed duration it is very easy to develop a
schedule based on best guess estimates for task durations. Historical
data from similar projects is a great place to start. Link tasks in the
logical sequence of performance. Then resource work hours are entered
and Project will automatically set the assignment level for resources.

John
Project MVP

 

[Steve House]

LOL - John and I are on opposite sides of the philosophical fence on this
one - I am strongly opposed to ever using fixed duration scheduling except
in very specific circumstances. Fixed duration is simply a workaround to
impose a set of schedule dates on the project, trying to sever the
relationship between work and duration. The assumption is that if the task
will take longer than you want it to, making the resource work harder will
solve the problem and make the task fit into the time you want to allow for
it. But it won't work - in a well managed firm resources are always working
as hard as they're ever going to work so if it's going to take him 3 days to
polish 100 fids, it will take him 3 days no matter what your schedule calls
for, whether you've budgeted 10 days or 1 day. The task might be a test
that must run for exactly 4 hours, no more and no less, for its results to
be valid so something like that could be a candidate to be entered as a
fixed duration task but that's about it. In my opinion, a manager does not
decide how long a task *ought* to take. Instead, a manager seeks to
*discover* how long a task will *need* to take to get the required result.
Scheduling becomes an act of discovery, not an imposition of will.

Frankly, I don't see why you're building these buffers into the task at
all - If your best estimate is that it should take 3 days to get the fids
ready to polish, coordinate with the resource to verify that your estimate
is reasonably accurate and to get a buy-in on your expectations from him,
and then schedule it that way. Build the schedule on the assumption that it
WILL take 3 days and you can schedule the next task in line to start on day
4. What you're doing by putting on buffers is saying "I think we'll be
ready to go on day 4 but I'm not going to promise it'll start until day 6 so
that in the event the first task takes a little longer than planned I don't
ever have to go to my boss with the news that we're going to run later than
I'd originaly expected." Basically you're trying CYA to insure that reality
is never worse that first estimates. But the end result is going to be a
"worst case" schedule than has the project scheduled to last longer than it
really could take to get it done. And human psychology being what it is,
Joe Resource will say to himself "I could get 'er done in 3 days but the
boss has given me 6 so why break a sweat?" and the old saw about the work
expanding to fill the time allotted for it will come true.

Baselines are not targets to be engraved in granite - they are a record of
your best-guess schedule estimates preserved in order to measure progress.

 

[SR]

Thanks both of you. I got the point.
My intention behind the buffer time was "not to keep the resource reserved"
for the subsequent task. it makes a little difficult to get the resource back
if you do not stick to the initial dates and the first task got delayed. it
makes the plan ever worst if i get a substitute resource.
Chances of the first task being late is a little high. there is nothing
wrong in the effoprt estimate but the duration. a 16 hrs task always takes
ard 2 weeks duration to finish since resources are not 100% and I never know
their availability.

But I got your point anyway, i should always stick to my original best
estimation on duration and you r right in saying baseline dates are not
engraved in granite only prob is hard to make the senior mgmt understand when
u hv a rule "base line will only be changed upon scope change" or any other
valid reasons.

Thanks again.


--
sr

LOL - John and I are on opposite sides of the philosophical fence on this
one - I am strongly opposed to ever using fixed duration scheduling except
in very specific circumstances. Fixed duration is simply a workaround to
impose a set of schedule dates on the project, trying to sever the
relationship between work and duration. The assumption is that if the task
will take longer than you want it to, making the resource work harder will
solve the problem and make the task fit into the time you want to allow for
it. But it won't work - in a well managed firm resources are always working
as hard as they're ever going to work so if it's going to take him 3 days to
polish 100 fids, it will take him 3 days no matter what your schedule calls
for, whether you've budgeted 10 days or 1 day. The task might be a test
that must run for exactly 4 hours, no more and no less, for its results to
be valid so something like that could be a candidate to be entered as a
fixed duration task but that's about it. In my opinion, a manager does not
decide how long a task *ought* to take. Instead, a manager seeks to
*discover* how long a task will *need* to take to get the required result.
Scheduling becomes an act of discovery, not an imposition of will.

Frankly, I don't see why you're building these buffers into the task at
all - If your best estimate is that it should take 3 days to get the fids
ready to polish, coordinate with the resource to verify that your estimate
is reasonably accurate and to get a buy-in on your expectations from him,
and then schedule it that way. Build the schedule on the assumption that it
WILL take 3 days and you can schedule the next task in line to start on day
4. What you're doing by putting on buffers is saying "I think we'll be
ready to go on day 4 but I'm not going to promise it'll start until day 6 so
that in the event the first task takes a little longer than planned I don't
ever have to go to my boss with the news that we're going to run later than
I'd originaly expected." Basically you're trying CYA to insure that reality
is never worse that first estimates. But the end result is going to be a
"worst case" schedule than has the project scheduled to last longer than it
really could take to get it done. And human psychology being what it is,
Joe Resource will say to himself "I could get 'er done in 3 days but the
boss has given me 6 so why break a sweat?" and the old saw about the work
expanding to fill the time allotted for it will come true.

Baselines are not targets to be engraved in granite - they are a record of
your best-guess schedule estimates preserved in order to measure progress.

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

 

[John]

Thanks both of you. I got the point.
My intention behind the buffer time was "not to keep the resource reserved"
for the subsequent task. it makes a little difficult to get the resource back
if you do not stick to the initial dates and the first task got delayed. it
makes the plan ever worst if i get a substitute resource.
Chances of the first task being late is a little high. there is nothing
wrong in the effoprt estimate but the duration. a 16 hrs task always takes
ard 2 weeks duration to finish since resources are not 100% and I never know
their availability.

But I got your point anyway, i should always stick to my original best
estimation on duration and you r right in saying baseline dates are not
engraved in granite only prob is hard to make the senior mgmt understand when
u hv a rule "base line will only be changed upon scope change" or any other
valid reasons.

Thanks again.

sr,
You're welcome. Your management is right in that the baseline should
only be changed due to a change in scope. However, with that rule comes
the consequence that variances may get pretty ugly if the original
estimates were not that good and/or the execution is faltering.

John
Project MVP

--
sr

LOL - John and I are on opposite sides of the philosophical fence on this
one - I am strongly opposed to ever using fixed duration scheduling except
in very specific circumstances. Fixed duration is simply a workaround to
impose a set of schedule dates on the project, trying to sever the
relationship between work and duration. The assumption is that if the task
will take longer than you want it to, making the resource work harder will
solve the problem and make the task fit into the time you want to allow for
it. But it won't work - in a well managed firm resources are always
working
as hard as they're ever going to work so if it's going to take him 3 days
to
polish 100 fids, it will take him 3 days no matter what your schedule calls
for, whether you've budgeted 10 days or 1 day. The task might be a test
that must run for exactly 4 hours, no more and no less, for its results to
be valid so something like that could be a candidate to be entered as a
fixed duration task but that's about it. In my opinion, a manager does not
decide how long a task *ought* to take. Instead, a manager seeks to
*discover* how long a task will *need* to take to get the required result.
Scheduling becomes an act of discovery, not an imposition of will.

Frankly, I don't see why you're building these buffers into the task at
all - If your best estimate is that it should take 3 days to get the fids
ready to polish, coordinate with the resource to verify that your estimate
is reasonably accurate and to get a buy-in on your expectations from him,
and then schedule it that way. Build the schedule on the assumption that
it
WILL take 3 days and you can schedule the next task in line to start on day
4. What you're doing by putting on buffers is saying "I think we'll be
ready to go on day 4 but I'm not going to promise it'll start until day 6
so
that in the event the first task takes a little longer than planned I don't
ever have to go to my boss with the news that we're going to run later than
I'd originaly expected." Basically you're trying CYA to insure that
reality
is never worse that first estimates. But the end result is going to be a
"worst case" schedule than has the project scheduled to last longer than it
really could take to get it done. And human psychology being what it is,
Joe Resource will say to himself "I could get 'er done in 3 days but the
boss has given me 6 so why break a sweat?" and the old saw about the work
expanding to fill the time allotted for it will come true.

Baselines are not targets to be engraved in granite - they are a record of
your best-guess schedule estimates preserved in order to measure progress.

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

Thanks Steve. Out of the three solution yu provided, i can only apply one
(reducing the resource usage). I tried this option before. It used to
take
a
lot of time to calculate this and for a project with around 1000 tasks,
it
is
very time cosuming. That is why I started using Lag days. But now I
realize
may be the resource usage is a better option. but do let me know if you
have
any other alternatives. I cann't increase the effort as i track the cost
and
my budget will go up.

I used to adjust the usage % by hit & trial, keeping in mind the date i
am
targeting. my effort hrs are not always whole numbers nor multiple of 8.
May
be any alternate simple way to do this will also help.

--
sr


:

As you've discovered, lags aren't the same as a buffer. A lag time of,
say, 3 day between tasks means that there MUST be a 3 day delay between
the completion of the first task and the start of the second. For
example, perhaps you'll always need 3 days of curing time between
pouring concrete in the first task before starting to paint it in the
second task. No matter what date task 1 ends, task 2 should not start
until 3 days later.

Frankly, the best way to use the buffers is to include them in the
task's duration estimate. You say you don't know duration but you can
estimate it. If you think work will require 40 man-hours and you knw
you can have your resource full time, the duration will probably be 40
hours as well (5 days). So to add a 25% buffer set the duration to 50
hours. Or if you don't want to disturb the work estimate, set the
duration to 50 hours and assign the resource at 75% - work will be 40
hours.
--
Steve House
MS Project MVP
Visit http://www.mvps.org/project/faqs.htm for the FAQs



Thank John but may be i was not clear earlier.

I do not at all touch the start & finish date. that is why to adjust
the
date i put this lag.
lets say I have Task A - efft hrs 16 hrs & Task B - eff hr - 32 but
the dur
i don't know and hv one resource (not 100%) actual %ge not available.

If i simply schd B after A with Start-Finish, it will finish in 6 days
with
no lag. But then since the resource is not available 100%, A is not
going to
finish in 2 days. So what i do I keep "TaskAFS+5 days" in predecessor
col.
that gives me 5 days and i can maitain my baseline dates. but if the
takes 4
days and when i enter the actual finish date, it automatically adds
another 5
ds for Task B to start. I have to manually go and reduce the lag days
to 2 so
that the next task start can start on time.

What I am asking here is, is there any way to have this buffer so that
i
don't deviate from baseline dates and also keep some extra room for
each task



--
sr


:

Hi,

I am working in a functional unit projs where resources work in
multiple
projs. My prob is, when i create my plan, i only know the
estimated hrs for
each task and the % of resource availability. So it is really
difficult for
me to schedule the exact dates that a particular task is going to
finish. The
way I am doing is, take resource as 100% available and keep some
buffer days
(lag) for the next task to start. this i do by adding lags for the
next task.
e.g - if a 16 effort hrs task starts on 7/3. my schd will have an
end date
for this task 7/4 and with a lag of 5 days, next task will start
7/12.
Problem here is - when the task finishes on 7/10 with no effort
variance, the
start date for next task automatically set to 7/18 for 5 lag days.
I then
have to remove this lag to start on 7/11.

Saying that - cann't put date contraints as actually do not have
any
- duration available for the proj is always much
higher
than estmated hours.
- should not vary from the baseline dates for
main tasks as
the resource are blocked for the baseline dates for other
functional groups.

Does any one has any idea how to fix this problem or a better
solution to
schedule the task.

SR,
Your scenario is very typical - you have an estimate for the number
of
hours required to do a task and you know who you want to work on it.
The
problem I see in what you have described is that you appear to be
"forcing" the schedule, perhaps even doing something you should not
and
that is to directly entering start and finish dates for tasks.

The whole reason for using Project is to allow it to schedule your
project based on some basic inputs - task description, estimated
duration, schedule logic (links), estimated work, and resource
assignments. Is your plan going to be perfect? No, it never is.
Remember
most of the data is estimated so the initial schedule is a best
guess
estimate of how the plan will unfold. As the plan is executed, it is
updated and modified as necessary to reflect newer information.

It is also not clear if you understand the difference between
duration
time and work time. Duration is the time during which a task will be
completed. It is expressed in working time as the difference between
the
Start and Finish fields. Work on the other hand is the amount of
time
one or more resources will expend actually performing the task. If a
single resource is assigned at 100%, then duration and work will be
the
same. However it is also very common to have a duration time that is
longer than the work time. For example, painting a room may take 5
days
but the estimated work to paint the room may only be 30 hours.

It is very rare that you will have all the resources you want/need
to
complete your plan. It is also very rare that there is actually
enough
time to execute the plan as you would like. Those are the realities
of
the business world. Your job is to create the most reasonable but
realistic plan with the assets available to you. If you truly can't
get
there from here, then you need to make your case to your management
for
more time and/or resources.

John
Project MVP

 

[Steve House]

They are correct that the baseline should only be changed given a scope
change but keep in mind that the baseline is not an objective or
productivity target. It is only a record of your estimates - some of the
project may come in before the baseline, other parts may come in after. But
an actual that deviates from the baseline is NOT a changing baseline, it is
only an indicator of the accuracy of your estimating process. ( And keeping
a record of those variances helos you improve the estimating process in
future projects.)
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Thanks both of you. I got the point.
My intention behind the buffer time was "not to keep the resource
reserved"
for the subsequent task. it makes a little difficult to get the resource
back
if you do not stick to the initial dates and the first task got delayed.
it
makes the plan ever worst if i get a substitute resource.
Chances of the first task being late is a little high. there is nothing
wrong in the effoprt estimate but the duration. a 16 hrs task always takes
ard 2 weeks duration to finish since resources are not 100% and I never
know
their availability.

But I got your point anyway, i should always stick to my original best
estimation on duration and you r right in saying baseline dates are not
engraved in granite only prob is hard to make the senior mgmt understand
when
u hv a rule "base line will only be changed upon scope change" or any
other
valid reasons.

Thanks again.


--
sr

LOL - John and I are on opposite sides of the philosophical fence on this
one - I am strongly opposed to ever using fixed duration scheduling
except
in very specific circumstances. Fixed duration is simply a workaround to
impose a set of schedule dates on the project, trying to sever the
relationship between work and duration. The assumption is that if the
task
will take longer than you want it to, making the resource work harder
will
solve the problem and make the task fit into the time you want to allow
for
it. But it won't work - in a well managed firm resources are always
working
as hard as they're ever going to work so if it's going to take him 3 days
to
polish 100 fids, it will take him 3 days no matter what your schedule
calls
for, whether you've budgeted 10 days or 1 day. The task might be a test
that must run for exactly 4 hours, no more and no less, for its results
to
be valid so something like that could be a candidate to be entered as a
fixed duration task but that's about it. In my opinion, a manager does
not
decide how long a task *ought* to take. Instead, a manager seeks to
*discover* how long a task will *need* to take to get the required
result.
Scheduling becomes an act of discovery, not an imposition of will.

Frankly, I don't see why you're building these buffers into the task at
all - If your best estimate is that it should take 3 days to get the fids
ready to polish, coordinate with the resource to verify that your
estimate
is reasonably accurate and to get a buy-in on your expectations from him,
and then schedule it that way. Build the schedule on the assumption that
it
WILL take 3 days and you can schedule the next task in line to start on
day
4. What you're doing by putting on buffers is saying "I think we'll be
ready to go on day 4 but I'm not going to promise it'll start until day 6
so
that in the event the first task takes a little longer than planned I
don't
ever have to go to my boss with the news that we're going to run later
than
I'd originaly expected." Basically you're trying CYA to insure that
reality
is never worse that first estimates. But the end result is going to be a
"worst case" schedule than has the project scheduled to last longer than
it
really could take to get it done. And human psychology being what it is,
Joe Resource will say to himself "I could get 'er done in 3 days but the
boss has given me 6 so why break a sweat?" and the old saw about the work
expanding to fill the time allotted for it will come true.

Baselines are not targets to be engraved in granite - they are a record
of
your best-guess schedule estimates preserved in order to measure
progress.

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

Thanks Steve. Out of the three solution yu provided, i can only apply
one
(reducing the resource usage). I tried this option before. It used to
take
a
lot of time to calculate this and for a project with around 1000 tasks,
it
is
very time cosuming. That is why I started using Lag days. But now I
realize
may be the resource usage is a better option. but do let me know if you
have
any other alternatives. I cann't increase the effort as i track the
cost
and
my budget will go up.

I used to adjust the usage % by hit & trial, keeping in mind the date i
am
targeting. my effort hrs are not always whole numbers nor multiple of
8.
May
be any alternate simple way to do this will also help.

--
sr


:

As you've discovered, lags aren't the same as a buffer. A lag time
of,
say, 3 day between tasks means that there MUST be a 3 day delay
between
the completion of the first task and the start of the second. For
example, perhaps you'll always need 3 days of curing time between
pouring concrete in the first task before starting to paint it in the
second task. No matter what date task 1 ends, task 2 should not start
until 3 days later.

Frankly, the best way to use the buffers is to include them in the
task's duration estimate. You say you don't know duration but you can
estimate it. If you think work will require 40 man-hours and you knw
you can have your resource full time, the duration will probably be 40
hours as well (5 days). So to add a 25% buffer set the duration to 50
hours. Or if you don't want to disturb the work estimate, set the
duration to 50 hours and assign the resource at 75% - work will be 40
hours.
--
Steve House
MS Project MVP
Visit http://www.mvps.org/project/faqs.htm for the FAQs



Thank John but may be i was not clear earlier.

I do not at all touch the start & finish date. that is why to adjust
the
date i put this lag.
lets say I have Task A - efft hrs 16 hrs & Task B - eff hr - 32 but
the dur
i don't know and hv one resource (not 100%) actual %ge not
available.

If i simply schd B after A with Start-Finish, it will finish in 6
days
with
no lag. But then since the resource is not available 100%, A is not
going to
finish in 2 days. So what i do I keep "TaskAFS+5 days" in
predecessor
col.
that gives me 5 days and i can maitain my baseline dates. but if the
takes 4
days and when i enter the actual finish date, it automatically adds
another 5
ds for Task B to start. I have to manually go and reduce the lag
days
to 2 so
that the next task start can start on time.

What I am asking here is, is there any way to have this buffer so
that
i
don't deviate from baseline dates and also keep some extra room for
each task



--
sr


:

Hi,

I am working in a functional unit projs where resources work in
multiple
projs. My prob is, when i create my plan, i only know the
estimated hrs for
each task and the % of resource availability. So it is really
difficult for
me to schedule the exact dates that a particular task is going
to
finish. The
way I am doing is, take resource as 100% available and keep some
buffer days
(lag) for the next task to start. this i do by adding lags for
the
next task.
e.g - if a 16 effort hrs task starts on 7/3. my schd will have
an
end date
for this task 7/4 and with a lag of 5 days, next task will start
7/12.
Problem here is - when the task finishes on 7/10 with no effort
variance, the
start date for next task automatically set to 7/18 for 5 lag
days.
I then
have to remove this lag to start on 7/11.

Saying that - cann't put date contraints as actually do not have
any
- duration available for the proj is always
much
higher
than estmated hours.
- should not vary from the baseline dates for
main tasks as
the resource are blocked for the baseline dates for other
functional groups.

Does any one has any idea how to fix this problem or a better
solution to
schedule the task.

SR,
Your scenario is very typical - you have an estimate for the
number
of
hours required to do a task and you know who you want to work on
it.
The
problem I see in what you have described is that you appear to be
"forcing" the schedule, perhaps even doing something you should
not
and
that is to directly entering start and finish dates for tasks.

The whole reason for using Project is to allow it to schedule your
project based on some basic inputs - task description, estimated
duration, schedule logic (links), estimated work, and resource
assignments. Is your plan going to be perfect? No, it never is.
Remember
most of the data is estimated so the initial schedule is a best
guess
estimate of how the plan will unfold. As the plan is executed, it
is
updated and modified as necessary to reflect newer information.

It is also not clear if you understand the difference between
duration
time and work time. Duration is the time during which a task will
be
completed. It is expressed in working time as the difference
between
the
Start and Finish fields. Work on the other hand is the amount of
time
one or more resources will expend actually performing the task. If
a
single resource is assigned at 100%, then duration and work will
be
the
same. However it is also very common to have a duration time that
is
longer than the work time. For example, painting a room may take 5
days
but the estimated work to paint the room may only be 30 hours.

It is very rare that you will have all the resources you want/need
to
complete your plan. It is also very rare that there is actually
enough
time to execute the plan as you would like. Those are the
realities
of
the business world. Your job is to create the most reasonable but
realistic plan with the assets available to you. If you truly
can't
get
there from here, then you need to make your case to your
management
for
more time and/or resources.

John
Project MVP