Schedule · Letter D

Dependency Mapping

The systematic identification of internal, external, mandatory, and discretionary relationships between activities so the schedule logic mirrors the way work really has to happen.

By Dr. Hassan Eliwa, PhD · Founder of PMMilestone.org and PMMilestone.com · Updated 2026-06-28

Definition

Dependency Mapping is the disciplined identification and classification of every relationship between activities, deliverables, or teams that determines what must happen before something else can start or finish. AACE and PMI describe four classes: mandatory (hard logic, dictated by physics or contract), discretionary (preferred sequencing), external (outside the project), and internal (within the project). On the schedule it appears as predecessor/successor links; on a programme it appears as a dependency log.

Why It Matters

Most schedule failures are dependency failures. Tasks finish; their successors cannot start; the team learns at the daily stand-up. The cost of a missed external dependency rises with how late it surfaces. Mapping the dependencies before the work makes the schedule honest and the risk register useful.

Types

  • Mandatory — physical or legal necessity ("rebar before pour").
  • Discretionary — preferred sequence ("integration test before performance test").
  • External — outside the team or project ("permit issuance by regulator").
  • Internal — within the project ("steel detailing before fabrication release").

Real-World Construction Example

On a port expansion, a dependency mapping workshop with engineering, procurement, marine, and operations surfaced 23 previously implicit dependencies. The most consequential: a regulatory navigational permit required hydrographic survey data the survey contractor was not contracted to provide before dredging began. The discovery, made eight months early, cost $48,000 to resolve. Found six weeks before dredging, it would have cost approximately $2.1M in vessel standby.

Real-World IT / Agile Example

A platform team mapping cross-squad dependencies for a single quarter identified 41 inter-team handoffs across nine squads. The exercise produced a one-page heatmap of which squads were most coupled. Six handoffs were renegotiated to feature flags or stub APIs; two squads merged epics; one external partner's missing API was escalated and contracted. The next quarter's velocity rose 14% with no team additions.

Key Takeaways

  • Dependencies cause more delay than scope, weather, or labour combined on most projects.
  • Mandatory and external dependencies are immovable — they must be discovered, not invented.
  • Discretionary dependencies hide opportunity; challenge them in every plan review.
  • The dependency map ages — re-run it at each rolling wave.

Expert Tips

  • Run the workshop with the people who do the work, not their managers.
  • Mark every external dependency with a named owner outside the team; ownerless external dependencies are root-cause for missed dates.
  • Quantify dependency slack — short slack on external dependencies is the highest-risk pattern in the plan.
  • Tag discretionary dependencies so a future planner knows where compression is possible without re-engineering.
  • Visualize: a dependency graph reveals patterns no spreadsheet does.

Common Mistakes

  • Treating Finish-to-Start as the default and ignoring SS/FF/SF relationships where they are physically real.
  • Missing the external dependency on a vendor, regulator, or sister project.
  • Burying dependencies in narrative and never re-extracting them when the schedule changes.
  • Discretionary dependencies left unchallenged for years because "we have always done it that way."
  • Letting look-ahead sessions ignore dependencies in favour of activities — the activities are usually fine; the dependencies are what fail.

Practical Lessons Learned

  • Capital projects with a formal dependency log have fewer claims; the log is its own dispute-avoidance tool.
  • Squads that map dependencies quarterly run quieter quarters than ones that improvise.
  • The dependency that costs you most is the one nobody felt accountable to name.

Related Encyclopedia Entries

Related Research Articles, Case Studies & Tools

Frequently Asked Questions

  • Is finish-to-start the only dependency type that matters?
    No — SS, FF, and SF are common on construction and on integrated software releases.
  • How often should dependencies be remapped?
    Each rolling-wave planning cycle and after any major change.
  • What is the highest-risk dependency type?
    External dependencies with short slack and no named owner.
  • Can discretionary dependencies be removed?
    Often, with engineering review. They are the prime target for schedule compression.
  • Do agile teams need dependency mapping?
    Yes — cross-squad and external dependencies are the main cause of missed quarterly commitments.
  • Should dependencies live in the schedule or a separate log?
    Both — internal in the schedule; external in a log with named owners.
  • What is the best tool?
    Any tool the team will actually maintain. Sophistication without maintenance is worse than a wall of sticky notes.
  • Which calculators on PMMilestone.org apply to Dependency Mapping?
    For Dependency Mapping, the most relevant tools on the flagship platform are the EVM, SPI and CPI calculators on PMMilestone.org. They reproduce the formulas referenced in this entry against your own project data.
  • What is a common misconception about Dependency Mapping?
    That the topic is well-defined across all references. In practice, definitions vary between PMBOK, PRINCE2, AACE and ISO 21500 — this entry uses the definition most aligned with field practice on capital projects, and flags where the standards diverge.
  • Which related encyclopedia entries should I read alongside Dependency Mapping?
    Read Earned Value Management, Critical Path Method and the DCMA 14-point assessment next. The full A–Z is available in the PMMilestone Encyclopedia, and quick one-line definitions live in the PM Glossary on the flagship platform.
  • How does Dr. Hassan Eliwa's research treat Dependency Mapping?
    Dr. Hassan Eliwa's research focuses on owner-side project controls, schedule integrity and forensic delay analysis on capital construction and power programmes. Dependency Mapping is treated through that lens — what a planning or controls engineer is expected to do with it on a live project, not its textbook definition alone. See the full research library at PMMilestone Research Articles.
  • How is Dependency Mapping defined on PMMilestone Research & Insights?
    The systematic identification of internal, external, mandatory, and discretionary relationships between activities so the schedule logic mirrors the way work really has to happen. For the full treatment, see the definition, principles, applications and related entries above — every encyclopedia entry follows the same research-grade structure.

People also ask

Follow-up questions practitioners search for next — each one points to the calculator, template or reference entry that answers it.

Related Entries

Browse more in this category

More in Schedule

View all Schedule entries →

Further reading on PMMilestone.org

Curated companion resources hosted on the flagship platform, PMMilestone.org.

Related Encyclopedia Entries
Career Guides
Tools on PMMilestone.org
Buy me a coffee