What are the three types of activity dependencies?

Project schedules rarely behave like simple to-do lists. A schedule is a network of commitments, constraints, and handoffs, and the connective tissue holding that network together is the dependency relationship between activities. The three types of activity dependencies are mandatory dependencies, discretionary dependencies, and external dependencies. Each type answers a different question about why one activity must or should come before another. Without sorting these out early, project managers tend to build schedules that look logical on screen but fall apart when real work begins.

These dependency categories show up during the planning process, specifically in the sequence activities process. The project team examines the defined activities and determines which ones have to happen first, which ones could be reordered, and which ones depend on forces outside the project. That distinction matters because it changes how much control the team has over the schedule. A mandatory dependency cannot be outsmarted by a clever planner. A discretionary dependency, by contrast, is a choice, and choices can be revisited. An external dependency is a reminder that not every schedule variable belongs to the project manager.

Project managers usually encounter these concepts while building a project schedule network diagram. The idea is simple enough at a high level, but the practical consequences become clear only when a team sees what happens to a schedule when a hard constraint is ignored or a soft preference is mistaken for an unchangeable rule. The three types have different implications for risk, float, and schedule compression. That is why experienced planners spend considerable time classifying each relationship rather than just drawing arrows between boxes.

Summary of the Three Types of Activity Dependencies

Key Concept	Summary
Activity Dependencies	Project activities are interdependent; effective scheduling requires mapping each activity's relationships to predecessors, successors, and concurrent work.
Finish-to-Start Links	Finish-to-start dependencies may arise from legal mandates, team-defined sequencing preferences, or external control over a required input.
Hard Constraints	Hard logic represents physical limitations, legal obligations, or technical constraints that cannot be resolved without altering the project scope, method, or sequencing approach.
Soft Preferences	Soft preferences reflect team choices or conventions rather than mandatory constraints; they must be distinguished from hard logic to keep the schedule realistic and flexible.
Sequence Activities	Sequence Activities is performed after activity definition and before duration estimation and schedule development in predictive project life cycles.
Activity Attributes	The project team reviews activity attributes and the milestone list to evaluate each potential predecessor and successor pair for logical validity.
Early Visibility	Early visibility into activity sequencing helps prevent a common planning failure in which the activity list is either too granular or too vague to support meaningful dependency mapping.
Hard Logic Chain	An extended chain of hard logic activities establishes a minimum possible duration for the project unless the delivery approach or technical method is changed.

Understanding Activity Dependencies in Project Schedule Management

At the heart of schedule development lies a simple observation: project activities do not happen in isolation. In project management, activity dependency types define the logical relationships between a predecessor and a successor. These relationships dictate the sequence of work and the constrained paths through the schedule network. Project managers who treat every activity as independent are essentially ignoring the physical, contractual, and organizational reality of the work.

In PMBOK terminology, dependency identification belongs to project schedule management and specifically to the sequence activities process of the planning process group. The main output of that process is a schedule network diagram, which shows the logical order in which project activities will be performed. Precedence relationships such as finish-to-start, start-to-start, finish-to-finish, and start-to-finish provide the mechanics, but the dependency type explains the reason behind the relationship. A finish-to-start link may exist because it is legally required, because the team prefers it, or because an outside party controls an input.

This process follows activity definition and logically precedes schedule development and duration estimation in most predictive project life cycles. In practice, though, teams often start identifying dependencies earlier, during scope definition or even while building the work breakdown structure. That early visibility helps avoid a common failure mode where the activity list is too granular or too vague to sequence meaningfully. Sequencing is not an afterthought. It is the point where the plan starts to become a schedule rather than a list of intentions.

Where the Three Types of Activity Dependencies Fit in the Planning Process

The three types of activity dependencies are not just labels for arrows in a diagram. They serve as a classification scheme that guides later decisions about schedule compression, risk management, and what-if analysis. During sequence activities, the team reviews the activity attributes and milestone list, then examines each potential predecessor-successor pair. Because each pair can have multiple dependency attributes, a relationship may be both mandatory and external, or discretionary and internal. The three types described here are not mutually exclusive in every scenario, but they represent distinct decision categories that planners need to consider separately.

