What are the four logical relationships in a network diagram?

Understanding the four logical relationships in a network diagram is one of the first steps toward building a project schedule that actually reflects how work happens. Project managers who skip this foundation often end up with timelines that look tidy on screen but collapse as soon as execution starts. The Precedence Diagramming Method, often shortened to PDM, defines how activities connect to one another through dependencies. In a PDM network diagram, boxes or rectangles represent activities, and arrows show the logical relationships between them. This Activity-On-Node technique is used by most project management software packages because it gives schedulers a clear, visual way to model task sequencing.

The four relationship types cover every possible way one task can depend on another. They are finish-to-start, finish-to-finish, start-to-start, and start-to-finish. Each one answers a specific question about whether the successor activity waits for the predecessor to start or to finish. While finish-to-start is by far the most common, the other three relationships matter in many real-world situations. Ignoring them forces schedulers to use awkward workarounds or artificial milestones that distort the true logic of the work.

What often surprises people new to scheduling is how much practical power sits inside these four small definitions. They are not just theoretical options. Choosing the wrong dependency type can create a schedule that looks valid in software but misrepresents how teams actually coordinate. Over the next sections, we will break down each relationship, explore common pitfalls, and connect the concept to broader project management frameworks and practical scenarios.

Summary Table: Four Logical Relationships in Network Diagrams

Key Concept	Summary
Activity-On-Node	Activity-on-node diagrams represent schedule logic as nodes connected by precedence arrows. Most project management software packages adopt AON because it provides an intuitive, unambiguous way to model task sequencing.
Dependency Direction	Experienced schedulers verify dependency direction before changing dates, since a reversed arrow can invert the logical sequence and produce a schedule that no longer reflects how work actually progresses.
Start-to-Start	Start-to-start dependencies are the correct choice when two activities must commence simultaneously due to shared resources or a common kickoff event. This representation avoids the distortion introduced by artificial milestones in finish-to-start logic.
Finish-to-Start	A finish-to-start relationship is drawn with an arrow from the predecessor's finish side to the successor's start side, indicating that the successor cannot begin until the predecessor completes.
PDM Benefits	The precedence diagramming method places activities in nodes and links them directly with precedence arrows, eliminating the need for dummy activities and other workarounds that complicated earlier methods.
Common Pitfalls	When dependency types are ignored, schedulers often fall back on artificial milestones, which mask the true sequence of work and weaken schedule integrity.
Practical Experimentation	Because PDM is straightforward to apply, project teams can test alternative dependency types and observe the immediate effect on network logic and the critical path.
Real-World Example	In practice, QA test design often cannot start until development has begun writing code, as the testing team first needs enough architectural detail to design meaningful test cases.

The Precedence Diagramming Method and Activity-On-Node Logic

The precedence diagramming method forms the backbone of modern project scheduling. It describes a technique where nodes represent activities and arrows indicate the logical relationships between them. Most project management software packages default to this approach because it is intuitive, flexible, and does not require dummy activities to show complex dependencies. The term Activity-On-Node comes directly from this node-and-arrow structure. In earlier arrow diagramming methods, activities often sat on arrows, which made certain relationships harder to model.

What often gets overlooked is that PDM is not just a drawing style. The arrows carry specific meaning about when a successor can start or finish relative to a predecessor. Getting this wrong changes the entire schedule logic. A seasoned scheduler will confirm the dependency direction before adjusting dates, because an arrow pointing the wrong way can create a schedule that appears valid but violates how work actually unfolds.

PDM also allows schedulers to apply lead and lag time to relationships. Lag inserts a delay between the predecessor and successor. Lead, sometimes called negative lag, accelerates the successor by overlapping it with the predecessor. These adjustments can be applied to any of the four logical relationships, though they are most often used with finish-to-start and start-to-start. Understanding this flexibility helps avoid creating artificial activities just to represent waiting time or overlap.

Defining Logical Relationships in a Network Diagram

A logical relationship in a network diagram describes the dependency between a predecessor activity and a successor activity. The predecessor controls some aspect of timing for the successor. The four relationship types differ based on whether the control point is the start or the finish of each activity. For example, finish-to-start means the successor starts only after the predecessor finishes. Start-to-start means the successor starts only after the predecessor starts, even if the work then continues in parallel.

This distinction matters more than it might first appear. A schedule is essentially a chain of commitments about timing. If the chain relies on the wrong control point, the schedule will send misleading signals to the team. For instance, if two activities must begin at the same time because they share a resource or a kickoff event, start-to-start captures that better than finish-to-start with an artificial milestone. Choosing the right relationship type keeps the network diagram honest.

