Finish-to-Start Relationship

A finish-to-start relationship is a logical dependency between two project activities in which the start of a successor activity depends on the completion of a predecessor activity. The predecessor must reach its defined completion state before the successor can begin. This relationship is the most common dependency type in project scheduling and forms the backbone of critical path analysis. In precedence diagramming method notation, a finish-to-start link is drawn as an arrow from the finish point of the predecessor node to the start point of the successor node. Because of its intuitive logic, it often serves as the default connection when a project schedule is first constructed.

When a project manager records that task B has a finish-to-start relationship with task A, the statement is about sequencing, not about resource allocation or organizational authority. Completion in this context means the specific output, condition, or handoff required by task B is ready. It does not automatically imply that task A has been formally accepted, closed, or signed off. The dependency simply says that the successor cannot start until the predecessor has finished enough of its work to satisfy the defined entry condition. That distinction matters more in practice than many new project managers expect.

Finish-to-Start Relationship: Summary of Key Topics

What Is Finish-to-Start Relationship?

The definition of finish-to-start relationship in project management centres on the sequential logic that one activity cannot commence until another activity has finished. It is one of four precedence relationships described in the precedence diagramming method, alongside start-to-start, finish-to-finish, and start-to-finish. Among these, finish-to-start is used far more often because it reflects the natural order of many kinds of work. A successor could be a concrete pour that cannot begin until formwork is complete, or a training rollout that cannot start until the training materials have been produced. The relationship captures a hard or soft gate between two activities, depending on the underlying reason for the link.

This concept is sometimes called a finish-to-start dependency or an FS link. The abbreviation FS appears frequently in scheduling software, network diagrams, and project documents. In many tools, when a user drags a connector from one task to another, the software assigns a finish-to-start relationship by default. That default is helpful because it prevents accidental concurrency, but it also encourages schedule creators to overuse sequential links without questioning whether an overlap might be possible. A finish-to-start relationship is not inherently a rule about strict phase-gate management. It is a scheduling convention that should be chosen deliberately.

At its core, the finish-to-start relationship is a timing constraint between activities. It says nothing about who performs the work, how long either activity is estimated to take, or whether the predecessor and successor are part of the same deliverable. Those details are captured elsewhere in activity attributes, resource calendars, and the work breakdown structure. The relationship only tells the scheduler the order in which the two activities are allowed to occur. Understanding this narrow but vital role prevents the dependency from being overloaded with meaning it does not carry.

Essential Insights on Finish-to-Start Relationships

Core definition of the link

A finish-to-start relationship establishes that a successor activity cannot commence until the predecessor activity has been fully completed, creating a clear handoff point between tasks.

One of four precedence types

This dependency is one of four precedence relationships defined in the precedence diagramming method, alongside start-to-start, finish-to-finish, and start-to-finish, each modeling a distinct timing constraint between activities.

Most common scheduling dependency

Finish-to-start links are the predominant schedule dependency because they reflect the natural order of most project work, such as pouring concrete only after the formwork has been erected and secured.

Default setting in scheduling tools

Scheduling software typically applies a finish-to-start relationship by default when tasks are linked, which reduces the risk of unintended parallel work but can also produce overly conservative schedules by forcing sequential execution where some overlap might be safe.

Key Components and Characteristics of Finish-to-Start Relationships

The key components of finish-to-start relationships include a predecessor activity, a successor activity, a defined finish point, a defined start point, and any lag or lead that modifies the timing between them. The predecessor is the activity that must finish first, while the successor is the activity that waits for that completion. The finish point of the predecessor is usually defined by a measurable output, such as a tested module, an approved design, or an installed component. The start point of the successor is the moment work can begin because that output is available. Without clarity on these boundary conditions, the dependency can become ambiguous and difficult to manage.

Characteristics of a finish-to-start relationship include asymmetry and directionality. The dependency flows in one direction only, meaning that a delay in the predecessor has a predictable impact on the successor, but not the reverse. This directionality is what allows schedulers to trace paths through a network and calculate early start, early finish, late start, late finish, and float. In a simple two-activity chain, if the predecessor finishes late, the successor starts late unless it has some independent float. That causal chain is central to critical path analysis and to understanding how schedule risk propagates through a project.