One practical way to think about this is to ask three sequential questions for every relationship. Is this sequence physically or contractually unavoidable? Is this sequence a preference based on best practice? Is this sequence driven by an entity outside the project boundary? The answer determines how much freedom the team has to adjust the schedule later. A relationship that is mandatory will constrain the critical path in a fixed way. A discretionary relationship may create artificial constraints that can be removed. An external relationship introduces uncertainty that often requires buffer or contingency.

Core Insights on Activity Dependencies

Dependencies define work sequence

Activity dependency types establish the logical relationships between predecessor and successor activities, determining the order in which work can proceed and exposing the constrained paths that shape the overall schedule network.

Part of sequence activities process

Identifying dependencies is a core step in the Sequence Activities process within Project Schedule Management, where the project team produces a schedule network diagram that maps the logical flow and interdependencies among all project activities.

Identify dependencies early for quality

Experienced teams begin identifying dependencies as early as scope definition or work breakdown structure creation, ensuring the activity list remains sufficiently detailed and appropriately scoped to support meaningful sequencing.

Mandatory Dependencies: Hard Logic in Activity Sequencing

Mandatory dependencies are the least forgiving type of activity relationship. They are either contractually required or inherent in the nature of the work. The project team determines which dependencies are mandatory during the process of sequencing the activities. That determination is not an arbitrary judgment; it reflects physical limitations, legal obligations, or technical constraints that cannot be avoided without changing the scope or approach.

Construction projects provide the clearest example. It is impossible to erect the superstructure until after the foundation has been built. That is not a preference. The laws of physics and structural safety make the dependency mandatory. In an electronics project, a prototype must be built before it can be tested. You cannot validate performance on a device that does not yet exist. These relationships are sometimes called hard logic, and the name fits. Hard logic does not bend based on resource availability, stakeholder preference, or schedule pressure.

Because mandatory dependencies cannot be eliminated, they create fixed constraints in the schedule network. If a project has a long chain of hard logic activities, that chain will act as a lower bound on the overall duration unless the approach changes. For example, if a regulatory review cannot begin until a submission is complete, and the submission cannot be finalized until testing is done, the sequence is locked. Planners cannot shorten that path by resequencing. They have to change the method, add resources in a way that actually accelerates the predecessor, or accept the timeline.

One common mistake is treating mandatory dependencies too broadly. A team may label a sequence as hard logic because it reflects how the organization has always done the work. But if another acceptable technical sequence exists, the dependency may actually be discretionary. Disciplined planners test mandatory relationships by asking whether the successor activity is truly impossible without the predecessor. If the answer is no, the relationship deserves closer scrutiny. Overusing the hard logic label is a quiet killer of schedule flexibility.

Discretionary Dependencies: Preferred Logic and Scheduling Flexibility

Discretionary dependencies are the opposite of hard logic in one important respect. They exist because the project team chooses a particular sequence, not because the work is impossible any other way. The team determines which dependencies are discretionary during the sequencing process. They are sometimes called preferred logic, preferential logic, or soft logic. The choice is often based on knowledge of best practices within a particular application area or on a desire for a specific sequence even though other acceptable sequences exist.

A software team might decide to complete database design before user interface design because that order reduces rework. Another team might sequence testing after development in a traditional phase gate, even though some testing could technically overlap. In a construction fit-out, the team might prefer to run electrical wiring before drywall installation, even though some wallboards could be installed first and cut later. These are sensible choices, but they are still choices. They are not dictated by physics or contract.

Discretionary dependencies should be fully documented because they can create arbitrary total float values and limit later scheduling options. When a planner inserts a soft logic preference into the schedule, the tool will calculate float as if the constraint were real. That can make a non-critical path look artificially tight or a critical path look longer than it actually is. The documented rationale helps the team remember which relationships are flexible and which are not. Without that record, a discretionary dependency may harden over time simply because everyone gets used to seeing it in the schedule.

This is where schedule compression techniques become relevant. When fast tracking techniques are employed, these soft logic dependencies should be reviewed and considered for modification or removal. Fast tracking involves overlapping activities that would normally be done in sequence. If the sequence is discretionary, the team has room to overlap. If the sequence is mandatory, fast tracking may not be possible at all. Documenting discretionary dependencies therefore creates a menu of schedule compression opportunities that can be used when the timeline becomes a problem.

