Unit 4: Task Linkages - Subjective Questions

A logical task sequence arranges project tasks according to the order in which they must be performed, based on dependencies rather than merely on dates.

Steps to create a logical sequence:

• Identify all tasks required to complete the project.
• Break large activities into manageable subtasks.
• Determine which tasks must occur before others.
• identify tasks that can be performed simultaneously.
• Assign appropriate predecessor and successor relationships.
• Add lag or lead time where necessary.
• Review the sequence for missing, circular, or unnecessary dependencies.
• Verify the resulting schedule using the Gantt Chart.

A well-designed logical sequence allows scheduling software to calculate realistic start dates, finish dates, and overall project duration.

The General tab contains the basic properties of a selected task. It is commonly used to view or modify:

• Task name: Identifies the activity.
• Duration: Specifies the expected working time required by the task.
• Percent complete: Records the progress made on the task.
• Start and finish dates: Display or modify the scheduled dates, subject to scheduling settings.
• Priority: Controls how the task is treated during resource leveling.
• Milestone status: Allows a task to be displayed as a milestone.
• Task calendar: Assigns a specific calendar to the task when required.
• Scheduling mode: Indicates whether the task is manually or automatically scheduled, where supported.

The tab provides a central location for entering and reviewing essential task information.

A task predecessor is a task whose start or finish controls the scheduling of another task, called its successor.

Predecessor information generally includes:

• The identifier or name of the predecessor task.
• The dependency type, such as Finish-to-Start or Start-to-Start.
• Any lag or lead applied to the relationship.

For example, if Task B has Task A as a Finish-to-Start predecessor, Task B normally cannot begin until Task A finishes. When the duration or date of Task A changes, scheduling software recalculates Task B and other dependent tasks. Predecessors therefore create a dynamic schedule in which changes can flow through the entire task network.

Task resources are the people, equipment, facilities, or materials required to perform a task.

Common resource categories include:

• Work resources: People and equipment whose effort is measured in time.
• Material resources: Consumable items such as cement, paper, or cables.
• Cost resources: Expenses such as travel or service charges.

Resource assignments can affect:

• Work: The total effort required to complete the task.
• Duration: The elapsed working time needed for completion.
• Units: The percentage or capacity of a resource assigned.
• Cost: The expense calculated from resource rates and usage.
• Availability: A limited resource may cause overallocations or schedule delays.

The precise effect of changing an assignment depends on the task type and whether effort-driven scheduling is enabled.

Advanced task options provide additional control over task behavior. Important settings may include:

• Constraint type and date: Restrict when a task can start or finish.
• Task type: Determines whether work, duration, or resource units remain fixed.
• Effort-driven scheduling: Redistributes work when resources are added or removed.
• Deadline: Records a target completion date without normally restricting scheduling.
• Task calendar: Applies a special working-time calendar.
• Ignore resource calendars: Schedules the task according to its task calendar even when assigned resources have different availability.
• Recurring or milestone behavior: Supports special task representations where applicable.
• WBS or outline information: Helps organize the task within the project hierarchy.

These options should be used carefully because they can significantly influence automatic scheduling calculations.

A task constraint is a rule that limits the dates on which a task may start or finish.

Flexible constraints:

• As Soon As Possible (ASAP): Schedules the task at the earliest available date in a forward-scheduled project.
• As Late As Possible (ALAP): Schedules the task at the latest possible date without delaying the project.

Semi-flexible constraints:

• Start No Earlier Than (SNET): Prevents the task from starting before a specified date.
• Start No Later Than (SNLT): Prevents the task from starting after a specified date.
• Finish No Earlier Than (FNET): Prevents completion before a specified date.
• Finish No Later Than (FNLT): Prevents completion after a specified date.

Inflexible constraints:

• Must Start On (MSO): Fixes the task start to a specified date.
• Must Finish On (MFO): Fixes the task finish to a specified date.

Flexible constraints allow dependencies to drive the schedule, while inflexible constraints can override scheduling flexibility and should therefore be used only when necessary.

Task types control which scheduling variable remains constant when resource assignments are changed. Their behavior is based on the relationship:

Fixed Units:

• Resource assignment units remain constant.
• Changing work normally changes duration.
• Changing duration normally changes work.

Fixed Work:

• Total work remains constant.
• Adding resources can reduce duration.
• Reducing available resource units can increase duration.
• Fixed Work tasks are generally effort-driven.