The relationship can be further described by its origin. A finish-to-start link may be mandatory because the successor physically or legally cannot begin before the predecessor is complete. It may also be discretionary, reflecting a preferred sequence chosen by the team for convenience, quality, or risk management. It may be internal, involving activities within the project team, or external, involving activities controlled by outside parties such as regulators, vendors, or contractors. These descriptors are independent of the finish-to-start timing logic itself, but they shape how the dependency is evaluated and challenged during schedule reviews.

Lag and Lead in Finish-to-Start Dependencies

A finish-to-start relationship often includes a lag, which is a delay applied after the predecessor finishes before the successor can start. A typical example is waiting for concrete to cure after pouring before framing can begin. The curing time is expressed as a lag on a finish-to-start link. Lag does not change the fundamental finish-to-start logic, but it adds a fixed or variable waiting period that represents a real physical, contractual, or regulatory constraint. If the lag is greater than zero, the successor is still attempting to start only after the predecessor finishes, plus an additional delay.

A lead, sometimes called negative lag, allows a successor to start before a predecessor fully finishes. For instance, software developers might begin coding a module before the detailed design document is fully approved. In precedence diagramming, this can be modelled as a finish-to-start relationship with a lead. The formal dependency type remains finish-to-start, but the lead relaxes the clean finish-before-start boundary. Practitioners often observe that a finish-to-start link with a large lead behaves very much like a start-to-start relationship in the field, even though the software labels it differently. This is why clear documentation of leads and their justification is necessary.

Mandatory versus Discretionary Finish-to-Start Links

Mandatory finish-to-start links exist when a physical, legal, or contractual requirement prevents the successor from starting before the predecessor completes. A roof cannot be installed until the walls are up. A drug cannot be marketed until a regulatory approval is issued. These constraints are not optional and cannot be removed by rescheduling. Discretionary finish-to-start links, by contrast, represent a preferred order that the project team has chosen. A project might decide to finish the database design before starting the user interface build, even though both could theoretically proceed in parallel. Discretionary finish-to-start links are useful for reducing coordination complexity, but they should be reviewed because they often hide opportunities for schedule compression.

Finish-to-Start Relationship in PMBOK and PRINCE2

The finish-to-start relationship in PMBOK is formally recognized within the Schedule Management knowledge area, specifically during the Sequence Activities process. The PMBOK Guide lists sequence activities as the process that identifies and documents relationships among project activities. Inputs such as the activity list, milestone list, project scope statement, and enterprise environmental factors are used to determine dependencies. The precedence diagramming method is the primary tool for creating a project schedule network diagram, and finish-to-start is the most frequently used dependency type in that method. The resulting network diagram becomes an input to the Estimate Activity Durations and Develop Schedule processes.

Within the PMBOK framework, finish-to-start dependencies are not simply drawn. They are determined through dependency determination analysis, which classifies each link as mandatory or discretionary and internal or external. Leads and lags are then applied as needed. This analysis ensures that the schedule reflects not just technical constraints but also the chosen strategy for how work will be carried out. The finish-to-start relationship is also central to the critical path method. The longest path through the network is often formed by a chain of finish-to-start links, and the total float of each activity depends on the logical relationships that connect it to the rest of the schedule.

PRINCE2 approaches dependencies through product-based planning rather than activity-first scheduling. The product breakdown structure and product flow diagram identify which products must exist before others can be created. When product flow is translated into activity dependencies, finish-to-start relationships naturally emerge as the most common logic. PRINCE2 does not prescribe a specific notation for activity dependencies, but its Plans theme requires that dependencies between products and activities be identified and managed. A finish-to-start link in a PRINCE2 plan usually represents a product handoff or a management stage boundary where one set of work must be completed before the next can begin.

