Dependency Determination

Schedule technique · See it on the map

Guide only — A printable worksheet is written for it; there is no figure for a launcher to compute.

Sorting each link between tasks into what is a fixed fact and what is really a choice.

When to use it

Use it while building the dependency network, specifically when you're deciding whether a sequencing choice is negotiable. It's the technique that tells you which arrows in a precedence diagram are safe to challenge when you need to compress the schedule and which ones aren't.

When to avoid it

Skip formal classification for a small project where the whole team already knows, informally, which orderings are real constraints and which are habit — writing it down there is overhead without a decision it's going to change.

Steps

1. For each dependency in the network, ask whether the sequence is inherent to the work itself (mandatory / "hard logic", e.g. concrete must cure before framing) or a preference the team or organization chose (discretionary / "soft logic", e.g. doing design review before code review because that's the team's convention).
2. Separately, ask whether the dependency involves a party outside the project (external, e.g. a permit from a city office) or is entirely within the team's control (internal).
3. Tag each dependency with both classifications.
4. When you need to compress the schedule, look first at discretionary dependencies — those are the ones you can legally reorder or overlap without violating a real constraint.

What it produces

• Every dependency in the network tagged mandatory-or-discretionary and external-or-internal, so a later compression pass knows which arrows are actually movable.

Common pitfalls

• A discretionary dependency gets treated as mandatory because "that's how we've always done it", which quietly removes real compression options from consideration.
• An external dependency gets classified but not tracked separately with its own lead time and owner, so its risk to the schedule goes unmanaged until it's already late.
• The classification is done once and never revisited, even after the circumstance that made a dependency mandatory (a specific vendor, a specific regulation) has changed.

Worked example

On a museum exhibit build, "install glass display cases" must follow "cure the epoxy floor coating" — mandatory and internal. "Submit exhibit signage for curator sign-off" must follow "finalize signage copy" and involves a party outside the project team — mandatory and external. "Paint gallery walls" before "hang wayfinding signs" is discretionary and internal — the team could do it the other way if wall painting slips.

Source

• PMBOK-6 §6.3.2.2

Where it comes from: this technique is named by the PMBOK Guide, 6th edition.