5.8 Sequence Activities
| 5.8 Sequence Activities | ||
|---|---|---|
| Inputs | Tools & Techniques | Outputs |
Arrange project activities in the right logical order by defining dependencies and leads/lags, resulting in a network diagram that supports duration estimating and schedule development.
Purpose & When to Use
Sequence Activities organizes the activity list into a logical order so work can flow efficiently. It defines how tasks relate (what must happen before or alongside what), enabling creation of a network diagram and later the critical path. Use this after the activity list is defined and before estimating durations and developing the schedule.
Mini Flow (How It’s Done)
- Review the activity list, activity attributes, and milestone list to understand all work items.
- Identify dependencies: mandatory (by nature of the work), discretionary (best practice or preference), and external (outside parties or events).
- Select relationship types between activities: Finish-to-Start (FS), Start-to-Start (SS), Finish-to-Finish (FF), or Start-to-Finish (SF).
- Apply leads and lags where justified, documenting the reason and the amount (e.g., SS with 2-day lag).
- Capture constraints and assumptions that affect ordering, and note external or cross-team links.
- Build the network diagram, aiming for a clear single start and single finish path where practical.
- Validate logic with the team and stakeholders; look for loops, open ends, and unnecessary constraints.
- Update activity attributes with predecessors, successors, relationship types, and lead/lag details.
- Record changes to risks and assumptions that arise from dependencies (e.g., supplier timing risk).
Quality & Acceptance Checklist
- Every activity (except project start/finish milestones) has at least one predecessor or successor recorded.
- Relationship types are correct and minimal; FS is used by default unless SS, FF, or SF adds needed realism.
- Leads and lags have numeric values and documented reasons; they are not used to hide missing work.
- Discretionary dependencies are explicitly labeled and can be changed if schedule compression is needed.
- Hard date constraints are avoided unless truly required; logic, not dates, drives the sequence.
- The network diagram has no loops and no dangling activities; paths are traceable end to end.
- External dependencies are identified, documented, and linked to risk responses and monitoring.
- Updates to the assumptions log and risk register reflect key dependency uncertainties.
- Traceability to the WBS is maintained so scope changes can be reflected in activity logic.
Common Mistakes & Exam Traps
- Using fixed dates instead of logical links, which weakens the schedule and hides true drivers.
- Overusing leads (negative lag) to force overlap rather than modeling additional activities.
- Leaving open ends: activities without predecessors or successors, causing broken network paths.
- Misapplying relationship types; for example, using FF when the intent is to start work in parallel (SS).
- Skipping team validation and relying on one person’s view of the sequence.
- Ignoring external dependencies and not reflecting them as risks with monitoring actions.
- Confusing processes: sequencing orders activities; estimating durations and resource assignments come later.
- Mixing up visuals: a network diagram shows logic; a Gantt chart shows timing after durations are applied.
- Treating lags as percentages; lags and leads should be defined in measurable time or effort units.
PMP Example Question
The team wants testing to begin two days after development starts, with both activities running in parallel. Which relationship should the scheduler use?
- Finish-to-Start with a 2-day lead.
- Start-to-Start with a 2-day lag.
- Finish-to-Finish with a 2-day lag.
- Start-to-Finish with a 2-day lag.
Correct Answer: B — Start-to-Start with a 2-day lag.
Explanation: SS with a 2-day lag starts the successor two days after the predecessor begins. FS with a lead references finish, not start, and would not tie the start times as required.
HKSM