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?

  1. Finish-to-Start with a 2-day lead.
  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 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.

AI Systems with Claude, for Scrum Masters and Project Managers

Most AI pilots in project management do not fail on the model. They fail because somebody pointed the thing at a decision instead of at a task. This course is built around that distinction, and around the work that follows once you get it right.

Eight teaching sections, taught against one running project from the first lecture to the last. You watch a system get built, then you build the same one against your own sprint. Nothing here is a demo that works only on the example.

You finish with five working systems and you keep them. The sprint report machine turns your board export and standup notes into the report you currently write by hand. The retro intelligence system tells you what the team keeps saying, not just what it said this time. The stakeholder comms engine drafts the update in the register the audience expects. The backlog health monitor flags the quiet decay nobody has time to check for. The risk and dependency tracker follows the chains that actually bite.

Seventy-six working files ship with it, across four sections, so every system is built against real sprint data rather than material invented for a slide. Four sprints of retrospectives, board exports, standup notes, backlog and risk data.

Explore the Course


Stop Managing Admin. Start Leading the Future!

HK School of Management and Technology helps you learn AI prompt engineering for project work. Move beyond status reports and risk logs with practical prompt frameworks for everyday tasks. Practical skills, tools, and guidance you can apply right away. Covered by Udemy's 30-day refund policy.

Enroll Now