Finish-to-Finish Relationship

A finish-to-finish relationship is a logical dependency between two project activities in which the successor activity cannot be considered complete until the predecessor activity is complete.

Within the precedence diagramming method, the finish-to-finish relationship is one of four ways to connect schedule activities. It is represented in project network diagrams by an arrow from the finish point of one activity to the finish point of another. Project managers use this type of dependency when completion of a deliverable, test, inspection, or handoff is gated by the completion of a related upstream task. The relationship does not require the two activities to start at the same time, nor does it dictate that they must finish at the same moment. It simply establishes that the end of one activity controls the end of another.

Finish-to-Finish Relationship: Key Topics at a Glance

What Is a Finish-to-Finish Relationship?

In formal project management terminology, the finish-to-finish relationship definition describes a logical link in which a successor activity cannot finish until its predecessor finishes. This constraint appears in the sequence of work and influences how project schedules are calculated. The relationship is sometimes abbreviated as FF in scheduling software and in the precedence diagramming method notation. It is distinct from the more common finish-to-start dependency, where a successor cannot start until the predecessor is complete.

When a project network contains a finish-to-finish link, the successor may begin before the predecessor ends, provided the successor has enough input to progress. This creates overlap between execution windows. For example, a quality assurance review activity can begin while a document is still being drafted, but the review cannot be marked complete until the draft is finalized. The finish-to-finish relationship therefore captures a completion-level dependency rather than a start-level dependency.

In practice, the relationship often feels counterintuitive because much of project management culture is built on handoffs from one completed activity to the next. A finish-to-finish dependency asks the planner to think about what must be done before the project can say something is finished, not necessarily before the next task can begin. That subtle shift matters when activities partially overlap and when resources must work in parallel under tight deadlines.

Finish-to-Finish in the Precedence Diagramming Method

The precedence diagramming method models activities as nodes and dependencies as arrows. Finish-to-finish is one of the four logical relationship types, along with finish-to-start, start-to-start, and start-to-finish. In PDM notation, an FF arrow is drawn from the predecessor activity's finish node to the successor activity's finish node. This visual convention communicates that the successor cannot cross its own finish line until the predecessor crosses its finish line.

Many scheduling tools allow the user to apply a lag or lead value to the FF relationship. A positive lag extends the required time between the two finish points. A negative lag, or lead, pulls the successor finish earlier relative to the predecessor finish. These adjustments are useful, but they also increase the risk of misinterpreting the logical dependency if the schedule is not well documented.

How Finish-to-Finish Differs from a Finish-to-Start Handoff

A finish-to-start relationship is a sequential handoff. The predecessor must be complete before the successor can begin. A finish-to-finish relationship is not a handoff. It is a shared completion condition. The successor can be in motion for much of the predecessor's duration, but the successor's final state depends on the predecessor's final state. This distinction becomes clear when someone asks why two activities are shown as overlapping yet one still constrains the other. The answer is that the constraint is only about the finish point.

This distinction also affects how team members perceive accountability. In a finish-to-start sequence, the predecessor team is often seen as blocking the successor team until they finish. In a finish-to-finish dependency, both teams can work simultaneously, but the successor team cannot claim full completion until the predecessor team delivers the necessary final output. That creates a more collaborative, but sometimes more ambiguous, accountability structure.

Core Insights on Finish-to-Finish Relationships

Formal definition of FF

In formal project management, a finish-to-finish relationship stipulates that the successor activity cannot be marked complete until the predecessor activity has reached its own completion point.

Contrast with finish-to-start

Unlike the more common finish-to-start dependency, a finish-to-finish link permits the successor to start while the predecessor is still in progress, provided that sufficient input or preliminary deliverables are available.

Example of overlapping work

For example, a quality assurance review may begin while the document is still being drafted, yet the review cannot be finalized until the draft is complete.

PDM notation and planning shift

