Critical path not showing through an activity with ed days

[Andrew]

I have an activity - concrete cure which I have alloted 7ed. I know that this
activity is critical because I have linked it to be. However, the critical
path jumps this activity ie its blue and the next activity is red. Any ideas
??

Andrew

 

[Gérard Ducouret]

Hello Andrew,



These tasks with elapsed duration can run 24/7. May be this "Concrete
curing" task ends on Friday evening at 5pm. Its successor with classical
duration cannot start before next Monday, in the morning (may be 8 am). But,
if necessary, the concrete curing could drift on Saturday and on Sunday,
without postponing the following task. So this ed task as some slack (almost
2 days)



Gérard Ducouret

 

[Andrew]

Gerard

Firstly thankyou for your quick response. I understand what you are saying
regarding the weekend, however the curing activity in this case ends on a
Thursday, and the following activity starts on the friday and is not linked
to any other activity. I quickly opened up a new project and tried the same
thing and the ed activity is still blue (non critical).

Andrew

 

[Gérard Ducouret]

Andrew,
- the curing activity ends on a Thursday : at what time ? with ed duration
it could drift until Friday morning 8am
- and the following activity starts on the friday : At what time?

Gérard

 

[Andrew]

Gerard

I see. My activity (ed) ends at 17:00 and the next starts at 08:00 the next
day I checked the Total float and the ed act has 0.63ed. This leads to a
further question if I run a critical filter the ed activity will not be
selected, and a gap is shown between the critical activities with no links
between them - is there any way to show the ed activity as critical, or would
it be better to allocated a 7 day calendar to the cure activity.

Andrew

 

[Steve House]

An activity with a positive, non-zero slack time is by definition
non-critical. You keep saying the task is question is critical but by the
formal definition of a critical task, it isn't. It could be delayed by up
to 0.63 days before it becomes critical and begins to push on the successor
task's start time.

 

[Andrew]

Steve

The activity preceding and the activity succeeding the cure activity (with
the ed duration) are both critical and are only linked to the cure activity.
I originally tried to have the cure as a 7 day duration no matter where it
comes ie over weekends etc, just in case the bar moves. The only reason that
I can see for the bar being "non critical" is that the potential duration
span for elapsed time duration activities carries from 17:00 through to 08:00
each day. The cure activity is critical but the succeeding activity can only
start on 08:00 in the morning because it is on the standard 08:00 to 17:00
calendar, hence the float value. I have circumnavigated this by using a
standard 7 day calender and assigned it to the cure activity. Maybe I should
have done this in the first place and this problem would never have surfaced.
I used it because I thought that was what the ed duration was used for in
MSp, no matter as the critical path is now showing the cure period which is
what i required. Thankyou for your help in this matter also the same to
Gerard - many thanks

Andrew

Andrew

 

[Gérard Ducouret]

Andrew,
A last point : if you consider that a slack of 0.63ed is no a real
"confort" you can rely on, you can go to Tools / Options / Calculation /
Tasks are critical if slack is less than or equal to .. days

Gérard Ducouret

 

[Trivikram]

Andrew,

Going thru the whole issue, I got to share with you guys a best practice we
adopt. We use 10 days of float as the critical path definition for a project
extending thru 2 or 3 years. It would be wise to use more than 0 days for
critical path in any project, as we would have an opportunity to concentrate
on near critical tasks along with the critical tasks in a particular project.
This way we would be more responsive the critical tasks of a project.

Trivikram.

 

[Steve House]

A question came to mind as I was looking back at the thread ... does the
curing activity require the active participation of a resource? If not,
consider not making it a task at all. I think a task should be fairly
narrowly defined as a physical activity performed by a resource that results
in the creation of a deliverable. Curing times, drying times, time spent
waiting for an approval, etc, are not physical activities done by
resources - just the opposite, waiting for something to happen is
non-activity by definition. Strctly speaking they are not tasks at all.
That being the case, I prefer to see such waiting periods modeled through
the use of lag times in the link between the activity that enters the
waiting period and the activity that begins after the waiting time has
expired. Your problem disappears if you completely eliminate "curing" as an
actual task and instead model it as "pour concrete" ---> "walk on concrete"
with a 7 ed lag time impressed on the link between the two to accomodate the
curing time.

 

[Trivikram]

Hi Steve,

I disagree with you on two things.
First, on not scheduling tasks that are not resource driven. As a Planner
one is interested in the schedule and not the resource hours (mostly). So if
for any project, a foundation is critical obviously its curing time also
becomes critical driving the end date of the project.
Second, on the use of leads and lags... Me & my team/colleagues are fully
averse of using these lags and leads as these things are not physically
controllable as we tend to loose track of those things once the execution
starts. Yes, it would be a nice way to use them before baselining a schedule
to avoid start & finish variances during the analysis after the project is
complete. Certainly its not the best practice.