How PDM Differs from Other Diagramming Approaches

Before PDM became standard, project schedulers often used the arrow diagramming method, also called Activity-On-Arrow. That approach placed activities on arrows and used nodes as events. It worked, but it required dummy activities to represent certain dependencies, which made diagrams cluttered. PDM eliminated that need by putting activities in nodes and letting arrows directly connect predecessor and successor boxes. This is why PDM is sometimes called Activity-On-Node.

The shift to PDM aligned well with the rise of scheduling software. Graphical user interfaces could easily display rectangular nodes with activity names, durations, and dates. Arrows could be drawn, deleted, and reassigned without restructuring the entire diagram. This ease of use made it possible for project teams to experiment with different dependency types and immediately see the impact on the schedule network.

Core Insights on PDM Logic

Node-and-arrow scheduling backbone

The precedence diagramming method represents activities as nodes and logical dependencies as arrows, establishing the standard structural backbone for contemporary project schedules.

Software default for scheduling

Project management tools default to PDM because its intuitive, flexible structure can model complex dependencies directly, eliminating the need for dummy activities.

Meaning encoded in arrows

Each dependency arrow in a PDM diagram defines the timing condition that governs when a successor can start or finish relative to its predecessor, making arrow direction a carrier of critical schedule logic.

Direction errors break logic

Reversing a dependency arrow can produce a schedule that appears logically valid yet contradicts the actual sequence of work, so schedulers must confirm arrow direction before modifying dates.

Avoiding artificial activities

PDM's flexibility allows planners to represent waiting periods or activity overlap directly through relationship logic, eliminating the need for artificial placeholder activities.

What Are the Four Logical Relationships in a Network Diagram?

The four logical relationships in a network diagram are finish-to-start, finish-to-finish, start-to-start, and start-to-finish. Each relationship defines a specific timing condition between two activities. Finish-to-start means the initiation of the successor activity depends upon the completion of the predecessor activity. Finish-to-finish means the completion of the successor activity depends upon the completion of the predecessor activity. Start-to-start means the initiation of the successor activity depends upon the initiation of the predecessor activity. Start-to-finish means the completion of the successor activity depends upon the initiation of the predecessor activity.

These definitions are precise, but they can feel abstract without examples. Think of finish-to-start as the default handoff from one task to the next. Think of finish-to-finish as two tasks that must wrap up at the same time. Start-to-start describes tasks that launch together but then run independently. Start-to-finish is the odd one, where the successor cannot finish until the predecessor starts, which often surprises people because it sounds backwards.

Most project schedules are built predominantly from finish-to-start relationships. The other three appear when specific coordination constraints exist. A strong scheduler recognizes when a non-default relationship is needed and does not force every dependency into finish-to-start just because it is familiar. That forced modeling often creates false constraints and extra activities that make the schedule harder to maintain.

Finish-to-Start: The Default Dependency in Project Schedules

The finish-to-start relationship is the most commonly used type of precedence relationship. It states that the successor activity cannot start until the predecessor activity has finished. This is the natural handoff in sequential work, such as when you cannot paint a wall until the drywall is installed and taped. In a network diagram, the arrow points from the finish of the predecessor to the start of the successor.

Because finish-to-start is so dominant, many schedulers fall into the habit of using it for everything. That is not always wrong, but it can hide parallel work and resource handoffs. When two activities overlap in reality, modeling them with a pure finish-to-start relationship forces the successor to wait artificially. The schedule may then show longer duration than necessary, or the team may ignore the schedule logic because it does not match how they actually work.

Finish-to-start relationships work best when there is a clear deliverable or approval that gates the next activity. For example, you cannot begin testing a software build until the build is complete and deployed to the test environment. The predecessor output is the condition for starting the successor. This one-directional handoff makes finish-to-start easy to understand and explain to stakeholders.

Practical Examples of Finish-to-Start Dependencies

Construction projects are full of finish-to-start logic. Foundation curing must finish before framing begins. Rough electrical inspection must finish before insulation can be installed. Each predecessor produces a physical state that the successor needs. The same pattern appears in document development, where drafting must finish before editing starts, and editing must finish before final approval starts.

In software projects, finish-to-start often appears between development and code review. The developer finishes the code change and then the reviewer starts. It also appears between user acceptance testing and release approval. These gates create a clear sequence and make it easy to trace the critical path through the network diagram.

Finish-to-Start in a Network Diagram

When you look at a finish-to-start relationship in a network diagram, the arrow connects the right edge of the predecessor node to the left edge of the successor node. That visual convention matches the concept of time moving from left to right, with the predecessor finishing before the successor starts. Software tools often label the arrow with FS or finish-to-start so the dependency type is clear at a glance.

