Dependencies types in project management refer to the classification of relationships between project activities or work packages based on how and why one activity depends on another. The term encompasses mandatory, discretionary, external, and internal dependencies, each describing a different origin or degree of control over the sequencing logic in a project schedule. Understanding these types is fundamental to building realistic schedules, estimating critical paths, and managing coordination across teams and suppliers. In practice, project managers use dependencies types to decide which tasks can start only after others finish, which sequences are preferred but not strictly required, and which activities depend on factors outside the project team’s control.
Dependencies Types: Key Topics Summary
| Key Concept | Summary |
|---|---|
| Dependency Types | Mandatory, discretionary, external, and internal dependencies each define a distinct origin of sequencing constraints and the level of control the project team can exert. |
| Sequencing Decisions | Dependency analysis informs which activities are strictly ordered, which sequences reflect best practice rather than hard constraints, and which rely on conditions beyond the team's authority. |
| Scope | These classifications operate across the project hierarchy, from individual activities and work packages to milestones, deliverables, and program-level initiatives. |
| Combined Classifications | Dependencies frequently combine dimensions: regulatory approval prior to release is both mandatory and external, while a preferred code review step is both discretionary and internal. |
| Common Examples | Typical instances include completing foundation work before erecting structural steel and obtaining approved requirements before finalizing detailed design. |
| Mislabeling Risk | Teams often classify dependencies as mandatory without confirming whether the constraint is a physical necessity or an ingrained practice that could be challenged. |
| Discretionary Rationale | Discretionary dependencies are deliberate choices, generally retained because prior experience showed a specific sequence reduces risk or improves quality. |
| Agile Goal | In Agile delivery, the objective is to eliminate or minimize dependencies through cross-functional teams, smaller story decomposition, and thin vertical slices that reduce handoff overhead. |
What Are Dependencies Types?
A dependency, in project management, exists when one scheduled activity or deliverable relies on another for an input, completion, approval, or resource. The dependencies types definition therefore centers on a systematic way to group these reliance relationships according to their nature, flexibility, and source. The two most commonly taught dimensions are whether a dependency is mandatory or discretionary and whether it is internal or external. These four categories appear in the PMBOK Guide as part of the Sequence Activities process, and they form the backbone of schedule network logic.
What this means on a construction site is that the concrete pour must happen before framing can begin, because the frame needs a stable base. That kind of physical necessity is mandatory. But choosing to install windows after the roof is on, rather than before, might simply be a preference based on weather protection. That preference is discretionary, and the project manager may be able to change it if the schedule demands faster progress.
Core Meaning and Scope
Dependencies types can apply to activities, work packages, milestones, products, and even entire projects within a program. The concept is used whenever one unit of work cannot start, finish, or achieve quality without something else happening first. The classification gives the project team a shared vocabulary for discussing why a sequence exists, which is different from simply knowing the order of tasks. Some organizations refer to dependency categories rather than dependency types, but the underlying logic remains the same.
Why Dependency Types Are Not the Same as Dependency Relationships
Dependencies types are often confused with precedence relationships such as finish-to-start or start-to-start. A precedence relationship describes the timing order between two activities. A dependency type describes the reason or authority behind that order. For example, a finish-to-start relationship might be mandated by law, making it mandatory, or it might be chosen by a project manager, making it discretionary. Recognizing the difference prevents schedule logic from looking mathematically sound while remaining behaviorally or contractually wrong.
Key Takeaways on Dependency Classification
- Dependency defined by reliance
- A dependency arises when one scheduled activity or deliverable depends on another for an input, completion, approval, or resource, and this relationship extends to activities, work packages, milestones, products, and even entire projects within a program.
- Four core dependency categories
- Dependencies are systematically classified along two independent dimensions, mandatory versus discretionary and internal versus external, and the resulting four categories form the structural backbone of schedule network logic in the PMBOK Guide's Sequence Activities process.
- Classification validates schedule logic
- Classifying each dependency gives the team a shared vocabulary for explaining why a sequence exists and helps prevent schedules from being mathematically valid yet behaviorally or contractually unsound.
Key Components of Dependencies Types
The key components of dependencies types include the two classification axes and the practical subcategories that emerge in real schedules. The first axis separates mandatory dependencies from discretionary dependencies. The second axis separates internal dependencies from external dependencies. A single dependency can be both mandatory and external, such as a regulatory approval that must occur before shipping, or discretionary and internal, such as a team preference for code review before merging.
Mandatory Dependencies
Mandatory dependencies are inherent in the nature of the work or imposed by legal, contractual, or physical constraints. They are sometimes called hard logic because they cannot be ignored without compromising quality, safety, compliance, or feasibility. Examples include pouring a foundation before erecting structural steel or receiving approved requirements before finalizing detailed design. In schedule models, mandatory dependencies define the non-negotiable skeleton of the project’s sequence. A common reality is that some teams label dependencies mandatory without verifying whether the constraint is truly physical or merely a deeply embedded habit.
Discretionary Dependencies
Discretionary dependencies reflect preferred practices, organizational norms, or expert judgment about sequencing. They are sometimes called soft logic or preferential logic. A project manager may choose to run user interface design after backend architecture is stable, not because the interface cannot be designed earlier, but because it reduces rework. Discretionary dependencies can be removed or rearranged when schedule pressure demands faster delivery, which makes them valuable compression candidates. However, they should not be treated as arbitrary; they usually exist because past experience demonstrated lower risk or better quality in a particular sequence.
External Dependencies
External dependencies involve activities, deliverables, or decisions outside the immediate project team’s control. These might include supplier shipments, regulatory inspections, client approvals, or deliverables from another project. They are often mandatory in practice, but their timing is governed by an external party, which creates schedule risk. A project manager can influence an external dependency through contracts, service level agreements, or escalation, but cannot direct it the way they can direct internal work. Tracking them separately is critical because they frequently cause delay when hidden in a detailed task list.
Internal Dependencies
Internal dependencies exist between activities within the project team’s control. These are the most manageable because the project manager, product owner, or delivery lead can adjust priorities, add capacity, or resequence work. An internal dependency might involve a backend developer needing an API contract from a frontend team within the same project. Because these are controllable, they are sometimes overlooked as a source of delay, but poor internal handoffs can be just as damaging as external waits.
Resource and Cross-Team Dependencies
Beyond the four formal categories, practitioners commonly describe resource dependencies and cross-team dependencies. A resource dependency occurs when two activities cannot proceed in parallel because they require the same specialized person or equipment. A cross-team dependency arises in multi-team environments when one group must finish a story, component, or interface before another group can complete its work. These are not always named in the PMBOK Guide as distinct dependency types, but they are widely used in program management, SAFe, and large-scale agile settings.
Hard Logic and Soft Logic
The terms hard logic and soft logic map closely to mandatory and discretionary dependencies. Hard logic implies that the dependency is physically or legally unavoidable. Soft logic implies that the dependency is a choice shaped by preferences, past experience, or risk tolerance. Planners sometimes use these labels informally during schedule reviews because they are quicker to say and easier for stakeholders to understand. The formal PMBOK categories add more precision by also distinguishing internal and external sources.
Dependencies Types in PMBOK
In the PMBOK framework, dependencies types in PMBOK appear primarily during the Sequence Activities process within Project Schedule Management. The PMBOK Guide identifies mandatory, discretionary, external, and internal dependencies as the categories used to determine the logical sequence of work. These types are evaluated alongside leads and lags to develop a schedule network diagram. The output of this process is a project schedule network diagram and updated activity attributes, both of which feed schedule development.
Sequence Activities and Dependency Determination
During Sequence Activities, the project manager examines each activity and asks what must precede it and what can follow it. Dependency determination is the tool used to classify the relationship before assigning a precedence relationship. By first classifying the dependency type, the planner avoids treating an optional sequence as a hard constraint or an external obligation as an internal task. This step makes the schedule defensible because the logic reflects actual business and technical constraints rather than only habit or convenience.
Precedence Diagramming Method and Dependency Types
The Precedence Diagramming Method assigns finish-to-start, start-to-start, finish-to-finish, and start-to-finish relationships. These relationships describe the timing mechanics, while dependency types describe the origin and flexibility of the requirement. A finish-to-start relation may be mandatory, such as code compilation before testing, or discretionary, such as documentation review before code review. Project managers commonly mix these concepts, but PMI treats them as separate elements of sequencing. PDM also incorporates leads and lags, which adjust the timing between activities without changing the underlying dependency type.
Role in Schedule Baseline and Critical Path
Dependencies types shape the critical path because every path in the schedule network is a chain of activities connected by dependencies. Mandatory dependencies often create the longest path that cannot be compressed without scope or design changes. Discretionary dependencies are often the first place project managers look when applying fast tracking, since soft logic can sometimes be removed to run activities in parallel. External dependencies introduce uncertainty that may require buffers or contingency reserves. Internal dependencies can often be managed through resource leveling or clearer work authorization.
Key Insights on Dependency Types
- Four dependency categories defined
- The PMBOK framework recognizes four dependency categories, namely mandatory, discretionary, external, and internal, each of which is assessed during Sequence Activities so the project team can establish a defensible logical order for the work.
- Sequence Activities process role
- Within the Sequence Activities process, the project manager identifies predecessor and successor relationships for every activity, and classifying each dependency prevents discretionary sequencing choices or external obligations from being mistaken for hard internal constraints.
- Schedule network diagram output
- Combined with leads and lags, these classified dependencies provide the foundation for the project schedule network diagram and revised activity attributes, both of which feed directly into the Develop Schedule process.
- Discretionary dependencies and fast tracking
- Discretionary dependencies are the most suitable targets for fast tracking because their soft logic can often be adjusted or removed to allow activities to run in parallel, for example converting a finish-to-start relationship such as documentation review before code review into concurrent work.
Dependencies Types in PRINCE2
PRINCE2 does not use the exact same four-category model as the PMBOK Guide, but it addresses dependencies types in PRINCE2 through the Plans theme and product-based planning technique. Dependencies in PRINCE2 are identified by considering what must be produced before something else can be produced or completed. The product breakdown structure and product flow diagram show the sequence of products and the dependencies between them. External dependencies are specifically called out because they originate outside the project’s control and often affect stage plans and project plan feasibility.
Product-Based Planning and Dependencies
Product-based planning starts with the products rather than the activities. Once the product breakdown structure is created, the product flow diagram defines the order in which products will be developed and integrated. A dependency in this context can be functional, meaning one product contains information needed by another, or chronological, meaning production cannot begin until another product reaches a certain state. This product-first approach surfaces dependencies that activity-level planning often misses, particularly in complex integration projects.
External Dependencies and Stage Control
PRINCE2 emphasizes management by stages, and dependencies influence where stage boundaries are placed. If a critical external dependency delivers during a future stage, the plan may include a stage boundary or a control point around that delivery. The Project Board monitors such dependencies because they can affect the business case if conditions change. PRINCE2 also recognizes that dependencies are not static; they must be reviewed at the end of each stage and updated in the next stage plan.
Dependencies Types in Agile and Hybrid Projects
In Agile environments, dependencies types in Agile are often described more fluidly than in predictive scheduling. Scrum teams, for example, may track dependencies between user stories, between teams, or between a team and an external vendor. The underlying categories still exist, but they surface through backlog refinement, sprint planning, and team-of-teams coordination rather than through a formal network diagram. Hybrid projects often combine a milestone-level predictive schedule with agile delivery, meaning traditional dependency classification is applied at the release or epic level while team-level dependencies are handled in backlogs.
How Scrum and Kanban Handle Dependencies
Scrum does not prescribe a dependency taxonomy, but teams commonly distinguish between internal story dependencies and external team dependencies. A user story might depend on another story in the same product backlog, on an API from a different team, or on a third-party service. Kanban teams often visualize such dependencies on their boards or use dependency tags to prevent work from stalling. The practical goal in Agile is not merely to classify dependencies but to remove them, usually by creating cross-functional teams, splitting stories, or building thin vertical slices that reduce handoffs.
SAFe and Program-Level Dependencies
The Scaled Agile Framework explicitly addresses dependencies during PI Planning. Teams use a program board to show feature dependencies, milestone dependencies, and cross-team coordination points. A dependency may be internal to the Agile Release Train or external to suppliers and shared services. SAFe encourages teams to minimize dependencies by aligning teams around value streams, but when dependencies remain, they are made visible and assigned owners. This differs from traditional scheduling, where dependencies may be buried in a Gantt chart, because the entire program reviews them face-to-face during planning.
Hybrid Dependency Management
In hybrid delivery, dependencies at the work package level may follow a predictive schedule, while dependencies inside a sprint backlog follow agile rules. The project manager often maintains a milestone-level network diagram that shows mandatory and external dependencies, while the product owner and scrum master manage internal story dependencies. The key is not forcing one approach on all dependencies, but choosing the right level of formality based on the dependency’s risk and organizational impact. This pragmatic blend is increasingly common in large enterprises.
Key Insights on Agile Dependencies
- Fluid Agile dependency tracking
- Agile teams surface dependencies dynamically through backlog refinement, sprint planning, and cross-team coordination, which makes formal network diagrams largely unnecessary.
- Hybrid combines predictive and agile classification
- Hybrid delivery models apply structured dependency classification at the release and epic levels, while team-level dependencies continue to be managed within backlogs.
- Scrum separates internal and external dependencies
- Scrum teams distinguish internal story dependencies from external integration points such as APIs delivered by other teams or third-party services.
- Kanban uses visual dependency management
- Kanban teams make dependencies visible directly on their boards and often use dependency tags to prevent work from stalling and keep flow uninterrupted.
- Agile prioritizes dependency removal over classification
- Agile practice prioritizes eliminating dependencies altogether by building cross-functional teams, splitting stories, and creating thin vertical slices that reduce handoffs and accelerate delivery.
Purpose and Importance of Dependencies Types
The purpose and importance of dependencies types lies in their ability to make schedule logic transparent, defensible, and easier to adjust under pressure. When a project manager knows which dependencies are mandatory, schedule compression efforts can target discretionary logic without violating physical or regulatory constraints. When external dependencies are separately identified, the team can monitor them more closely and assign early warning indicators. Without this classification, a schedule can appear coherent while hiding fragile assumptions and uncontrolled external waits.
Schedule Realism and Critical Path Accuracy
Critical path analysis depends entirely on accurate activity sequencing. If discretionary dependencies are entered as if they were mandatory, the critical path may appear longer and less flexible than it truly is. If external dependencies are omitted, the schedule may show an optimistic completion date that ignores supplier lead times or client approvals. Categorizing dependencies forces planners to justify each relationship, which improves estimate confidence and supports more honest communication to stakeholders. This is especially relevant in regulatory or construction projects, where mandatory dependency chains define the minimum feasible duration.
Risk Identification and Response
Dependency classification also feeds risk management. An external dependency often carries higher schedule risk because the project team has limited control. A mandatory dependency may create a single point of failure if that activity slips. By examining dependency types, a project manager can identify where buffers, alternative approaches, or early procurement actions are needed. This is a key reason dependency review appears during plan quality checks and stage gate reviews.
Coordination and Governance
At the governance level, knowing the dependency types helps executives understand why a milestone cannot move. A mandatory dependency linked to a safety inspection is not negotiable, while a discretionary dependency linked to a preference for sequential design may be open to discussion. This distinction supports better decision-making in change control boards and steering committees. It also frames trade-off conversations around cost, scope, and time in terms that business leaders can evaluate.
Practical Application of Dependencies Types
The practical application of dependencies types spans the entire project lifecycle, from initial scoping through closing. In early planning, project managers identify dependencies by analyzing technical requirements, contracts, resource availability, and stakeholder commitments. During schedule development, they encode these dependencies into a network diagram or gantt chart. Later, during execution, they monitor the same dependencies for changes and escalate blockers. The types remain useful even after delivery, when teams analyze which dependencies caused delay and how future projects can avoid them.
Dependency Discovery in Project Initiation
During chartering and scope definition, external dependencies are often visible at a high level, such as a permit, a client decision, or a shared service from another program. Internal and mandatory dependencies become clearer as the work breakdown structure emerges. Project managers may not yet have a detailed schedule, but they can note major dependencies in the project charter assumptions and constraints section. This early visibility helps sponsors understand why the project may have a long lead time before visible delivery begins.
Sequencing and Baselining in Planning
The core use occurs when the project manager sequences activities and develops the schedule baseline. Each dependency is classified, assigned a relationship type, and adjusted with leads or lags. The resulting network diagram supports critical path calculation, resource leveling, and compression analysis. At this stage, dependency types influence the schedule baseline because mandatory dependencies set the minimum duration, while discretionary dependencies offer potential flexibility. External dependencies may require calendar buffers or contingency reserves to absorb third-party variability.
Monitoring and Controlling Dependencies During Execution
During execution, dependencies types help prioritize monitoring. External dependencies typically need more frequent status checks because they are outside the team’s control. Mandatory dependencies require early warning systems because a slip can cascade through the critical path. Discretionary dependencies may be reevaluated when the project falls behind, possibly removed to recover time. Many organizations maintain a dependency log with risk ratings, owners, and next review dates, which becomes a standing agenda item in project status meetings.
Closing and Lessons Learned
At project closure, dependency analysis can reveal patterns. Some teams find that certain external partners consistently deliver late, or that many mandatory labels were actually preferences. These insights feed into organizational process assets, templates, and future estimating practices. The dependency log is also reviewed to confirm that no open commitments remain outstanding. This closing discipline is often skipped, but it sharpens the organization’s ability to plan more accurately on the next initiative.
Key Takeaways on Dependency Management
- Dependencies span the full lifecycle
- Dependencies influence project outcomes from initial scoping and planning through final delivery, and they remain central to reviews that assess delays and capture lessons learned.
- Early identification through project charters
- External dependencies such as permits and client decisions are recorded in the assumptions and constraints section of the project charter, which gives sponsors early visibility into approval lead times and supports proactive risk planning.
- Schedule baseline and network analysis
- Mandatory dependencies define hard constraints and minimum durations, while discretionary dependencies give schedulers room to adjust sequencing during critical path analysis, resource leveling, and schedule compression exercises.
- Ongoing tracking with dependency logs
- Organizations that maintain dependency logs with risk ratings, assigned owners, and review dates are better positioned to surface emerging issues early, and they treat dependency reviews as a standing agenda item in project status meetings to sustain accountability.
Common Challenges and Misconceptions About Dependencies Types
One of the most common misconceptions about dependencies types is that discretionary means optional. Common misconceptions about dependencies types often lead project managers to remove soft logic without analyzing the risk that led to its inclusion. A discretionary dependency may exist because subject matter experts learned that a particular sequence reduces rework or defect rates. Treating it as meaningless can create hidden quality costs later. Another misconception is that external dependencies are always mandatory, when some external relationships are actually chosen for convenience or preference.
Overclassifying Discretionary Dependencies as Mandatory
Teams frequently label dependencies mandatory because they have always done the work in that sequence. A reviewer may write that testing cannot begin until all development is complete, when in fact integration testing could begin earlier on stable modules. This overclassification makes schedules rigid and inhibits fast tracking. Experienced planners challenge mandatory labels by asking what would break, physically or legally, if the sequence changed. If the answer is only inconvenience or extra coordination, the dependency is discretionary.
Invisible External Dependencies
External dependencies often hide inside task names or assumptions. A task called "receive approval from legal" may be tracked as internal work, but the wait time is controlled by the legal department. When these dependencies are not classified separately, forecast accuracy suffers. Regular dependency reviews with suppliers, clients, and other projects help surface these relationships. A dependency register or log is often used to keep external obligations visible, along with the responsible owner and escalation path.
Confusing Dependency Types with Relationship Types
A persistent source of confusion is the use of finish-to-start language to describe mandatory dependencies. A finish-to-start relationship can be mandatory or discretionary. Likewise, a start-to-start relationship may be mandatory when two systems must initialize together for testing. The precedence diagramming method answers when, while the dependency type answers why. Mixing these two dimensions can produce a schedule that is mathematically consistent but disconnected from how the work actually happens.
Limitations of Rigid Classification
There are situations where strict classification creates more overhead than value. Very small projects or single-team efforts may not need separate external and internal registers. Overly detailed dependency mapping can consume planning time without improving delivery. The appropriate level of formality depends on project size, regulatory exposure, and the number of external interfaces. In simple projects, a casual note about what must wait on what is often sufficient, but in complex programs the formal categories become essential for control.
Dependencies Types vs Related Project Management Concepts
Dependencies types are closely related to several other planning concepts, but they are not the same as constraints, assumptions, risks, or precedence relationships. Dependencies types vs constraints is a frequent point of confusion because a constraint may force a dependency, yet the two terms operate differently. A constraint is a limiting factor such as a fixed deadline or a limited budget. A dependency is a sequencing relationship between activities. For example, a regulatory approval may be an external dependency, while a contractual completion date is a constraint that surrounds the delivery of the work with the approval.
Dependencies and Assumptions
Many dependencies are recorded as assumptions when their timing is uncertain. A project manager may assume that a vendor delivers hardware by a certain date, creating an external dependency. If the assumption proves false, the dependency becomes a risk trigger. Assumption logs and dependency registers often overlap, but they serve different purposes. The assumption records uncertainty about conditions, while the dependency records a relationship that must be satisfied. One can exist without the other, but most external dependencies carry an underlying assumption about timing or availability.
Dependencies and the Critical Path Method
The critical path method uses activity dependencies and estimated durations to calculate the longest path through a project. The quality of that calculation depends on the accuracy of dependency classification. Mandatory dependencies usually form the non-compressible backbone of the critical path. Discretionary dependencies may be removed to shorten the schedule, and external dependencies may create float or require buffers. This connection is why schedule analysts often ask whether each dependency is hard or soft before accepting a proposed fast tracking plan.
Program and Portfolio Dependencies
Above the project level, dependencies types expand into program and portfolio mapping. A program may have dependencies between component projects, such as a shared platform team delivering an API before several application teams build on it. Portfolio dependencies connect investments that share resources, capabilities, or strategic outcomes. These are often external from the perspective of any single project manager. Managing them requires governance that crosses project boundaries, because the individual project schedule cannot fully control or even see all portfolio-level constraints.
Key Distinctions Among Planning Concepts
- Constraints differ from dependencies
- A constraint is a limiting condition, such as a fixed deadline or budget cap, that can force a dependency. The constraint itself is distinct from the dependency.
- Assumptions overlap with dependency registers
- Assumption logs record conditions accepted as true without proof, while dependency registers identify relationships that require active coordination. An item may appear in both, but each artifact supports a different aspect of planning.
- Dependencies shape scheduling and governance
- Activity-level dependencies drive critical path analysis by defining the longest sequence of work, and dependencies among component projects require governance structures that operate across project boundaries.
Evolution and Current Thinking on Dependencies Types
The concept of dependencies was formalized with the rise of the Critical Path Method and PERT in the 1950s. Early schedulers recognized that activities had logical relationships, but the explicit separation of mandatory, discretionary, external, and internal categories became common through project management standards. Evolution of dependencies types reflects a shift from static schedule logic to dynamic dependency management, especially as organizations adopted iterative delivery, distributed teams, and complex supplier ecosystems. Modern thinking treats dependency types less as a one-time planning exercise and more as an ongoing risk-based conversation.
From Static Network Logic to Continuous Visibility
In traditional predictive projects, dependencies were documented during planning and then revisited only during change control. Today, many teams visualize dependencies on kanban boards, program boards, or dependency maps that are updated weekly. The types have not disappeared, but they are embedded in real-time coordination practices. For example, a team may tag a story as externally blocked rather than simply noting the dependency in a project file. This shift toward visibility reflects the practical reality that dependencies are frequently discovered during execution, not just during upfront planning.
The BVOP Perspective on Planning and Dependencies
Business Value-Oriented Project Management adds a focused note on dependencies in planning. It uses relational effort points and warns that work breakdown structure inaccuracies can distort the dependency map that follows. BVOPM also performs hiring-and-training-based dependency analysis in stakeholder-facing contexts, recognizing that some dependencies are caused by capability gaps rather than activity sequencing alone.
Current Debates and Best Practices
There is a healthy debate about whether discretionary dependencies should be minimized more aggressively in modern delivery. Some Agile practitioners argue that any unnecessary dependency is waste and should be designed out through cross-functional teams and modular architecture. Others caution that removing soft logic without understanding its purpose can increase rework and defect rates. Current best practice therefore combines classification with challenge: each dependency should be visible, owned, justified, and periodically reviewed. Tools such as dependency registers, program boards, and automated traceability help, but the core skill remains judging whether a sequence is truly constrained or merely traditional.