A business value-oriented view of finish-to-start dependencies treats each link as a handoff of value, not just a timing rule. In Business Value-Oriented Project Management, a finish-to-start relationship is considered meaningful only if the predecessor's output is actually needed as the successor's input and if that output meets the agreed quality threshold. Otherwise the dependency may be creating unnecessary waiting time. This perspective aligns with the broader principle that schedule logic should serve value delivery, not merely satisfy a planning convention.

Key Takeaways on Finish-to-Start Dependencies

PMBOK Sequence Activities Process

The PMBOK Guide formally treats finish-to-start relationships within the Schedule Management knowledge area through the Sequence Activities process, which identifies and documents the logical dependencies among project activities.

Inputs and Precedence Diagramming

The activity list, milestone list, project scope statement, and enterprise environmental factors provide the key inputs for dependency determination, and the precedence diagramming method is the primary technique used to construct the schedule network diagram.

Mandatory Versus Discretionary Dependencies

Dependency determination analysis categorizes each finish-to-start relationship as mandatory or discretionary and internal or external, helping the schedule account for both hard technical constraints and the project team's chosen execution strategy.

Critical Path and Total Float

Because chains of finish-to-start dependencies frequently define the longest path through the network, an activity's total float is determined by how its logical relationships connect it to the broader schedule.

PRINCE2 and Value-Oriented Views

PRINCE2 does not mandate a specific dependency notation but still requires dependencies between products and activities to be managed within its Plans theme, while value-oriented project management treats a finish-to-start link as meaningful only when the predecessor's output is genuinely needed and meets the agreed quality threshold.

Finish-to-Start in Agile and Hybrid Environments

The role of finish-to-start in agile projects is often less visible because agile approaches avoid phase-gated life cycles. However, finish-to-start relationships still appear at the level of individual tasks, acceptance criteria, and workflow states. A developer cannot demo a finished feature until the underlying code has been written. A tester cannot begin formal acceptance testing until a build is ready for test. These are finish-to-start constraints that exist inside iterations and on kanban boards even when the overall project is not planned as a sequential waterfall. Agile teams manage these micro-dependencies through daily coordination rather than detailed network diagrams.

In hybrid environments, finish-to-start relationships frequently appear at the boundary between predictive and adaptive work. A predictive procurement process might need to finish before an agile development team can start working with the purchased component. Or an agile discovery phase may need to complete its primary experiments before a predictive business case can be finalized. Hybrid governance often introduces finish-to-start gates at stage transitions while allowing considerable freedom within each stage. The challenge is to avoid imposing too many hard finish-to-start links between agile work packages, because that can reintroduce the same rigidity that agile methods were meant to reduce.

Agile teams also use the concept of a definition of ready, which acts as a softer version of a finish-to-start entry condition. A backlog item is ready for development only after its acceptance criteria are clear and its dependencies are satisfied. When a dependency is hard and truly finish-to-start, the item may be blocked until the predecessor completes. This is a practical manifestation of the same sequencing logic, managed through kanban blockers and dependency boards. The finish-to-start relationship does not disappear in agile; it becomes a local, visible, and collaboratively managed constraint instead of a static link in a baseline schedule.

Purpose and Importance in Project Scheduling

The importance of finish-to-start dependencies lies in their ability to reveal the true sequence of work and the consequences of delay. A schedule is not a collection of independent tasks; it is a network of dependencies that determines when each activity can occur. Finish-to-start links define which activities must come before others and therefore shape the project timeline. When these links are accurate, the critical path emerges clearly and the schedule can be used to make reliable trade-off decisions. When they are inaccurate, the schedule becomes an optimistic or pessimistic fiction that misleads sponsorship and demoralizes the team.

Finish-to-start relationships serve several purposes. They communicate handoff conditions between people or teams. They help prevent two activities from starting before their prerequisites are met, reducing rework and coordination failures. They provide the logical basis for calculating early and late dates, float, and schedule risk. They also make dependencies transparent for stakeholders who need to understand why a project cannot simply be accelerated by starting everything at once. This transparency is especially important during schedule reviews, audit trails, and change control discussions.