Fixed Duration:

• Task duration remains constant.
• Changes to resource units normally change the calculated work.
• It is suitable when a task must occupy a fixed period regardless of staffing.

The appropriate task type depends on whether resource capacity, total effort, or elapsed task duration is the most stable project variable.

Task notes are descriptive details attached to an individual task. They can be entered through the task information interface and may contain formatted text, lists, references, assumptions, or instructions.

Task notes are useful for recording:

• Detailed task requirements.
• Technical or operational instructions.
• Assumptions used in estimating duration or cost.
• Reasons for scheduling decisions.
• Risks, issues, and special conditions.
• Acceptance criteria or completion details.
• References to related documents or stakeholders.

Notes provide context without making the task name excessively long. They also preserve important scheduling knowledge for team members and future project reviews. However, critical dependencies and constraints should still be represented through proper scheduling fields rather than only being written in notes.

Task outlining is the hierarchical organization of project tasks into phases, work packages, summary tasks, and subtasks.

Procedure:

• Enter the project activities in an appropriate sequence.
• Create a task that represents a major phase or work package.
• Place the related detailed activities immediately below it.
• Indent those detailed activities to make them subtasks.
• The task above the indented activities becomes their summary task.
• Use additional indent levels when further decomposition is required.
• Outdent a task to move it to a higher level in the hierarchy.

The outline makes a work breakdown structure easier to read and manage. It supports collapsing and expanding phases, reporting at different levels, and viewing rolled-up schedule information.

A summary task represents a phase or group of related subtasks in an outlined schedule. It summarizes information calculated from the tasks beneath it.

Its values are generally determined as follows:

• Start: The earliest scheduled start among its subtasks.
• Finish: The latest scheduled finish among its subtasks.
• Duration: The working-time span between the summary start and finish, rather than the simple sum of subtask durations.
• Cost: The rolled-up total of costs from its subtasks and assignments.
• Work: The accumulated work of the subtasks.
• Progress: A calculated roll-up based on the progress and duration or work of the underlying tasks.

Dependencies and resources should usually be assigned to detailed subtasks. Linking or assigning resources directly to summary tasks can produce confusing schedule behavior and double counting.

The four principal dependency relationships are:

• Finish-to-Start (FS): The successor starts after the predecessor finishes. This is the most common relationship.
• Start-to-Start (SS): The successor starts after the predecessor starts. The tasks may overlap.
• Finish-to-Finish (FF): The successor finishes after the predecessor finishes. Their start dates may differ.
• Start-to-Finish (SF): The successor finishes after the predecessor starts. This relationship is uncommon and is often used for shift or service handovers.

Each relationship identifies the predecessor event and successor event being connected. Lag can delay the successor event, while lead can permit overlap. The linkage type should reflect the real operational dependency between tasks rather than be chosen solely to force preferred dates.

In a Finish-to-Start (FS) relationship, the successor task cannot start until the predecessor task has finished.

Example:

• Predecessor: Complete software coding.
• Successor: Begin system testing.

Testing starts only after coding has been completed and delivered. If coding is delayed by three working days, testing is also moved by three working days unless float, another dependency, or a constraint changes the result.

FS is the default and most frequently used linkage because many activities naturally follow a sequential flow. A lag may be added when waiting time is required, while lead may be used when the successor can begin before the predecessor is fully complete.

In a Start-to-Start (SS) relationship, the successor cannot start until the predecessor has started. It does not require both tasks to finish together.

Example:

• Predecessor: Start coding application modules.
• Successor: Start preparing unit test cases.

Once coding begins, test-case preparation can also begin. If an SS lag of two days is applied, test-case preparation starts two working days after coding starts.

This relationship supports parallel or overlapping work and can shorten the project schedule. However, the tasks may need additional finish dependencies if their completion order is also important. An SS link alone controls only the relationship between their start events.

In a Finish-to-Finish (FF) relationship, the successor cannot finish until the predecessor has finished. The relationship controls completion dates rather than start dates.

Example:

• Predecessor: Complete data migration.
• Successor: Complete migration verification.

Verification may begin while migration is in progress, but it cannot be declared complete before migration itself is complete. An FF lag can require verification to finish a specified period after migration finishes.

