Dynamic schedule

[Vazabe]

I understand the benefit of having a schedule with no date constraints, a
dynamic, free floating schedule. But at what level of detail do you think the
dynamics must stop? To clarify: An activity gets delayed by 3 hours and
pushes the whole schedule forward. Should I let the 3 hour delay show in the
schedule and affect the schedule or should I hide the delay with a lag of 3
hours or some other technique?

 

[John]

I understand the benefit of having a schedule with no date constraints, a
dynamic, free floating schedule. But at what level of detail do you think the
dynamics must stop? To clarify: An activity gets delayed by 3 hours and
pushes the whole schedule forward. Should I let the 3 hour delay show in the
schedule and affect the schedule or should I hide the delay with a lag of 3
hours or some other technique?

Vazabe,
I assume you are working with a schedule timescale wherein 3 hours is a
significant factor. In other words, your total plan must be only a few
days or weeks long. If your plan is several months in duration, 3 hours
isn't going to materially affect the outcome except in some really
extreme cases. And if a 3 hours delay actually shows up in a schedule of
several months then the level of detail is probably to great.

Any time a task is delayed for whatever reason and it pushes the end
milestone beyond the desired time, then it is time to take remedial
action to recover the plan. This is what the Project Manager (PM) does
in coordination with the performing organizations. He/she Maintains the
schedule and when there is evidence of a problem, a flag is raised to
indicate the need for a workaround - add more resources, shift some
tasks, develop alternate approaches, whatever.

Something that causes the schedule to get off track should NEVER be
hidden. That will only make it more difficult to recover when that
little cover-up is discovered by management or worse yet, the customer.

John
Project MVP

 

[Vazabe]

Thank you for your reply!
Yes, I agree that the level of detail is to great but that is what we have
to do since we all use the timesheets in Project server set to 'Hours per
day...' and we are not allowed to change this setting. The 3 hour delay that
came up on lets say friday will be fixed during monday morning but will I let
the successor activity be delayed also by 3 hours or could I let the activity
start as planned since the resources are not the same on these two
activities? How will I model this in Project? By a lag of 3 hours?

 

[John]

Thank you for your reply!
Yes, I agree that the level of detail is to great but that is what we have
to do since we all use the timesheets in Project server set to 'Hours per
day...' and we are not allowed to change this setting. The 3 hour delay that
came up on lets say friday will be fixed during monday morning but will I let
the successor activity be delayed also by 3 hours or could I let the activity
start as planned since the resources are not the same on these two
activities? How will I model this in Project? By a lag of 3 hours?

Vazabe,
You're welcome.
I don't know about Project Server but if it forces the whole plan to be
at an hourly detail because the timesheets are set for hourly input,
then I'd say there is a deficiency. You might want post to our server
newsgroup (microsoft.public.project.server) and see if there is a better
way to do this.

Now with regard to your hypothetical case. You say the 3 hour delay will
be "fixed" Monday morning but how exactly will it be "fixed"? Maybe
that's the question you are asking - how SHOULD you fix it.

A successor task should only be a successor if it in fact depends on the
predecessor being finished before it can start. It sounds like that
might not be the case which means the link isn't really valid to begin
with. If the predecessor must be finished, (e.g. data entry must be
finished before data processing can commence, or the primer coat must be
dry before the finish coat can be applied), then you really don't have a
choice - the successor task will be delayed. However, in many cases the
predecessor task may not need to be 100% complete before the successor
can start, (e.g. a primer coat can be applied to those window frames
that have been stripped and sanded even though some sanding remains to
be done on a few window frames, or assembly can start even though not
all the parts are in house).

A lag is definitely NOT what you want to model this. A lag puts in a
delay and you already have that. What you need is a lead. Better still,
maybe the link should have been set as [pred ID]SS + x days. This says
the successor must start after the predecessor starts but can start
before the predecessor is 100% complete. The delay can also be expressed
as a percent (i.e. [pred ID] + 80%). However, if the successor task can
in fact start even though the predecessor is delayed, I would just break
the link and enter the successor start date manually. This will set a
start-no-earlier-than constraint on the successor task. Although setting
constraints in a schedule is not a good practice, in this case it is a
valid description of the work as it is being done.

Hope this helps.
John
Project MVP

 

[Vazabe]

A million thanks! You have helped me a lot.

Thank you for your reply!
Yes, I agree that the level of detail is to great but that is what we have
to do since we all use the timesheets in Project server set to 'Hours per
day...' and we are not allowed to change this setting. The 3 hour delay that
came up on lets say friday will be fixed during monday morning but will I let
the successor activity be delayed also by 3 hours or could I let the activity
start as planned since the resources are not the same on these two
activities? How will I model this in Project? By a lag of 3 hours?

Vazabe,
You're welcome.
I don't know about Project Server but if it forces the whole plan to be
at an hourly detail because the timesheets are set for hourly input,
then I'd say there is a deficiency. You might want post to our server
newsgroup (microsoft.public.project.server) and see if there is a better
way to do this.

