Unit 4: Task Linkages

I. Foundations of Task Linkages

Task linkages are dependency relationships that place project activities in a logical, workable order. In scheduling software such as Microsoft Project, links connect predecessor and successor tasks so that changes to one task can automatically affect the dates of another.

• Task: A defined activity with a start date, finish date, duration, work requirement, and possibly assigned resources.
• Predecessor: A task whose start or finish controls another task; for example, “Approve design” precedes “Begin development.”
• Successor: A task whose timing depends on a predecessor.
• Dependency: The logical relationship between two tasks, represented by a link type such as Finish-to-Start.
• Scheduling convention: Dependency abbreviations are FS, SS, FF, and SF; lag or lead is appended, as in 12FS+2d.
• Planning principle: Links should represent real operational dependencies, not merely preferred calendar dates.
• Hierarchy: Summary tasks group subtasks, while milestones normally represent zero-duration events such as approval or delivery.
• Schedule calculation: In an automatically scheduled project, the scheduling engine combines links, calendars, durations, constraints, and resource information.

II. Constructing and Configuring Tasks

A. Creating A Logical Sequence

A logical sequence arranges tasks according to the work and information required to begin or complete them.

• Identify deliverables: Start from concrete outputs such as “Requirements approved” or “Test report completed.”
• Determine dependencies: Ask what must exist before each task can proceed; coding may require an approved design.
• Avoid date-driven planning: Link tasks through dependencies instead of independently entering fixed start dates.
• Check completeness: Include approvals, reviews, procurement, testing, and handovers rather than only production work.
• Example sequence: Gather requirements → Approve requirements → Design system → Develop system → Test system.

B. Using The General Tab

The General tab of the Task Information dialog stores the task’s core identity and scheduling details.

• Identification fields: Task name and task ID distinguish the activity in the task table.
• Scheduling fields: Duration, start, finish, and completion percentage describe its current timing and progress.
• Calendar option: A task calendar can define working periods that differ from the project calendar.
• Scheduling mode: Manual scheduling preserves entered values, whereas automatic scheduling calculates dates from scheduling rules.
• Milestone setting: A task may be marked as a milestone even when its duration is greater than 0d, although zero duration is conventional.

C. Understanding Task Predecessors

Task predecessors define the earlier activities that logically control a task’s schedule.

• Predecessor entry: The Predecessors tab records the predecessor task ID, dependency type, and lag.
• Multiple predecessors: A task can depend on several activities; its calculated date must satisfy every applicable relationship.
• Example: For task 8, the entry 3FS,5FS means task 8 can start only after both tasks 3 and 5 finish.
• Maintenance effect: If a predecessor moves by three working days, an automatically scheduled successor generally moves accordingly.
• Integrity check: Circular logic, such as task 4 depending on task 6 while task 6 depends on task 4, is invalid.

D. Understanding Task Resources

Task resources are the people, equipment, facilities, or materials assigned to perform an activity.

• Work resources: Developers, analysts, machines, and rooms contribute time measured through assignment units.
• Material resources: Consumable items, such as 200 kg of concrete, are assigned using material quantities.
• Cost resources: Travel or licensing expenses can be attached directly without calculating work.
• Assignment units: 100% means one resource’s full available capacity; two full-time resources total 200%.
• Schedule interaction: Resource calendars and availability can affect dates when resource-leveling or resource-driven calculations apply.

E. Understanding Advanced Task Options

Advanced task options control scheduling behavior beyond basic dates and duration.

• Deadline: A deadline marks a target date and can produce an indicator when missed without normally fixing the task date.
• Task calendar: A selected calendar may allow night work or weekend work for that task.
• Calendar precedence: “Scheduling ignores resource calendars” makes the task calendar control timing despite assigned-resource availability.
• Effort-driven scheduling: When enabled, total work is redistributed as resources are added or removed.
• Inactive task: An inactive task remains visible for planning purposes but does not affect the active schedule.

F. Understanding Task Constraints

A task constraint limits when a task may start or finish.

• Flexible constraints: “As Soon As Possible” permits normal forward scheduling, while “As Late As Possible” supports backward scheduling.
• Inflexible constraints: “Must Start On” and “Must Finish On” impose exact dates.
• Semi-flexible constraints: “Start No Earlier Than” or “Finish No Later Than” establishes one scheduling boundary.
• Date field: A date-based constraint requires both a constraint type and a constraint date.
• Risk: Excessive constraints can override dependency-driven movement and create scheduling conflicts.

