Dependencies and Network Planning

Introduction

Project schedules are not merely lists of activities with dates. They are logical models of how work must unfold. A software team may be able to begin interface design before all database work is complete, but it cannot usually deploy a system before the required code has been built, tested, approved, and packaged. These relationships between activities are dependencies. Representing them clearly is the foundation of reliable network planning.

Dependency analysis helps a project manager answer practical questions: Which activities must occur first? Which activities may proceed in parallel? Which relationships are imposed by technology, policy, or contracts? Where can work overlap safely? What happens if an external supplier is late? A poorly sequenced schedule can create rework, idle resources, missed milestones, and false confidence in the planned completion date.

This chapter explains the principal types of dependencies, introduces precedence network diagrams, applies leads and lags, and presents methods for validating activity sequencing. The focus is on software projects, although the principles apply to most project environments.

Learning Objectives

By the end of this chapter, you should be able to:

• distinguish mandatory, discretionary, internal, and external dependencies;
• explain the four standard logical relationship types;
• construct and interpret a precedence network;
• apply leads and lags without creating unsafe or illogical schedules;
• identify critical sequencing errors, missing relationships, and circular logic;
• validate a network with project stakeholders and suitable scheduling tools; and
• assess the managerial, contractual, and governance implications of dependencies.

1. The Meaning and Role of Dependencies

An activity is a defined piece of project work that produces an output, decision, or deliverable. A dependency exists when the start or finish of one activity is constrained by the start or finish of another. The constraining activity is often called the predecessor, while the constrained activity is the successor.

For example, “configure the production environment” may depend on “approve the deployment plan.” The approval is the predecessor and configuration is the successor. The dependency does not necessarily mean that the entire approval activity must be completed before every aspect of configuration begins; the exact relationship must be specified.

Dependencies serve several purposes:

1. They express workflow logic. The network shows how deliverables are produced.
2. They support schedule calculations. Early and late dates depend on the network structure.
3. They expose risk. A successor may rely on a supplier, regulator, specialist, or uncertain decision.
4. They guide coordination. Teams can see when inputs are required and who must provide them.
5. They support change analysis. If one activity moves, the network helps identify affected work.

A dependency is not the same as a resource constraint. If two activities cannot occur together because only one test environment is available, that is primarily a resource limitation. If testing must wait until a build exists, that is a logical dependency. In practice, both may affect the schedule, but they should be recorded and managed differently.

2. Classifying Dependencies

Two classification dimensions are especially important: the degree of necessity and the source of the relationship.

2.1 Mandatory and discretionary dependencies

A mandatory dependency is logically required by the nature of the work, by physical or technical limitations, or by a binding legal or contractual requirement. It is sometimes called a hard logic dependency. Examples include:

• source code must exist before it can be compiled;
• a database schema must be available before dependent database integration tests can run;
• a product must pass an approval gate before contractual release;
• a security control required by regulation must be implemented before production access is granted.

Mandatory does not mean that only one implementation sequence is possible. For example, a complete system test may require an integrated build, but unit testing can occur while other components are still being developed. The mandatory relationship applies to the defined activities, not necessarily to broad phases such as “development” and “testing.”

A discretionary dependency is a preferred or established sequence that could be changed without violating the fundamental nature of the work. It is sometimes called soft logic, preferred logic, or preferential dependency. Examples include:

• conducting a design review before detailed coding because the organization prefers early assurance;
• completing the user-interface prototype before designing training materials;
• implementing a familiar module before a technically more difficult module to reduce team risk.

Discretionary dependencies should be documented with their rationale. They can often be revised when a deadline changes, but removing them may increase risk, reduce quality, or create coordination problems. Treating a preference as mandatory unnecessarily reduces schedule flexibility.

2.2 Internal and external dependencies

An internal dependency is controlled mainly within the project or performing organization. Examples include a relationship between requirements analysis and software configuration, or between code completion and an internal quality review.

An external dependency involves a party or event outside the direct control of the project team. Examples include:

