• The Problem with Dangling Activities
• Monitor and Remedy Dangling Activities

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.

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.

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.