One common mistake is forgetting that finish-to-start does not imply zero gap between activities. A successor may start immediately after the predecessor finishes, or it may start days or weeks later due to resource availability or external constraints. The dependency only sets the minimum condition. Actual start dates can be later, but never earlier, unless lead time is applied.

Core Insights on Sequential Handoffs

Natural sequential progression dependency

Finish-to-start captures the strictest handoff logic in which a successor activity remains blocked until the predecessor is fully complete, for example wall painting cannot start before drywall installation is finished.

Risk of masking parallel work

Where activities do overlap in practice, imposing a strict finish-to-start link creates artificial delay for the successor, extends the overall schedule, and encourages teams to ignore dependency logic that conflicts with how work actually proceeds.

Best fit for gated deliverables

This dependency type delivers the most value when a tangible deliverable or formal approval gates the transition to the next activity, because the one-way flow becomes straightforward for stakeholders to understand and monitor.

Finish-to-Finish: Coordinating Completion Dates

The finish-to-finish dependency means the completion of the successor activity depends upon the completion of the predecessor activity. In other words, the successor cannot finish until the predecessor has finished. This relationship does not say both activities start together, only that their finish points are linked. It often appears when two work streams must complete at the same time to allow a combined deliverable or release.

If you have ever watched two activities that must finish together but start at different times, you have felt this dependency intuitively. A documentation team might start writing user manuals early in a project, but the manual cannot be finalized until the software development finishes because final screens and features must be reflected. Documentation starts long before development ends, but it finishes only after development finishes.

Finish-to-finish can be tricky because it allows the successor to start before the predecessor finishes. That overlap is exactly what some schedulers need. It also means the successor may have a long duration that stretches to match the predecessor's end date. Without care, this can create float and critical path surprises if the predecessor slips.

Finish-to-Finish in a Network Diagram

In a finish-to-finish relationship, the arrow connects the right edge of the predecessor node to the right edge of the successor node. This visual pattern tells the scheduler that both activities complete at the same moment, regardless of when they begin. The dependency type is often displayed as FF.

One common scenario is final inspection and punch list closure. Final inspection cannot finish until the punch list items are completed. The inspection may start earlier and run in parallel with repairs, but it cannot be marked complete until the last repair is done. The arrow from the punch list finish to the inspection finish captures this perfectly.

When Finish-to-Finish Works Best

Finish-to-finish works best when two deliverables must be integrated at the end of a phase or project. Think of a marketing campaign where the website content and the advertising copy must both be ready before launch day. The copywriting can start early, but it cannot finish until the website content team confirms the final messaging. The finish-to-finish relationship ensures the copywriting schedule does not close out prematurely.

It also works in quality assurance environments where test documentation cannot be finalized until testing is complete. The test script writing may start early, but the final version of the test scripts cannot be approved until the test execution results are known. Finish-to-finish captures that dependency without forcing the script writing to wait until testing begins.

Start-to-Start: Kicking Off Work in Parallel

The start-to-start relationship means the initiation of the successor activity depends upon the initiation of the predecessor activity. The successor cannot start until the predecessor has started. This is useful when two activities need to launch at the same time but then proceed independently. For example, you might not begin the quality assurance test design until the development team has started writing code, because the QA team needs a basic understanding of the architecture before designing tests.

Start-to-start does not mean the activities finish together. One may finish long before the other. It only coordinates the beginning. That makes it valuable for activities that share a kickoff event or a resource that becomes available at the same time. Once both are underway, their paths can diverge.

Many schedulers use start-to-start with a lag to model a delay between the start of the predecessor and the start of the successor. For instance, coding must start before code review can start, but the review should not start until the first batch of code is ready. The dependency is start-to-start with a lag of a few days, allowing the developer to get ahead before the reviewer begins.

Start-to-Start in a Network Diagram

In a start-to-start relationship, the arrow connects the left edge of the predecessor node to the left edge of the successor node. This drawing signal tells the scheduler that both activities begin together, even if their durations differ. Software tools usually label this dependency as SS.

Consider a project where the procurement team must start ordering long-lead materials at the same time the engineering team begins detailed design. Engineering does not need the materials to arrive immediately, but procurement cannot place orders until engineering starts because specifications are needed. The start-to-start link ensures both activities launch in coordination without forcing procurement to wait until design finishes.

Using Start-to-Start with Lag and Lead

Start-to-start relationships often include lag time. A common example is the start of concrete placement and the start of curing. Concrete placement must start before curing can begin, but curing starts a few hours after placement starts. The relationship is start-to-start with a lag equal to the time needed for the first pour to be in place.