• a cloud provider supplying an approved environment;
• a client providing data or acceptance criteria;
• a regulator granting an authorization;
• a vendor delivering a software component;
• another organizational project completing an interface.

External dependencies require explicit ownership, assumptions, dates, communication arrangements, and contingency planning. A project manager should not represent an external commitment as if it were an internal promise. The schedule should identify who controls the predecessor and what evidence will confirm its completion.

The categories can overlap. A legally required approval from an external regulator is both mandatory and external. A preferred internal design review is discretionary and internal. Classification is useful because it informs the appropriate management response.

3. Logical Relationships in Precedence Networks

The most widely used representation is the precedence diagramming method (PDM), also called activity-on-node network planning. In PDM, each activity is shown as a node, and arrows show logical relationships. The four standard relationship types are finish-to-start, start-to-start, finish-to-finish, and start-to-finish.

3.1 Finish-to-start (FS)

In a finish-to-start relationship, the successor cannot start until the predecessor has finished. This is the most common relationship.

Example: “Complete test script” → “Execute test.”

The relationship can be expressed as:

Here, S_s is the start time of the successor, F_p is the finish time of the predecessor, and L is the lag. With no lag, L = 0. A positive lag creates waiting time; a negative lag is a lead.

3.2 Start-to-start (SS)

In a start-to-start relationship, the successor cannot start until the predecessor has started. It is appropriate where activities can overlap after a triggering point.

Example: “Begin requirements workshops” → “Begin requirements documentation.” Documentation may start once workshops begin, although it may continue after the workshops finish.

The constraint is:

A start-to-start link does not imply that the two activities finish together or that the successor may begin immediately. A positive lag may be needed, such as starting documentation two working days after workshops begin.

3.3 Finish-to-finish (FF)

In a finish-to-finish relationship, the successor cannot finish until the predecessor has finished. The activities may start independently.

Example: “Conduct performance testing” → “Finalize performance report.” The report may begin while testing is underway, but it cannot be finalized before the test evidence is complete.

The constraint is:

This relationship is often preferable to an artificial finish-to-start link when work can legitimately overlap.

3.4 Start-to-finish (SF)

In a start-to-finish relationship, the successor cannot finish until the predecessor has started. This is uncommon and should be used only when it accurately describes the work.

Example: an old support arrangement may continue until a new support service begins. The start of the new service permits the old service to finish. The relationship is:

Using start-to-finish merely to force a desired date is poor practice. The relationship should be explainable to someone who was not involved in creating the schedule.

3.5 Network notation

A useful activity node may include the activity identifier, description, duration, owner, and status. Arrows should point from predecessor to successor. A network should have a clear beginning and end, even if summary milestones are used.

Figure: An illustrative precedence network with parallel activities converging at system test.

The diagram shows that requirements precede design, while development and test preparation proceed in parallel after design. System test requires both branches. This is important: a successor with several predecessors cannot begin until all mandatory predecessor conditions are satisfied.

4. Leads and Lags

A lag is a deliberate waiting period inserted between related activities. A positive lag may represent drying, stabilization, review time, data transfer, or a contractual waiting period. In software projects, examples include waiting two days after a configuration change before reviewing monitoring results, or allowing a client five working days to review a deliverable.

A lead is an intentional overlap that allows a successor to begin before the predecessor is fully complete. In scheduling notation, a lead is often represented as a negative lag. For example, testing may begin when development is 20 percent complete, provided that the testable component is available and the relationship is properly controlled.

Leads and lags should be used carefully:

• State the unit, such as working days or calendar days.
• Explain the business or technical rationale.
• Identify the portion of work that can overlap.
• Confirm that quality, safety, security, and contractual conditions remain satisfied.
• Avoid hiding uncertainty inside unexplained lag values.
• Review the relationship when the method of delivery changes.

For example, “Development finish to test start, lag 3 days” is less informative than “Test environment stabilization: three working days after deployment.” The second description makes the reason and ownership visible.