G. Understanding Task Types

Task type determines which scheduling variable remains fixed when work, duration, or assignment units change.

Work = Duration × Assignment Units

• Work: Total labor, commonly measured in hours, such as 80h.
• Duration: Working time between task start and finish, such as 10d.
• Units: Resource capacity assigned to the task, such as 100%.
• Fixed Units: Assignment units remain constant when work or duration changes.
• Fixed Work: Total work remains constant; assigning more capacity can reduce duration.
• Fixed Duration: Duration remains constant, so changes may alter work or units.

H. Using Task Notes

Task notes preserve supporting information that does not belong in the task name or schedule fields.

• Suitable content: Acceptance criteria, assumptions, instructions, decision history, and brief contact information.
• Access: Notes are entered through the Notes tab of the Task Information dialog.
• Indicator: Scheduling software commonly displays a notes icon in the Indicators column.
• Good practice: Write actionable text, such as “Obtain security approval before deployment,” rather than an unclear remark such as “Check this.”
• Limitation: Notes document a requirement but do not create a dependency, constraint, or automatic alert.

III. Organizing the Work Breakdown Structure

A. Outlining A Task

Outlining creates a hierarchy that expresses how detailed activities contribute to larger phases or deliverables.

• Indent operation: Indenting a task makes it a subtask of the nearest preceding task at the higher outline level.
• Outdent operation: Outdenting raises a task one level in the hierarchy.
• Outline codes: Numbering such as 2, 2.1, and 2.1.1 shows parent-child relationships.
• Visibility: Collapsing an outline hides lower-level subtasks without deleting them.
• Planning rule: Tasks at the same outline level should represent a reasonably consistent degree of detail.

B. Understanding Summary Tasks

A summary task is a parent row whose schedule and values are aggregated from its subtasks.

• Calculated duration: Its start is normally the earliest subtask start, and its finish is the latest subtask finish.
• Progress roll-up: Work, cost, and completion information are derived from the underlying tasks.
• Phase representation: “System Testing” may summarize test planning, execution, defect correction, and sign-off.
• Linking caution: Dependencies are usually clearer between detailed tasks or milestones than between broad summary tasks.
• Project summary: A project summary task can represent the entire project at outline level 0.

C. Outline tasks into subtasks and summary tasks

Tasks become subtasks and summary tasks through indentation based on the project’s work breakdown structure.

• Procedure: Enter the parent task first, place component activities beneath it, select those activities, and apply Indent Task.
• Result: The parent becomes a bold summary row, while the indented rows become its subtasks.
• Example: Under “Deployment,” indent “Prepare release,” “Install production build,” and “Verify service.”
• Correction: Apply Outdent Task when an activity has been placed under the wrong parent.
• Scheduling effect: Outlining organizes work but does not itself create predecessor links between subtasks.

IV. Dependency Relationships

A. Understanding Linkage Types

Linkage types specify which endpoint of one task controls an endpoint of another task.

• Finish-to-Start (FS): The successor starts after the predecessor finishes.
• Start-to-Start (SS): The successor starts after the predecessor starts.
• Finish-to-Finish (FF): The successor finishes after the predecessor finishes.
• Start-to-Finish (SF): The successor finishes after the predecessor starts.
• Interpretation: In 4SS+1d, task 4 is the predecessor, SS is the relationship, and +1d is lag.

B. Using A Finish To Start Relationship

Finish-to-Start requires the predecessor to finish before the successor can start.

• Notation: A FS B means task B starts after task A finishes.
• Typical use: “Complete coding” precedes “Begin system testing.”
• Calendar behavior: With zero lag, the successor starts at the next available working time after the predecessor’s finish.
• Strength: FS clearly models sequential work and is the most frequently used relationship.
• Limitation: It can overstate delay when tasks can safely overlap.

C. Using A Start To Start Relationship

Start-to-Start allows the successor to start only after the predecessor has started.

