Mandatory Dependency

Mandatory dependency refers to a relationship between two project activities in which one activity must finish or start before another can proceed because the sequence is dictated by the nature of the work, a legal requirement, or a contractual obligation. In schedule management it is commonly called hard logic or a hard dependency. The defining feature is that the dependency cannot be removed by management preference or team choice. It represents a real constraint that shapes the project schedule at its foundation.

Mandatory Dependency: Key Topics at a Glance

What Is Mandatory Dependency in Project Management?

In formal terms, the mandatory dependency definition used in project management standards describes an inherent, legally required, or contractually mandated sequence between activities. The PMBOK Guide defines mandatory dependencies as those that are legally or contractually required or inherent in the nature of the work. They frequently involve physical limitations that no amount of planning can eliminate.

If a project team is constructing a building, the concrete foundation must be poured and cured before structural steel can be erected. That sequence is not a matter of preference or efficiency. The physical work simply cannot happen in reverse, and no project manager can negotiate with gravity.

Core Meaning and Attributes

A mandatory dependency has several distinguishing attributes. The dependency is objective rather than chosen, it remains valid regardless of who performs the work, and it usually becomes visible through technical analysis or regulatory review. These dependencies also tend to create predictable constraints in the schedule because they define the minimum logical order of execution.

Mandatory dependencies can exist at any level of the project. They may connect two activities inside a work package, two major phases, or two separate projects inside a program. The scale does not change the core nature of the relationship. What changes is how directly the project team can manage the constraint.

How Mandatory Dependencies Differ from Other Dependency Types

Dependencies are generally classified along two dimensions. The first dimension is mandatory versus discretionary. The second is internal versus external. A common mistake is to treat all sequencing decisions as mandatory when many are actually discretionary preferences dressed up as hard logic.

Discretionary dependencies reflect the team's preferred way of working, such as ordering design reviews before procurement or completing documentation in a specific sequence. These can be changed if the situation calls for it. Mandatory dependencies cannot be changed by a simple scheduling decision because they are rooted in physical, legal, or contractual reality.

Types and Key Components of Mandatory Dependencies

The key components of mandatory dependencies include the underlying constraint source, the directional relationship between activities, and the degree to which the dependency is controllable by the project team. Understanding these components helps project managers identify which dependencies genuinely belong in the hard logic category and which are being overstated.

Mandatory dependencies generally arise from three broad sources. Physical constraints represent the first source. Legal and contractual constraints represent the second. External parties and jurisdictional boundaries can create a third source that overlaps with the first two. Each source has a different impact on how the dependency should be managed and documented.

Physical and Technical Constraints

Physical constraints are perhaps the easiest mandatory dependencies to understand. A roof cannot be installed before the supporting walls exist. A software module cannot be integration-tested before the code is written. In manufacturing, a component cannot be assembled into a product before it has been fabricated and inspected.

Technical constraints are the engineering and quality-driven cousins of physical constraints. Some technical sequences are truly mandatory because an earlier activity produces information or a condition that the later activity requires. For example, a test plan may need to be approved before formal testing begins because the approval establishes the acceptance criteria.

Legal, Contractual, and Regulatory Constraints

Legal and regulatory constraints create mandatory dependencies that may not be obvious from the technical work itself. A construction project may need a building permit before site work begins, even if the crew is physically ready. A clinical trial cannot start patient enrollment until ethics approval is granted. These dependencies are hard logic even though they do not arise from the physical nature of the work alone.

Contractual obligations can also establish mandatory dependencies. A supplier contract may require formal acceptance of a design before manufacturing starts. A client agreement may specify that a particular milestone payment must be received before the next work package is authorized. These constraints operate as hard dependencies because the project has legally committed to them.

Internal and External Mandatory Dependencies

Internal mandatory dependencies exist between activities within the same project or team. They are generally easier to predict because the project manager has direct visibility into the work. External mandatory dependencies involve a party outside the project, such as a vendor, regulator, partner organization, or another project. They can still be mandatory, but they are harder to control.

The distinction matters in practice. An internal physical constraint can be managed by adjusting resource levels or sequencing other work around it. An external mandatory dependency may require escalation, contract negotiation, or schedule buffering. The mandatory nature of the dependency does not disappear simply because the project team cannot control the other party.

Mandatory Dependency in PMBOK and Predictive Project Management