Lead time can also apply to start-to-start relationships, though it is used less frequently. If a successor can begin before the predecessor starts because some preparatory work is already done, lead allows that overlap. The scheduler must be careful, because lead time in a start-to-start dependency can create a scenario where the successor starts before the predecessor's triggering event, which may violate the real-world condition.

Core Insights on Start-to-Start Links

Dependency definition

In a start-to-start dependency, the successor activity can commence as soon as the predecessor activity starts, rather than waiting for its completion.

Parallel work enabler

This dependency type is ideal when activities share a common launch point but then progress independently, allowing each workstream to advance without waiting for the other to finish.

Lag for real-world timing

Schedulers often introduce a lag to start-to-start links to model a planned delay, such as starting code review a few days after coding begins and the first code batch is ready.

Coordination without waiting

With a start-to-start link, procurement can initiate long-lead material orders at the same moment engineering starts detailed design, keeping both workstreams in sync without waiting for design completion.

Lead time caution

Project schedulers must manage lead time carefully, since excessive lag in a start-to-start dependency can cause the successor activity to start before its triggering event, potentially violating real-world constraints.

Start-to-Finish: The Rare Reverse Logic

The start-to-finish relationship is the least understood of the four logical relationships. It says the completion of the successor activity depends upon the initiation of the predecessor activity. In plain terms, the successor cannot finish until the predecessor starts. This sounds backwards because most people expect the predecessor to finish before the successor can finish. But start-to-finish means the successor needs some input or trigger from the predecessor's start, not its completion.

Honestly, start-to-finish can feel like a scheduling quirk, but it does show up in rare handoff situations. One classic example is shift work in a 24-hour operation. The night shift cannot finish until the day shift starts. The day shift starting is the trigger that allows the night shift to close out its log and hand over responsibilities. Without the day shift starting, the night shift cannot end.

Another example involves a system cutover. The old system cannot be shut down until the new system starts. The start of the new system is the condition that allows the old system's operation to finish. This dependency is start-to-finish from the new system start to the old system finish. It is rare, but when it appears, it models a real constraint that other relationship types cannot capture.

Start-to-Finish in a Network Diagram

In a start-to-finish relationship, the arrow connects the left edge of the predecessor node to the right edge of the successor node. Visually, this creates an unusual backward-leaning pattern that can confuse people reading the diagram. Software tools label it as SF. Because it is so rare, many schedulers have never used it in a real project.

The arrow direction is counterintuitive. Most dependency arrows flow from the predecessor's finish to the successor's start. Start-to-finish flows from the predecessor's start to the successor's finish, which makes it look like the dependency runs backwards in time. But the logic is valid. The successor is already in progress and needs the predecessor to start before the successor can complete.

Why Start-to-Finish Confuses People

Start-to-finish confuses people because it reverses the usual mental model. Most project work follows a pattern where finishing one thing enables starting the next thing. Start-to-finish breaks that pattern by saying the start of one thing enables the finish of another. This is uncommon in typical project environments, so it is rarely taught with strong examples.

The confusion also comes from the labels themselves. The first word refers to the predecessor's state, and the second word refers to the successor's state. So start-to-finish means predecessor starts, successor finishes. Once a person internalizes that convention, the relationship becomes easier to understand. But until then, it tends to feel like a mistake or an inverted arrow.

How Project Management Software Handles the Four Logical Relationships

Modern project management software dependencies rely heavily on PDM relationship types. Most scheduling tools allow the scheduler to select between finish-to-start, finish-to-finish, start-to-start, and start-to-finish when creating a link between two activities. The tool then calculates the successor's start and finish dates based on the selected relationship, the predecessor's dates, and any lag or lead applied.

In Microsoft Project, Oracle Primavera, and many other tools, the default dependency type is finish-to-start. That default mirrors the reality that sequential handoffs are the most common pattern in project work. Schedulers can change the dependency type by editing the link properties, and the tool will recalculate the network automatically. This capability makes it easy to experiment with different relationship types and see the effect on the schedule.

Software also displays these dependencies in the network diagram view. Arrows are labeled with FS, FF, SS, or SF to indicate the relationship type. This visual labeling helps schedulers audit the logic quickly. In complex schedules with hundreds of activities, those labels can be essential for spotting a mistakenly placed start-to-finish relationship or an overused finish-to-start dependency that should have been a start-to-start with lag.

Setting Dependency Types in Scheduling Tools