In precedence diagramming method notation, the finish-to-finish arrow connects the predecessor's finish node to the successor's finish node, directing planners to manage completion criteria and final integration points rather than sequential handoffs.

Key Components and Characteristics of Finish-to-Finish Dependencies

Several key components of finish-to-finish dependencies determine how the relationship behaves in a schedule model. At minimum, a finish-to-finish relationship involves a predecessor activity, a successor activity, and a dependency constraint on the finish point of the successor. The relationship can also include lag or lead time, resource assignments, and calendar constraints that affect the precise finish dates.

The predecessor activity is the controlling task whose completion gates the successor's completion. The successor activity is the dependent task that cannot be declared complete until the predecessor is done. This does not mean the successor starts after the predecessor. In many cases, the successor may start early and conduct work in parallel, completing only after the predecessor's final output is available.

Lags and leads are important modifiers. A lag in an FF relationship is usually expressed as a delay after the predecessor finishes before the successor can finish. For example, a lag of two days might reflect the time needed for a final inspection after construction before commissioning can be considered complete. A lead is less common in FF relationships, but it can represent a situation where the successor can finish slightly before the predecessor because some downstream constraint has been relaxed.

Predecessor and Successor Semantics

In project schedules, the labels predecessor and successor refer to the direction of the logical dependency, not the chronological order of work. This is particularly important for finish-to-finish relationships. The predecessor may complete after the successor starts, and in some scenarios the successor may begin before the predecessor has made meaningful progress. The term successor simply means the activity whose schedule position is constrained by the other activity.

Planners sometimes confuse this sequencing language with actual work order. A finish-to-finish predecessor is not always the task that starts first. It is the task that must be complete before the other can be considered complete. This distinction prevents errors when communicating the dependency to team members who assume that predecessor and successor always operate in a strict before-after sequence.

Mandatory, Discretionary, and External Attributes

Finish-to-finish dependencies can be categorized as mandatory, discretionary, external, or internal based on the nature of the constraint. A mandatory FF dependency occurs when the work itself cannot physically or contractually finish before another activity. For example, a structural inspection activity cannot finish before the installation it inspects finishes. A discretionary FF dependency is a preferred sequencing decision, often used to coordinate resources or align acceptance reviews. External FF dependencies involve parties outside the project team, such as a regulatory sign-off that cannot finish until an internal deliverable is complete. Internal FF dependencies sit entirely within the project's control.

Understanding these attributes becomes important when schedule risk is assessed. Mandatory FF links usually cannot be removed without changing the scope or execution approach. Discretionary FF links can be removed if they create unnecessary complexity. Many schedule quality reviews start by separating the two, because discretionary finish-to-finish links are a common source of hidden schedule logic problems.

Finish-to-Finish Relationship in PMBOK and Scheduling Standards

The finish-to-finish relationship PMBOK treatment appears within the Project Schedule Management Knowledge Area, specifically in the processes for sequencing activities and developing the schedule. The PMBOK Guide describes the precedence diagramming method and lists finish-to-finish as one of the four dependency types used to create a project schedule network diagram. It also recognizes mandatory, discretionary, external, and internal dependency attributes that can apply to any logical relationship, including finish-to-finish.

Within the PMBOK framework, finish-to-finish relationships are not used as often as finish-to-start relationships, but they are considered valid and sometimes necessary. The guide emphasizes that dependencies should reflect the true logic of the work, not merely a preferred sequence. When a downstream activity genuinely cannot finish before an upstream activity finishes, the schedule model should show an FF dependency to support realistic critical path calculations.

Schedule network analysis uses these dependencies to calculate early start, early finish, late start, and late finish dates. In an FF relationship without lag, the early finish of the successor is constrained by the early finish of the predecessor. The successor may still have its own duration and work periods. The forward pass and backward pass calculations in the critical path method account for this finish-point constraint differently than they would for a finish-to-start relationship.

Process Groups and Knowledge Areas