A lead can reduce elapsed time but may increase coordination and rework risk. If development and testing overlap, testers may repeatedly revise scripts as the software changes. A lag can improve stability but may create idle time. The project manager must therefore balance schedule compression against cost, quality, and risk.

5. Constructing a Precedence Network

Network construction should begin with a validated activity list. A practical sequence is as follows.

Step 1: Clarify activity definitions

Each activity should have a clear start condition, finish condition, deliverable, responsible role, and estimated duration. “Develop system” is usually too broad to sequence effectively. “Implement authentication service” and “Integrate authentication service with user portal” are more useful activities.

Step 2: Identify immediate predecessors

For every activity, ask: “What must be true before this activity can start or finish?” Record immediate predecessors rather than every activity that has ever influenced the work. Redundant relationships make networks difficult to understand and maintain.

Step 3: Classify each relationship

Record whether the dependency is mandatory or discretionary and internal or external. Also identify the relationship type and any lead or lag.

Step 4: Draw or enter the network

Use nodes for activities and arrows for relationships. A schedule tool can calculate dates, but it cannot determine whether the logic is professionally sensible. The team must supply and review the logic.

Step 5: Check convergence and divergence

A merge occurs when multiple predecessors feed one successor. A burst occurs when one activity feeds multiple successors. Confirm that every incoming relationship is necessary and that every outgoing relationship represents a real information or deliverable flow.

Step 6: Add milestones and external events

Milestones have zero duration and represent significant points such as “client acceptance received” or “release authorized.” External events should be labelled clearly rather than hidden in an activity name.

6. Worked Example: Calculating a Simple Network Duration

Consider the following illustrative software project. Durations are in working days and are assumed to be deterministic for this basic example.

Using finish-to-start relationships with zero lag:

• A finishes on day 3.
• B starts after A and finishes on day 7.
• C starts on day 7 and finishes on day 13.
• D also starts on day 7 and finishes on day 10.
• E must wait for both C and D, so it starts on day 13 and finishes on day 17.
• F starts on day 17 and finishes on day 18.

The planned network duration is therefore 18 working days. The path A–B–C–E–F has duration 3 + 4 + 6 + 4 + 1 = 18 days. The alternative path A–B–D–E–F has duration 3 + 4 + 3 + 4 + 1 = 15 days. The longer path controls the earliest project completion in this simple network and is called the critical path, subject to the assumptions of the schedule.

The calculation uses the forward-pass principle: an activity’s earliest start is constrained by the latest required predecessor finish. In general, for finish-to-start relationships with zero lag:

where ES_s is the earliest start of successor s, and EF_p represents the earliest finish of each predecessor. For an activity with duration d,

These equations assume a consistent time convention. If the project uses day-one date counting rather than elapsed-time counting, displayed calendar dates may differ by one date even though elapsed duration is unchanged. The schedule standard must state its convention.

7. Validating Activity Sequencing

Validation is more than checking whether the software accepts the network. It is a structured review of whether the logic reflects the way work will actually occur.

7.1 Logic validation questions

For each activity, ask:

• What input, decision, or condition permits the activity to start?
• What output permits the successor to start or finish?
• Is the relationship truly mandatory, or merely preferred?
• Is the relationship internal or external?
• Is the selected relationship type accurate?
• Is the lead or lag measurable and justified?
• Could the activities overlap safely?
• Are any activities missing predecessors or successors?
• Is there a circular dependency?
• Does the network contain unnecessary constraints?

7.2 Common network defects

Missing predecessor. An activity begins without its required input, such as test execution scheduled before a testable build exists.

Missing successor. An output is produced but no later activity uses or verifies it. This may indicate an incomplete scope model.

Circular logic. Activity A requires B, while B requires A. No valid schedule can satisfy this cycle. The cycle must be resolved by redefining activities, separating partial outputs, or removing an incorrect relationship.

Dangling activity. An activity has no meaningful connection to the project start or finish. It may be out of scope, incorrectly entered, or missing links.