Most scheduling tools allow you to set the dependency type in a task link dialogue box. You select the predecessor, the successor, the relationship type, and any lag or lead. The tool then creates the arrow and adjusts dates automatically. Some tools also offer a graphical interface where you can drag an arrow from one side of a node to another, and the relationship type is inferred from where you start and end the drag.

That drag-and-drop convenience can cause errors. If you drag from the left edge of the predecessor to the right edge of the successor, you create a start-to-finish relationship, often by accident. Many schedulers have unknowingly created start-to-finish links when they intended a finish-to-start. Always verify the relationship type after using a graphical editor, especially if the schedule suddenly shows odd date shifts.

Network Diagram Views and Relationship Arrows

The network diagram view in project management software shows every activity as a node, usually a rectangle with task information inside. Arrows connect the nodes, and the side of the node where the arrow originates tells you the dependency type. An arrow from the right side of one node to the left side of another indicates finish-to-start. An arrow from right side to right side indicates finish-to-finish. From left side to left side indicates start-to-start. From left side to right side indicates start-to-finish.

Reading these arrows becomes second nature with practice. But when a schedule is printed or exported to a PDF, the labels may shrink and become hard to read. Color coding or filtering by dependency type can help. Some schedulers run a filter to show only non-finish-to-start relationships, because those are the ones most likely to be entered incorrectly.

Core Insights on Relationship Handling

Default finish-to-start dependency

Most scheduling platforms, including Microsoft Project and Oracle Primavera, default to finish-to-start because sequential handoffs represent the most common dependency pattern in real project workflows.

Automatic date recalculation

Changing the dependency type through link properties triggers an automatic recalculation of the successor activity's dates based on the relationship type, predecessor dates, and any applied lag or lead.

Visual relationship labels

Network diagram arrows are labeled with FS, FF, SS, or SF, enabling schedulers to quickly identify misapplied start-to-finish links or excessive finish-to-start dependencies across large schedules.

Configurable link properties

Schedulers can assign dependency types through a task link dialog box, providing a straightforward way to compare relationships and instantly evaluate their impact on successor dates and the overall schedule.

Common Pitfalls and Misconceptions with PDM Relationships

Many logical relationship mistakes in project schedules stem from a few recurring misunderstandings. The first is assuming every dependency should be finish-to-start. This habit creates artificial constraints that force sequential work when parallel work is possible. It also inflates the schedule duration and can push a critical path through activities that are not truly gating each other. Schedulers should ask whether the successor can start before the predecessor finishes. If the answer is yes, finish-to-start is probably not the best model.

The second common mistake is confusing finish-to-finish with start-to-start. Both allow overlap, but they coordinate different ends of the activities. Finish-to-finish links the completion points. Start-to-start links the initiation points. If a team needs to finish together, finish-to-finish is correct. If a team needs to begin together, start-to-start is correct. Using the wrong one can silently distort the schedule logic and cause late starts or finishes that nobody understands.

A third pitfall involves lag and lead. Many schedulers apply lag to a finish-to-start relationship without realizing that they are effectively modeling a start-to-start or finish-to-finish relationship with extra steps. Lag can be useful, but it sometimes masks an underlying parallel dependency that should be modeled directly. Overusing lag makes the schedule harder to read and audit because the reason for the delay sits in a link property rather than in an explicit activity or milestone.

Confusing Finish-to-Start with Finish-to-Finish

Finish-to-start and finish-to-finish are often confused because both involve the finish of the predecessor. The key difference is what the successor depends on. In finish-to-start, the successor depends on the predecessor finishing before the successor starts. In finish-to-finish, the successor depends on the predecessor finishing before the successor can finish. The successor may start earlier in finish-to-finish.

A practical test is to ask what would happen if the predecessor slipped. In a finish-to-start relationship, the successor's start date would be delayed, which may or may not affect its finish date depending on float. In a finish-to-finish relationship, the successor's finish date would be delayed directly, even if its start date remains unchanged. That difference is crucial for critical path analysis.

Overusing Start-to-Finish Without a Clear Handoff

Start-to-finish is so rare that many schedulers avoid it altogether. When they do use it, they often do so incorrectly because the real dependency is actually a finish-to-start with a different activity ordering. If you find yourself creating multiple start-to-finish relationships, step back and ask whether the activities have been defined in the right order. Sometimes the issue is that the predecessor and successor labels should be swapped.

Start-to-finish should only be used when the successor genuinely cannot finish until the predecessor starts. Shift handoffs and system cutovers are the clearest examples. If the situation does not involve one activity starting to release another activity from ongoing work, then start-to-finish is probably not the right model.

Ignoring Lag and Lead Implications

