Defining and sequencing activities

The WBS tells us what will be produced. The schedule tells us when, and building it starts by breaking work packages into activities and working out the order in which they must happen. This lesson covers activity definition, activity attributes and milestones, the precedence diagramming method, the four types of logical relationship, leads and lags, types of dependency, and how to build and check a network diagram. The next lessons add durations and resources, then calculate the critical path.

From work packages to activities

An activity is a distinct, scheduled portion of work performed during the project. Activities are actions, usually described with a verb and a noun: "pour slab", "install kiosks", "train staff". Each work package is decomposed into the activities needed to produce its deliverable. The aim is activities that can be estimated, assigned and tracked, typically lasting from a day or two to a few weeks. As with the WBS, the team and experts should be involved, and templates from similar projects help.

The activity list records each activity with a unique identifier, a description and its WBS code. Activity attributes add detail: predecessors and successors, logical relationships, leads and lags, resource requirements, imposed dates, constraints, assumptions, location and the person responsible. Attributes grow as planning proceeds; early on an activity may have only a name and a WBS link.

Milestones are significant points or events in a project, with zero duration. They mark the completion of major deliverables, decision points, contractual dates or external events. For Project Compass, milestones include lease signed, permit issued, construction complete, occupancy permit issued, soft opening and grand opening. A milestone list identifies which milestones are mandatory, such as contractual or regulatory dates, and which are optional, such as internal checkpoints.

This network is deliberately simplified so that later calculations can be followed by hand. A real fit-out schedule would have a few hundred activities, but the logic is the same.

The precedence diagramming method

The precedence diagramming method (PDM) represents activities as nodes (boxes) and dependencies as arrows. It is sometimes called activity-on-node. Each node can show the activity name, duration and the early and late dates calculated later. An older method, activity-on-arrow, put activities on the arrows and needed dummy activities to show some dependencies; it is rarely used now and you are unlikely to need it on the exam.

Four types of relationship

PDM supports four logical relationships between a predecessor and a successor activity.

Finish-to-start is used for most links. Start-to-finish is rare and often confusing; it appears mainly in handovers and shift changes. When reading an exam question, identify which activity is the predecessor and which is the successor, then ask which end of each is constrained.

Leads and lags

A lead is the amount of time a successor can be advanced relative to its predecessor; a lag is the amount of time a successor must be delayed. Leads and lags modify relationships without changing the activities themselves. A finish-to-start relationship with a 5-day lag means the successor starts 5 days after the predecessor finishes, for example to let paint cure. A finish-to-start relationship with a 5-day lead means the successor starts 5 days before the predecessor finishes, for example starting to move shelving into one zone while finishes are completed in another.

Leads and lags should be documented with their reasons and should not replace proper activities. A two-week lag for "waiting for approval" hides real work; it is better modeled as an activity such as "landlord reviews drawings" with a responsible party. Leads are one way to fast-track a schedule, a compression technique covered in lesson 8, and they add risk because work overlaps.

Types of dependency

Dependencies have four characteristics, combined in pairs. Mandatory dependencies are required by contract or inherent in the work (hard logic): walls must be framed before drywall goes up. Discretionary dependencies are chosen by the team based on best practice or preference (soft or preferential logic): installing the service desk before the shelving is a preference, not a necessity. External dependencies involve something outside the project team's control, such as the building department issuing a permit or a supplier delivering kiosks. Internal dependencies are within the team's control.

The distinction matters when compressing a schedule. Discretionary dependencies can be changed to allow fast tracking; mandatory ones cannot. External dependencies are a common source of risk because the project cannot control them; they should be watched closely and, where possible, managed through agreements.

Building and checking the network

A network diagram is only useful if its logic is sound. Every activity except the first should have at least one predecessor, and every activity except the last should have at least one successor. Activities without a successor (dangling activities) or predecessor (open starts) make the critical path unreliable. Loops, where an activity eventually depends on itself, make it impossible to calculate. Scheduling software flags these problems, but understanding why they matter helps when reviewing a schedule.

