Project Planning Fundamentals: Sequencing Work and Mapping Dependencies

1) Identify dependency types and when to use them

Sequencing work means deciding the logical order of tasks so the schedule reflects how work actually happens. Dependencies describe how one task’s timing is constrained by another task’s timing. Choosing the right dependency type prevents unrealistic overlaps, hidden waiting time, and “impossible” schedules.

Common dependency relationships

Leads and lags (intentional overlap or waiting)

Beyond the relationship type, you may need a deliberate offset:

• Lag: waiting time between tasks (e.g., curing time, shipping, review window). Example: FS + 3 days.
• Lead: controlled overlap (starting earlier than a strict FS would allow). Example: FS − 2 days (use carefully; it can hide rework risk).

Hard vs. soft dependencies

• Hard (mandatory): dictated by physics, compliance, or technical necessity (e.g., “Provision server” before “Deploy app”).
• Soft (discretionary): chosen for efficiency or preference (e.g., “Write FAQ” after “Draft help content” could be swapped). Marking these helps you compress the schedule later without breaking reality.

Quick selection rules

• Use FS for approvals, sign-offs, and true handoffs.
• Use SS when two tasks can progress in parallel after a kickoff or initial setup.
• Use FF when deliverables must complete together (integration, packaging, release readiness).
• Use lags for external waits (vendor delivery, legal review windows) rather than burying wait time inside task durations.

2) Build a precedence network from your WBS tasks

A precedence network (often drawn as a dependency map) turns a task list into a logical flow. The goal is to make handoffs, approvals, and external waits visible so the schedule can be realistic and defensible.

Step-by-step: build the network

1. List the tasks you will sequence: use the WBS work packages or tasks at the level you plan to schedule (avoid mixing very large and very tiny items).
2. Define the “done” output for each task: one sentence per task describing what is produced (document, configured system, decision, delivered item). This makes handoffs explicit.
3. For each task, ask: “What must be true before this can start?” Capture predecessors and the dependency type (FS/SS/FF/SF) plus any lag.
4. Draw the network: boxes (tasks) connected by arrows (dependencies). Keep it readable: left-to-right flow, minimal crossing lines, group by phase or workstream.
5. Highlight special nodes: approvals, handoffs between roles/teams, and external waits (vendors, regulators, customers).

What to explicitly highlight

• Handoffs: where work moves from one person/team to another. These are common sources of delay due to queue time and clarification needs.
• Approvals: decisions that can block downstream work. Model them as tasks with duration (e.g., “Review & approve” with a realistic review window).
• External waits: shipping, procurement lead times, third-party responses, customer availability. Represent as a dependency with lag or as a separate “wait” task so it is visible.

Mini-example: turning tasks into a network

Suppose you have these tasks (names simplified):

• A: Draft requirements
• B: Review requirements (stakeholder review window)
• C: Approve requirements
• D: Build solution
• E: Test solution
• F: Release

Dependencies might look like:

Continue in our app.

• Listen to the audio with the screen off.
• Earn a certificate upon completion.
• Over 5000 courses for you to explore!

Or continue reading below...

Download the app

A (Draft reqs) --FS--> B (Review reqs, 3 days) --FS--> C (Approve reqs) --FS--> D (Build) --FS--> E (Test) --FS--> F (Release)

If testing can start once the first build is available, you might use SS with a lag:

D (Build) --SS + 5 days--> E (Test)

This makes the overlap explicit and easier to challenge: “Is 5 days enough to have something testable?”

3) Identify critical constraints that shape the sequence

Dependencies describe logical order; constraints describe limits that can override or tighten the schedule. Identifying constraints early prevents building a beautiful network that cannot be executed.

Common critical constraints to capture

• Fixed dates: immovable events such as regulatory deadlines, marketing launch dates, contract milestones, blackout periods, or facility access windows.
• Resource availability: key people only available part-time, shared specialists, holiday coverage gaps, or a single environment that can be used by one team at a time.
• Procurement lead times: vendor quoting cycles, purchase approvals, shipping times, onboarding/security reviews, and contract negotiation.
• Operational windows: maintenance windows, deployment freeze periods, customer business hours, or “only on weekends” cutovers.
• Quality/compliance requirements: mandatory reviews, audit evidence collection, or segregation-of-duties checks that must occur before release.

Step-by-step: add constraints to the network

