Open Ends and Dangling Logic: Finding and Fixing Them
An open end is an activity missing a predecessor or a successor. A dangling activity has one of each but still has a start or finish that nothing controls. Both make the schedule's float numbers wrong, and both let delays happen without moving the finish date. This post shows how an open end inflates float on a worked example, explains the less obvious SS and FF danglers, and gives a cleanup routine you can run on any schedule before it goes to the owner.
The rule
In a CPM network, every activity should have at least one predecessor and at least one successor, except the project start milestone (no predecessor) and the project finish milestone (no successor). And more specifically:
- Every activity's start should be driven by something: an FS or SS relationship coming in.
- Every activity's finish should drive something: an FS or FF relationship going out.
The first bullet is about predecessors. The second is about successors. An activity can technically have both a predecessor and a successor and still fail one of these tests. That's dangling logic.
Why an open end matters: a worked example
Here's the back end of a mid-rise building. Durations are working days, 0-based convention (first activity ES = 0, EF = ES + duration). All FS, no lag.
| ID | Activity | Duration | Predecessors |
|---|---|---|---|
| A | Structure topped out (milestone) | 0 | none |
| B | Elevator rails, machines, and cabs | 30 | A |
| C | Elevator state inspection | 5 | B |
| D | Interior finishes | 60 | A |
| E | Final building inspections | 5 | D |
| F | TCO (milestone) | 0 | E |
| G | Punch list | 15 | F |
| H | Closeout documents | 10 | G |
| I | Project complete (milestone) | 0 | H |
Notice what's missing: the elevator inspection (C) has no successor. Someone forgot to tie it to anything.
Forward pass:
A: 0
B: ES 0, EF 30
C: ES 30, EF 35
D: ES 0, EF 60
E: ES 60, EF 65
F: 65
G: ES 65, EF 80
H: ES 80, EF 90
I: 90
On the backward pass, an activity with no successor has nothing to take a late start from. Most CPM tools give it a late finish equal to the project finish. So C gets LF = 90, LS = 85, and total float of 55 days. B gets LF 85, LS 55, also 55 days.
According to this schedule, the elevator can slip 55 working days without affecting anything.
That's wrong. You can't get a TCO in a mid-rise building without an inspected elevator. Add the missing tie, C as a predecessor to E (final building inspections):
E: ES = max(EF of C, EF of D) = max(35, 60) = 60
C: LF = LS of E = 60, LS 55, TF = 55 - 30 = 25
B: LF 55, LS 25, TF = 25 - 0 = 25
The real float on the elevator path is 25 days, not 55. Now play out a 40-day slip on the elevator install:
| Scenario | Elevator inspection finishes | Schedule shows TCO | Actual TCO |
|---|---|---|---|
| Open end (broken) | Day 75 | Day 65, no impact, 15 days float left | Day 80 |
| Tied correctly | Day 75 | Day 80, 15 days late | Day 80 |
The broken schedule reports the job on time right up until the inspector refuses to sign off. That's the whole problem with open ends: they don't produce errors, they produce optimism.
The common culprits
Some activities show up as open ends on almost every building job. Check these first:
| Activity | Usually missing | Should drive |
|---|---|---|
| Elevator inspection | Successor | Final inspections or TCO |
| Fire alarm acceptance test | Successor | Final fire marshal inspection, TCO |
| Permanent power energized | Successor | Equipment startup, commissioning |
| Submittal and procurement activities | Successor | The install activity they feed |
| Commissioning and TAB | Successor | Substantial completion or owner turnover |
| Punch list | Successor | Substantial or final completion |
| Closeout documents, O&M manuals | Successor | Final completion |
| Site work, landscaping | Successor | Final completion or TCO, if required |
| Owner-furnished equipment delivery | Predecessor | A start constraint or procurement chain |
| Permit issuance | Predecessor | Start milestone or a start constraint with a documented date |
The procurement ones are especially sneaky. A "Fabricate and deliver switchgear" activity that doesn't drive the switchgear install makes the switchgear lead time look irrelevant. Long-lead equipment is where a lot of real delay comes from, so it's the last place you want the schedule to be blind.
Dangling logic: the less obvious kind
An activity can have both a predecessor and a successor and still dangle.
Open finish (SS-only successors)
Drywall hanging, Level 5, has one successor: taping, Level 5, linked SS + 3. Hanging has a successor, so it passes a simple "missing successors" check. But nothing depends on when hanging finishes. It could take 40 days instead of 10 and taping wouldn't notice, because taping only cares that hanging started.
Fix: add an FF from hanging to taping, or an FS from hanging to the next activity that really needs hanging done (for example, ceiling grid or the drywall inspection, if your jurisdiction does one).
Open start (FF-only predecessors)
The mirror image. Taping has one predecessor: hanging, linked FF + 2. Nothing controls when taping starts, so the forward pass puts it at the earliest possible point (the project start or the data date). The bar shows taping starting months before hanging.
Fix: add an SS (usually with a lag) or an FS from something that genuinely has to happen first. See FS, SS, FF, SF: Choosing the Right Relationship Type.
Constraint instead of logic
An activity with no predecessor but a Start On or After constraint isn't technically an open end in some tools. It still isn't driven by logic. If a real predecessor exists, link it. Use constraints only for dates that come from outside the schedule. See Schedule Constraints: When to Use Them and What They Break.
Ties to the wrong place
Everything with no obvious successor gets linked to the project complete milestone. Technically, no open ends. But punch list and closeout activities that feed only "project complete" may show weeks of float when they really need to finish before substantial completion. Tying an activity to the end of the project to satisfy a checker is not the same as tying it to what it actually drives.
How to find them
Most CPM tools give you what you need:
- Filter for activities with no predecessors and no successors. P6's schedule log lists activities without predecessors and without successors every time you schedule. MS Project needs a custom filter or a column showing predecessor and successor counts.
- Sort by total float, descending. Activities with very high float are usually missing a successor. An activity with more float than the remaining duration of the project is almost certainly wrong.
- Check relationship types on each activity. Look for activities whose only outgoing relationships are SS, or whose only incoming relationships are FF.
- Run a schedule quality check. The DCMA 14-Point Assessment's first check is missing logic, and it expects open ends on no more than 5 percent of incomplete activities. Many tools, including schedule.construction, run DCMA-style checks and list the offending activities. See The DCMA 14-Point Assessment, Explained for Construction.
A cleanup routine
- Schedule the project and pull the list of activities missing a predecessor or successor.
- For each one, ask the superintendent or the trade: "What has to happen before this?" and "What can't happen until this is done?"
- Add the real ties. Don't default everything to the project finish milestone.
- Find SS-only successors and FF-only predecessors. Add the missing finish or start tie.
- Sort by total float and investigate anything with float that looks too good.
- Reschedule and compare the critical path to what you had before. Fixing open ends often moves it, sometimes a lot.
- Repeat at every update. New activities get added during the job, and they're added in a hurry.
Key takeaways
- Every activity except the start and finish milestones needs a predecessor driving its start and a successor driven by its finish.
- Open ends inflate float. The schedule looks safe while the job slips.
- SS-only successors leave a finish open. FF-only predecessors leave a start open. Both are dangling logic.
- Tying everything to the project finish milestone clears the checker but not the problem.
- Check for open ends at every update, not just the baseline.