The mandatory dependency PMBOK treatment sits within the Schedule Management knowledge area and the Plan Schedule Management and Sequence Activities processes. In predictive project management, mandatory dependencies are documented in the project schedule network diagram and then used to calculate the critical path. They are not optional entries in a schedule model; they represent the non-negotiable skeleton of the plan.

Project managers ordinarily identify mandatory dependencies during the Sequence Activities process. The team reviews the activity list, examines the technical and contractual requirements, and applies the precedence relationships that reflect true hard logic. The output of this work feeds directly into schedule development and the approved baseline.

Sequence Activities and Precedence Diagramming Method

The precedence diagramming method, or PDM, is the standard technique used to model dependencies in a network diagram. PDM supports four relationship types: finish-to-start, start-to-start, finish-to-finish, and start-to-finish. Mandatory dependencies most often appear as finish-to-start relationships, although the other types can also reflect hard logic in specific operational contexts.

For example, a start-to-start mandatory dependency might exist when two pieces of equipment must be powered on together from the beginning of a test. A finish-to-finish dependency might apply when a security review cannot close until the final code freeze is complete. The relationship type describes the logical coupling; the mandatory nature describes whether the coupling can be altered.

Project Schedule Network Diagram and Critical Path

Once mandatory dependencies are entered into the schedule model, they directly influence the critical path. The critical path is the longest sequence of dependent activities through the project, and any mandatory dependency on that path creates a hard constraint that affects the overall finish date. If the dependency is modeled incorrectly, the entire schedule becomes unreliable.

Project managers often find that mandatory dependencies create zero or negative float on certain paths. This is expected when the logical order of work is fixed. The schedule then reveals where schedule compression may or may not be possible. If the activity is on the critical path and the dependency is truly mandatory, fast tracking may not be an option because the sequential nature of the work cannot be compressed.

Schedule Baseline and Change Control

Mandatory dependencies influence the schedule baseline and the change control process. A request to remove or alter a mandatory dependency should be treated with caution. If the dependency was genuinely mandatory, removing it from the schedule does not remove it from reality. The work will still hit the physical or contractual constraint, but the schedule will no longer warn the team in advance.

Change requests involving mandatory dependencies usually require technical or legal justification. The project manager must verify that the underlying constraint has changed. For example, a new construction method may genuinely remove a physical constraint, or a contract amendment may relax a sequencing requirement. Without that evidence, the dependency remains mandatory.

Core Takeaways on Mandatory Schedule Dependencies

PMBOK Process Placement

Mandatory dependency management falls within PMBOK's Schedule Management knowledge area and is primarily addressed during the Plan Schedule Management and Sequence Activities processes.

Non-Negotiable Schedule Skeleton

In predictive project management, these dependencies form the non-negotiable structural core of the schedule and are identified through a deliberate review of the activity list, technical specifications, and contractual obligations.

PDM and Relationship Types

The precedence diagramming method serves as the standard technique for modeling mandatory dependencies in the schedule network diagram, and these dependencies most often appear as finish-to-start relationships, although other relationship types can also represent hard logic.

Critical Path Hard Constraint

When a mandatory dependency lies on the critical path, it becomes a hard constraint that directly influences the project's overall finish date.

Mandatory Dependency in PRINCE2 and Other Frameworks

The mandatory dependency in PRINCE2 environment is handled through the Plans theme and product-based planning rather than through a separate dependency classification system. PRINCE2 focuses on products, their quality criteria, and the sequence in which those products must be created. Many product dependencies are mandatory because a later product requires the completed earlier product as an input.

PRINCE2 does not use the phrase mandatory dependency as prominently as the PMBOK Guide, but the underlying idea is present. In product-based planning, the product flow diagram shows the order in which products must be developed. Some of those arrows reflect preference, while others reflect physical or contractual necessity. Experienced PRINCE2 practitioners distinguish between the two because the hard ones constrain the plan far more seriously.

Product-Based Planning and Dependencies

In product-based planning, the project team creates a product breakdown structure and then a product flow diagram. The flow diagram identifies which products are needed before others can be produced. A mandatory dependency appears when a downstream product cannot exist without the upstream product being complete and approved.

For example, a detailed design document must be approved before the corresponding build phase can start if the governance rules require that approval. This is a mandatory dependency created by quality requirements and project controls. The product flow diagram makes the constraint visible, but it does not by itself resolve the schedule impact.