1. Mark tasks affected by fixed dates: annotate the task box with “Must start on” or “Must finish by” and the date (use sparingly; too many fixed dates make planning brittle).
2. Identify scarce resources: tag tasks that require the same specialist or shared asset; note potential conflicts (two tasks that “must” happen at the same time but need the same person).
3. External lead times: create explicit tasks such as “Vendor delivery lead time” or add lag to the dependency (e.g., “Order placed” --FS + 15 days--> “Hardware received”).
4. Validate feasibility: check whether constraints force re-sequencing (e.g., procurement must start earlier; approvals need longer windows).

Practical example: procurement as a visible driver

If a key component has a 4-week lead time, do not hide it inside “Build solution.” Instead:

G: Select vendor --FS--> H: Place order --FS + 20 business days--> I: Receive component --FS--> D: Build solution

This makes it clear that delaying vendor selection directly delays build start, and it gives you a concrete lever (start procurement earlier, choose in-stock alternatives, or adjust scope).

4) Introduce milestones and stage gates aligned to decision points

Milestones are zero-duration markers that indicate a meaningful point in the project (something achieved, approved, or ready). Stage gates are decision checkpoints where work is reviewed and a “go / no-go / revise” decision is made before committing further effort.

When to use milestones

• To mark completion of a major deliverable (e.g., “Requirements approved”).
• To align cross-team handoffs (e.g., “Build ready for test”).
• To track external events (e.g., “Vendor contract signed,” “Hardware received”).
• To anchor reporting and stakeholder expectations without adding artificial task duration.

When to use stage gates

• Before committing significant cost or irreversible actions (procurement, launch, data migration, customer communications).
• When risk is high and you need explicit acceptance criteria (security review passed, compliance sign-off).
• When the next phase depends on a decision (prioritization, scope trade-offs, go-live readiness).

How to define a good stage gate

• Entry criteria: what must be completed to hold the gate (e.g., test results compiled, open issues list prepared).
• Decision owners: who decides and who must be consulted (keep it explicit).
• Decision options: go / go with conditions / no-go / rework required.
• Exit criteria: what “approved” means (e.g., “No critical defects open; rollback plan reviewed”).

Example milestone and gate set (generic)

Practice: create a dependency map, milestone list, and run sanity checks

A) Create your dependency map (worksheet)

Use this table to capture the minimum information needed to draw a precedence network.

Then draw it as a simple map (paper, whiteboard, or diagram tool):

• One box per task (include ID and short name).
• Arrows labeled with dependency type and lag (e.g., “FS +3d”).
• Use a distinct border color or icon for approvals and external waits.

B) Create a milestone list (starter template)

C) Dependency sanity check (remove circular logic and hidden waiting time)

• Check for circular dependencies: if Task A depends on B and B depends on A (directly or through a chain), the network is impossible. Fix by clarifying the real prerequisite, splitting tasks, or redefining outputs.
• Check every task has at least one predecessor (except true starts): tasks with no predecessors often represent missing dependencies or assumed availability (e.g., “Test” with no link to “Build”).
• Check every task has at least one successor (except true ends): orphan tasks may be unnecessary or missing a handoff.
• Validate approvals are modeled: if an approval is required, represent it as a task with duration or as a milestone preceded by a review task. Avoid “instant approvals” unless truly guaranteed.
• Expose external waits: if a vendor response typically takes 10 days, do not bury it inside a task duration that looks like productive work. Add lag or a visible wait task.
• Challenge excessive SS/FF usage: SS and FF can hide risk by implying parallelism. Confirm what minimum output is needed to start the successor and whether rework is likely.
• Look for unrealistic overlap: leads (negative lag) should be justified with clear partial deliverables (e.g., “Start drafting training while UI is 80% stable”).
• Confirm constraints don’t contradict the logic: fixed dates and resource limits may force re-sequencing. If two tasks require the same scarce resource at the same time, add a dependency or adjust timing assumptions.
• Identify “hidden queues” at handoffs: if work passes to a busy team, add a review/queue buffer explicitly (a short lag or a “triage” task) rather than hoping it happens immediately.

D) A compact checklist you can reuse

Dependency Map Checklist  (tick each item)  [ ] Every task has clear output (“done” definition)  [ ] Approvals are explicit and have time allocated  [ ] External waits are visible (lag or wait task)  [ ] No circular dependencies  [ ] No orphan tasks (missing predecessors/successors)  [ ] SS/FF dependencies justified with partial deliverables  [ ] Key constraints captured (fixed dates, resources, procurement)  [ ] Milestones and stage gates align to real decisions