The relationship also supports resource smoothing and leveling. By knowing which activities are logically constrained by finish-to-start links, a project manager can identify where resources can be applied in parallel and where they cannot. If a succession of finish-to-start links creates a long chain of dependent work, adding more people to a single activity may not shorten the overall timeline if that activity is already on the critical path with no float. The dependency structure, more than individual productivity, often determines the shortest achievable duration. Recognizing this is a key step in moving from task-level management to system-level schedule management.

Key Takeaways on Finish-to-Start Dependencies

Schedules Are Dependency Networks

A schedule functions as an interconnected network of dependencies rather than a loose collection of independent tasks, and this structure is what determines when each activity can actually occur.

Links Shape the Timeline

Finish-to-start relationships establish which activities must be completed before others can begin, and that logical dependency directly determines the overall project timeline.

Accuracy Reveals the Critical Path

Accurate finish-to-start dependencies reveal the critical path and give project leaders a reliable foundation for making decisions about time, cost, and resource allocation.

Bad Links Mislead Stakeholders

Inaccurate dependencies turn the schedule into an optimistic or pessimistic distortion that misleads sponsors and erodes the project team's confidence.

Transparency Supports Reviews and Control

Visible dependencies give stakeholders a clear explanation of why work cannot simply be accelerated by starting all activities at once, which is especially important during schedule reviews, audits, and change control discussions.

Finish-to-Start Relationship vs Other Dependency Types

Comparing finish-to-start vs start-to-start dependencies highlights a common scheduling trade-off between sequential and concurrent work. In a start-to-start relationship, a successor can begin when a predecessor begins, allowing activities to run in parallel. A finish-to-start relationship prevents that parallelism because the successor waits for the predecessor to complete. Start-to-start is often used when later activities can make progress based on early outputs of earlier activities, such as when testing scripts can be written while the software design is still evolving. Finish-to-start is preferred when the successor truly cannot add value until the predecessor has achieved a stable handoff state.

Finish-to-finish dependencies require that two activities complete at the same time or that one cannot finish before another finishes. They are common in situations involving shared documentation or coordinated delivery. For example, a technical manual cannot finish before the final product configuration is frozen. Start-to-finish dependencies are the rarest and least intuitive. They mean that a successor cannot finish until a predecessor has started. A classic example is a security guard shift that cannot end until the next guard has started. This schedule logic is uncommon in most project environments and often confuses stakeholders when it appears in network diagrams.

The distinction matters because different dependency types create different schedule dynamics. Finish-to-start links create sequential chains and are the main driver of project duration. Start-to-start links create overlap and can shorten duration but may increase coordination risk. Finish-to-finish links align completion dates but do not by themselves determine when work begins. Start-to-finish links are usually too unusual to use without a specific operational reason. In practice, many schedules can be built almost entirely from finish-to-start relationships with selective leads, lags, and start-to-start overlaps where justified. Choosing the right type is a matter of matching the dependency to the actual handoff condition.

Common Challenges and Misconceptions

Common misconceptions about finish-to-start relationships often stem from treating every sequential link as a mandatory, physical constraint. In reality, many finish-to-start links are discretionary choices made for convenience or risk avoidance. A project manager may link design to development with a finish-to-start relationship because it feels safer, even though development could begin on some modules while design is still finishing others. This over-sequencing creates artificial waiting time and can inflate the schedule without adding value. Reviewing each finish-to-start link with the question "Is this truly required, or is it a preference?" frequently reveals schedule compression opportunities.

Another challenge is the assumption that the finish-to-start relationship automatically includes a zero lag. Project teams sometimes talk about a finish-to-start link as if the successor starts the instant the predecessor finishes. In the real world, there are often natural delays for information transfer, resource availability, approval wait times, or physical processes like curing and cooling. These delays should be explicitly modelled as lags or as separate activities, rather than hidden inside inflated activity durations. Hidden lag reduces schedule transparency and makes it harder to understand why the project is taking longer than planned.