• Notation: A SS B links the start of B to the start of A.
• Typical use: “Write documentation” may begin when “Develop module” begins.
• Independence of finishes: The tasks do not have to finish together.
• Lag use: A SS+2d B starts B two working days after A starts.
• Control: An additional relationship may be necessary if the successor must not finish before another event.

D. Using A Finish To Finish Relationship

Finish-to-Finish prevents the successor from finishing before the predecessor finishes.

• Notation: A FF B links B’s finish to A’s finish.
• Typical use: “Quality monitoring” should not finish before “Production run” finishes.
• Start flexibility: B may begin before, with, or after A, subject to duration and other restrictions.
• Lag use: A FF+1d B makes B finish one working day after A finishes.
• Purpose: The relationship coordinates completion rather than commencement.

E. Using A Start To Finish Relationship

Start-to-Finish requires the successor to finish only after the predecessor has started.

• Notation: A SF B means B’s finish depends on A’s start.
• Typical use: An outgoing support shift cannot finish until the incoming shift starts.
• Scheduling direction: It is most understandable in replacement, handover, or just-in-time situations.
• Rarity: Most ordinary project work is represented more clearly by FS, SS, or FF.
• Verification: Because SF is easily reversed conceptually, both task order and arrow direction should be checked.

F. Understanding Simple Linkage

Simple linkage is a direct dependency between two tasks with one relationship and usually zero lag.

• Creation: Select two tasks in predecessor-successor order and use the Link Tasks command.
• Default: Most scheduling tools create an FS relationship unless another type is specified.
• Removal: Unlinking removes the dependency but does not delete either task.
• Chain: Linking A to B and B to C forms A → B → C; it does not require a separate A-to-C link.
• Benefit: Simple links make schedule logic easier to inspect, update, and explain.

V. Schedule Visualization and Timing

A. Spotting Linkages On A Gantt Chart

A Gantt chart displays task links as connector lines between task bars or milestones.

• Arrow direction: The arrow points toward the successor task.
• Attachment points: A line attached to a bar’s finish or start indicates the endpoint used by the relationship.
• Milestones: A milestone is commonly displayed as a diamond, with links connected to that event.
• Cross-check: The Predecessors column provides exact data when overlapping bars make connector lines difficult to interpret.
• Diagnostic value: Missing arrows may reveal unlinked tasks; dense crossing lines may indicate unnecessarily complex logic.

B. Understanding Lag And Lead Time

Lag and lead adjust the delay or overlap within a dependency without creating another task.

1. Lag time: A positive offset, such as FS+2d, delays the successor by two working days after the linked event.
2. Lead time: A negative offset, such as FS-2d, allows the successor to begin two working days before the predecessor finishes.

• Percentage offsets: A value such as FS+50% bases the offset on the predecessor’s duration.
• Appropriate use: Lag can represent curing or waiting time; lead can represent controlled overlap.
• Caution: Substantial active work should be modeled as a task rather than hidden inside lag.

C. Understanding Lead Time On The Gantt Chart

Lead time appears on a Gantt chart as an overlap between linked predecessor and successor bars.

• Visual pattern: Under FS-2d, the successor bar begins two working days before the predecessor bar ends.
• Connector meaning: The link still represents FS; the negative offset shifts the successor relative to the predecessor’s finish.
• Calendar calculation: Two days normally means two working days according to the relevant calendars, not necessarily 48 elapsed hours.
• Schedule effect: Increasing lead can shorten the overall path but may raise coordination or rework risk.
• Inspection: The exact negative value is best confirmed in the Predecessors field or Task Information dialog.

D. Understanding The Types Of Constraints

Constraint types range from flexible scheduling preferences to exact date requirements.

• As Soon As Possible (ASAP): Places work at the earliest permitted date in a forward-scheduled project.
• As Late As Possible (ALAP): Places work at the latest permitted date without delaying the project.
• Start No Earlier Than (SNET): Prevents starting before a specified date.
• Start No Later Than (SNLT): Prevents starting after a specified date.
• Finish No Earlier Than (FNET): Prevents finishing before a specified date.
• Finish No Later Than (FNLT): Prevents finishing after a specified date.
• Must Start On (MSO): Fixes the start to one date.
• Must Finish On (MFO): Fixes the finish to one date.
• Selection principle: Use the least restrictive type that expresses the real requirement so dependencies can continue to drive the schedule.