Network Construction and Logic Validation

Introduction

A project network is a formal representation of the logical relationships among project activities. It answers a deceptively simple question: what must occur before what, and under which conditions? In network-based scheduling, activity durations are important, but duration calculations are meaningful only when the underlying logic is coherent. An incorrectly constructed network can produce an apparently precise completion date that is operationally impossible.

Network construction therefore precedes critical path analysis. The scheduler must translate scope, work packages, and sequencing knowledge into a directed network, assign unique identifiers, validate relationships, and test for structural and semantic defects. This chapter focuses on activity-on-node networks, which are the dominant representation in contemporary scheduling software, while also explaining concepts that apply to activity-on-arrow networks.

Learning Objectives

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

1. Construct a coherent activity-on-node project network.
2. Assign unique activity identifiers and distinguish identifiers from descriptions.
3. Explain merge points, burst points, open ends, loops, and redundant relationships.
4. Detect inappropriate constraints and incorrect dependency types.
5. Perform formal structural, logical, and managerial schedule checks.
6. Apply validation methods to a realistic project scenario.
7. Recognize the limitations of automated schedule-quality metrics.

1. The Network as a Directed Graph

A project network can be represented as a directed graph G = (V, E), where V is the set of activities or nodes and E is the set of directed relationships. An edge from activity A to activity B means that the scheduling logic requires A to precede B in the specified manner.

In a basic finish-to-start relationship without lag, activity B cannot start until activity A has finished. If activity A has duration d_A and begins at time S_A, its finish is:

where F_A is the finish time, and all time quantities use the same unit, such as working days. For a finish-to-start relationship with lag L_AB, the successor’s early-start calculation is:

Here, ES_B is the early start of B, EF_A is the early finish of A, and L_AB is the lag. This expression assumes a finish-to-start relationship and a consistent calendar. Other relationship types require different expressions and careful interpretation of lag.

A valid network normally has:

• a defined project start or start milestone;
• a defined project finish or finish milestone;
• directed relationships that reflect real dependencies;
• no circular paths;
• no unexplained activities disconnected from the principal flow;
• activity identifiers that are unique and stable;
• logic that is sufficient to explain execution without encoding unnecessary restrictions.

The network is not merely a drawing. It is a decision model concerning sequence, responsibility, information flow, and conditions of work.

2. From Scope to Network Logic

Network construction begins with the work breakdown structure and the activity list. A work package describes deliverable-oriented scope; an activity is a schedulable piece of work that can be assigned, estimated, monitored, and statused. The two should not be confused. A work package may contain several activities, while an activity should be sufficiently specific to establish a meaningful duration and dependency.

For each activity, the planner should establish:

A useful activity name normally includes a verb and an object, such as “Approve structural design” rather than “Structural design.” Ambiguous names make logic review difficult because reviewers cannot determine what completion means.

2.1 Dependency categories

Dependencies should be classified before they are encoded in software.

Mandatory dependencies arise from the nature of the work, safety requirements, physical interfaces, or technical necessity. A foundation must normally precede the erection of a structure.

Discretionary dependencies reflect a preferred method or organizational practice. They may be changed if the project team adopts another execution strategy. Such logic should be documented because it may create schedule flexibility or risk.

External dependencies involve parties or events outside the project team, such as regulatory approval, delivery by a supplier, or a utility connection.

Internal dependencies are controlled within the project, such as the sequence between design review and procurement release.

This classification is valuable during risk analysis. Mandatory logic often represents technical feasibility, whereas discretionary logic may be a target for optimization.

2.2 Relationship types

The four standard relationship types are:

• Finish-to-start (FS): the predecessor finishes before the successor starts.
• Start-to-start (SS): the predecessor starts before the successor starts.
• Finish-to-finish (FF): the predecessor finishes before the successor finishes.
• Start-to-finish (SF): the predecessor starts before the successor finishes.

FS is common, but using it everywhere can distort the real execution model. For example, testing may begin after part of an installation is complete, making SS more appropriate than FS. Conversely, a finish-to-finish relationship may express the need for two streams of work to complete together.

Relationship type should describe a genuine condition, not compensate for vague activity definitions. Excessive use of SS or FF relationships can make progress measurement and forensic analysis difficult, especially when actual status is uncertain.

3. Identifiers, Nodes, and Network Conventions

An activity identifier is a unique key, not a description. IDs should remain stable throughout the project so that baselines, updates, correspondence, and reports can be reconciled. A practical identifier might be “CIV-120” or “WP03-045.” Sequential numbering is useful, but the numbering should not imply a permanent execution order. If activity 120 precedes activity 130 numerically, that should not be interpreted as a logical relationship unless an explicit link exists.

