Some scheduling software misses to properly identify open end activities. An activity might have a FF predecessor and still be start dangling. An activity might have a SS successor and still be finish dangling.
The filter as well as the scheduling report shall distinguish activities without predecessor / successor only and activities without predecessor to start only / successor from finish only.
The following is a case where an activity [Activity 11] with predecessor and successor is dangling at start and finish nodes.
Member for
16 years 3 months
Member for16 years4 months
Submitted by Zoltan Palffy on Wed, 2018-10-17 19:02
used not primarily as a predcessor but a successor relation where the compound relationship SS ties down the the front end of the activity and the FF ties down the backend of the activity. In theory only having a SS realtionship counts as an open ended activity.
Member for
21 years 8 months
Member for21 years8 months
Submitted by Rafael Davila on Wed, 2018-10-17 14:48
Unfortunately, all PERT charts contain a fatal flaw of logic. They imply that you must [ALWAYS] complete the preceding task before you start the succeeding one. This notion of precedence is dangerous in a fast-moving world. You see, PERT charts assume that nothing useful can be done in a succeeding step until all of the preceding step is complete. Thus, succeeding activities don't start until everything required to complete them is available. Such logic unnecessarily places activities on the critical path, which is exactly the opposite of what we need for rapid development. Instead, we must begin the succeeding activity as soon as we have the minimum information required to begin it.
PERT charts inherently result in longer development schedules, because they incorrectly use sequential logic. Not starting downstream activities until the upstream ones are complete inexorably lengthens the critical path. Instead, we must use the logic of concurrency to shorten the critical path.
Sequential Logic as well as Concurrency Logic does happen, use them as need be.
Be reminded that when using Concurrency Logic there might be LAG DRAG. This happens when increasing the duration of a task accelerates the start of a successor task. To identify such occurrence use DRAG float values to identify if it happens on critical activities, use Start FLEX to identify whenever it can happen in non-critical activities.
Then you have to decide if DRAG activity duration might be increased or if activity shall split. Usually it is better to keep current activity duration when not critical, when critical it can be otherwise.
When increasing/decreasing activity duration you must always consider the impact of this action on resource leveling. You might decide to increase/decrease resource quantity, you might decide to increase/decrease partial workloads, you might decide to increase/decrease lag values, you might decide to change lag type [duration lag/volume lag], you might decide to change lag calendar, and you might decide to increase/decrease resource production rate or maybe a combination of these and any other strategies. What is important is that you keep control and that it is transparent.
Member for
15 years 11 months
Member for15 years11 months
Submitted by Raymund de Laza on Tue, 2018-10-16 07:47
This is a provacative question that was probably asked and answered many times here. The documented debate goes back 54 years, and you will find strong dogma-driven opinions on both sides.
From my perspective, there's no better way to model sequentially overlapping activities in P6 than by using compound relationships with lags. (According to a 1987 paper by Fondahl, this was one of the advantages driving PDM's adoption in the construction industry in the 1960s). Still, you need to be careful with them to avoid logic traps (mainly with lags) during revision and updating.
Member for
21 years 8 monthsThe Problem with Dangling
Some scheduling software misses to properly identify open end activities. An activity might have a FF predecessor and still be start dangling. An activity might have a SS successor and still be finish dangling.
The filter as well as the scheduling report shall distinguish activities without predecessor / successor only and activities without predecessor to start only / successor from finish only.
The following is a case where an activity [Activity 11] with predecessor and successor is dangling at start and finish nodes.
Member for
16 years 3 monthsused not primarily as a
used not primarily as a predcessor but a successor relation where the compound relationship SS ties down the the front end of the activity and the FF ties down the backend of the activity. In theory only having a SS realtionship counts as an open ended activity.
Member for
21 years 8 monthsSequential Logic and
Sequential Logic and Concurrency Logic
Unfortunately, all PERT charts contain a fatal flaw of logic. They imply that you must [ALWAYS] complete the preceding task before you start the succeeding one. This notion of precedence is dangerous in a fast-moving world. You see, PERT charts assume that nothing useful can be done in a succeeding step until all of the preceding step is complete. Thus, succeeding activities don't start until everything required to complete them is available. Such logic unnecessarily places activities on the critical path, which is exactly the opposite of what we need for rapid development. Instead, we must begin the succeeding activity as soon as we have the minimum information required to begin it.
PERT charts inherently result in longer development schedules, because they incorrectly use sequential logic. Not starting downstream activities until the upstream ones are complete inexorably lengthens the critical path. Instead, we must use the logic of concurrency to shorten the critical path.
Sequential Logic as well as Concurrency Logic does happen, use them as need be.
Be reminded that when using Concurrency Logic there might be LAG DRAG. This happens when increasing the duration of a task accelerates the start of a successor task. To identify such occurrence use DRAG float values to identify if it happens on critical activities, use Start FLEX to identify whenever it can happen in non-critical activities.
Then you have to decide if DRAG activity duration might be increased or if activity shall split. Usually it is better to keep current activity duration when not critical, when critical it can be otherwise.
When increasing/decreasing activity duration you must always consider the impact of this action on resource leveling. You might decide to increase/decrease resource quantity, you might decide to increase/decrease partial workloads, you might decide to increase/decrease lag values, you might decide to change lag type [duration lag/volume lag], you might decide to change lag calendar, and you might decide to increase/decrease resource production rate or maybe a combination of these and any other strategies. What is important is that you keep control and that it is transparent.
Member for
15 years 11 monthsThe best to apply both the SS
The best to apply both the SS and FF is the link in Construction of Column & Construction of Suspended Slab.
Activities in Slab can commence upon Construction of Columns but can never finish the Slab unless the Columns is Completed.
Member for
18 years 11 monthsThis is a provacative
This is a provacative question that was probably asked and answered many times here. The documented debate goes back 54 years, and you will find strong dogma-driven opinions on both sides.
From my perspective, there's no better way to model sequentially overlapping activities in P6 than by using compound relationships with lags. (According to a 1987 paper by Fondahl, this was one of the advantages driving PDM's adoption in the construction industry in the 1960s). Still, you need to be careful with them to avoid logic traps (mainly with lags) during revision and updating.