Finish-to-finish relationships are established in the Sequence Activities process and then used in the Develop Schedule process. In PMBOK terms, Sequence Activities is where project managers identify and document dependencies among activities. The output is a project schedule network diagram. The finish-to-finish type is selected based on the work's characteristics, often with input from subject matter experts who understand the operational constraints. Develop Schedule then takes those dependencies and applies duration estimates, resources, calendars, and constraints to calculate start and finish dates.

This separation matters because it reinforces that finish-to-finish is a logical relationship, not a date constraint. A date constraint forces an activity to finish on a particular day. A finish-to-finish relationship only defines how one activity's finish is referenced to another activity's finish. Both may exist in the same schedule, but they have different effects on critical path calculations and schedule flexibility.

Schedule Network Analysis and Critical Path

During the forward pass, the finish-to-finish relationship influences the earliest point at which the successor can be marked complete. The successor's early finish cannot occur before the predecessor's early finish, unless a lead modifies the logic. The backward pass then determines late dates by calculating the latest allowable finishes while respecting the same constraint.

One practical effect is that an FF dependency can reduce total project duration compared with a strict finish-to-start sequence if the successor can begin earlier. This compression effect is one reason project managers use FF relationships for activities that can overlap. However, it also introduces more complex scheduling logic that requires careful review during schedule risk assessment. On a practical level, if a review cannot finish until a document is finalized, the schedule will not allow the review to show a completed date before the document's completion date. That is the entire calculation in plain terms.

PRINCE2 and Alternative Framework Perspectives

PRINCE2 does not explicitly define a finish-to-finish dependency as a named technique, but finish-to-finish in PRINCE2 appears as an accepted scheduling detail when conventional project management tools are used. The method focuses on product-based planning, where the emphasis is on identifying products and their quality criteria before determining activities and dependencies. When planning activities in a PRINCE2 project, the project manager can apply conventional scheduling dependencies, including finish-to-finish logic, within the plans if the chosen scheduling tool supports it.

The PRINCE2 approach places more attention on product flow, quality reviews, and stage boundaries than on the specific arrow conventions of network diagrams. This does not mean PRINCE2 rejects finish-to-finish relationships. It simply treats dependency logic as a scheduling detail rather than a central method requirement. Many PRINCE2 practitioners use finish-to-finish dependencies in their product-based plans when a product cannot be approved until a related product is complete.

Agile environments take a different view. In iterative or flow-based delivery, teams are less likely to model finish-to-finish dependencies as formal schedule constraints. Work is broken into small items that are usually independent or sequenced by simple priority. However, when dependencies exist across teams or external suppliers, an Agile release plan may still reflect finish-to-finish logic informally. For example, a compliance sign-off cannot be considered complete until the technical documentation is complete, even if both items are being worked on simultaneously.

Hybrid models often combine predictive scheduling with Agile delivery. A finish-to-finish relationship can appear in the higher-level project plan while the detailed sprint backlog remains dependency-light. This allows executives to see milestone logic without forcing every user story into a network diagram.

Origin and Cross-Industry Context of Finish-to-Finish Dependencies

The finish-to-finish relationship origin is tied to the development of network scheduling techniques in the mid-twentieth century. Activity-on-node diagrams and the precedence diagramming method emerged as a more flexible alternative to activity-on-arrow diagrams, which were primarily built around finish-to-start logic. The ability to model finish-to-finish, start-to-start, and start-to-finish dependencies allowed planners to represent overlapping work more accurately in complex engineering and construction projects.

Construction scheduling remains one of the most common domains for finish-to-finish dependencies. A concrete pouring activity may begin after formwork starts, but the pouring cannot be considered complete until the formwork installation is complete. This overlap is natural in field operations and avoids the inefficiency of fully sequential scheduling. In manufacturing and maintenance planning, similar logic appears when a final assembly cannot finish until a subassembly or inspection process is complete, even though portions of both are being performed concurrently.

