HKSM

A logical relationship describes the time-based link between two activities (finish-to-start, start-to-start, finish-to-finish, or start-to-finish). It determines sequence and overlap so the schedule model reflects how work really flows and can be calculated.

Key Points

• Four types: Finish-to-Start (successor can start after predecessor finishes), Start-to-Start (successor can start after predecessor starts), Finish-to-Finish (successor can finish after predecessor finishes), Start-to-Finish (successor can finish after predecessor starts; rarely used).
• Defined between a predecessor and a successor, optionally with a lead (negative lag) or a lag (delay).
• Chosen to represent actual work sequencing, handoffs, or policy constraints, then documented in activity attributes.
• Drives network logic, critical path, float, and how dates propagate through the schedule model.
• Keep logic clear and minimal: prefer simple FS links, use SS/FF to model overlap, and avoid SF unless truly required.
• Aim for each activity to have at least one predecessor and one successor, except for project start and finish nodes.

Purpose of Analysis

• Capture how deliverables are produced and handed off so the schedule computes realistic early/late dates.
• Enable safe parallel work by using SS/FF where appropriate to shorten overall duration without masking risk.
• Support schedule compression, what-if scenarios, and identification of critical and near-critical paths.
• Expose waiting times and handoff risks so they can be managed or redesigned.

Method Steps

• Map deliverable flow: list activities and the outputs each one needs from others.
• For each pair, ask “what must exist before this can start or finish?” to identify the natural predecessor.
• Select the relationship type that best models the timing (FS, SS, FF, or SF), starting with FS by default.
• Add only the minimum lead or lag needed to reflect real timing, and note the rationale.
• Enter logic into the scheduling tool and generate the preliminary network and dates.
• Review with the team to validate overlaps, lags, and handoffs; adjust as needed.
• Run logic checks for open starts/finishes, circular paths, and excessive lags.
• Iterate during planning and when change requests or risks alter the work sequence.

Inputs Needed

• Activity list and activity attributes, including descriptions and constraints.
• WBS and deliverable flow or process maps.
• Milestones, assumptions, and known handoffs or approvals.
• Resource calendars and availability if sequencing depends on teams or equipment.
• Risk register entries that affect sequencing or overlap feasibility.
• Contracts, compliance requirements, and organizational policies that impose order.
• Historical schedules or templates for similar work.

Outputs Produced

• Documented predecessor–successor links with relationship type and any lead/lag values.
• Updated activity attributes and the project schedule network diagram.
• Refined schedule model with recalculated early/late dates, float, and critical path.
• Notes on logic assumptions for governance, audits, and future updates.

Interpretation Tips

• Use FS for straightforward handoffs; switch to SS or FF to safely model overlap and staged deliveries.
• Keep lags small and justified; consider modeling lengthy waits as explicit activities for transparency.
• Document leads clearly since they increase risk and may hide rework potential.
• Check for dangling activities with no predecessor or successor and resolve them to maintain network integrity.
• Validate that logic, not date constraints, drives the schedule whenever possible.

Example

Feature development for a mobile app:

• A: Define requirements → B: Design UI (FS, 0d lag).
• A: Define requirements → C: Develop backend API (FS, 0d lag).
• B: Design UI → D: Develop UI (FS, 0d lag).
• D: Develop UI → E: System testing (SS, +2d lag) to start testing two days after UI development begins.
• C: Develop backend API → E: System testing (FF, 0d lag) so testing cannot finish until the API is complete.

This logic allows controlled overlap of development and testing while ensuring testing completion depends on backend completion.

Pitfalls

• Overusing lags to model work time, which hides effort and risks; model as activities instead.
• Misapplying SS/FF to force dates rather than reflect real handoffs.
• Leaving open starts/finishes that distort float and path analysis.
• Creating circular logic or using SF when an FS or SS would be clearer.
• Burying risky assumptions in leads that are not visible to stakeholders.

PMP Example Question

Testing can begin two days after development starts, and both activities may proceed in parallel. Which logical relationship and timing should link development (predecessor) to testing (successor)?

1. Finish-to-Start with a 2-day lag.
2. Start-to-Start with a 2-day lag.
3. Finish-to-Finish with a 2-day lag.
4. Start-to-Finish with a 2-day lag.

Correct Answer: B — Start-to-Start with a 2-day lag.

Explanation: SS models parallel starts, and the 2-day lag delays testing until two days after development starts. FS would block testing until development finishes, which is not intended.