Activity-on-node notation places the activity in a box or node and relationships on connecting arrows. Milestones may be represented as zero-duration nodes, but they should be used consistently. A milestone represents an achieved condition, such as “permit approved,” rather than a quantity of work.

A network should be readable at several levels:

1. Executive level: major deliverables and control milestones.
2. Management level: work packages, interfaces, and phase gates.
3. Control level: activities suitable for assignment and status reporting.

Overly detailed networks create maintenance costs and false precision. Overly aggregated networks hide interfaces and make critical-path interpretation unreliable.

4. Merge and Burst Points

A merge point is an activity or event with two or more immediate predecessors. It represents convergence of work streams. For example, commissioning may require both equipment installation and operator training.

A burst point is an activity or event with two or more immediate successors. It represents divergence into parallel work streams. For example, approval of a design may release procurement, construction planning, and regulatory submission.

Merge and burst points are not defects. They are important control locations because they expose integration risk. At a merge point, the successor is exposed to delay in any required predecessor. At a burst point, one late predecessor may affect several downstream paths.

Figure: A burst point releases parallel work, while a merge point requires several streams to converge.

The planner should ask whether all predecessors at a merge point are genuinely required and whether all successors at a burst point are genuinely dependent on the predecessor. This question often reveals accidental logic.

5. Open Ends and Network Connectivity

An open end is an activity with no predecessor or no successor where one is expected. A legitimate project start activity may have no predecessor, and a legitimate project finish activity may have no successor. Other open ends require explanation.

Typical causes include:

• an omitted relationship;
• an activity created for reporting but not integrated into the schedule;
• a cancelled or superseded activity left in the model;
• a missing start or finish milestone;
• a relationship placed on the wrong activity;
• an external dependency not represented explicitly.

Open ends should be reviewed rather than automatically eliminated. For example, a regulatory approval may legitimately have no internal predecessor if it is driven by an external date, but the external assumption should be documented. Similarly, a final handover activity may have no successor because it defines project completion.

A connectivity check can identify the set of activities reachable from the start node and the set that can reach the finish node. Activities in neither relevant set are disconnected. In software, this is commonly implemented using graph traversal, such as depth-first search or breadth-first search. The mathematical test is structural; the professional judgment concerns whether the resulting structure represents the intended project.

6. Loops and Circular Logic

A loop exists when a directed path returns to an earlier activity. For example, “Test system” may be linked to “Correct defects,” which is linked back to “Test system.” Iteration may be real, but a circular schedule relationship usually cannot be calculated as an ordinary precedence network.

A loop must be distinguished from a planned iterative process. Iteration should be represented through explicitly bounded activities or a controlled planning assumption, such as a defined test–repair cycle. An unbounded cycle creates ambiguity about the number of repetitions and can prevent forward and backward schedule calculations.

Formally, a directed acyclic graph has no directed cycle. A topological ordering exists if and only if the directed graph is acyclic. Scheduling engines use an equivalent concept when calculating activity order. If a topological sort fails, the network contains a cycle or an equivalent data inconsistency.

Common sources of loops include:

• incorrect predecessor selection after copying activities;
• reciprocal links added by different discipline teams;
• status-driven logic, where an activity is linked to its own approval;
• confusing a deliverable with the activity that produces it;
• attempts to model rework without defining iteration boundaries.

7. Redundant Logic and Inappropriate Constraints

A relationship is redundant when another path already imposes the same effective precedence condition and the additional link adds no useful scheduling information. Redundancy is not always harmful, but unnecessary links increase maintenance effort and can conceal the true logic.

Consider A→B, B→C, and A→C. If all relationships are FS with zero lag, A→C may be redundant because the path through B already requires A to precede C. However, removing it should be considered only after checking calendars, relationship types, lags, constraints, and the intended meaning. A direct relationship may still be retained for communication or interface control, but it should be documented as deliberate.

Inappropriate constraints include imposed dates that do not represent genuine external conditions. Examples are unnecessary “must start on” dates, artificial finish dates, and excessive use of “as soon as possible” or “as late as possible” settings without a sound baseline strategy.

Constraints can mask missing logic. If an activity starts on a desired date because of a hard constraint rather than because its predecessors support that date, the network may appear feasible while its causal structure is weak. Constraints should therefore be classified as:

• contractual or regulatory;
• resource or calendar related;
• externally imposed;
• management target;
• temporary planning assumption.

A target date is not automatically a logic constraint. It may be better represented as a milestone or deadline against which variance is measured.

