7.05a–7.05c - Activity networks and critical paths
Turn a list of jobs into an activity network, then find how quickly the whole project can finish. You will construct activity-on-arc networks in 7.05a, use forward and backward passes to find critical activities in 7.05b, and calculate total float in 7.05c.
Constructing activity networks
A gallery needs five jobs completed before an exhibition opens. Preparing the room takes hours, connecting the equipment takes , making signs takes , testing takes , and opening checks take . Must this project take all hours, and could making the signs take four extra hours without delaying the opening? The order of the jobs matters as much as their lengths.
You already know
A graph has vertices and arcs joining them. A path follows consecutive arcs without repeating vertices. The connections matter, rather than the position of the drawing on the page.
Here the arcs are directed: an arrow records the order in which events must occur, and a directed path follows those arrows. Some jobs can happen together. Others have to wait: the signs require the prepared room, testing requires both the room and the equipment, and opening checks require both signs and testing. The table records only immediate predecessors: jobs which must finish before that activity can start, with no intervening activity in that dependency.
| Activity | Job | Immediate predecessors | Duration, hours |
|---|---|---|---|
| Prepare the room | none | ||
| Connect equipment | none | ||
| Make signs | |||
| Test | |||
| Opening checks |
An activity network records these dependencies without assigning workers. For now, assume enough resources for every available activity to start immediately, with fixed durations and no interruption.
Activity-on-arc network
In an activity-on-arc network, each activity is a directed arc labelled with its name and duration. A vertex represents an event: completion of all activities entering it, allowing activities leaving it to start. An event takes no time. A burst has more than one outgoing arc; a merge has more than one incoming arc. For example, the project start is a burst when and can begin together. An activity written inside a vertex is activity-on-node, which is a different representation.
Use a single start and a single finish, with all arcs directed. Numbering events so that arrows go from smaller to larger numbers helps prevent accidental directed cycles. A project cannot require a job to precede itself.
Sometimes two dependencies need to be separated. In this project needs both and , but needs only . Merging and before both and would wrongly make wait for .
Dummy activity
A dummy activity is a directed arc of duration , drawn dashed. It records a dependency and represents no actual work. It can also distinguish activities that would otherwise have the same start and finish events. For example, a dummy from the end of to the end of can make wait for while leaving free to follow alone. A dashed dummy is still an arc whose direction must be respected.
Construct from the dependencies, then read the resulting network back as a check. Use a dummy only when it carries necessary information.
Worked example 1: separating two predecessor lists
Question. Construct an activity-on-arc network for the gallery project in the table above.
Plan. Give and separate finish events, join them for with one dummy, then merge and before .
Why this step? Event can occur only after both and the dummy from have finished. Event can occur after alone, so has the correct, shorter predecessor list.
Answer. The left-hand network below has exactly the required precedences and one dummy activity.
Check. Reading backwards from gives ; from gives ; from gives alone. There is one start, one finish and no directed cycle.
Worked example 2 changes one feature: an extra job follows testing alone. A second dummy is now needed, because the new job must not wait for the signs.
Worked example 2: separating a second merge
Question. The gallery adds activity , which lasts hours and follows alone. The project is complete when both and finish. All five original activities and their dependencies are unchanged. Construct an activity network.
Plan. Keep the first dummy, separate the finish of from the merge of , and use a second dummy to carry 's dependency into that merge.
Why this step? Starting at the same merge as would wrongly make it depend on . The dummy lets wait for testing without making wait for the signs.
Answer. The right-hand network below uses exactly two directed dummy activities and has one finish at event .
Check. Reading immediate predecessors gives , , , and . Neither nor depends on the other, and the project waits for both.
Compare the diagrams at the second merge, where the new job needs a different predecessor list.
[DIAGRAM: asset_name: Dummies preserve different predecessor lists; asset_slug: h245_7_05_activity_construction; caption: One dummy separates the dependencies of C and D. Adding F after D alone requires a second dummy before the merge for E; description: Left panel has the original five-event gallery network with dummy 2 to 3. Right panel adds F of duration 2 and uses six events: A 1 to 2, B 1 to 3, dummy 2 to 3, D 3 to 4, C 2 to 5, dummy 4 to 5, E 5 to 6 and F 4 to 6. Both diagrams have all arcs directed, labelled real activities, dashed zero-duration dummies, a single start and a single finish]

A correct diagram is judged by its dependencies, not by its shape on the page.
Watch out
Wrong: merge and and then start both and . That makes depend on . Right: keep separate completion events and use a directed dummy to pass only the required dependency to .
Now separate both merges in a project with different activities.
Earliest times and the forward pass
At a merge, an event must wait for every incoming activity, so its earliest possible time is the latest of their finishing times.
Return to the original gallery project, with the dummy and lasting hours. Write for the earliest event time at vertex , taking the project start as time . The outgoing activities can start at , so this is also their earliest start time. For example, can start at time , immediately after .
Forward pass
For an activity of duration , its earliest completion is . Starting with , calculate
over all arcs entering event , including dummies of duration . The earliest time at the single finish event is the minimum project completion time, assuming sufficient resources.
Not in the formula booklet: learn it.
The maximum is essential: arriving by one short route does not complete the work on the other routes.
Worked example 3: a merge waits for the later branch
Question. Carry out a forward pass for the original gallery network and determine the minimum project completion time.
Plan. Work from the start towards the finish, adding each arc's duration and taking the maximum at each merge.
Why this step? Although the signs finish at time , testing finishes at time . Opening checks cannot begin until both are complete.
Answer. The earliest event times are . The minimum project completion time is hours.
Check. Activities must occur consecutively and take hours, so no shorter completion time is possible.
Worked example 4 changes one duration: the signs now take hours. The maximum at the merge may therefore come from a different branch.
Worked example 4: a different branch becomes the bottleneck
Question. Activity now takes hours; all other gallery data are unchanged. Determine the new minimum project completion time by a forward pass.
Plan. Keep the early event times before , then recalculate from its finishing event onwards.
Why this step? The dependency structure has not changed, but the controlling branch has: now finishes after .
Answer. The project now takes at least hours.
Check. The path has length , agreeing with the finish event time.
The numbers at events belong to events, not to individual routes. Carry each number to every outgoing arc at a burst.
Continue this lesson.
You’re previewing NovaLearn without an account. Create a free account to read the rest.
Create free account