In an FS dependency, the start of one task depends on the completion of another task. As you said, task B cannot start until task A is finished. For example, task A is "cutting wood" and task B is "shaping wood". So task B cannot begin until the wood is cut and available for shaping. Whereas, in an SF dependency, the completion of one task depends on the start of another task. As you mentioned, task A will start when task B finishes. For example, at a small event like a wedding, task A is to "sit everyone to their seats" and task B is to "welcome the arriving guests." So we cannot start seating guests before they arrive at the event. I hope these examples help you to better clarify the differences between FS and SF dependencies.

The key distinction between FS and SF is the direction of dependency. FS can be described as having a "forward-looking" dependency where Task B's start is dependent on Task A's finish. SF can be described as an almost "backward-looking" dependency where Task B's finish is dependent on Task A's start. Moreover, FS relationships are sequential and are about the progress of a project where one must finish one task to start another. On the other hand, SF relationships are more related to closure and transitioning of tasks where starting something new allows the closure of something old. I believe your confusion arises from the fact that both types of relationship involve starting and finishing; however, as long as you remember that in FS the completion results in the beginning of another task, and in SF the beginning of one task results in the completion of another, you should be able to distinguish between them. 

I’ll be providing a start-to-finish relationship example that occurred a few semesters ago on campus. The implementation of the new parking tapping card access system must be completed before the old swiping card access system is removed represents a SF relationship. The roll-out of the new access system is required to be able to remove the original access system. The next example relates to the writing process. An example of a finish-to-start relationship is: a report must be drafted before it can be edited. The finish date of the report draft determines the start date of the editing process. When drafting is completed, the editing process can start.

I love the examples that everyone has given so far! I want to build on this by directly connecting to project management tasks and seeing the FS and SF relations in play. I think your confusion comes from how both relationships have a start and a finish, but here, directionality is what sets them apart. In a Finish-to-Start (FS) relationship, task B cannot start until task A is finished. The finish of the first task directly triggers the start of the next task. You can’t start validation testing until you finish verifying the design. For Start-to-Finish (SF), the dependency runs in the opposite direction. A classic example is switching shifts as an EMT. You cannot end your shift until the next EMT comes and starts their shift. For project management, an example would be how an older revision of a Design Input Document cannot be officially closed and retired until the new revision is released. 

These distinctions also affect risk, since FS dependencies can create a delay risk if Task A has issues. With issues in Task A, Task B cannot start, and now the project is delayed. For SF, there is danger in continuity since Task A needs to start on time for Task B to end. This can hurt resource allocation or affect timelines, leading to a jumble in the schedule that can take a while to sort through and sort out. Gaps between processes can create documentation and traceability issues. 

I like how SF relationships need to be thought through more thoroughly than FS relationships, allowing for schedule-builders to actually stop and think about the feasibility of the schedule. SF forces you to think about continuity, and it makes one’s brain churn since they need to think about “what cannot stop until another thing starts.” This can help close gaps in schedules and ensure that documentation is thorough. 

What scenarios have you seen with SF relationships, and in scheduling, are these relationships hard to incorporate, or does it follow my logic I mentioned earlier and make scheduling more thorough? Have you seen PMs mostly default to FS relationships, and then discover SF constraints when problems arise? How can this be avoided? How can this affect staffing?

Another way to consider the distinction is to focus on what event is being protected. In FS dependencies, you are protecting the start of the successor task, since these tasks cannot begin until the predecessor task is complete. Thus, these dependencies are more about logical sequence and readiness. For example, in MDD, design verification protocols may not begin till the design freeze milestone is completed. Thus, the risk being controlled here would be premature execution. Meanwhile, an SF dependency prevents a task from ending until another task has started. For example, a legacy manufacturing line may need to remain operational until a new automated line is established and operational. Thus, the risk of being controlled here is the loss of continuity or operational downtime, as the old line cannot shut down till the new line starts. 

I have found SF dependencies to be quite interesting among the two, as they are particularly important in transition planning, regulatory compliance, and systems migrations. These areas typically require uninterrupted, continuous coverage/oversight, boosting the applicability of SF dependencies. Considering most scheduling tools and PMs that I have known, I have noticed a preference for sequential thinking and FS dependencies. So, I wonder if you all also think that SF constraints are sometimes overlooked until late-stage transition planning?

As many others above illustrate in FS the start of one event is tied to the finish of another as with es's cutting wood example while with SF, the start of one event is tied to the progress of another, as with Dr. Simon's example of painting lines on a road. The road doesn't necessarily need to be fully paved to begin painting, it just needs to have been started. An easier way to interpret this is thinking of FS tasks just as they are named, one needs to finish for the other to start. This implies that the first task must be fully complete to initialize the second task such as establishing the foundation of a building before building the walls. While as a start to finish task needs one task to start before the second task can finish. This interpretation I agree can be more confusing, however if you keep your frame of mind focused on the idea of continual progress it becomes easier to digest. An example of an SF task would be paving a road like mentioned above, or planting crops in a field. You need to till the field first before you can plant, but you don't have to wait for the entire field to be tilled before you begin planting. I hope that clears up any confusion and clearly illustrates the difference between the two.