Documenting Discretionary Dependencies to Protect Schedule Flexibility

The practical challenge with discretionary dependencies is not identification. Project teams are usually aware that alternative sequences exist. The challenge is maintaining that awareness over the life of the project. A scheduling tool may show a dependency arrow, but it does not reveal whether the arrow reflects hard logic or preference. That is why many project managers keep a dependency log or add activity attributes that record the rationale for each relationship. The log might say, "Painting after electrical is preferred to avoid dust contamination, but painting could start earlier if required." That note becomes valuable when the sponsor asks for a two-week schedule reduction.

Another subtle issue is that discretionary dependencies can be influenced by resource leveling. A team may sequence work based on the order in which a specialist is available. That sequence is not inherent to the work, but it may feel unchangeable because of staffing constraints. It is still discretionary from a logical standpoint, even though the resource constraint is real. Distinguishing between logical discretion and resource-driven constraints helps the team avoid false assumptions about what can be changed.

Core Takeaways on Soft Logic

Choice-based sequencing rationale

Discretionary dependencies capture a team's preferred execution order, driven by best practices or a deliberate effort to reduce rework, rather than by any technical constraint that makes another sequence impossible.

Practical examples of soft logic

Software teams often schedule database design ahead of user interface design to limit rework, while construction teams typically run electrical wiring before hanging drywall, even when reversing the order remains technically possible.

Documentation is critical

Because these discretionary dependencies create arbitrary total float values and can reduce later scheduling flexibility, they should be documented as soon as they are introduced.

Artificial float calculations

When soft logic is encoded in scheduling software, the tool treats the preferred sequence as a mandatory constraint and calculates float accordingly, which can make non-critical paths appear artificially tight or overstate the length of critical paths.

Risk of hardening over time

Without clear documentation, a discretionary dependency can harden into assumed hard logic over time, purely because stakeholders become accustomed to seeing that sequence repeated in the schedule.

External Dependencies: Interface with Non-Project Activities

External dependencies involve a relationship between project activities and non-project activities. The project management team identifies these during the sequencing process. They are usually outside the project team's control, which makes them a primary source of schedule risk. The project can manage its own work perfectly and still be delayed by a vendor, regulator, customer, or another program that operates on a different timeline.

A typical external dependency appears when a project cannot begin system integration until a third-party hardware component is delivered. Another example is waiting for a government permit before construction can start on a site. The project team may have submitted the permit application on time, but the approval date belongs to the permitting agency. In product development, testing might depend on a customer providing test data or feedback. In each case, the project has an activity that cannot proceed until an outside party completes an activity that is not managed by the project.

The key distinction is control. The project team can communicate, escalate, monitor, and plan around an external dependency, but it cannot directly manage the non-project activity. That lack of control changes the nature of schedule risk management. A project manager may add buffer to absorb the variability. Monitoring becomes more important because early warning signs from the outside party may be the only actionable information. Contractual dependencies also fall into this category when a supplier's delivery obligation is written into the agreement but the delivery itself is not executed by the project team.

External dependencies are not always obvious during initial planning. They often emerge later, when a team realizes that a needed input is produced by an entity outside the project boundary. For that reason, stakeholder identification and interface analysis are closely connected to dependency identification. A project that overlooks an external dependency may build an optimistic schedule that collapses the first time an external party misses a date.

How Each Dependency Type Influences Scheduling Decisions

The practical impact of the three types becomes visible in schedule network analysis. Dependency-driven schedule decisions determine which paths become critical, where float appears, and how much control the project manager has over the sequence. A mandatory chain creates a fixed logical duration that cannot be compressed by resequencing. A discretionary chain can be reordered to shorten the path, though sometimes at the cost of added risk or rework. An external dependency injects a wait state that may not appear as a long duration but can create unpredictable delays.

