DCMA-14 Metric 4 — Relationship Types: Why Non-FS Relationships Get Flagged

DCMA flags non-Finish-to-Start relationship types because it wants at least 90% of logic links in a construction schedule to be Finish-to-Start (FS). FS gives a clear sequential path, while Start-to-Start (SS), Finish-to-Finish (FF) and Start-to-Finish (SF) links can obscure logic and distort float. SS and FF are not banned; they should be a minority, and justified.

This is metric 4 of the DCMA-14 schedule assessment. Construction is full of legitimate overlaps, so the real skill is knowing which non-FS links to keep and how to defend them.

What are the four relationship types in a construction schedule?

Every logic link ties a predecessor to a successor in one of four ways. Oracle's Relationship Types check documentation defines them in P6 terms.

Any of them can carry a lag. The DCMA metrics for lags and leads are counted separately from this one.

What exactly does DCMA require?

The DCMA pamphlet says Finish-to-Start relationships should make up at least 90% of logic links. Start-to-Finish is to be used "only very rarely and with detailed justification." The formula is:

FS % = FS logic links ÷ all logic links

That is all the pamphlet states numerically. Secondary sources add detail. Mosaic Projects' summary says the non-FS share should be mostly SS and FF, with other types under about 5%, and SmartPM lists SF at zero. Treat those as the authors' interpretations, not DCMA text.

Oracle's own check is looser still. The P6 Relationship Types section of the Schedule Check Report gives no numeric threshold and only says the majority of relationships should be FS.

Worked example

Illustrative example, with assumed counts: a schedule has 900 logic links.

FS is 87.8%, below the 90% floor, so the metric is flagged. Reaching 90% needs 810 FS links. The five SF links are a second issue, because each one needs detailed justification regardless of the percentage.

Why do SS and FF links get flagged?

The concern is what SS and FF can hide. Three problems come up in reviews.

They let activities float loose. An activity whose only predecessor is an SS link has no constraint on when it finishes, and one whose only successor is an FF link has no constraint on when it starts. The network looks connected when counted by links, yet the activity can drift. Pairing SS with FF closes the gap.

They complicate float. With an SS link, total float on the predecessor depends on the successor's start, not its finish. Readers used to FS logic misjudge which activity is driving.

They reduce visibility. A long chain of overlapping activities tied by SS makes it hard to see the sequence on a bar chart, and progress can run out of sequence. The logic metric is the companion check for missing ties.

None of that makes them wrong. Floor-by-floor repetitive work, overlapping trades, and phased turnover all produce natural SS and FF logic.

How an SS-only tie leaves a finish unconstrained

Illustrative example with assumed durations. Framing (A100) takes 15 days. Drywall (D200) takes 10 days and is tied to framing by SS +5 only.

Drywall finishes on day 15, the same day framing does, because nothing ties its finish to the framing finish. If framing's duration grows by 10 days, nothing pushes drywall's finish, because only the starts are linked. The schedule can show drywall done while framing is still open. Adding A100 FF +3 fixes this: drywall now finishes no earlier than three days after framing. This is the pairing check in practice.

What mistakes do reviewers flag most often?

• SS with no finish tie. The example above is the most common defect in construction schedules.
• Large lags on SS links. A 40-day SS lag often means two activities that should be separate sequential phases.
• SF links with no note. The pamphlet requires detailed justification, and a bare SF is the first thing a reviewer questions.
• Forcing FS to hit the percentage. Converting a real overlap to FS lengthens the schedule or hides the overlap in a duration that no longer matches the work.
• Mixing tool counts. A 91% in one tool and 88% in another can be the same file, because tools handle paired SS and FF links and the denominator differently.

When are SS and FF relationships genuinely valid?

A non-FS link is defensible when it reflects a physical or contractual relationship and a reviewer could verify it on site.

• Repetitive sequence. The framing crew starts level 4 five days after starting level 3. Use SS with a positive lag, paired with FF if finishes must also stagger.
• Concurrent trades in the same area. Electrical rough-in starts once framing starts, but cannot finish before framing does. Use SS and FF together.
• Testing tied to installation. A test cannot finish until installation finishes: FF, usually with a lag for the test duration.
• Continuous operations. Excavation and hauling run together, so hauling starts when digging starts.

Oracle's help for both the relationship types and negative lags checks recommends a positive lag on SS instead of a negative lag on FS, which is the pattern above.

A before-and-after

Assume A100 is framing L3 (15 days). The paired SS and FF replace a sequential FS that did not match the field: rough-in starts four days after framing starts and finishes three days after framing finishes.

How do I document and defend non-FS links?

Document each one on three levels.

1. The activity or relationship note. One line: why the overlap exists and what the lag represents.
2. The schedule narrative. A paragraph on the count by type, the percentage of FS, and the categories of non-FS links.
3. A pairing check. Confirm every SS-only predecessor has a finish tie. Reviewers who see dangling SS links will assume missing logic.

Keep a short table for the submittal listing non-FS link categories and the count in each. Then reconcile the percentage with the reviewer's tool. Mosaic notes that MS Project does not allow paired SS and FF links between the same two activities while P6 does, so link counts differ by tool, and the percentages you report should name the tool you used.

How do I check relationship types in P6?

Use the schedule check report's relationship types section, which reports the distribution, or export the relationships and count by type. Compute FS ÷ all links yourself and record the date and tool. Menu paths vary by version, so confirm in yours.

To reduce non-FS counts without distorting the logic, consider these steps:

• Replace SS links that have no real overlap with FS.
• Split an overlapping activity at the point where the successor begins, then use FS to the second part.
• Convert large negative lags on FS to SS plus a positive lag.
• Remove redundant links, because duplicates inflate the denominator.

Reschedule after each change and compare the finish date and critical path. If the dates move, the old link was carrying time that the new logic should represent honestly.

The metric is a flag, not a verdict. A construction schedule at 86% FS with each non-FS link documented will usually fare better in review than a schedule at 91% where the scheduler forced FS links to hit a number.