Certified - CompTIA Project+

In project scheduling, dependencies define the relationship between two or more activities in the plan. They establish the rules for how and when tasks can start or finish in relation to one another, shaping the overall flow of the schedule. Dependencies are not arbitrary—they reflect real-world constraints, whether technical, logical, or organizational. When dependencies are misunderstood or mismanaged, the result is often a chain reaction of delays, resource conflicts, and rework that can disrupt the entire project. That is why a clear grasp of dependency types is essential for accurate scheduling and for maintaining both efficiency and control throughout execution.
A dependency is essentially a link that dictates how the start or finish of one activity relates to another activity. This link is informed by constraints that may be physical, legal, procedural, or simply based on best practice. Dependencies ensure that activities are performed in a sequence that is viable, coordinated, and aligned with the project’s objectives. Every scheduled task should be evaluated for possible dependencies so that nothing critical is overlooked. Leaving dependencies undocumented increases the risk of building an unrealistic schedule that will collapse under real-world conditions.
Hard logic, also known as a mandatory dependency, represents constraints that cannot be avoided or altered without violating a physical or legal requirement. A classic example is pouring concrete before any structure can be built on top of it—the laws of physics make this sequence mandatory. These dependencies are not open to negotiation and must be respected when determining the order of work. Often, hard logic comes from the inherent nature of the deliverable or from compliance regulations that dictate specific procedural steps.
Soft logic, or discretionary dependencies, are those based on best practices, preferences, or team judgment rather than hard physical constraints. They allow for some flexibility in the sequence of work. For example, a team may prefer to complete all preliminary design drawings before starting procurement activities, even though some items could technically be ordered earlier. Because soft logic is flexible, it can be adjusted to optimize schedules, sometimes by reordering tasks or using techniques like fast-tracking. However, changing soft logic without understanding the downstream effects can create new risks.
Internal dependencies exist between tasks performed within the boundaries of the same project. Examples include a deliverable that requires review by an internal quality assurance team before the next phase can start, or a resource handoff from one internal team to another. These dependencies are under the project team’s control, meaning the project manager can coordinate schedules, resolve conflicts, and adjust priorities to keep work moving. Strong internal coordination is vital to prevent bottlenecks and to ensure that resources are available when needed.
External dependencies, by contrast, involve activities or deliverables outside the direct control of the project team. These could include waiting for a vendor to deliver specialized equipment, a client to approve a design, or a regulatory body to conduct an inspection. Because the project manager has limited influence over these activities, they are inherently riskier. Delays in external dependencies can affect the critical path, forcing the project to slip beyond planned delivery dates. The only way to mitigate these risks is through proactive communication, careful tracking, and contingency planning.
In scheduling, relationships between activities are also defined by the way their start and finish dates interact. A Start-to-Start (SS) relationship means that one activity cannot begin until another has started. For example, drafting detailed engineering drawings might only start once preliminary architectural layouts have begun. This allows for overlap, which can compress the schedule, but it also requires close coordination to avoid errors from incomplete predecessor work.
A Finish-to-Finish (FF) relationship requires that one activity cannot finish until another activity has finished. This is common in testing or integration phases, where the final acceptance testing of a product cannot be completed until all subsystem testing has also concluded. FF relationships are useful for synchronizing the end of related tasks to ensure smooth handovers and consistent quality across deliverables.
The Start-to-Finish (SF) relationship is the least common in project management. It means that one activity cannot finish until another has started. For example, in a security staffing scenario, the night shift cannot end until the morning shift has begun, ensuring continuous coverage. SF relationships are rare but can appear in specialized workflows, particularly those involving shift work or service continuity.
The most common type of dependency in project scheduling is the Finish-to-Start, or FS, relationship. In this arrangement, one activity must be fully completed before the next one can begin. This is the natural and most intuitive flow for many project tasks. For example, development work on a software feature must be completed before user acceptance testing can begin. The FS structure creates a clear, sequential order that is easy to follow and track, which is why it forms the backbone of most project schedules. However, while it’s the default choice for many tasks, relying solely on FS dependencies without considering potential overlaps can unnecessarily extend timelines.
Beyond the dependency type, scheduling often requires the use of lag time. Lag is the intentional delay inserted between the completion of one task and the start of its dependent task. For example, after painting a room, you might insert a three-day lag to allow the paint to dry before installing fixtures. Lag times account for curing periods, approval windows, delivery delays, or any other waiting periods that are built into the plan. In most scheduling tools, lag is represented as a positive offset, meaning it pushes the start of the successor task out by a set number of days or hours. Managing lag effectively ensures that the schedule reflects real-world timing rather than just idealized task sequences.
On the other hand, lead time works in the opposite direction by allowing tasks to overlap. Lead is a negative offset that pulls the start of the dependent activity closer to the start or finish of its predecessor. For instance, you might begin unit testing a software module before all development work is complete, as long as a sufficient portion of the code is ready. Using lead time can accelerate delivery, but it also introduces coordination challenges and potential quality risks if preceding work is incomplete or unstable. Therefore, lead should be applied selectively and with a clear understanding of its implications for quality control and rework.
In most professional scheduling environments, documenting dependencies in project management software is standard practice. Tools such as Microsoft Project, Primavera P6, or similar platforms allow the project manager to define each dependency type, apply lag or lead times, and visualize the relationships through Gantt charts or network diagrams. The advantage of this digital approach is that the software can automatically recalculate the entire schedule when durations change, ensuring that dependent activities adjust accordingly. However, this also means that incorrect dependency settings can propagate errors through the schedule, producing unrealistic completion dates and misleading performance reports.
Dependencies are not static—they can change during the life of a project. Change requests, resource reassignments, or delays in predecessor activities may require adjusting the links between tasks. When this happens, the project manager must update the scheduling tool to reflect the new relationships and then recalculate the project’s critical path and total float. This is especially important for dependencies that directly influence milestone dates or deliverable handoffs. Every change to dependencies should be documented and communicated to relevant stakeholders to maintain alignment and avoid surprises.
Some dependencies are more critical than others, particularly those that sit on the project’s critical path. A critical dependency is one where any delay in the predecessor task will immediately push back the project’s completion date. These dependencies demand closer monitoring, more frequent progress checks, and faster escalation if risk indicators emerge. Understanding float—or slack—helps identify which dependencies have schedule flexibility and which do not. Managing these distinctions well allows the project manager to focus attention and resources on the dependencies that truly drive project timelines.
External dependencies carry an elevated level of risk because they rely on parties or conditions outside the project team’s direct control. Vendor shipments, regulatory approvals, and client decisions are all examples. Any disruption here can stall downstream tasks and potentially affect the entire delivery date. To manage this, contingency buffers may be added to account for potential delays, or alternative suppliers and processes may be identified in advance. Strong, proactive communication with external stakeholders and frequent status checks are essential to reducing uncertainty in these areas.
When conflicts arise between dependent tasks—whether due to overlapping resource needs, mismatched timelines, or competing priorities—the project manager must step in to coordinate a resolution. This may involve resequencing activities, reassigning resources, or adjusting task durations to better align with overall project priorities. In some cases, resolving a dependency conflict may require escalation to higher management or steering committees if the impact is significant or crosses departmental boundaries. Holding regular coordination meetings that include relevant stakeholders helps catch and address these conflicts before they escalate into schedule-critical issues.
Network diagrams are one of the most effective tools for visualizing and analyzing dependencies. These diagrams show the logical flow of tasks and how they connect, making it easier to spot bottlenecks, identify the critical path, and communicate task relationships to stakeholders. Whether using the activity-on-node or activity-on-arrow method, network diagrams provide a clear picture of the project’s workflow that complements the more date-focused view of a Gantt chart. They are particularly useful during schedule development and risk analysis, as they allow the team to map out “what-if” scenarios for task ordering.
Communicating dependency-related risks to stakeholders is vital for maintaining trust and preparing for potential schedule impacts. Stakeholder updates should highlight which dependencies are critical, which are at risk, and what mitigation strategies are in place. Providing early warnings when a high-risk dependency is slipping allows decision-makers to approve adjustments or allocate resources before the impact becomes irreversible. By being transparent about these relationships, the project manager builds credibility and reinforces the perception that the project is under disciplined control.
Different project delivery approaches manage dependencies in different ways. In a traditional waterfall model, dependencies are mapped out in detail from the start, and the plan is executed with careful adherence to these predefined relationships. Agile methodologies, in contrast, minimize formal dependencies by organizing work into self-contained increments that can be delivered independently. However, Agile teams still manage internal dependencies within each sprint to ensure coordinated delivery. Hybrid environments often apply both approaches—maintaining detailed dependencies for certain workstreams while allowing iterative teams greater flexibility.
Ultimately, effective dependency management ensures that the project schedule is both realistic and coordinated. Understanding the distinctions between hard and soft logic, internal and external dependencies, and the various sequencing types allows the project manager to create a schedule that reflects the true flow of work. By documenting, adjusting, and communicating dependencies proactively, the team can avoid many of the common pitfalls that derail project timelines. Strong dependency control not only improves scheduling accuracy but also enhances resource utilization and overall project outcomes, aligning with both best practice and the expectations of the CompTIA Project+ exam.