Over-constrained network. Many discretionary relationships are entered as mandatory-looking links. This reduces flexibility and may create artificial critical paths.

Incorrect relationship type. A finish-to-start link is used where a finish-to-finish relationship better represents overlapping work, or a start-to-finish link is used without a genuine handover logic.

Unexplained lag. A large lag hides a planning assumption, waiting period, or risk. It should be described and assigned an owner.

External dependency without accountability. The schedule names a vendor deliverable but does not record the supplier commitment, acceptance condition, escalation route, or contingency.

7.3 Validation techniques

A logic walk-through involves reviewing each chain from project initiation to completion with the people who perform the work. A reverse walk-through starts with the final deliverable and asks what must have occurred immediately before it. Comparing both directions often reveals omissions.

A dependency register records the predecessor, successor, dependency type, relationship type, owner, evidence, due date, risk, and response. This is especially useful for external dependencies.

A schedule quality review may use tool-based checks for open ends, excessive constraints, negative float, lags, and cycles. Automated checks are valuable but cannot judge whether a relationship is technically meaningful.

A scenario test asks what happens if a predecessor is delayed, delivered partially, or rejected. The aim is not to predict every event but to reveal fragile chains and unowned assumptions.

8. Case Application: A Client Portal Release

The following is an illustrative case. A small software company is delivering a secure client portal. The release includes authentication, document upload, audit logging, and user acceptance testing.

Background and problem

The initial schedule placed user acceptance testing immediately after “development complete.” The project manager noticed that the client’s test accounts, representative documents, and security review were not represented. The team also linked every development activity finish-to-start, even though testers could prepare scripts while development was progressing.

The result was a nominally short schedule with a high probability of late discovery and rework.

Analysis

The team classified the major dependencies:

• Authentication design before authentication implementation: mandatory and internal.
• Client provision of representative documents before realistic upload testing: mandatory for that test and external.
• Security review before production authorization: mandatory and partly external, because the client’s security officer must approve the evidence.
• Test-script preparation after test objectives are agreed: discretionary-to-mandatory in practice, depending on the governance standard.
• Training-material drafting while the user interface is stable: discretionary and internal.

The team replaced the vague “development complete” predecessor with more precise deliverables. Testers could prepare scripts after objectives were approved, using a start-to-start relationship with requirements clarification and a short lag. Upload testing could not complete until sample documents were received. Production authorization was linked to security approval by finish-to-start with zero lag.

Approach and solution

The revised network included:

1. Confirm acceptance criteria.
2. Prepare test objectives and scripts in parallel with development, subject to agreed inputs.
3. Build authentication and upload functions.
4. Obtain client test accounts and documents as an external dependency.
5. Deploy a release candidate to the test environment.
6. Complete security review and resolve mandatory findings.
7. Conduct user acceptance testing.
8. Obtain client acceptance.
9. Authorize production deployment.

Each external dependency received an owner and evidence requirement. “Client data received” was replaced by “approved representative documents received and validated,” making the completion condition testable.

Outcome

The revised schedule did not simply shorten the project. It made the completion forecast more credible. Test preparation began earlier, while the client data dependency was visible as a risk. The security review was no longer assumed to occur informally. When the client delayed its documents, the team could distinguish the resulting impact from internal development performance and could use synthetic data for some tests without falsely claiming that realistic upload testing was complete.

Learning points

The case illustrates four principles. First, broad phase labels conceal important logic. Second, parallel work is useful only when the required inputs and quality conditions are explicit. Third, external dependencies need ownership and evidence. Fourth, a network is a management model, not merely a drawing used to calculate dates.

9. Professional, Governance, and Technology Considerations

Dependency decisions affect accountability. If a project manager records a supplier delivery as a firm predecessor without confirming the supplier’s commitment, stakeholders may interpret an assumption as a guarantee. Schedule baselines should therefore distinguish commitments, estimates, assumptions, and constraints.

Security and privacy dependencies deserve particular care. A schedule should not encourage teams to bypass security review merely to preserve a target date. Activities involving personal data should include appropriate authorization, data-minimization, access-control, and retention conditions. “Test data available” should not automatically mean that production personal data may be copied into a test environment.

