Dependency Identification

Dependency Identification is the deliberate practice of discovering and documenting the specific points at which a team's work relies on something outside its own direct control, such as another team's deliverable, an external system, a required approval, or a piece of information yet to be provided, so that these reliances are known and can be actively planned around rather than discovered only once they begin causing disruption. It is the foundational first step within Dependency and Impediment Management, since a dependency that has not been identified cannot be tracked, communicated, or accounted for in planning, no matter how well the rest of the management approach is otherwise designed.

Why Identifying Dependencies Matters

Converting Hidden Reliance Into Visible Information

Many dependencies exist implicitly within a plan without being explicitly stated, and identification surfaces this hidden reliance, converting an assumption about self-sufficiency into an explicit, examined fact that can be managed deliberately.

Enabling Realistic Planning

Once dependencies are identified, planning can account for the timing constraints they introduce, sequencing work in a way that respects when each dependency is actually expected to be satisfied rather than assuming the team's work can proceed entirely independently.

Reducing the Frequency of Unanticipated Impediments

Because many impediments originate from dependencies that were not properly tracked and consequently went unmet, thorough identification reduces the likelihood of being caught off guard by a disruption that earlier, deliberate attention could have anticipated.

Categories of Common Dependencies

Cross-Team Dependencies

Reliance on work being produced by another team within the same organization, such as a shared component or a required interface, represents one of the most frequent sources of dependency in organizations where multiple teams contribute to a connected product.

External Vendor or Partner Dependencies

Reliance on a piece of work, service, or approval coming from an organization outside the team's own company introduces dependencies whose timing and quality are often less directly influenced by the team itself, requiring particular attention.

Technical and Infrastructure Dependencies

Reliance on shared technical infrastructure, platforms, or tools being available and functioning as expected represents a category of dependency that can be easy to overlook since it is often assumed to simply exist rather than treated as something requiring explicit tracking.

Information and Decision Dependencies

Reliance on a specific piece of information or a formal decision from a stakeholder, before certain work can proceed, constitutes a dependency just as concrete as a deliverable, even though it is less tangible in nature.

Techniques for Identifying Dependencies

Reviewing Planned Work for Implicit Assumptions

Examining planned work items specifically to ask what each one assumes will already be true or available reveals dependencies that might not be mentioned explicitly in the description of the work itself.

Mapping Relationships Between Teams

For work involving multiple interconnected teams, deliberately mapping which teams rely on outputs from which others surfaces a structured view of dependency relationships that might otherwise only become apparent informally and incompletely.

Structured Planning Discussions

Including a specific, deliberate step during planning sessions to ask what the team is relying on outside its own control encourages systematic surfacing of dependencies rather than relying on them to be mentioned only if someone happens to think of them.

Reviewing Historical Patterns

Examining what dependencies caused disruption in previous, similar work provides a useful starting point for anticipating comparable dependencies in current planning, since similar work often relies on similar external factors.

When Dependency Identification Occurs

During Initial Planning

Early identification, performed as part of planning for an upcoming body of work, establishes a baseline understanding of what the team will rely on before committing to specific timelines or sequencing decisions.

Continuously Throughout Delivery

Because new dependencies can emerge as work evolves and scope shifts, identification is repeated throughout delivery rather than treated as a single, one-time activity confined to the earliest stage of a project.

Consequences of Incomplete Identification

Being Surprised by Preventable Delay

A dependency that was never identified cannot be planned around, meaning the team may be caught off guard when the relied-upon factor is not available exactly when needed, converting what deliberate identification could have anticipated into an unexpected impediment.

Underestimating True Schedule Risk

Plans built without full awareness of actual dependencies tend to understate genuine schedule risk, since the timing constraints those unidentified dependencies impose are not reflected in the plan at all.

Visual Representation

Each identified dependency links the team's work to a specific external source of reliance. This can be expressed as:

Dependency Identification is the deliberate effort to ensure this sum reflects a genuinely thorough scan across all relevant sources, rather than capturing only whichever dependencies happen to be most immediately visible.