Buffer or lag periods

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

John
Fri Jul 07 10:39:21 CDT 2006

In article <94E7E50F-EA84-457E-9883-DD8490F2E0AE@microsoft.com>,
SR <SR@discussions.microsoft.com> wrote:

> 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
Fri Jul 07 11:00:01 CDT 2006

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


"John" wrote:

> In article <94E7E50F-EA84-457E-9883-DD8490F2E0AE@microsoft.com>,
> SR <SR@discussions.microsoft.com> wrote:
>
> > 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
Fri Jul 07 11:51:43 CDT 2006

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



"SR" <SR@discussions.microsoft.com> wrote in message
news:5DE79B5A-6975-4173-9C29-3AE5069422B1@microsoft.com...
> 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
>
>
> "John" wrote:
>
> > In article <94E7E50F-EA84-457E-9883-DD8490F2E0AE@microsoft.com>,
> > SR <SR@discussions.microsoft.com> wrote:
> >
> > > 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
Fri Jul 07 12:07:01 CDT 2006

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


"Steve House" wrote:

> 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
>
>
>
> "SR" <SR@discussions.microsoft.com> wrote in message
> news:5DE79B5A-6975-4173-9C29-3AE5069422B1@microsoft.com...
> > 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
> >
> >
> > "John" wrote:
> >
> > > In article <94E7E50F-EA84-457E-9883-DD8490F2E0AE@microsoft.com>,
> > > SR <SR@discussions.microsoft.com> wrote:
> > >
> > > > 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
> > >
>
>
>

John
Fri Jul 07 15:41:12 CDT 2006

In article <5DE79B5A-6975-4173-9C29-3AE5069422B1@microsoft.com>,
SR <SR@discussions.microsoft.com> wrote:

> 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

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
>
>
> "John" wrote:
>
> > In article <94E7E50F-EA84-457E-9883-DD8490F2E0AE@microsoft.com>,
> > SR <SR@discussions.microsoft.com> wrote:
> >
> > > 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
Sun Jul 09 11:23:06 CDT 2006

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


"SR" <SR@discussions.microsoft.com> wrote in message
news:72E1D835-DB0A-4C3C-8BF9-47E26DEB777E@microsoft.com...
> 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
>
>
> "Steve House" wrote:
>
>> 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
>>
>>
>>
>> "SR" <SR@discussions.microsoft.com> wrote in message
>> news:5DE79B5A-6975-4173-9C29-3AE5069422B1@microsoft.com...
>> > 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
>> >
>> >
>> > "John" wrote:
>> >
>> > > In article <94E7E50F-EA84-457E-9883-DD8490F2E0AE@microsoft.com>,
>> > > SR <SR@discussions.microsoft.com> wrote:
>> > >
>> > > > 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
Mon Jul 10 08:19:03 CDT 2006

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


"Steve House" wrote:

> 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
>
>
> "SR" <SR@discussions.microsoft.com> wrote in message
> news:72E1D835-DB0A-4C3C-8BF9-47E26DEB777E@microsoft.com...
> > 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
> >
> >
> > "Steve House" wrote:
> >
> >> 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
> >>
> >>
> >>
> >> "SR" <SR@discussions.microsoft.com> wrote in message
> >> news:5DE79B5A-6975-4173-9C29-3AE5069422B1@microsoft.com...
> >> > 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
> >> >
> >> >
> >> > "John" wrote:
> >> >
> >> > > In article <94E7E50F-EA84-457E-9883-DD8490F2E0AE@microsoft.com>,
> >> > > SR <SR@discussions.microsoft.com> wrote:
> >> > >
> >> > > > 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
> >> > >
> >>
> >>
> >>
>
>

John
Mon Jul 10 10:14:41 CDT 2006

In article <20D88CD4-E480-4811-A233-436F7E68EF95@microsoft.com>,
SR <SR@discussions.microsoft.com> wrote:

> 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
>
>
> "Steve House" wrote:
>
> > 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
> >
> >
> > "SR" <SR@discussions.microsoft.com> wrote in message
> > news:72E1D835-DB0A-4C3C-8BF9-47E26DEB777E@microsoft.com...
> > > 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
> > >
> > >
> > > "Steve House" wrote:
> > >
> > >> 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
> > >>
> > >>
> > >>
> > >> "SR" <SR@discussions.microsoft.com> wrote in message
> > >> news:5DE79B5A-6975-4173-9C29-3AE5069422B1@microsoft.com...
> > >> > 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
> > >> >
> > >> >
> > >> > "John" wrote:
> > >> >
> > >> > > In article <94E7E50F-EA84-457E-9883-DD8490F2E0AE@microsoft.com>,
> > >> > > SR <SR@discussions.microsoft.com> wrote:
> > >> > >
> > >> > > > 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
Mon Jul 10 14:53:50 CDT 2006

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


"SR" <SR@discussions.microsoft.com> wrote in message
news:20D88CD4-E480-4811-A233-436F7E68EF95@microsoft.com...
> 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
>
>
> "Steve House" wrote:
>
>> 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
>>
>>
>> "SR" <SR@discussions.microsoft.com> wrote in message
>> news:72E1D835-DB0A-4C3C-8BF9-47E26DEB777E@microsoft.com...
>> > 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
>> >
>> >
>> > "Steve House" wrote:
>> >
>> >> 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
>> >>
>> >>
>> >>
>> >> "SR" <SR@discussions.microsoft.com> wrote in message
>> >> news:5DE79B5A-6975-4173-9C29-3AE5069422B1@microsoft.com...
>> >> > 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.
>>