Trivikram.

 

[Steve House]

I think you are using the term "critical" to mean more than its specific
definition within the context of CPM. Certaily it's critical that a
foundation cure properly before building on it but "important" is a not a
synonym for "critical" in the scheduling sense. It is perfectly possible to
have a curing time that absolutely and positively must be allowed to run to
completion yet have its timing in realtionship to the other tasks in the
project be such that it's completion could be delayed by some amount without
affecting the completion time of the project. Imagine for some reason we
scheduled pouring the concrete for the foundation to occur on the same day
we order the materials for the framing. The concrete will take 1 week to
cure but the framing materials will take 2 weeks to arrive. We COULD delay
the pouring for up to up to a week before it starts to affect the date we'll
start framing. Even though the project can't proceed until the pour and
cure so it's absolutely mandatory that we do it, it's not a critical task
because it could be potentially delayed by some amount of time before it
affects the ultimate completion date of the project. UNLESS we delay the
pouring for a week after ordering the framing, the curing time does not
affect the project completion and is not a driving factor.

I don't know why you say that a lag time is not physically controllable.
You may be thinking of slack (float) but float and lag are two entirely
different things. You have total control of the lag while float is a
consequence of the schedule details. Task A is linked to Task B with a FS
link containing a 1 week lag time. specified by you when you create the
link. No matter what happens to the finish date of A as the schedule
evolves either in the planning phase or the execution phase, whether it
moves up because the task itself is moved up or the task takes less time and
finishes early, or is pushed back so A finishes later, task B will always be
scheduled to start 1 week after A finishes. it's start date moving in
lock-step to the changes in the finish of A. As far as the relationship
between A's finish and B's start is concerned, it's acting as if the
intervening time is a task, yet it's not distorting the project by appearing
to be an activity tieing up a resource.

 

[Rod Gill]

Not with you there at all. As a project manager and scheduler of 30+ years,
much time spent as a trainer, coach and currently scheduler of a refinery
expansion project (a slightly complex beast? ) I find people get into
trouble most when what is being scheduled does not mirror reality. Pouring
concrete is a concrete (literally!) task, but curing time is not. If you
create a curing task there isn't anyone twiddling their thumbs waiting for
the concrete. For accuracy you would have to give the task a duration of
7ed, the same as for a lag. (Note for the non civil engineering minded
people reading this thread, concrete gets 80% of its strength only after 7 x
24h days have past. It keeps curing over the weekend and over holidays!)

My definition of a critical Task is any Task that if delayed a small amount
of time (say 10 minutes) delays the project finish time by the same amount
of time or more. So, if the next Task cannot start until 8:00 and the curing
finishes 07:00 the pour concrete Task can be delayed an hour without
affecting the finish of the project. It is by definition therefore, not
critical. One way around this is to set as critical any task with totals
slack of 1d under Tools, Options and I think, the calculation tab.

A lag better reflects reality and so is the better option in my experience.
If I have novice consumers of my schedule I may add a note to the remove
temporary supports task such as "supports cannot be removed until 7 days
after pouring concrete". Remember a schedule is as much about communication
as it is about planning.

I regularly use negative lags, anything that accurately reflects what I want
to have happen. In a tight timeframe project overlaps (especially where
different Resources are on overlapping tasks) accurately schedule the
quickest way of doing things. So I'm afraid I don't support your view and
consider lags and lead times very good practice. Mind you different types of
projects in different industries and different political constraints within
organizations do affect what can or has to be communicated. For example a
petro-chem project has quite different practices compared to a software
development project.

Remember the final check for a schedule is a peer review. Add notes wherever
there may be any ambiguity and be clear on what you want to communicate to
the users of your schedules.

--

Rod Gill
Microsoft MVP for Project

Author of the only book on Project VBA, see:
http://www.projectvbabook.com

 

[Gary L. Chefetz]

Steve, Rod:

Whether or not the task is critical, there are some fairly strong arguments
in favor of using tasks to model activities like cement curing. Ultimately,
there is resource responsibility in a task like "cement curing." Someone has
to verify that it actually cured and cured correctly and certify it ready
for building. Cure times are estimates and can be affected by weather
conditions and by characteristics of the mix. Albeit a trivial work
assignment, it is a resource responsibility to assure quality and
completion. Now take this task to an enterprise implementation and consider
the requirement that someone needs to report on the assignment or become the
"assignment owner" for this task. Like so many things in Project, there is
no single *right way* to do things, there is only what works best for each
individual situation. My personal preference would be to model these as
tasks rather than using lag because, at the very least, I want someone to be
responsible for responsible for reporting completion and I want to be able
to measure variance on that activity.