Subjects and lessons to explore.

Law

Project Management · Foundations

Dependencies

11 min read 5 practice questions
9 key termsSourcesReport an error
Want it in plain words first? Jump to Eli explains — the same idea, no jargon.
On this page 9 sections
  1. In 30 seconds
  2. Why this matters
  3. The college version
  4. Eli explains
  5. Worked example
  6. Key takeaway
  7. Quick check
  8. Study tools
  9. Sources & references

In 30 seconds

A is a logical relationship that says how one planned activity relates to another. means one activity must finish before the next can start; and allow specific kinds of overlap; is a rare reverse relationship. Dependencies can be internal to a project or external, involving something outside its control. Recording the relationship, its reason, assumptions, and constraints makes the current plan easier to question and update; it does not guarantee timing.

Why this matters

A calendar can show dates without explaining why work is ordered that way. Dependencies expose those reasons: a review may need a draft, two activities may begin together, or a project may need information from outside the team. That visibility helps people distinguish a genuine condition from a habit or an unstated guess. It also prevents a common error: treating an outside approval, delivery, or decision as though the project can command it. Learning to state dependencies precisely improves discussion of a plan without claiming to predict its finish date or calculate a critical path.

The college version

Dependencies state a relationship, not merely two dates

A dependency is a logical relationship between planned activities. It says that an event concerning one activity affects when another activity may start or finish. The activity supplying the condition is the ; the activity affected by it is the . These labels describe the relationship, not job rank or importance. A predecessor may be a short review activity, and a successor may be a much larger activity.

The central question is not, “Which date comes first on a calendar?” It is, “What condition connects these activities?” For example, if a team cannot begin a public review until a draft exists, the review has a logical connection to the draft. A schedule may show both on dates, but the dependency explains why placing the review earlier would not make sense. Conversely, two activities that happen to be dated one after another do not automatically have a dependency. They may simply have been placed that way for convenience.

A dependency is also not a claim that a certain date will be met. It gives a model of a relationship using current information. If its underlying condition changes, the relationship or its interpretation may need review. That is why a dependency should be understandable to the people reading the plan: it is evidence for a proposed order of work, not an invisible rule produced by scheduling software.

Four relationship types describe different conditions

Finish-to-start (FS) is the familiar sequence: the successor cannot start until the predecessor finishes. “Review the completed draft” after “prepare the draft” is an FS relationship if the review needs the completed version. FS does not mean the review begins immediately after drafting; another condition could still delay it. It names one boundary that must be satisfied.

Start-to-start (SS) means the successor cannot start until the predecessor starts. It can express a limited kind of overlap. For example, a team may begin monitoring sign-up questions only after registration opens. Once registration has started, monitoring may start too, although it need not begin at the exact same moment. Finish-to-finish (FF) means the successor cannot finish until the predecessor finishes. A project could require both a participant guide and its accessibility check to be complete before the guide is considered ready; the activities may proceed in parallel, yet the check cannot be treated as complete before the guide it checks is complete.

Start-to-finish (SF) means the successor cannot finish until the predecessor starts. It is the fourth possible combination, but it is unusual and easy to misread because the successor may occur earlier in time than the predecessor. A handover from an existing support shift to a new shift can illustrate the idea: the existing shift cannot end until the replacement shift has begun. In beginner planning, it is often better to state the real handoff condition plainly than to introduce a complicated relationship. No type is a magic shortcut; the useful type is the one that accurately communicates the condition.

Internal, external, assumptions, constraints, and documentation

An internal dependency connects activities within the project’s own planned work. “Draft the guide before review” is internal if both activities belong to the same project. An connects the project to something outside that schedule or project boundary, such as an outside group’s decision, an external system’s availability, or a required piece of information from another effort. The distinction matters because the project may be able to change, split, or clarify internal work, but it may not control the external event. Calling an external dependency “internal” can create a false impression of authority.

Assumptions and constraints add useful context. An assumption is a condition used for planning because it is treated as true for now, such as expecting a partner to provide a data file in a particular format. A is a limit or condition that narrows what can be done, such as a fixed venue-access window or an interface that cannot accept a certain file type. Neither label makes a future event certain. Recording them helps a reader see why the relationship was modeled and what should be checked if the plan changes.

A lightweight dependency record can name the predecessor and successor, relationship type, whether it is internal or external, the reason for the link, its source or point of contact when relevant, and any assumptions, constraints, or review date. The record makes a conversation auditable: a reader can ask whether the condition is real, still current, and owned by the right boundary. It does not tell a real organization who must approve work, force an external party to act, or solve a delay. Critical-path calculations, duration estimates, buffers, and detailed network analysis are separate topics and are intentionally outside this lesson.

Eli, the EliExplains learning guide

Eli explains

The same idea, in plain words

Explain it like I’m 10

Imagine a school play. Before actors can rehearse with the finished props, the props must be ready. That is a dependency: one thing changes what another thing can do. The prop-making job is the predecessor, and the rehearsal is the successor.