These cross-industry origins reinforce that finish-to-finish is not a bureaucratic concept invented for project management software. It reflects how physical work and knowledge work often complete together. The value of naming the relationship comes from the ability to calculate schedules and communicate constraints rather than leaving overlap implicit in a Gantt chart.

Influence on Scheduling Software

Modern scheduling tools such as Oracle Primavera P6, Microsoft Project, and other project management platforms implement finish-to-finish dependencies as a standard relationship type. The software typically provides a drop-down or properties field where the scheduler selects FF and may enter a lag value. The tool then applies the constraint in the network calculations. This technical implementation has made the concept accessible to a broader range of project managers, but also increased the risk of using it without understanding the calculation logic. When a schedule contains thousands of activities, a few poorly placed finish-to-finish links can significantly alter the critical path and float calculations in ways that are difficult to trace manually.

Key Takeaways on Finish-to-Finish Origins

Origins in Network Scheduling

The finish-to-finish dependency emerged from mid-twentieth-century network scheduling techniques, especially activity-on-node diagrams and the precedence diagramming method, which offered greater modeling flexibility than the finish-to-start logic used in activity-on-arrow diagrams.

Modeling Overlapping Work Realistically

Finish-to-finish, start-to-start, and start-to-finish dependencies allow planners to model concurrent work with greater accuracy, such as concrete pouring that can begin once formwork starts but cannot be completed until the formwork installation is finished.

Software Adoption and Hidden Risks

Oracle Primavera P6 and Microsoft Project support finish-to-finish as a standard relationship, which expands scheduling options but can compromise critical path and float calculations when misplaced links remain hidden in large schedules.

Practical Application and Real-World Scenarios

Common finish-to-finish examples in project management involve testing, documentation, commissioning, and handoff activities. Consider a software implementation project in which system integration testing cannot be declared complete until data migration is fully complete. Test execution may begin while migration is still underway, but the test phase cannot finish because final test cases depend on the migrated data. A finish-to-finish relationship captures this constraint cleanly.

Another practical scenario occurs in event management. Venue setup and security configuration may happen in parallel, but the security configuration activity cannot be considered done until the venue setup is done because final security checks require the finished venue layout. The finish-to-finish relationship keeps the schedule logically honest without forcing setup to complete before security work can begin.

Project managers should use finish-to-finish dependencies when there is a genuine finish gating condition. This often exists when a successor has a final deliverable, review, or acceptance step that depends on the predecessor's output. If the successor can actually finish before the predecessor without any consequence, then the dependency should not be used. Adding unnecessary FF links creates false constraints that distort float and critical path calculations.

Schedule Compression and Parallel Work

Finish-to-finish relationships support schedule compression by allowing parallel execution where a strict finish-to-start sequence would extend the schedule. This is not the same as fast tracking. Fast tracking is a deliberate schedule compression technique that converts sequential activities into overlapping ones and increases risk. Finish-to-finish is a logical relationship type that may be selected during initial planning or as part of fast tracking. The distinction matters because a schedule can contain finish-to-finish dependencies without being considered fast tracked if the overlap reflects the natural way the work is done.

Who Uses Finish-to-Finish at Which Lifecycle Stage

Schedulers, project managers, and planning engineers are the primary users of finish-to-finish relationships. They appear most often during schedule development and schedule refinement. Control account managers and work package owners may also reference these dependencies when reviewing critical path logic. In the closing phase, finish-to-finish links are less visible, but they may still clarify why final acceptance activities cannot close until technical deliverables are complete.

On capital projects, owners and contractors may dispute finish-to-finish dependencies because they affect delay analysis and liquidated damages. A contractor might argue that a finish-to-finish relationship shows concurrent work and therefore should not be treated as sequential delay. An owner might claim that the true finish gate was earlier. This is why schedule baselines increasingly require not just the FF link but a narrative explaining the physical or contractual reason for the dependency. In project management practice, the relationship is not just a planning tool; it becomes evidence in claims and forensic schedule analysis.