Overly rigid finish-to-start chains can also become a problem in fast-moving or uncertain environments. When a ten-activity chain is linked entirely with finish-to-start dependencies, a single delay cascades through the whole project. That may be accurate, but it may also reflect an outdated assumption about how work can be decomposed. Practitioners sometimes observe that breaking a large activity into smaller pieces and using a few start-to-start overlaps can significantly reduce total project duration without increasing risk. The finish-to-start relationship is not wrong; it is the unexamined accumulation of finish-to-start links that distorts the schedule.

A final misconception is that finish-to-start relationships only belong in predictive, waterfall-style projects. Agile, Lean, and hybrid teams also experience sequential constraints, but they manage them locally through board policies, definitions of ready, and dependency blockers rather than through a central network diagram. The underlying sequencing logic is the same. Refusing to acknowledge finish-to-start dependencies in agile settings often results in blocked work, hidden waits, and cumulative flow diagrams that show big gaps between stages. Ignoring the relationship does not remove the constraint; it just removes the visibility needed to manage it.

Practical Applications Across the Project Lifecycle

Typical finish-to-start examples in project management appear in every major industry and at every phase of the project lifecycle. In construction, excavation must finish before foundation forms can be set, and the foundation must finish before framing starts. In software development under a predictive life cycle, requirements analysis often precedes design, which precedes coding, which precedes testing. In event management, the venue contract may need to be signed before invitations can be sent, and the agenda may need to be finalized before printed programs are produced. These are all natural finish-to-start links that reflect a genuine handoff requirement.

During planning, finish-to-start relationships are documented in the schedule network diagram and reviewed with the team. During execution, project managers track predecessor completion and relay go signals to successor activities. During monitoring and controlling, delays in a predecessor trigger analysis of the successor's start date, float, and critical path impact. During closing, final acceptance testing typically must finish before the transition to operations can begin, and all open work packages must finish before the project can be formally closed. The relationship therefore functions as a recurring language for sequencing work from initiation through final delivery.

In large programs, finish-to-start dependencies often span multiple projects. A program may require one project to deliver a shared platform before another project can begin its integration work. In portfolio management, a strategic initiative may be sequenced after the completion of an enabling project. These cross-project finish-to-start links are critical for program schedule integration, but they are more fragile because the predecessor and successor may be controlled by different managers, budgets, and governance structures. Inter-project finish-to-start dependencies usually require formal interface agreements and regular synchronization sessions to remain reliable.

Evolution and Current Thinking

The evolution of finish-to-start scheduling began with the critical path method and program evaluation and review technique in the 1950s. Early scheduling systems relied heavily on finish-to-start logic because it was simple to model and easy to compute. The mathematics of the critical path method builds directly on sequential dependency chains, and the finish-to-start relationship became the default unit of that model. Over time, scheduling software added more dependency types, leads, lags, and constraint features, but finish-to-start remained the most commonly used connection. Its dominance is partly technical and partly cultural; planners often find sequential links easier to explain and defend.

Current thinking has become more cautious about automatic finish-to-start chains. Lean practitioners point out that waiting time between a predecessor and a successor is waste, and a finish-to-start relationship creates a natural opportunity for waiting if the handoff is not well managed. Agile methods emphasize delivering small vertical slices that minimize large-scale sequencing. Critical chain project management challenges finish-to-start scheduling by focusing on resource dependencies and buffer placement rather than purely logical task order. These approaches do not reject finish-to-start relationships, but they question whether they should always be the primary structure of a schedule.

Debate continues about how strictly dependencies should be modelled under uncertainty. Some schedulers prefer to keep finish-to-start links simple and deterministic, treating dependencies as fixed until a change request is made. Others advocate for probabilistic models that recognize predecessor completion may be partial or uncertain. The right approach depends on the complexity, duration, and risk profile of the project. What has not changed is the core insight: a finish-to-start relationship is a formal statement that one piece of work must finish before another can begin. That simple logic remains foundational to project scheduling even as tools and frameworks evolve around it.