Program and Portfolio Dependency Mapping

At the program and portfolio level, mandatory dependencies often cross project boundaries. A program may depend on one project delivering a shared platform before another project can integrate with it. A portfolio may have a regulatory milestone that several projects must collectively satisfy. These dependencies are frequently mandatory and require active management at a higher governance level.

Program managers use dependency maps, integrated roadmaps, and gate reviews to track such constraints. The challenge is that a mandatory dependency between projects may be clear to the program manager but invisible to the individual project teams. This visibility gap is a recurring source of schedule surprises in complex organizations.

Mandatory Dependency in Agile and Hybrid Environments

The mandatory dependency in Agile context is often less formalized than in predictive project management, but it is just as real. Agile teams still face technical and regulatory constraints that force a specific order of work. A user story cannot be tested before the code exists. A release cannot be deployed before the required security review passes.

Agile frameworks typically do not use activity network diagrams or critical path analysis as central planning tools. Instead, the team surfaces mandatory dependencies through backlog refinement, sprint planning, and continuous collaboration. The dependency still constrains the work, but the management approach is more conversational and iterative.

Technical Dependencies in Iterative Delivery

Technical mandatory dependencies inside an iterative delivery model usually appear as order constraints within a backlog. A story that depends on a database change may need to wait until that change is complete. A feature that consumes an API cannot be fully built until the API contract is stable or the endpoint is available.

Agile teams often try to break work into slices that reduce dependency exposure. They may build a mock or a stub to allow parallel progress. But this does not remove the underlying mandatory dependency entirely. The stub only defers the real integration point. Eventually the team must connect the work to the actual dependency and verify that the sequence holds.

Managing Mandatory Dependencies Across Teams and Iterations

When mandatory dependencies span multiple teams, Agile environments rely on coordination mechanisms such as Scrum of Scrums, dependency boards, and release train planning. The goal is to make the hard constraints visible early enough to sequence work without last-minute conflict. Teams that ignore cross-team mandatory dependencies often discover them during integration, when the cost of rework is highest.

Hybrid environments combine the structured dependency analysis of predictive planning with Agile delivery cadences. High-level mandatory dependencies may be mapped in a milestone plan, while detailed execution happens in sprints. The mandatory constraints remain fixed, but the work around them is allowed to flex within the boundaries of the release plan.

Key Takeaways on Agile Mandatory Dependency

Real Constraints Without Formal Diagrams

Agile teams routinely encounter technical and regulatory constraints that impose a fixed sequence of work, even though these mandatory dependencies rarely appear in formal dependency diagrams.

Order Constraints Inside the Backlog

Within iterative delivery, mandatory technical dependencies typically surface as backlog ordering constraints, such as a feature that cannot be fully developed until the relevant API contract is stable or an endpoint is available.

Testing Requires Completed Code

Agile teams still follow fundamental sequencing rules because a user story cannot be tested before the code exists and a release cannot be deployed until the required security review has passed.

Dependencies Surfaced Through Collaboration

Rather than depending on activity network diagrams or critical path analysis, Agile teams surface mandatory dependencies through backlog refinement, sprint planning, and continuous collaboration.

Coordination Across Multiple Teams

When mandatory dependencies span multiple teams, Agile organizations rely on mechanisms such as Scrum of Scrums, dependency boards, and release train planning to keep interrelated work sequences aligned.

Purpose and Importance of Identifying Mandatory Dependencies

The purpose and importance of mandatory dependencies lies in their effect on schedule realism, risk visibility, and stakeholder confidence. A schedule that omits a mandatory dependency will look optimistic until the project collides with reality. The resulting delay is often more damaging than the original constraint because it arrives as a surprise.

Identifying mandatory dependencies early gives the project team an honest picture of what can and cannot be accelerated. It also helps the sponsor and other stakeholders understand why certain work must follow a fixed sequence. That understanding reduces pressure to make impossible schedule commitments.

Schedule Integrity and Realistic Baselines

Schedule integrity depends on the accuracy of the dependencies used in the schedule model. Mandatory dependencies are the load-bearing walls of that model. If they are missing, the schedule is structurally unsound. If they are modeled as discretionary, the critical path may appear to have more flexibility than it actually has.