Common Misconceptions and Pitfalls

Several finish-to-finish misconceptions cause avoidable errors in project schedules. One of the most frequent is the assumption that a finish-to-finish relationship means both activities must finish at the same time. The relationship only prohibits the successor from finishing before the predecessor, absent a lead. The successor can finish later, and it often does. Another misconception is that finish-to-finish relationships force activities to start together. They do not.

Planners sometimes use finish-to-finish links as a shortcut to create overlap without verifying that the finish constraint is real. This can generate misleading schedule logic and hide genuine execution risks. For example, linking a design activity and a procurement activity with an FF dependency may look efficient, but if procurement can legitimately finish before design is fully signed off, the link is artificial. Artificial constraints make the critical path less reliable and can reduce the credibility of the schedule.

There is also a tendency to confuse finish-to-finish with start-to-start. Both enable overlap, but they constrain different ends of the activity. Start-to-start controls when the successor can begin. Finish-to-finish controls when the successor can finish. In a painting and inspection example, inspection cannot start until painting starts if there is a start-to-start link. Inspection cannot finish until painting finishes if there is a finish-to-finish link. Both may be combined in some schedules.

When Not to Use Finish-to-Finish

A finish-to-finish relationship should not be used when the successor's completion is unrelated to the predecessor's completion. It should also be avoided when the team cannot explain the finish gating condition in plain operational language. If the dependency exists only to make the Gantt chart look more parallel, it is likely adding noise. Schedules with large numbers of unnecessary FF links become difficult to audit and maintain, especially when lags and leads are layered on top.

Project controls professionals often observe that excessive finish-to-finish dependencies can hide near-critical paths. Because these links change the forward and backward pass calculations, they may shift float in ways that are not obvious to stakeholders. A transparent schedule uses finish-to-finish logic sparingly and documents why the constraint exists in the activity attributes.

Mistaking Lags for Uncertainty Buffers

Another common error is using lag on finish-to-finish relationships as a hidden buffer. A project manager may add a lag of three days between the finish of design and the finish of quality review, believing this creates breathing room. In effect, that lag delays the successor's finish and may seem harmless. But it does not represent actual work logic. It is a schedule buffer dressed as a dependency. When the lag is challenged or removed, the schedule can shift abruptly. Buffers are better managed through explicit reserve analysis or schedule contingency, not through artificial finish-to-finish lags.

Key Takeaways on Finish-to-Finish Pitfalls

Simultaneous finish is not required

A finish-to-finish relationship does not require both activities to complete at the same time; it only prevents the successor from finishing before the predecessor unless a lead is explicitly applied.

Shared start times are a myth

A common misconception is that finish-to-finish links require activities to begin together, but in reality the relationship constrains only the finish side of the successor.

Shortcut links create false overlap

Planners sometimes insert finish-to-finish links solely to create overlap, without first confirming that a genuine finish constraint exists between the two activities.

Artificial ties distort the critical path

Artificial finish-to-finish dependencies distort the critical path by imposing constraints that do not reflect actual work logic, reducing the schedule's reliability and undermining its credibility.

Excess links hinder auditing

Schedules overloaded with unnecessary finish-to-finish links, especially those layered with lags and leads, become difficult to audit and maintain and can obscure near-critical paths.

Relationship to Other Project Management Concepts

The comparison between finish-to-finish vs finish-to-start is the most important conceptual contrast for new project managers. A finish-to-start relationship states that the successor cannot start until the predecessor finishes. A finish-to-finish relationship states that the successor cannot finish until the predecessor finishes. In both cases the predecessor constrains the successor, but the constrained point is different. Finish-to-start is appropriate for sequential handoffs. Finish-to-finish is appropriate for overlapping work with a shared completion gate.