Lag and lead modify the timing of any relationship. Lag delays the successor. Lead accelerates the successor by allowing it to overlap with the predecessor. Schedulers sometimes ignore the fact that lead time on a finish-to-start relationship is essentially a start-to-start relationship with a delayed predecessor. That can create date calculations that are hard to explain to team members.

It is usually better to model overlap explicitly as a start-to-start dependency with lag rather than as a finish-to-start dependency with lead. The explicit version makes the logic visible in the diagram. The lead version hides the overlap inside a link property that may not be printed or reviewed. Both approaches can produce the same dates, but the explicit version is more maintainable.

Logical Relationships in PMBOK and Other Frameworks

Precedence relationships in project management frameworks appear under schedule management. In the PMBOK Guide, the Precedence Diagramming Method is described as a technique for developing the schedule model. It belongs to the Planning Process Group and the Schedule Management knowledge area, where activities are sequenced and then linked with dependencies. The four relationship types are identified there as the standard options for connecting activities.

The PMBOK Guide does not prescribe which relationship to use in every case. It presents the four types and leaves the choice to the project team based on the nature of the work. Most practitioners learn finish-to-start as the default and then add the other types as needed. The key requirement is that the schedule model reflects the actual logic of the work, not just convenient dates.

PRINCE2 approaches planning differently, with a stronger focus on product-based planning and product breakdown structures. Dependencies still exist, but they are often captured in product flow diagrams rather than activity network diagrams. The logical relationships between activities remain relevant during scheduling, but PRINCE2 practitioners may think of them more in terms of product dependencies and handoffs. Agile environments also handle dependencies differently, often through visual boards, sprint planning, and continuous reprioritization rather than fixed network logic.

PMBOK Schedule Management and PDM

In PMBOK terms, PDM is part of the Sequence Activities process. This process takes the defined activities and identifies the order in which they must occur. The four logical relationships are the building blocks of that sequencing. After relationships are set, the Develop Schedule process uses the network diagram to calculate start and finish dates, critical path, and float. PDM sits at the heart of that calculation engine.

The PMBOK Guide also discusses dependencies as mandatory, discretionary, external, or internal. Those categories describe why a dependency exists, while the four logical relationships describe how the timing is linked. A mandatory dependency might be expressed as finish-to-start, while a discretionary dependency might be expressed as start-to-start with lag. Both dimensions matter for building a realistic schedule.

Agile and Hybrid Views on Dependencies

Agile teams often avoid heavy network diagrams because work is broken into small increments and reprioritized frequently. Dependencies still exist, but they are more often managed through backlog ordering, team coordination, and service-level expectations. A Scrum team might note that a user story cannot be demonstrated until an API endpoint is available. That is a finish-to-start concept, but it is not modeled in a network diagram.

Hybrid projects blend these approaches. A team may use a high-level milestone plan with finish-to-start relationships for major phases, while day-to-day work is managed on a Kanban board. The logical relationships still matter at the milestone level because they set the boundaries for when major deliverables can be released. Ignoring them entirely leads to unrealistic phase-end dates.

PRINCE2 and Product-Based Planning Contrast

PRINCE2 does not center its planning method on PDM the way traditional PMBOK-based scheduling often does. Instead, PRINCE2 focuses on products, their quality criteria, and the sequence in which products are created. A product flow diagram shows which products must be complete before others can start, which is conceptually similar to a finish-to-start relationship. The difference is that PRINCE2 emphasizes the product rather than the activity.

This product-focused view can help avoid one common PDM pitfall. When schedulers model activities without first identifying deliverables, they sometimes create dependencies based on who is doing the work rather than what output is required. PRINCE2 reminds teams to anchor dependencies in deliverables. PDM then expresses those deliverable-based dependencies as logical relationships in the schedule network.

Key Insights on Dependency Logic

PMBOK precedence diagramming method

The PMBOK Guide defines the Precedence Diagramming Method as a Planning Process Group technique within Schedule Management, allowing project teams to sequence activities through four distinct dependency types.

Schedule reflects actual work logic

The schedule model must faithfully reproduce the actual sequence and constraints of the work, rather than being reverse-engineered to fit predetermined target dates.

PRINCE2 product-based planning

PRINCE2 places product-based planning and product breakdown structures at its core, treating logical relationships as dependencies and handoffs between deliverables.

Agile and hybrid dependency handling

Agile teams surface dependencies through visual boards, sprint planning, and frequent reprioritization, and they often combine a high-level milestone plan with finish-to-start relationships for major phases while managing daily work on a Kanban board.

Develop Schedule process outputs