A realistic baseline incorporates the true physical, legal, and contractual sequences. It does not show artificial parallelism where the work cannot actually run in parallel. This realism may make the baseline longer, but it also makes it more defensible and more useful for decision-making.

Risk and Constraint Visibility

Mandatory dependencies frequently act as risk triggers. A regulatory approval that must occur before a major phase creates schedule risk if the approval timeline is uncertain. A vendor dependency that is mandatory exposes the project to external performance risk. By identifying these dependencies, the project manager can plan risk responses, buffers, or alternative strategies.

Constraint visibility also supports better escalation. When stakeholders demand an earlier finish date, the project manager can point to the mandatory dependencies that limit compression. This does not end the conversation, but it changes it from an argument about effort to a discussion about the actual sequence of work.

Practical Applications and Common Scenarios

Realistic mandatory dependency examples appear in nearly every industry, although the form varies considerably. Construction, engineering, software development, regulatory projects, and organizational change initiatives all have hard sequences that cannot be reversed. The common thread is that the work itself or the rules surrounding the work dictate the order.

Recognizing these patterns in real project work helps project managers avoid the trap of treating every dependency as a preference. It also provides a practical vocabulary for discussing constraints with technical experts, legal advisors, and procurement teams.

Construction, Engineering, and Infrastructure Projects

Construction projects are often the clearest illustration of mandatory dependencies. Excavation must precede foundation work. Concrete must cure before load can be applied. Electrical wiring must be in place before walls are closed and finished. Each step creates a hard condition for the next step.

Infrastructure projects add regulatory and environmental layers to the physical constraints. A road project may require utility relocations before main construction can start. An environmental permit may be mandatory before any earthmoving activity. These dependencies are not choices; they are prerequisites established by safety, legal, and engineering standards.

Software Development, Product Releases, and Organizational Change

Software development contains its own set of mandatory dependencies. Code must be committed before a build can be created. The build must succeed before automated tests can run. A production release may require a database migration to finish before the new application version goes live. These sequences are technically unavoidable.

Organizational change projects also have hard dependencies. A payroll system cannot be cut over before employee data is migrated and validated. A new process cannot be enforced before the supporting policy is approved. The mandatory nature of these dependencies often becomes visible only when the change team maps the end-to-end flow across business units.

Common Challenges, Pitfalls, and Misconceptions

Several common misconceptions about mandatory dependencies create problems in real project environments. The first misconception is that any dependency preferred by a technical expert is automatically mandatory. The second is that mandatory dependencies are always obvious. The third is that hard logic cannot be challenged or restructured.

These misconceptions lead to over-constrained schedules, missed opportunities for parallel work, and a defensive planning culture. Project managers who treat every claimed hard dependency as sacred may preserve unnecessary sequence constraints long after the underlying reason has disappeared.

Confusing Mandatory with Discretionary Dependencies

One of the most frequent mistakes is inflating discretionary dependencies into mandatory ones. A team may insist that testing must wait until all documentation is complete because that was the historical practice. In reality, the documentation may be a preference, not a physical or contractual prerequisite. Labeling it mandatory removes flexibility without adding any real protection.

Conversely, a genuine mandatory dependency may be treated as discretionary because the team wants to appear responsive to schedule pressure. This is more dangerous. Removing hard logic from the schedule model does not remove it from the physical world. The project will simply discover the constraint later, usually at higher cost.

Overlooking Hidden Mandatory Dependencies

Not all mandatory dependencies are immediately visible. They may be buried in regulatory text, procurement terms, technical specifications, or organizational policies. A project may plan to start system integration before realizing that a security accreditation must be completed first. The accreditation was mandatory all along, but no one identified it during planning.

Hidden mandatory dependencies often surface during walkthroughs with specialists, legal reviews, or supplier discussions. The lesson is that dependency identification cannot rely on the project manager's assumptions alone. It requires input from people who understand the technical, contractual, and regulatory environment in detail.

Misusing Mandatory Dependencies as Excuses

Mandatory dependencies can become a convenient shield against difficult conversations. A team that does not want to attempt aggressive schedule compression may claim that every constraint is hard logic. A sponsor may use a supposed mandatory dependency to reject a competing initiative. While some constraints are indeed hard, the label should be backed by evidence.