Here’s Episode 32: Successor and Predecessor Relationships in Detail — Part 1 of 2 in the expanded 6,000–7,000 character narration style, following your bullet-to-paragraph mapping but with richer explanation, examples, and pacing for spoken delivery.
________________________________________
In a well-structured project schedule, every single task should connect to at least one other task. These connections are not arbitrary—they define the logical order in which work is executed, creating the backbone of the schedule’s sequencing. Successor and predecessor relationships guide the flow of work, helping the team understand not only what needs to be done, but in what order and under what conditions. This structure gives the project manager a clear map of dependencies, making it easier to identify risks, allocate resources effectively, and maintain overall schedule integrity. Without this relational logic, schedules become a loose list of dates, vulnerable to missed connections and overlooked constraints.
A predecessor is a task that must either start or finish before another task can proceed. It controls the timing of its successor and forms one half of the dependency link. Predecessors can be necessary for many reasons—technical sequencing, resource availability, or organizational policy. For instance, in construction, foundation work is a predecessor to framing; in software, coding is a predecessor to testing. Incorrectly linking or omitting predecessors can cause misalignment in schedules, resulting in idle resources, rework, or tasks starting before prerequisites are complete.
A successor, by contrast, is a task that follows another task’s start or finish. It relies on its predecessor to meet defined conditions before it can begin or conclude. Successors give forward motion to the schedule, forming the chain of activities that ultimately leads to project completion. They are especially important in tracking downstream impact: if a predecessor is delayed, all linked successors are affected. This makes the successor’s performance a direct indicator of how well the schedule is holding together.
The most common relationship between predecessors and successors is Finish-to-Start. In this arrangement, the predecessor must finish before the successor can start. It’s the default in most scheduling tools and represents the natural, intuitive flow of work. For example, in manufacturing, a machine part must be fabricated before it can be assembled into a product. While this structure keeps sequencing clear, it also means that any delay in the predecessor will push back the successor’s start, potentially impacting the overall timeline.
Start-to-Start relationships allow a successor to begin once its predecessor has started. This approach enables tasks to run in parallel, compressing timelines when time is tight. For example, you might start writing user documentation once software development begins, rather than waiting for the final code. However, this requires strong coordination to ensure the successor does not advance too far ahead, relying on incomplete or changing predecessor work.
Finish-to-Finish constraints mean that the predecessor must finish before the successor can finish. This is used when deliverables need to conclude together, even if they start at different times. A good example is finalizing a report and its associated graphics—both must be completed before the report can be published. This relationship is often used to align review cycles, multi-component testing, or phased approvals.
Start-to-Finish is the rarest form of task relationship. In this case, the predecessor must start before the successor can finish. It is typically used in specialized operational contexts, such as staffing a 24-hour facility, where one shift cannot end until the next has started. While uncommon, this relationship can be critical in environments that require continuous coverage or tightly timed handoffs.
Many tasks have multiple predecessors. Integration testing, for example, may require that development on several modules is completed before it can start. In this case, all listed predecessors must meet their conditions before the successor begins. While this is sometimes unavoidable, having multiple predecessors increases complexity and risk, as delays in any one of them can hold up the entire successor task.
Similarly, one task can have multiple successors. The approval of a major design might trigger the start of manufacturing, marketing, and documentation tasks all at once. In such cases, the predecessor’s completion date is a single point of dependency for multiple streams of work, meaning that a delay has a wide ripple effect. Each successor must be tracked individually for progress and resource needs.
Managing these relationships in scheduling software allows project managers to define, visualize, and adjust task connections. Tools like Microsoft Project or Primavera P6 offer both Gantt chart views for visual timelines and network diagrams for logical sequencing. These tools also flag logic errors, such as circular dependencies, which can lock schedules in unsolvable loops. Regular review of these relationships in the tool helps keep the schedule realistic and aligned with the project’s evolving reality.
During the sequencing phase of schedule development, each task is examined for its logical position relative to the others. Predecessors and successors are assigned deliberately, based on the project’s scope, estimated durations, resource availability, and technical dependencies. The goal is to produce a schedule that is not only logically correct but also executable in the real world. This process often involves collaboration with subject matter experts, functional managers, and team leads to ensure that the order of activities reflects the way work can and should actually be done. Every relationship should be scrutinized for its role on the critical path, as tasks that drive project completion require extra attention.
As the project progresses, these relationships must be reassessed regularly. Real-world conditions can reveal that some dependencies are no longer necessary, or that new ones have emerged. For example, if a prototype build is completed earlier than expected, downstream tasks like quality inspections might be able to start sooner. Conversely, a delay in acquiring materials might require the resequencing of multiple successor tasks. Regular schedule reviews allow the project manager to update relationships so that the plan remains an accurate reflection of the current state of work.
Lead and lag adjustments are powerful tools for fine-tuning these relationships without changing the underlying scope of tasks. Lead time allows a successor to begin earlier than the standard dependency would normally permit, creating intentional overlap. This is common in situations where partial completion of a predecessor is enough to begin work on a related task, such as starting system configuration before all hardware is delivered. Lag time, on the other hand, introduces a planned delay between tasks. This can be critical for curing times in construction, mandatory review periods in compliance-heavy projects, or waiting for approvals. Both lead and lag should be applied deliberately and documented to prevent misunderstandings.
Validating the integrity of these relationships is essential to schedule quality. Every task should connect logically to the rest of the schedule, with at least one predecessor and one successor, except for the first and last tasks in the project. Loops, disconnected tasks, or excessive use of leads and lags are red flags that suggest flawed planning. Validation may involve automated checks within scheduling tools, as well as manual reviews by experienced planners or the project management office. A clean relationship structure ensures that schedule updates and critical path calculations remain reliable.
In many projects, tasks are owned by different teams, departments, or even organizations. Cross-team dependencies must be clearly documented and communicated, because delays or misunderstandings in one area can cascade into multiple others. Hand-off points, deliverable acceptance criteria, and timing expectations should all be agreed upon in advance. Without explicit coordination, a task that one team believes is “done” may not meet the needs of the next team in the sequence, causing costly rework and schedule slips.
External dependencies introduce another layer of complexity to successor and predecessor relationships. When tasks rely on vendors, clients, or third parties, the project manager’s control over the timing is reduced. These external links are especially vulnerable to delays, and their status must be monitored closely. Buffer time or contingency planning is often built into the schedule to protect critical successors from the impact of late deliveries, missed approvals, or regulatory reviews. The visibility of these dependencies in the master schedule allows for proactive risk management.
Tasks on the critical path that serve as predecessors to other critical tasks require the highest level of monitoring. In these cases, any delay in the predecessor will directly impact the successor and ultimately push out the project completion date. These relationships have zero float, meaning there is no flexibility without affecting the end date. The project manager should prioritize these tasks in progress reviews, resource allocation, and risk management efforts, ensuring they receive immediate attention if problems arise.
Not all relationships are this rigid. Tasks with float have some flexibility in their start or finish dates without impacting the overall project timeline. These non-critical relationships can provide breathing room in tight schedules, offering opportunities to adjust for resource conflicts or unexpected events. However, float is not a license to ignore these tasks—misuse of flexibility can erode buffer time and create new risks. Preserving float through disciplined scheduling practices helps maintain overall stability.
Communicating the impact of task relationships to stakeholders is an important part of project transparency. When reviewing the plan, stakeholders should understand which activities drive the timeline and how delays in predecessors can affect downstream work. Visual tools such as milestone charts, dependency maps, or network diagrams can make these connections easier to grasp. Clear communication builds confidence that the schedule is logical, realistic, and managed with discipline.
Whenever scope changes occur—whether through formal change requests, client requests, or internal strategy shifts—the entire web of relationships must be revalidated. Adding, removing, or reordering tasks can significantly alter the structure of predecessors and successors. If these updates are not made, the schedule will no longer accurately forecast the project’s future, leading to missed commitments and resource conflicts. The work breakdown structure, schedule, and resource plan should all be updated in parallel to maintain alignment.
Auditing task relationships periodically is a best practice for ensuring schedule health. These audits can uncover broken links, circular dependencies, and unnecessary constraints that reduce flexibility. Many project management offices use relationship integrity as a quality metric when assessing schedules, recognizing that a clean, logical network is the foundation for effective planning. In professional practice—and on the CompTIA Project+ exam—being able to explain, create, and maintain high-quality predecessor-successor structures is a hallmark of competent scheduling.
In summary, the disciplined use of predecessor and successor relationships is what transforms a collection of tasks into a functioning project schedule. By establishing logical sequencing, applying leads and lags effectively, validating connections, and managing cross-team and external dependencies, the project manager ensures that the schedule remains both realistic and adaptable. Mastering these concepts enables better forecasting, more efficient resource use, and stronger on-time delivery performance, all of which directly support both exam readiness and success in real-world project execution.