After the logical relationships are established, the Develop Schedule process analyses the network diagram to calculate start and finish dates, identify the critical path, and determine available float across the project.

Practical Scenarios and Worked Examples

Network diagram examples help make the four relationship types concrete. Consider a construction project where the foundation must be poured, inspected, and then framed. The foundation pour must finish before the inspection starts, so that is finish-to-start. The inspection must finish before framing starts, also finish-to-start. But the framing team might start some layout work before the foundation inspection finishes, as long as the foundation is poured. That arrangement could be modeled as start-to-start with lag between foundation pour and framing layout.

Now add a finish-to-finish example. The final site cleanup cannot finish until the landscaping contractor finishes installing plants and mulch. Landscaping starts early, while cleanup starts later, but cleanup cannot be marked complete until landscaping is done. The dependency from landscaping finish to cleanup finish is finish-to-finish.

In a software release project, the development team starts writing code. The technical writer starts drafting release notes a few days after development begins. That is start-to-start with lag. The release notes cannot be finalized until the development team finishes the final build, which is finish-to-finish from development finish to release notes finish. The deployment to production cannot start until the final build finishes, which is finish-to-start. These combinations create a realistic network diagram that shows both parallel work and sequential gates.

Construction Example with Multiple Dependencies

A construction schedule for a small commercial building might have the following dependencies. Site grading must finish before foundation excavation starts, finish-to-start. Foundation excavation must start before the concrete crew can begin setting forms, start-to-start with a small lag. Form setting must finish before concrete pouring can start, finish-to-start. Concrete pouring must finish before framing can start, finish-to-start, but the framing materials delivery must start when concrete pouring starts so materials arrive on time, start-to-start with a longer lag.

Framing must finish before the roof is weatherproof, but the roof underlayment can start as soon as the first section of framing is up, start-to-start with lag. The electrical rough-in cannot finish until the drywall installation finishes, because the electricians need to pull final wires through walls, finish-to-finish. The final building inspection cannot start until all subsystem inspections finish, which is a finish-to-start from the last subsystem inspection to the final inspection.

This combination of relationship types shows how a real project schedule is rarely one long chain of finish-to-start links. Overlaps and shared completion points are natural. Modeling them explicitly keeps the schedule realistic and helps identify which activities truly drive the end date.

Software Development Example with Parallel Work

A software project often includes backend development, frontend development, database migration, and security review. Backend development must start before integration testing can start, start-to-start with lag to allow the first API endpoints to be built. Frontend development must finish at the same time as backend development so the integration environment can be assembled, finish-to-finish. The database migration cannot start until the backend schema design is firmed up, finish-to-start from schema design finish to migration start.

Security review cannot finish until the final build is complete, finish-to-finish. The go-live activity cannot start until security review finishes and the final build is deployed, finish-to-start from both. These relationships prevent the schedule from showing security review finishing early while development is still changing the code, and they keep go-live from starting before the system is ready.

In this example, the start-to-finish relationship might appear if the old system cannot be shut down until the new system starts. That is a cutover dependency. Most software teams never need start-to-finish, but it can be the right tool for a big-bang migration where two systems run in parallel for a short period before the old one is retired.

Looking at Logical Relationships from a Business Value Perspective

Business value-oriented project management adds a layer of value thinking to schedule modeling. While traditional PDM focuses on activity logic, value-oriented approaches remind teams that a network diagram is only useful if it supports delivery of value. A schedule can be logically perfect and still deliver the wrong thing if the underlying activity decomposition is poor. In that sense, the logical relationships are downstream of scope definition and value identification.

Business Value-Oriented Project Management also treats scope uncertainty differently. It uses a five-level scope scale from definite to unlikely, where scope changes are seen as user feedback rather than failure. That perspective affects network diagrams because activities with uncertain scope may not have clean finish-to-start boundaries. A team might use start-to-start relationships with lag to allow discovery work to begin while scope details are still emerging, rather than forcing a rigid finish-to-start gate that locks the schedule prematurely.

The same approach warns against over-reliance on work breakdown structure accuracy. A network diagram built from a poorly decomposed WBS will inherit flawed dependencies. Relational effort points and transparent scope discussions can reduce that risk. In practice, this means validating the activity list before drawing arrows, because the best dependency modeling cannot fix an activity that should not exist or is defined at the wrong level.

Value Delivery and Schedule Logic

Value delivery often depends on finishing certain activities together, not just sequentially. A product launch may require marketing, sales enablement, and technical documentation to finish together. That is a natural finish-to-finish situation. If the schedule forces those work streams into finish-to-start chains, the launch date may slip artificially. Value-oriented schedulers look for these shared completion points early and model them directly.