8. Formal Schedule Logic Checks

A robust validation process combines automated tests with expert review. The following sequence is effective.

8.1 Structural checks

Check that:

• every activity has a unique ID;
• no IDs are duplicated or reused;
• every relationship references existing activities;
• relationship types and lags are valid;
• calendars are assigned;
• duration units are consistent;
• the network has a defined start and finish;
• no unintended disconnected subnetwork exists.

8.2 Graph checks

Run a cycle-detection algorithm. Then perform reachability analysis from the start and toward the finish. Flag activities with no predecessor, no successor, or both, excluding approved start and finish exceptions.

8.3 Logic checks

Review:

• excessive reliance on FS relationships;
• unusual or negative lags;
• excessive relationship counts;
• dangling milestones;
• relationships that skip deliverable interfaces;
• activities linked to summary tasks where detail-level logic is required;
• links crossing work packages without an identifiable interface.

Negative lag, sometimes called lead, should be treated cautiously because it can hide overlap assumptions and complicate status interpretation. Where overlap is operationally meaningful, it is often clearer to define separate activities or use SS/FF logic with explicit assumptions.

8.4 Constraint and calendar checks

Identify activities whose dates are controlled primarily by constraints rather than logic. Examine calendar exceptions, nonworking periods, time zones, and 24-hour operations. A logically sound network can still produce a wrong date if calendars are inconsistent.

8.5 Critical-path and float checks

After logic validation, calculate early and late dates. For an activity, total float is commonly calculated as:

where ES and EF are early start and early finish, and LS and LF are late start and late finish. The equality assumes a consistent forward and backward pass and the same project completion objective. Activities with zero total float under the adopted calculation may form a critical path, but near-critical activities also require management attention.

A path that appears critical only because of an artificial constraint should not be treated as a technical critical path without qualification.

8.6 Independent review

The schedule owner should not be the only person validating the logic. A discipline lead can test technical dependencies, a project manager can test deliverable sequencing, and an independent scheduler can test structural integrity. Review comments should be traceable to specific activities and relationships.

9. Worked Example: Constructing and Validating a Small Network

Consider a software implementation project with the following activities:

A100 is the start activity. A100 is a burst point because it releases A110 and A120. A150 is a merge point because it requires both A130 and A140. A170 is the final activity.

Assume a project start at day 0 and a finish-to-start relationship with zero lag. The forward pass gives:

• A100: ES 0, EF 3.
• A110: ES 3, EF 11.
• A120: ES 3, EF 8.
• A130: ES 11, EF 15.
• A140: ES 8, EF 11.
• A150: ES max(15, 11) = 15, EF 19.
• A160: ES 19, EF 21.
• A170: ES 21, EF 22.

The project duration is therefore 22 working days. The controlling path is A100–A110–A130–A150–A160–A170, with total duration 22 days. The training branch finishes at day 11, while A150 cannot begin until day 15; therefore the training branch has four days of schedule flexibility under the stated assumptions. This flexibility is not automatically guaranteed: resource constraints, calendars, or unrecorded dependencies could consume it.

Suppose a planner adds a direct relationship A100→A150. Under the current logic it is redundant, because A100 already precedes A110 and A130, which precede A150. The direct link should be removed unless it represents a separately documented requirement. Suppose also that A140 has no successor because the link to A150 was accidentally omitted. The resulting open end would incorrectly make training appear irrelevant to testing. These examples illustrate why validation must examine both structure and meaning.

10. Applied Case: Data-Centre Migration

Background

The following is an illustrative case. A university plans to migrate a student-records application to a new data centre during a scheduled service window. The initial schedule contains design, infrastructure preparation, security approval, data migration, user acceptance testing, and cutover.

Problem

The first schedule shows a 14-day completion period, but operations staff question whether cutover can occur safely. Review reveals that security approval is linked to the final cutover date by a hard constraint rather than linked to completion of the security assessment. A network engineer also discovers that data migration has no predecessor and that the rollback plan is not connected to the cutover decision.

Analysis

The scheduler conducts four analyses:

1. Scope-to-activity traceability: each required deliverable is mapped to an activity.
2. Dependency workshop: security, infrastructure, application, and operations specialists identify mandatory and discretionary dependencies.
3. Graph validation: the schedule is tested for open ends, cycles, and invalid references.
4. Constraint review: every hard constraint is classified and justified.

The team establishes that migration can begin only after infrastructure validation and security approval. User acceptance testing requires migrated test data. Cutover requires successful testing and an approved rollback plan. The original hard constraint is replaced by a contractual service-window milestone, while the causal logic is represented through explicit predecessors.