# Building and checking the Project Compass fit-out network (finish-to-start links)
acts = {  # id: (description, duration in working days, predecessors)
    "A": ("Design fit-out", 15, []),
    "B": ("Obtain building permit", 20, ["A"]),
    "C": ("Order shelving and RFID gear", 30, ["A"]),
    "D": ("Demolition", 10, ["B"]),
    "E": ("Electrical and data rough-in", 15, ["D"]),
    "F": ("HVAC upgrade", 20, ["D"]),
    "G": ("Finishes", 15, ["E", "F"]),
    "H": ("Install shelving and RFID", 10, ["C", "G"]),
    "I": ("Staff training", 10, ["C"]),
    "J": ("Collection move-in", 8, ["H"]),
    "K": ("Soft opening", 2, ["I", "J"]),
}

def topo(acts):
    order, placed = [], set()
    while len(order) < len(acts):
        ready = [a for a, (_, _, p) in acts.items()
                 if a not in placed and all(x in placed for x in p)]
        if not ready:
            raise ValueError("no activity can be scheduled next; check for a loop among " + ", ".join(sorted(set(acts) - placed)))
        for a in sorted(ready):
            order.append(a); placed.add(a)
    return order

succ = {a: [b for b, (_, _, p) in acts.items() if a in p] for a in acts}
print("Order:", " ".join(topo(acts)))
print("Start activities:", [a for a, v in acts.items() if not v[2]])
print("Finish activities:", [a for a in acts if not succ[a]])
print("Merge points:", [a for a, v in acts.items() if len(v[2]) > 1])
print("Burst points:", [a for a in acts if len(succ[a]) > 1])

bad = dict(acts); bad["A"] = ("Design fit-out", 15, ["G"])   # a mistaken link
try:
    topo(bad)
except ValueError as e:
    print("Check found:", e)

Order: A B C D I E F G H J K
Start activities: ['A']
Finish activities: ['K']
Merge points: ['G', 'H', 'K']
Burst points: ['A', 'C', 'D']
Check found: no activity can be scheduled next; check for a loop among A, B, C, D, E, F, G, H, I, J, K

The script finds the order in which activities can be scheduled, confirms there is a single start (A) and finish (K), and lists merge points (activities with several predecessors) and burst points (activities with several successors). Merge points matter for risk: G, H and K each wait for several paths, so a delay on any one of them can hold up the merge. The final check shows what happens if someone mistakenly makes design depend on finishes: no activity can be scheduled, because the logic contains a loop.

Other checks are worth making. Are there hard-coded dates (constraints) that override logic? Are lags long and unexplained? Are there activities with no resources? Does every work package have at least one activity? The schedule should be reviewed with the people doing the work, who often spot missing activities such as inspections, approvals, deliveries and handovers.

Sequencing in adaptive work

Adaptive teams sequence work differently. Within a sprint, the team decides how to organize the work. Across sprints, the product owner orders the backlog by value, risk and dependencies, and teams identify technical dependencies during backlog refinement. Large programs use dependency boards or big-room planning to make cross-team dependencies visible. In hybrid projects, the interface points between adaptive and predictive work become milestones in the network. For Project Compass, "app release 1 published" is an external-to-the-fit-out milestone that must be complete before the soft opening, and "kiosk interface specification approved" is a dependency from the technology work to the app team.

Reviewing a contractor's schedule

On contracted work, the project often receives a schedule from the contractor rather than building it. Reviewing it uses the same ideas as this lesson. Check that every activity is linked, that relationships make sense, that lags are explained, that milestones match the contract, that the owner's own activities (such as approvals, owner-supplied equipment and inspections) appear with realistic durations, and that the critical path runs through the work you would expect. For Project Compass, the project manager's review of the general contractor's first schedule found that the landlord's approval of the HVAC roof curb was missing and that shelving delivery was shown as a contractor activity, although the library was buying the shelving directly. Both were corrected before the schedule was accepted as the basis for progress payments.

Many organizations and contracts specify schedule quality checks, such as limits on the share of activities with lags, missing links or hard constraints. These checks do not guarantee a good schedule, but a schedule that fails them is almost certainly unreliable.