Finish-to-finish also interacts with total float and free float. An FF relationship can create a situation where the successor has zero total float relative to the project finish even if it has some free float relative to its own successor. Understanding how the software calculates these float values helps the project manager explain why an activity may appear noncritical in one view but critical in another.

In earned value management, finish-to-finish logic does not directly change EVM formulas, but it can influence the planned value curve. If activities overlap under an FF relationship, the planned value for work packages is distributed across earlier periods than it would be under a sequential plan. This affects the performance measurement baseline and can alter variance interpretations during execution.

Finish-to-Finish and Critical Path Method

The critical path method uses finish-to-finish dependencies during both the forward pass and the backward pass. A common mistake is to treat the FF link as if it only matters after the predecessor finishes. In reality, the dependency constrains the successor's finish date throughout the schedule calculation. This can affect the early and late dates of other linked activities and may extend or shrink the total float depending on the network structure.

Risk models also incorporate finish-to-finish dependencies when simulating schedule outcomes. Uncertainty in the predecessor's finish date propagates to the successor's finish date according to the FF logic. If Monte Carlo simulation is used, the correlation between these activities may be partly structural rather than statistical. This is an important consideration in schedule risk analysis because modeled correlations can produce misleading results if the underlying dependency logic is incorrect.

Evolution and Current Thinking

Current finish-to-finish relationship best practices emphasize logical accuracy over visual convenience. The scheduling profession has moved toward making dependencies explicit and auditable rather than embedding them silently in software defaults. Modern scheduling guidelines, including those from professional project management associations and government project controls bodies, recommend that every finish-to-finish link be justified by a verifiable work logic statement.

One evolution is the increased use of schedule quality checks. Automated schedule health tools flag finish-to-finish relationships that are missing lag justifications, or that appear in excessive numbers. Some organizations set thresholds or require review of non-finish-to-start dependencies. This is not because finish-to-finish is inherently wrong, but because it is more frequently misused than the simpler finish-to-start relationship.

Debate continues over how granular these dependencies should be. Some practitioners prefer detailed activity-level finish-to-finish links to model precise overlap. Others argue that too much detail creates brittleness, especially in knowledge work where finish points are ambiguous. The current consensus is context dependent. Large construction, aerospace, and infrastructure projects benefit from detailed FF logic. Smaller software or business change projects may only need finish-to-finish constraints at milestone level or not at all.

Key Takeaways on Finish-to-Finish Best Practices

Logic Outweighs Visual Convenience

Current best practice prioritizes logical accuracy by treating finish-to-finish dependencies as deliberate scheduling decisions that must withstand scrutiny, not as shortcuts for making diagrams look tidy.

Dependencies Must Be Explicit

The profession has moved away from burying relationships inside software defaults and now expects dependencies to be explicitly documented, traceable, and auditable throughout the schedule.

Justification Through Work Logic

Guidelines issued by professional associations and public sector project controls bodies now require every finish-to-finish link to be supported by a verifiable work logic statement that explains why the relationship exists.

Automated Health Checks Proliferate

Automated schedule quality tools increasingly flag finish-to-finish relationships that lack justified lag values or appear in excessive numbers, leading many organizations to set quantitative thresholds and require formal review of non-finish-to-start dependencies.

Debate Over Activity-Level Detail

Practitioners disagree about granularity; some favor detailed activity-level finish-to-finish links to model precise overlap, while others caution that excessive detail creates brittle schedules, especially in knowledge work and smaller business change projects where milestone-level constraints may be enough.

BVOP Perspective on Finish-to-Finish Dependencies

From a BVOP viewpoint, BVOP finish-to-finish dependencies are applied conservatively because BVOP planning uses relational effort points and acknowledges the limits of work breakdown structure accuracy. In a value-oriented plan, a finish-to-finish constraint is retained only when a predecessor deliverable truly gates the completion of a successor deliverable. Scope shifts are treated as feedback rather than failure, so rigid completion dependencies are not used to mask uncertainty or force a false sense of control.