Consider a simplified project with five activities. If three of them are linked by mandatory dependencies, those three form a locked path. If two other activities are discretionary, the team can choose to run them in parallel or in sequence based on resource availability and risk appetite. The scheduler may initially show a discretionary sequence as the critical path, but after removing that soft logic, the path shortens and the true mandatory path emerges as the real constraint. This kind of what-if analysis is one of the most valuable uses of the dependency classification.

Float distribution highlights the difference. Mandatory dependencies tend to create structural float that reflects the true flexibility of the project. Discretionary dependencies can create arbitrary total float values, as noted earlier, because the scheduling tool treats the preferred sequence as fixed even though it is not. When a team sees an unusually small amount of float on a path that seems logically flexible, the first place to look is often a hidden discretionary dependency. Removing or modifying that soft logic can reveal additional float and reduce apparent schedule pressure.

Comparing the Three Types of Activity Dependencies for Schedule Control

A useful comparison emerges when a project manager asks how much schedule control the team has over each type. The three types of activity dependencies map roughly onto three levels of control. Mandatory dependencies are controlled by the nature of the work or the contract. Discretionary dependencies are controlled by the project team. External dependencies are controlled by outside parties. That simple mapping drives decisions about risk response. The team can own and modify discretionary logic, must plan around mandatory logic, and must monitor and influence external logic without pretending to manage it directly.

This comparison also explains why dependency classification should not be a one-time exercise. Early in planning, some relationships may be labeled discretionary because the team believes another sequence is acceptable. Later, after detailed design or procurement, that sequence may become mandatory due to a newly signed contract or a discovered technical constraint. Reclassifying dependencies as the project evolves is a normal part of progressive elaboration. A schedule that was flexible in the planning phase may harden in ways that require explicit trade-offs later.

Key Insights on Dependency Scheduling

Mandatory chains fix critical duration

A mandatory dependency fixes the logical sequence between activities, which makes the overall duration path irreducible and therefore defines the true critical path; any remaining float is structural and represents genuine scheduling flexibility.

Discretionary logic distorts float values

Discretionary dependencies let teams choose between parallel and sequential execution based on resource availability and risk tolerance, but because scheduling tools treat that chosen order as fixed, they can generate artificial total float and a misleading critical path until the soft logic is removed.

External waits create surprise delays

An external dependency introduces a waiting period that often appears as negligible duration on the schedule, yet it can produce unpredictable delays; project managers should therefore treat that uncertainty as a real constraint on the timeline.

Common Pitfalls and Misconceptions in Dependency Identification

Honestly, this is where schedules get messy. Dependency identification mistakes are common even among experienced planners, mostly because the distinctions feel academic until a schedule problem shows up. The biggest misconception is treating every sequence as mandatory. Teams often say, "That is just how we do it," without examining whether the sequence reflects a physical constraint or an organizational habit. That habit, once embedded in the schedule, looks exactly like hard logic to the scheduling tool and to leadership reviewing the timeline.

A related pitfall is failing to document discretionary dependencies. A planner may know that a sequence is soft logic, but a year later, after team turnover, nobody remembers. The new team treats the arrow as fixed. When the sponsor asks for faster delivery, the team says it cannot be done because the dependency is in the system. The original flexibility has evaporated simply because no one recorded the rationale. This is a documentation failure, not a scheduling failure.

External dependencies create their own pitfalls. Teams often identify them late, after the schedule baseline has been approved. Then the team must either absorb the delay or request a baseline change. Another mistake is assuming that an external dependency will behave like an internal one, with predictable durations and reliable handoffs. External parties may have different priorities, different fiscal calendars, or different definitions of done. The project manager cannot just put a date on the schedule and expect the outside party to honor it without a formal agreement and active monitoring.

There is also a misconception that discretionary dependencies are always weak and should be removed whenever schedule pressure appears. That is not true. Some soft logic preferences exist to reduce rework, improve quality, or manage risk. Removing a discretionary dependency may shorten the schedule but introduce technical debt or create a cascade of defects downstream. The classification is not a recommendation to remove soft logic. It is a reminder to evaluate the trade-off deliberately.

Applying the Three Types of Activity Dependencies in Different Project Environments