When a mandatory dependency is invoked, the appropriate response is to ask what makes it mandatory. Is it a physical requirement, a legal restriction, or a contractual term? If the answer is vague or points to history or preference, the dependency may not be mandatory at all. This verification step is part of healthy schedule governance.

Relationship to Other Project Management Concepts

The relationship between mandatory dependencies and critical path analysis is particularly direct. Mandatory dependencies create the fixed sequencing upon which the critical path depends. Without an accurate model of hard logic, the critical path becomes a mathematical fiction disconnected from how the work must actually be performed.

Mandatory dependencies also connect to leads, lags, constraints, assumptions, risk registers, and stakeholder communication. They do not exist in isolation. A mandatory dependency may carry a lag while concrete cures. It may be documented as an assumption when the exact regulatory timeline is uncertain. It may appear in a risk register as a source of schedule risk.

Leads, Lags, Constraints, and Assumptions

Leads and lags modify dependency relationships without changing their mandatory nature. A finish-to-start mandatory dependency may include a lag for a required waiting period, such as paint drying or regulatory review time. The lag is part of the constraint, not an optional buffer. If the lag is contractual or physical, it is just as hard as the dependency itself.

Constraints and assumptions interact with mandatory dependencies during schedule development. A fixed start date may be a constraint created by an external dependency. An assumption about vendor delivery may need to be validated to confirm whether the dependency is truly mandatory. The schedule model is only as reliable as these supporting details.

Float, Critical Path, and Schedule Compression

Float represents the amount of time an activity can slip without delaying the project. Mandatory dependencies on the critical path typically have zero float because the sequence cannot be rearranged. Activities with discretionary dependencies may have more float and can be resequenced to relieve pressure.

Schedule compression techniques interact differently with mandatory dependencies. Crashing, which adds resources, may shorten the duration of an activity even when the dependency remains. Fast tracking, which overlaps activities, may be impossible for a truly mandatory finish-to-start relationship. The project manager must understand the nature of the dependency before recommending a compression approach.

Stakeholder Communication and Governance

Mandatory dependencies are a common topic in stakeholder communication because they directly affect expectations about dates and sequencing. Governance boards frequently ask why work cannot be accelerated. The project manager must explain the hard constraints in terms the stakeholders can accept. A clear dependency map or schedule fragment often communicates this more effectively than abstract explanation.

Business Value-Oriented Project Management adds a further dependency consideration by treating hiring and training pipelines as potential sources of mandatory constraints. When a specialized skill is unavailable, the dependency is not discretionary and must be reflected in the plan. Brief planning documents that all stakeholders can read help surface these constraints before they become invisible delays.

Evolution and Current Thinking in Mandatory Dependency Management

The way practitioners understand and manage mandatory dependencies has evolved from static schedule logic toward broader systems thinking. Early project scheduling tools focused on activity sequencing in a single project. Modern project management recognizes that hard dependencies also exist across projects, programs, contracts, and supply chains.

A useful way to approach the subject is through a full mandatory dependency explained lens, which places the concept inside a larger conversation about constraint management. The dependency itself is not the problem. The problem arises when the dependency is ignored, misclassified, or communicated too late. Current thinking emphasizes early validation and continuous review.

From Static Hard Logic to Systems Thinking

Traditional critical path method treated mandatory dependencies as fixed inputs to a schedule calculation. The focus was on modeling the sequence and determining the minimum project duration. That approach remains valid, but it has been supplemented by systems thinking. A mandatory dependency is now understood as a signal about the environment in which the project operates.

For example, a regulatory dependency is not just a line on a network diagram. It is a relationship between the project, the regulator, the legal environment, and the organization's risk appetite. Managing that dependency may require communication, negotiation, contingency planning, or redesign of the work approach. The schedule model captures the constraint, but it cannot by itself resolve the underlying system interaction.

Current Debates and Best Practices

Current best practice emphasizes the verification of mandatory dependencies rather than their passive acceptance. Project teams are encouraged to document why a dependency is mandatory and to revisit that justification when circumstances change. A dependency that was mandatory under one technical approach may disappear if the approach is changed.

There is also a healthy debate about how much hard logic should be built into early schedules. Some argue that too many mandatory dependencies make plans brittle and discourage creative delivery strategies. Others respond that removing hard logic creates unrealistic optimism. The balanced position is that mandatory dependencies should be modeled accurately, challenged appropriately, and communicated clearly.