Now with regard to your hypothetical case. You say the 3 hour delay will
be "fixed" Monday morning but how exactly will it be "fixed"? Maybe
that's the question you are asking - how SHOULD you fix it.

A successor task should only be a successor if it in fact depends on the
predecessor being finished before it can start. It sounds like that
might not be the case which means the link isn't really valid to begin
with. If the predecessor must be finished, (e.g. data entry must be
finished before data processing can commence, or the primer coat must be
dry before the finish coat can be applied), then you really don't have a
choice - the successor task will be delayed. However, in many cases the
predecessor task may not need to be 100% complete before the successor
can start, (e.g. a primer coat can be applied to those window frames
that have been stripped and sanded even though some sanding remains to
be done on a few window frames, or assembly can start even though not
all the parts are in house).

A lag is definitely NOT what you want to model this. A lag puts in a
delay and you already have that. What you need is a lead. Better still,
maybe the link should have been set as [pred ID]SS + x days. This says
the successor must start after the predecessor starts but can start
before the predecessor is 100% complete. The delay can also be expressed
as a percent (i.e. [pred ID] + 80%). However, if the successor task can
in fact start even though the predecessor is delayed, I would just break
the link and enter the successor start date manually. This will set a
start-no-earlier-than constraint on the successor task. Although setting
constraints in a schedule is not a good practice, in this case it is a
valid description of the work as it is being done.

Hope this helps.
John
Project MVP

 

[John]

A million thanks! You have helped me a lot.

Vazabe,
You're welcome. Boy, I wish I had a dollar for every time someone said
that

John

Thank you for your reply!
Yes, I agree that the level of detail is to great but that is what we
have
to do since we all use the timesheets in Project server set to 'Hours per
day...' and we are not allowed to change this setting. The 3 hour delay
that
came up on lets say friday will be fixed during monday morning but will I
let
the successor activity be delayed also by 3 hours or could I let the
activity
start as planned since the resources are not the same on these two
activities? How will I model this in Project? By a lag of 3 hours?

Vazabe,
You're welcome.
I don't know about Project Server but if it forces the whole plan to be
at an hourly detail because the timesheets are set for hourly input,
then I'd say there is a deficiency. You might want post to our server
newsgroup (microsoft.public.project.server) and see if there is a better
way to do this.

Now with regard to your hypothetical case. You say the 3 hour delay will
be "fixed" Monday morning but how exactly will it be "fixed"? Maybe
that's the question you are asking - how SHOULD you fix it.

A successor task should only be a successor if it in fact depends on the
predecessor being finished before it can start. It sounds like that
might not be the case which means the link isn't really valid to begin
with. If the predecessor must be finished, (e.g. data entry must be
finished before data processing can commence, or the primer coat must be
dry before the finish coat can be applied), then you really don't have a
choice - the successor task will be delayed. However, in many cases the
predecessor task may not need to be 100% complete before the successor
can start, (e.g. a primer coat can be applied to those window frames
that have been stripped and sanded even though some sanding remains to
be done on a few window frames, or assembly can start even though not
all the parts are in house).

A lag is definitely NOT what you want to model this. A lag puts in a
delay and you already have that. What you need is a lead. Better still,
maybe the link should have been set as [pred ID]SS + x days. This says
the successor must start after the predecessor starts but can start
before the predecessor is 100% complete. The delay can also be expressed
as a percent (i.e. [pred ID] + 80%). However, if the successor task can
in fact start even though the predecessor is delayed, I would just break
the link and enter the successor start date manually. This will set a
start-no-earlier-than constraint on the successor task. Although setting
constraints in a schedule is not a good practice, in this case it is a
valid description of the work as it is being done.

Hope this helps.
John
Project MVP

:

I understand the benefit of having a schedule with no date
constraints, a
dynamic, free floating schedule. But at what level of detail do you
think
the
dynamics must stop? To clarify: An activity gets delayed by 3 hours
and
pushes the whole schedule forward. Should I let the 3 hour delay show
in
the
schedule and affect the schedule or should I hide the delay with a
lag of
3
hours or some other technique?

Vazabe,
I assume you are working with a schedule timescale wherein 3 hours is a
significant factor. In other words, your total plan must be only a few
days or weeks long. If your plan is several months in duration, 3 hours
isn't going to materially affect the outcome except in some really
extreme cases. And if a 3 hours delay actually shows up in a schedule
of
several months then the level of detail is probably to great.

Any time a task is delayed for whatever reason and it pushes the end
milestone beyond the desired time, then it is time to take remedial
action to recover the plan. This is what the Project Manager (PM) does
in coordination with the performing organizations. He/she Maintains the
schedule and when there is evidence of a problem, a flag is raised to
indicate the need for a workaround - add more resources, shift some
tasks, develop alternate approaches, whatever.

Something that causes the schedule to get off track should NEVER be
hidden. That will only make it more difficult to recover when that
little cover-up is discovered by management or worse yet, the customer.

John
Project MVP