FF is useful when activities can proceed simultaneously but their completion order must be coordinated. Since it does not directly control when the successor starts, another dependency or scheduling condition may be needed to define a realistic start date.

In a Start-to-Finish (SF) relationship, the successor task cannot finish until the predecessor task has started.

Example:

• Predecessor: Start the new support shift.
• Successor: Finish the previous support shift.

The previous shift cannot finish until the replacement shift begins, ensuring uninterrupted service.

SF is uncommon because most project work is controlled by the finish of earlier work rather than by the start of replacement work. It is mainly suitable for handovers, continuous operations, staffing transitions, and service replacement. Care must be taken to identify the predecessor and successor correctly, since reversing them can produce an illogical schedule.

Simple linkage usually refers to connecting tasks with a direct Finish-to-Start relationship and no lag or lead. It creates a straightforward sequence in which one task begins when the preceding task finishes.

Links can be created by:

• Selecting tasks in sequence and using the Link Tasks command.
• Entering predecessor task identifiers in the Predecessors column.
• Using the predecessor section of the Task Information dialog box.
• Dragging a dependency line between task bars in the Gantt Chart, where supported.

After creating a link, the scheduler recalculates the successor task. The link should be checked to ensure that the predecessor direction and dependency type represent the actual work process.

On a Gantt Chart, task linkages are normally displayed as connector lines with arrows between task bars. The direction of the arrow points toward the successor task.

They can be interpreted by examining:

• The endpoint of the line on the predecessor bar.
• The endpoint or arrow on the successor bar.
• Whether the connection joins starts, finishes, or one of each.
• Any visible gap that may indicate lag.
• Any overlap that may indicate lead or a parallel dependency.
• Changes in successor dates when predecessor bars are moved.

For example, a line from the finish of one bar to the start of another represents an FS relationship. If the chart is crowded, the Predecessors column or Task Information dialog box should be used to confirm the exact linkage type and lag value.

Lag time is a planned delay inserted between linked task events. Lead time allows a successor to begin or finish before the normal dependency point and is commonly represented as negative lag.

Lag example:

• Task B has an FS relationship with Task A and a two-day lag.
• Task B starts two working days after Task A finishes.

Lead example:

• Task B has an FS relationship with Task A and a two-day lead.
• Task B may start two working days before Task A finishes.

Lag can represent curing, approval, delivery, or waiting time. Lead can represent controlled overlap, such as beginning testing before all modules are complete. Both may be entered as working-time values or percentages, depending on the scheduling tool. Excessive use of lead can increase schedule risk because the successor may depend on incomplete predecessor output.

Lead time is commonly entered as a negative lag value, such as FS -2 days or FS -25%. On the Gantt Chart, it appears as an overlap between the linked predecessor and successor task bars.

For example, if coding is scheduled for ten days and testing has an FS dependency with a two-day lead, testing can begin two working days before coding finishes. The dependency line reflects the connection even though the bars overlap.

Scheduling consequences include:

• Shorter overall elapsed project time.
• Earlier successor start or finish dates.
• Increased coordination between teams.
• Greater risk of rework if predecessor output changes.
• Possible ambiguity if the amount of completed predecessor work is not clearly defined.

Lead should therefore be used only when partial predecessor output is genuinely sufficient for the successor to proceed.

A possible project outline is:

• 1. Planning and Design — summary task
• 1.1 Requirements Analysis — subtask
• 1.2 System Design — subtask
• 2. Development and Testing — summary task
• 2.1 Coding — subtask
• 2.2 Test Planning — subtask
• 2.3 System Testing — subtask
• 3. Release — summary task
• 3.1 Deployment — subtask

Suggested linkages:

• System Design follows Requirements Analysis using FS.
• Coding follows System Design using FS.
• Test Planning follows the start of Coding using SS, possibly with a short lag.
• System Testing follows Coding using FS. A carefully justified lead could allow testing of completed modules before all coding ends.
• Deployment follows System Testing using FS.

Constraints and scheduling choices:

• Use ASAP for normal tasks so dependencies drive the schedule.
• Apply Start No Earlier Than to Deployment only when an external release window exists.
• Use a deadline to record a target release date without unnecessarily fixing the schedule.
• Assign resources to detailed tasks rather than summary tasks.
• Add task notes to document assumptions, entry criteria, and reasons for any lead or lag.

This structure separates management-level phases from executable work while preserving a logical and maintainable schedule.