The relative importance of each type varies across project delivery environments. In construction and heavy engineering, mandatory dependencies dominate because physical work sequences are rigid. You cannot pour concrete on an upper floor until the lower floor is cured. Discretionary dependencies exist but often involve trade logistics or crew sequencing. External dependencies frequently involve inspections, permits, and material deliveries. Schedule risk in these environments is heavily shaped by hard logic and external approvals.

In software and product development, mandatory dependencies are fewer but still present. A team cannot release code that has not been built, and cannot run automated acceptance tests before the build compiles successfully. Discretionary dependencies are abundant because many development tasks can be reordered. External dependencies often involve third-party APIs, cloud provider changes, or customer inputs. Agile teams tend to treat these as blockers or external wait states rather than formal schedule arrows, but the underlying dependency concept remains the same.

Pharmaceutical and regulated industries add another layer. Regulatory submissions, clinical trial milestones, and quality release steps create long chains of mandatory and external dependencies. The project cannot compress those chains easily because the regulation dictates the sequence. Discretionary logic still exists in areas such as document preparation or site activation order, but the dominant scheduling constraint often comes from hard logic and external agency review timelines.

Applying the Three Types of Activity Dependencies in Agile and Hybrid Projects

Agile teams sometimes resist formal dependency terminology, but the three types of activity dependencies still show up in the backlog and on the team board. A story may be blocked because another team must deliver an API endpoint, which is an external dependency. A team may prefer to complete database migration before frontend work, which is a discretionary dependency. A release may require a security scan before deployment, which is often mandatory because of policy. Agile frameworks do not eliminate dependencies; they make them more visible and shorten the feedback loop for resolving them.

In hybrid projects, dependency management becomes a bridge between predictive scheduling and iterative delivery. The project manager may maintain a high-level schedule network with hard and external dependencies, while the delivery team manages discretionary sequencing within iterations. This split works well when the team respects the classification. Problems arise when the high-level schedule assumes a mandatory sequence that the agile team believes is discretionary, or when an external dependency is hidden inside a team-level story and not escalated until it becomes urgent.

Dependency Takeaways Across Environments

Mandatory logic dominates construction

Physical work sequences in construction and heavy engineering impose a fixed order of operations, so mandatory dependencies dominate the schedule and leave little room for resequencing.

External dependencies shape construction schedules

Construction schedules are heavily influenced by inspections, permits, and material deliveries that sit outside the project team's direct control, making external dependencies a recurring source of timeline variability.

Agile teams reframe dependencies as blockers

Agile teams typically manage mandatory and external dependencies as blockers or waiting states in the backlog rather than as formal schedule logic, yet the underlying sequence constraints still govern delivery.

Regulatory chains drive life sciences

In life sciences, regulatory submissions, clinical trial milestones, and quality release steps create long chains of mandatory and external dependencies, and agency review timelines largely dictate the schedule regardless of internal plans.

Misaligned dependency assumptions cause friction

Friction in agile and hybrid projects arises when a dependency is scheduled as mandatory but the team treats it as discretionary, or when an external dependency remains buried in a story and is not escalated until it becomes urgent.

Practical Techniques for Documenting and Managing Dependencies

Effective dependency documentation practices turn the classification from a theoretical concept into a working tool. The first step is to record the dependency type and rationale in the activity attributes. Many project management software applications include fields for dependency type, but teams often leave them blank. Filling in those fields takes minutes per activity and pays off whenever someone asks why the schedule looks the way it does. A note like "Contract requires vendor acceptance before final payment" is far more useful than an unexplained arrow.

Beyond the scheduling tool, a dependency register or log can capture relationships that span multiple projects or involve external parties. The log might include the dependent activity, the outside party, the expected date, the escalation path, and the current status. This log becomes a monitoring artifact and a communication tool for steering committee updates. When an external dependency is at risk, the log provides a structured way to report it without scrambling for information.

In some organizations, dependency management is folded into a broader integrated master schedule or a program-level dependency matrix. This is common when multiple projects share resources or when a program delivers components that must integrate. The three types still apply, but the classification must be visible to all project managers involved. Without shared definitions, one project may treat a relationship as mandatory while another treats it as discretionary, leading to conflicting assumptions about what can be accelerated.