Similarly, start-to-start relationships support value delivery by enabling fast feedback. Two teams can start working in parallel as soon as the initial handoff occurs, even if one team will finish later. This keeps the overall value stream moving instead of waiting for a large batch to be fully complete before the next group starts. That is consistent with lean and Agile-inspired thinking, though PDM remains the underlying notation.

Uncertainty and Scope in Network Diagrams

Network diagrams often assume activities are known and stable. Real projects rarely work that way. Scope uncertainty can make finish-to-start dependencies too rigid. If the successor cannot start until the predecessor finishes, but the predecessor's scope is likely to change, then the successor may be delayed repeatedly. Some teams respond by using start-to-start relationships with lag, allowing the successor to begin on a stable subset of the predecessor's output while the rest is still being refined.

This practice connects to the idea of treating scope change as feedback. Instead of freezing the network diagram at baseline, the team adjusts dependencies as new information arrives. The four logical relationships remain the same, but the specific links between activities may shift. A flexible scheduling mindset recognizes that the network diagram is a model, not a contract carved in stone.

Core Insights on Value Scheduling

Value drives schedule design

A value-oriented project schedule treats network diagrams as meaningful only when they directly enable business value delivery, never as an end in themselves.

Scope precedes logical relationships

Because logical dependencies depend on a clear scope and value definition, even a logically flawless schedule will deliver the wrong outcome if the underlying activities are poorly decomposed.

Uncertainty calls for flexible logic

When scope is uncertain, activities rarely have clean finish-to-start boundaries; teams therefore use start-to-start relationships with lag to permit discovery work while scope details are still emerging.

Validate activities before linking

Teams must confirm that every activity in the list is necessary and appropriately scoped before drawing dependencies, since even the most sophisticated dependency modeling cannot compensate for an activity that should not exist or is defined at the wrong level.

Finish-to-finish keeps value flowing

For deliverables like a product launch that depend on marketing, sales enablement, and technical documentation finishing at the same time, finish-to-finish relationships sustain the flow of value and prevent the delays caused by large batch handoffs.

Putting the Four Logical Relationships to Work

Applying logical relationships effectively requires more than knowing the four definitions. It requires a habit of questioning the nature of each dependency before entering it into the schedule software. Ask whether the successor waits for the predecessor's start or finish. Ask whether two activities must begin together or end together. Ask whether the relationship is mandatory or merely convenient. These questions lead to a more accurate network diagram and a more defensible critical path.

One practical workflow is to sketch the high-level dependency map on paper or a whiteboard before entering activities into software. This step exposes parallel work and shared completion points that might otherwise be hidden in a list view. It also helps the team agree on the true handoffs. Once the sketch is agreed, transferring it into PDM relationships becomes mechanical.

During execution, review the dependency types as part of schedule updates. Team members may report that a finish-to-start link prevented them from starting earlier, or that a finish-to-finish link forced them to wait unnecessarily. Those reports are signals that the model needs adjustment. A schedule that evolves with reality is more valuable than one that stays internally consistent but detached from the work.

Reviewing Dependencies Before Baselining

Before baselining a schedule, run a filter to show all non-finish-to-start relationships. Review each one with the team. If a start-to-finish relationship appears, ask for the specific handoff scenario. If a finish-to-finish relationship has no clear shared completion event, consider whether it should be finish-to-start. This audit catches many modeling errors before they become embedded in the baseline.

Also check for missing finish-to-start links. Sometimes parallel activities should have a finish-to-start gate that is missing, allowing a successor to start before a critical predecessor finish. The baseline schedule should reflect all mandatory dependencies, even if the team plans to manage some of them informally. Missing links can hide risk and create an unrealistic critical path.

Maintaining Schedule Logic During Execution

As the project progresses, actual dates will differ from planned dates. Update the schedule to reflect those actuals and then examine how the logical relationships respond. A start-to-start relationship may no longer hold if the predecessor started late but the successor still started on time due to a workaround. That exception may be fine for one instance, but the schedule model should be corrected if the workaround is likely to persist.

Schedule maintenance also means watching for relationships that become redundant. An activity may have both a finish-to-start and a start-to-start link to the same successor. The more restrictive relationship will drive the dates, but the extra link can confuse future reviewers. Clean up redundant dependencies and keep the logic as simple as the real work allows.

Logical relationships are not just a technical detail buried in scheduling software. They encode how a team intends to coordinate work. When that coordination changes, the relationships should change too. Mastering the four types gives project managers a precise language for describing dependencies, and that precision pays off every time the schedule is updated, audited, or challenged.