Most dependencies are simple: finish the props, then start the rehearsal. Sometimes jobs can overlap. The person checking costumes might start as soon as costume sewing starts, but cannot finish the final check until sewing is finished. A project can also wait for something outside the team, such as the school confirming that the auditorium is available. That is an external dependency, because the play group does not control the confirmation.

Picture it like this

Dependencies are like rules for connecting pieces in a domino setup. One piece may need another piece placed first, while two separate lines can be built at the same time. The connections reveal which actions are related.

Where the picture stops working

A project is not a row of dominoes that always falls in one fixed way. People can revise work, conditions can change, and an outside group may not act when expected. The analogy also does not choose dates, calculate a critical path, or tell a real organization how to approve a change.

Worked example

River City Library hypothetically plans a one-evening digital-skills workshop. Its project activities include prepare a draft handout, begin an accessibility review, finish the handout, and complete the review. The team records an SS relationship between preparing the draft and beginning the review: the reviewer can start giving early feedback only after draft work has started. It records an FF relationship between finishing the handout and completing the review, because the review cannot be complete until the handout version being reviewed is complete. The workshop also depends on an external confirmation that a community partner will supply a projector. The record labels that link external, identifies the partner confirmation as its source, and notes the assumption that the projector supports the required connection. This documentation clarifies the current plan; it does not guarantee the partner’s action, estimate a date, or decide how the library should respond if the confirmation changes.

Key takeaway

Dependencies make the logic behind a plan visible. Choose a relationship type that states the real condition, distinguish internal work from external reliance, and document relevant assumptions and constraints so the relationship can be examined without mistaking it for a guaranteed date.

Quick check

3 questions here, of 5 in this lesson’s practice set. Answers stay hidden until you check.

Question 1 of 3foundational

Which statement best defines a finish-to-start relationship?

Choose an answer, then check it.
Question 2 of 3intermediate

A reviewer may begin reading a guide once drafting has begun, but the review cannot be completed until the guide is complete. Which relationship best describes the condition on completing the review?

Choose an answer, then check it.
Question 3 of 3intermediate

A project cannot run a workshop until a community partner confirms that it will provide a projector. The partner is outside the project team. How should the dependency be classified?

Choose an answer, then check it.
Practice all 5

Keep learning

Ready to build on this? Continue to the next lesson.

Practice this lesson
Study tools & related lessonsYou’ll learn to · Common mistakes · Easily confused · Key vocabulary · Related

You’ll learn to

  • Define a dependency and distinguish predecessor and successor activities.
  • Explain the basic meanings of finish-to-start, start-to-start, finish-to-finish, and start-to-finish relationships.
  • Distinguish internal dependencies from external dependencies.
  • Identify the role of assumptions and constraints when documenting a dependency.
  • Apply dependency concepts to a short hypothetical example without calculating a critical path or estimating a schedule.

Common mistakes

  • Calling every pair of consecutive calendar entries a dependency.

    State the actual condition that connects activities; dates alone do not prove a logical relationship.

  • Reading finish-to-start as a command that the successor must begin immediately.

    It says the successor cannot start before the predecessor finishes; other conditions can still affect its start.

  • Treating an external dependency as work the project team controls.

    Label the external boundary, source, and relevant assumption so the control limit is visible.

  • Using a relationship label without explaining its rationale or constraint.

    Record why the link exists and what condition should prompt a review.

Easily confused

Finish-to-start vs. Start-to-start

FS prevents the successor from starting before the predecessor finishes; SS prevents it from starting before the predecessor starts.

Finish-to-finish vs. Start-to-finish

FF prevents the successor from finishing before the predecessor finishes; SF prevents the successor from finishing before the predecessor starts and is less common.

Internal dependency vs. External dependency

An internal link connects activities within the project plan; an external link depends on an event, information source, or activity outside the project boundary.

Assumption vs. Constraint

An assumption is treated as true for current planning; a constraint is a limiting condition that narrows available choices.

Key vocabulary

dependency
A logical relationship in which one planned activity affects when another activity may start or finish.
predecessor
The activity whose start or finish provides a condition for a related successor activity.
successor
The activity whose start or finish is affected by a stated relationship with a predecessor.
finish-to-start
A relationship in which the successor cannot start until the predecessor activity has finished.
start-to-start
A relationship in which the successor cannot start until the predecessor activity has started.
finish-to-finish
A relationship in which the successor cannot finish until the predecessor activity has finished.
start-to-finish
A less common relationship in which the successor cannot finish until the predecessor activity has started.
external dependency
A relationship tied to activity, information, or an event outside the project’s own schedule or boundary.
constraint
A limit or condition that restricts the available ways project work can be planned or performed.

Sources & references

  1. Schedule Assessment Guide: Best Practices for Project Schedules (GAO-16-89G) — U.S. Government Accountability Office
  2. Follow the yellow brick road (the critical path) — Project Management Institute

EliExplains lessons are original prose written from the open, credible references above. See Copyright & Licensing.

Educational content only. It is not medical, legal or professional advice. Found an error? Tell us.