Business Value-Oriented Project Management also places dependency analysis under hiring and training constraints, noting that team capability availability can determine whether certain project activities are feasible in a given sequence. A project may want to execute two workstreams in parallel, but if the only qualified specialist is fully allocated, the parallel sequence may be unrealistic. That dependency is not always shown in a traditional network diagram, yet it functions as a practical constraint on sequencing, especially in organizations with scarce expertise.

Recording the Three Types of Activity Dependencies in Project Documents

The three types of activity dependencies should appear in more than just the schedule file. The project management plan can include a brief section on dependency assumptions, particularly for discretionary logic. The risk register may list high-impact external dependencies as specific risks with triggers and response plans. The assumption log can capture the belief that an external party will deliver by a certain date. This integration prevents dependency information from living only in the mind of the scheduler.

When a baseline change occurs, the documentation trail becomes evidence. If a team removes a discretionary dependency during fast tracking, the change should be recorded with the rationale and the expected impact on risk. If an external dependency shifts, the log should reflect the new date and the effect on downstream activities. These records may seem bureaucratic, but they are what allow a project manager to explain historical schedule changes without reconstructing decisions from memory.

The Role of Dependencies in Fast Tracking and Schedule Compression

Schedule compression usually begins with a close look at fast tracking and schedule compression opportunities. Fast tracking means overlapping activities that would normally be performed in sequence. The first question a planner should ask is whether the dependency between those activities is mandatory or discretionary. If it is discretionary, the overlap may be feasible, though it usually increases risk and may require rework. If it is mandatory, fast tracking may be impossible because the successor truly cannot begin until the predecessor has finished.

This is why the source material emphasizes that discretionary dependencies should be reviewed when fast tracking techniques are employed. The review is not a formality. It is the process of converting soft logic into explicit schedule trade-offs. A team may decide to overlap design and procurement to save three weeks, even though the original sequence was preferred to avoid ordering errors. The team has to accept that some orders may be placed based on incomplete design information. That is a legitimate business decision, but it should be made consciously, not by accident.

External dependencies complicate fast tracking because the project team cannot compress an outside party's activity. If a vendor needs four weeks to deliver a component, the project cannot fast track that vendor's internal work. The project can, however, overlap its own activities with the external wait time. While waiting for the permit, the team might begin preparing training materials or pre-assembling non-restricted components. That kind of selective overlap is often the only compression lever available when external dependencies dominate.

Mandatory dependencies can sometimes be challenged by changing the approach rather than the sequence. If a prototype must be built before testing, the team might use simulation or virtual testing as a partial predecessor evaluation. That does not remove the hard logic, but it may reduce the downstream duration or allow earlier discovery of issues. The dependency type tells the team where schedule fat cannot be cut. The response, if the constraint becomes critical, is to change the scope, method, or acceptance criteria, not simply to redraw the arrow.

In the end, the distinction between mandatory, discretionary, and external dependencies is not merely a classification exercise. It is a decision framework for schedule realism, risk management, and compression. Teams that treat every dependency the same lose the ability to see where flexibility actually exists. Teams that document and honor the three types can explain why a schedule is the way it is, where it can be changed, and where it cannot. That clarity is what separates a schedule that people trust from one they merely admire.

Summary: Dependency Types in Compression

Mandatory versus discretionary dependencies

The first step in a fast tracking analysis is to determine whether each dependency is mandatory or discretionary, because only discretionary relationships create any realistic opening for overlap.

Discretionary dependencies permit overlap

When a dependency is discretionary, overlapping the activities can shorten the timeline, but this approach usually raises integration risk and may require rework if early decisions prove incorrect.

Mandatory dependencies block fast tracking

When a dependency is mandatory, fast tracking is generally not a viable option, because the successor activity cannot begin until the predecessor has completed its required output.

Soft logic becomes explicit trade-offs

Fast tracking converts discretionary soft logic into deliberate schedule trade-offs. For example, overlapping design and procurement may recover three weeks, but it can also increase the chance of ordering errors that the original sequence was intended to prevent.

External dependencies complicate compression

External dependencies limit schedule compression because the project team cannot accelerate the external party's work. The team can still use the waiting period to prepare training materials or pre-assemble components that are not constrained by the external dependency.