Approach and solution

The revised network uses:

• infrastructure validation → security assessment;
• infrastructure validation → test-data migration;
• security approval and test-data migration → user acceptance testing;
• rollback plan approval → cutover readiness;
• user acceptance testing and cutover readiness → cutover.

The network now contains a legitimate merge at cutover readiness and exposes the rollback plan as a critical interface rather than an isolated document activity. The service window remains a deadline, not a substitute for technical logic.

Outcome

The revised model increases the calculated duration by two working days, but it improves credibility. More importantly, it identifies the security approval and rollback plan as potential schedule risks. Management can now decide whether to add resources, reduce scope, or negotiate the service window on the basis of visible logic.

Learning points

• A shorter schedule is not necessarily a better schedule.
• Constraints should not hide missing dependencies.
• Safety and governance activities must be connected to the work they authorize.
• Cross-disciplinary reviews identify logic that a scheduler working alone may miss.

11. Technology, Automation, and AI-Assisted Validation

Modern scheduling tools can automatically detect duplicate IDs, invalid links, loops, open ends, excessive lags, and constraint patterns. Graph databases and application programming interfaces can support large-scale network analysis. Visualization tools can highlight high-connectivity nodes and paths with low float.

AI can assist by comparing activity descriptions with likely dependency patterns, identifying inconsistent naming, and flagging activities that appear disconnected from deliverables. It can also summarize change impacts when a predecessor is delayed. However, AI should be treated as an analytical aid rather than an authority. A model may infer a plausible relationship that is not technically mandatory, or it may overlook a safety, contractual, or organizational condition absent from the data.

Governance requires that generated recommendations be explainable, reviewable, and traceable to source information. Human approval remains necessary for logic affecting safety, regulatory compliance, contractual commitments, or executive decisions. Version control should preserve the network before and after automated changes.

12. Limitations and Professional Judgment

Network logic is a simplified model of project execution. It does not automatically represent resource contention, learning effects, productivity variation, uncertainty, rework probability, or organizational behavior. Two activities may be logically independent but unable to proceed concurrently because they require the same specialist. Resource-leveling analysis is therefore complementary to precedence-network validation.

Likewise, a relationship does not guarantee that the predecessor will provide a usable output. Quality, approval, information completeness, and interface readiness may need explicit activities or acceptance criteria. The schedule should not become a repository for every risk, but material conditions should be visible through activities, milestones, assumptions, or risk links.

Professional validation is ultimately a combination of graph discipline and domain knowledge. Automated checks can prove that a reference exists; they cannot prove that the reference represents reality.

Best-Practice Checklist

Before approving a baseline network, confirm that:

1. The schedule is traceable to scope and deliverables.
2. Every activity has a unique, stable identifier.
3. Activity names describe observable work or an achieved condition.
4. Mandatory, discretionary, internal, and external dependencies are distinguished.
5. Relationship types reflect actual execution conditions.
6. Start and finish open ends are intentional and documented.
7. No unintended loops or disconnected subnetworks exist.
8. Merge and burst points have been reviewed for interface risk.
9. Redundant relationships and unexplained lags have been assessed.
10. Constraints are justified and do not conceal missing logic.
11. Calendars, units, and time zones are consistent.
12. Independent technical and schedule reviews have been completed.
13. Critical and near-critical paths have been interpreted in context.
14. Changes are controlled, versioned, and traceable.

Chapter Summary

Network construction converts project scope and execution knowledge into a directed model of precedence. A sound network uses unique identifiers, clear activity definitions, appropriate relationship types, and documented dependency classifications. Merge points reveal convergence and integration exposure; burst points reveal the release of parallel work. Open ends may be legitimate at project boundaries, but unexplained open ends indicate missing or disconnected logic. Loops prevent ordinary precedence calculations and must be removed or represented through bounded iteration. Redundant relationships increase maintenance effort, while inappropriate constraints can mask weak causal logic.

Formal validation combines structural tests, graph algorithms, relationship review, calendar and constraint analysis, and independent professional judgment. Critical-path calculations are meaningful only after the network has passed these checks. Technology and AI can improve detection and analysis, but governance requires human review, traceability, and caution when schedule logic affects safety, contracts, or regulation.

Key Terms

Network: A directed representation of project activities and relationships.

Directed graph: A graph in which relationships have a specified direction.

Activity-on-node: A notation in which activities are represented by nodes.

Predecessor: An activity that logically precedes another activity.

Successor: An activity that logically follows another activity.