Contractual dependencies should identify acceptance criteria, notice periods, service-level obligations, and escalation procedures. A milestone such as “vendor component delivered” may be insufficient if the contract requires installation, verification, and acceptance.

Modern scheduling tools can identify cycles, calculate dates, display network views, and highlight external links. Artificial intelligence may assist by detecting unusual lags, suggesting possible missing relationships from historical schedules, or summarizing dependency risks. Such suggestions require human review. AI-generated logic may reproduce past planning errors, confuse correlation with necessity, or infer sensitive information from project data. The accountable project team must approve the network, preserve an audit trail, and protect confidential client and supplier information.

10. Best Practices and Limitations

Effective dependency management follows several practices:

• define activities at a level that exposes meaningful deliverables;
• use mandatory relationships only when technically, legally, or contractually justified;
• document the rationale for discretionary logic;
• identify external owners and confirmation evidence;
• prefer the simplest relationship that accurately represents the work;
• use leads and lags sparingly and explain them in plain language;
• validate the network with performers, clients, suppliers, and assurance roles;
• review dependencies at major scope or solution changes; and
• distinguish logical dependencies from resource limitations and management-imposed dates.

Network planning also has limitations. Estimates may be uncertain, activities may produce partial outputs, and iterative development may not fit neatly into a single linear chain. A network is a model and therefore a simplification. It should be detailed enough to support decisions but not so detailed that it becomes impossible to maintain. In adaptive or agile environments, dependencies still exist; they may be managed through backlog ordering, integration agreements, interface definitions, release coordination, and explicit entry and exit criteria rather than through a long fixed schedule.

Chapter Summary

Dependencies express the logical conditions that connect project activities. They may be mandatory or discretionary, and internal or external. Mandatory dependencies arise from the nature of the work, law, technology, or contract; discretionary dependencies represent preferred practice. Internal dependencies are primarily controlled by the project, whereas external dependencies require coordination with another party or event.

Precedence diagramming represents activities as nodes and relationships as arrows. The four standard relationship types are finish-to-start, start-to-start, finish-to-finish, and start-to-finish. Leads permit planned overlap, while lags introduce waiting time. Both must be justified, measured consistently, and reviewed for their effects on quality and risk.

A reliable network is built from clearly defined activities, immediate predecessors, explicit relationship types, and validated completion conditions. Walk-throughs, dependency registers, reverse reviews, scenario tests, and scheduling-tool checks help identify missing logic, cycles, dangling activities, excessive constraints, and unowned external dependencies. Network planning is therefore both a technical scheduling activity and a governance practice that makes assumptions and accountability visible.

Key Terms

Dependency: A logical relationship in which one activity constrains another.

Predecessor: An activity that provides a condition, input, or event for a successor.

Successor: An activity constrained by one or more predecessors.

Mandatory dependency: A relationship required by technical, physical, legal, or contractual conditions.

Discretionary dependency: A preferred relationship that could be changed without violating fundamental work logic.

Internal dependency: A dependency controlled mainly within the project or organization.

External dependency: A dependency involving a party or event outside the project team’s direct control.

Precedence diagramming method: A network technique that represents activities as nodes and relationships as arrows.

Finish-to-start: A relationship in which the successor starts after the predecessor finishes.

Start-to-start: A relationship in which the successor starts after the predecessor starts.

Finish-to-finish: A relationship in which the successor finishes after the predecessor finishes.

Start-to-finish: A relationship in which the successor finishes after the predecessor starts.

Lead: Planned overlap allowing a successor to begin before its predecessor is complete.

Lag: Deliberate waiting time between related activities.

Milestone: A zero-duration event representing an important achievement or decision.

Merge: A point at which several predecessor relationships feed one successor.

Burst: A point at which one activity leads to several successor activities.

Critical path: The longest logical path through a network under the schedule’s assumptions.