Unique identifier: A stable code that distinguishes one activity from all others.

Merge point: A node with multiple immediate predecessors.

Burst point: A node with multiple immediate successors.

Open end: An activity lacking an expected predecessor or successor.

Loop: A directed circular path in a network.

Redundant logic: A relationship that adds no useful precedence beyond existing paths.

Constraint: A date or scheduling rule imposed on an activity.

Lag: An intentional waiting or overlap interval in a relationship.

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

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

Total float: The allowable delay before an activity affects the calculated project completion date.

Topological ordering: An ordering of activities in which every predecessor appears before its successor.

Reachability: The ability to travel through directed relationships from one node to another.

Logic validation: The systematic examination of schedule structure and dependency meaning.

Review Questions

Short Answer Questions

1. What is the difference between an activity identifier and an activity description?
2. Define a merge point and a burst point.
3. Why are unexplained open ends a schedule-quality concern?
4. What is a directed loop in a project network?
5. Name two categories of project dependency.

Long Answer Questions

1. Explain how a project team should move from a work breakdown structure to a validated activity-on-node network.
2. Compare finish-to-start, start-to-start, finish-to-finish, and start-to-finish relationships, including situations in which each may be appropriate.
3. Discuss how inappropriate constraints can conceal missing or weak network logic.
4. Explain the role of graph algorithms in detecting cycles and disconnected activities, and identify what such algorithms cannot determine.
5. Evaluate the benefits and limitations of AI-assisted schedule logic validation.

Analytical / Application Questions

1. A project network contains A→B, B→C, and A→C, all with zero lag and finish-to-start relationships. Assess whether the direct A→C relationship is redundant and identify the assumptions that must be checked before removing it.
2. In a construction project, testing has predecessors from installation and operator training, while training has no successor after a link is accidentally deleted. Diagnose the network problem and explain how it may distort the critical path.
3. A manager imposes a fixed start date on an activity because the desired completion date is politically important, although no external event requires the start date. Explain how you would represent the management target and validate the underlying causal logic.

Multiple Choice Questions with Answers

Question 1

Which feature identifies a merge point in a project network?

A. One predecessor and several successors

B. Several predecessors and one successor

C. No predecessor and no successor

D. A circular path returning to the same activity

Correct Answer: B. Several predecessors and one successor

Question 2

What is the primary purpose of a unique activity identifier?

A. To determine the activity duration

B. To indicate the critical path automatically

C. To distinguish and trace the activity unambiguously

D. To replace the activity description

Correct Answer: C. To distinguish and trace the activity unambiguously

Question 3

Which relationship requires a predecessor to finish before its successor starts?

A. Finish-to-start

B. Start-to-start

C. Finish-to-finish

D. Start-to-finish

Correct Answer: A. Finish-to-start

Question 4

What is the principal problem with an unintended loop in a precedence network?

A. It always shortens the project duration

B. It prevents ordinary acyclic schedule calculations

C. It creates an additional legitimate milestone

D. It converts all relationships to finish-to-start

Correct Answer: B. It prevents ordinary acyclic schedule calculations

Question 5

In the worked software example, what is the calculated project duration?

A. 11 working days

B. 15 working days

C. 19 working days

D. 22 working days

Correct Answer: D. 22 working days

Question 6

Which situation is most likely to represent an open end requiring investigation?

A. The approved start milestone has no predecessor

B. The final completion milestone has no successor

C. An internal testing activity has no successor

D. A project finish activity has zero duration

Correct Answer: C. An internal testing activity has no successor

Question 7

Which statement best describes redundant logic?

A. A relationship that creates a circular path

B. A relationship that duplicates an effective precedence already imposed by another path

C. A relationship with a positive lag

D. A relationship between activities in different work packages

Correct Answer: B. A relationship that duplicates an effective precedence already imposed by another path

Question 8

If an activity has ES = 8 and LS = 11, what is its total float under the standard formula?

A. 3 time units

B. 8 time units

C. 11 time units

D. 19 time units

Correct Answer: A. 3 time units

Question 9

Why should a hard date constraint be reviewed during logic validation?

A. It always indicates an invalid activity

B. It may conceal missing causal relationships

C. It automatically creates a merge point

D. It eliminates the need for calendars

Correct Answer: B. It may conceal missing causal relationships

Question 10

What does a topological ordering demonstrate about a directed project network?

A. That every activity has the same duration

B. That every predecessor can be placed before its successor without a directed cycle

C. That all activities are on the critical path

D. That all constraints are contractual

Correct Answer: B. That every predecessor can be placed before its successor without a directed cycle