Dependency register: A controlled record of dependencies, owners, conditions, dates, and risks.

Dangling activity: An activity insufficiently connected to the project’s start or finish logic.

Review Questions

Short Answer Questions

1. What is the difference between a predecessor and a successor?
2. Distinguish mandatory and discretionary dependencies.
3. What is an external dependency? Give one software-project example.
4. Define a lag and explain why its rationale should be documented.
5. Name the four standard precedence relationship types.

Long Answer Questions

1. Explain how a project team can construct and validate a precedence network from an activity list.
2. Compare finish-to-start, start-to-start, finish-to-finish, and start-to-finish relationships, using an example for each.
3. Discuss the risks of treating discretionary dependencies as mandatory.
4. Explain why external dependencies require different management practices from internal dependencies.
5. Describe how leads and lags can reduce elapsed time while increasing project risk.

Analytical / Application Questions

1. A project schedules system testing immediately after coding, but test data, security approval, and the client’s acceptance criteria are not represented. Identify the likely missing dependencies and propose a revised sequence.
2. Two activities are linked finish-to-start even though the successor can begin after the predecessor starts and can continue while it completes. Which relationship may be more appropriate, and what risks must be assessed before changing it?
3. An external supplier’s interface component is three days late. Explain how you would use the network, dependency register, and scenario analysis to assess and manage the impact.

Multiple Choice Questions with Answers

Question 1

Which dependency is normally classified as mandatory?

A. Conducting a preferred design review before coding

B. Compiling source code before executing the compiled integration test

C. Writing training materials before preparing a demonstration

D. Implementing the most familiar module first

Correct Answer: B. Compiling source code before executing the compiled integration test

Question 2

A relationship requires the successor to start only after the predecessor has finished. Which relationship is this?

A. Finish-to-start

B. Start-to-start

C. Finish-to-finish

D. Start-to-finish

Correct Answer: A. Finish-to-start

Question 3

Which example is an external dependency?

A. A development task waiting for an internal code review

B. A tester waiting for a build from the project team

C. A release waiting for a client’s security approval

D. A developer waiting for a local design decision

Correct Answer: C. A release waiting for a client’s security approval

Question 4

What is the primary purpose of a lag?

A. To remove a predecessor from the network

B. To introduce deliberate waiting time between related activities

C. To convert an internal dependency into an external dependency

D. To make every activity critical

Correct Answer: B. To introduce deliberate waiting time between related activities

Question 5

In a precedence network, what does a merge represent?

A. One activity leading to several successors

B. Several predecessors feeding one successor

C. A circular dependency

D. An activity with no duration

Correct Answer: B. Several predecessors feeding one successor

Question 6

Which relationship is most appropriate when a report may be prepared during testing but cannot be finalized until testing finishes?

A. Start-to-start

B. Start-to-finish

C. Finish-to-finish

D. Finish-to-start with no predecessor

Correct Answer: C. Finish-to-finish

Question 7

In the worked network, activities A, B, C, E, and F have durations of 3, 4, 6, 4, and 1 working days. What is the duration of that path?

A. 15 working days

B. 16 working days

C. 17 working days

D. 18 working days

Correct Answer: D. 18 working days

Question 8

Which issue occurs when Activity A requires Activity B, while Activity B also requires Activity A?

A. A burst

B. A circular dependency

C. A milestone

D. A discretionary dependency

Correct Answer: B. A circular dependency

Question 9

What is a lead in scheduling?

A. A planned overlap allowing a successor to begin before the predecessor is complete

B. A mandatory delay after the predecessor finishes

C. A zero-duration approval event

D. A relationship controlled by a supplier

Correct Answer: A. A planned overlap allowing a successor to begin before the predecessor is complete

Question 10

Which practice best improves management of an external dependency?

A. Hide it inside a broad summary activity

B. Treat the supplier’s estimate as an internal commitment

C. Assign an owner and define evidence confirming completion

D. Remove it from the schedule until it becomes late

Correct Answer: C. Assign an owner and define evidence confirming completion